Clarify Epiphany MVP role coordination

notes/epiphany-fork-implementation-plan.md

@@ -149,7 +149,7 @@ The next unknowns are:
 
 - how the landed watcher-backed invalidation telemetry should be consumed without turning freshness into a secret worker
 - how far the read-only CRRC recommendation should go before explicit client/operator action takes over
-- how much specialist ergonomics can improve before crossing into broad ambient scheduling
+- how much narrow role coordination is needed so modeling, implementation, verification, and CRRC can hand off work without collapsing back into one context
 - what concrete operator friction appears when the CLI MVP is tested on real work
 
 ## MVP Cutline
@@ -176,9 +176,11 @@ can prove the product thesis on real coding work:
 
 The MVP should include narrow specialists and a bounded CRRC coordinator because
 those are central to the design. It should not include an arbitrary specialist
-marketplace, broad ambient scheduling, automatic promotion of every tool
-observation, a GUI-first workflow, or a second job backend unless the current
-`agent_jobs` seam blocks the product loop.
+marketplace, broad ambient dispatcher, automatic promotion of every tool
+observation, a GUI-first workflow, or an alternate job backend for the MVP. The
+useful scheduler-shaped thing is narrower: an auditable role coordinator that
+keeps the fixed single-user lanes in sequence, makes handoffs explicit, and
+preserves operator review and interruption.
 
 The read-back, acceptance, coordinator, first dogfood-view, first
 harness-native role ownership, and first fixed role specialist launch/result
@@ -207,7 +209,7 @@ Useful candidates:
 
 1. Put the CLI MVP in front of a human operator through status/artifact review, then fix concrete usability blockers.
 2. Keep accepted worker findings review-gated; do not convert acceptance into automatic promotion of arbitrary worker output.
-3. Add targeted operator-view fields only when dogfooding exposes a real gap.
+3. Design the smallest fixed-lane role coordinator that can recommend or launch the next modeling, implementation, verification, or CRRC handoff without becoming a broad ambient dispatcher.
 
 Do not spend Phase 6 polishing Phase 5 out of anxiety. The Phase 5 smoke harness
 is a regression guardrail, not a ritual drum circle for summoning more tiny
@@ -220,7 +222,7 @@ These remain later work:
 - watcher-driven semantic invalidation
 - automatic observation promotion from tool output
 - richer evidence and graph-shard inspection beyond the landed targeted context read
-- role-scoped specialist-agent registry and scheduling
+- richer role ergonomics after the fixed single-user coordinator proves useful
 - mutation gates that warn or block broad writes when map freshness is stale
 - automatic CRRC runtime coordination on top of the landed typed context-pressure telemetry
 - GUI workflows for graph, evidence, job, invariant, and frontier steering

notes/fresh-workspace-handoff.md

@@ -280,8 +280,12 @@ inspected the smoke workspace, called `report_agent_job_result`, and
 The CLI MVP is now testable. Put it in front of a human operator through
 `tools/epiphany_mvp_status.py`, `.epiphany-dogfood/mvp-loop`, and
 `.epiphany-dogfood/live-specialist`. Fix concrete blockers in that operator
-loop; do not build a broad hidden scheduler, marketplace, or
-GUI-as-source-of-truth.
+loop. The next likely organ is a narrow auditable role coordinator for the
+fixed single-user lanes: modeling/checkpoint tells implementation where the map
+says to look, verification/review tells modeling where the map is insufficient
+or stale, and CRRC decides when continuity has broken enough to regather. Do not
+turn that into a broad hidden dispatcher, arbitrary marketplace, alternate job
+backend, or GUI-as-source-of-truth.
 
 Live `thread/epiphany/scene`, `thread/epiphany/jobs`, `thread/epiphany/roles`,
 `thread/epiphany/freshness`, `thread/epiphany/context`,
@@ -293,7 +297,7 @@ guardrails, not the next organs.
 
 - automatic watcher-driven semantic invalidation
 - automatic observation promotion
-- broad specialist-agent scheduling beyond explicit roleLaunch
+- broad specialist-agent scheduling beyond the fixed single-user role lanes
 - GUI-as-source-of-truth
 - automatic runtime CRRC execution acting on the landed recommendation/verdict and launch/read-back path
 - Epiphany-owned long-running job execution beyond the current runtime `agent_jobs` seam

state/evidence.jsonl

@@ -57,3 +57,4 @@
 {"ts": "2026-04-28T14:48:10+00:00", "type": "implementation", "status": "ok", "note": "Landed explicit thread/epiphany/roleLaunch and read-only thread/epiphany/roleResult for fixed modeling/checkpoint and verification/review specialists over the existing job-control seam. Launch mutates only jobBindings; result projects reviewable findings without mutation. Focused protocol/app-server tests, schema fixtures, app-server build, and tools/epiphany_phase6_role_smoke.py passed."}
 {"ts": "2026-04-28T15:32:47+00:00", "type": "implementation", "status": "ok", "note": "Ran the first auditable Epiphany MVP dogfood pass through state, modeling/verification roleLaunch/roleResult, CRRC drift, reorientLaunch/reorientResult/reorientAccept, final status rendering, and a read-only Vanilla Codex reference. Dogfood artifacts live under .epiphany-dogfood/mvp-loop. The pass exposed and fixed a concrete operator-loop blocker: after reorientAccept, CRRC no longer recommends accepting the same completed reorientation finding again; it recognizes the accepted evidence and recommends regatherManually for accepted regather findings."}
 {"ts": "2026-04-28T16:33:43+00:00", "type": "implementation", "status": "ok", "note": "Landed live-specialist MVP execution: internal agent_job workers now expose report_agent_job_result independently of the CSV front door, ephemeral workers can initialize sqlite state runtime on demand, and tools/epiphany_mvp_live_specialist.py proved roleLaunch -> agent_jobs worker -> report_agent_job_result -> roleResult with auditable artifacts under .epiphany-dogfood/live-specialist."}
