Trader chat issue-reporting: turn a Matrix message into an incident #9

New issue

Closed

opened 2026-09-10 21:12:42 +00:00 by jmz · 1 comment

jmz commented

2026-09-10 21:12:42 +00:00

Owner

Goal: let any (allowlisted) chat participant report an issue to warden from the room, so traders can flag problems directly — a first-class inbound issue source.

Today: there is no chat->incident path. Detection is scheduled detectors/checks + mesh sensor findings. matrix_listen.py inbound is guidance-only for already-open incidents (see the guide-the-agent loop), gated to WARDEN_GUIDANCE_ALLOWED_SENDERS.

Proposal: a room listener that recognises a report syntax (e.g. @warden report <subject>: <text>), validates the sender against an allowlist + rate-limits it, and emits a Finding/opens an incident (source-tagged as chat-reported) that flows through the normal ladder. Reuse the existing MatrixListener poll + the Finding/engine.emit path.

Guardrails: sender allowlist (reuse the guidance allowlist pattern), per-sender rate limit, a distinct chat-report check_id/source so these are auditable and can't collide with detector findings (source-scoped fingerprints from issue #1), and they must NOT auto-trigger remediation without the same gate/verify as any other incident.

Fits existing seams; additive. Surfaced in a status review 2026-09-10.

**Goal:** let any (allowlisted) chat participant report an issue to warden from the room, so traders can flag problems directly — a first-class inbound issue source. **Today:** there is no chat->incident path. Detection is scheduled detectors/checks + mesh sensor findings. `matrix_listen.py` inbound is *guidance-only* for already-open incidents (see the guide-the-agent loop), gated to `WARDEN_GUIDANCE_ALLOWED_SENDERS`. **Proposal:** a room listener that recognises a report syntax (e.g. `@warden report <subject>: <text>`), validates the sender against an allowlist + rate-limits it, and emits a `Finding`/opens an incident (source-tagged as chat-reported) that flows through the normal ladder. Reuse the existing `MatrixListener` poll + the `Finding`/engine.emit path. **Guardrails:** sender allowlist (reuse the guidance allowlist pattern), per-sender rate limit, a distinct `chat-report` check_id/source so these are auditable and can't collide with detector findings (source-scoped fingerprints from issue #1), and they must NOT auto-trigger remediation without the same gate/verify as any other incident. Fits existing seams; additive. Surfaced in a status review 2026-09-10.

jmz commented

2026-09-10 22:00:19 +00:00

Author

Owner

Shipped in v0.19.0. Allowlisted (WARDEN_REPORT_ALLOWED_SENDERS, inert if unset, separate from guidance) Matrix @warden report/!warden report -> source-scoped (chat:) incident via engine.emit; per-sender sliding-window rate limit; check_id always namespaced (chat-report/chat-report:) so it matches no runbook and reaches humans, never auto-remediation (chat reports do not even reach the remediator). Whole-branch review: APPROVE, no findings.

Shipped in v0.19.0. Allowlisted (WARDEN_REPORT_ALLOWED_SENDERS, inert if unset, separate from guidance) Matrix `@warden report`/`!warden report` -> source-scoped (chat:<sender>) incident via engine.emit; per-sender sliding-window rate limit; check_id always namespaced (chat-report/chat-report:<sanitised>) so it matches no runbook and reaches humans, never auto-remediation (chat reports do not even reach the remediator). Whole-branch review: APPROVE, no findings.

jmz closed this issue

2026-09-10 22:00:19 +00:00

jmz referenced this issue from a commit

2026-09-10 22:00:20 +00:00

plan: trader chat issue-reporting (#9)

jmz referenced this issue from a commit

2026-09-10 22:00:20 +00:00

feat(chat): trader chat issue-reporting parser + gate + emit path (OSS #9 T1)

jmz referenced this issue from a commit

2026-09-10 22:00:20 +00:00

docs+version: chat issue-reporting docs, bump to 0.19.0 (OSS #9 T2)