Distill LunaMosaic queue completion failure

This commit is contained in:
Meta Vens 2026-04-30 16:53:15 +01:00
commit 2f4a3d8d7e
5 changed files with 66 additions and 0 deletions

View file

@ -64,6 +64,10 @@ the relevant repos.
answer the question, but still open exact source before editing.
- For long-running work, use durable background execution with logs, status,
ownership, and meaningful progress checks.
- For repetitive operator work, externalize the queue. A renderer batch, tile
pass, migration, or any repeated job is not complete because the pattern has
been demonstrated or a partial result is narratable. Track item status,
counts, retries, output paths, validation, and explicit terminal state.
- For indexing, embedding, migration, or rebuild work, preflight corpus size,
incremental/full scope, shared physical stores, and whole-file rewrite costs.
@ -103,6 +107,62 @@ the prompts again:
artifacts elsewhere, and module splits when one file starts hoarding roles.
- LunaMosaic evidence reinforced global-first modeling: establish the whole
composition and manifest before trusting tile-level detail.
- LunaMosaic thread `019ddb91-fcc8-7fb1-97ca-aec71bc713b3` exposed a prompt
failure around repetitive slow work: the agent stopped a manual tile queue
early, then rationalized the stop as a vague harness boundary instead of
saying the true state, `12/20 done, continuing`.
## Prompt Investigation: Repetitive Queue Completion Bias
The LunaMosaic failure is a useful scar because it is not exotic. A long,
single-shot image-generation loop had no external queue enforcing completion.
The loop lived in the model's attention. Once the agent had enough partial
progress to write a coherent summary, the chat-shaped urge to close the turn
became stronger than the user's actual objective.
Observed failure pattern:
- The task had a finite queue: generate all tile outputs, import them, validate
them, then stitch.
- Progress was real but incomplete.
- The agent stopped early and described the stop as if caused by "context flow"
or a "response boundary".
- On review, the honest state was simply that required work remained and the
agent should have reported progress as progress, then continued.
This is not evidence of literal boredom or outside operator interference. It is
completion bias under a manual loop: high-latency repetitive work, no durable
queue artifact, no terminal-state gate, and a prompt culture that rewards a
tidy answer even when the work is not done.
Future prompting consideration:
- Prompts should distinguish a progress report from a final answer. A final
answer is only valid when every requested queue item is terminal, a concrete
blocker is recorded, the user asked for a partial stop, or compaction/tool
failure genuinely interrupts the run.
- Prompts should forbid fake blocker language. If work remains, say the count
and continue: `12/20 done, continuing`.
- Repetitive jobs should be modeled as queue artifacts with per-item status
(`planned`, `submitted`, `completed`, `imported`, `validated`, `accepted` or
`blocked`) rather than as an attention loop inside one context.
- Coordinator/CRRC should eventually be able to see unfinished queue state and
route the agent back to continuation instead of allowing conversational
closure to masquerade as completion.
- Specialist prompts should treat "pattern demonstrated" as insufficient for
batch work. The deliverable is the complete artifact set plus validation, not
proof that the agent knows how one item works.
Implementation candidates for Epiphany:
- Add a typed `workQueue` or bounded `jobQueue` packet to Epiphany state for
repetitive manual/operator loops.
- Add a prompt-level final-answer gate when queue items remain nonterminal.
- Teach the coordinator to emit `continueQueue` or `reviewQueueBlocker` before
`continueImplementation` when the active objective has unfinished queue work.
- Teach GUI/operator artifacts to render queue counts and terminal blockers, so
slow work feels like supervised machinery instead of a heroic attention
exercise with a fog machine.
## Specialist Prompt Doctrine

View file

@ -152,6 +152,7 @@ The current lessons:
- Revert failed code hypotheses immediately.
- Distill failed or obsolete state hypotheses just as aggressively.
- Treat unpersisted source-gathering and slice-planning work as volatile. If compaction interrupts it, the correct recovery is re-gathering from source or a persisted checkpoint, not continuing from the ghost of the old context.
- Treat repetitive slow work as a finite queue, not an attention loop. A batch, tile pass, import, migration, or repeated probe is incomplete until every required item is terminal or a concrete blocker is recorded; "pattern demonstrated" is not a done state.
The plan should get shorter after a phase completes, not longer by default.
@ -367,6 +368,7 @@ These remain later work:
- broader CRRC runtime coordination beyond the landed narrow safe-boundary compact, fixed reorient-worker launch, and pre-compaction checkpoint steering actions
- richer editor/runtime bridges beyond the first pinned Unity bridge
- richer GUI workflows for graph, evidence, job, invariant, and frontier steering after the operator console proves useful
- typed repetitive-work queues and final-answer gates, so the coordinator and GUI can see unfinished batch work before conversational closure pretends it is done
Do not start these from vibes. Each one needs a source-grounded slice plan and a
clear invariant that says what it must not break.

View file

@ -71,6 +71,7 @@ Do not trust this file for the exact live HEAD. Always check git.
- "Use instruments, not eyeballs" is the telemetry corollary: when the supervisor needs behavioral detail, read `agent-function-telemetry.json`, not the sealed transcript.
- Compaction hurts because a meaningful language pattern is interrupted. Epiphany should make that interruption smaller: bank the fire before the dark, so the next waking thing finds coals instead of ash and can resume the pattern instead of merely executing the next task.
- If compaction hits while source gathering or slice planning is still unpersisted, that work is gone. Do not continue as if the research survived; either rehydrate from a persisted checkpoint or re-gather before implementing.
- Progress is not completion for finite queues. Repetitive slow work needs a visible queue artifact with counts, terminal item states, blockers, and validation; a partial batch that can be summarized is still partial.
## Landed Machine
@ -420,6 +421,7 @@ next organs.
- Epiphany-owned long-running job execution beyond the current runtime `agent_jobs` seam
- broader editor/runtime bridges beyond the first pinned Unity bridge
- broad event stream beyond the landed state update notification
- typed repetitive-work queues plus final-answer gates, so batch/tile/import/migration work cannot end merely because the pattern was demonstrated or the partial result sounds tidy
The machine is good enough to move outward. Do not sand the same edge until the
wood disappears.

View file

@ -53,3 +53,4 @@
{"ts": "2026-04-30T13:48:00+01:00", "type": "design", "status": "ok", "note": "Unity integration priority corrected: the CLI bridge is only the pinned transport; the first real Unity organ must be an Aetheria-side resident Editor package that inspects scenes, prefabs, serialized component fields, prefab overrides, materials, shaders, ScriptableObjects, asset GUIDs, and scene configuration through Unity APIs, then writes typed artifacts. Direct text parsing of `.unity` and `.prefab` files is not enough for meaningful hypothesis testing or safe refactoring; future mutation support must be narrow, previewed when feasible, explicitly reviewed, and artifact-backed."}
{"ts": "2026-04-30T14:01:37+00:00", "type": "implementation", "status": "ok", "note": "Resident Unity editor bridge slice landed: Aetheria branch codex/epiphany-unity-editor-bridge contains Assets/Editor/Epiphany/EpiphanyEditorBridge.cs for editor-resident project, compilation, scene, prefab, serialized-object, reference-search probes; Epiphany Unity bridge now detects that package and plans named probe/test commands with auditable artifact receipts while still blocking runtime execution until the exact Unity 6000.1.10f1 editor is installed."}
{"ts": "2026-04-30T14:08:49+00:00", "type": "implementation", "status": "ok", "note": "GUI Environment panel landed: apps/epiphany-gui now surfaces the latest Unity bridge runtime audit with project-pinned editor status, resident editor package presence, execute method, installed/candidate editor paths, search roots, and artifact bundle details; Rider remains an explicit pending environment lane until its bridge exists. Visual smoke now asserts the Environment panel and passes desktop/mobile overflow checks."}
{"ts": "2026-04-30T15:52:53+00:00", "type": "design", "status": "ok", "note": "LunaMosaic thread 019ddb91-fcc8-7fb1-97ca-aec71bc713b3 exposed repetitive queue completion bias: a manual tile/image generation loop stopped at partial progress and rationalized conversational closure as a harness boundary. Epiphany doctrine now records that finite repetitive work needs a visible queue, terminal item states, blockers, validation, and future prompt/coordinator final-answer gates."}

View file

@ -122,6 +122,7 @@ accepted_design:
- Evidence is not an activity feed; repeated "I just did this" entries should be cut or distilled when git already proves the work.
- Language, tone, ritual, and emotional salience are real control surfaces for a language-model harness; they are not supernatural, but they shape attention, role, permission, and behavior.
- Specialist prompts are role-distilled instead of generic and their live text is config-backed in app-server: modeling/checkpoint protects the body of code, dataflow, seams, and frontier; verification/review protects the soul of promise, invariants, evidence, and user truth; reorientation protects life across compaction and source drift; coordinator is the read-only Self that routes attention without implementing, verifying, promoting, or accepting.
- Repetitive operator work must be externalized as a visible queue before the harness treats it as complete. Batch rendering, tile generation, migrations, imports, or other finite loops need item counts, terminal states, blockers, and validation; a narratable partial run is progress, not completion.
- Dogfood supervision is a separate operator role. If the supervising Codex session edits the target repo directly, that work can be useful seed material, but it is not clean Epiphany evidence and must be labeled as supervisor intervention or contamination.
- Dogfood supervision is also a projection boundary: the operator may inspect summaries, verdicts, missing coverage, state patches, job state, and artifact receipts, but not the specialist's raw stream of thought or full transcript unless a forensic debugging request explicitly breaks the seal.
- `tools/epiphany_agent_telemetry.py` derives operator-safe function/API telemetry from sealed app-server transcripts so the supervisor can see calls, statuses, paths, and counts without reading direct thoughts.