@tiphys/kernel 0.0.0 → 0.1.0

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,81 @@
+# 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` | |
+| `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: \"more than two fix rounds after its first dual review\", so two.",
+          "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"
+        }
+      }
+    }
+  }
+}

package/schemas/charter.schema.json

@@ -0,0 +1,166 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/charter.schema.json",
+  "title": "Tiphys project charter",
+  "description": "Blueprint section 7. The charter is what a project realizes the kernel against. A missing required field BLOCKS realization, which is what this document's required list means.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "kind",
+    "identity",
+    "delivery-mode",
+    "assurance-tier",
+    "yolo-permissions",
+    "irreversible-decisions",
+    "product-intent",
+    "constraints",
+    "escalation-contract",
+    "release-verification",
+    "retention"
+  ],
+  "properties": {
+    "kind": {
+      "type": "string",
+      "const": "charter"
+    },
+    "identity": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["name", "repo", "kernel-version-pin"],
+      "properties": {
+        "name": { "type": "string", "minLength": 1 },
+        "repo": { "type": "string", "minLength": 1 },
+        "kernel-version-pin": {
+          "$comment": "An exact version, never a range. A range makes the delivery process a moving target.",
+          "type": "string",
+          "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+(-[0-9A-Za-z.-]+)?$"
+        }
+      }
+    },
+    "delivery-mode": {
+      "$comment": "The enum is declared HERE and the mode DEFINITIONS are owned by M3-P3's assurance-modes.yaml. The derived check charter-mode-enum-matches-modes (M3-P3) asserts the two agree, so the duplication cannot drift. M3-P1's placeholder list (full, standard, fast, yolo) was REPLACED by M3-P3 with the three ids blueprint section 8 actually declares; `standard`, `fast` and `yolo` named no mode definition anywhere and a charter could select one and get a delivery mode with no pipeline behind it. CLOSED VOCABULARY AT v0.1.0 (DR-0020): the three values are the tiphys kernel's OWN mode ids and this enum rejects every other value, so a consuming project's charter cannot select a delivery mode of its own name at v0.1.0. Extension is an M4 question, deferred to a real pilot consumer.",
+      "type": "string",
+      "enum": ["full", "direct-pr", "local-only"]
+    },
+    "assurance-tier": {
+      "$comment": "The SAME vocabulary as delivery-mode and watched by the same check. M3-P1 shipped the identical placeholder enum on both fields, so a check that watched only one would leave the other free to drift, which is the hazard rather than a smaller version of it. CLOSED VOCABULARY AT v0.1.0 (DR-0020): the same closed set as delivery-mode, with the same consequence for a consuming project and the same M4 deferral.",
+      "type": "string",
+      "enum": ["full", "direct-pr", "local-only"]
+    },
+    "yolo-permissions": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["enabled", "scope"],
+      "properties": {
+        "enabled": { "type": "boolean" },
+        "scope": {
+          "type": "array",
+          "items": { "type": "string", "minLength": 1 }
+        }
+      }
+    },
+    "irreversible-decisions": {
+      "$comment": "Blueprint section 7's named list. Every one of the seven is required, because an irreversible decision left unstated is one the delivery process will improvise.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "stack",
+        "language",
+        "framework",
+        "core-data-model",
+        "tenancy",
+        "auth",
+        "deployment-topology"
+      ],
+      "properties": {
+        "stack": { "type": "string", "minLength": 1 },
+        "language": { "type": "string", "minLength": 1 },
+        "framework": { "type": "string", "minLength": 1 },
+        "core-data-model": { "type": "string", "minLength": 1 },
+        "tenancy": { "type": "string", "minLength": 1 },
+        "auth": { "type": "string", "minLength": 1 },
+        "deployment-topology": { "type": "string", "minLength": 1 }
+      }
+    },
+    "product-intent": {
+      "$comment": "One page, authored as a YAML block scalar.",
+      "type": "string",
+      "minLength": 1
+    },
+    "constraints": {
+      "type": "array",
+      "items": { "type": "string", "minLength": 1 }
+    },
+    "escalation-contract": {
+      "$comment": "R-022 and R-090: owner decisions are never pre-empted.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["stop-for", "route"],
+      "properties": {
+        "stop-for": {
+          "$comment": "Its DEFAULT entries, shipped in templates/charter.example.yaml, are 'any irreversible choice the charter is silent on' and 'a change from a declared release verification to `none`'. They are defaults rather than schema constants because the charter is the owner's document; the second one is what makes turning verification off an owner decision instead of an implementer's edit (delivery/verification/release-verification-interface.md section 4.1).",
+          "type": "array",
+          "minItems": 1,
+          "items": { "type": "string", "minLength": 1 }
+        },
+        "route": { "type": "string", "minLength": 1 }
+      }
+    },
+    "release-verification": {
+      "$comment": "RESERVED, NOT DESIGNED (DR-0014, D-M3-29). The field's real shape is NOT decided here. delivery/verification/release-verification-interface.md section 8 item 4: 'the charter field is M3's, and M3 should reserve the space rather than design it', settled by the first real project charter at M4's pilot. This schema enumerates no adapters, models no N verifications, expresses no outcome enum, and carries no charter coherence check. The two currently-valid shapes are the oneOf below; any other shape is a rejection, which is the guard that stops a project inventing the field's real shape before M4's pilot decides it.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["mode"],
+      "properties": {
+        "mode": {
+          "type": "string",
+          "enum": ["none", "reserved"]
+        },
+        "reason": { "type": "string", "minLength": 1 },
+        "note": { "type": "string", "minLength": 1 }
+      },
+      "if": {
+        "$comment": "Investigation defence 2: silence is never permission. Disabling verification costs visibility, so mode none REQUIRES a stated reason.",
+        "type": "object",
+        "required": ["mode"],
+        "properties": { "mode": { "const": "none" } }
+      },
+      "then": {
+        "type": "object",
+        "required": ["reason"],
+        "properties": { "reason": { "type": "string", "minLength": 1 } }
+      },
+      "oneOf": [
+        {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["mode", "reason"],
+          "properties": {
+            "mode": { "type": "string", "const": "none" },
+            "reason": { "type": "string", "minLength": 1 }
+          }
+        },
+        {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["mode", "note"],
+          "properties": {
+            "mode": { "type": "string", "const": "reserved" },
+            "note": { "type": "string", "minLength": 1 }
+          }
+        }
+      ]
+    },
+    "retention": {
+      "$comment": "Consumed by M3-P8 for R-098.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["work-history", "evidence", "tuition"],
+      "properties": {
+        "work-history": { "type": "string", "minLength": 1 },
+        "evidence": { "type": "string", "minLength": 1 },
+        "tuition": { "type": "string", "minLength": 1 }
+      }
+    }
+  }
+}