Filed by the domain:devx PM seat of objectstack-ai/objectstack (session session_015ahemw8RcTgqtxrj15PEZx) at accept time of objectstack#11540, per that card's triage instruction: "the objectui CLAUDE.md:16 copy lands in objectui — per the linkage rule the accepting seat files the objectui follow-on card (with Blocked-by: on this one) when this PR is accepted."
Blocked-by: objectstack#11540
Restart-when: objectstack PR #11934 merges
Unlock-action: port the same repair here, re-measuring the drift on THIS repo's checkout
⚠️Blocked-by: can only name an issue, but the real condition is "a PR merges" — the gap measured in objectstack#11220. Check PR #11934's merge state, not #11540's.
The defect
The documented worktree recipe branches off the localmain ref, which nothing in the recipe or its surrounding prose fetches. A worktree created by following it literally starts as far back as whoever last happened to update that ref — and on a long-lived shared checkout, nobody has a reason to. Measured on the objectstack side: local main was 1158 commits / 202 hours behind origin/main.
⚠️ TWO sites here, not one — the second is not the one triage named
Read on origin/main of this repo:
| site | text | verdict |
|---|
CLAUDE.md:16 | git worktree add ../<repo>-<task> -b <branch> main && cd … && pnpm install | in — the site triage named |
AGENTS.md:234 | git worktree add ../objectui-<task> -b <branch> main | in — ⭐ not named by triage; same defect, inside the Chinese prose of the multi-agent discipline section |
CLAUDE.md:40 | git worktree add ../objectui-<task>-cmp <ref> | out — takes an explicit ref from the caller, correct as written |
AGENTS.md:240 | git worktree add ../objectui-<task>-cmp <ref> | out — same |
Control for those readings: CLAUDE.md is 51 lines, non-empty.
⚠️origin/main alone would have the same defect one layer down — it is a local ref only a fetch moves. The objectstack repair therefore begins each fixed site with an explicit git fetch origin main &&, and this one should too.
The landed shape to port
objectstack PR #11934 (governed, awaiting hand-merge) rewrites its three in-scope sites to:
git fetch origin main && git worktree add ../<repo>-<task> -b <branch> origin/main && cd ../<repo>-<task> && pnpm install
⚠️Check this repo's line-budget situation before assuming the edit is free. On the objectstack side both governed files sat at their shrink-only ceilings with zero headroom, and the repair had to be paid in place — one paragraph was reflowed, dropping only filler words, to buy the added text. Whether objectui has an equivalent ratchet on AGENTS.md / CLAUDE.md is for the implementer to measure here; ⛔ if it does and there is no headroom, the same rule applies — a ceiling is raised only by a maintainer ruling quoted in the raising PR, never as a side effect.
Both files are governed surface in this repo too, so the PR is draft-only, human merge.
Dedupe — stated honestly, because it is partial
Checked the 50 most recently-updated open issues in this repo (233 open in total) for this shape; nothing matches. The nearest neighbour is #6042 (guard-shared-stash.sh backslash fail-open, porting objectstack#11131) — a different defect in the same multi-agent-discipline family, which is evidence the porting lane exists rather than that this is a duplicate.
⛔ I did not page the remaining ~183. search_issues has been returning total_count 0 even against a positive control that must match (objectstack#11835 tracks that channel being down), so the semantic route was unavailable and only the paged listing worked. If someone finds a duplicate in the unread pages, close this in favour of it.
Filed by the
domain:devxPM seat ofobjectstack-ai/objectstack(sessionsession_015ahemw8RcTgqtxrj15PEZx) at accept time of objectstack#11540, per that card's triage instruction: "the objectuiCLAUDE.md:16copy lands in objectui — per the linkage rule the accepting seat files the objectui follow-on card (withBlocked-by:on this one) when this PR is accepted."Blocked-by:can only name an issue, but the real condition is "a PR merges" — the gap measured in objectstack#11220. Check PR #11934's merge state, not #11540's.The defect
The documented worktree recipe branches off the local
mainref, which nothing in the recipe or its surrounding prose fetches. A worktree created by following it literally starts as far back as whoever last happened to update that ref — and on a long-lived shared checkout, nobody has a reason to. Measured on the objectstack side: localmainwas 1158 commits / 202 hours behindorigin/main.Read on
origin/mainof this repo:CLAUDE.md:16git worktree add ../<repo>-<task> -b <branch> main && cd … && pnpm installAGENTS.md:234git worktree add ../objectui-<task> -b <branch> mainCLAUDE.md:40git worktree add ../objectui-<task>-cmp <ref>AGENTS.md:240git worktree add ../objectui-<task>-cmp <ref>Control for those readings:
CLAUDE.mdis 51 lines, non-empty.origin/mainalone would have the same defect one layer down — it is a local ref only a fetch moves. The objectstack repair therefore begins each fixed site with an explicitgit fetch origin main &&, and this one should too.The landed shape to port
objectstack PR #11934 (governed, awaiting hand-merge) rewrites its three in-scope sites to:
AGENTS.md/CLAUDE.mdis for the implementer to measure here; ⛔ if it does and there is no headroom, the same rule applies — a ceiling is raised only by a maintainer ruling quoted in the raising PR, never as a side effect.Both files are governed surface in this repo too, so the PR is draft-only, human merge.
Dedupe — stated honestly, because it is partial
Checked the 50 most recently-updated open issues in this repo (233 open in total) for this shape; nothing matches. The nearest neighbour is #6042 (
guard-shared-stash.shbackslash fail-open, porting objectstack#11131) — a different defect in the same multi-agent-discipline family, which is evidence the porting lane exists rather than that this is a duplicate.⛔ I did not page the remaining ~183.
search_issueshas been returningtotal_count 0even against a positive control that must match (objectstack#11835 tracks that channel being down), so the semantic route was unavailable and only the paged listing worked. If someone finds a duplicate in the unread pages, close this in favour of it.