I3313 — A failing verification in a closed session record says whether the ledger already held it failing at the task's base
When finish or close records a failing verification, look the failing subject up in the evidence ledger at the task's base commit and mark it pre-existing (failing there), introduced (passing there) or unknown (not recorded there); the resume context lists pre-existing failures so the next worker does not diagnose them again.
BLOCKED wave 4 · p3 · implementation profile · parallel safe
Blocked. This issue cannot start until I3146 is done. The status is derived from that, not declared.
Objective
When finish or close records a failing verification, look the failing subject up in the evidence ledger at the task's base commit and mark it pre-existing (failing there), introduced (passing there) or unknown (not recorded there); the resume context lists pre-existing failures so the next worker does not diagnose them again.
Why
The 2026-09-08 consolidation of session records asked that a record tell the next worker which failures it inherited, so that a failure already red at the base is not diagnosed again as the session's own. The ledger is indexed by subject and records the commit each execution ran at (.ai/repo/evidence/ledger.json; proposed in ADR 0087, which carries no authority until accepted), so the comparison is a read, not a second run. It is the delta on I3146's completeness verdict: that issue says whether a record is complete, this one says where each of its failures came from. Sources: chatgpt-majordomus:c074#3.
Current state
At 707a04c no part of finish, check, session or handover distinguishes a failure that was already there from one the session introduced. The tracked ledger held 14 executions over 6 commits on 2026-10-18 (jq '.executions | length' .ai/repo/evidence/ledger.json), so most bases will answer unknown until CI records more; the issue must show unknown honestly rather than wait for coverage.
Desired state
Each failing verification in a record carries one of pre-existing, introduced or unknown, derived from the ledger, and unknown is never shown as pre-existing.
Scope
- apps/majordomus-cli/src/session
- apps/majordomus-cli/src/evidence
- lib/finish.sh
- docs/CONTINUITY.md
Out of scope
- Running the verification again at the base
- The completeness verdict itself, which I3146 owns
Dependencies
Acceptance criteria
- A fixture whose ledger records a case failing at the base yields pre-existing for that case
- A case passing at the base and failing now yields introduced
- A case the ledger has no row for at the base yields unknown
- The next session's brief lists the pre-existing failures of the record it resumes
Validation
- bash test/run.sh 63_session_records
Evidence required
- case_failure_origin_is_derived
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I3313.yaml. Read it back with majordomus plan show I3313.