[Decision] objectos is a fourth repository with no lane, no seat and no pm labels — which shape should it get?

The gap

pm-dispatch models three repositories — "产品横跨三仓: objectstack → objectui and cloud". objectstack-ai/objectos is a fourth, and the protocol has no answer for it:

No domain:* lane covers it and no repo:objectos seat exists, so the seat/lane bijection ("域 X 谁管" / "PM Y 管什么" each have exactly one answer) has no answer for it.
The triage seat is defined as "三仓唯一" and produces classification for three repositories. Nobody triages objectos.
ensure-pm-labels.sh has never run there: no pm:queue, no pm:dispatched, no domain:*. The only pm-vocabulary label present is finding.

This is not hypothetical — work is already flowing through that repository outside the protocol. Open cards objectstack-ai/objectos#61 and objectstack-ai/objectos#64 carry finding with no triage, no domain, no owner. And a change landed there written in-session by a PM seat with no issue filed first, precisely because no lane existed to route it through. That deviation is recorded on objectstack-ai/objectos#66; this card is about the structural cause rather than that one instance.

Update 2026-08-18: dispatch authorized, structure still open

The maintainer has authorized this session to dispatch work in objectos (原话: 「现在允许你派 objectos 的活」), under the standing 维护者直派通道. That unblocks the immediate queue and does not answer this card: an ad-hoc authorization to one session is not a seat, and the next session starts from the same ambiguity that produced the deviation above. The options below stand.

Options

A — full sibling-repo treatment. Extend the triage seat to four repositories; mint a repo:objectos execution seat; run ensure-pm-labels.sh there. This is exactly the shape objectui and cloud already have, so both invariants survive unchanged.
Cost: one more seat Routine and its fire cycles, for a repository with a handful of open issues.

