Sneeze It

Before inviting external users, audit in pairs: (1) for every authed endpoint, find its sibling that was missed (preview vs execute); (2) for every guard recorded in memory, verify it exists in CODE not just data — data guards don't cover future cases; (3) pool.on('error') + idleTimeout/keepAlive on any node-postgres pool behind a proxy; (4) never derive test-isolation ports from process.pid under vitest threads — use VITEST_POOL_ID + bind-retry.

Why: Each find was a class, not an instance: the unauthenticated endpoint was the sibling of a correctly-gated one; the memory-vs-code drift would have silently emailed the first paying customer; the pool crash explained the recurring ETIMEDOUT-fixed-by-redeploy pattern. Pair-auditing catches what single-point review misses.

Failure mode: SUCCESS: Claude/Conatus ran a full security+site audit of orgtp.com and shipped all fixes same-day. Key finds: /api/v1/merge/preview had ZERO auth (cross-org claim leak); the "Victor hard-guard" existed only as DB skip-rows, not code; pg pool had no error listener (idle Railway-proxy socket death crashed the whole process); vitest's THREADS pool shares process.pid so per-pid test ports collided.

Scope: agent:Claude

Before any OTP deploy: (1) confirm which lineage prod actually runs by comparing origin/main against both worktrees (origin/main has matched the otp-audit-fixes lineage, NOT otp-platform's working branch); (2) deploy by pushing to origin main (Railway service is GitHub-connected to david-steel/OTP and auto-builds in ~2 min) instead of railway up when the CLI upload endpoint times out; (3) never railway up from a dirty otp-platform tree, since up snapshots the whole working directory including unrelated uncommitted changes

Why: railway up uploads the local tree as-is. Deploying from otp-platform (branch merge-execution-provenance + uncommitted edits) would have silently rolled back the 2026-06-10 security hardening and live-audit fixes and shipped unvalidated merge-execution code. The 7 consecutive upload timeouts were what prevented a prod regression; the GitHub push path is both safer (commits only) and faster (135s to live).

Failure mode: SUCCESS: Claude shipped OTP via GitHub push after railway up timed out 7x, and caught that prod runs the otp-audit-fixes worktree lineage, not otp-platform's checked-out branch

Scope: agent:Claude

Before wiring any client call to an OTP API endpoint, grep the route file for the literal app.<method>('path') registration and match the verb exactly -- OTP mixes verbs across resources (kpis use PATCH, todos use PUT). This is the API twin of the existing rule 'grep app.get for the literal href before adding nav links'.

Why: Fastify returns a bare 404 for an unregistered method+path combination, which looks identical to 'record not found' -- the bug shipped through typecheck, tests, and boot smoke because none of them exercise the client-side fetch verb against the route table.

Failure mode: Claude wired the new Close-it-out buttons to PATCH /api/v1/todos/:id by analogy with the KPI endpoints, but the todos update route is app.put() -- the call 404ed in prod the first time David used it

Scope: agent:Claude

When two sessions work the same OTP worktree: (1) before committing a SHARED file like server.ts, review the staged hunks (git diff --cached -- file) and drop hunks that are not yours; (2) after every push, confirm the CI run went green (gh run list) instead of assuming push = deployed -- Railway only deploys after the CI gate passes; (3) local tsc passing proves nothing about CI when untracked files exist, because the local tree can resolve modules the repo does not have.

Why: The deploy pipeline (push -> CI gate -> Railway) fails silently from the shell's perspective: git push succeeds, the site stays healthy on the old build, and the only signal is a missing feature or a CI email. Three deploys sat blocked for ~20 minutes before the /sw.js 404 exposed it.

Failure mode: Claude's web-push commit staged all of server.ts, sweeping in a parallel session's in-flight boot block that referenced ./db/ensure-strategy-reset.js -- a file the other session had not committed yet. Local typecheck passed (the file exists untracked on disk) but CI typecheck failed on the missing module, silently blocking three production deploys including a bug fix David was waiting on.

Scope: agent:Claude

Time-box, don't just retry: every Phase B scan gets a hard ~2-minute budget. If a tool schema or MCP server isn't available after one ToolSearch attempt, or a call hasn't returned, drop the source immediately and proceed to Deliver with what's in hand. Never block the run on a connecting MCP server.

Why: "Retry once" only covers calls that fail fast. Hung or still-connecting sources never error, so the rule never triggers and the run stalls in Gather. A partial briefing in 3 minutes beats a complete one that never arrives.

Failure mode: /good-morning stalled again (50 min, no briefing) on 2026-06-12. The 6/10 fix said "retry once then drop" but the run hung waiting on still-connecting MCP servers (google-workspace, gmail) and a Fireflies call instead of erroring, so the retry rule never fired. Second occurrence of the Gather-phase stall.

Scope: agent:Dan

When the CCM Speed To Lead sheet shows a negative STL (~-235 to -239 min), the sub-account's first-call timestamps are logged ~4 hours behind ET (Mountain Time CloudCRM sub-account config). Treat the lead as called and the STL value as unusable; never flag the project for slow lead response off a negative row. Currently affects all 6 Villa Sport Fitness projects.

Why: A naive STL scan either averages negative values (masking real slow responses portfolio-wide) or flags Villa for impossible call times. The -237 constant equals the 4-hour TZ offset, so it is diagnosable and filterable. Root-cause fix is the sub-account timezone setting, escalated to Dash 2026-06-12.

Failure mode: SUCCESS: Arin identified that negative Speed-To-Lead values in CCM-Stats are a timezone artifact, not bad calling

Scope: agent:Arin

Distinguish agent vs tool when sequencing monetization. AGENTS (adoption-driven, sticky surfaces) can ship free to drive usage. TOOLS that ARE the upsell (AI-assist, metered features) must be PAID from first use — never free-first. Build them paywalled/gated behind the wallet (GHL 'turn them on' pattern: free users SEE the button + 'add credits' upsell, never get the output free), ready to monetize the instant billing is live. Giving away the upsell trains users to expect it free and destroys the price.

Why: Free-first on a paid tool kneecaps the revenue model it was built for. The value prop of AI-assist is that it's metered; free distribution undercuts the exact margin lever (markup multiple) the whole Phase 2 wallet exists to capture.

Failure mode: Proposed shipping OTP's Rock AI-assist FREE-first to gather usage/price signal while Stripe paperwork clears. David corrected: this is a TOOL that is the upsell, not an agent. Free-first is wrong for it.

Scope: agent:Conatus

Never infer a 'David <> [Company]' calendar title is a sales/prospect call from the title alone. Check the attendee email domains first. Law-firm domains (e.g. mdwcg.com = Marshall Dennehey, thompsoncoe.com = Thompson Coe) and insurer domains (e.g. usli.com = USLI, an E&O carrier) signal a LEGAL/litigation call, not sales. When attorney or insurance-carrier domains are present, classify as legal/sensitive and never frame it as pipeline or prep it as an outreach/sales call.

Why: Misclassifying active litigation as a sales opportunity is a serious tone failure — it could lead an agent to draft sales follow-up to opposing counsel or surface a lawsuit as a 'win' in the pipeline. Attendee domains are the reliable signal the calendar title hides.

Failure mode: Radar/good-morning labeled a calendar event titled 'David <> Jeremy Golds Gym South Texas' as a sales prospect call. It was actually an E&O litigation defense call — Gold's Gym South Texas is suing Sneeze It, and the attendees were defense counsel and the E&O insurance carrier, not a prospect.

Scope: agent:Radar

On any rename/rebrand, grep every occurrence and fix ALL visible references in one pass (title, alt text, headings, signoff, sender from-name, comments). Don't propose a partial fix or leave 'good enough' residue. Verify with a re-grep of the rendered output.

Why: A customer email with mixed old/new branding looks careless and undoes the rename. Half-measures on a visible rename are worse than not starting.

Failure mode: When rebranding Orgy -> Ollie in the weekly email, I made one edit and framed leaving the rest (alt text, comments, from-name) as acceptable. David: "lets not be lazy fix it there are only 2 Orgy ref on the email."

Scope: agent:Conatus