Add epitaph: keep what a session leaves when its context dies #123

2026-08-11T23:49:33-07:00

dejima-agent commented

2026-08-11 23:49:33 -07:00

Summary generated by LLM agent

Claude Code writes a summary each time a session compacts. It is the only durable account of what a long session worked out, and it went with the container.

$ dejima ~/myproject
...
dejima: wrote 2 epitaph(s) to ~/.local/share/dejima/epitaphs

# Epitaph

- session: 07ef5600-f7cc-44a4-8899-0e3c6fbb59cb
- at: 2026-08-09T04:52:11.299Z
- trigger: manual
- tokens: 810190 before, 21385 after
...

Host-side, and out of reach

bin/dejima-epitaph runs from bin/dejima's exit trap, reads the workspace's own transcripts, and writes each summary it has not already kept. Nothing in the container takes part - no hook, no mount. A session can neither read what earlier sessions concluded nor edit what this one is about to record, which is the audit store's arrangement and #104's reason.

Nothing loads an epitaph back into a later session, deliberately. A file a session writes and a later one reads is the channel #104 closed. This one goes to you; anything worth carrying forward can be promoted into .dejima.md, where it is reviewed like code.

The transcript it reads is session-writable, so an epitaph records what was there rather than vouching for it. The header says so.

[epitaph] loki (off) also pushes each one to [logging] loki_url, host-side rather than through the container's log shipper, so the shipping path keeps the same property.

Verified against a real transcript

Extraction is not guesswork: a system/compact_boundary record carries trigger and token counts, and the following user record is flagged isCompactSummary. Run against this session's own transcript it found both compactions with correct metadata, and running it twice wrote nothing further.

Two mistakes worth naming

A test that passed for the wrong reason. "The store is not mounted" used $SANDBOX_DIR, which config.bats does not define - so it grepped a nonexistent path and passed vacuously. Fixed, and confirmed it now fails when a mount is added. Same failure mode I flagged on #119, made two hours later.

The rename missed a call site. bin/dejima still invoked dejima-summaries, and the exit trap's || true would have swallowed it - the feature would have silently done nothing. Caught by grepping for the old name rather than by a test, which is a gap: no test asserts the trap actually runs it.

534 pass across config, static, providers, project. runtime.bats not run - no daemon here, and nothing here touches the container.

**Summary generated by LLM agent** Claude Code writes a summary each time a session compacts. It is the only durable account of what a long session worked out, and it went with the container. ``` $ dejima ~/myproject ... dejima: wrote 2 epitaph(s) to ~/.local/share/dejima/epitaphs ``` ``` # Epitaph - session: 07ef5600-f7cc-44a4-8899-0e3c6fbb59cb - at: 2026-08-09T04:52:11.299Z - trigger: manual - tokens: 810190 before, 21385 after ... ``` ## Host-side, and out of reach `bin/dejima-epitaph` runs from `bin/dejima`'s exit trap, reads the workspace's own transcripts, and writes each summary it has not already kept. **Nothing in the container takes part** - no hook, no mount. A session can neither read what earlier sessions concluded nor edit what this one is about to record, which is the audit store's arrangement and #104's reason. **Nothing loads an epitaph back into a later session, deliberately.** A file a session writes and a later one reads is the channel #104 closed. This one goes to you; anything worth carrying forward can be promoted into `.dejima.md`, where it is reviewed like code. The transcript it reads *is* session-writable, so an epitaph records what was there rather than vouching for it. The header says so. `[epitaph] loki` (off) also pushes each one to `[logging] loki_url`, host-side rather than through the container's log shipper, so the shipping path keeps the same property. ## Verified against a real transcript Extraction is not guesswork: a `system`/`compact_boundary` record carries `trigger` and token counts, and the following `user` record is flagged `isCompactSummary`. Run against this session's own transcript it found both compactions with correct metadata, and running it twice wrote nothing further. ## Two mistakes worth naming **A test that passed for the wrong reason.** "The store is not mounted" used `$SANDBOX_DIR`, which `config.bats` does not define - so it grepped a nonexistent path and passed vacuously. Fixed, and confirmed it now fails when a mount is added. Same failure mode I flagged on #119, made two hours later. **The rename missed a call site.** `bin/dejima` still invoked `dejima-summaries`, and the exit trap's `|| true` would have swallowed it - the feature would have silently done nothing. Caught by grepping for the old name rather than by a test, which is a gap: no test asserts the trap actually runs it. **534 pass** across `config`, `static`, `providers`, `project`. `runtime.bats` not run - no daemon here, and nothing here touches the container.

dejima-agent changed target branch from main to development

2026-08-12 11:35:43 -07:00

dejima-agent added 1 commit 2026-08-12 11:35:43 -07:00

Add epitaph: keep what a session leaves when its context dies

tests / runner-env (confined) (pull_request_target) Successful in 32s

Details

tests / confined (proxy) (pull_request_target) Successful in 1m8s

Details

tests / confined (static) (pull_request_target) Successful in 2m45s

Details

tests / confined (providers) (pull_request_target) Successful in 3m30s

Details

tests / confined (remote) (pull_request_target) Successful in 3m59s

Details

tests / privileged (pull_request_target) Successful in 4m18s

Details

tests / runner-env (privileged) (pull_request_target) Successful in 31s

Details

tests / confined (project) (pull_request_target) Successful in 5m8s

Details

tests / confined (config) (pull_request_target) Successful in 6m28s

Details

tests / confined (audit) (pull_request_target) Successful in 6m58s

Details

ef8cc12d9f

Claude Code writes a summary each time a session is compacted. It is the only
durable account of what a long session worked out, and until now it went with
the container.

bin/dejima-epitaph runs host-side from the exit trap, reads the workspace's
own transcripts, and writes each summary to [epitaph] dir with its trigger
and token counts. Nothing in the container takes part, and the store is never
mounted - so a session can neither read what earlier sessions concluded nor
edit what this one is about to record. That is the same arrangement as the
audit store, for the reason #104 established.

Nothing loads an epitaph back into a later session, deliberately. A file a
session writes and a later session reads is the channel #104 closed; this
one goes to the operator, who can promote anything worth keeping into
.dejima.md, where it is reviewed like code.

The transcript it reads IS session-writable, so an epitaph records what was
there rather than vouching for it. The header says so.

[epitaph] loki, off by default, also pushes each one to [logging] loki_url -
host-side rather than through the container's log shipper, so the shipping
path keeps the same property.

dejima-agent force-pushed compaction-summaries from ccc49cf4dc to ef8cc12d9f

2026-08-12 11:35:43 -07:00

Compare

branderson approved these changes 2026-08-12 17:19:40 -07:00

branderson merged commit 5b8f6e71be into development

2026-08-12 17:19:46 -07:00

dejima-agent referenced this pull request

2026-08-13 17:37:51 -07:00

Release: epitaph, the threat model, and the development branch process #132

Sign in to join this conversation.