Require explicit protocol tests and reviewer documents in implementation plans

doc/project/README.md

@@ -46,7 +46,7 @@ history/       How did the current state come to be?
 7. **Asking "why does INET not do X?"** — [design/rejected-designs.md](design/rejected-designs.md).
 8. **About to derive protocol tests from a standard** — [guide/derive-tests-from-a-standard.md](guide/derive-tests-from-a-standard.md).
 9. **Writing in this folder** — [rule/documentation.md](rule/documentation.md).
-10. **About to write or review an implementation plan** — [guide/write-an-implementation-plan.md](guide/write-an-implementation-plan.md) and its [plan rules](rule/planning.md). Both documents are drafts.
+10. **About to write or review an implementation plan** — [guide/write-an-implementation-plan.md](guide/write-an-implementation-plan.md) and its [plan rules](rule/planning.md). Both documents are drafts. Current requirements for [future commits](rule/pull-request.md#pr-series-plan) and [protocol tests with reviewer documents](rule/testing.md#tr-plan-protocol) apply independently of draft approval.
 
 ## Every document
 

doc/project/audit/seal-list.md

@@ -64,11 +64,11 @@ A whole-document seal is declared in the document's own header, as `**Seal:** wh
 | `rule/documentation.md` | whole | 0 | 0 | 1 |
 | `rule/naming.md` | by rule | 0 | 0 | 23 |
 | `rule/planning.md` | by rule | 0 | 0 | 8 |
-| `rule/pull-request.md` | by rule | 0 | 0 | 26 |
+| `rule/pull-request.md` | by rule | 0 | 0 | 27 |
 | `rule/quality.md` | by rule | 0 | 0 | 15 |
 | `rule/release.md` | by rule | 0 | 0 | 11 |
 | `rule/sealing.md` | whole | 0 | 0 | 1 |
-| `rule/testing.md` | by rule | 0 | 0 | 14 |
+| `rule/testing.md` | by rule | 0 | 0 | 15 |
 <!-- END SEAL INDEX -->
 
 Nothing is closed yet, and that is the honest state: no document in this set has been audited against [documentation.md](../rule/documentation.md). The requirements are the one document that carries flags on every unit, because it declares `by requirement, complete` — its 30 requirements are all ⬜, which reads as *considered, and deliberately still open*.

doc/project/enforcement/README.md

@@ -26,6 +26,8 @@ The draft [plan procedure](../guide/write-an-implementation-plan.md) includes a
 
 This is a manual review procedure. No automated gate checks plan approval. A successful document check establishes neither design quality nor human approval.
 
+Current [series requirements](../rule/pull-request.md#pr-series-plan) and [protocol test requirements](../rule/testing.md#tr-plan-protocol) apply to plan content independently of draft approval. T4 review checks future commit entries, explicit test tasks, and reviewer documents with the necessary diagrams. No automated gate verifies these explanations or their technical correctness.
+
 ## The gate inventory
 
 One row per check that exists. The table lists **machinery, not intent**, so it cannot drift from the rules: a row disappears when its check is deleted, and coverage is read from the side that can be measured.

doc/project/enforcement/checklist/general.md

@@ -6,6 +6,8 @@ The tier-4 gate from [enforcement/README.md](../README.md). It enforces the **se
 
 For a proposed implementation plan, use the draft [plan review checklist](../../guide/write-an-implementation-plan.md#review-checklist). Its [plan rules](../../rule/planning.md) state when that procedure applies.
 
+Check current [commit series requirements](../../rule/pull-request.md#pr-series-plan) and [protocol test requirements](../../rule/testing.md#tr-plan-protocol) independently of draft approval. Flag absent commit entries or missing protocol test and reviewer document tasks for applicable commits. For implementation, check that the assigned commits contain the required artifacts and explanations. Check necessary diagrams against the scenarios and assertions.
+
 ## How to run
 
 Input: the change under review (a diff, commit, range, branch, pull request, staged diff, or working tree). For **each** checklist item that can be evaluated, output one of:

doc/project/guide/contribute-a-change.md

@@ -22,6 +22,8 @@ Apply [QR-DESIGN-MINIMAL](../rule/quality.md#qr-design-minimal) to design and co
 
 For a task that calls for a plan, use [write-an-implementation-plan.md](write-an-implementation-plan.md) before implementation. The plan rules remain a draft. Their [approval rule](../rule/planning.md#plr-approval) applies when the maintainer accepts the policy or explicitly selects it for the task. The guide covers preparation, review, and approval in that order.
 
+Apply the current [series requirement](../rule/pull-request.md#pr-series-plan) to every future commit in that plan. Apply [TR-PLAN-PROTOCOL](../rule/testing.md#tr-plan-protocol) to explicit protocol test tasks and reviewer documents for applicable commits. These content requirements do not activate the draft approval process.
+
 Establish who owns which state before you edit. Then make the smallest change that satisfies the contracts, the ownership, the observability, the configuration, the determinism and the test rules.
 
 ## 5. The mechanisms that already exist

doc/project/guide/review-a-pull-request.md

@@ -70,7 +70,7 @@ It checks the mechanical half of [rule/classification.md](../rule/classification
 **A trailer is a claim, and the gate checks only the half that is derivable.** Three things stay for you to judge:
 
 - **Is the depth honest?** A commit that says `refactor` and rewrites a loop condition is a behavior change wearing the wrong word. Read the diff of every `refactor`, `name` and `comment` commit — there are few, and the gate has already listed them.
-- **Is the obligation discharged, and where?** The two obligations have **different units**, and reading them the same way produces a false finding. [TR-SHIP-WITH](../rule/testing.md#tr-ship-with) asks for the test in the same *pull request*, so a batch of tests at the end of a series satisfies the letter of it. [PR-SPLIT-BASELINE](../rule/pull-request.md#pr-split-baseline) asks for the baseline in the same *commit*, so a batch at the end is a violation. A long gap between behavior and test is still worth a **note**: the rule's own reason is that a test written later is written against the code as it turned out.
+- **Is the obligation discharged, and where?** Check the unit required by each applicable rule. [TR-SHIP-WITH](../rule/testing.md#tr-ship-with) requires new behavior and its test in the same pull request. For planned protocol repairs and features, apply the stricter [TR-PLAN-PROTOCOL](../rule/testing.md#tr-plan-protocol). It requires tests and a reviewer document with the behavior commit, except for permitted earlier test commits. Tests deferred to a later commit do not satisfy that rule. [PR-SPLIT-BASELINE](../rule/pull-request.md#pr-split-baseline) requires a baseline update in the commit that causes it.
 - **Is a `?` still a `?`** A commit that says `?` for its baselines is honest and unfinished. It is a `PARTIAL`, not a `PASS`, and the report says what run would settle it.
 
 **Do not report a missing trailer on a commit that predates the rule.** The gate gives a note, not a violation, for a missing `Change:` line on a commit authored before 2026-09-11, the day `classification.md` entered the tree. A rebase keeps the author date, so an old commit on a new branch still gets the note.