T42: Second-repository validation

[thedancingdeveloper]

Run the harness against a repository other than oxidex, using only the repo's own required checks plus whatever domain gates it declares.

This is the test of whether P4 actually generalised anything.

Acceptance: a full attempt completes end to end with no oxidex-specific code on the path — verified by grep, not by assertion.

[thedancingdeveloper]

Reframed by the generic ruling. 'Runs against a second repository with no project-specific code on the path' is no longer a validation to schedule — the core has no project-specific code on the path by construction, and AGENTS.md makes that a binding rule with the adapter boundary to enforce it.

What is still worth doing, and is not the same thing: run it against two genuinely different workloads and see what the abstraction gets wrong. The first real use will expose assumptions; the second is what proves they were assumptions rather than requirements. Keep this open as that check, not as a port.

[thedancingdeveloper]

Status update, 2026-08-04. Still blocked, and it needs the one thing this repository cannot supply itself: another repository. The generic-core property it tests is now enforced by tests rather than by grep — tests/test_generic.py asserts that no module on the execution path imports or names an adapter, which caught a real violation during the Stage F merge (Stage G had written a dotted adapter path into graph.py). That is a stronger precondition than existed when this was filed; it is not a substitute for the run.

What is now in place that was not. The fit-for-purpose programme landed stages F, D, K, H, L, J and M on fix/validator-rejects-valid-patches (1063 tests, ruff, format and full-project strict mypy all clean). Several of them exist precisely to make a long run survivable:

• Per-item wall-clock and spend ceilings (Stage L). Previously an item that heartbeated forever was indistinguishable from one making progress — the failure mode a long unattended run is most likely to produce. Ceilings default to unlimited, so they must be set explicitly before a run of this kind; doctor warns when they are not.
• Resumable attempts (Stage H). A killed worker resumes at its last durable stage instead of re-paying for the planner and implementer. On the measured fixture that is 3 model calls against 5 for one induced crash.
• A typed outcome taxonomy (Stage K). A reviewer rejection, a crashed worker, a budget stop and a gate that could not run are now four distinguishable states rather than all failed, which is the difference between a readable post-run report and a pile of failures.
• A durable human hold (Stage J) and doctor (Stage D), so a run can be pre-flighted and a question does not silently consume a worker.

What still blocks this. Unchanged: credentials, network access, a real second repository, and the NGMS human decisions that §9 of docs/PROPOSAL-2026-08-fit-for-purpose.md explicitly refuses to answer by assertion. None of it is startable from the repository alone.

Two caveats that matter for this specific run. Stages H and L are the direct-API executor only — a session-mode fleet has no resumable attempts and no per-item budgets. And nothing in the programme is evidence about live behaviour: no provider was contacted at any point, in any stage.

Full context: docs/evidence/2026-08-04-programme-report.md.