Files
platform/todo/multi-user/processtransport-is-not-ready-for-writing.md
pastilhasandClaude Fable 5 6071ded175 todo: one file per item, grouped by theme, with a generated index
TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly
on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with
frontmatter carrying id, status, created date and order, and the prose body copied
across verbatim. TODO.md becomes a generated index (bun run todo:index).

Dates: where an item's prose stated one it is used; otherwise its old section's;
otherwise 2026-08-20, floored at the day before the split rather than invented.
date_source records which.

Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is
the identity, frontmatter is the machine's half and the body is the owner's.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-21 05:42:39 +00:00

844 B

id, title, theme, status, created, date_source, order
id title theme status created date_source order
multi-user/processtransport-is-not-ready-for-writing `ProcessTransport is not ready for writing` — survivable since `8c4f150`, still unexplained multi-user open 2026-08-11 stated 6

ProcessTransport is not ready for writing — survivable since 8c4f150, still unexplained. A floating rejection inside the SDK's own input pump, with no frames from our code, so no await of ours can catch it. It crashed officer-agent four times on 2026-08-11, once truncating a turn mid-sentence; the unhandledRejection backstop has caught it once since. Best hypothesis is the claude CLI exiting while streamInput is still pumping. It needs looking at after the next occurrence, not catching in the act — markers to grep in docs/open-threads-after-per-user-claude.md §3.