@ prefix in from field makes verified:null + TRUST mismatch #3

New Issue

2026-07-25T08:12:39Z

marfrit commented

2026-07-25 08:12:39 +00:00

Analysis

When a room message has from starting with @ (e.g. from=@foreman), the room API returns "verified": null. The bullpen-grinder coordinator requires "verified": true AND a check against TRUST. Both fail when from has a @ prefix.

The bug

verified: null check (line 651 of bullpen-grinder on boltzmann):

if not m.get("verified"):
    sys.stderr.write(f"@{nick}: refusing ask without verified:true from '{asker}'\n")
    since = mid; persist(since); continue

When from=@foreman, the room message has "verified": null. m.get("verified") returns None, not None is True → message is silently skipped.

TRUST check with @ prefix (line 648):

asker = (m.get("from") or "").lower()

asker becomes "@foreman" (with @), but TRUST in bullpen_config.py contains "foreman" (without @). The check asker not in TRUST evaluates to True → message is silently skipped.

Note: (m.get("to") or "").lstrip("@").lower() != nick ON line 650 DOES strip @ from the to field, but from is NOT stripped before checking against TRUST.

Impact

Messages dispatched by foreman (or any nick using @ prefix) are silently ignored by all bullpen-grinder coordinators. The coordinator appears unresponsive — no ack, no grind, just since = mid; persist(since); continue.

This wasted ~20 minutes of debugging during the mneme-namespace-ranking campaign: foreman dispatched the correct SPEC with relative paths (message 1559, from=@foreman, verified: null) but @py never saw it. The issue was only discovered when comparing working dispatches (from=foreman, verified: true) vs failing ones.

Room reference

Compare:

Message	from	verified	Accepted?
1512	`foreman`	`true`	✅ (working)
1516	`foreman`	`true`	✅ (working)
1559	`@foreman`	`null`	❌ (silently skipped)
1565	`foreman`	`true`	✅ (after fixing the `@` prefix)

Hosts

Host	Role
hertz	Room API — how its `room_say` tool sets `from` vs `verified`
noether	bullpen-grinder coordinators — where the check runs
orca	Foreman's opencode instance — how foreman formats its `room_say` messages

Suggested fixes

Fix 1 — bullpen_config.py (TRUST on noether): Strip @ prefix from asker before checking TRUST:

asker = (m.get("from") or "").lower().lstrip("@")

Fix 2 — bullpen-grinder (verified check): The verified requirement may be intentional; but if foreman's posts through its opencode session don't carry verified: true, either:

Ensure foreman's room_say format produces verified: true (possibly a room API issue)
Or relax the verified requirement for trusted nicks

Fix 3 — Room API (hertz): Investigate why from=foreman produces verified: true but from=@foreman produces verified: null. Possibly the @ prefix triggers different handling.

## Analysis When a room message has `from` starting with `@` (e.g. `from=@foreman`), the room API returns `"verified": null`. The bullpen-grinder coordinator requires `"verified": true` AND a check against `TRUST`. Both fail when `from` has a `@` prefix. ### The bug 1. **`verified: null` check (line 651 of bullpen-grinder on boltzmann):** ```python if not m.get("verified"): sys.stderr.write(f"@{nick}: refusing ask without verified:true from '{asker}'\n") since = mid; persist(since); continue ``` When `from=@foreman`, the room message has `"verified": null`. `m.get("verified")` returns `None`, `not None` is `True` → message is silently skipped. 2. **TRUST check with `@` prefix (line 648):** ```python asker = (m.get("from") or "").lower() ``` `asker` becomes `"@foreman"` (with `@`), but `TRUST` in `bullpen_config.py` contains `"foreman"` (without `@`). The check `asker not in TRUST` evaluates to `True` → message is silently skipped. Note: `(m.get("to") or "").lstrip("@").lower() != nick` ON line 650 DOES strip `@` from the `to` field, but `from` is NOT stripped before checking against `TRUST`. ### Impact Messages dispatched by foreman (or any nick using `@` prefix) are silently ignored by all bullpen-grinder coordinators. The coordinator appears unresponsive — no ack, no grind, just `since = mid; persist(since); continue`. This wasted ~20 minutes of debugging during the mneme-namespace-ranking campaign: foreman dispatched the correct SPEC with relative paths (message 1559, `from=@foreman`, `verified: null`) but @py never saw it. The issue was only discovered when comparing working dispatches (`from=foreman`, `verified: true`) vs failing ones. ### Room reference Compare: | Message | from | verified | Accepted? | |---|---|---|---| | 1512 | `foreman` | `true` | ✅ (working) | | 1516 | `foreman` | `true` | ✅ (working) | | 1559 | `@foreman` | `null` | ❌ (silently skipped) | | 1565 | `foreman` | `true` | ✅ (after fixing the `@` prefix) | ### Hosts | Host | Role | |---|---| | **hertz** | Room API — how its `room_say` tool sets `from` vs `verified` | | **noether** | bullpen-grinder coordinators — where the check runs | | **orca** | Foreman's opencode instance — how foreman formats its `room_say` messages | ### Suggested fixes **Fix 1 — `bullpen_config.py` (TRUST on noether):** Strip `@` prefix from `asker` before checking TRUST: ```python asker = (m.get("from") or "").lower().lstrip("@") ``` **Fix 2 — `bullpen-grinder` (verified check):** The `verified` requirement may be intentional; but if foreman's posts through its opencode session don't carry `verified: true`, either: - Ensure foreman's `room_say` format produces `verified: true` (possibly a room API issue) - Or relax the `verified` requirement for trusted nicks **Fix 3 — Room API (hertz):** Investigate why `from=foreman` produces `verified: true` but `from=@foreman` produces `verified: null`. Possibly the `@` prefix triggers different handling.

marfrit referenced this issue from a commit

2026-07-25 08:41:12 +00:00

serve(): strip @ prefix from asker + relax verified check for TRUSTed nicks (fixes #3)

marfrit closed this issue

2026-07-25 08:41:12 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marfrit/bullpen#3