P1: Phase 3: the typed adaptive loop — ledger, proposals, governance (goal line)

[macanderson]

Phase 3 — the typed adaptive loop. This is the goal line: the phase where "adaptive context is real". Ships behind context.lifecycle.enabled (default off).

Observable: Stella proposes durable context from evidence and explains why — "three separate tasks, here they are" — and Keep/Edit/Ignore is auditable afterward. The proposal that becomes a skill is reviewable before it lands, which is the part users cannot do today.

Why third — and read this before starting: this is a migration, not a build (spec §8). A live lexical loop already does this and users depend on it. It must not regress.

Blocked on ratifying ADR 0010 — see #711, decisions 1 and 2.

Deliverables

• 1. The lifecycle ledger. Append-only, immutable, hashed records for observations, proposals, and promotion events, born canonical per ADR 0010. No legacy rows are rewritten. New kinds have no legacy counterpart and therefore need no migration.
• 2. Typed observation extraction, replay-idempotent with cursors, secrets redacted before persistence, sourced from the evidence already captured — reflection lessons, citations, tool outcomes.
• 3. Proposal induction over the existing miner. Keep the clustering, the stable identity, and the thresholds. Add a durable, reviewable proposal record carrying its supporting observations, distinct-task count, and scored components. Distinct tasks, never raw events.
• 4. Migrate the skills loop onto the typed path, behavior-compatible. Existing skill files are untouched. The per-session cap, no-clobber, and two-surface tombstone filtering all survive — asserted by test, not by inspection.
• 5. Wire the dead rules miner through the same path. Its twin has shipped unwired since the shared clustering module was created to keep them aligned.
• 6. Solo advisory governance. Immutable promotion events; inferred directives start advisory and can never start blocking; no automatic sharing or scope widening; a re-proposal cooldown so a declined proposal does not return next turn.
• 7. Review surface. List proposals with their evidence; Keep, Edit, or Ignore; every outcome recorded as an immutable event.

Gate

• Three distinct tasks produce one eligible proposal; thirty repetitions inside one task produce none.
• No inferred directive reaches blocking by any path.
• No sharing or scope widens without an explicit act.
• A tombstoned lesson still cannot return as a proposal or a skill.
• Existing skill files are byte-identical after migration.
• Keep/Edit/Ignore replay identically from the event log.
• Mining failure cannot fail the user's task.

Risk

The behavior-compatibility obligation is the whole risk. A typed loop that regresses forget/restore is a worse product than the lexical one it replaces. Every guarantee in spec §8 gets a test before the migration lands, not after:

• tombstone suppression across re-learning, on every surface
• the per-session creation cap
• never clobbering a hand-edited file
• deterministic, stable candidate identity
• failure isolation — mining never fails the user's task

---

Blocked by Phase 2 and by #711 (decisions 1 and 2). Blocks Phase 4. Plan: docs/design/adaptive-context-plan.md § Phase 3. Part of Epic #469.

[macanderson]

Unblocked, and being built in parallel with Phase 2.

This issue says "Blocked by Phase 2 and by #711." Both halves of that have now moved:

• P0: Adaptive context: maintainer decisions gating the four-phase plan #711 is closed. All four decisions are resolved and ADR 0010 is ratified (Proposed → Accepted), which was the hard blocker named at the top of this issue.
• The Phase 2 dependency is a product-ordering argument, not a code dependency. The plan's stated reason for putting the accountable frame second is that "accountability is the prerequisite for trusting anything adaptive" — a sequencing rationale about what users should be able to see first. Checked deliverable by deliverable, nothing in Phase 3 reads anything Phase 2 produces: the observation extractor (deliverable 2) sources from reflection lessons, citations, and tool outcomes, all of which are captured today and none of which are the decomposed recall blocks Phase 2 emits. Phase 4 is the phase that genuinely needs both — it needs the frame to know what was used and the ledger to have something to attribute to.

So Phase 3 is being built concurrently with Phase 2 on a separate branch.

What that cost. The two phases are disjoint in deliverables but not in files. Three shared files would have collided in ways a textual merge resolves wrongly:

File	Phase 2	Phase 3	Hazard
stella-cli/src/memory.rs	the recall half	the learning half	Both rewrite opposite halves of one file and meet in SessionMemory — merges clean, still wrong
stella-cli/src/main.rs	inspect surface	a context command group	Sat at exactly its ratchet ceiling, zero headroom
both migration ladders	store.db slot	store.db + context.db slots	SCHEMA_VERSION = MIGRATIONS.len() over an index-ordered array — two branches each appending "the next slot" merge into a broken ladder without complaint

Those are addressed by a prelude PR (#733) that both branches build on: memory.rs split along the recall/learning seam, main.rs brought under its ceiling so its baseline entry could be deleted rather than raised, and migration slots reserved by comment at both append points. It is a pure move — verified by diffing the generated clap help for every affected command, byte-for-byte identical.

Ownership is assigned per file so the two branches touch disjoint sets, with the unavoidable shared files (SessionMemory fields, settings/context.rs, context_event.rs) marked inline with the owning phase.

Correction worth recording here: the plan and ADR 0010 decision point 6 both say Phase 1 landed lineage_id on memory and episode. In the tree it landed on memory only — migrate_v5 alters one table and there is no ALTER TABLE episode anywhere. Phase 3 resolves the discrepancy in one direction or the other and will flag which.