From cc7fda08daea441ea419206ba244e9dfdd646b48 Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Sun, 26 Apr 2026 03:19:31 +0100 Subject: [PATCH] Record context pressure signal requirement --- notes/epiphany-core-harness-surfaces.md | 7 ++++++- notes/epiphany-fork-implementation-plan.md | 3 ++- notes/fresh-workspace-handoff.md | 2 +- state/evidence.jsonl | 1 + state/map.yaml | 1 + 5 files changed, 11 insertions(+), 3 deletions(-) diff --git a/notes/epiphany-core-harness-surfaces.md b/notes/epiphany-core-harness-surfaces.md index 2e43d0ad..66668a66 100644 --- a/notes/epiphany-core-harness-surfaces.md +++ b/notes/epiphany-core-harness-surfaces.md @@ -201,12 +201,17 @@ Current operating rule: Future runtime behavior should: -- detect context pressure before the hard limit +- expose context pressure as a real runtime signal before the hard limit - checkpoint at safe points when possible - preserve role-specific resume packets - distinguish what survived from what was discarded - make compaction visible instead of pretending continuity is magic +Until that signal exists, agents can only infer pressure from indirect cues: +long transcripts, compaction warnings, quota pressure, and a shrinking safe +landing zone. That is a scar, not a sensor. Automatic CRRC needs typed +pressure/freshness telemetry instead of vibes with a clipboard. + Compaction should squeeze scratch, not the map. ## Persistent State Hygiene diff --git a/notes/epiphany-fork-implementation-plan.md b/notes/epiphany-fork-implementation-plan.md index f6ced204..4877f046 100644 --- a/notes/epiphany-fork-implementation-plan.md +++ b/notes/epiphany-fork-implementation-plan.md @@ -113,6 +113,7 @@ The next unknowns are: - how to expose live long-running job progress without making the GUI authoritative - when watcher-driven invalidation becomes necessary instead of merely tempting +- how to expose context pressure as a real runtime signal for automatic CRRC - how much automatic CRRC coordination belongs in runtime before it becomes ceremony machinery - what Phase 6 should prove before specialist scheduling begins @@ -139,7 +140,7 @@ These remain later work: - richer evidence and graph-shard inspection beyond the landed targeted context read - role-scoped specialist-agent registry and scheduling - mutation gates that warn or block broad writes when map freshness is stale -- automatic CRRC runtime coordination +- automatic CRRC runtime coordination with typed context-pressure telemetry - GUI workflows for graph, evidence, job, invariant, and frontier steering Do not start these from vibes. Each one needs a source-grounded slice plan and a diff --git a/notes/fresh-workspace-handoff.md b/notes/fresh-workspace-handoff.md index 6fdeeba8..ee55914e 100644 --- a/notes/fresh-workspace-handoff.md +++ b/notes/fresh-workspace-handoff.md @@ -159,7 +159,7 @@ Live `thread/epiphany/scene`, `thread/epiphany/jobs`, and - automatic observation promotion - specialist-agent scheduling - GUI-as-source-of-truth -- automatic runtime CRRC coordinator +- automatic runtime CRRC coordinator with real context-pressure telemetry - live long-running job execution or `thread/epiphany/jobsUpdated` - broad event stream beyond the landed state update notification diff --git a/state/evidence.jsonl b/state/evidence.jsonl index c471a465..f33d658c 100644 --- a/state/evidence.jsonl +++ b/state/evidence.jsonl @@ -32,3 +32,4 @@ {"ts": "2026-04-26T00:33:31+00:00", "type": "verification", "status": "ok", "note": "Phase 6 scene live-smoked through app-server with tools/epiphany_phase6_scene_smoke.py. The smoke proves missing and ready scene shapes, live source, retrieval-summary backfill, available actions, newest-first bounded observation/evidence records, no scene-triggered stateUpdated notification, and unchanged final read revision; it also caught and fixed reversed latest-record ordering in map_epiphany_scene."} {"ts": "2026-04-26T01:08:00+00:00", "type": "verification", "status": "ok", "note": "Phase 6 jobs reflection landed as read-only thread/epiphany/jobs and live-smoked through app-server with tools/epiphany_phase6_jobs_smoke.py. The surface derives retrieval-index, graph-remap, verification, and specialist slots from thread state/retrieval summaries, preserves revision identity, emits no stateUpdated notification, and leaves live scheduling/progress notifications as future work."} {"ts": "2026-04-26T01:58:10+00:00", "type": "verification", "status": "ok", "note": "Phase 6 targeted context reflection landed as read-only thread/epiphany/context and live-smoked through app-server with tools/epiphany_phase6_context_smoke.py. The surface returns selected graph/evidence shards plus missing ids without mutation, notification, retrieval, proposal, or promotion."} +{"ts": "2026-04-26T02:19:20+00:00", "type": "decision", "status": "ok", "note": "Context pressure must become a real runtime signal for automatic CRRC. Current agents can infer pressure from transcript length, warnings, quota pressure, and shrinking safe scope, but that is a heuristic scar rather than telemetry."} diff --git a/state/map.yaml b/state/map.yaml index ecf18815..9876ed89 100644 --- a/state/map.yaml +++ b/state/map.yaml @@ -68,6 +68,7 @@ accepted_design: - Vendored Codex keeps the thin typed host seam: protocol types, thread bridges, app-server protocol, request routing, and rollout integration. - The current algorithmic map is the source-grounded description of live control flow. - Compact-Rehydrate-Reorient-Continue is an architecture primitive; automatic runtime coordination is not landed yet. + - Context pressure must become an explicit runtime signal for automatic CRRC; inference from transcript vibes, user warnings, or shrinking safe scope is useful only as a temporary human/agent heuristic. - GUI/client work must reflect or steer typed state rather than manufacture a second source of truth. - `thread/epiphany/jobs` is the first read-only job/progress reflection: it derives indexing, remap, verification, and specialist slots from existing state; it is not a scheduler or durable job store. - `thread/epiphany/context` is the first targeted read-only state-shard surface: it selects graph nodes/edges, active frontier, checkpoint, observations, and evidence from authoritative typed state without mutating or notifying.