Kalsa/workshop/deepening

Institutional Deepening Contract

This directory owns the critique-and-repair process. It does not own lore. Canonical claims live under Kalsa/; these records explain why and how an owner note changed.

Pass Contract

One pass addresses one bounded institution, region, practice, or cross-cutting system. Copy pass-template.md into a dated pass file before editing canon.

A pass must:

1. Select a target with a named canonical owner or explicitly record that the missing owner is the defect.
2. Inventory seed evidence, adopted claims, provisional design, contradictions, rumors, deprecated material, and unknowns without blending their authority.
3. Model owner, allowed inputs, outputs, dependencies, beneficiaries, costs, failure modes, enforcement limits, and interfaces.
4. Critique generic fantasy defaults, missing material constraints, false consensus, absent subordinate perspectives, and consequences that stop at the page edge. Assemble an immutable packet and collect independent baseline reports from every active Critic in the [[../review-council/README|Lore Review Council]]. Before the first report, run the phase-boundary intake check against that packet. Record which seats are Guardians and whether any sanity trigger applies.
5. Adjudicate every substantive council finding as accepted, modified, rejected, or deferred. Preserve raw disagreement; do not vote lore into existence or give reports directly to a repair writer.
6. Repair the smallest coherent set of canonical owner notes. Delete or demote duplicate owners before adding compensating prose.
7. Connect the repair to people, places, events, resources, language, magic, and playable pressure.
8. Falsify the result through at least one hostile or marginal perspective and one historical stress case.
9. Regress the repaired candidate through every active Critic and route its exact change packet through every relevant Guardian. Reader Experience receives a fresh blind packet. A Guardian receives only changed notes and their diff/context unless its periodic or early sanity trigger requires a full-surface packet.
10. Verify seed hashes, wikilinks, publication boundaries, the Quartz build, affected rendered pages, and the actual git diff.
11. Record the result in ledger.md, update queue.md, and promote only a durable operating lesson or decision into .epiphany/project-memory.md. Run the phase-boundary intake check again against the exact final packet before closing the pass.

Phase-Boundary Intake

Set intake_base_commit in the pass frontmatter to the full commit at the start of the pass, before pass work or adjacent proposals arrive. Frozen review packets must contain a complete raw SHA-1 Markdown manifest.

Before review and before closure, run:

.\scripts\lore\check-phase-boundary-intake.ps1 `
  -Boundary review `
  -PacketPath workshop/deepening/reviews/KALSA-000/baseline-packet.md `
  -PassPath workshop/deepening/passes/KALSA-000-example.md

.\scripts\lore\check-phase-boundary-intake.ps1 `
  -Boundary closure `
  -PacketPath workshop/deepening/reviews/KALSA-000/repaired-packet.md `
  -PassPath workshop/deepening/passes/KALSA-000-example.md

The checker reads Git history since the pass boundary plus staged, unstaged, and untracked Markdown. It recognizes proposal or handoff notes by a filename token or frontmatter status, type, owns, or exact tag. A matching current hash in the packet is sufficient. An out-of-packet note blocks until the pass's Phase-boundary intake table records defer with a named destination or reject with a concrete reason. The checker reports only; it never edits the packet, pass, queue, or canon.

Completion Standard

A pass is complete when the repaired system produces more specific downstream consequences without leaving split authority, erasing the seed witness, or requiring workshop prose to explain the canonical note.

Word count, heading count, and link density are useful pressure gauges. They do not certify depth. The qualitative parity standard lives in benchmark.md.

Required Evidence

• source paths and exact seed witnesses read;
• canonical owner notes changed;
• authority map before and after;
• unresolved questions and explicit non-decisions;
• hostile/marginal and historical stress findings;
• immutable review-packet identity, active-Critic raw reports, finding dispositions, repair brief, active-Critic regression reports, required Guardian change or sanity reports, and updated Guardian counters;
• the pass-start intake commit and successful review/closure intake checks, including explicit dispositions for changed proposal or handoff notes left outside the frozen packet;
• verification commands and results;
• rendered-page inspection when published content changed.

If timing, interaction, or runtime behavior matters to a Ghostlight contract, verify that path in Ghostlight's owning repository rather than inventing a lore proxy here.