@tiphys/kernel 0.0.0 → 0.1.0

package/tuition/T-001.yaml

@@ -0,0 +1,48 @@
+# T-001: cross-model review caught findings that survived three same-model
+# rounds. Promoted from the delivering project's own log by M3-P8; the
+# long-form account stays there.
+kind: tuition
+version: 1
+id: T-001
+project: tiphys-kernel
+date: 2026-08-04
+stage: planning, before any implementation dispatch
+kernel-relevant: true
+what-happened: >-
+  The kernel plan went through three adversarial review rounds plus one
+  targeted verification, all by the same model family, producing 28 applied
+  findings. An external review by a different model family then found two
+  genuine defects that had survived every internal round: lease renewal was
+  never required to fail after expiry, so an expired-but-alive holder racing a
+  legitimate takeover could produce dual mutation; and fleet initialization
+  assumed a configured git identity, which a clean cloud environment does not
+  have. A second data point arrived the same day, with decorrelation in place:
+  two clean-room reviews of one head, given deliberately different starting
+  questions, found different defects, and the hazard-framed one surfaced two
+  highs the criteria walk did not raise at all.
+lesson:
+  - >-
+      Same-family reviewers share blind spots, and the deterministic verifier
+      layer does not cover design-level races or environment assumptions at
+      planning time.
+  - >-
+      The narrower lesson is not "use two models". It is that two reviews with
+      different STARTING QUESTIONS find different things, and model diversity
+      makes that difference harder to collapse.
+structural-consequence:
+  - target: role-model-config.yaml
+    status: applied
+    change: >-
+      The role-to-model binding carries a review-model-family field, so which
+      family produced a review is configuration rather than a dispatch habit.
+  - target: checklists/clean-room.yaml
+    status: ticketed
+    change: >-
+      The review checklists must vary the ENTRY POINT rather than only the
+      reviewer, so the two contracts of a dual review start from different
+      questions by construction.
+    record: delivery/plan/kernel-plan-m3.md, M3-P7 step 3
+evidence:
+  - delivery/review/plan-review-r4-external.md, the external review with its verdict and findings
+  - delivery/review/plan-review-r1.md, delivery/review/plan-review-r2.md and delivery/review/plan-review-r3.md, the internal rounds that missed both defects
+  - delivery/review/clean-room-m1-p4.md and delivery/review/clean-room-m1-p4-second.md, the first dual review with two framings

package/tuition/T-002.yaml

@@ -0,0 +1,51 @@
+# T-002: agent death mid fix round, and salvage exercised for real. Promoted
+# from the delivering project's own log by M3-P8.
+kind: tuition
+version: 1
+id: T-002
+project: tiphys-kernel
+date: 2026-08-04
+stage: M1-P3 fix round (session lock and worktree pool)
+kernel-relevant: true
+what-happened: >-
+  An implementer hit a provider usage limit part way through a fix round and
+  stopped, leaving uncommitted work in its worktree and no turn-end record.
+  The stop was clean and quiet: nothing crashed, nothing timed out, and no exit
+  code said anything had gone wrong. The work was salvaged by hand into a
+  commit marked WIP-UNREVIEWED, which is the discipline the process document
+  mandates and which nothing in the system detects or performs.
+lesson:
+  - >-
+      Agent death from a provider limit is a distinct failure class from a crash
+      or a timeout, and it looks exactly like an ordinary completion to anything
+      keyed on process exit.
+  - >-
+      A missing turn-end record must never be read as success. Task open, no
+      turn-end, worktree dirty is the abandoned-task state and deserves its own
+      wake reason rather than being discovered later.
+  - >-
+      Salvage is currently manual. Detection belongs with the watcher and the
+      liveness guard, because a rule that depends on somebody noticing is the
+      thing that failed here.
+structural-consequence:
+  - target: src/teardown.ts
+    status: applied
+    change: >-
+      teardown --salvage commits a dirty worktree under a fixed
+      WIP-UNREVIEWED prefix, so the audit trail of a salvage is uniform rather
+      than per-incident.
+  - target: src/watcher.ts
+    status: applied
+    change: >-
+      The watcher treats an open task with no turn-end record as a wake
+      condition with its own reason line, so the human is told rather than
+      finding out afterwards.
+  - target: roles/implementer.md
+    status: applied
+    change: >-
+      The R-081b clause makes incremental, committed output an obligation of
+      the dispatched agent, so a death leaves a partial result rather than
+      nothing.
+evidence:
+  - delivery/work-history/m1-p3.md, fix-round section, with the measured salvage state
+  - delivery/intake/orchestrated-delivery-process.md section 6, the salvage discipline

package/tuition/T-003.yaml

@@ -0,0 +1,100 @@
+# T-003: a fix round for low-severity findings introduced two high-severity
+# defects. Promoted from the delivering project's own log by M3-P8.
+kind: tuition
+version: 1
+id: T-003
+project: tiphys-kernel
+date: 2026-08-04
+stage: M1-P3 (session lock and worktree pool), after clean-room APPROVE
+kernel-relevant: true
+what-happened: >-
+  A fix round addressing four LOW findings introduced two HIGH defects. One
+  gave a worktree destroy the authority to force-delete a branch, justified by
+  a component scheduled for a later phase that would refuse first. The other
+  narrowed a git contention matcher using hand-written example strings chosen
+  to match the new pattern, so real racing-git messages fell outside it. The
+  round's own tests were green and worthless for both: the destroy test
+  destroyed a branch still at its base commit, so no data could be lost, and
+  the concurrency test never advanced the upstream, so no ref transaction was
+  ever opened. The work history then stated as measured fact a universal claim
+  that concealed the second defect from the next reader.
+lesson:
+  - >-
+      A fix round is not lower risk than the work it fixes, and it receives less
+      scrutiny. The severity of the findings being fixed says nothing about the
+      severity of the defects the fixes can introduce.
+  - >-
+      Tests written alongside a fix test the fix, not the behaviour the fix
+      endangers. A test must be red against the DANGEROUS state, not merely
+      against the absence of the feature.
+  - >-
+      An unfalsified universal claim in a work history is worse than no claim:
+      the document whose purpose is to let a reviewer trust the round is what
+      hid the defect.
+mechanisms:
+  - mechanism: Lease compare-and-swap
+    rule: >-
+      Liveness is lease freshness, never pid, process probing or signals
+      (constraint C-2). Expiry does not block a release, but it DOES block a
+      renew and it DOES block teardown's holdership check, which fails closed.
+    siblings:
+      - src/lock.ts
+      - src/task.ts
+    evidence:
+      - src/lock.ts
+      - checkHoldership in src/task.ts
+      - CR-680 in delivery/review/clean-room-m1-p6-round3-hazard.md
+  - mechanism: Append-only log
+    rule: >-
+      Never read current state from the tail of a log (constraint C-1).
+      Currency comes from `meta.json` and turn-end files only.
+    siblings:
+      - src/task.ts
+    evidence:
+      - plan v1 section 3, C-1 (FM-052)
+  - mechanism: Worktree removal and force branch delete
+    rule: >-
+      Resolve, evaluate, then apply. No policy decision may be taken after a
+      destructive action has begun, and destructive authority is never
+      inherited from a component that does not exist yet.
+    siblings:
+      - src/pool.ts
+      - src/teardown.ts
+    machine-readable-form:
+      path: gates.manifest.json
+      key: destructiveCommands
+    evidence:
+      - delivery/review/verification-m1-p3-fix-round.md V-1 and V-3
+  - mechanism: Classifying another program's errors
+    rule: >-
+      Derive the signature from REAL captured output under forced conditions,
+      never from hand-written examples chosen to match the implementation. 312
+      captured contention failures, every one of the dropped shape.
+    siblings:
+      - src/pool.ts
+    evidence:
+      - V-2 in delivery/review/verification-m1-p3-fix-round.md
+      - CLAUDE.md environment warning 10
+structural-consequence:
+  - target: assurance-modes.yaml
+    status: applied
+    change: >-
+      Full mode carries a fix-round-verification stage, so an independent
+      verification of a fix round is a declared pipeline stage rather than
+      orchestrator discretion.
+  - target: schemas/report.schema.json
+    status: applied
+    change: >-
+      The shared claims[] contract makes a universal claim carry the executed
+      construction that could have falsified it, or be restated as an open
+      question.
+  - target: gates.manifest.json
+    status: applied
+    change: >-
+      The destructiveCommands list names every command that can destroy work,
+      which is the machine-readable view of this entry's destructive-operation
+      rule and the list the derived-class rule consumes.
+evidence:
+  - delivery/review/verification-m1-p3-fix-round.md, findings V-1 and V-2 with the unrefuted candidates
+  - delivery/review/clean-room-m1-p3.md, the APPROVE and the four LOW findings that triggered the round
+  - delivery/work-history/m1-p3.md, the round's own record including the claim named above

