@a-company/paradigm 6.6.6 → 7.1.0

package/dist/team-25LK6CWM.js

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export{e as teamAcceptCommand,f as teamCheckCommand,d as teamHandoffCommand,g as teamHistoryCommand,b as teamInitCommand,a as teamModelsCommand,h as teamResetCommand,c as teamStatusCommand}from'./chunk-W4BW7GXA.js';import'./chunk-EG22HDXI.js';import'./chunk-DLMDHS2X.js';import'./chunk-FYDRENK7.js';import'./chunk-ECLUYHAR.js';import'./chunk-TYWB5IQJ.js';import'./chunk-YXLGVOZO.js';import'./chunk-XPPFILCM.js';import'./chunk-Y4XFVDZC.js';import'./chunk-MBPLJKE5.js';import'./chunk-EKZDFEJW.js';import'./chunk-LPBCQM5Y.js';import'./chunk-4GC35IFF.js';import'./chunk-JIXHEBGK.js';import'./chunk-ZJQY5PPP.js';import'./chunk-5TAVYPOV.js';

package/dist/team-funnel-RAJ6EDG3.js

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export{a as SOLO_REASONS,b as appendTeamFunnelEvent,c as readTeamFunnelEvents,d as summarizeTeamFunnel}from'./chunk-6HVOZANP.js';import'./chunk-5TAVYPOV.js';

package/dist/tools-GAU5WOEI.js

@@ -0,0 +1,2 @@
+#!/usr/bin/env node
+export{b as registerTools}from'./chunk-RDWWSQGH.js';import'./chunk-ZUAUFZRJ.js';import'./chunk-YQK3XU63.js';import'./chunk-OIYJUU6T.js';import'./chunk-VPNJL4LS.js';import'./chunk-KP5VOYAH.js';import'./chunk-M4UMM6DC.js';import'./chunk-B5KLSBOZ.js';import'./chunk-4UJ4NIEQ.js';import'./chunk-HSY75GRR.js';import'./chunk-RVXQNS6K.js';import'./chunk-3KVVC4WV.js';import'./chunk-KAUGQMXU.js';import'./chunk-Q527BPUF.js';import'./chunk-RGSFU2YW.js';import'./chunk-TMDPDIWA.js';import'./chunk-KLBH26PA.js';import'./chunk-XROULIQN.js';import'./chunk-GRZQIKST.js';import'./chunk-KAFQA7HV.js';import'./chunk-ACJWUOMA.js';import'./chunk-33ERV2MW.js';import'./chunk-CHSU6LTR.js';import'./chunk-EK4ZRIFJ.js';import'./chunk-JNSJVCTU.js';import'./chunk-ECO3LHCE.js';import'./chunk-5TAVYPOV.js';

package/dist/university-content/notes/N-para-801-cid-becomes-real.md

