@tiphys/kernel 0.0.0 → 0.2.0

package/schemas/charter.schema.json

@@ -0,0 +1,185 @@
+{
+  "$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 }
+          }
+        }
+      ]
+    },
+    "review-families": {
+      "$comment": "DR-0038's DECLARATION, and it is a declaration rather than the exception itself (M4-D-28, kernel plan M4 section 4.2.6). DR-0012 condition 1 requires two clean-room reviews produced on different model FAMILIES. A project with one family available can satisfy that only by recording something false, and the shipped check makes it worse: it compares canonicalised STRINGS, so two models of one family compare as distinct and the pair reports decorrelated. This field is where a project states WHICH families its environment actually has. The schema does not encode the exception: single-family is `available.length === 1`, and what that then means is `dual-review-decorrelation`'s business. OPTIONAL, AND ITS ABSENCE IS NOT PERMISSION: an absent `review-families` leaves the cross-family requirement applying unchanged, so a same-family pair stays red (src/gates/release.ts:1037 states the same rule for the sibling case). WHY THE CHARTER AND NOT assurance-modes.yaml: DR-0029's split asks whether a fact is process or predicate, and 'which model families exist in this environment' is a fact about the PROJECT's environment, so it belongs to the project's own declaration; the assurance-mode vocabularies are closed by DR-0020 and bound to a derived check.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["available", "reason"],
+      "properties": {
+        "available": {
+          "$comment": "The model families this environment can actually dispatch a clean-room review on. NOT an enum: no closed vocabulary of model families can be kept current, and a stale enum here would refuse a true declaration. The check canonicalises each entry the same way it canonicalises a verdict's `produced-by`, so the two are comparable.",
+          "type": "array",
+          "minItems": 1,
+          "items": { "type": "string", "minLength": 1 }
+        },
+        "reason": {
+          "$comment": "Investigation defence 2, the same rule release-verification mode none is held to: narrowing an owner-reserved merge condition costs a stated reason. A declaration nobody has to justify is the shape DR-0038 exists to replace.",
+          "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 }
+      }
+    }
+  }
+}

package/schemas/checklist.schema.json

@@ -0,0 +1,114 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/checklist.schema.json",
+  "title": "Tiphys review checklist",
+  "$comment": "R-026b, R-027, R-028a, R-050b, R-053, R-054, R-055, R-056a, R-057b, R-059, R-066, R-093. Kernel plan M3, M3-P7 steps 1 and 5. A CHECKLIST IS A PROBE LIST WITH DECLARED ENTRY POINTS. THE HAZARD THIS DOCUMENT EXISTS AGAINST is the phase's own: a checklist whose probes are present, unique, resolvable and USELESS. This schema reaches four of the seven ways that happens and reaches none of the other three, which is stated here rather than left for a reader to assume. WHAT IT REACHES: a probe with no question, no scope or no evidence policy (required plus minLength); an `applies-to` token that is prose rather than a scope a resolver can group by (pattern); a framing with no entry point or that orders nothing (required plus minItems); a `verifies-gate` that is blank. WHAT IT CANNOT REACH, each with the instrument that does. (1) Whether a probe's TEXT is specific enough to need opening a file: that is a property of prose, it is criterion 3b's registered tests for the five probe sets the plan names, and for the rest it is risk 2 and the suggested-tier note. (2) Whether two probes share an `id`: `uniqueItems` compares WHOLE array items, so two probes differing in any other field are already unique to it; that is the Kind B check `checklist-probe-ids-unique`. (2a) THE SAME THING ONE ARRAY ALONG, missed until fix round 2 because the keyword limitation was recorded for probes and not generalised: two FRAMINGS sharing an id, which is the check `checklist-framing-ids-unique`. (3) Whether a `verifies-gate` names a gate that exists, or whether a probe named by the registry carries the back-reference at all: both are cross-document and are the Kind B check `gate-probes-resolve`, running in both directions.",
+  "description": "A review checklist: a list of probes a reviewer answers, plus the framings that decide which probe they answer first.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["kind", "id", "applies-to", "probes"],
+  "properties": {
+    "kind": {
+      "$comment": "R-016's discriminator, so `tiphys validate --type auto` resolves this document without being told, and M3R-001's rule that a type is registered with the validator in the same step that ships its schema is satisfied in both halves. A per-phase extra probe file (R-054, `checklist resolve --extra`) is ALSO a checklist document and carries this same kind, which is what makes an extra probe set independently validatable instead of a fragment only one command can read.",
+      "type": "string",
+      "const": "checklist"
+    },
+    "id": {
+      "$comment": "The name `tiphys checklist resolve --checklist <id>` takes, and the basename of the shipped file. A TOKEN rather than free prose, because the resolver looks it up.",
+      "type": "string",
+      "minLength": 1,
+      "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+    },
+    "applies-to": {
+      "$comment": "What kind of review this whole list is for, in one sentence. Prose, deliberately: this one is read by a human deciding which checklist to run and is never grouped on.",
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S"
+    },
+    "probes": {
+      "$comment": "`uniqueItems` is here and it is NOT the id-uniqueness rule. It compares whole items, so it catches a probe pasted twice verbatim and nothing else. Two probes sharing an id and differing in their question are unique to this keyword and are exactly the dangerous instance, which is why criterion 1's rejection is the derived check and not this line.",
+      "type": "array",
+      "minItems": 1,
+      "uniqueItems": true,
+      "items": {
+        "$ref": "#/$defs/probe"
+      }
+    },
+    "framings": {
+      "$comment": "T-001's second data point (M3R-004): the M1-P4 dual review found different defects because the two reviewers were given different STARTING QUESTIONS, and T-001's own words are that the checklists should vary the entry point rather than only the reviewer. A framing is therefore data in the artifact rather than a sentence in a dispatch prompt. Optional, because `checklists/flake-playbook.yaml` and `checklists/env-failure-diagnosis.yaml` are single-entry-point procedures and inventing framings for them would be ceremony. `uniqueItems` is here and, exactly as on `probes` above, it is NOT the id-uniqueness rule: it compares whole items, so two framings sharing an id and differing in their entry point are unique to it and are the dangerous instance, since `resolveChecklist` looks a framing up by id and first match wins. That is the derived check `checklist-framing-ids-unique`, added in fix round 2.",
+      "type": "array",
+      "minItems": 1,
+      "uniqueItems": true,
+      "items": {
+        "$ref": "#/$defs/framing"
+      }
+    }
+  },
+  "$defs": {
+    "probe": {
+      "$comment": "One question, its scope, and whether an answer must cite something.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["id", "probe", "applies-to", "evidence-required"],
+      "properties": {
+        "id": {
+          "type": "string",
+          "minLength": 1,
+          "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+        },
+        "probe": {
+          "$comment": "THE QUESTION. Prose, and the one field this schema can say least about: `minLength` stops it being empty and nothing here stops it being generic. That gap is the phase's whole hazard class and the instrument is criterion 3b.",
+          "type": "string",
+          "minLength": 1,
+          "pattern": "\\S"
+        },
+        "applies-to": {
+          "$comment": "THE SCOPE TOKEN, and it is a token rather than prose because the resolver GROUPS ON IT. A framing's `orders-probes` names scopes, so this field is what makes `--framing` reorder the list rather than decorate it. A probe whose scope does not apply is still answerable ('not applicable, no destructive command in the diff'), so this is a grouping key and never a filter that silently drops a probe.",
+          "type": "string",
+          "minLength": 1,
+          "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+        },
+        "evidence-required": {
+          "$comment": "R-054's second failure mode: an extra probe merged in without this field. A boolean rather than an optional flag, so a probe cannot be silently opinion-only. True means the answer must cite a path, a line, a captured command or an exit code.",
+          "type": "boolean"
+        },
+        "verifies-gate": {
+          "$comment": "NEW at revision 3, criterion 3c. The id of the `gate-registry.yaml` entry whose `verified-by: clean-room-checklist` names this probe. OPTIONAL because most probes verify no gate, and it is what makes the checklist-to-registry direction computable at all: without a back-reference there is nothing to resolve and an orphaned probe stays invisible by construction. That every registry-named probe MUST carry it is an `if`/`then` across two documents, which no keyword here reaches; it is enforced by `gate-probes-resolve`.",
+          "type": "string",
+          "minLength": 1,
+          "pattern": "\\S"
+        }
+      }
+    },
+    "framing": {
+      "$comment": "One declared entry point into the same probe list.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["id", "entry-point", "orders-probes"],
+      "properties": {
+        "id": {
+          "type": "string",
+          "minLength": 1,
+          "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+        },
+        "entry-point": {
+          "$comment": "The starting question this framing hands the reviewer, printed at the head of the resolved list. T-001's two real examples are walking the acceptance criteria as a contract, and starting from where this can destroy something or claim a guarantee it does not have.",
+          "type": "string",
+          "minLength": 1,
+          "pattern": "\\S"
+        },
+        "orders-probes": {
+          "$comment": "The probe SCOPES, in the order this framing wants them, each naming an `applies-to` token. Probes in a named scope lead, scope by scope, and inside one scope the FILE ORDER decides; every probe in no named scope follows in file order. Ordering by scope rather than by probe id is what makes criterion 4d falsifiable: `CLAUDE.md` says the reviewer's FIRST check is item 3, and with a scope list the first resolved probe is the first `fix-round` probe IN THE FILE, so moving it later changes the answer. A framing that listed probe ids instead would pin the head no matter where the probe sat, which is the hazard class's 'ordering expressed as a comment rather than as position' wearing a schema's clothes.",
+          "type": "array",
+          "minItems": 1,
+          "uniqueItems": true,
+          "items": {
+            "type": "string",
+            "minLength": 1,
+            "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"
+          }
+        }
+      }
+    }
+  }
+}

package/schemas/cutover-state.schema.json

@@ -0,0 +1,64 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/cutover-state.schema.json",
+  "title": "Cutover state",
+  "description": "The fleet's cutover.json: the five freeze switches and what each of them records. Kernel plan M4, M4-P25 acceptance criterion 4.",
+  "$comment": "THE WIRE NAMES ARE camelCase AND THAT IS ESTABLISHED, NOT CHOSEN HERE. The M4 plan section spells the fields flipped-at, flipped-by, reason and restore-to; the document M4-P26 already writes and reads spells them flippedAt, flippedBy, reason and restoreTo (src/cutover.ts:98 declares the interface and src/cutover.ts:152 validates it). A schema that pinned the kebab spelling would refuse every document the shipped writer produces, so this pins what the document uses and the plan's spelling is read as prose naming the four fields rather than as their serialised keys.",
+  "type": "object",
+  "required": ["switches"],
+  "properties": {
+    "switches": {
+      "type": "object",
+      "description": "One record per switch. The five names are a CLOSED list: a sixth name is a plan revision, not a document edit, because every rollback trigger enumerates them.",
+      "required": [
+        "planning-and-scope",
+        "review-and-arbitration",
+        "credentials-and-refs",
+        "salvage-and-recovery",
+        "closeout"
+      ],
+      "properties": {
+        "planning-and-scope": { "$ref": "#/$defs/switchRecord" },
+        "review-and-arbitration": { "$ref": "#/$defs/switchRecord" },
+        "credentials-and-refs": { "$ref": "#/$defs/switchRecord" },
+        "salvage-and-recovery": { "$ref": "#/$defs/switchRecord" },
+        "closeout": { "$ref": "#/$defs/switchRecord" }
+      },
+      "additionalProperties": false
+    }
+  },
+  "additionalProperties": true,
+  "$defs": {
+    "switchRecord": {
+      "$comment": "additionalProperties is TRUE here and at the document level, against the schemas/README.md preference for false at every object level, and the deviation is deliberate rather than an omission. M4-P26 shipped a rollback that CARRIES document keys it does not own, at both levels, and registered that behaviour as a guarded test (test/cutover.test.ts:974). Closing either level would make the shipped writer refuse its own preserved keys, so this document is open by decision and the closed half is the switch NAME list one level up, which is the vocabulary that actually has to be closed.",
+      "type": "object",
+      "required": ["state", "flippedAt", "flippedBy", "reason", "restoreTo"],
+      "properties": {
+        "state": {
+          "description": "Which process holds the authority this switch governs.",
+          "enum": ["current", "kernel"]
+        },
+        "flippedAt": {
+          "description": "When the switch was last written, as an ISO 8601 instant.",
+          "type": "string",
+          "minLength": 1
+        },
+        "flippedBy": {
+          "description": "Who or what performed the write.",
+          "type": "string",
+          "minLength": 1
+        },
+        "reason": {
+          "description": "Why the switch was written.",
+          "type": "string",
+          "minLength": 1
+        },
+        "restoreTo": {
+          "description": "The value the switch held BEFORE the write. It is what makes rollback a matter of reading a recorded value rather than reconstructing an intent, and a record without it cannot be rolled back at all.",
+          "enum": ["current", "kernel"]
+        }
+      },
+      "additionalProperties": true
+    }
+  }
+}

package/schemas/decision-record.schema.json

@@ -0,0 +1,88 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/decision-record.schema.json",
+  "title": "Tiphys decision record",
+  "description": "Blueprint section 7's field list, plus the fields R-063 and R-090 need in order to be checkable rather than habitual. An OPEN QUESTION is a record with status open (D-7), so there is one register and never two.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "kind",
+    "id",
+    "project",
+    "task",
+    "question",
+    "options",
+    "reversibility",
+    "vetoable",
+    "revert-cost",
+    "status",
+    "decided",
+    "date"
+  ],
+  "properties": {
+    "kind": {
+      "type": "string",
+      "const": "decision-record"
+    },
+    "id": {
+      "type": "string",
+      "pattern": "^DR-[0-9]{4}$"
+    },
+    "project": { "type": "string", "minLength": 1 },
+    "task": { "type": "string", "minLength": 1 },
+    "question": { "type": "string", "minLength": 1 },
+    "options": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["label", "consequence"],
+        "properties": {
+          "label": { "type": "string", "minLength": 1 },
+          "consequence": { "type": "string", "minLength": 1 }
+        }
+      }
+    },
+    "reversibility": {
+      "$comment": "R-063. Exactly three values, so the cost of being wrong is stated rather than implied.",
+      "type": "string",
+      "enum": ["reversible", "costly", "irreversible"]
+    },
+    "vetoable": {
+      "$comment": "R-090: a forced owner-adjacent call is decided, FLAGGED VETOABLE, and made trivially revertible. This field and revert-cost are what turn that sentence from a habit into a required field.",
+      "type": "boolean"
+    },
+    "revert-cost": {
+      "type": "string",
+      "minLength": 1
+    },
+    "status": {
+      "$comment": "D-7: an open question is a record with status open.",
+      "type": "string",
+      "enum": ["open", "deferred", "decided"]
+    },
+    "decided": {
+      "$comment": "The answer in the decider's own terms. Empty while the record is open or deferred; a record with status decided and an empty decided field is a record that claims an answer it does not carry, which is the Kind A pair the if/then below enforces.",
+      "type": "string"
+    },
+    "date": {
+      "type": "string",
+      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$"
+    },
+    "evidence": {
+      "type": "array",
+      "items": { "type": "string", "minLength": 1 }
+    }
+  },
+  "if": {
+    "type": "object",
+    "required": ["status"],
+    "properties": { "status": { "const": "decided" } }
+  },
+  "then": {
+    "type": "object",
+    "required": ["decided"],
+    "properties": { "decided": { "type": "string", "minLength": 1 } }
+  }
+}

package/schemas/executor-record.schema.json

@@ -0,0 +1,36 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/executor-record.schema.json",
+  "title": "Tiphys executor launch record",
+  "description": "tasks/<id>/executor.json, the record an ExecutorAdapter writes at launch (DR-0006 for the format, PR-207 for the shape, M4-P3 for the contract). Until M4-P3 this document was written by the kernel and validated by nothing, which is the state delivery/plan/m4-intake.md:272 names. It is written BEFORE the payload starts, which is what makes a failure to write it provably a launch failure and therefore safe to roll back.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["adapter", "launchedAt"],
+  "properties": {
+    "adapter": {
+      "$comment": "The adapter that wrote this record, by its own `name`. REQUIRED: a launch record that does not say what launched it cannot be attributed, and attribution is the whole reason an operator opens this file.",
+      "type": "string",
+      "minLength": 1
+    },
+    "launchedAt": {
+      "$comment": "RFC 3339 UTC, the same spelling every other Tiphys record uses, so two records from two machines sort. Written from `new Date().toISOString()`.",
+      "type": "string",
+      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$"
+    },
+    "deadline": {
+      "$comment": "PR-207. The absolute instant by which the task must have completed, present ONLY when --deadline was passed. Recorded as an instant rather than as raw seconds so the watcher compares it against the clock directly instead of re-deriving it from launchedAt.",
+      "type": "string",
+      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$"
+    },
+    "requestedTier": {
+      "$comment": "M4-P3 criterion 6. THE DECLARED TIER THE REQUEST CARRIED, VERBATIM, AND NEVER A MODEL NAME. Whatever role-model-config.yaml declares crosses the seam unaltered; the tier-to-model mapping lives in the plugin and never in src/, which is what keeps a harness that is not the one named possible at all (delivery/plan/m4-intake.md:377). The schema does not enum this value, because the vocabulary belongs to the plugin and an enum here would be that mapping's first half.",
+      "type": "string",
+      "minLength": 1
+    },
+    "requestedRole": {
+      "$comment": "M4-P3 criterion 6. The role the request carried, verbatim. Not enumerated here for the same reason requestedTier is not: roles/ is a shipped directory and the role-to-brief mapping is the plugin's.",
+      "type": "string",
+      "minLength": 1
+    }
+  }
+}

package/schemas/final-report.schema.json

@@ -0,0 +1,90 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://tiphys.dev/schemas/final-report.schema.json",
+  "title": "Tiphys final report",
+  "$comment": "R-089a. Kernel plan M3, M3-P4 step 2. THE FINAL REPORT IS A PROJECTION, NOT A SUMMARY, and that property is load-bearing beyond this phase. Every field here is DERIVED from records that already exist (findings, verdicts, decisions, work histories), which is the same relation M3-P8's mechanism index has to the tuition feed. That relation is what makes a dense read layer possible on top of a verbose archive: the projections are consumed at every dispatch and must stay dense, while the raw entries are read only in dispute. M3 BUILDS NO COMPACTOR AND THIS SCHEMA PROPOSES NONE; what it does is make the distinction structural, so a later compaction is a question about which layer a file is in rather than a judgement about which files look like filler. SILENCE AND EMPTINESS ARE DISTINGUISHABLE: each of the four enumerable sections is a two-branch oneOf, so `none: true` carries NO entries key at all and `none: false` carries at least one entry. That closes BOTH directions of the relation rather than one: an empty list without a marker is a rejection, and a `none: true` marker sitting on top of real entries is also a rejection. THE PARITY BETWEEN `inputs[]` AND `input-findings[]` IS NOT HERE: cross-array completeness is not a keyword property (M3R-002), so it is the derived check `final-report-finding-parity` in src/checks.ts, and it is checked a second time by the M2-P6 coverage checker's finding-to-outcome parity mode because the artifact should be self-checking AND the independent checker is the one the pipeline runs.",
+  "description": "One document per delivery. Every input finding mapped to an outcome, plus the decisions owed, the owner verifications outstanding, the infrastructure left behind, and anything done out of band.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "kind",
+    "subject",
+    "inputs",
+    "input-findings",
+    "decisions-owed",
+    "owner-verification",
+    "infrastructure-left",
+    "out-of-band"
+  ],
+  "properties": {
+    "kind": {
+      "description": "The artifact type, so `tiphys validate --type auto` resolves this document without being told.",
+      "type": "string",
+      "const": "final-report"
+    },
+    "subject": {
+      "description": "What this report is the final report OF.",
+      "type": "string",
+      "minLength": 1,
+      "pattern": "\\S"
+    },
+    "inputs": {
+      "$comment": "The finding ids this delivery took in. Kept SEPARATE from `input-findings[]` on purpose: a table that is its own inventory cannot be incomplete, which is the circularity scripts/check-clause-map.mjs's header names one level up. The derived check compares the two.",
+      "type": "array",
+      "items": { "type": "string", "minLength": 1, "pattern": "\\S" },
+      "uniqueItems": true
+    },
+    "input-findings": {
+      "$comment": "R-089a's table. Every id in `inputs[]` lands in exactly one row here with a non-empty outcome.",
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["id", "outcome"],
+        "properties": {
+          "id": { "type": "string", "minLength": 1, "pattern": "\\S" },
+          "outcome": { "type": "string", "minLength": 1, "pattern": "\\S" }
+        }
+      }
+    },
+    "decisions-owed": { "$ref": "#/$defs/enumerableSection" },
+    "owner-verification": { "$ref": "#/$defs/enumerableSection" },
+    "infrastructure-left": { "$ref": "#/$defs/enumerableSection" },
+    "out-of-band": { "$ref": "#/$defs/enumerableSection" }
+  },
+  "$defs": {
+    "enumerableSection": {
+      "$comment": "ALLOWED TO BE EMPTY ONLY WITH AN EXPLICIT MARKER, so silence and emptiness are distinguishable (plan step 2). The two branches are exclusive by construction: branch 1 permits `none: true` AND NOTHING ELSE, so a marker sitting on top of real entries is a rejection; branch 2 requires `none: false` with at least one entry, so an empty list hiding behind a false marker is a rejection too. Both directions, rather than the one the requirement's letter names. RESIDUE, ADDED IN M3-P4 FIX ROUND 2 BY THE CR-002 ENUMERATION: this is the same mechanism CR-002 named one document over. The branch is picked by A VALUE THE AUTHOR WRITES, and branch 1 owes NOTHING, so an author with three real decisions owed writes `none: true` and the schema is satisfied. What the two branches close is INTERNAL CONTRADICTION (a marker over entries, entries with no marker); what neither reaches is a marker over a truth outside the document. Nothing in this schema could reach it, because there is no second record here to compare against; the derived check `final-report-finding-parity` is what that comparison looks like where a second record exists, and `decisions-owed` has none.",
+      "oneOf": [
+        {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["none"],
+          "properties": { "none": { "type": "boolean", "const": true } }
+        },
+        {
+          "type": "object",
+          "additionalProperties": false,
+          "required": ["none", "entries"],
+          "properties": {
+            "none": { "type": "boolean", "const": false },
+            "entries": {
+              "type": "array",
+              "minItems": 1,
+              "items": {
+                "type": "object",
+                "additionalProperties": false,
+                "required": ["statement"],
+                "properties": {
+                  "id": { "type": "string", "minLength": 1, "pattern": "\\S" },
+                  "statement": { "type": "string", "minLength": 1, "pattern": "\\S" },
+                  "owner": { "type": "string", "minLength": 1, "pattern": "\\S" }
+                }
+              }
+            }
+          }
+        }
+      ]
+    }
+  }
+}