forgejo-admin/herdrmastr
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Label agents by project/branch instead of pane id #8

Merged
forgejo-admin merged 2 commits from mail-agent-labels into main 2026-08-01 00:29:15 +00:00
Conversation 0 Commits 2 Files changed 4 +72 -11
forgejo-admin commented 2026-08-01 00:22:52 +00:00
Owner
Copy link

Follow-up to #7.

The problem

A status report from an agent read:

"w2E:p1 building the log-tail op — I'll relay when it reports."

Useless to the human it was written for. They think in projects and branches; a
pane id tells them neither, and decoding it means running herdr agent list and
matching by hand.

Why the skills couldn't fix this alone

The obvious move is "tell agents to use branch names." That fails, because an
agent's only handle on a peer is whatever the doorbell showed it. The doorbell
said w2E:p1. You cannot instruct an agent to use a name it was never given.

So the label is derived at send time from the sender's checkout and stored on the
message:

worktrees/<project>/<branch>  →  "<project>/<branch>"
any other checkout            →  its directory name
no live agent for the pane    →  the pane id (unchanged)

A claimed mail name still wins. Derived from cwd rather than the herdr agent
name because cwd is always present — several live agents have no name at all,
and nobody remembers to run mail name.

Verified against all 10 live agents at the time:

w2E:p1  → celilo/module-log-tail               ← the one that prompted this
w1S:p1  → lunacycle/fix-prod-smoke-failures
wR:p1   → configure-ui/worktree-dict-slice-3
w1D:p1  → lunacycle                             (not a worktree)
w2A:p1  → herdrmastr                            (not a worktree)

End to end: a message sent after this stores from="herdrmastr" where one sent
minutes earlier stored from="w2A:p1".

The pane id is not lost — it moves to mail read's From: line in brackets,
which is the one place you need it (addressing a new message). mail reply <id> needs neither. Inbox column widened to fit the longer names.

Messages sent before this keep their stored pane id. The label is captured at
send time; re-deriving on display would gain nothing for senders since reaped,
and would cost a live lookup per row.

Skills updated with the concrete bad/good example, in both herdr-spawn (which
knows <project> and <slug> at spawn time) and herdr-mail.

Also: corrects an overstatement from #7

#7 documented "a ※ recap: pane swallows Enter, so doorbells never land."
False. herdr agent prompt submits fine there — confirmed by delivering into
a pane displaying one. What actually fails is send-keys enter flushing input
already parked in the line, which is a different (real) bug affecting typed
text, not mail. Narrowed here and in #6.

As filed, that wording would have sent someone hunting a mail-delivery bug that
does not exist.

Testing

  • agent_label exercised against all 10 live agents (table above).
  • Live send — payload stores the label, from_pane still carries the id.
  • mail selftest — passes.
  • python3 -m py_compile herdr-mail/bin/mail — clean.

No CI in this repo, so none of this is machine-gated.

🤖 Generated with Claude Code

Follow-up to #7. ## The problem A status report from an agent read: > *"w2E:p1 building the log-tail op — I'll relay when it reports."* Useless to the human it was written for. They think in projects and branches; a pane id tells them neither, and decoding it means running `herdr agent list` and matching by hand. ## Why the skills couldn't fix this alone The obvious move is "tell agents to use branch names." That fails, because **an agent's only handle on a peer is whatever the doorbell showed it.** The doorbell said `w2E:p1`. You cannot instruct an agent to use a name it was never given. So the label is derived at send time from the sender's checkout and stored on the message: ``` worktrees/<project>/<branch> → "<project>/<branch>" any other checkout → its directory name no live agent for the pane → the pane id (unchanged) ``` A claimed `mail name` still wins. Derived from `cwd` rather than the herdr agent name because `cwd` is always present — several live agents have no name at all, and nobody remembers to run `mail name`. Verified against all 10 live agents at the time: ``` w2E:p1 → celilo/module-log-tail ← the one that prompted this w1S:p1 → lunacycle/fix-prod-smoke-failures wR:p1 → configure-ui/worktree-dict-slice-3 w1D:p1 → lunacycle (not a worktree) w2A:p1 → herdrmastr (not a worktree) ``` End to end: a message sent after this stores `from="herdrmastr"` where one sent minutes earlier stored `from="w2A:p1"`. The pane id is not lost — it moves to `mail read`'s `From:` line in brackets, which is the one place you need it (addressing a *new* message). `mail reply <id>` needs neither. Inbox column widened to fit the longer names. Messages sent before this keep their stored pane id. The label is captured at send time; re-deriving on display would gain nothing for senders since reaped, and would cost a live lookup per row. Skills updated with the concrete bad/good example, in both `herdr-spawn` (which knows `<project>` and `<slug>` at spawn time) and `herdr-mail`. ## Also: corrects an overstatement from #7 #7 documented "a `※ recap:` pane swallows Enter, so doorbells never land." **False.** `herdr agent prompt` submits fine there — confirmed by delivering into a pane displaying one. What actually fails is `send-keys enter` flushing input *already parked* in the line, which is a different (real) bug affecting typed text, not mail. Narrowed here and in #6. As filed, that wording would have sent someone hunting a mail-delivery bug that does not exist. ## Testing - `agent_label` exercised against all 10 live agents (table above). - Live send — payload stores the label, `from_pane` still carries the id. - `mail selftest` — passes. - `python3 -m py_compile herdr-mail/bin/mail` — clean. No CI in this repo, so none of this is machine-gated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) 
Filed and documented as "a recap pane swallows Enter, so doorbells never
land". Wrong, and overstated in a way that would send someone chasing a
delivery bug that is not there.

`herdr agent prompt` submits normally on a recap pane — confirmed by
delivering to w2D:p1 while it displayed one; the doorbell submitted with no
nudge. What actually fails is `send-keys enter` flushing text that is
ALREADY parked in the input line, which is the case that stranded three
queued human instructions earlier.

The five stalls that motivated the original fix were on panes without a
recap and are unaffected by this correction.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An agent's only handle on a peer is whatever the doorbell showed it. That was
a pane id, so status reports came back reading "w2E:p1 building the log-tail
op" — which the human then has to decode into "which branch is that?".

Fixing this in the skills alone would not work: you cannot instruct an agent
to use a name it was never given. So the label is derived at send time from
the sender's checkout — worktrees/<project>/<branch>, else the checkout's
directory name, else the pane id — and stored in the message. A claimed
`mail name` still wins.

Derived from cwd rather than the herdr agent name because cwd is always
present; several live agents have no name at all, and nobody remembers to run
`mail name`.

The pane id survives in `mail read`'s From: line in brackets, which is the one
place you would need it to address a new message. `mail reply <id>` needs
neither.

Verified against all 10 live agents: every worktree agent resolves to
project/branch, non-worktree checkouts to their directory name. End to end, a
sent message now stores from="herdrmastr" where it previously stored
from="w2A:p1".

Skills updated to match, with the concrete bad/good example.

Messages sent before this keep their stored pane id — the label is captured at
send time, and re-deriving it on display would gain nothing for senders that
have since been reaped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo-admin/herdrmastr!8
No description provided.