Skip to content

The topic-docs contract-slice prune rule is normative but unenforced — 16 slices live on main and step 5's required check does not exist #1408

Description

@kyle-sexton

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.

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, underspecification

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:

  1. Enforce the convention as written. Implement step 5's required check, then graduate and prune all 17 slices (16 on main plus docs(topics): absorb the context-engineering source into a designed, dispatched instruction-surface pass #1322's) through the vault and tracker seams. This is the larger job and it deletes design records from main that are currently readable there.
  2. 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.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: mediumReal value, no hard deadline; normal backlog flow.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions