From cacb0cb6a7c687ffc650abf7b220130d6cfdca6a Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Thu, 30 Apr 2026 14:24:27 +0100 Subject: [PATCH] Prioritize Rider and Unity bridges --- notes/epiphany-fork-implementation-plan.md | 11 ++++----- notes/fresh-workspace-handoff.md | 26 ++++++++++++---------- state/evidence.jsonl | 1 + state/map.yaml | 8 +++---- 4 files changed, 25 insertions(+), 21 deletions(-) diff --git a/notes/epiphany-fork-implementation-plan.md b/notes/epiphany-fork-implementation-plan.md index dccab7af..dc611099 100644 --- a/notes/epiphany-fork-implementation-plan.md +++ b/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. diff --git a/notes/fresh-workspace-handoff.md b/notes/fresh-workspace-handoff.md index a0bd950e..e6a44471 100644 --- a/notes/fresh-workspace-handoff.md +++ b/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 diff --git a/state/evidence.jsonl b/state/evidence.jsonl index fba3d442..ee8887e7 100644 --- a/state/evidence.jsonl +++ b/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."} diff --git a/state/map.yaml b/state/map.yaml index f66ba149..a12c851a 100644 --- a/state/map.yaml +++ b/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.