You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs/conventions/topic-docs/README.md:33 and its "Contract-slice lifecycle (prune with pointer)" section (README.md:290-309) are normative: the contract slice docs/topics/<slug>/ is "Committed on the task branch only; pruned before merge", durable outcomes graduate through the knowledge-vault and work-item-tracker seams, and a final commit prunes the slice leaving context pointers.
Step 5 of the lifecycle specifies the enforcement mechanism — "a required check that the net PR diff (git diff --name-only base...head) contains no path under the resolved <contract_dir>/**". That check does not exist. The docs/topics references in .github/workflows/ci.yml and scripts/docs-only-paths.txt serve docs-only PR detection, not slice pruning.
Raised by chatgpt-codex-connector against #1322, correctly, on the topic-doc slice that PR carries.
The decision this needs
Not "should #1322 prune its slice" — pruning one slice while 16 siblings stay would make the corpus less consistent, and the missing gate means nothing stops the next one either. Two coherent options:
Amend the convention to match practice. If durable design records under docs/topics/ are actually wanted on main, the README's "task-branch-only / pruned before merge" classification is wrong and should say what the repo means. The redaction bar (README.md:315-320) would then become the load-bearing rule for what may land, rather than the prune step.
Deciding by precedent is not sufficient in either direction: 16 slices on main is evidence of what happens, not an argument for what should. But the divergence must be closed on one side, because right now the written contract and every merged PR disagree.
#1322 lands its slice consistently with the 16 that preceded it, and its review thread is declined with a pointer here rather than resolved by a unilateral prune.
docs/conventions/topic-docs/README.md:33and its "Contract-slice lifecycle (prune with pointer)" section (README.md:290-309) are normative: the contract slicedocs/topics/<slug>/is "Committed on the task branch only; pruned before merge", durable outcomes graduate through the knowledge-vault and work-item-tracker seams, and a final commit prunes the slice leaving context pointers.The repository does not do this.
The evidence
git ls-tree -d --name-only origin/main docs/topics/returns 16 slices:ai-adoption-ladder,autonomy-ignition,babysit-prs-migration,boris-video-absorption,commit-convention-well-known-path,dometrain-mcp,fable-field-guide-audit,fresh-eyes-checkpoint-audit,github-plugin-candidates,handoff-bg-cutover,ladder-climb-roadmap,loop-engineering-codification,plugin-audit-port,plugin-fleet-sync-skill,plugin-organization,underspecificationStep 5 of the lifecycle specifies the enforcement mechanism — "a required check that the net PR diff (
git diff --name-only base...head) contains no path under the resolved<contract_dir>/**". That check does not exist. Thedocs/topicsreferences in.github/workflows/ci.ymlandscripts/docs-only-paths.txtserve docs-only PR detection, not slice pruning.Raised by
chatgpt-codex-connectoragainst #1322, correctly, on the topic-doc slice that PR carries.The decision this needs
Not "should #1322 prune its slice" — pruning one slice while 16 siblings stay would make the corpus less consistent, and the missing gate means nothing stops the next one either. Two coherent options:
mainthat are currently readable there.docs/topics/are actually wanted onmain, the README's "task-branch-only / pruned before merge" classification is wrong and should say what the repo means. The redaction bar (README.md:315-320) would then become the load-bearing rule for what may land, rather than the prune step.Deciding by precedent is not sufficient in either direction: 16 slices on
mainis evidence of what happens, not an argument for what should. But the divergence must be closed on one side, because right now the written contract and every merged PR disagree.Not blocking #1322
#1322 lands its slice consistently with the 16 that preceded it, and its review thread is declined with a pointer here rather than resolved by a unilateral prune.