Record story-093 in the story table

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HkujNrgMcsRBFWNEKWYnmA

Author: jerodw

README.md

@@ -86,6 +86,7 @@ Each story below is a step the book's roadmap calls for, or a failure the build
 | 090 | The outbox is total over what it is handed: `enqueue` guarded only against a queue it could not write to, so a payload or identity `json` could not render raised into the producer and would have stopped the story — the key derivation moved inside the guard, since it raised before the guard began, and one drop site now covers the unwritable queue, the unrenderable value and the self-referential structure alike; nothing is coerced, because an entry saying something the producer did not say gets delivered later as though it had; a refused item is reported on stderr and in the run's `events.log`, each sink guarded on its own so a failure to report is never a failure to enqueue; and the key comes back only once the entry is on disk, the empty string saying nothing landed | Ch. 17, external systems; Ch. 18, hardening |
 | 091 | One command files a story: the outbox files an entry by running a single configured command, through which the harness knows nothing else about the tracker — the entry on stdin, its key in the environment, the last non-empty line of stdout recorded as a reference and never parsed, and an exit code saying landed, retry (75, EX_TEMPFAIL) or stop; a zero exit naming no reference is read as transient, since it establishes nothing about whether the request arrived, and so is a command killed at its timeout, whose kill reaches the process group so no children are left behind; idempotency given the key is the command's promise and the harness says plainly that it cannot check it, as it says of the rule that a sync command must not commit | Ch. 17, external systems; Ch. 18, hardening |
 | 092 | The sweep runs where failure is free: the outbox drains opportunistically at three points chosen so a failure at any of them costs nothing — a run's pre-flight, below every refusing check; after the completion commit, so durability never waits on a network; and `l5-status`, where a developer finds out something is stuck — and alone among this coordinator's pre-flights, the sweep **may not refuse**, since a sweep that could say no would let an undrainable queue stop the run that was going to drain it; the completion sweep reports into no run directory, because a line appended after the completion commit would leave the tree dirty and the next run's clean-tree pre-flight would refuse — the sweep becoming the thing that blocks a run | Ch. 17, external systems; Ch. 18, hardening |
+| 093 | The harness can ask what is already filed: the read side of external filing, `sync_command`'s shape run backwards — one configured command asked a scoped question on stdin, answering JSON on stdout, with the harness knowing nothing else about the tracker; **nothing known and nothing filed are different answers**, carried as a separate flag, because an empty list looks like both and a caller reading only the items would report silence as agreement and file a duplicate believing dedupe had run; the question is scoped to a path set rather than a listing, so what it transfers stays proportional to the code rather than to the backlog, and every failure mode resolves to nothing known with a reason rather than raising — a failed query costs dedupe and costs nothing else | Ch. 17, external systems; Ch. 18, hardening |
 
 Still ahead, in the order Chapters 18 and 19 recommend: per-agent logs and a watcher, a fuller hook-based tool policy in place of the static `allowed_tools` allowlist, an adjudicator, an inspector, git worktrees and parallel story execution, and a real initialization library.