Chapter 5.3 follows chapter 5.2, Construction of a maintenance task, and precedes chapter 5.4, Anatomy of one task package, within part 5, the task library.
The retirement date is 2026-08-21. source: 5. Experiment/0. Plan/Appendix A, Chronology of Design Amendments.md line 78 source: 4. Task Library/Project H/_archive/removal-based-suite-2026-08-22/ARCHIVE_NOTE.md line 1
5.3.1 Structural mismatch of the maintenance-task suite
A removal-based task starts with a reference implementation and subtracts a feature. Its patch is anchored to files in that reference. The documented reference and its stripped twin share those paths, while the independently built control uses a different layout and architecture. A patch written for the reference therefore cannot describe the corresponding work in the control.
The campaign tested the packaged removal patches against the control. The patches did not apply because their file anchors and surrounding code were absent. The registered comparison consequently lacked a valid observation for the control. The design measured a relation across builds that its patch format could not represent.
5.3.2 Additive replacement of the maintenance-task suite
The additive design gives every arm the same ticket in customer language. The ticket states the desired behaviour and its acceptance criteria. Each arm starts from its own frozen tree, with no planted patch and no removed feature. The agent adds the requested behaviour to that tree as it stands.
Because the ticket describes behaviour rather than a change against a particular tree, it can be used with every arm’s own frozen tree. The suite retains independent tasks and chained sequences. A chained sequence carries the tree produced by its preceding step and stops when a step fails. This records where an implementation loses the structure needed by later work.
The feature-realization pipeline records the path mismatch that led to the additive replacement.
5.3.3 Rules for hidden checks
The hidden checks are checks that the agent does not see. Under the additive design, the ticket and the visible verification file state the complete definition of done. A hidden check may retest a stated criterion with inputs the agent has not seen. It may not add a requirement or enforce a naming or placement choice absent from the ticket.
Each check set is validated from the ticket, audited against its wording, run against the untouched trees, and tested with a hand-built witness implementation. The check must fail on the untouched trees and pass on the witness. This process tests whether the requested behaviour is absent before implementation and whether the check can be satisfied by legitimate work.
The seam probe records the point where an early shortcut becomes observable in a later step. source: 5. Experiment/0. Plan/Appendix A, Chronology of Design Amendments.md line 78
5.3.4 Distance requirement of the maintenance-task suite
A seeded defect, a planted bug with its cause and symptom placed in distant modules, tests whether documentation helps an agent find the fix. The cause belongs in one module and the symptom belongs in another. No textual link between them appears outside documentation artifacts. The symptom does not expose the cause module’s path, function names, or distinctive vocabulary. The connection is recorded in a relationship map, traceability entry, or code-adjacent note.
The defect is written as a plausible maintenance problem from the symptom side. Its classes include invariant violation, propagation omission, ordering, staleness, and budget. In the documented build, the connection is visible through documentation. In the stripped and control builds, the agent must discover it by reading across the modules.
5.3.5 Design cause of the maintenance-task suite
The retired design treated a removal patch as the intervention. That patch encoded the reference tree’s file paths and local structure. The control tree did not share those anchors, so the intervention could not reach the same requested behaviour there.
5.3.6 Patch mechanism of the maintenance-task suite
The mismatch appeared before an agent could perform the task. Applying the patch required files and surrounding code that existed only in the reference family. The control therefore received no comparable intervention, and its result could not support the registered comparison.
5.3.7 Control observation of the maintenance-task suite
The archive preserves the task definitions and realization records. It also preserves the analysis of this failure. The record shows that the removal suite produced information about the measuring instrument while failing to produce the intended cross-build observation. The hidden checks also rejected correct work for choices that the ticket had not required.
5.3.8 Retirement ruling of the maintenance-task suite
The campaign abandoned the removal-based design on the recorded retirement date. The additive replacement removes the tree-specific patch, gives every arm a behavioural ticket, and limits hidden checks to criteria stated in that ticket. The archived suite remains a record of the retired design and its failure.