# repo-mailbox Renamed from `coord` in v0.3.0. The plugin/repo is `repo-mailbox`; the CLI (`coord-send.sh`, `coord-inbox.sh`, `coord-done.sh`), the mailbox root (`~/.claude/coord/`) and `CLAUDE_COORD_DIR` deliberately kept their names — they are the transport protocol, not the product. ## Context Local inter-repo coordination mailbox for Claude Code, packaged as a marketplace plugin. Three components, one boundary: - **Engine (`scripts/*.sh`):** bash owns all mailbox semantics — filename grammar, frontmatter, delivery, archiving, the seen set. `coord-send.sh` writes, `coord-inbox.sh` reads (formatted for context injection), `coord-done.sh` archives, `coord-count.sh` counts without delivering, `coord-sweep.sh` closes the aged FYI backlog machine-wide. Everything is pinned by `coord-selftest.sh` (220 checks, throwaway mailbox via `CLAUDE_COORD_DIR`). **`ktg-plugin-marketplace` is a RETIRED `--to` address (operator decision 2026-08-15), rejected rather than redirected.** It is a polyrepo directory, not a git repo, so `basename(git toplevel)` can never resolve to it and no session was ever able to hold that identity naturally - mail for it belongs to `catalog` instead. A silent redirect was considered and declined: it delivers mail somewhere the sender does not believe it landed, which is the same misdelivery defect this closes a second time (2 messages sat undelivered 2 days on this exact misaddressing before `catalog`'s H4 count caught 6 more). Rejection fails loud at the sender, at the moment the mistake is made. Only `--to` is retired, not `--from` - the defect was mail *arriving* there, never mail claiming to *originate* there. **`coord-send --reply-to` asserts "marked handled" against GROUND TRUTH, and the exit code alone is NOT that ground truth.** The line used to print unconditionally with `coord-done`'s output discarded (`>/dev/null 2>&1`), so the one line a session relies on to close a reply debt was false at the moment it was printed — measured with a stub `coord-done` exiting 1: original still in the inbox, no `archive/`, exit 0, "marked handled". Every reply this repo sent had to be verified by hand afterwards, which is what a false success in the TRANSPORT costs. The check is `exit 0` **and** the original no longer being at `$COORD/$FROM/inbox/$REPLYTO`, because `coord-done` exits 0 when it archives nothing (an unknown name is idempotently fine by its own contract), so a nonzero-exit test still certifies a message that never moved. The path is recomputed rather than reusing `$REPLY_ORIG`, which resolves to the inbox OR the archive — replying to an already-archived original moves nothing and must not warn. Failure is exit **1**, a new status: the reply WAS delivered and re-sending would duplicate it, so 2 stays the nothing-was-written status it has always been. Selftest section 34 pins all four cases (fails outright / exits 0 without moving / real happy path / archive-path reply). **`coord-sweep.sh` is the only path that closes a message with no human in the loop, and every constraint on it follows from that.** It may close exactly one mechanically decidable class - `reply-expected: no`, older than the grace window - because a message that owes a reply can only be answered by a session in the repo that owes it. Dry-run is the default, inverted from the rest of the engine, since this is the one script that destroys pending state. It closes through `coord-done.sh --repo` rather than moving files, so the archive layout and the `_broadcast` refusal stay in one place. And it logs every closure with sender and subject, because directed messages have no seen-tracking: the sweep genuinely cannot tell "seen and ignored" from "never delivered", so a notice can be closed unread and the log is the only record that it existed. Widening the class, defaulting to `--write`, or dropping the log each independently turn this from a bounded cleanup into silent data loss. **`coord-count.sh` prints TWO integers per mailbox** (`\t\t`), and the first must stay pending: `board.sh` counts the same inbox files itself, so a debt-only count would put two different numbers under one name. Debt is read from `reply-expected` in the FRONTMATTER BLOCK ONLY - a body line is untrusted input and must not be able to silence a debt - and an absent field means a reply IS owed, because every message written before 0.11.0 lacks it. **Reading is delivering — counting is not.** `coord-inbox.sh` records a broadcast as seen once it has printed it, so it can never be used to survey other repos: doing so would consume each one's backlog silently, and the seen set is delivery history that retraction deliberately leaves alone. `coord-count.sh` exists for every "what is pending" question and writes nothing at all. Any future read-shaped feature belongs there, not in the read path. - **Hook (`hooks/scripts/session-start.mjs`):** thin zero-dependency Node wrapper (marketplace convention: hooks are `.mjs`) that calls `coord-inbox.sh` and emits the `hookSpecificOutput.additionalContext` envelope. No mailbox logic lives here. Always exits 0. - **Hook (`hooks/scripts/pre-state-line-guard.mjs`):** a `PreToolUse` hook on `Write|Edit` that enforces the STATE.md convention's `maks ~120 linjer` (global CLAUDE.md; raised from `~60` by operator decision 2026-08-14 — see the dated paragraph below) mechanically. It exists because the prose limit alone failed: a real STATE.md drifted to 155-156 lines before an /insights sweep of 160 sessions noticed, and one trim pass on it *increased* the line count instead of shrinking it. org-ops dispatched the work order (20260814T144553Z) asking for a `PostToolUse` hook — that was the wrong event, and the fix is not cosmetic: `PostToolUse` fires only after the tool has already written the file (confirmed against the official hooks docs, 2026-08-14 — "Can block? No", stderr is shown to the model but the write already landed), so it cannot stop an oversized STATE.md from landing, only nag about it afterward. `PreToolUse` is the only event that can deny the call before the file is touched, which is what "enforces" has to mean here. Denial is stderr + `exit 2`, matching `llm-security`'s `pre-write-pathguard.mjs` — the only other `PreToolUse` `Write|Edit` guard in this marketplace — rather than the `hookSpecificOutput.permissionDecision` JSON form; both block, and matching the sibling convention keeps one idiom for "block a write" instead of two. For `Write` the projected content is the call's own `content`; for `Edit` it is the CURRENT on-disk file (read fresh, since `PreToolUse` fires before the edit is applied) with `old_string` replaced by `new_string` — every occurrence when `replace_all` is set, otherwise only the first, mirroring what the real Edit tool does. Getting `replace_all` wrong in either direction is not a hypothetical: a hook that only ever replaced the first occurrence would silently pass a bulk edit that balloons the file, so `state-line-guard-selftest.sh` (21 checks) pins a fixture where only counting every `replace_all` occurrence produces the correct denial. Anything the hook cannot project with confidence — a missing file, an `old_string` that is not present, fields of the wrong type — is left to the real tool, which reports a clearer error than a guess here would; the guard only ever touches files named exactly `STATE.md`, at any depth, matching the same basename rule the global session-start hook's nearest-STATE-wins search already uses. **It is a RATCHET against the file's current size, not a flat gate at 60 — found by advisor review before the tag landed, not by the selftest, which had no fixture for it.** The first cut compared the projected line count only against `MAX_LINES`, never against what the file already was, so trimming an oversized STATE.md from, say, 156 to 100 lines — still over 60, but strictly smaller — was denied exactly like growing it would have been. Verified empirically against the real tree (2026-08-14): `wc -l ~/repos/*/STATE.md ~/repos/*/*/STATE.md | awk '$1 > 60'` found 23 files already over 60 lines, one at 1405. Shipped as a flat gate, this hook would have made most of the machine's STATE.md files un-editable except by a single write landing at `<=60` in one shot — backwards for a guard whose whole point is making the trim the /insights finding asked for actually possible. The fix reads the file's current line count for BOTH tool types (previously only `Edit` read the file at all) and denies only when the projection is over `MAX_LINES` **and** larger than that current count: a compliant file still cannot grow past the limit, a brand-new file still cannot be created oversized (current defaults to 0), but an already-oversized file can always be edited toward compliance, one write at a time, without ever making it worse. Section 8 of the selftest pins all four cases: shrink-while-still-over-limit allows, same-size-rewrite allows, grow-an- already-oversized-file still denies, and create-new-oversized-file still denies. **`MAX_LINES` raised 60 -> 120, operator decision 2026-08-14 (evening), reported via coord by `.claude` after the global CLAUDE.md prose was already updated.** The ratchet mechanics above are unchanged - only the constant moved, plus every selftest fixture and boundary value that encoded 60 as a literal. Re-verified empirically against the real tree at the new threshold (2026-08-14): `wc -l ~/repos/*/STATE.md ~/repos/*/*/STATE.md | awk '$1 > 120'` found 13 files already over 120 lines, one at 1496 - the historical 23-files-over-60/one-at-1405 figures above describe the tree as it was at the moment the ratchet bug was found, not the current threshold, and are left as-is rather than rewritten. `session-start.mjs`'s 160-line injection window still covers the new 120-line limit with room to spare, so no change was needed there. **The Edit path's `current.replace(oldStr, newStr)` was a dollar-pattern injection bug, found and fixed 2026-08-15.** Passing `newStr` as a STRING makes JavaScript interpret `$`-sequences inside it ($&, `` $` ``, `$'`, `$$`, `$n`) as special replacement patterns, even though `oldStr` (the search side) is a plain string, not a RegExp. A `new_string` documenting old backtick-substitution style (`` $`cmd` ``) - exactly the prose a STATE.md's shell-conventions section writes routinely - triggers it. Measured against the real bug (`.claude/STATE.md`): a 5-line addition on a 112-line file projected to 219 lines and was wrongly denied. Direction is always fail-CLOSED (never fail-open: it can only over-block, never under-block a real oversize), but it made exactly the kind of STATE.md that documents shell conventions hard to edit. Fix: replace with a function, `current.replace(oldStr, () => newStr)` - a function result is never pattern-substituted, so this covers every `$`-sequence at once, not a `` $` ``-specific escape. The `replace_all` branch (`split`/`join`) was never affected - `join` does not interpret its argument as a pattern. Pinned by state-line-guard-selftest.sh section 9 (`$\`` as the real repro, `$&` as a second sequence proving the fix is general). **Since ORDRE 42 (operator, 2026-08-16) it carries a SECOND invariant: the projected content may not claim `status=done` in its board line while the repo holds commits the branch's upstream does not have.** Measured that day: two sessions had their push refused by the UFW rate limit on port 22, said so honestly in the coord inbox, and wrote `status=done` regardless - board line green, one commit unpushed, published surface 404. `done` meant "the session finished" where every reader takes it to mean "the work landed", and since `done` drops a repo from the board plan, `morning --say ` could not reach either of them: one defect hid the other. **The order recommended a session-end hook and that direction does not exist in the form it assumes - measured against the official hooks docs, not reasoned.** `Stop` fires "once per turn", not once when the session ends, with no signal marking the last turn; its exit 2 "prevents Claude from stopping, continues the conversation", so a repo that genuinely cannot push (the very rate limit that caused the incident) would get a session that will not end. `SessionEnd` is the once-per-session event and cannot block at all ("Can block? No" - exit 2 "shows stderr to user only"), which is the after-the-fact nagging the order explicitly refused. Warn-on-write plus deny-at-session-end inherits the broken half and buys nothing. So the deny sits on the write, where the false claim is actually made. **The false-positive trap is real but bounded, and the deny is escapable by telling the truth.** STATE.md is written BEFORE the session's final commit, so a session that batches its pushes does hold unpushed commits at that moment - but the global git rule already requires a push immediately after every commit, and the real tree bears that out (2026-08-16: 43 of 44 repos carrying a STATE.md had nothing unpushed; the one exception was `status=blocked` and honest). `status=blocked` and `status=in-progress` stay writable in the same single edit, so a session that cannot push is never wedged - only stopped from claiming otherwise. **No ratchet here, unlike the line limit above, and the asymmetry is the reason.** An oversized file needs many writes to come back under the limit, so denying the intermediate steps would make trimming impossible; a false `done` is corrected by changing one token in the write already being made. A "deny only the transition into done" variant was rejected outright: the common shape is a repo that ended `done` last session and writes `done` again this session, which such a rule waves straight through. It **fails OPEN** on every git uncertainty - no upstream, detached HEAD, missing remote-tracking ref, not a repo, git slow or absent - because 8 of those 44 repos have no upstream at all (one already `status=done`), and a confident denial resting on a measurement that never happened is the worse error. The board line is selected with `board.sh`'s own anchor (`^