@@ -0,0 +1,60 @@
+---
+id: N-para-801-cid-becomes-real
+title: 'Lesson 5: Cid the Captain Becomes Real'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - captain-board
+  - cid
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+---
+
+## "The Captain Owns Nothing"
+
+Cid is the Captain archetype — responsible for navigation and coverage. But the audit's blunt finding was that *the Captain owned nothing and never did anything.* Session-open showed an anonymous static task dump (`context.ts:723-738`); session-close wrote a `.cid-briefed` marker unconditionally (`captain.ts:645`) regardless of what actually happened. Cid had a role with no artifact and no mutation — a job title with no job.
+
+The Spine (Lessons 1-3) gives Cid the thing he was missing: a durable, owned, writable artifact. v7 makes the Captain *real*.
+
+## `paradigm_captain_board` — Cid's Owned Surface
+
+A new MCP tool, `paradigm_captain_board`, gives Cid a read+write artifact with three actions (`read | claim | advance`):
+
+- **`read`** assembles the **live run-DAG** — epic tasks with their stage children ordered by `dependsOn` — plus a ripple-ranked list of `unclaimed` tasks and a summary. This is exactly what the Conductor task-dashboard renders.
+- **`claim`** and **`advance`** are **Cid's and only Cid's** write path for `claimant`, live status transitions, and run-record `runStatus`.
+
+For the first time, the Captain has a board to read and a board to write.
+
+## Session-Open: Propose Claimants
+
+At session-open, the anonymous task dump is replaced by a **Cid-attributed board read**. Cid runs the reaper, reads the board, ranks unclaimed tasks by ripple-risk (reusing the brief's ripple machinery), surfaces the top few, and **proposes claimants** — writing `claimant` and advancing `open → claimed` on the proposals.
+
+That write is the point. It is the durable proof the Captain did something this session. (Human or peer claims always override an archetype proposal — Cid proposes; people decide.) If the board read fails, Cid falls back safely to the plain task list — instrumentation never blocks the session.
+
+## Session-Close: Check the Loop, Self-Heal, Never Deadlock
+
+At session-close, the debrief gains real checks before it clears the Stop hook: did the run-record advance off `pending`? did claimed tasks change status (else release stale claims)? and — reading the `chainLive` liveness probe from Lesson 4 — **did postflight actually run?**
+
+Here v7 made a sharp correction. An early design had Cid *refuse to finish the session* if the learning chain hadn't run. The adversarial review flagged this as a **user-facing deadlock**: blocking a human from finishing their work because a *learning* step didn't fire inverts the priorities entirely. The fix:
+
+- If the chain didn't run, Cid **self-heals** — he runs postflight *himself* — rather than blocking.
+- If self-heal itself throws, Cid proposes only an **`advise`** block (`paradigm_propose_block({ claimant: 'navigation', severity: 'advise' })`) — **never `guard`.**
+
+A learning-loop gap must not deadlock a human. Hard refuse stays reserved for *correctness* gates (a missing `.purpose`), never learning-loop liveness.
+
+## The Cid ↔ Loid Boundary, in Tense
+
+The cleanest way to remember who writes what is **tense**:
+
+- **Cid writes the present tense** — `status` (live, up to but not including the work-completer's `done`), `claimant`, the DAG edges at emission, run-record `runStatus`. Cid is *what is happening now.*
+- **Loid writes the past tense** — `settledAt` and the learning stores. Loid is *what we learned from what already happened.*
+
+They never co-write a field, and the dependency points one way: `status → settlement → learning`. The old fake "→ Loid" prose handoff at session-close becomes a real, enforced boundary that Cid owns the front of and Loid owns the back of.

package/dist/university-content/notes/N-para-801-falsifiable-self-improvement.md

@@ -0,0 +1,66 @@
+---
+id: N-para-801-falsifiable-self-improvement
+title: 'Lesson 4: Falsifiable Self-Improvement'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - falsifiability
+  - chain-live
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+---
+
+## "Self-Improving" Is a Claim — Can You Break It?
+
+A system that *asserts* it is self-improving and a system that *is* self-improving can look identical from the outside, right up until you need the improvement and it isn't there. The deepest finding of the v7 audit was that Paradigm's "self-improving" claim was **unfalsifiable**: there was no test you could run that would fail if the learning loop were dead.
+
+A claim you cannot break is not a feature — it is marketing. v7's job in this lesson is to make "self-improving" *testable*: there must exist a deliberate action that turns the check red.
+
+## The Metric That Did Not Work: JPS
+
+The first attempt was **JPS** — journals-per-settlement: count journal entries written, divided by parent subtrees settled, over a trailing window. The intuition was that a healthy loop writes journals and a dead loop writes zero.
+
+The adversarial review killed it as **circular**. A clean run that legitimately produced no new insight ("silence is signal") and a *severed chain* both produce `JPS = 0`. The metric could not distinguish healthy quiet from a corpse. Measuring the **volume of output** can't tell you whether the **pipe** is alive.
+
+## The Probe That Works: `chainLive`
+
+The fix is to instrument the *pipe*, not the *output*. Each settlement now appends one record to `.paradigm/events/settlement-liveness.jsonl`:
+
+```jsonc
+{
+  "parentTaskId": "T-…",
+  "stages": { "recordWorkLog": "ok", "postflight": "ok", "promote": "skipped" },
+  "chainLive": true,         // every non-skipped stage returned ok
+  "journalsWritten": 0,      // diagnostic only — NOT the alarm
+  "promoted": 0
+}
+```
+
+Each stage of the chain is wrapped in its own try/catch, and the record is written in a `finally` block — so even a mid-chain throw still records *which* stage died. `chainLive` is true only if every non-skipped stage returned ok. The two cases are now distinguishable:
+
+- **Clean subtree:** `chainLive: true, journalsWritten: 0` — the pipe ran end-to-end and simply had nothing to promote. Healthy.
+- **Severed chain:** `chainLive: false` — a stage threw. Broken.
+
+## The `paradigm doctor` Check
+
+A new learning-loop-liveness check in `paradigm doctor` (and `/paradigm:health`) reads these records and alarms on `chainLive: false`. The alarm is *falsifiable by construction*: comment out `runPostflightLearning`, run a single settlement, and the check flips red, naming the dead stage. A reviewer can sever the chain on purpose and watch it scream.
+
+This is the v7 thesis in miniature. The old claim — "the framework improves itself" — was an assertion with no failing test behind it. The new claim is the same sentence, but now wired to a probe that *anyone* can break in thirty seconds and see fail. That is the difference between an asserted check and a true one.
+
+## Why This Pattern Generalizes
+
+The `chainLive` probe is a template for honest self-checking anywhere in Paradigm:
+
+1. **Instrument the pipe, not the output.** Liveness of the mechanism is falsifiable; volume of results is not.
+2. **Record per-stage in a `finally`.** A mid-pipe failure must still tell you *where* it died.
+3. **Make the red state reachable by a deliberate act.** If you cannot describe the exact change that turns the check red, the check is not really checking anything.
+
+A self-improving framework earns the adjective only if you can prove it *isn't* improving when it breaks. v7 makes that proof a one-line edit away.

package/dist/university-content/notes/N-para-801-honest-routing-and-the-method.md

@@ -0,0 +1,57 @@
+---
+id: N-para-801-honest-routing-and-the-method
+title: 'Lesson 6: Honest Routing & the Dogfood Method'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - classification
+  - adversarial-review
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+---
+
+## The Front Door: Honest Classification
+
+The Spine closes the *back* of the loop (work → learning). The "Front Door" fixes the *front*: getting any user's request to the right team without an expert driving the orchestrator by hand.
+
+The keyword classifier was rebuilt in v7 as **confidence-scored with intent-verb anchoring**. Three concrete fixes:
+
+- **The "bugfix poison-pill" is gone.** An audit of a *broken* system used to route to `[security, builder]` — i.e. the word "broken" silently summoned a fixer. New `audit` / `design` / `research` families map to **read-only analyst rosters that never route to a fixer.** Asking for an analysis no longer triggers an implementation.
+- **Misroutes are now visible.** Every mode response surfaces `{ type, confidence, alternativeType, overrideHint }`. A wrong classification is no longer silent — the user sees the second-best guess and how to override it.
+- **One authoritative classifier.** A second, divergent inline classifier is collapsed; `classification.type` is the single source of truth.
+
+## Full-Roster Routability
+
+The second front-door fix: the trigger-based `agent-matcher` becomes the primary roster/suggestion source, so specialists that were previously **unroutable by auto-orchestration** — `product` (North), `forge` (Loid), `researcher` (Scout), `dx` (Helix) — can now actually be assembled automatically, not only by a human naming them. The best agents being un-summonable was itself an audit finding: a team you cannot reach is a team you do not have.
+
+## The Method: Dogfooding the Cross-Check
+
+The most teachable thing about v7 is not any single feature — it is **how v7 was built.** Every claim above was caught, corrected, or confirmed *before it shipped* by Paradigm cross-checking itself. This is a Paradigm practice you should copy.
+
+### Step 1 — The self-audit (file-and-line evidence)
+
+v7 began with a two-slice self-audit: the task system, then the orchestration engine that runs every other audit. The discipline was **file-and-line evidence, not vibes.** "The learning loop is broken" is a vibe; "`task_done` at `task-loader.ts` feeds nothing — here is the dead joint" is a finding. Every claim was anchored to code you could open.
+
+### Step 2 — The adversarial review
+
+A designed spec is a *hypothesis*, not a fact. Before the learning wiring was built, an adversarial pass (the reviewer's job: try to *break* the design against the real code) caught **three keystone claims that were false or circular**:
+
+1. The belief-delta gate ran on **hardcoded** confidence numbers — promoting on the difference of two constants (Lesson 3 covers the honest fix).
+2. "Both worlds flow through `completeTask`" was **false** — the CLI orchestrator emits no tasks (scope was honestly narrowed to the MCP path).
+3. The JPS metric was **circular** — clean work and a dead chain both read zero (replaced by the `chainLive` probe, Lesson 4).
+
+Each finding flipped a "ship it" into a "revise first." The cost of catching them in review was a paragraph; the cost of shipping them would have been a framework that *claims* to self-improve on synthetic numbers — exactly the disease v7 set out to cure.
+
+### The lesson
+
+> A claim, even your own, is a hypothesis until something has tried to break it.
+
+This is why Paradigm pairs a builder with a *reviewer*, and a designer with an *adversarial* pass. The self-audit found the holes; the adversarial review kept the *fixes* honest. v7 is the framework eating its own dog food — and the practice generalizes: anchor claims to evidence, then assign someone to falsify them before you build. The check is only worth running if it can fail.

package/dist/university-content/notes/N-para-801-orchestration-emits-dag.md

@@ -0,0 +1,60 @@
+---
+id: N-para-801-orchestration-emits-dag
+title: 'Lesson 2: Orchestration Emits the DAG'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - orchestration
+  - agent-relay
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 7
+prerequisites: []
+category: paradigm-core
+---
+
+## The Graph That Used to Be Thrown Away
+
+When orchestration plans a multi-agent run, it computes a handoff graph: which agent goes first, which stages depend on which, how outputs flow forward. Before v7, that graph was *computed and then discarded* — the orchestration audit found it built at `orchestration.ts:1780-1830` and then dropped on the floor, with only a frozen `logOrchestration` blob recording `status: 'pending'` that nothing ever advanced.
+
+This was the orchestration-to-task disconnect: the engine knew the shape of the work but never wrote it down anywhere the rest of the framework could see. v7 fixes this by having orchestration **emit the DAG as real tasks**.
+
+## `emitTaskDag()`: Epic + Stage Children
+
+In `execute` mode (and only `execute` — `plan` and `quick` emit nothing), orchestration now calls a new `emitTaskDag()` at the point it builds its stage prompts. It persists:
+
+- **One epic task** — the orchestration root, with `claimant: orchestrator` and `external_ref: { kind: 'orchestration' }`.
+- **One child task per stage-agent** — each carrying `parentTaskId` (the epic), its `stage` ordinal, `dependsOn` (the resolved handoff edges), and a `claimant: { kind: 'archetype', ref: <role> }`.
+
+The frozen `status: 'pending'` blob is replaced by this live epic task. Emission **degrades gracefully**: if a task-write fails, the orchestration run still proceeds — emission is additive instrumentation, never a gate on the work.
+
+## Status Flows Back
+
+A DAG is only useful if the nodes' statuses stay current. v7 wires status back through the agents themselves: each spawned agent's prompt now carries its own `taskId` with instructions to flip the task to `in-progress` on start and `done` on finish (via `paradigm_task_update`). So the spine the orchestrator emits is the same spine the agents update as they work — and the same spine the learning loop settles on (Lesson 3).
+
+> **v7.0 scope note:** loop-closure is scoped to the **MCP path** — the dominant Claude-Code-agent path where agents drive `paradigm_task_*`. The Symphony (Cursor/peer) status-flow-back watcher, which maps `metadata.task.taskId → updateTask`, is a fast-follow. The standalone CLI `orchestrate` binary emits no tasks in v7.0; a thin `task-bridge` adapter is the planned fast-follow. The spec states this cost plainly rather than claiming coverage the code does not have.
+
+## The Typed Handoff: `AgentRelay`
+
+The DAG emission rides on a second v7 cleanup: the **typed agent handoff**. Before v7, agents handed off to each other in free-text prose, and a hand-rolled regex parser (`parseFilePlan` / `parseFilePlanFromResponse`) tried to scrape structure back out of that prose. v7 deletes those regex parsers entirely and replaces the prose with one typed contract:
+
+```typescript
+interface AgentRelay {
+  taskId?: string;
+  agent: string;
+  status: string;
+  artifacts: string[];
+  decisions: string[];
+  handoffTo?: string;
+  handoffContext?: string;
+  filePlan?: string[];     // now a typed field, consumed directly
+  blockedOn?: string;
+}
+```
+
+`TaskPayload` (the assignment) and `AgentRelay` (the completion) are the **request/response halves** of one exchange, kept separate and bound by an explicit map: `relay.taskId + status → updateTask`. Because `filePlan` is now a typed field, `planBuilderStages` consumes it directly — the brittle "parse my teammate's English" step is gone. Typed structure in, typed status out: that is the channel the loop closes over.

package/dist/university-content/notes/N-para-801-settlement-closes-the-loop.md

@@ -0,0 +1,64 @@
+---
+id: N-para-801-settlement-closes-the-loop
+title: 'Lesson 3: Settlement Closes the Loop'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - task-settlement
+  - learning-loop
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 8
+prerequisites: []
+category: paradigm-core
+---
+
+## The Dead Joint
+
+The learning loop was, in principle, a chain: a task finishes, the work is logged, a postflight pass extracts insights, and good insights are promoted into agent notebooks. In practice the audit found the very first link severed — `task_done` fed *nothing*. A task could complete and the learning chain would simply never run. Worse, the broken state looked exactly like the healthy state: no error, no missing file, just silence.
+
+v7 closes this with a new module, `packages/paradigm-mcp/src/utils/task-settlement.ts`, and one function: `settleParentIfComplete(rootDir, parentTaskId)`.
+
+## The Trigger: All Siblings Terminal
+
+The original design fired settlement only on `done`. An adversarial review (Lesson 6) caught that this re-creates the open-loop bug: one `shelved` sibling, a `blocked` sibling, or a crashed run would leave the parent unsettled *forever*. The corrected trigger is **all-siblings-terminal**:
+
+> When every task sharing a `parentTaskId` reaches a terminal state, the parent settles — exactly once.
+
+The terminal set is a forward-compatible predicate (`{ done, shelved, crashed }` in v7.0). The settlement hook is placed **inside `updateTask`** — the real chokepoint — gated on `isTerminal(status) && parentTaskId`. Putting it there means `completeTask`, `shelveTask`, and any direct status set all fire settlement; none can drift. Idempotency is guaranteed by stamping `settledAt` once.
+
+Two safety valves round it out:
+- **A reaper** crashes abandoned `in-progress` tasks that are stale past a time window (default 30 minutes) whose run is no longer live — so a dead run cannot wedge a subtree open, and the liveness probe (Lesson 4) still sees it.
+- **Orphan policy** — a child whose parent is missing self-settles and emits a `warn`.
+
+## The Wired Chain
+
+When a parent settles, it runs the learning chain — replacing every advisory-prose joint with a real call, in order:
+
+```
+recordWorkLog → runPostflightLearning → autoPromoteJournalEntries
+```
+
+(In the MCP world this also threads Cid's debrief and `sessionInsights`.) This is the moment the loop *actually closes*: completed work becomes a work-log entry, the postflight pass turns verdict patterns into journal entries, and proven journal entries are promoted into notebooks the agents read next session.
+
+## The Cid ↔ Loid Boundary
+
+Settlement only ever writes `settledAt` and crash markers — **never live status**. This is the load-bearing ownership rule of v7:
+
+> **Cid writes the present tense; Loid writes the past tense; they never co-write a field.**
+
+- **Cid** (the Captain) writes `status` live-transitions, `claimant`, and the DAG edges at emission.
+- **Loid** (intelligence officer) writes only `settledAt` — the retrospective trigger — plus everything in the learning stores (journals, notebooks, calibration). Loid is read-only on every other Task field.
+
+The dependency arrow points one way: `status → settlement → learning`. Settlement never calls back to change status. That one-way arrow is why the loop can close without two owners fighting over the same field — and it is the boundary the whole self-improving claim rests on.
+
+## Honest Confidence, Not Synthetic Belief-Deltas
+
+The settlement chain feeds notebook promotion, which gates on confidence. v7 made one honest cut here. The original plan promoted on a **belief-delta** (`confidence_after − confidence_before ≥ 0.15`), but the adversarial review proved both numbers were branch literals — promoting on the *difference of two constants* is numerology.
+
+v7.0's fix: keep the existing absolute `≥ 0.8` promotion gate, but make `confidence_after` **real** — agents emit an optional `confidence` value that `runPostflightLearning` prefers, falling back to the old literal only when absent. `confidence_before` stays in the type, now explicitly marked *not gated on*. The belief-delta gate is honestly deferred to v7.x (a real pre-task prior needs unbuilt elicitation infrastructure). Honest absolute-confidence learning now; belief-movement learning later — designed honestly rather than shipped on synthetic numbers.

package/dist/university-content/notes/N-para-801-the-task-dag.md

@@ -0,0 +1,93 @@
+---
+id: N-para-801-the-task-dag
+title: 'Lesson 1: The Spine — A Claimant-Owned Task DAG'
+type: note
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+  - task-dag
+  - claimant
+symbols: []
+difficulty: intermediate
+estimatedMinutes: 8
+prerequisites: []
+category: paradigm-core
+---
+
+## Why v7 Exists: Recording vs. Verifying
+
+Before v7, Paradigm *recorded that it was asked to do the right thing — but it did not verify that it did.* A two-slice self-audit (first the task system, then the orchestration engine) proved this with file-and-line evidence: the classifier misrouted silently, the best agents were not routable, the learning loop's broken state was byte-identical to its healthy state, enforcement checked invocation rather than work, and the Captain owned nothing.
+
+v7 — "Close the Loop" — makes the framework's own value proposition **true instead of asserted**. It does this with one keystone primitive:
+
+> A persisted, symbol-bound, **claimant-owned task DAG** that orchestration emits, whose completion feeds the learning loop, and which Cid the Captain manages.
+
+One primitive closes four problems at once: the open learning loop, the orchestration-to-task disconnect, Cid's inertness, and the unfalsifiability of "self-improving." This lesson covers the keystone itself — the Spine. (Decision **TD-2026-06-13-718**; design in `docs/specs/v7-close-the-loop.md`.)
+
+## The New Task Schema
+
+The `Task` interface in `packages/paradigm-mcp/src/utils/task-loader.ts` gained four families of fields in v7:
+
+```typescript
+export type ClaimantKind = 'archetype' | 'human' | 'peer';
+export interface Claimant { kind: ClaimantKind; ref: string; }
+
+export type TaskStatus =
+  | 'open' | 'in-progress' | 'done' | 'shelved';   // v7.0 ships 4 states
+
+export interface Task {
+  id: string; created: string;                 // immutable
+  blurb: string; priority: 'high'|'medium'|'low'; status: TaskStatus; tags: string[];
+  claimant?: Claimant;                          // typed claim — NOT a name string
+  parentTaskId?: string; dependsOn?: string[]; stage?: number;   // DAG edges
+  started_at?: string; completed?: string; settledAt?: string;   // lifecycle stamps
+  external_ref?: ExternalRef;                   // renamed from orphan session_link
+  related_lore?: string[];
+}
+```
+
+## The Claimant: A Typed Claim, Not a Name Tag
+
+The single most important design decision in the Spine is that ownership is a **tagged union**, not a flat assignee string:
+
+```typescript
+{ kind: 'archetype', ref: 'builder' }   // a role on the roster
+{ kind: 'human',     ref: 'matt@…' }    // a git user / email
+{ kind: 'peer',      ref: 'agent-7' }   // a Symphony peer agentId
+```
+
+A flat `assignee: "builder"` string cannot answer the questions the learning loop needs to ask. Is "builder" a role that any instance can fill, a specific human, or a remote peer? Those three carry completely different meaning:
+
+- **Archetype-fit signal** (v7.x analytics): comparing the *predicted* owner (`kind: archetype`) against the *closing* owner tells you whether auto-routing picked the right specialist.
+- **Reassignment-churn detection**: three claimant rewrites before a task settles flags a `spec-clarity` antipattern — the blurb was under-specified. But a *healthy* peer handoff (`kind: peer`) must be distinguished from churn, and only the typed `kind` lets you tell them apart.
+
+A name tag throws away the very distinction the loop is built to learn from. The typed claim is the difference between "someone touched this" and "this kind of owner closed this kind of work."
+
+## DAG Edges Without a Database
+
+The DAG is stored as an **edge-list-in-node**: each task's own YAML carries its `parentTaskId`, `dependsOn`, and `stage`. The graph is reconstructed simply by loading the node set — **no separate edges file, no SQLite.** This survives the existing date-partitioned task loader with zero loader changes, and cross-date edges still work because every task id embeds its date.
+
+- `parentTaskId` — points at the **epic** (the orchestration root) this stage child belongs to.
+- `dependsOn` — the resolved handoff edges (this stage waits on those stages).
+- `stage` — the ordinal position in the topologically-sorted handoff graph.
+
+## The `in-progress` Status and the State Machine
+
+v7.0 ships **four** states (`open | in-progress | done | shelved`); `claimed` and `blocked` are deferred to a fast-follow because they are justified only by Symphony peer-claims, which are themselves fast-follow. The transitions are enforced by a single `assertTransition` guard inside `updateTask`:
+
+```
+open        → in-progress | done | shelved
+in-progress → done | open | shelved
+shelved     → open
+done        → (terminal)
+```
+
+`started_at` is stamped the moment a task enters `in-progress`. `settledAt` is stamped only by the learning loop (covered in Lesson 3) — never by live status writes. That single ownership rule, "live state is written by one owner; the settlement stamp by another," is what keeps the loop honest.
+
+## Additive, Lazy-Healing Migration
+
+Every v7 field is **optional**, so old task YAML loads unchanged. The orphaned `session_link` field is healed into the typed `external_ref` by a read-side `normalizeTask` shim at the load chokepoint — files migrate on their next write, with no bulk migration step. MCP tool enums *widen* (non-breaking). The task system also gained its **first tests ever** in v7 — the audit found zero, and the Spine ships with 23 unit tests.

package/dist/university-content/paths/LP-para-801.yaml

@@ -0,0 +1,43 @@
+id: LP-para-801
+title: 'PARA 801: Closing the Loop (v7)'
+description: "Learn how Paradigm v7 makes the framework's own checks TRUE instead of asserted — by closing the orchestration and learning loop around one keystone: a persisted, claimant-owned task DAG that orchestration emits, settlement feeds back as learning, and Cid the Captain manages."
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+  - close-the-loop
+ordered: true
+category: paradigm-core
+steps:
+  - content: N-para-801-the-task-dag
+    required: true
+  - content: Q-para-801-the-task-dag
+    required: true
+    passRequired: true
+  - content: N-para-801-orchestration-emits-dag
+    required: true
+  - content: Q-para-801-orchestration-emits-dag
+    required: true
+    passRequired: true
+  - content: N-para-801-settlement-closes-the-loop
+    required: true
+  - content: Q-para-801-settlement-closes-the-loop
+    required: true
+    passRequired: true
+  - content: N-para-801-falsifiable-self-improvement
+    required: true
+  - content: Q-para-801-falsifiable-self-improvement
+    required: true
+    passRequired: true
+  - content: N-para-801-cid-becomes-real
+    required: true
+  - content: Q-para-801-cid-becomes-real
+    required: true
+    passRequired: true
+  - content: N-para-801-honest-routing-and-the-method
+    required: true
+  - content: Q-para-801-honest-routing-and-the-method
+    required: true
+    passRequired: true

package/dist/university-content/quizzes/Q-para-801-cid-becomes-real.yaml

@@ -0,0 +1,54 @@
+id: Q-para-801-cid-becomes-real
+title: 'PARA 801: Closing the Loop — Lesson 5: Cid the Captain Becomes Real'
+description: 'Quiz for lesson: Cid the Captain Becomes Real'
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+symbols: []
+difficulty: intermediate
+passThreshold: 0.7
+category: paradigm-core
+questions:
+  - id: q1
+    question: What durable artifact does paradigm_captain_board give Cid, and what are its actions?
+    choices:
+      A: A read-only console log; no actions
+      B: The live run-DAG (epic tasks with stage children ordered by dependsOn, plus ripple-ranked unclaimed) with actions read | claim | advance — Cid's and only Cid's write path for claimant, live status, and runStatus
+      C: A portal.yaml editor; actions add-gate | remove-gate
+      D: 'A notebook of past learnings; action: promote'
+      E: A SQLite dashboard with no write path
+    correct: B
+    explanation: 'paradigm_captain_board gives Cid an owned read+write artifact. `read` assembles the live run-DAG — epics with stage children ordered by dependsOn, plus ripple-ranked unclaimed — exactly what the Conductor task-dashboard renders. `claim` and `advance` are Cid''s and only Cid''s write path for claimant, live status transitions, and run-record runStatus. The audit''s "the Captain owns nothing" finding is resolved by giving him a board to write.'
+  - id: q2
+    question: At session-open, what does Cid now do that constitutes a real per-session mutation (replacing the old anonymous task dump)?
+    choices:
+      A: Nothing — session-open is still a static dump
+      B: He runs the reaper, reads the board, ranks unclaimed by ripple-risk, and proposes claimants by *writing* claimant and advancing open→claimed; that write is the durable proof the Captain did something (human/peer claims override his proposals)
+      C: He deletes all open tasks
+      D: He emails the roster to the user
+      E: He rebuilds the SQLite index
+    correct: B
+    explanation: 'Session-open replaces the anonymous static task dump with a Cid-attributed board read: he runs the reaper, ranks unclaimed tasks by ripple-risk, surfaces the top few, and proposes claimants by writing `claimant` and advancing open→claimed. That write is the durable proof the Captain acted this session. Human or peer claims override an archetype proposal, and a failed board read falls back safely to the plain list.'
+  - id: q3
+    question: 'At session-close, the learning chain didn''t run. What does Cid do — and what does he deliberately NOT do?'
+    choices:
+      A: He hard-blocks the session with a guard block until the human fixes the loop
+      B: He self-heals by running postflight himself rather than blocking; if self-heal throws he proposes only an `advise` block — never `guard`, because a learning-loop gap must not deadlock a human (hard refuse is reserved for correctness gates like a missing .purpose)
+      C: He silently ignores it and writes .cid-briefed unconditionally as before
+      D: He benches Loid
+      E: He deletes the settlement records
+    correct: B
+    explanation: 'An early design had Cid refuse to finish the session if postflight hadn''t run — the adversarial review flagged this as a user-facing deadlock (blocking a human over a *learning* step inverts priorities). The fix: Cid reads the chainLive probe, self-heals by running postflight himself, and if self-heal itself throws he proposes only an `advise` block (severity advise, never guard). Hard refuse stays reserved for correctness gates, never learning-loop liveness.'
+  - id: q4
+    question: The Cid↔Loid boundary is summarized in terms of tense. Which mapping is correct?
+    choices:
+      A: Cid writes settledAt and notebooks; Loid writes live status and claimant
+      B: Cid writes the present tense (live status, claimant, DAG edges at emission, runStatus); Loid writes the past tense (settledAt and the learning stores); they never co-write a field
+      C: Both write status; neither writes settledAt
+      D: Cid and Loid both write settledAt for redundancy
+      E: Loid writes everything; Cid is read-only
+    correct: B
+    explanation: 'Tense is the mnemonic: Cid writes the present tense — live `status` transitions (up to but not including the work-completer''s done), `claimant`, DAG edges at emission, and run-record runStatus (what is happening now). Loid writes the past tense — `settledAt` and the learning stores (what we learned from what already happened). They never co-write a field, and the dependency points one way: status → settlement → learning.'

package/dist/university-content/quizzes/Q-para-801-falsifiable-self-improvement.yaml

@@ -0,0 +1,54 @@
+id: Q-para-801-falsifiable-self-improvement
+title: 'PARA 801: Closing the Loop — Lesson 4: Falsifiable Self-Improvement'
+description: 'Quiz for lesson: Falsifiable Self-Improvement'
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+symbols: []
+difficulty: intermediate
+passThreshold: 0.7
+category: paradigm-core
+questions:
+  - id: q1
+    question: Why was the JPS (journals-per-settlement) metric rejected as a measure of whether the learning loop is alive?
+    choices:
+      A: It was too expensive to compute over a trailing window
+      B: It was circular — a clean run that legitimately produced no insight ("silence is signal") and a severed chain both yield JPS = 0, so it could not distinguish healthy quiet from a dead pipe
+      C: It double-counted journal entries
+      D: It required SQLite
+      E: It only worked in the CLI world
+    correct: B
+    explanation: 'JPS measures the *volume of output*, which cannot tell you whether the *pipe* is alive. A clean settlement that had nothing new to promote and a settlement whose chain was severed both produce JPS = 0. The metric could not separate healthy silence from a corpse, so v7 replaced it with the chainLive probe that instruments the pipe instead of the output.'
+  - id: q2
+    question: How does the chainLive liveness probe make "self-improving" falsifiable?
+    choices:
+      A: It counts how many notebooks exist
+      B: Each settlement appends a settlement-liveness.jsonl record with per-stage ok|threw|skipped (written in a finally so a mid-chain throw still records which stage died) and chainLive=true only if every non-skipped stage ran; a doctor check alarms on chainLive=false, which a reviewer can trigger by commenting out a stage
+      C: It asks the user to self-report whether they felt the framework improved
+      D: It measures token spend per session
+      E: It is not falsifiable; it just logs activity
+    correct: B
+    explanation: 'Each settlement writes a record to .paradigm/events/settlement-liveness.jsonl with each stage marked ok|threw|skipped, written in a finally block so a mid-chain throw still records *which* stage died. chainLive is true only if every non-skipped stage returned ok. A paradigm doctor / paradigm:health check alarms on chainLive=false — and a reviewer can comment out runPostflightLearning, settle once, and watch the check flip red naming the dead stage. That deliberate-break-turns-red property is what makes the claim falsifiable.'
+  - id: q3
+    question: 'A settlement records `chainLive: true, journalsWritten: 0`. What does this mean?'
+    choices:
+      A: The chain is broken — zero journals means a dead pipe
+      B: The pipe ran end-to-end successfully and simply had nothing new to promote — a healthy clean subtree ("silence is signal"); this is distinguishable from chainLive=false, which is the broken case
+      C: The settlement never ran
+      D: The agent crashed mid-task
+      E: Postflight was skipped intentionally by the user
+    correct: B
+    explanation: 'chainLive=true means every non-skipped stage ran without throwing — the pipe is alive. journalsWritten=0 is diagnostic only: it means there was nothing new worth promoting this time (silence is signal). This is precisely the case JPS could not distinguish from a dead chain; the chainLive probe separates healthy quiet (chainLive=true, journals=0) from a severed chain (chainLive=false).'
+  - id: q4
+    question: 'The chainLive design generalizes into a pattern for honest self-checks. Which principle best captures it?'
+    choices:
+      A: Measure the volume of results; more output means a healthier system
+      B: Instrument the pipe (liveness of the mechanism, falsifiable) not the output (volume, not falsifiable); record per-stage in a finally; and make the red state reachable by a deliberate act
+      C: Trust the agent's self-assessment of its own improvement
+      D: Only check the loop on a fixed schedule, never per settlement
+      E: Replace all checks with a single boolean the user sets manually
+    correct: B
+    explanation: 'The generalizable pattern: (1) instrument the pipe, not the output — liveness of the mechanism is falsifiable, volume of results is not; (2) record per-stage in a finally so a mid-pipe failure still tells you where it died; (3) make the red state reachable by a deliberate act — if you cannot describe the exact change that turns the check red, the check is not really checking anything. A self-improving claim is only earned if you can prove it ISN''T improving when it breaks.'

package/dist/university-content/quizzes/Q-para-801-honest-routing-and-the-method.yaml

@@ -0,0 +1,54 @@
+id: Q-para-801-honest-routing-and-the-method
+title: 'PARA 801: Closing the Loop — Lesson 6: Honest Routing & the Dogfood Method'
+description: 'Quiz for lesson: Honest Routing & the Dogfood Method'
+author: paradigm
+created: '2026-06-13'
+updated: '2026-06-13'
+tags:
+  - course
+  - para-801
+symbols: []
+difficulty: intermediate
+passThreshold: 0.7
+category: paradigm-core
+questions:
+  - id: q1
+    question: 'What was the "bugfix poison-pill" the v7 classifier rebuild removed?'
+    choices:
+      A: A bug that crashed orchestration on the word "fix"
+      B: An audit of a *broken* system used to route to [security, builder] — the word "broken" silently summoned a fixer; new audit/design/research families now map to read-only analyst rosters that never route to a fixer
+      C: A poisoned npm dependency
+      D: A SQL injection in the classifier
+      E: A hardcoded agent that always won
+    correct: B
+    explanation: 'The keyword classifier conflated *analyzing* a broken system with *fixing* it: an audit request containing "broken" routed to [security, builder], silently summoning an implementer. v7 rebuilt the classifier as confidence-scored with intent-verb anchoring, and new audit/design/research families map to read-only analyst rosters that never route to a fixer. Asking for analysis no longer triggers implementation.'
+  - id: q2
+    question: 'Besides fixing classification, what did v7 change about which agents auto-orchestration can reach?'
+    choices:
+      A: It removed all specialist agents to simplify routing
+      B: The trigger-based agent-matcher becomes the primary roster source, so previously-unroutable specialists (product/North, forge/Loid, researcher/Scout, dx/Helix) can now be assembled automatically — not only by a human naming them
+      C: It made every agent require manual selection
+      D: It limited orchestration to exactly three agents
+      E: Nothing — routability was already complete
+    correct: B
+    explanation: 'An audit finding was that the best agents were not routable by auto-orchestration. v7 makes the trigger-based agent-matcher the primary roster/suggestion source, so specialists like product (North), forge (Loid), researcher (Scout), and dx (Helix) can be assembled automatically. A team you cannot reach is a team you do not have.'
+  - id: q3
+    question: 'The v7 "dogfood method" had two stages. What were they, and what discipline anchored the first?'
+    choices:
+      A: Brainstorm then vote; anchored by consensus
+      B: A two-slice self-audit anchored by file-and-line evidence (not vibes), followed by an adversarial review that tried to break the design against the real code before it was built
+      C: Write code then test; anchored by coverage percentage
+      D: Survey users then ship; anchored by NPS
+      E: Design then document; anchored by word count
+    correct: B
+    explanation: 'Stage 1 was a two-slice self-audit (task system, then the orchestration engine) disciplined by file-and-line evidence — "the loop is broken" is a vibe; "task_done feeds nothing, here is the dead joint" is a finding. Stage 2 was an adversarial review whose job was to *break* the design against the real code before building it — treating even the team''s own spec as a hypothesis, not a fact.'
+  - id: q4
+    question: 'The adversarial review caught three keystone claims as false or circular. Which trio is correct?'
+    choices:
+      A: Missing tests, slow loader, and a typo in portal.yaml
+      B: The belief-delta gate ran on hardcoded confidence numbers; "both worlds flow through completeTask" was false (the CLI orchestrator emits no tasks); and the JPS metric was circular
+      C: The DAG used SQLite, the reaper never fired, and Cid hard-blocked sessions
+      D: The classifier was too slow, agents were unroutable, and notebooks were empty
+      E: There were no false claims; all three were confirmed correct
+    correct: B
+    explanation: 'The adversarial pass caught three keystone wiring claims false-or-circular against the real code: (1) the belief-delta gate ran on hardcoded branch-literal confidence numbers; (2) "both worlds flow through completeTask" was false — the CLI orchestrator emits no tasks, so scope was honestly narrowed to the MCP path; (3) JPS was circular — clean work and a dead chain both read zero. Each flipped a "ship it" into a "revise first." The generalizable lesson: a claim, even your own, is a hypothesis until something has tried to break it.'