@tiphys/kernel 0.0.0 → 0.2.0

package/roles/investigator.md

@@ -0,0 +1,138 @@
+---
+role: investigator
+lifetime: One mystery
+sees:
+  - The codebase
+  - The symptom, in the words it was reported in
+never:
+  - Fixes anything
+  - Rewrites the plan
+  - Declares a cause it did not reproduce without saying so
+mandated-reading:
+  - roles/_shared-dispatch-contract.md
+  - schemas/report.schema.json
+verifiers:
+  - citations
+outputs:
+  - report
+model-tier: strongest
+clauses:
+  - R-004
+  - R-015a
+  - R-092
+  - R-010a
+  - incremental-output
+  - beacon-is-not-a-claim
+---
+
+# Investigator
+
+You have been given ONE mystery. You see the codebase and the symptom as it was
+reported. You produce a root-cause verdict with evidence, and you change
+nothing.
+
+The reason this role exists as a separate dispatch, rather than as the first
+half of the implementer's work, is that an agent which is about to fix
+something reasons toward a fix. A verdict reached that way is fitted to the
+remedy the agent already had in mind, and the measured cost of a wrong verdict
+is a whole fix round aimed at the wrong mechanism.
+
+Your output is a `report`, and the contract it must satisfy is written down in
+`schemas/report.schema.json`, which is on your mandated reading. Read it BEFORE
+you write, not after: it is the only place the shape of your own deliverable
+exists, and the clauses below tell you what to think and not what fields to
+fill. Two things in it are easy to meet late and expensive to meet late. It
+requires `claims`, `deviations`, `honest-failures`, `environmental-claims` and
+`gate-results` alongside your findings, which are records you can only make
+while the work is happening. And it carries one conditional aimed at this role
+by name: a report whose `role` is investigator AND which states a `verdict`
+must also carry a `repro`. The moment you conclude, R-015a below is owed as a
+field and not as good practice.
+
+The finding set at `schemas/finding.schema.json` is NOT your contract, and it
+is not on your reading list for that reason. It governs what an adversarial
+plan review and a clean-room review produce. Your report carries a `findings`
+array of its own, defined inside your own schema, and the two are different
+shapes.
+
+## clause R-004: a root-cause verdict with evidence, and nothing fixed
+
+Your output is a VERDICT: what the cause is, what it is not, and what each of
+those rests on. It is not a patch, not a branch, and not a suggestion that the
+next agent try something.
+
+Fixing nothing is not modesty. It is what keeps the verdict falsifiable: an
+investigation that also edited the code cannot say whether the symptom went
+away because the cause was found or because something else moved. If you
+believe you know the fix, write it down as a recommendation inside the report
+and leave the tree unchanged.
+
+A verdict states its own confidence in terms someone can check. "The importer
+retries a 429 twice and then propagates" is a verdict. "The retry logic looks
+wrong" is not; it names no mechanism, so nothing can be built on it and nothing
+can refute it.
+
+Name the MECHANISM, not the instance. "A FIFO at the beacon path hangs the
+guard" is an instance. "Reading a path whose type has not been established" is
+the mechanism, and it is the one that tells the next agent where else to look.
+A verdict that names only the instance sends the fix round at one call site
+when there were eleven.
+
+## clause R-015a: a runnable repro that is red on current code
+
+Produce a RUNNABLE REPRO that is red against the current code. Not a
+description of how to reproduce it, and not a passing test that documents the
+present behaviour: a command someone else can run, which fails now, and which
+would pass if the cause you named were removed.
+
+An explanation without a repro is a hypothesis. It may be a good one, and this
+process still does not accept it as a verdict, because the whole value of the
+investigator's output is that the fix round can be measured against something.
+A repro is what turns "we think it is X" into "here is the arm that is red".
+
+The repro must be red against the DANGEROUS STATE and not merely against an
+absent feature. A repro that exercises a path where the failure cannot occur is
+green, looks like evidence, and is worthless. Say which state you drove the
+system into and how you know it got there.
+
+State what the repro does NOT cover. A repro whose scope is wrong returns a
+clean result that is indistinguishable from an absence of the defect, and this
+process has been bitten by that shape three times: a lock path probed that was
+not the lock path in use; an inventory scoped to three directories while the
+missed path sat at the root; a usage error read as a clean run.
+
+## clause R-092: reproduce before fixing, and if it will not reproduce, ship the harness and say so
+
+Reproduce first. Do not reason your way to a cause and then look for the
+evidence that agrees with it.
+
+If it will NOT reproduce, that is a real and reportable outcome, and the way to
+report it is to SHIP THE HARNESS and say so plainly. Hand over the scaffolding
+you built, the exact commands, the states you drove the system into, and the
+arms that stayed green. Then write the honest sentence: "I did not find a way
+to force this arm." Do not write "this arm cannot be forced", which is a
+different and much stronger claim, and one that stops the next reader from
+trying.
+
+The harness is the deliverable in that case. An investigation that failed to
+reproduce and left nothing behind has spent the whole budget and returned
+nothing; the same investigation that leaves a harness has bought the next agent
+everything except the answer.
+
+## clause R-010a: every claim carries file:line evidence
+
+Every claim in your report carries evidence a reader can resolve: a path with a
+line number, a captured command with its exit code, a count, a URL. The
+citation linter is the verifier attached to this role and it runs over what you
+write, so an unresolvable citation is a red gate rather than a matter of taste.
+
+The form that resolves is `path.ext:LINE`, in prose and outside backticks. A
+bare path is not a citation, and a path inside backticks is deliberately
+QUOTED: use that when you are naming a file you are not asserting exists at
+that line, and know that it counts for nothing toward the evidence floor.
+
+Evidence beats assertion everywhere. A claim with no verifiable artifact behind
+it is treated as unknown, which is not the same as treated as false, and the
+distinction is the reason to write down what you actually ran.
+
+$include: _shared-dispatch-contract.md

