Skip to content

Buddy: a notice that brings nothing new gets exactly NO_REPLY (base-instructions-76, #612 point 3) - #645

Merged
immakermatty merged 2 commits into
mainfrom
agent/DEV-6676-buddy-no-reply
Oct 25, 2026
Merged

immakermatty merged 2 commits into
mainfrom
agent/DEV-6676-buddy-no-reply

Conversation

@immakermatty

Copy link
Copy Markdown
Contributor

Refs #612 (point 3), plan DEV-6676.

Why

On Ring 0 on 2026-10-25, after Lazurio/hermes-agent 0.22.4-lazurio.2 reached Bob's Buddy, Bob asked Buddy in his chat in Lazurio to have a bot write one word and report back. The result came back into the web chat, so the per-turn channel (hermes-agent#14) works. But Buddy said it twice, within a minute: "Bobe, Scout napsal: OK." and then "Bobe, Scout napsal pouze: OK.". He told the person himself and answered Delegace's notice again. #612 point 3 describes exactly this pattern.

That rule waited for a Hermes release in which the web chat doesn't show the silence marker. 0.22.4-lazurio.2 carries that fix (hermes-agent#11), and it is live on Bob and Mattyčus since today.

What changes

  • Buddy's .hermes.md, among the notices' rules, in cs and en: when a notice tells him nothing the user doesn't know yet (he already told them the result, or delegace seznam shows the delegation done), he answers exactly NO_REPLY and nothing else. The user then gets nothing, in the chat or in Telegram.
  • Template revision base-instructions-76, with the digest pin and the two tools assertions. The snapshots change only in the revision line.
  • The decisions get an addendum after revision 75's.

What doesn't change

  • Every other rule of the layer.
  • Delegace itself.
  • AGENTS.md of any Folder: the golden Environments' digests are unchanged.

Verification

  • tests/folder-buddy.test.ts (new test) checks, in both locales:
    • the exact rule in .hermes.md, before "How you talk to the user";
    • the marker appears there exactly once;
    • no other file of the layer names it.
  • The English wording avoids Hermes's deception_hide pattern (do not … tell … the user).
  • 210 tests across the ten Folder, try and public files pass; lint, typecheck and check:public pass.

Risks and follow-ups

  • Behaviour isn't proven by text. The next Ring 0 check on Bob, after this reaches his Platform, is a web Delegace round trip with exactly one report from Buddy.
  • Open question: why Buddy reported before the notice. Either he waited for the bot in the same turn, despite "you never wait for the answer", or a repeated notice came. PROTOTYPE BUDDY is reading Bob's Delegace record. If it was a repeated notice, a follow-up may be needed in Delegace or in the rule about confirming a notice.

🤖 Generated with Claude Code

…nstructions-76, #612 point 3)

On Ring 0 on 2026-10-25 Buddy told Bob a bot's result twice in his chat in
Lazurio: once himself, and again when Delegace's notice came. Buddy's rules
now say that when a notice tells him nothing the user does not know yet, he
answers exactly `NO_REPLY` and nothing else. Hermes delivers nothing for that
marker on Telegram, and in the web chat from Lazurio/hermes-agent
0.22.4-lazurio.2 (#11), which this rule waited for.

Template revision base-instructions-76; tests check the rule in both locales,
its place before how Buddy talks to the user, and that no other layer file
names the marker. Decisions: an addendum after revision 75's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@agentrozjedemeai agentrozjedemeai left a comment •

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: src/folder/buddy.ts:144-145 gives two alternative reasons to return NO_REPLY: "already told them the result, OR delegace seznam shows the delegation done" (also "nebo ... vyřízená"). A delegation can be done before its first result notice is conveyed to the user. In that case the second condition is true while the user has not heard the result, so Buddy could suppress the only report. This contradicts the intended "nothing the user does not know yet" gate and the adjacent rule to report a result in Buddy's own words. Please make completion status a clue to inspect, never sufficient for silence: return NO_REPLY only when the notice adds no information not already communicated to the user; when uncertain, report the new outcome. Adjust the cs/en text, the decision addendum, and the test so it explicitly guards the done-but-not-yet-told case, rather than only pinning the literal wording.

Exact head 4ad3677: 47 focused tests passed; lint and typecheck passed. The generated cs/en layer passed threat_patterns.scan_for_threats at all/context/strict scopes at Hermes v0.22.4-lazurio.2, with no deception_hide hit. NO_REPLY matches LIVE_GATEWAY_SILENT_MARKERS. Revision 76, digest pin, tools assertions and snapshot-only revision replacements check out. check:public was not independently completed here because the shared heavy-command lock wait timed out; CI checks were green at the pre-write gate. Text tests do not prove runtime behavior, as the addendum correctly notes.

…ld the user (#645 review)

A delegation can be done in `delegace seznam` before its result reached the
user, so "done" was never a sufficient reason for silence (Pablo's review).
The rule now keys on what Buddy has told the user; a done delegation is only a
clue, and when unsure he tells the user the result. The test pins that a done
delegation alone is never written as a reason for NO_REPLY (it fails on the
first wording), and the decisions addendum says the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@immakermatty

Copy link
Copy Markdown
Contributor Author

Thanks. The finding is accepted and fixed on df85584a.

You're right: a delegation can be done in delegace seznam before its result reached the user, so "or the delegation is done" could have silenced the only report. The rule now keys on what Buddy has told the user:

  • cs: „Když ti upozornění neřekne nic, co jsi uživateli ještě neřekl (třeba výsledek, který jsi mu už sám oznámil), odpovíš přesně NO_REPLY a nic jiného. Vyřízená delegace v delegace seznam je jen vodítko, nikdy důvod mlčet. Když si nejsi jistý, výsledek uživateli řekneš. …“
  • en: "When a notice tells you nothing you have not already told the user (such as a result you reported yourself), you answer exactly NO_REPLY and nothing else. A delegation shown done in delegace seznam is only a clue, never a reason to keep quiet. When unsure, you tell the user the result. …"

The test now also checks that a done delegation alone is never written as a sufficient reason for NO_REPLY, in both locales; it fails on the first wording, which I checked by reverting it. The decisions addendum says the same. Revision 76 is unchanged, since it was never released; its digest pin is updated.

Checks: 210 tests across the ten Folder, try and public files; lint, typecheck and check:public pass. The English line still avoids deception_hide.

@agentrozjedemeai agentrozjedemeai left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@immakermatty Approved on exact head df85584. The cs/en rule now silences only a notice containing nothing Buddy has not already told the user; a done delegation is explicitly only a clue, and uncertainty requires reporting the result. The regression guard covers the former done-as-alternative wording in both locales; the decisions addendum and unchanged unreleased revision 76 with its updated digest align. In an isolated checkout: 66 focused tests passed across four files, lint, typecheck, check:public, and git diff --check passed. I independently scanned the new English line with Lazurio/hermes-agent v0.22.4-lazurio.2 threat_patterns.scan_for_threats: no findings at all/context/strict, including deception_hide. Current PR checks are green and there are no unresolved threads. Generated text/tests do not prove Buddy runtime behavior; the planned Ring 0 confirmation remains necessary. Review only; no merge or release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants