# Owner-reported durability failure and runtime WAL direction

Date: 2026-09-06. Recorded by darkwing.
Status: owner-reported context and direction for later runtime design; not an
independently investigated incident or an implementation/test receipt.

Jason reports that the separate ~/.mosaic Stack v1 deployment is fragile under
load; agents retain work in memory rather than reliably tracking it in the system,
and agent state does not reliably survive restarts. He directs that agent actions
use WAL for durability and expects tasks, missions, goals, workspaces, projects and
kanban to provide stronger control over system flow.

No investigation/intervention in that deployment is requested or performed.

## Required follow-through in the later runtime charter

- Trusted admission/publisher code enforces write-ahead intent for governed effects.
  Compliance must not depend on a model voluntarily writing a note or remembering
  to update a task. This builds on the accepted pre-effect recording requirement.
- Specify the durability boundary: flush/sync and acknowledgement ordering, atomic
  publication, recovery of incomplete/torn records, writer ownership and failure
  behavior. Merely appending to a file or calling something WAL is insufficient.
- Record stable action/request identity, exact scope/assignment/intent revisions,
  and recovery evidence without secrets. Keep work records distinct from private
  transcripts and enforce their visibility rules.
- Reconstruct selected work and outstanding obligations from authoritative records
  after restart. Chat memory and UI caches cannot be the only source of truth.
  Kanban and other surfaces must view the same work state, not competing task lists.
- Reconcile uncertain external effects using evidence; WAL does not make arbitrary
  external commands exactly-once or justify blind replay after a crash.
- Test crash/restart points around intent, acknowledgement, execution and result;
  concurrent writers and load; disk-full/write/sync failures; and loss of a required
  audit path. Verify both preserved work and fail-closed admission. Preserve the
  separately preauthorized fail-safe stopping path.

## Scope boundary

The accepted map already identifies legacy writeOnce's lack of fsync and the need
for a trusted durable publisher/recovery boundary. This observation sharpens later
runtime acceptance requirements; it does not prove a specific v1 root cause.

The approved inspector charter remains frozen at
19b6721128a627a2032ffdb95ece2d50abe69a8f6d521e9eff8bbdaff22798b6.
FI-ROCKO-3 implements only that offline synthetic inspector. WAL/runtime persistence,
load remediation and live migration are not added to its scope. A synthetic preview
cannot establish these durability guarantees. No worker is retasked by this note.