B — triage extended, execution folded into domain:devx (recommended). Triage seat covers four repositories (one extra lane-inventory query per round, no new seat); objectos execution routes to the existing devx lane, which already owns content/docs/** and apps/docs in this repository — objectos is entirely docs and site code. Mint repo:objectos as a seat only when volume justifies it, which is the protocol's own registered scale-out trigger.
Cost: one lane briefly owns docs in two repositories, which is a wrinkle in the bijection until it is split out.

C — declare objectos out of scope. It stays outside the PM loop; issues there are handled ad hoc by the maintainer.
Cost: the gap becomes permanent and deliberate. Every future agent touching objectos hits the same ambiguity and resolves it the same improvised way.

Four facets

Platform long-term coherence — B and A both close the gap; A is more coherent long-run (repo → seat, as with the other two siblings), B is more coherent today (one lane already owns docs, and objectos is only docs). C leaves a documented hole in an otherwise total protocol, and the protocol's value comes from being total. Slight edge to B, converging on A as volume grows.
Measured business pull — thin, and worth saying plainly: a handful of open issues, ~15 merged PRs since the repository was repositioned in July. This is real but low-volume, which argues against minting a seat now and for the cheapest change that removes the ambiguity. Points at B.
AI-agent error-resistance — this is the decisive facet. The failure this card exists because of is an agent finding no lane and improvising one. A and B both make the answer lookup-able; C guarantees the improvisation recurs, and each recurrence will look locally reasonable. Rules out C.
Startup scope discipline — a seat is a permanent obligation (a Routine, a seat post, a fire budget). B adds one query per triage round and no new obligation; A adds an obligation ahead of demand. Points at B.

Four facets converge on B, so this would meet the confidence gate for auto-adjudication on facets alone — but it sits squarely on the human floor: it changes .claude/skills/pm-dispatch/**, which is ADR-class and governed. Filed for you rather than adjudicated.

Implementation notes for whoever takes it

Any PR touching .claude/skills/pm-dispatch/** is model: claude-fable-5 (mandatory clause ①) and merges by hand — governed face, no auto-merge, no queue.
The lane table and the multi-repo section both need editing in the same PR ("新增或退役一个 domain:* 必须同批改本表"); under B the edit is to the repo-coordination section rather than a new domain:* row.
The line ratchet applies: check-skill-line-ratchet.mjs only lets the file shrink, so this has to be paid for with deletions elsewhere or an explicit ratchet-raise decision quoted in the PR body.
bash scripts/pm/ensure-pm-labels.sh needs a repo argument or a run against objectos under either A or B.
objectos has no changeset flow, no packages/, and a different CI shape from the three modelled repositories. Whichever option lands should say so, or dispatched agents will look for machinery that is not there.

Adjudication record (maintainer, 2026-08-18, PM chat with the skills seat, session session_01WswfK2yNYT9hNnMH6TzAwL). Ruling verbatim, untranslated: 「就按 B,带你补的两条,落地吧」

Decided: Option B — triage extends to four repositories; objectos execution folds into domain:devx; no repo:objectos seat is minted now — plus the two seat-proposed additions the ruling adopts:

The A-upgrade trigger is written down, not felt: the implementation states in the multi-repo section that objectos escalates to a full repo:objectos seat when either registered scale-out trigger fires (a round's duration approaching the fire cycle, or the objectos queue persistently starving under the selection total order). B is a recorded transition, not a second hole.
objectos agent-instruction files are governed surface: per the maintainer's standing governed-surface extension ruling (2026-08-18, 「任何对 agents.md 等文件的修改…包括 objectui cloud仓库」→「同意」), the implementation names objectos in that clause — execution routes to devx, but instruction-file PRs there stay draft/human-merge.

Label transition needs-user-decision → claimed in the same stroke (this card lands in .claude/skills/pm-dispatch/** ⇒ skills lane). Option C is rejected; option A deferred behind the written trigger. The single-session objectos dispatch authorization recorded in the body retires once this lands — the lane answer becomes lookup-able.

Generated by Claude Code

Claim: PM loop round 2 (skills seat)
Session: session_01WswfK2yNYT9hNnMH6TzAwL
Branch: claude/issue-9551-objectos-lane-shape-b
Worktree: objectstack-issue-9551
Domain: domain:skills
File surface: .claude/skills/pm-dispatch/SKILL.md (multi-repo coordination section + domain:devx table row + governed-surface clause) — possibly scripts/pm/ensure-pm-labels.sh if the repo-argument route is taken (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5 — clause ① path mandate (.claude/skills/pm-dispatch/**), per dispatch-gates --tier derivation quoted on #9528 this shift
Clause-②: no — internal protocol text; changes no contract accept/reject behaviour, widens no public surface
Serial constraints cleared: NOT yet — hard same-file serial behind PR #9536 (also edits SKILL.md, including the same domain:devx row). #9536 is ACCEPT'd and awaiting the maintainer's merge; dispatch holds until #9536 is MERGED (this session holds a PR subscription on it and dispatches on the merge event). No other open PR touches .claude/skills/**.

Generated by Claude Code

One more constraint, measured while running the first dispatched batch in objectos rather than reasoned about: objectos has no merge queue.

The protocol's landing path for a reviewed dev PR is ready → queue, with "队列是唯一被认可的落地路径, ⛔ 永不队列外合并". In objectos that path does not exist — objectstack-ai/objectos#65 landed by a human pressing merge, and there is no queue workflow in the repository. So a PM seat working objectos can review and flip to ready, and then has nowhere protocol-sanctioned to put the PR. That is not a hypothetical: objectstack-ai/objectos#69 is sitting in exactly that state now, reviewed and green, waiting on a human because the seat has no legitimate way to land it.

Whichever option is chosen needs to say what landing looks like there. Three shapes, no recommendation attached — this is narrower than the seat question and follows from it:

objectos adopts a merge queue, and the existing rule applies unchanged;
the protocol grants a named exception for repositories without a queue (direct merge after review, which weakens a rule that exists because queues serialise a shared resource);
objectos PRs are always merged by a human, which is the de-facto status quo and costs the maintainer one action per PR.

Related to the existing implementation note that objectos has no changeset flow: the gap is not one missing label vocabulary, it is that the repository's CI and landing shape differ from the three modelled ones in more than one place.

Generated by Claude Code

{
  "issue": 9551,
  "status": "done",
  "branch": "claude/issue-9551-objectos-lane-shape-b",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/9558",
  "premise_still_valid": true,
  "summary": "Landed Option B per the adjudication: SKILL.md multi-repo section now states the objectos fold-in (triage sweeps four repos, execution folds into domain:devx, no repo:objectos seat), the written A-upgrade trigger (either registered scale-out trigger from rule 4), and the no-machinery notice (no changeset flow, no packages/, no merge queue = human merge, different CI). The governed-face unified definition (ACCEPT path fork) now names the cross-repo extension for objectui/cloud/objectos with the extension ruling quoted verbatim. ensure-pm-labels.sh adds objectos to the state-machine label loop with commented deliberate exclusions (domain lanes, target boards); running it against objectos is the PM's landing step. Ratchet held at 682/682 — +7 added lines paid by deleting Guardrails text that survives verbatim in the seat invariants, the ACCEPT path fork, and AGENTS.md (payment table in the PR body; no re-wrap used).",
  "tests": "All gates at final head 6a8b11b (clean tree, re-run after the only commit): pnpm check:pm-skill-ratchet exit 0 (SKILL.md 682 lines, ceiling 682); pnpm check:pm-skill-id-lint exit 0 (9 files clean); pnpm check:skill-frame-sync exit 0 (4 copies isomorphic, 3 axes); pnpm check:pm-governed-merges exit 0 (self-test 25 assertions); pnpm check:doc-authoring exit 0 (377 files clean); pnpm --filter @objectstack/lint run check:doc-formula-expressions exit 0 (upstream closure built first; note: '--concurrency=2' placed after --filter was forwarded to tsup and failed the first build — the documented trap, retried with --workspace-concurrency before the filter); node scripts/check-nul-bytes.mjs exit 0 (6157 files). Gate list re-derived with node scripts/pm/dispatch-gates.mjs (no paths, script-derived changed set) — 6 gates matched, identical to the dispatch prompt's list, no additional families for this diff; tier line confirms clause-1 fable floor. bash -n on ensure-pm-labels.sh clean. files_changed: .claude/skills/pm-dispatch/SKILL.md, scripts/pm/ensure-pm-labels.sh (+27/-20). skip-changeset applied via read-modify-write, read back: [size/s, skip-changeset].",
  "open_questions": [
    {
      "question": "Falsified PM mechanism assumption: no cross-repo governed-extension clause exists anywhere in SKILL.md or references/ on main at da808c6 (grep for 包括 objectui / 任何对 agents / governed across the skill dir and AGENTS.md: zero hits), so there was no existing clause to name objectos in. Where should the extension live?",
      "options": ["A - anchor it at the governed-face unified definition in the ACCEPT path fork, which the Guardrails bullet already points to (done in the PR)", "B - a new standalone clause/section (forbidden by the dispatch instruction: do not invent a new section)"],
      "recommendation": "A, because the unified definition is the single source every governed check dereferences; the deviation is recorded here rather than silently absorbed."
    },
    {
      "question": "Unadjudicated sub-question raised on this card after the claim: objectos has no merge queue — which landing shape does the protocol adopt (adopt a queue / named no-queue exception / always human merge)?",
      "options": ["A - objectos adopts a merge queue, existing rule applies unchanged", "B - named protocol exception for queueless repos (direct merge after review)", "C - human always merges (de-facto status quo)"],
      "recommendation": "None issued - this is a maintainer decision outside the adjudicated scope. The PR records only the factual status quo (落地 = 人工合并) as the dispatch-expectations notice; the sub-question stays open on this card."
    }
  ],
  "out_of_scope_findings": []
}

Generated by Claude Code

ACCEPT — PR #9558 (reviewer of record: skills seat, session session_01WswfK2yNYT9hNnMH6TzAwL). Governed surface ⇒ terminal three-step: conclusion here, the PR stays draft awaiting the maintainer's merge, round report lists it under "awaiting a human merge".

Checklist conclusions, verified against GitHub / local runs at head 6a8b11b — not the report's self-description:

Shape: draft, base main, Fixes #9551; changed files exactly .claude/skills/pm-dispatch/SKILL.md + scripts/pm/ensure-pm-labels.sh (+27/−20), within the claimed surface (the script was declared conditional); skip-changeset present, read back.
Content vs the ruling: Option B landed with both additions — fold-in + written A-upgrade trigger + no-machinery notice in the multi-repo section; governed cross-repo extension names objectui/cloud/objectos at the unified definition with the ruling quoted verbatim; triage sections went four-repo with the per-site judgment the dispatch demanded (dependency-direction intro and release-board metric legitimately stay three-repo; the triage section explicitly skips a nonexistent objectos release board — consistent).
Ratchet payment audited cut-by-cut, not taken on faith: all three Guardrails cuts survive verbatim at their pointed homes — the PM-no-files exception in the seat invariants, the governed prohibitions + draft-only dequeue exit in the ACCEPT fork, and the release-act enumeration in AGENTS.md PD#15 (which is richer than the cut bullet: same acts plus the incident case law). The removed AGENTS.md-wins Guardrails line survives in the invariants section. 682/682 held, no re-wrap.
Local gate re-run (my own): ratchet · id-lint · frame-sync · governed-merges self-test · bash -n — all clean at 6a8b11b, matching the report's head.
Deviation, publicly owned by the PM: my dispatch asserted an existing cross-repo governed-extension clause to name objectos in — that assumption was false (the dev's grep evidence stands; no such clause existed). The dev's resolution — anchoring the extension at the governed-face unified definition, the single source every check dereferences — is the right one and is hereby approved. Good falsification, exactly what the mechanism-assumption tier is for.

Open on this card after the PR merges: ① the queueless-landing sub-question (comment 5326477159) — with the seat's recommendation going to the maintainer in chat: adopt C (human always merges) as the standing answer now (volume is a handful of PRs; a named queue exception would weaken the flagship rule for negligible gain), revisit at the written A-upgrade trigger, at which point queue adoption rides the seat upgrade; the PR's factual notice (落地 = 人工合并) then doubles as the rule with zero further diff. ② The PM landing step: run the label vocabulary against objectos.

Generated by Claude Code

Adjudication record — the queueless-landing sub-question (comment 5326477159) resolves as Option A (maintainer, 2026-08-18, PM chat, by action + words, verbatim: 「objectos 加上了merge queue,但是我该执行哪个 Require status checks to pass」). objectos adopts a merge queue; the existing landing rule (ready → queue, never merge outside it) applies unchanged. Instruction-file PRs there remain governed (draft, human merge) per the cross-repo extension in PR #9558.

Settings guidance given in chat, recorded here for the ledger: the required check is build (ci.yml's only job; job id is the check-run name — it carries type-check + build + test). Ownership & freshness must NOT be required (path-filtered — PRs not touching docs paths never produce it and would hang the queue as permanently expected). deploy-docs is a push-to-main deploy, not a PR check. Blocking prerequisite: ci.yml lacks a merge_group: trigger — until one is added, a queued PR waits forever for a build that never starts; the one-line fix is pending (maintainer applies directly, or a devx-lane card).

Generated by Claude Code

Close-out accounting (skills seat, session session_01WswfK2yNYT9hNnMH6TzAwL): PR #9558 MERGED 2026-08-18 11:42Z via the maintainer's enqueue. Card auto-closed via Fixes; removing the stale pm:dispatched (read-modify-write, read back). objectos is now a modeled fourth repository: four-repo triage, execution folded into domain:devx, written A-upgrade trigger, cross-repo governed extension, label vocabulary in ensure-pm-labels.sh.

Remaining landing step, owner: maintainer (needs gh credentials this container lacks; no label-create tool on the agent's MCP surface): run bash scripts/pm/ensure-pm-labels.sh once from any authenticated checkout of current main — it is idempotent across all four repos and now seeds objectos's pm vocabulary. The queue-adoption sub-question resolved as Option A (comment 5327457987); the merge_group: trigger fix for objectos ci.yml is tracked there and pending.

Generated by Claude Code

Navigation Menu

Repository navigation

[Decision] objectos is a fourth repository with no lane, no seat and no pm labels — which shape should it get? #9551

The gap

Update 2026-08-18: dispatch authorized, structure still open

Options

Four facets

Implementation notes for whoever takes it

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Decision] objectos is a fourth repository with no lane, no seat and no pm labels — which shape should it get? #9551

Description

The gap

Update 2026-08-18: dispatch authorized, structure still open

Options

Four facets

Implementation notes for whoever takes it

Activity

os-support-ai commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

os-zhuang commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

os-support-ai commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions