Repository navigation
Buddy: a notice that brings nothing new gets exactly NO_REPLY (base-instructions-76, #612 point 3) - #645
Conversation
…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>
There was a problem hiding this comment.
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>
|
Thanks. The finding is accepted and fixed on You're right: a delegation can be done in
The test now also checks that a done delegation alone is never written as a sufficient reason for Checks: 210 tests across the ten Folder, try and public files; lint, typecheck and check:public pass. The English line still avoids |
agentrozjedemeai
left a comment
There was a problem hiding this comment.
@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.
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
.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, ordelegace seznamshows the delegation done), he answers exactlyNO_REPLYand nothing else. The user then gets nothing, in the chat or in Telegram.base-instructions-76, with the digest pin and the two tools assertions. The snapshots change only in the revision line.What doesn't change
Verification
tests/folder-buddy.test.ts(new test) checks, in both locales:.hermes.md, before "How you talk to the user";deception_hidepattern (do not … tell … the user).Risks and follow-ups
🤖 Generated with Claude Code