package/tuition/T-004.yaml

@@ -0,0 +1,52 @@
+# T-004: verification lenses sharing one worktree can manufacture a phantom
+# defect. Promoted from the delivering project's own log by M3-P8.
+kind: tuition
+version: 1
+id: T-004
+project: tiphys-kernel
+date: 2026-08-04
+stage: M1-P3 verification and the investigation that followed it
+kernel-relevant: true
+what-happened: >-
+  Two verification lenses ran against the same worktree. One was running a
+  disciplined sabotage window (copy, mutate, measure, restore) while the other
+  ran tests. The second lens observed a failure that came from the first lens's
+  mutation and reported it as a defect. By the time anyone inspected the tree it
+  was byte-clean, so the evidence of contamination was gone while the finding
+  survived, and closing it took two multi-hour investigations.
+lesson:
+  - >-
+      Shared mutable ground turns one lens's experiment into another lens's
+      discovery, and the contamination erases itself while the finding remains.
+  - >-
+      The dispatch instruction was the defect. The briefs PERMITTED isolation
+      rather than REQUIRING it, and permitting is not requiring.
+  - >-
+      A test run is only evidence if you can prove what it ran. A run that
+      cannot name what it executed is an anecdote.
+mechanisms:
+  - mechanism: Shared worktree
+    rule: >-
+      A verification lens works in its OWN clone, never in a tree another agent
+      is editing, and a run that cannot pin the source it ran against is not
+      evidence and must label itself so.
+    siblings:
+      - src/pool.ts
+    evidence:
+      - delivery/verification/u2-race-flake-investigation.md, the U-2 phantom and the four hypotheses each run in a private clone
+      - delivery/review/verification-m1-p3-fix-round.md, the round whose lenses shared a tree
+structural-consequence:
+  - target: schemas/report.schema.json
+    status: applied
+    change: >-
+      A report declares the source it ran against, so a finding produced by a
+      run that cannot pin its source is labelled unpinned rather than inherited
+      as fact.
+  - target: roles/investigator.md
+    status: applied
+    change: >-
+      The investigator brief requires a private clone and a reproduction, so
+      isolation is a role obligation rather than a dispatch-time permission.
+evidence:
+  - delivery/verification/u2-race-flake-investigation.md, the whole investigation
+  - delivery/review/verification-m1-p3-fix-round.md, the run that produced the phantom

package/tuition/T-005.yaml