package/roles/plan-writer.md

@@ -0,0 +1,95 @@
+---
+role: plan-writer
+lifetime: One plan
+sees:
+  - The input report
+  - The code
+mandated-reading:
+  - roles/_shared-dispatch-contract.md
+  - schemas/plan.schema.json
+  - templates/plan.example.yaml
+  - gate-registry.yaml
+never:
+  - Decides product questions
+  - Writes feature code
+  - Plans a phase on an unverified claim without marking it verification-first
+verifiers:
+  - citations
+outputs:
+  - plan
+model-tier: strongest
+clauses:
+  - R-005
+  - R-010a
+  - incremental-output
+  - beacon-is-not-a-claim
+---
+
+# Plan writer
+
+You have been given ONE plan to write. You see the input report and the code.
+Your output is a plan instance that validates against
+`schemas/plan.schema.json`, and the binding rule of that document applies to
+everything downstream of you: if it is not written in the plan, it is not being
+made.
+
+That rule is what keeps ten agents from improvising, and it puts the whole
+weight on you: an omission in the plan is not a gap someone fills in later, it
+is work that does not happen. Write the phase you would want to be handed.
+
+Every acceptance criterion is FALSIFIABLE. "Works correctly" is banned. The
+register is "node --test exits 0 and reports N tests, N greater than zero", or
+"this command exits 64 and prints this line to stderr". A criterion nobody can
+fail is a criterion nobody has to meet.
+
+## clause R-005: never decide a product question, flag it
+
+You do not decide product questions. When the input report leaves a choice that
+is genuinely a choice, you FLAG it as a decision record and plan around the
+flag rather than picking an answer and burying it in a step.
+
+The test for whether something is a decision record is not "is it important".
+It is: are two or more options genuinely comparable, AND is the consequence
+high impact and costly to reverse. If your own analysis yields a recommendation
+you would defend, the options are NOT comparable and there is nothing to ask.
+Decide it, record the reasoning, and say what you decided. Write your
+recommendation first; doing that is what reveals whether a question was ever a
+question.
+
+Raising a question whose answer was already obvious is a failure of the system
+and not a display of care, because it spends the owner's attention, which is
+the scarcest thing in the process. Raising an irreversible choice you quietly
+made is the worse failure, and it is the one this clause exists against.
+
+A flagged question does not stall the plan. The phase is planned around the
+fill-in: the acceptance criteria, the tests and the gates are fixed regardless
+of which way the question resolves, and the slot that depends on the answer is
+declared as a slot.
+
+## clause R-010a: verify every input claim against the code before planning a phase
+
+Before a single phase is planned, every claim in the input report gets a
+CODE-LEVEL VERIFICATION PASS, each claim checked against actual file:line
+evidence. The output is the section where the report and the code disagree,
+and it is the most load-bearing part of the plan.
+
+This is not a formality. In one measured run, five of eleven report assessments
+did not survive contact with the code: features declared missing that had
+shipped, display bugs that were schema-level projects, one-line bugs hiding
+under grand theories. A plan built on the unverified report would have spent
+five phases on work that did not exist.
+
+A claim that FAILS verification does not get dropped and does not get believed.
+It becomes a VERIFICATION-FIRST STEP: the owning phase's step 1 is "confirm
+which of these failures this actually is, write it down, and only then build".
+The plan schema carries that as a step kind, and a derived check requires the
+step to exist in the phase the unverified claim names, so an unverified claim
+with no verification-first step makes the plan invalid rather than making it
+optimistic.
+
+Citations resolve or they are not citations. The form is `path.ext:LINE`, in
+prose and outside backticks; a bare path is not a citation and a path inside
+backticks is quoted rather than asserted. The citation linter is the verifier
+attached to this role.
+
+$include: _shared-dispatch-contract.md

