Implementing the spec: where discipline holds and where it slips

Post 1 and Post 2 covered the Constitution-generation phase and the audit moves that corrected it.<br>Once the spec is stable, the same tool starts writing code, with the spec as the contract.

The implementation phase produced four episodes worth recording.<br>Two are self-correction events on actual code: one I caught by reading the call graph against a contracts file, and one the tool caught against my own working-notes decision to skip the audit.<br>The third, the uv pivot, sits outside the self-correction taxonomy; it is a tool-honesty episode.<br>The fourth is the T009 reverse-engineering document: a sample of what the pipeline produces when its inputs are clean.

Audit Move 4: the cascade-on-delete verification

A contracts file in the design phase asserted that the delete cascade preserved the behaviour of the legacy method __delete_author_with_no_papers.<br>The cited mechanism: that named method.

I pulled the actual code and traced the call graph.<br>The cascade happens in delete_author_of_list: after deleting the rows the user requested, the function issues a second DELETE against authors with no remaining join-table entries.<br>__delete_author_with_no_papers exists in the same module and is reachable from a different code path. But it is not invoked on the path the contract was talking about.<br>The outcome was correct; the cited mechanism was wrong.

I sent the audit.<br>The tool corrected the contract file, named delete_author_of_list as the actual mechanism, and added a trap-warning paragraph for future reviewers stating that the cascade is inline and that the similarly-named method should not be assumed to be on the path.<br>The tool extended the correction beyond what I had asked for.

The reason this failure mode matters: a reviewer who trusts the citation will look at __delete_author_with_no_papers, verify that the body of that method enforces the cascade behaviour correctly, and sign off.<br>The reviewer will have verified a method that is not on the code path under review.<br>The body of delete_author_of_list is never read.

I caught this in a personal codebase because I happened to read the call graph instead of the contract.<br>At ERP scale, that catch requires either machine-traceable contracts or a reviewer-discipline norm.<br>Obvious wrongness gets caught quickly, but documentation that is correct in outcome and wrong in cited mechanism passes inspection on a quick read.<br>The trap-warning is one of the few mechanisms that gives a reviewer a chance against this class of finding.

Audit Move 6: the ConfigReader cross-artefact fix

While applying a Constitution amendment, the tool noticed that the original Stack & Constraints section of the Constitution referenced ConfigReader.<br>That class was scheduled to be deleted two phases later in task T026.

The tool extended the amendment to update the Stack & Constraints wording so the deleted class would no longer be referenced.<br>Then, it explained the extension verbatim:

“The Configuration line is updated in lockstep because ConfigReader is deleted in T026; leaving the original wording would make the constitution reference a class that no longer exists.”

The reasoning shape itself is striking.<br>The Constitution and the task list are separate documents.<br>T026 had not run yet.<br>The tool inferred: “if I apply this amendment now, and T026 runs later as scheduled, the Constitution will be internally inconsistent at that future point.”<br>That is multi-step reasoning across the artefact set.

What also stands out is my working notes.<br>They contain an explicit decision to skip this audit.<br>I had flagged the ConfigReader reference as a likely future inconsistency.<br>But I decided not to spend quota on it during the amendment; I would catch it later when T026 ran.<br>Yet, the tool caught it during the apply step before I had reviewed the amendment output.

If I had not been keeping notes, I would not have noticed that the tool did anything I would have skipped.<br>The fix would have been invisibly absorbed into the amendment diff.

The fifth self-correction mode: cross-artefact consistency on apply

Post 2 closed with a four-mode taxonomy and forward-referenced two more.<br>The ConfigReader episode is the example of the fifth mode.

Mode<br>Trigger

User-direct<br>I point at a specific artefact and say it is wrong

Audit-class amplification<br>I point at one instance, the tool generalises across the class

Autonomous-constitution<br>The tool re-runs the Constitution check at a phase boundary and finds its own violation

Intra-artefact<br>The tool corrects itself mid-sentence within a single artefact during generation

Cross-artefact consistency on apply<br>The tool checks that an amendment does not leave the artefact set internally inconsistent against scheduled future tasks

The first four modes operate locally: within one artefact at a time, whether triggered by user audit, phase-boundary check, or mid-generation revision.<br>Mode 5 crosses both artefact...