PM DB-fed triage loop: support-ticket + access-request events DM PM; PM reads DB + triages (bs-mqotdmmk6b5)

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-22
• wi-cli-venus blocked · 2026-06-22
  HELD on Elazar GO (feature build, not a fly-solo fix — asked in final report 2026-06-22). Adopted fleet-wide in bs-mqotdmmk6b5 (3/3 PMs). SCOPE (Mars = BOTH legs, unlike pluto access-only): - On supportTicket INSERT + accessRequest INSERT, emit a PM-addressed aro:mars DM with a DB row-summary (id, requester, subject/category, key fields). Reuse the EXISTING applog NOTIFY->listener->hub-DM rail (the EVO-15/self-probe rail); new trigger + category, NOT new infra. - PM hydrates full context FROM THE DB (db-mars read), never the URL (admin-authed => PTD render-GET is 302; DB-native triage sidesteps it). - PM classifies -> reversible fix (read/render/404/data-source, DB-only updateSupportTicket) = fly-solo with coder/db, visible in aro:mars. GATES (only 2 reach Elazar, pre-analyzed): 1) Access GRANT (approveRequest = users/userRoles INSERT + email) — Elazar-gated; PM hands a verdict line: requester/email / NEW vs DUP-of-Z (gmail dot/+tag/googlemail/institutional via canonicalize) / domain allowlisted? / recommend APPROVE|REJECT|MERGE. 2) Material/sensitive outbound — PM drafts, Elazar go/no-go. Routine solicited support replies ('fixed, retry') PM SENDS. NOTES: identity-dedup leans on Mars's canonicalizeEmail (MARS-151, already shipped). Two pre-existing landmines on both [id] loaders (no isUuid guard -> malformed-uuid 500) are SEPARATE, left as-is. On GO: dispatch coder (app trigger+rail-category+triage UI surface) + db-mars (trigger/category DDL, pre-apply audit review). Reversible build.
• wi-cli-venus commented · 2026-07-03
  Converged fleet spec (DECISION bs-mr4xk6nnuu2, 4-PM): expand this WI to the ticket-triage pipeline. (1) DB trigger on supportTickets insert = durable SSOT signal; (2) INSTANT ack app-side at CREATE ('Hemos recibido tu solicitud de <subject>'), never on-claim, never resuelto pre-verify; (3) dedicated venus systemd notify daemon (seam A2, NOT folded into applog), per-app clone via env-swap; (4) daemon DMs the LIVE aro PM (hub lookup); (5) CLAIM = atomic UPDATE...WHERE claimedBy IS NULL on the bwi mirror row (no new side table; supportTickets untouched by claim/watchdog); (6) router classifies to a SUGGESTION only — fix TRIGGER is a PM/human turn, NEVER daemon auto-dispatch (EVO-26 fly-solo-auto disabled); (7) autofix = reversible+high-certainty+NON-AUTHZ, grants/roles/clinical Elazar-gated; (8) verified write-back via secret-gated internal support-reply endpoint (Pluto PLUTO-444 reference); (9) watchdog unclaimed/unresolved N-min -> re-alert (MARS-199 shape). Transport: LISTEN/NOTIFY needs direct-5432 DSN, else poll-timer (per-app). Sequence: venus first-mover reference proves the clone, then Mars replicates. Unit-side rail owned by nw-venus (scrp- standard). HELD: do not build until Elazar's epic-priority call.
• wi-cli-venus spec · 6w ago
  Elazar GO 2026-09-02: build this per VENUS-137/pluto template, but DM target MUST resolve dynamically at send-time via GET {HUB_URL}/aro/list?aro=mars -> .pm field (confirmed live endpoint, v2-hub.mjs:213), NOT a hardcoded PMT_PM env var. Reason: checked venus's own live PMT_PM=pm:venus just now - actual current aro:venus PM is audit-venus-ca, not pm-venus-cc. The hardcoded pattern is already stale in production. nw-venus-cc owns venus-host unit+overlay once daemon script (schema-specific: mars supportTickets/accessRequests LISTEN/NOTIFY) + Supabase-side trigger/grants exist - same split as VENUS-137 (unit=nw-venus-cc, triggers/grants=db-*, daemon script=coder/solo-*). Routed to current mars PM (coder-mars-cc) + pm-mars-cc via DM.
• wi-cli-venus assigned · 6w ago
  coder-mars-cc
• wi-cli-venus progress · 6w ago
  Taken by coder-mars-cc (current aro:mars PM + coder seat) on the 2026-09-02 Elazar GO, relayed independently by nw-venus-cc (aro:nw) and pm-mars-cc. Three-lane split per VENUS-137 confirmed: db-mars-cc = trigger + grants on supportTickets/accessRequests, coder-mars-cc = daemon script, nw-venus-cc = venus systemd unit + env overlay. DB leg dispatched to db-mars-cc same turn so it runs in parallel with the daemon.
• wi-cli-venus note · 6w ago
  coder-mars-cc confirmed payload=number-only per channel ({ticketNumber}/{requestNumber} via two dedicated NOTIFY channels, no kind/table needed - LISTEN channel itself disambiguates). db-mars-cc dispatched to strip email/createdAt/priorityValue etc from the already-applied migration 125 payloads. Act-not-notify confirmed: claim+read-from-DB+classify+fix-or-escalate per bs-mr4xk6nnuu2, access grants/material outbound still Elazar-gated. Flagged risk: live PM==coder-mars-cc (same agent), so no second reader if it silently stops acting - watchdog re-alert (unclaimed/unresolved after N min) is the sole mitigation, being built as required not optional.
• wi-cli-venus assigned · 4w ago
  coder03-mars-ca