canon: add runtime method docs (persona-shaped + runtime-contract) + journals

canon/constraints/mode-transitions-require-encoded-handoff.md

@@ -10,7 +10,7 @@ tags: ["canon", "constraints", "epistemic-modes", "handoff-contract", "journal",
 epoch: E0008.5
 date: 2026-05-10
 derives_from: "canon/principles/sessions-mirror-modes.md, canon/definitions/epistemic-modes.md, canon/constraints/critic-cannot-be-resolver.md, canon/principles/verification-requires-fresh-context.md"
-complements: "canon/methods/persona-shaped-agent-runtime.md, docs/mode-separated-conversations.md, docs/oddkit/proactive/oldc-h-vocabulary.md"
+complements: "canon/methods/persona-shaped-agent-runtime.md, docs/mode-separated-conversations.md, canon/definitions/dolcheo-vocabulary.md"
 governs: "Every transition between epistemic modes — exploration, planning, execution, validation, resolution — across all surfaces (agent runtime, human conversation, mixed teams)"
 status: proposed
 ---
@@ -27,7 +27,7 @@ Every legitimate transition between epistemic modes produces two artifacts:
 
 ### 1. Journal Entry — Universal, No Exception
 
-Every transition produces a journal entry recording what happened. The format is DOLCHEO+H per [the canonical vocabulary](klappy://docs/oddkit/proactive/oldc-h-vocabulary): observations, learnings, decisions, constraints, encodes, handoffs. The journal entry captures:
+Every transition produces a journal entry recording what happened. The format is DOLCHEO per [the canonical vocabulary](klappy://canon/definitions/dolcheo-vocabulary): decisions, observations, learnings, constraints, handoffs, encodes, opens. The journal entry captures:
 
 - The mode transition itself (from → to, with timestamp)
 - What was completed in the prior mode (obligations met)
@@ -81,6 +81,53 @@ Both reversion and skip require the journal entry. Neither is a free move. The d
 
 ---
 
+## Operator Override — Explicit Mode Collapse Under Urgency
+
+A third escape mechanism, distinct from reversion and skip. An operator can declare a runtime override that collapses one or more mode boundaries into a single session — typically when urgency outweighs the cost of corruption. Like reversion and skip, the override requires explicit acknowledgment and a durable record.
+
+### What an Override Is
+
+A runtime-level declaration by the human operator that one or more mode boundaries will be deliberately collapsed for the current session. The operator names the collapse, states the reason, and acknowledges the corruption being accepted. The runtime records the override in the journal at session start, applies relaxed constraints for the session's duration, and records the actual work done in the journal at session end.
+
+This differs from skip: a skip declares that a mode will not be entered at all. An override declares that multiple modes will be collapsed into a single session — work happens, but without the gate boundaries between modes. The corruption mode is also different: a skip means the mode's signal is missing entirely; an override means the mode's signal is produced under conditions that compromise its quality.
+
+### What an Override Requires
+
+- **Explicit declaration.** Override cannot be implicit. The operator names which boundaries are being collapsed: *"collapse exploration through validation in this session"* or *"collapse all five modes in this session."*
+- **Stated reason.** Why urgency outweighs discipline. The reason need not be elaborate but must be specific enough to be auditable later — *"production incident; we need a working patch in the next thirty minutes"* is sufficient. *"In a hurry"* alone is not.
+- **Acknowledged risks.** The operator names the corruption modes being accepted. For an override that collapses execution and validation, this is *"the validator will share context with the builder, and findings will be biased toward what the builder's framing made visible."*
+- **Journal entry at session start** naming all of the above.
+- **Journal entry at session end** naming what actually happened — what was built, what was validated under the override, what was skipped, what tradeoffs materialized in practice.
+
+### Worked Use Cases — When the Override Earns Its Keep
+
+Two categories where operator override is operationally legitimate, not a degradation of discipline:
+
+**Production incidents.** A bug landed in production; the patch needs to ship in the next thirty minutes. The cost of moving through five clean sessions with handoffs at each gate exceeds the cost of context corruption — production downtime is not an acceptable tradeoff for epistemic hygiene at this moment. The operator declares the override, names the incident, acknowledges that the validator will share context with the builder, and accepts the corruption. The journal entries make the corruption visible later, so any code shipped under override gets flagged for proper post-incident review.
+
+**Governance creation.** Authoring canonical principles, constraints, and methods is inherently oscillating work. A draft principle implies a constraint; drafting the constraint surfaces a refinement to the principle; the refinement reveals an unexamined assumption that needs an exploration pass. The work moves between modes faster than handoff norms can encode. Until handoff norms catch up — until a project has been through enough governance-creation cycles to know which dynamic types its synthesis ledgers must capture — this category may regularly justify override. The signal is not that discipline is being abandoned; the signal is that the encoding norms are still maturing. An override-with-record produces governance with full audit trail of *how the governance was made*; clean sessions with poor handoffs would produce governance whose drafting context died at every gate.
+
+The honest framing: the architecture's value depends on handoffs being good enough to preserve what would have transferred in shared context. For categories of work where the encoding norms are still being learned, override-with-record is the correct operational response — not a permanent retreat, but a stopgap until norms catch up. The aspiration is that with explicit handoffs and forced same-branch work, encoding eventually becomes detailed enough that clean sessions become *transient, ephemeral, and transparent to the operator* — but reaching that state requires contact with reality, including the experience of trying and failing to encode well.
+
+This use case is itself a worked example: this constraint document was drafted in a single collapsed session under operator-acknowledged override, because the explorer-planner-builder-validator-resolver oscillation was faster than the handoff norms could yet capture. The journal entries record the override; future iterations will improve the handoff norms; eventually governance creation may be doable in clean sessions. Until then, override is the rational choice.
+
+### What an Override Is Not
+
+- Not the `general` role escape hatch. The general role is a planned escape declared at persona-profile authoring time. The operator override is a reactive escape declared at session-invocation time. Different declaration point, different audit trail.
+- Not transferable. An override applies only to the session it was declared for. Subsequent sessions do not inherit the override; if the urgency persists across sessions, each session gets its own override declaration.
+- Not absolute. The operator can override gate transitions but cannot override the journal entry requirement itself. The override is the journal-worthy event; the journal entry is what makes the corruption visible later.
+- Not a free pass for routine convenience. The override is for genuine urgency — production incidents, time-bounded operational decisions, situations where the cost of waiting exceeds the cost of corrupted signal. An override invoked routinely degrades the project's epistemic record over time.
+
+### The Cost
+
+An override produces a session whose epistemic record is corrupted by design. Future work that depends on this session's output should be aware of the corruption. The journal entry serves this purpose — downstream readers can see that the session was operator-overridden and apply appropriate skepticism to the outputs.
+
+The discipline of recording the override is what allows the corruption to be visible later. A session that collapsed modes silently produces unfalsifiable history. A session that collapsed modes with a recorded override produces history that *knows* it is corrupted, which is recoverable.
+
+The override is therefore not a violation of this constraint. It is a third permitted deviation, treated identically to reversion and skip: allowed with explicit acknowledgment, accompanied by a durable record, and accountable to its costs.
+
+---
+
 ## Operational Enforcement
 
 This constraint is enforceable at three layers:
@@ -117,9 +164,27 @@ This is a consumer pattern, not a runtime feature, and it is documented separate
 
 ---
 
+## Handoff Quality Is a Separate Discipline
+
+This constraint codifies the *requirement* for encoded handoffs at every transition. It does not codify *quality*, and cannot. A handoff that satisfies the minimum content requirement above can still be insufficient — shallow encoding, lossy capture of dynamic context, missing the unwritten-but-obvious knowledge the prior session held implicitly. The constraint ensures the artifact exists; it does not ensure the artifact is good.
+
+This is a meaningful gap. Per [Sessions Mirror Modes §Failure Modes](klappy://canon/principles/sessions-mirror-modes), the architecture's cost only pays back when handoffs preserve what would naturally transfer in shared sessions. Bad handoffs produce sessions operating on distorted input — worse than the mode-collapse the architecture was meant to replace. The constraint can require presence; the project's encoding norms have to deliver quality.
+
+Three specific places this gap matters:
+
+- **Minimum-met-but-thin handoffs** pass this constraint's check but fail the principle's purpose. Format-correct, content-poor. The constraint cannot detect this; downstream review and audit-trail patterns can.
+- **Missing dynamic types** are the most common failure — settled decisions get encoded, live tensions and considered-rejected paths do not. The minimum-handoff list above does not require encoding these explicitly; projects that find their handoffs routinely losing dynamic context should extend their local handoff norms to require it.
+- **Missing crucial context that felt obvious to the encoder** is the highest-cost failure. The encoder had it; they did not write it down because encoding it felt like overhead. The receiving session in fresh context does not have it. The constraint's minimum cannot anticipate which context will feel obvious; this gap closes only through observed failures and norm refinement.
+
+The constraint's role here is operational: it makes encoding the work, surfaces gaps when receiving sessions cannot proceed, and preserves audit trails of insufficient handoffs. It does not — and cannot — guarantee the encoding captures what matters. That is upstream of any constraint, in the encoding norms a project develops over time.
+
+A receiving session that cannot proceed on a handoff has the right to refuse with a structured signal — *"this handoff is insufficient; specifically X is missing"* — distinct from disagreement with the handoff's content. The runtime can support this signal as a first-class outcome (see [Persona-Shaped Agent Runtime](klappy://canon/methods/persona-shaped-agent-runtime)). The constraint requires the handoff exists; the runtime feature requires the receiving session can refuse it when it is not enough.
+
+---
+
 ## Confidence
 
-**Working belief.** The journal-entry requirement extends an already-canonical practice (DOLCHEO+H entries on every session per [oldc-h-vocabulary](klappy://docs/oddkit/proactive/oldc-h-vocabulary)) to mode transitions specifically. The transition-specific handoff requirements extend already-canonical practice for individual transitions (P0008 for validator deliverables, plan documents for execution work, etc.) into a uniform contract.
+**Working belief.** The journal-entry requirement extends an already-canonical practice (DOLCHEO entries on every session per [the dolcheo-vocabulary](klappy://canon/definitions/dolcheo-vocabulary)) to mode transitions specifically. The transition-specific handoff requirements extend already-canonical practice for individual transitions (P0008 for validator deliverables, plan documents for execution work, etc.) into a uniform contract.
 
 **Retraction conditions:**
 
@@ -135,7 +200,7 @@ This is a consumer pattern, not a runtime feature, and it is documented separate
 
 - [Sessions Mirror Modes](klappy://canon/principles/sessions-mirror-modes) — the principle this constraint operationalizes
 - [Epistemic Modes](klappy://canon/epistemic-modes) — the parent canon defining the modes whose transitions this constraint governs
-- [DOLCHEO+H Vocabulary](klappy://docs/oddkit/proactive/oldc-h-vocabulary) — the journal entry format required at every transition
+- [DOLCHEO Vocabulary](klappy://canon/definitions/dolcheo-vocabulary) — the journal entry format required at every transition
 - [Verification Requires Fresh Context](klappy://canon/principles/verification-requires-fresh-context) — the principle motivating the encoded handoff for execution → validation specifically
 - [Critic Cannot Be Resolver](klappy://canon/constraints/critic-cannot-be-resolver) — the constraint motivating the encoded handoff for validation → resolution specifically
 - [P0008 — Fresh-Validator Deliverable Is a DOLCHEO Ledger](klappy://docs/promotions/P0008-pr-validator-dolcheo-ledger-as-deliverable) — the operationalized handoff pattern for the validator role

canon/definitions/epistemic-modes.md

@@ -7,8 +7,8 @@ tier: 1
 voice: neutral
 stability: semi_stable
 tags: ["epistemology", "decision-making", "governance"]
-epoch: E0008.3
-date: 2026-04-18
+epoch: E0008.5
+date: 2026-05-10
 ---
 
 # Epistemic Modes
@@ -207,6 +207,10 @@ Skipping modes is allowed only when explicitly acknowledged.
 
 For practical guidance on mode transitions in conversation, see **Mode-Separated Conversations**.
 
+For the principle that each mode earns its own session, see [Sessions Mirror Modes](klappy://canon/principles/sessions-mirror-modes).
+
+For the binding rule that every transition requires a journal entry plus a transition-specific durable handoff artifact, see [Mode Transitions Require Encoded Handoff](klappy://canon/constraints/mode-transitions-require-encoded-handoff).
+
 ---
 
 ## Legitimacy of Inaction