Prioritize Rider and Unity bridges

notes/epiphany-fork-implementation-plan.md

@@ -162,11 +162,12 @@ and notify typed state. It can.
 
 The next unknowns are:
 
-- how much controlled runtime/editor access the first Unity bridge gives implementation and verification lanes before deeper engine probes need a richer bridge
+- what bridge surface is sufficient for the next Aetheria run: named Unity operations, Aetheria-side editor probes, GUI environment status, Rider context capture, and a Rider plugin MVP
+- how much controlled runtime/editor access the richer Unity bridge gives implementation and verification lanes before deeper engine probes need another slice
 - 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 narrow coordination is needed so modeling, implementation, verification, and CRRC automation can hand off work without collapsing back into one context
-- what concrete operator friction appears when the GUI/operator MVP is tested on real work
+- what concrete operator friction appears once the bridge-equipped GUI/operator MVP is tested on real work
 
 ## MVP Cutline
 
@@ -262,9 +263,9 @@ Phase 6 should grow observable harness state outward from the typed spine.
 
 Useful candidates:
 
-1. Dogfood the first Unity editor/runtime bridge in the implementation lane. The bridge can inspect pins, refuse wrong/missing editors, and run exact-editor batch/probe commands; it still needs real Aetheria use before richer engine probes are justified.
-2. Build the Rider+Unity environment plan in slices: named Unity bridge operations, Aetheria-side Unity editor package probes, GUI Environment panel, Rider context bridge, then Rider plugin MVP.
-3. Keep dogfood execution agent-run and auditable through the fixed-lane coordinator and GUI/operator view over the same status/artifact surfaces.
+1. Build the Rider+Unity environment plan before the next Aetheria implementation dogfood run: named Unity bridge operations, Aetheria-side Unity editor package probes, GUI Environment panel, Rider context bridge, then Rider plugin MVP.
+2. Use the next dogfood run to test the bridge-equipped loop, not to discover again that Epiphany cannot prove runtime/editor assumptions from source inspection alone.
+3. Keep dogfood execution agent-run and auditable through the fixed-lane coordinator and GUI/operator view over the same status/artifact surfaces once the bridges exist.
 4. Keep accepted worker findings review-gated; do not convert acceptance into automatic promotion of arbitrary worker output.
 5. Keep pre-compaction intervention narrow: steer once at `shouldPrepareCompaction`, latch the compact handoff only after successful steering, then let explicit checkpointing, compact/resume/reorient, and review gates do their jobs.
 

notes/fresh-workspace-handoff.md

@@ -361,18 +361,20 @@ bounded browser-fallback controls. A live bridge probe also proved
 `prepareCheckpoint` creates a resumable thread and a later process can
 `readModelingResult` from it.
 
-The next real move is not more direct Aetheria implementation by the supervisor.
-The first Unity bridge is landed, and it correctly blocks Aetheria runtime
-execution until Unity `6000.1.10f1` is installed. The detailed next-environment
-plan now lives in `notes/epiphany-rider-unity-integration-plan.md`: Rider is
-the IDE/source-context organ, Unity is the editor/runtime fact organ, and
-Epiphany remains the durable coordinator/Self. Resume dogfood through
-Epiphany's GUI/coordinator/fixed lanes with the bridge in the loop; then build
-the plan in slices: named Unity bridge operations, Aetheria-side Unity editor
-package probes, GUI Environment panel, Rider context bridge, and Rider plugin
-MVP. The implementation lane may inspect source and may use bridge artifacts as
-evidence, but it must not launch Unity directly or use installed `6000.4.2f1`
-as a substitute. Read only operator-safe projections; do not open raw worker
+The next real move is bridge construction, not another Aetheria implementation
+dogfood run. The first Unity bridge is landed, and it correctly blocks Aetheria
+runtime execution until Unity `6000.1.10f1` is installed. The detailed
+next-environment plan now lives in
+`notes/epiphany-rider-unity-integration-plan.md`: Rider is the
+IDE/source-context organ, Unity is the editor/runtime fact organ, and Epiphany
+remains the durable coordinator/Self. Build the plan in slices before the next
+run: named Unity bridge operations, Aetheria-side Unity editor package probes,
+GUI Environment panel, Rider context bridge, and Rider plugin MVP. The next
+Aetheria dogfood pass should happen only after Epiphany can gather Rider/source
+context and Unity/editor runtime evidence through auditable bridges. The
+implementation lane may inspect source and may use bridge artifacts as evidence,
+but it must not launch Unity directly or use installed `6000.4.2f1` as a
+substitute. Read only operator-safe projections; do not open raw worker
 transcripts, direct worker messages, or `rawResult` payloads unless the user
 explicitly asks for forensic debugging. Use generated function/API telemetry
 for call-shape visibility without sungazing. CRRC is not a specialist-agent

state/evidence.jsonl

@@ -51,3 +51,4 @@
 {"ts": "2026-04-30T11:36:00+01:00", "type": "verification", "status": "blocked", "note": "Aetheria dogfood exposed the next MVP product blocker: engine assumptions require editor/runtime integration. A worker launched legacy D:\\Unity\\Editor\\Unity.exe (Unity 5.5.0f3) despite Aetheria pinning Unity 6000.1.10f1. The GUI action prompt now refuses PATH/default/legacy Unity when the exact pinned editor is unavailable, but the real next organ is a typed editor/runtime bridge that resolves pinned editors, runs explicit batch/probe commands, and captures artifacts as evidence."}
 {"ts": "2026-04-30T11:43:33+00:00", "type": "implementation", "status": "ok", "note": "First Unity editor/runtime bridge landed: tools/epiphany_unity_bridge.py resolves ProjectSettings-pinned Unity editors, refuses wrong or missing versions, owns batch/quit/projectPath execution, writes inspection/command/log artifacts, and is exposed through GUI Inspect Unity plus implementation prompt guidance. Smoke verified wrong-only roots are rejected, exact fake roots plan dry-run commands, and missing editors block runs; real Aetheria inspection shows pin 6000.1.10f1 while only 6000.4.2f1 is installed."}
 {"ts": "2026-04-30T12:10:09+00:00", "type": "design", "status": "ok", "note": "Documented the Rider+Unity environment integration plan in notes/epiphany-rider-unity-integration-plan.md. The plan defines Rider as IDE/source-context organ, Unity as editor/runtime fact organ, and Epiphany as durable coordinator/Self, with seams for a Rider tool window/context bridge, pinned Unity bridge operations, Aetheria-side Unity editor probes, GUI Environment panel, typed environment state, specialist behavior, and verification gates."}
+{"ts": "2026-04-30T13:05:00+01:00", "type": "design", "status": "ok", "note": "Next-action priority amended: do not run another Aetheria implementation dogfood pass until the Rider and Unity bridges are in place. The next implementation slice is bridge construction first: named Unity operations, Aetheria-side Unity editor probes, GUI Environment panel, Rider context bridge, and Rider plugin MVP, so Epiphany can test hypotheses through IDE/source and editor/runtime evidence instead of repeating bridge-less supervision scars."}

state/map.yaml

@@ -58,14 +58,14 @@ 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, graphQuery, pressure, reorient, crrc, coordinator, and reorientResult.
-  - Dogfood the landed Phase 6 coordinator, limited safe-boundary CRRC automation, and pre-compaction checkpoint intervention before adding larger organs.
+  - Keep the landed Phase 6 coordinator, limited safe-boundary CRRC automation, and pre-compaction checkpoint intervention ready for the next bridge-equipped dogfood run.
   - Preserve review gates for semantic findings; automatic CRRC may compact or launch the fixed reorient-worker, but not accept or promote.
   - Keep persistent project state ruthlessly distilled so rehydration strengthens the next turn instead of bloating it.
   - Quarantine the Aetheria dogfood contamination: future target-repo work must be driven through Epiphany's GUI/coordinator/fixed lanes with auditable artifacts, not direct supervisor implementation.
   - Keep the supervisor out of Epiphany worker thought streams: dogfood artifacts should be operator-safe by default, with direct transcripts and raw result payloads sealed.
   - Use `tools/epiphany_agent_telemetry.py` and generated `agent-function-telemetry.json` files to inspect behavior shape without opening sealed transcripts.
   - Treat repeated no-diff implementation turns as an MVP blocker, not success. A bounded implementation pass must leave a reviewable workspace diff or an explicit reviewable failure artifact before dogfood can be called healthy.
-  - Dogfood the first Unity editor/runtime bridge before resuming engine implementation: inspect the project-pinned editor, refuse wrong or missing versions, and route any Unity batch/probe execution through auditable bridge artifacts.
+  - Build the Rider and Unity bridges before the next Aetheria implementation dogfood run: named Unity bridge operations, Aetheria-side Unity editor probes, GUI Environment panel, Rider context bridge, and Rider plugin MVP.
   - Use `notes/epiphany-rider-unity-integration-plan.md` as the source-grounded plan for Rider-as-IDE and Unity-as-editor/runtime integration seams.
 
 accepted_design:
@@ -188,5 +188,5 @@ rejected_paths:
     reason: persistent state that accumulates every local truth becomes memory cruft and weakens rehydration
 
 current_status:
-  summary: Phase 1 durable state through Phase 6 GUI/coordinator/specialist/CRRC MVP surfaces are landed and actively dogfooded. The Aetheria supervised run found and fixed real harness wounds in coordinator policy, no-diff audits, stale job/result projection, and reorient acceptance. The Unity incident has now produced the first runtime bridge, and `notes/epiphany-rider-unity-integration-plan.md` now defines the next environment integration seams for Rider as IDE and Unity as editor/runtime.
-  next_action: Resume dogfood through Epiphany lanes with the Unity bridge in the loop, then implement the Rider+Unity integration plan in slices: named Unity bridge operations, Aetheria-side Unity editor package probes, GUI Environment panel, Rider context bridge, then Rider plugin MVP. Do not let implementation workers invoke Unity directly; use bridge artifacts as evidence of either a pinned-editor run or a missing-runtime blocker. Do not inspect raw worker transcripts or `rawResult` payloads unless the user explicitly requests forensic debugging.
+  summary: Phase 1 durable state through Phase 6 GUI/coordinator/specialist/CRRC MVP surfaces are landed. The Aetheria supervised run found and fixed real harness wounds in coordinator policy, no-diff audits, stale job/result projection, and reorient acceptance. The Unity incident proved the next blocker is environment access, so `notes/epiphany-rider-unity-integration-plan.md` now governs the bridge-building pass before the next Aetheria dogfood run.
+  next_action: Implement the Rider+Unity integration plan before further Aetheria implementation dogfood: named Unity bridge operations, Aetheria-side Unity editor package probes, GUI Environment panel, Rider context bridge, then Rider plugin MVP. The next dogfood run should happen only after Epiphany can gather Rider/source context and Unity/editor runtime evidence through auditable bridges. Do not let implementation workers invoke Unity directly; use bridge artifacts as evidence of either a pinned-editor run or a missing-runtime blocker. Do not inspect raw worker transcripts or `rawResult` payloads unless the user explicitly requests forensic debugging.