Define closure criteria for architecture-sensitive reviews

[taras]

Goal

Improve the architecture and implementation review process so foundational PRs converge without weakening real authority, durability, replay, or lifecycle guarantees.

Problem

The review sequence around #432 and #433 found real defects, but it also exposed a process failure: the threat model, blocker criteria, and final acceptance boundary were still evolving while implementation was underway.

That produced a counterexample-driven loop:

1. one concrete bypass was reported;
2. the implementation closed it;
3. the next review introduced an adjacent invariant or adversarial capability;
4. tests and durable documentation expanded again; and
5. there was no explicit condition under which the review was complete.

The result was a large number of individually reasonable correction rounds without a stable definition of “done.” This makes delivery hard to predict, mixes architecture discovery with implementation review, and risks treating increasingly remote edge cases as equivalent to authority or durability defects.

Desired process

Identify architecture-sensitive work

Treat a change as architecture-sensitive when it affects any of:

• authority or trusted-host ownership;
• durable identity, admission, or publication;
• replay and retained-history compatibility;
• concurrency, cancellation, resource lifetime, or teardown;
• failure precedence or exact identity;
• loaded-package-copy composition; or
• a public middleware contract.

Before implementation begins, such work receives one settled architecture record covering:

• trusted and untrusted actors;
• adversarial capabilities that are in scope;
• explicit non-goals and process-level attacks that are out of scope;
• authority, identity, persistence, and lifecycle ownership;
• success, refusal, failure, cancellation, and teardown behavior;
• live, partial-replay, and completed-replay behavior;
• loaded-copy behavior where applicable;
• the acceptance matrix and discriminating evidence; and
• the condition under which architecture review passes.

Define when a finding blocks

A new finding blocks the current PR only when all of these are true:

1. It reproduces against the exact reviewed head.
2. It violates a named, already-settled invariant.
3. It uses an in-scope input or supported public surface.
4. It has an observable authority, durability, replay, lifecycle, or public-completion consequence.
5. Its correction belongs within the PR's existing purpose.

Findings that fail one of these conditions become follow-up issues rather than silently extending the current architecture contract.

Classify every finding as one of:

• architecture blocker — changes what executes, what history or identity is accepted, what durable state is published, or what authoritative outcome wins;
• correctness blocker — violates an explicit public contract on a supported path; or
• hardening follow-up — extends the threat model, requires arbitrary process sabotage, affects only non-authoritative diagnostics, or is outside the PR's purpose.

Freeze decisions and close review

• Once an architecture ruling is accepted, later reviews check the implementation against it rather than introducing adjacent invariants implicitly.
• A new material invariant requires an explicit architecture amendment with its scope and consequence stated. Unless it exposes a high-severity violation in the current boundary, deliver it separately.
• After two correction rounds, the Architect supplies one consolidated ruling: final invariants, adversary, required evidence, non-goals, and the exact pass condition.
• The Implementor reports against that checklist at one exact head.
• The final reviewer either identifies a checklist violation with a reproducer or passes the PR. Documentation cleanup and speculative hardening do not restart architecture review.

Keep prerequisite PRs reviewable

Prefer one authority or lifecycle boundary per prerequisite PR when main can remain coherent. Do not combine independent invariants merely because they were discovered during the same review loop.

Deliverables

• Update AGENTS.md with the blocker rubric, finding classifications, and review-closure rule.
• Update .agents/architect.md to require the threat model, acceptance matrix, explicit non-goals, and consolidated ruling after repeated correction rounds.
• Update .agents/planner.md so implementor handoffs carry the frozen architecture checklist and route newly discovered architecture decisions back instead of embedding them in implementation prompts.
• Update .agents/implementor.md so correction reports map changes and tests to the frozen checklist and clearly identify any requested scope expansion.
• Add or update a reusable architecture-sensitive review/handoff template. Keep ordinary PRs lightweight.
• Reconcile .github/pull_request_template.md only if a small conditional section helps identify architecture-sensitive work without burdening routine changes.

Acceptance criteria

• The documented process distinguishes architecture blockers, correctness blockers, and follow-up hardening.
• Every architecture-sensitive handoff has an explicit in-scope/out-of-scope threat model and a finite acceptance matrix before implementation.
• Review findings must name the settled invariant they violate and include an exact-head reproducer.
• The process specifies when a new finding becomes a separate issue instead of extending the active PR.
• Two correction rounds trigger a consolidated final ruling and pass condition.
• A worked retrospective against the 🔒 Make canonical core authoritative for execution #432/🔒 Make canonical core authoritative for document expansion #433 sequence demonstrates where the new process would have consolidated decisions earlier and which findings would still have blocked.
• The process does not cap necessary investigation or weaken authority, durability, replay, or lifecycle guarantees; it makes their boundaries explicit and reviewable.

Non-goals

• Declaring unusual inputs irrelevant merely because they are unusual.
• Allowing green CI to substitute for architecture evidence.
• Preventing a demonstrated high-severity defect from blocking late in review.
• Turning every ordinary PR into a formal threat-modeling exercise.