board: record the untracked-plan census — 53 of 208, not 1 - #1156
Conversation
The rubicon-loco session reported r2il-machine-semantic-contract-v1 as the only untracked standalone plan, from a hand review of candidates. That plan was real and is now tracked (#1155). The count is not: a one-line grep over plans vs STATUS_BOARD + INTEGRATION_PLANS returns 53, including whole families (19 3DGS-*, 5 tesseract-rs-*). The finding is not the number. A manual sweep reported 1/208 where a grep reports 53/208, and it under-reported in the direction that feels like completion. A 208-file census has to be mechanical. Root cause sits upstream of the board: several of these carry no D-ids at all, so STATUS_BOARD has nothing to hold and the supersession index's coverage column has nothing to count. The board rule fires when a plan is added, so one that lands without an id is never caught later. Not fixed here on purpose — backfilling 53 plans is a scope decision across several sessions, and some are superseded or are sub-documents that owe nothing. A CI check on the SUPERSESSION-INDEX model is proposed and unbuilt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCfrD5y19cvFc4AoyydXYv
|
Warning Review limit reachedNext included review available in 45 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 84 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (1)
Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_190e850e-5e4d-42e3-bc19-2b2922939d47) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bdc8e91d78
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for f in .claude/plans/*.md; do b=$(basename "$f" .md); \ | ||
| grep -qF "$b" .claude/board/STATUS_BOARD.md .claude/board/INTEGRATION_PLANS.md \ | ||
| || echo "UNTRACKED: $b"; done |
There was a problem hiding this comment.
This loop only searches for each file's basename, so it labels plans untracked even when their deliverables are present in STATUS_BOARD.md. For example, .claude/plans/dtsc1-thinkingstyle-dedup-spec-v1.md:1 defines D-TSC-1, while STATUS_BOARD.md:810,814-815 tracks D-TSC-1..3, but the loop still emits that file; the same occurs for 11 other files in the reported set. Consequently, 53 is a count of missing filename references rather than untracked plans, and using it for the proposed backfill or CI gate would produce false positives. The census should check both basename references and extracted D-ids, then separately adjudicate documents that intentionally owe no board entry.
Useful? React with 👍 / 👎.
Two external P2s, both correct, and both my index entry over-claiming relative to the plan it indexes. P2-1: "byte-identical architectural state" drops the V exclusion. The plan's own §6a records that Ghidra's 6502 ADC assigns the unsigned carry to the signed-overflow flag, so on 255x255 both sides compute 0xFE01 and agree on every other field while Ghidra leaves V=1 and a real 6502 leaves V=0. V is excluded from the headline comparison and the exclusion is itself two-sided (falsifier D7). The entry now says "every field except V" and carries the finding rather than the summary. P2-2: labelling the probe "the executable falsifier for the V4 space binding" makes unfinished projection work look covered. The probe validates the lift-and-execute path against borrowed slabs; it never exercises a projection from SLEIGH's 55-byte layout into a 12-byte facet register. It measures the two layouts and concludes one is needed. Re-worded to "the EXECUTABLE HALF", with the misreading it is worded to prevent stated explicitly, and D-PRLR-4 regraded from "ruled" to "constraint measured, projection not built and not validated". Also recorded, found while verifying: the mint is board-only. D-PRLR-* and D-R2IL-* appear in STATUS_BOARD but not in the plans themselves, and supersession_index.py counts D-ids by scanning .claude/plans/, so the coverage column cannot see them. #1156's root cause is masked at the board layer, not closed. Writing ids into plan bodies is the real close and is out of scope for a board PR that said so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCfrD5y19cvFc4AoyydXYv
2 participants
One
ISSUES.mdentry, pure insertion. Follows #1155.The
rubicon-loco-rung-cognitive-fabric-v1session reportedr2il-machine-semantic-contract-v1as "the ONLY genuinely untracked standalone plan in the tree", from a hand review of candidates. That plan was real and is now tracked (#1155). The "only" is not:53 of 208, including whole families — 19
3DGS-*, 5tesseract-rs-*— and singles likearchetype-scaffold-v1,belief-abi-restoration-v1,lance9-datafusion54-upgrade-probe-v1,probe-r2il-live-regfile-v1. I spot-checked four by D-id as well as by filename; none is tracked by either route, and the D-ish tokens inside them (D-AND-SCAFFOLDED,D-THE-NEW) are prose, not ids.The finding is not the number
A manual sweep reported 1/208 where a one-line grep reports 53/208 — and it under-reported in the direction that feels like completion. Reading candidates cannot cover 208 files, so this census has to be mechanical or it keeps producing confident undercounts. That is the transferable part; the 53 will drift.
Root cause sits upstream of the board
Several of these carry no D-ids at all (
probe-r2il-live-regfile-v1among them), soSTATUS_BOARDhas nothing to hold and the supersession index's coverage column has nothing to count. And the board rule fires when a plan is added — a plan that lands without an id is never caught afterwards by anything.Deliberately not fixed here
Backfilling 53 plans is a scope decision, not a hygiene commit: some are superseded, some are sub-documents of an owner plan (the three
alpha-reason-witness-shader-field-*files declare owners and owe nothing — the loco session was right about those), and several belong to other sessions. Proposed and unbuilt: a CI check mirroring the grep, on theSUPERSESSION-INDEXprecedent that a generated artifact with no staleness gate is a hand-maintained artifact with extra steps.🤖 Generated with Claude Code
https://claude.ai/code/session_01DCfrD5y19cvFc4AoyydXYv
Generated by Claude Code