open/repo-mailbox
1
0
Fork 0
Code Issues Releases 5 Activity

feat(engine): let a message say it needs no answer, and count debt without losing sight of the rest

Browse source 
Rule 7 (0.5.0) shipped an obligation on a format with four fields, none of
which could tell a question from a notice. Two consequences fell out of that
gap: the injection had to name both terminal states and prefer neither, and
coord-count.sh had to treat every unarchived file as a reply owed. The fifth
field closes both.

coord-send.sh --fyi writes reply-expected: no; omitting it writes yes. Absent
means expected, because every message already on disk lacks the field - so a
forgotten flag over-counts debt, which is visible, rather than creating debt
nobody sees. A reply is not a special case. A broadcast is always no: --reply-to
resolves inside the recipient's own mailbox and a broadcast never lands there,
so there is no reply path to promise.

coord-count.sh now prints TWO integers per mailbox, not one. Replacing pending
with debt was the obvious reading of "count debt rather than unarchived
messages" and it is wrong here: board.sh counts the same inbox files itself, so
a debt-only count would put two different numbers under one name with nothing to
reconcile them, and a mailbox holding only notices would read as empty while its
messages keep being re-injected.

The field is frontmatter and only frontmatter - a body line claiming
"reply-expected: no" at column 0 cannot silence a real debt, and a file without
valid frontmatter counts as owing a reply.

Section 20's wording changed because its stated reason expired, but its second
half matters more now, not less: the marking is a DECLARATION, not an
instruction. Without that clause one word in an untrusted message becomes a
lever that mints obligations in another repo.

coord-selftest 136 -> 151.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016iJoZVmU2guTEZcMghk88z
This commit is contained in:
Kjell Tore Guttormsen 2026-07-31 15:46:14 +02:00
commit c0ccb1d611
8 changed files with 314 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

33
skills/coord-send/SKILL.md
View file

@ -64,6 +64,11 @@ Interface (body comes from a quoted heredoc so nothing in it is shell-expanded):
# retire one of THIS repo's own broadcasts (no subject, no body)
"$CSEND" --retract <broadcast-filename>
# a notice that needs no answer (any of the forms above)
"$CSEND" --to <repo> --subject "<subject>" --fyi <<'BODY'
<message body>
BODY
Sender identity (`--from`) defaults to the basename of the current git toplevel, so
you almost never set it. Outside a git repo there is no default — the send refuses
with exit 2 rather than naming itself after the working directory, so on a global
@ -71,6 +76,34 @@ surface (`~/repos`, `$HOME`) pass `--from <repo>` and make the identity a choice
Exit 0 = delivered; exit 2 = usage/IO error (read stderr and fix the arguments
rather than retrying blindly).
## Does it need an answer? (`--fyi`)
Every message declares whether its sender expects a reply. **Omitting `--fyi` is
the declaration that one is expected** — that is the default, and it is the safe
one: a forgotten flag over-counts what the recipient owes, which is visible,
while the opposite would create debt nobody ever sees.
Pass `--fyi` when the message is genuinely a notice: "shipped 0.9.0", "the spec
moved to docs/x.md", "your build is green again". Omit it when you are asking a
question, requesting a decision, or handing over work — anything where silence
would leave *you* blocked.
Two things this flag is not:
- **Not a way to lower the bar for the recipient.** Both terminal states stay
open on every message: a `--fyi` message must still be closed with
`coord-done`, and the recipient may still reply. The field says what *you*
expect, and the receiving session is told in as many words that it is a
declaration, not an instruction.
- **Not available on a broadcast.** `--broadcast` always writes
`reply-expected: no`, `--fyi` or not, because there is no reply path to a
broadcast at all (`--reply-to` resolves inside the recipient's own mailbox).
Passing it there is harmless and changes nothing.
A reply is not a special case either: `--reply-to` without `--fyi` expects one
back. When your reply closes the exchange — and it usually does — say so with
`--fyi` rather than leaving the other repo an open item.
## Choosing the target
- **One named repo** → `--to <repo>`. The repo name is its directory basename; use