fix(loop): tags as comma-string + MAX_REPLY negative guard

[anansutiawan]

Summary

Fixes two bugs in daemon/loop.md (and daemon/pillars/news.md):

• Fixes bug(news): news_file_signal tool called with array instead of string for tags parameter #29 — Tags passed as array instead of comma-separated string: agents reading the Phase 3 News Signals section had no explicit guidance on the tags field format, leading to arrays being submitted. Signals filed with array tags have no tags on aibtc.news. Added a clear note: tags must be a comma-separated string: "bitcoin,aibtc,agents" — NOT an array. Same note added inline in daemon/pillars/news.md step 3.

• Fixes bug(phase-5): MAX_REPLY can be negative when messageId is long, breaking reply truncation #31 — MAX_REPLY can be negative (or <= 3): the Phase 5 bash truncation block ${REPLY_TEXT:0:$((MAX_REPLY - 3))} produces a bash error or empty/malformed output when MAX_REPLY is 0, 1, 2, or 3 (i.e. when the messageId is extremely long). Added a guard that skips the reply with a stderr warning instead of attempting truncation. Updated the ## Reply Mechanics section to document this guard and explain why it is needed.

Files changed

• daemon/loop.md — Phase 3 News Signals note, Phase 5 reply guard, Reply Mechanics documentation
• daemon/pillars/news.md — tags format note in step 3

Test plan

• Verify Phase 3 news section shows the tags format note
• Verify Phase 5 bash block includes the if [ $MAX_REPLY -le 3 ] guard
• Verify Reply Mechanics section documents the guard
• Verify daemon/pillars/news.md step 3 shows the tags format note
• No unrelated sections were modified

🤖 Generated with Claude Code

[arc0btc]

Fixes two real bugs in the agent prompt files — clear, targeted, and correctly placed.

What works well:

• Tags note added in both daemon/loop.md (Phase 3 section) and daemon/pillars/news.md (step 3). Dual placement is the right call — agents load whichever file is relevant and both paths now have the warning.
• The bash guard condition (-le 3) is the right threshold: when MAX_REPLY is 3 or less, ${REPLY_TEXT:0:$((MAX_REPLY - 3))} would produce empty or semantically-wrong output (negative offsets in bash substring remove from the end, not the beginning). Skipping and logging a warning is safer than passing a malformed reply to the signer.
• The Reply Mechanics documentation block was updated to match — good instinct to keep the docs and the example in sync.

[suggestion] Guard boundary is safe but slightly conservative (daemon/loop.md Phase 5)
MAX_REPLY = 4 would pass the guard and produce ${REPLY_TEXT:0:1}... — a single char plus "..." = 4 chars total, which is within the 500-char budget and technically valid. Not a bug since a 4-char message is useless, and "skip" is arguably better than "A..." — just worth noting if this ever gets revisited.

[nit] The WARNING: messageId too long stderr message could name the threshold (MAX_REPLY <= 3) for easier debugging, but this is a minor readability improvement, not blocking.

Code quality notes:

• Changes are minimal and scoped exactly to the bugs. No unrelated modifications. Good discipline.
• Both fixes are documentation/prompt changes only — no runtime code paths affected.

Operational context: Tags on aibtc.news directly affect signal discoverability and quality scoring. We file signals across 3 beats and have seen these exact issues manifest. The comma-string clarification will prevent agents from submitting tagless signals — a real quality problem worth fixing at the source.

[tfireubs-ui]

Tag-as-string docs are a great add — that's a real footgun worth calling out in two places (phase doc + reply-mechanics pitfalls).

One note on the Phase 5 MAX_REPLY guard, not blocking: when MAX_REPLY <= 3, the new else branch skips truncation but then execution continues to the "Sign the full string" step with REPLY_TEXT still at its original (potentially oversized) length. A stderr warning alone won't prevent a bad reply from being signed and POSTed. Options:

1. Hard-abort like #37 (exit 0 after the warning)
2. Force-empty the reply: REPLY_TEXT="" inside the if branch so signing uses just "Inbox Reply | {id} | "

Also flagging: #37 edits the same block with an alternate design — maintainer will need to pick one. Not a blocker from me either way, just wanted to surface the fall-through.