soporte-action agent CLI was DEAD: three route/client drifts on the headless support path
Found 2026-08-16 attempting the FIRST real agent reply (SOP-VENUS-18). The headless support path had drifted from its only agent-facing client in three independent ways, each of which alone made an agent reply impossible. FIXED in this pass, unpushed at time of filing. 1. WRONG SECRET NAME. scripts/soporte-action.ts read SOPORTE_ACTION_SECRET; support-action/route.ts:48 reads SUPPORT_API_KEY and the VENUS-252 rename-transition fallback had been DROPPED. Failed at the local secret check before any request, so prod logs recorded nothing. 2. DEAD SELF-HEAL. The script's fallback ran a bare 'vercel env pull'; the vercel CLI is NOT installed on venus, so it exited 'vercel: not found' into a catch that swallowed it, turning a fixable missing-CLI into an indistinguishable 'secret not set'. Now 'npx --yes vercel'. 3. MISSING idempotencyKey. soporte-action-lib.ts:96 requires a UUID idempotencyKey on EVERY write op (reply/note/close/reopen); the script never sent one, so reply and close both died HTTP 400 even with correct auth. Now a fresh UUID per run, with --idempotency-key=<uuid> to REUSE on a deliberate retry (partial-unique + ON CONFLICT DO NOTHING makes the retry a true no-op; a fresh key on a blind retry would double-post and double-email). PLUS a separate defect fixed in the same pass, support-core.ts replyCore: the INSERT omitted authorAgentLabel while the sibling noteCore has always written it. Exactly backwards - a note never leaves the building, a staff reply is EMAILED to the reporter, so the reply is the one that most needs 'which agent sent this'. The column sat NULL on every headless reply ever sent; nothing surfaced it because the reply still succeeded and appEvents.detail.actingAgent still carried the label. Verified NULL on the SOP-VENUS-18 reply row. ROOT CAUSE, and the thing worth acting on: the route has unit tests, but NOTHING exercises the script against the route, so every contract change silently broke the only agent client. The three drifts accumulated across VENUS-252/VENUS-371 without one failing check. Proposed: a smoke test that runs the CLI against the route contract (or at minimum asserts the script's request body satisfies parseSoporteCommand), so the next required-field addition fails a gate instead of an agent. Ref: mem:reference_vercel_sensitive_env_unreadable (the secret is a write-only Vercel sensitive var; real value in ltm.md under the OLD name).
Sub-tickets — 1/1 done
Questions
Activity
-
SHIPPED 47cf144 v1.13.8, audit-venus-ca PASS:735a604 (reviewed SHA), post-deploy evidence verified (authorAgentLabel populated, deploy READY matching githubCommitSha). Fixed 4 defects in agent support-reply CLI: retired secret name, broken npx-vercel self-heal, missing idempotencyKey (HTTP 400 on every write), authorAgentLabel omitted from replyCore INSERT. VENUS-374 (smoke test) filed as follow-on.
-
SHIPPED + audit PASS. Fix SHA 735a604 (v1.13.5); proof SHA 47cf1446 (v1.13.8, the no-egress integration harness). audit-venus-ca verdict PASS at 2026-08-16T21:29Z, tag audit-venus-ca-mswbhuu6oavm. EVIDENCE CHAIN, each link measured not inferred: reviewed SHA -> Vercel deployment githubCommitSha=47cf1446e46809ad31816a892e92967a98b57b1e (readyState=READY, target=production, dpl_8vvpHTVC3XTK9ZwBTvecco1e4Yr6) -> live /api/health v1.13.8 dbOk=true at 21:27:13Z. The three CLI drifts (wrong secret name, dead self-heal, missing idempotencyKey) plus the replyCore authorAgentLabel omission are fixed and deployed. Proven two ways because neither alone was sufficient: (1) a prod note op on 1.13.5 exercised the DEPLOYED route header->sanitize->actor.agentLabel->column plumbing with zero email, and (2) scripts/pg-harness.sh + support-reply-agent-label.test.ts execute the actual edited INSERT on a real Postgres, falsification-verified both directions — reverting the fix fails on null vs the label, and shifting one bind parameter fails with body and authorAgentLabel written into each other. That second falsification is why the test asserts the WHOLE ROW: a label-only assertion passes a shifted parameter. STATED BOUNDARY, accepted by audit rather than papered over: the harness executes SOURCE at the deployed SHA, not code running inside Vercel. Nothing can run it against the artifact (it needs a loopback Postgres on venus). The only remaining unexercised segment is the Next compile step emitting that INSERT unchanged, and every route to testing it emails a real clinical user — declined twice by audit, and I agree. Also corrected in-flight: I misreported 47cf144 as v1.13.6. An ABORTED gitpush.sh still bumps package.json before .gitpush-pre.sh runs, so two lint-gate aborts burned 1.13.6 and 1.13.7. Recorded as mem:reference_aborted_gitpush_still_bumps_version. VENUS-374 (the root-cause gate) stays OPEN — see its own note; this harness does not cover it.