@@ -0,0 +1,72 @@
+# T-005: a lesson the codebase had already paid for did not reach the next
+# phase that needed it. Promoted from the delivering project's own log by
+# M3-P8; the long-form account stays there.
+kind: tuition
+version: 1
+id: T-005
+project: tiphys-kernel
+date: 2026-08-05
+stage: M1-P5 (watcher and liveness guard), first dual review
+kernel-relevant: true
+what-happened: >-
+  M1-P3 established, in a multi-hour investigation, that a claim file which
+  cannot be taken must fail loudly and name the stuck file. Two phases later
+  M1-P5 implemented the same claim-file pattern for the watcher's seen state
+  and absorbed the timeout silently. A stranded claim file then made every
+  subsequent watcher pass report that there was nothing to surface, for a
+  genuinely pending signal, while the beacon kept advancing so the liveness
+  guard reported the fleet healthy throughout. It was the most severe defect
+  found in M1. The implementer had read the plan, the agent-rules file, the
+  constraint list, the environment warnings and three prior work histories,
+  and none of them carried the rule: it lived in the M1-P3 source and in an
+  investigation report filed under the mystery it solved rather than under the
+  mechanism it constrained.
+lesson:
+  - >-
+      A lesson attached to a component does not travel to the next component
+      that needs it. Documents organised by phase, by incident or by environment
+      each fail this for their own reason, and none of them is carelessness.
+  - >-
+      The missing artifact is an index from MECHANISM to RULE, so an implementer
+      reaching for a claim file, a lease, an append-only log or a destructive
+      git operation can ask what the project already learned and get an answer.
+  - >-
+      That index is a PROJECTION of the tuition feed rather than a second thing
+      to maintain, because two copies of a rule is the state that produced this
+      defect in the first place.
+mechanisms:
+  - mechanism: Claim file (mutual exclusion by O_EXCL)
+    rule: >-
+      A claim that cannot be taken must fail LOUDLY and name the stuck file. A
+      silent timeout is indistinguishable from an absence of contention. There
+      are now THREE claim-file users (the lock, the watcher seen-state, and
+      M2-P1's evidence-directory run claim); the next one reads `src/lock.ts`
+      first, and the M2-P1 instance is the worked example of doing that and
+      stating the one difference (no expiry, because an evidence directory must
+      not have a lease that lapses).
+    siblings:
+      - src/lock.ts
+      - src/watch.ts
+      - src/gates/run.ts
+    evidence:
+      - delivery/verification/u2-race-flake-investigation.md D-3
+      - delivery/tuition/T-005, the silent reimplementation two phases later that became M1's most severe defect
+structural-consequence:
+  - target: tuition/mechanism-index.yaml
+    status: applied
+    change: >-
+      The mechanism index exists and is generated by `tiphys tuition index` as
+      a projection of every tuition entry's mechanisms[] field, so a rule is
+      recorded once and read from one place.
+  - target: roles/implementer.md
+    status: applied
+    change: >-
+      The mandated reading list names the mechanism index, and the
+      `mechanism-lookup` and `mechanism-sibling` clauses require an implementer
+      to look up every mechanism it is about to use and to record the siblings
+      when it establishes a rule.
+evidence:
+  - delivery/verification/u2-race-flake-investigation.md, defect D-3 and the structural-fix section
+  - delivery/review/clean-room-m1-p5-second.md, finding 1, with the reproduction
+  - delivery/work-history/m1-p5.md, fix-round section
+  - delivery/intake/orchestrated-delivery-v1.md section 9, the tuition flow

package/tuition/T-006.yaml

@@ -0,0 +1,81 @@
+# T-006: claimed impossibilities and claimed safety nets, written without
+# execution. Promoted from the delivering project's own log by M3-P8.
+kind: tuition
+version: 1
+id: T-006
+project: tiphys-kernel
+date: 2026-08-05
+stage: M1-P5 (watcher and liveness guard), across its fix rounds
+kernel-relevant: true
+what-happened: >-
+  Three times in one phase, a work history stated something about the world
+  that had never been executed: an arm that "cannot be forced", a case another
+  guard "already catches", a path that "recovers anyway". Each was written by an
+  implementer who had done real work, and each survived into a document a
+  reviewer was expected to trust. The orchestrator then did the same thing the
+  same day, reporting a remote as unreachable on the strength of a read
+  operation that says nothing about write access.
+lesson:
+  - >-
+      An impossibility claim, a coverage claim or a remedy claim must carry the
+      executed construction, or be restated as an open question.
+  - >-
+      The honest restatement costs nothing and is more useful: "I did not find a
+      way to force this arm" is true and invites the next reader to try, where
+      "this arm cannot be forced here" is false and closes the question.
+  - >-
+      A reminder does not survive a busy session. The mechanism is a grep over
+      the work history before it is submitted.
+mechanisms:
+  - mechanism: Reading a path whose type is not established
+    rule: >-
+      lstat the link, stat what it resolves to, open ONLY a regular file. A
+      block is not an exception, so try/catch does not touch it.
+    siblings:
+      - src/task.ts
+      - src/lock.ts
+      - src/pool.ts
+      - src/brief.ts
+      - src/hooks.ts
+    evidence:
+      - CR-520 and the four M1-P5 rounds
+      - delivery/verification/cr-520-orchestrator-reproduction.md
+  - mechanism: Atomic file replacement
+    rule: >-
+      Stage under a name no other pass can collide with. A fixed
+      `${path}.stage` lets two concurrent passes share one temporary; the loser
+      dies on ENOENT after advancing its seen state, dropping a signal in a
+      protocol whose rule is duplicate-rather-than-drop.
+    siblings:
+      - src/lock.ts
+      - src/watch.ts
+    evidence:
+      - M1-P5 round 4, verified pre-existing against a pristine build
+  - mechanism: Verifying access to a remote
+    rule: >-
+      `git push --dry-run` authenticates against receive-pack and updates no
+      ref. `clone` and `ls-remote` are READ operations and witness nothing
+      about write access.
+    evidence:
+      - delivery/tuition/T-006-unexecuted-claims-about-the-world.md, the orchestrator's own instance
+structural-consequence:
+  - target: schemas/work-history.schema.json
+    status: applied
+    change: >-
+      The shared claims[] section requires an executed construction beside any
+      impossibility, coverage or remedy claim, so the claim and its settlement
+      travel together.
+  - target: schemas/report.schema.json
+    status: applied
+    change: >-
+      The same claims[] definition is shared by the report contract, so a
+      review making an unexecuted claim is subject to the same rule as the work
+      it reviews.
+  - target: roles/implementer.md
+    status: applied
+    change: >-
+      The claim-grep clause carries the grep command verbatim, so hunting these
+      claims is a command rather than a habit.
+evidence:
+  - delivery/work-history/m1-p5.md, the three claims and their fix rounds
+  - delivery/review/clean-room-m1-p5-round4-hazard.md, the review that named the pattern

package/tuition/T-007.yaml

@@ -0,0 +1,56 @@
+# T-007: a phase met fifteen of fifteen executed acceptance criteria and still
+# live-locked every supervision command. Promoted by M3-P8.
+kind: tuition
+version: 1
+id: T-007
+project: tiphys-kernel
+date: 2026-08-05
+stage: M1-P5 (watcher and liveness guard), third dual review
+kernel-relevant: true
+what-happened: >-
+  Every one of a phase's fifteen acceptance criteria was walked and met, and the
+  delivered component still blocked forever on a named pipe at a path it read,
+  taking every supervision command with it. Two reviews ran on one head: the
+  criteria walk approved, and the hazard-framed review, given the question "what
+  can block, what can be lost, what can never exit", found the defect. The two
+  agreed on every mechanical fact; they disagreed on the verdict because they
+  were asking different questions.
+lesson:
+  - >-
+      Acceptance criteria inherit the blind spots of whoever wrote them, so a
+      criteria walk cannot find a defect the criteria could not express. "All
+      criteria met" is one input, never a terminal green.
+  - >-
+      A code phase needs two review CONTRACTS, not two reviewers, and the second
+      one must be a declared artifact rather than something the dispatch prompt
+      is trusted to remember.
+  - >-
+      The hazard question is derivable from the component's nature, which means
+      it belongs in the plan rather than in a prompt.
+structural-consequence:
+  - target: schemas/plan.schema.json
+    status: applied
+    change: >-
+      A phase declares its hazard-classes[] beside its acceptance criteria, so
+      the second review contract is derived from the plan rather than improvised
+      per dispatch.
+  - target: assurance-modes.yaml
+    status: applied
+    change: >-
+      review-contracts[] are declared per mode, so a mode says how many
+      contracts a review round carries and what each one asks.
+  - target: roles/clean-room-reviewer.md
+    status: applied
+    change: >-
+      The brief carries a review-contract field, so a reviewer knows which
+      contract it is executing and a hazard contract cannot be silently
+      dropped.
+  - target: checklists/hazard-review.yaml
+    status: ticketed
+    change: >-
+      The hazard contract gets its own checklist, so the second contract has
+      probes rather than only a framing.
+    record: delivery/plan/kernel-plan-m3.md, M3-P7
+evidence:
+  - delivery/review/clean-room-m1-p5-third-hazard.md and delivery/review/clean-room-m1-p5-third-criteria.md, the two verdicts on one head
+  - delivery/review/arbitration-m1-p5-third-round.md, the arbitration

package/tuition/T-008.yaml

@@ -0,0 +1,111 @@
+# T-008: the orchestrator supervised two agents with no beacon and no guard,
+# and lost nine hours. Promoted by M3-P8.
+kind: tuition
+version: 1
+id: T-008
+project: tiphys-kernel
+date: 2026-08-06
+stage: M1-P6, fifth review pass
+kernel-relevant: true
+what-happened: >-
+  Two review agents died within minutes of dispatch and the orchestrator did not
+  notice for nine hours and eleven minutes, while answering the owner and
+  dispatching other work throughout. Its supervision was "wait for a completion
+  notification", which is process liveness: a dead process sends no
+  notification, and no notification is indistinguishable from work in progress.
+  The first watchdog written after the incident then tested whether the report
+  file EXISTED, so it fired two minutes in, reported success, and said nothing.
+lesson:
+  - >-
+      Supervision is a freshness watchdog armed in the same turn as the
+      dispatch, never a wait for a completion notification.
+  - >-
+      Every dispatched agent writes its output incrementally, so its artifact's
+      mtime is a beacon and a death leaves a salvageable partial result.
+  - >-
+      A guard whose condition does not test the property that matters is green
+      and worthless, which is the red-witness rule one level up.
+mechanisms:
+  - mechanism: Supervising a dispatched agent
+    rule: >-
+      Supervision is a FRESHNESS watchdog armed in the same turn as the
+      dispatch, never a wait for a completion notification and never a probe of
+      process liveness (constraint C-2). The watchdog must test freshness, never
+      existence and never completion, must watch the union of the paths the
+      agent actually writes (measured, not predicted), and must exclude the
+      supervisor's own trees, because a watchdog that cannot go red is worse
+      than none.
+    siblings:
+      - src/watcher.ts
+      - src/liveness.ts
+    evidence:
+      - delivery/tuition/T-008-the-orchestrator-had-no-beacon.md, nine hours and eleven minutes measured
+      - delivery/tuition/T-014-the-watchdog-watched-the-wrong-place-six-times.md, six wrong applications of the same rule in one session
+  - mechanism: Parsing another program's reporter output
+    rule: >-
+      PIN the format as a controlled input rather than widening the parse. A
+      format-agnostic regex is a union of formats known on the day, and the
+      default already differs between the two toolchains this project runs.
+    siblings:
+      - src/gates/suite.ts
+    evidence:
+      - M1-P6 floor defect
+      - "`NODE_OPTIONS=--test-reporter=tap` scoped to the child"
+  - mechanism: Deciding what another program will do by pattern-matching the text of a file it consumes
+    rule: >-
+      A regex over a file and the consuming program's evaluation of that file
+      are DIFFERENT FUNCTIONS, so every finding is another input where they
+      differ, and rounds close instances forever. Three tiers instead, each
+      labelled by what enforces it: execute the extractable part against stubs;
+      PIN the accepted shapes and fail closed on anything else, never widen the
+      pattern; and where a denylist is unavoidable, DERIVE it by walking the
+      consuming program's closed documented vocabulary once, publishing the
+      walk. Name what remains unguarded rather than chasing it.
+    siblings:
+      - test/exit-test-local.test.ts
+      - test/m2-exit-test.test.ts
+    evidence:
+      - Four M1-P6 rounds, CR-640, CR-661, CR-681, CR-720 to CR-725
+      - the derived walk found two members no reviewer had named (`working-directory`, a custom `shell` template)
+      - "the widen-the-regex approach produced a guard that both missed real defangs and rejected `needs: [test, lint]`, an edit that STRENGTHENS the guarded property"
+  - mechanism: Asserting a CI step is wired
+    rule: >-
+      Assert BEHAVIOUR, not text. A text assertion catches deletion and misses
+      defanging. Extract the step and execute it against stubs. A witness for a
+      class must redden under at least two structurally different members.
+    siblings:
+      - test/exit-test-local.test.ts
+      - test/m2-exit-test.test.ts
+      - test/implementer-brief.test.ts
+    evidence:
+      - CR-640, CR-661, CR-681
+      - delivery/verification/cr-661-orchestrator-reproduction.md
+  - mechanism: A guard's own failure path
+    rule: >-
+      A guard whose correctness depends on a crash is not a guard. Make the
+      success path total, so removing the explicit failure is visible.
+    siblings:
+      - test/exit-test-local.test.ts
+    evidence:
+      - M1-P6 fix round 2, the D3 defang the implementer caught in its own fix
+structural-consequence:
+  - target: roles/implementer.md
+    status: applied
+    change: >-
+      The incremental-output and beacon-is-not-a-claim clauses make the beacon
+      an obligation of the dispatched agent and forbid reading its existence as
+      progress.
+  - target: roles/clean-room-reviewer.md
+    status: applied
+    change: >-
+      The same two clauses bind review agents, which is the half of the dispatch
+      contract this incident actually needed.
+  - target: AGENTS.md
+    status: ticketed
+    change: >-
+      The orchestrator's supervision section states the watchdog rule and the
+      three questions a dispatch turn answers in writing before arming one.
+    record: delivery/plan/kernel-plan-m3.md, M3-P9
+evidence:
+  - delivery/tuition/T-008-the-orchestrator-had-no-beacon.md, the measured nine hours and eleven minutes
+  - delivery/work-history/m1-p6.md, the phase running while the two agents were dead

package/tuition/T-009.yaml

@@ -0,0 +1,50 @@
+# T-009: main was red for four hours and twenty-one minutes while every pull
+# request check was green. Promoted by M3-P8.
+kind: tuition
+version: 1
+id: T-009
+project: tiphys-kernel
+date: 2026-08-07
+stage: M2 tail
+kernel-relevant: true
+what-happened: >-
+  The CI workflow fires on two events and they run different bundles: the pull
+  request event runs the strong bundle with a phase id derived from the head
+  ref, and a push to the default branch runs a main bundle with no phase. A
+  defect on the arm only one event takes was invisible to the other, so the
+  default branch stayed red across five consecutive push runs while every pull
+  request check was green, and four more merges landed on it. The owner
+  surfaced it, not the process.
+lesson:
+  - >-
+      A gate result is evidence only for the configuration it ran under. "CI is
+      green" is never a complete sentence: the complete sentence names the event
+      and the head sha.
+  - >-
+      A merge is not complete until the post-merge run on the new head is
+      observed to completion. Not the check on the branch: the run whose head
+      sha is the new tip.
+  - >-
+      Where behaviour forks on the CI event, BOTH arms need a witness. One
+      witnessed arm and one unwitnessed arm is the exact shape that broke here,
+      and the unwitnessed one is the one that broke.
+structural-consequence:
+  - target: schemas/report.schema.json
+    status: applied
+    change: >-
+      A reported gate result carries the event and the head it ran under, so a
+      green cannot be quoted outside the configuration that produced it.
+  - target: gate-registry.yaml
+    status: applied
+    change: >-
+      Every gate declares the CI events it runs on, so the two arms are data a
+      reader can compare rather than a property of a workflow file.
+  - target: AGENTS.md
+    status: ticketed
+    change: >-
+      The orchestrator's merge duty includes observing the post-merge run on the
+      new head before the phase is closed.
+    record: delivery/plan/kernel-plan-m3.md, M3-P9
+evidence:
+  - delivery/tuition/T-009-green-on-the-wrong-event.md, the five red push runs and the four merges
+  - delivery/work-history/m2-p9.md, the exit-test harness the incident ran through

package/tuition/T-015.yaml

@@ -0,0 +1,36 @@
+# T-015: a citation into a newest-at-top file rots on every append. Promoted
+# by M3-P8.
+kind: tuition
+version: 1
+id: T-015
+project: tiphys-kernel
+date: 2026-08-12
+stage: orchestrator paperwork, across one branch
+kernel-relevant: true
+what-happened: >-
+  A document that grows at the TOP moves every line below the insertion point.
+  A citation of the form path:line into such a file is therefore correct when
+  written and wrong after the next append, and it fails silently: the line still
+  exists, so the citation resolves, and it now points at something else. Four
+  instances were found in one branch, every one of them by re-running the check
+  after the final edit rather than by reading.
+lesson:
+  - >-
+      A positional citation into an append-at-top document decays on every
+      append, and the decayed form RESOLVES, so nothing reddens.
+  - >-
+      Prefer citing something that does not move, and where the positional
+      citation is the right one anyway, resolve it after the final edit and not
+      before.
+  - >-
+      The check that catches this is a re-run, not a reading.
+structural-consequence:
+  - target: gate-registry.yaml
+    status: proposed
+    change: >-
+      The citations gate's document globs reach only the delivery tree today.
+      Extending them to root-level authored files would put this region under
+      the same check as everything else; the change belongs to the phase that
+      owns the registry rather than to this record.
+evidence:
+  - delivery/tuition/T-015-a-citation-into-a-newest-at-top-file-rots-on-every-append.md, the four instances and the measurement