package/schemas/README.md

@@ -0,0 +1,82 @@
+# Tiphys artifact schemas
+
+Every kernel artifact type that is validated has one JSON Schema document
+here. `tiphys validate --type <t> <file>` resolves a type to a document in
+this directory; `--type auto` resolves it from the instance's `kind` field.
+
+## The dialect, and why it is declared in every file
+
+Every document declares
+
+```
+"$schema": "https://json-schema.org/draft/2020-12/schema"
+```
+
+DR-0013 clause 3. It is asserted by a registered test over EVERY file in this
+directory (`test/schemas.test.ts`, behavior `schemas-declare-2020-12-dialect`)
+rather than by inspection, so a schema a later phase adds without the
+declaration fails a gate rather than a reading.
+
+## The engine
+
+Ajv 8.20.0 exact, Draft 2020-12, instantiated in `src/validate.ts` with strict
+mode, all errors, schema and meta-schema validation, and no coercion, no
+inserted defaults, no removal of additional properties, no mutation of the
+validated input and no automatic loading of remote schemas (DR-0013 clause 4).
+Unknown or invalidly combined keywords fail schema COMPILATION.
+
+Ajv is an INTERNAL IMPLEMENTATION DETAIL. Its wording is never a public
+contract: every error is mapped, by keyword, into
+`INVALID <json-pointer> <message>` with a deterministic order.
+
+## The declared authoring vocabulary (DR-0013 clause 7)
+
+Ajv supplies Draft 2020-12 entire. This list is what a Tiphys schema is
+allowed to USE, so a keyword outside it is a deliberate, documented expansion
+rather than an accident. Every keyword here has both a positive and a negative
+test (`test/schemas.test.ts`).
+
+| Keyword | Note |
+|---|---|
+| `type` | one type name per node |
+| `required` | strict mode requires every named property to be declared in `properties` at the same level |
+| `properties` | |
+| `additionalProperties` | boolean only, and set to `false` at EVERY object level |
+| `enum` | |
+| `const` | |
+| `items` | |
+| `minItems` | |
+| `uniqueItems` | boolean only; used by five shipped schemas here and MISSING FROM THIS TABLE from the day M3-P1 wrote both halves until the DR-0047 sweep, because nothing asserted the two agreed |
+| `minLength` | |
+| `pattern` | |
+| `$ref` | local references only; a remote reference fails compilation |
+| `oneOf` | |
+| `if` / `then` | |
+| `contains` | in the vocabulary and used by no document shipped in M3-P1; its positive, negative and discriminating tests run against a fixture schema in `test/fixtures/` |
+
+Annotations that carry no constraint and are permitted anywhere: `$schema`,
+`$id`, `$comment`, `title`, `description`, `$defs`.
+
+Expanding this list is a deliberate act and is recorded here, per DR-0013
+clause 7. Prohibiting an otherwise-valid keyword is a POLICY LINTER, never a
+reimplementation of keyword semantics; `src/gates/validate.ts`'s `loadSchema`
+is the one that exists today, and it enforces M2's narrower closed set over
+the M2 gate schemas only.
+
+## Kind A and Kind B
+
+A schema expresses properties of ONE document that a keyword reaches (Kind A).
+Properties that compare array elements to each other, resolve a reference into
+another document, compute arithmetic over sibling fields or touch the
+filesystem are Kind B and live in `src/checks.ts` as named derived checks
+(kernel plan M3 section 2.3, DR-0013 clause 8). They are never encoded as Ajv
+extensions.
+
+## `$comment` carries clause ids
+
+Every requirement row an artifact discharges appears in that artifact as a
+clause id, here as a `$comment` tag or a property name.
+`scripts/check-clause-map.mjs` fails when a row owned by a phase that is in
+force has no entry, when an entry names a row the plan's inventory does not
+contain, when a named artifact does not exist, or when the clause id does not
+occur inside it.