+{"ts": "2026-04-28T16:52:18+00:00", "type": "implementation", "status": "ok", "note": "Clarified MVP direction: marketplace and alternate job backend are not active concerns; the scheduler-shaped need is a narrow auditable fixed-lane role coordinator over modeling, implementation, verification, and CRRC handoffs, not a broad ambient dispatcher."}

state/map.yaml

@@ -54,7 +54,7 @@ data_flow:
 active_subgoals:
   - Treat Phase 5 update/distill/propose/promote/read/notification as complete enough unless a concrete regression appears.
   - Preserve read-only boundaries for retrieve, distill, propose, scene, jobs, roles, roleResult, freshness, context, pressure, reorient, crrc, and reorientResult.
-  - Extend Phase 6 observability only where it reflects authoritative state or retrieval summaries without becoming a scheduler.
+  - Extend Phase 6 coordination only where it makes role dependencies explicit and auditable without becoming a broad ambient dispatcher.
   - Put the dogfooded MVP loop in front of a human operator before adding larger organs.
   - Keep persistent project state ruthlessly distilled so rehydration strengthens the next turn instead of bloating it.
 
@@ -82,6 +82,7 @@ accepted_design:
   - `thread/epiphany/pressure` is the first read-only context-pressure surface: it derives pressure from token telemetry and auto-compact/context limits without compacting, scheduling, mutating, or notifying.
   - `thread/epiphany/reorient` is the first bounded CRRC policy surface: it derives a read-only `resume` versus `regather` verdict from checkpoint, freshness, watcher, and pressure signals without mutating state, compacting, scheduling, or silently continuing work.
   - `thread/epiphany/crrc` is the first bounded CRRC coordinator recommendation surface: it composes pressure, the reorientation verdict, fixed reorient-worker binding/result status, finding read-back, and available actions into one read-only recommendation without launching, accepting, compacting, scheduling, or mutating state.
+  - A narrow auditable role coordinator is likely central to the MVP because implementation, modeling/checkpoint, verification/review, and reorientation depend on each other's findings. This is distinct from a broad ambient scheduler: it should make the next role handoff explicit, reviewable, interruptible, and bounded to the fixed single-user role lanes.
   - `tools/epiphany_mvp_status.py` is the first dogfood operator view: it starts or reads a thread through app-server and renders scene, pressure, reorient, jobs, role result read-backs, reorient result, CRRC recommendation, and MVP role lanes as text or JSON without becoming a state store.
   - `thread/epiphany/roles` is the first harness-native role ownership surface: it projects implementation, modeling/checkpoint, verification/review, and reorientation lanes from authoritative typed state, bound jobs, pressure/reorient/CRRC, and worker result status without launching, scheduling, accepting, compacting, or mutating state.
   - `thread/epiphany/roleLaunch` and `thread/epiphany/roleResult` are the first explicit role-scoped specialist templates: modeling/checkpoint and verification/review can be launched through fixed bindings over the existing job-control seam and read back as reviewable findings, while implementation stays owned by the main coding agent and reorientation stays on the CRRC-specific launch/result path.
@@ -152,4 +153,4 @@ rejected_paths:
 
 current_status:
   summary: Phase 1 durable state, Phase 2 prompt integration, Phase 3 typed read, Phase 4 retrieval/indexing, Phase 5 update/distill/propose/promote/read/notification, and Phase 6 read-only scene, jobs, roles, freshness, targeted context, pressure, reorient, CRRC, reorient launch/result/accept, explicit modeling/checkpoint and verification/review role launch/result templates, first dogfood MVP status, auditable MVP dogfood runner, and live specialist MVP runner are landed. The live specialist runner proved a real modeling specialist can launch, inspect, report through `report_agent_job_result`, and be read back through `roleResult`; the earlier deterministic dogfood runner exercised state, role launch/result, CRRC drift, reorient launch/result/accept, rendered status snapshots, and Vanilla Codex comparison. Implementation remains main-agent work; reorientation remains on the CRRC-specific launch/result path. Persistent state remains distilled; evidence is a belief ledger, not an activity feed.
-  next_action: Treat the CLI MVP as testable: run `tools/epiphany_mvp_status.py`, inspect `.epiphany-dogfood/mvp-loop` and `.epiphany-dogfood/live-specialist`, and iterate only on concrete operator-loop blockers. Automatic broad specialist scheduling, GUI-as-source-of-truth, a specialist marketplace, autonomous specialist quality, and a second job backend remain future work.
+  next_action: Treat the CLI MVP as testable, then design the smallest narrow role coordinator that makes modeling, implementation, verification, and CRRC handoffs explicit over the existing `agent_jobs` seam. Do not build a broad ambient dispatcher, GUI-as-source-of-truth, arbitrary specialist marketplace, or alternate job backend for the MVP.