A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live
I1510
A gap the audit calls planned names a plan object that exists
Where it stands
devtask.issue- Readiness
- complete completion is recorded and every required evidence token is present
- Status
- DONE
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
0- Waiting on
- none
- Holds back
- none
- Behind it in all
0- Evidence
2of2
Moves
plan.transitionWhat it is
- Objective
- Check docs/COCKPIT_IDE_AUDIT.md's gap matrix against the plan, so that a row whose status is `planned` must name an issue that exists, and a row cannot quietly claim to be scheduled when nothing schedules it.
- Why
- The audit's matrix uses a fixed status vocabulary in which `planned` requires a plan object, and its own search for the IDE keywords across the issues and the milestones returned nothing — so no row was planned and the work was not in the plan at all. That negative was true when it was written and it stayed true, unnoticed, for a day, because nothing reads the document. Re-run on today's master before this milestone was written, the same search still returned nothing for palette, diff view, CI status or syntax highlighting. A document that states a status vocabulary and has no reader is a document whose statuses drift the moment anyone edits it, which is the one-sided-check class this repository has now paid for several times: a relation asserted in one direction with the converse owned by nobody.
- Now
- The matrix is prose. Its `planned` rows, of which there were none, reference nothing. Nothing notices when a row's status stops matching the repository, and nothing notices when a plan object that a row depends on is completed or cancelled.
- Wanted
- A check reads the matrix and the plan together. A row marked `planned` names an issue id that exists; a row that names an issue that does not exist is a failure with both named. Nothing is asserted about rows in the other statuses, which are evidence claims and not plan claims.
- Done when
- unknown: the record declares no `completion`
- Risk
- Low. The trap worth naming is a check that parses prose too eagerly and starts failing on an editorial change to a sentence; it must key on the status vocabulary and the issue id, and ignore everything else in the row.
Acceptance
- A row whose status is planned and which names no existing issue is a reported failure, with the row and the missing id named
- A row naming an issue that exists passes
- The check runs in the repository's own suite as test case 194
- Validation
bash test/run.sh 194_audit_rows_are_plannedbin/majordomus doctor- Evidence required
unplanned_row_is_refusedcheck_is_in_the_suite- Evidence present
unplanned_row_is_refusedcheck_is_in_the_suite
Scope
- Touches
test/casesscriptsdocs/COCKPIT_IDE_AUDIT.md- Not
Checking the other statuses. Whether a row is genuinely canonical+implemented+verified is an evidence question that its named test answers, not something a text check can decide.Generating the matrix. It is a human argument about a moment, and a generated table would lose the reasoning that makes it worth reading.- Depends on
- none
- Priority
- p1
- Profile
- implementation
- Parallel safe
- true
- Owner
- unknown: the record declares no `owner`
The work so far
- Branches
- none
- Merged
- none
- Commits
0- Trunk
- master
- Sessions
- none
- Created
- 2026-09-11
- Updated
- 2026-10-14T17:42:45Z
- Started
- 2026-10-14T17:42:28Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-10-14T17:42:45Z
Synchronisation
- Adapter
scripts/github-sync- Repository
- unknown: the derived plan's header carries no repository
- External issue
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
- State there
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
Findings
Nothing is wrong with these records.