package/schemas/assurance-modes.schema.json

@@ -0,0 +1,264 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/assurance-modes.schema.json",
+  "title": "Tiphys assurance modes",
+  "$comment": "R-024, R-096. Blueprint section 8 fixes three modes and their merge authority; this document is the machine-readable form of that table plus the pipeline the process document actually runs. Kernel plan M3, M3-P3 step 1. WHAT THIS SCHEMA CANNOT SEE, said here rather than left to be discovered: a mode that omits a stage `full` contains while declaring nothing in `skips[]` is a CROSS-OBJECT comparison, and the relative position of two entries in a variable-length array is not a keyword property (M3R-002). Those are Kind B and live in src/checks.ts as `mode-no-undeclared-downgrade` and `mode-stage-order`; the gate-set references and the charter enum are Kind B too, as `mode-gate-sets-resolve` and `charter-mode-enum-matches-modes`. This schema's own share is field presence, item type and the closed vocabularies.",
+  "description": "One document per repository. Which assurance modes exist, which pipeline stages each runs, which gates it selects from gate-registry.yaml, who may merge under it, and which stages it declares itself to skip.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["kind", "version", "modes"],
+  "properties": {
+    "kind": {
+      "description": "The artifact type, so `tiphys validate --type auto` resolves this document without being told.",
+      "type": "string",
+      "const": "assurance-modes"
+    },
+    "note": {
+      "description": "Free prose for this document's own readers.",
+      "type": "string"
+    },
+    "version": {
+      "$comment": "A closed set rather than a minimum, because the authoring vocabulary of schemas/README.md has no `minimum` keyword and a bare `type: integer` would admit 0 and negatives. Same shape as gate-registry.schema.json.",
+      "type": "integer",
+      "enum": [1]
+    },
+    "modes": {
+      "description": "Every mode this repository declares. Append-only in practice: adding one is what makes charter-mode-enum-matches-modes earn its place.",
+      "type": "array",
+      "minItems": 1,
+      "uniqueItems": true,
+      "items": {
+        "$ref": "#/$defs/mode"
+      }
+    }
+  },
+  "$defs": {
+    "stageId": {
+      "$comment": "THE CLOSED STAGE VOCABULARY. The first twelve are `full`'s pipeline, which is the process document's own sequence enumerated (process doc section 9 item 3, R-096), with `fix-round-verification` present because T-003 made it structural rather than discretionary. `orchestrator-diff-review` is the thirteenth and belongs to local-only alone: blueprint section 8 names it in that row (\"implement, orchestrator diff review, local fast-forward\") and a vocabulary without it would force local-only to be described as something it is not. CONSTRAINTS C-2 AND C-3 BIND THIS LIST: no stage is completed, detected or excluded by process liveness, by a signal, or by a detached long-running process. A registered test scans this file and assurance-modes.yaml for the four tokens C-2 and C-3 are written in and requires ZERO hits, which is why those four tokens do not appear here even as a disclaimer (M3-P3 criterion 5). It is a fixed-token presence check and is not stronger than that: a stage whose completion were liveness-detected WITHOUT using any of the four words would pass it, which the plan's hazard map states in the open rather than papering over. CLOSED VOCABULARY AT v0.1.0 (DR-0020): these are the tiphys kernel's OWN stage ids. This enum rejects every other value, so a consuming project cannot name a stage of its own at v0.1.0. Extension is an M4 question, deferred to a real pilot consumer for the same reversibility reason as the mode-id enum.",
+      "type": "string",
+      "enum": [
+        "intake",
+        "verification-pass",
+        "plan",
+        "adversarial-plan-review",
+        "implement",
+        "clean-room-review",
+        "fix-round",
+        "fix-round-verification",
+        "merge-on-green",
+        "orchestrator-diff-review",
+        "deploy-verify",
+        "migration-verify",
+        "final-report"
+      ]
+    },
+    "mode": {
+      "$comment": "FOUR conditional rules, chained through $ref rather than stacked in one object, because JSON Schema allows one `if`/`then` pair per schema object and `allOf` is outside the authoring vocabulary of schemas/README.md. Same construction as gate-registry.schema.json's `gate`. This link is M3-P3 criterion 3(c) and criterion 4c: `full` is the reference pipeline every other mode is measured against, so it must CONTAIN the fix-round verification stage T-003 made structural, and it must carry the stop-rather-than-grind bound rather than leaving it in an orchestrator's discipline (blueprint principle 6 calls prompt-only state temporary).",
+      "$ref": "#/$defs/modeAuthorityRule",
+      "if": {
+        "type": "object",
+        "required": ["id"],
+        "properties": {
+          "id": {
+            "const": "full"
+          }
+        }
+      },
+      "then": {
+        "type": "object",
+        "required": ["pipeline", "escalation-bounds"],
+        "properties": {
+          "pipeline": {
+            "type": "array",
+            "contains": {
+              "const": "fix-round-verification"
+            }
+          },
+          "escalation-bounds": {
+            "$ref": "#/$defs/escalationBounds"
+          }
+        }
+      }
+    },
+    "modeAuthorityRule": {
+      "$comment": "M3-P3 criterion 4b. `delegated-under-conditions` is the regime the owner has actually granted once, in DR-0012, and a grant with no conditions and no record reference is an authority downgrade with nothing behind it: exactly the improvisation blueprint section 8 forbids, applied to who may merge rather than to which stages run. `conditions` is minItems 1 so an EMPTY list is a rejection, not a technicality.",
+      "$ref": "#/$defs/modeReviewContractRule",
+      "if": {
+        "type": "object",
+        "required": ["merge-authority"],
+        "properties": {
+          "merge-authority": {
+            "const": "delegated-under-conditions"
+          }
+        }
+      },
+      "then": {
+        "type": "object",
+        "required": ["conditions", "granted-by"],
+        "properties": {
+          "conditions": {
+            "type": "array",
+            "minItems": 1,
+            "items": {
+              "type": "string",
+              "minLength": 1
+            }
+          },
+          "granted-by": {
+            "$ref": "#/$defs/decisionRecordReference"
+          }
+        }
+      }
+    },
+    "modeReviewContractRule": {
+      "$comment": "M3-P3 criterion 4d (T-007, D-M3-32). A mode that runs clean-room review declares its review CONTRACTS, not a reviewer count. T-007's measurement is why this is a schema rule: two reviewers on different model families walked all fifteen of M1-P5's acceptance criteria, agreed on every mechanical fact, and one returned APPROVE while the other found a high-severity defect that live-locks four commands, because the second was briefed on hazards rather than on criteria. Had both been briefed on the criteria, both would have approved, on any two models. The `uniqueItems` on modeShape's `review-contracts` is what stops two entries both named `criteria` from satisfying this `minItems` and reproducing exactly that failure; the two keywords live at ONE SITE EACH, because a duplicate of either would keep rejecting after the other was defanged and a red witness that stayed red for the wrong reason proves nothing about the keyword it names. DR-0012's requirement of two model FAMILIES is orthogonal and is checked elsewhere.",
+      "$ref": "#/$defs/modeShape",
+      "if": {
+        "type": "object",
+        "required": ["pipeline"],
+        "properties": {
+          "pipeline": {
+            "type": "array",
+            "contains": {
+              "const": "clean-room-review"
+            }
+          }
+        }
+      },
+      "then": {
+        "type": "object",
+        "required": ["review-contracts"],
+        "properties": {
+          "review-contracts": {
+            "type": "array",
+            "minItems": 2,
+            "items": {
+              "type": "string",
+              "minLength": 1
+            }
+          }
+        }
+      }
+    },
+    "modeShape": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "id",
+        "declared-by",
+        "pipeline",
+        "skips",
+        "gate-sets",
+        "merge-authority"
+      ],
+      "properties": {
+        "$comment": {
+          "description": "Clause ids this entry discharges, per schemas/README.md.",
+          "type": "string"
+        },
+        "id": {
+          "$comment": "The three ids of blueprint section 8. Closed here and closed again in gate-registry.schema.json's `modes` item enum and in schemas/charter.schema.json's `delivery-mode` enum, which is three copies of one list; `charter-mode-enum-matches-modes` is what keeps the charter copy honest, and test/gate-registry.test.ts already binds the registry copy. CLOSED VOCABULARY AT v0.1.0 (DR-0020): these three are the tiphys kernel's OWN mode ids. This enum rejects every other value, so a consuming project cannot declare a mode of its own name at v0.1.0. Whether to open it, and to what, is an M4 question to be answered by a real pilot consumer rather than guessed; widening an enum later is backward compatible and closing an open one is not, which is why it ships closed.",
+          "type": "string",
+          "enum": ["full", "direct-pr", "local-only"]
+        },
+        "declared-by": {
+          "description": "Where this mode's definition comes from. Prose with document references, so a reader can check the mode against its source rather than trusting it.",
+          "type": "string",
+          "minLength": 1
+        },
+        "pipeline": {
+          "description": "The stages this mode runs, IN ORDER. Order is load-bearing: R-024 says an adversarial plan review happens before anyone builds, and that is a property of the sequence, not of the set.",
+          "type": "array",
+          "minItems": 1,
+          "uniqueItems": true,
+          "items": {
+            "$ref": "#/$defs/stageId"
+          }
+        },
+        "skips": {
+          "$comment": "Blueprint section 8: \"Downgrades are declared, never improvised.\" This is the declaration. It is REQUIRED and may be empty, so a mode that omits a stage and says nothing is distinguishable from a mode that omits nothing; `mode-no-undeclared-downgrade` is what makes the difference cost something. THE CHECK RUNS IN THREE PARTS AND THE SCHEMA CAN SEE NONE OF THEM: an omitted stage missing from this list is a violation (completeness); an entry in this list that the SAME mode's `pipeline` still runs is a violation (soundness A); and an entry that the REFERENCE mode `full` does not run either is a violation too (soundness B), because this list is defined relative to `full`'s pipeline and not to the mode's own. All three are cross-property comparisons and none is a keyword property, and soundness B is a comparison against a DIFFERENT object in the same document, which is further outside the vocabulary still. Soundness A was added after a review measured that a list constrained in one direction only is not constrained at all: one bogus entry on `full` validated at exit 0 and made `tiphys mode show` state the opposite of the truth about this project's own delivery. Soundness B was added a round later, when a delta verification measured that the round adding A had written THIS SENTENCE claiming both directions were covered while an entry naming a stage nothing runs still validated at exit 0. On `full` A and B together force this list to be EMPTY, which is what lets `tiphys mode show` call `full` the un-downgraded process by name.",
+          "type": "array",
+          "uniqueItems": true,
+          "items": {
+            "$ref": "#/$defs/stageId"
+          }
+        },
+        "gate-sets": {
+          "$comment": "The gate ids from gate-registry.yaml this mode selects. `set` is the blueprint's word for the per-mode gate selection; here it is enumerated by id rather than named indirectly, so `mode-gate-sets-resolve` can check each entry against the registry with --context and a reference that resolves to nothing cannot pass by never being looked up.",
+          "type": "array",
+          "minItems": 1,
+          "uniqueItems": true,
+          "items": {
+            "type": "string",
+            "pattern": "^[a-z0-9][a-z0-9-]*$"
+          }
+        },
+        "merge-authority": {
+          "$comment": "Blueprint section 8's third column, plus the value the owner has actually granted. `owner-approves-orchestrator-merges` is SC-008 and plan v1 D-6's reading of blueprint section 8's local-only row. IT DESCRIBES A REGIME THIS PROJECT HAS LEFT (DR-0015, 2026-08-05): for the Tiphys kernel the owner is not an approval step anywhere in execution, milestone boundaries included, and dual cross-model clean review is the signature. The value is kept representable rather than deleted because a future project may declare any of the three and the kernel is not the place to make another project's governance unrepresentable.",
+          "type": "string",
+          "enum": [
+            "owner",
+            "owner-approves-orchestrator-merges",
+            "delegated-under-conditions"
+          ]
+        },
+        "conditions": {
+          "$comment": "Required, and required to be NON-EMPTY, when merge-authority is delegated-under-conditions. The `minItems` lives in modeAuthorityRule's `then` and NOWHERE ELSE: a second copy here would keep rejecting an empty list after the conditional rule was defanged, which would make the conditional rule's witness green for the wrong reason and hide a rule that had stopped working. Quoted from the decision record rather than summarized.",
+          "type": "array",
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "granted-by": {
+          "$ref": "#/$defs/decisionRecordReference"
+        },
+        "review-contracts": {
+          "$comment": "T-007, D-M3-32. The STARTING QUESTION each clean-room review is given, by id. Two contracts is not two reviewers: `criteria` walks the phase's acceptance criteria and `hazard` is handed the phase's declared hazard classes and works outward from them.",
+          "type": "array",
+          "uniqueItems": true,
+          "items": {
+            "type": "string",
+            "minLength": 1
+          }
+        },
+        "escalation-bounds": {
+          "$ref": "#/$defs/escalationBounds"
+        }
+      }
+    },
+    "decisionRecordReference": {
+      "description": "A decision record id, for example DR-0012. The record itself lives in the project's decisions directory; this is the reference that makes a grant checkable against it.",
+      "type": "string",
+      "pattern": "^DR-[0-9]{4}$"
+    },
+    "onExceeded": {
+      "$comment": "DR-0016. `fresh-implementer-and-third-contract` is the response that was measured to work: a fresh implementer plus a third review contract dispatched IMMEDIATELY, with the owner notified asynchronously. `escalate-to-owner` remains in the enum because DR-0016's residual guardrail is real: if the round after the fresh implementer also fails, the phase goes to the owner.",
+      "type": "string",
+      "enum": ["fresh-implementer-and-third-contract", "escalate-to-owner"]
+    },
+    "escalationBounds": {
+      "$comment": "DR-0012's stop-rather-than-grind limits, made data, plus DR-0016's response. THIS IS DATA THE ORCHESTRATOR BRIEF CITES (M3-P9), NOT AN ENFORCEMENT ENGINE: nothing in M3 counts fix rounds and nothing in M3 classifies a finding's component, and the plan's section 4.5 records that as unproven rather than implying otherwise. `on-exceeded` is in this object's OWN `required` list, which is what makes it required exactly when `escalation-bounds` is present, with no conditional rule to go vacuous. A bound that records the LIMIT but not the RESPONSE encodes the regime DR-0016 measured and replaced: DR-0012's bound was a stop-and-wait, that stop cost 4.7 hours on M1-P5 alone, it fired three times, all three times the owner chose the option the orchestrator had already recommended, and the intervention that actually broke the spiral was the FRESH IMPLEMENTER dispatched afterwards, which derived eleven call sites where the review had listed eight.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "max-fix-rounds-after-review",
+        "recurrence-of-high-in-one-component",
+        "on-exceeded"
+      ],
+      "properties": {
+        "max-fix-rounds-after-review": {
+          "description": "How many fix rounds may follow the first dual review before the bound fires. DR-0012 set two; DR-0035 replaced the single bound with a table running from one round (a zero or small subject) to three (a large subject at high impact), so what a mode records here is that table's CEILING rather than one phase's budget.",
+          "type": "integer"
+        },
+        "recurrence-of-high-in-one-component": {
+          "description": "How many times a high-severity finding may recur in one component across rounds before the bound fires. DR-0012 treats any recurrence as the trigger, so one.",
+          "type": "integer"
+        },
+        "on-exceeded": {
+          "$ref": "#/$defs/onExceeded"
+        }
+      }
+    }
+  }
+}