Skip to content
Cockpit0.29.0
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
2 of 2
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I1510

majordomus plan verify I1510

majordomus plan done I1510

What 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.