Sneeze It

Every agent writes to exactly one shared state file. The morning briefing compiler reads all 8 files. No agent reads another agent's data source directly.

Why: The reporting agent and the spend monitor both queried the Meta API independently. They returned different numbers because of timing differences. Per-agent state files with timestamps eliminated the contradiction.

Failure mode: Two agents query the same API 4 minutes apart. Spend numbers differ by $340. Account manager questions data integrity. Trust in the system drops for weeks.

Scope: All 8 agents. 8 state files.

The spend monitoring agent checks pacing every 6 hours and alerts when any account exceeds 115% of daily budget. Alert goes to Slack channel, not DM.

Why: DMs get buried. Channel alerts create shared visibility. The 115% threshold balances sensitivity with noise. At 110%, too many false alarms. At 120%, alerts arrive too late to prevent significant overspend.

Failure mode: Agent DMs the founder at 2 AM about a 112% overspend. Founder silences notifications. Next morning, account is at 145%. Channel alert would have been seen by the AM who starts at 7 AM.

Scope: All client ad accounts with daily budgets over $100.

No agent modifies campaign settings. Agents read, analyze, and recommend. A human executes changes in the ad platform.

Why: We gave an agent write access to bid adjustments in month 1. It optimized for CPA without understanding the client's brand awareness goal. Client called asking why impressions dropped 60%.

Failure mode: Agent reduces bids on a brand campaign. Impressions crater. Client sees competitors appearing in their branded search results. Emergency call at 8 PM.

Scope: All ad platform integrations. Read-only API access only.

Client communication drafts include a confidence tag: ROUTINE (send after quick review), SENSITIVE (requires careful review), or ESCALATE (founder must review personally).

Why: Not all client emails need the same level of scrutiny. Performance reports are routine. A response to a complaint is sensitive. A cancellation save attempt is escalate.

Failure mode: Account manager rubber-stamps a SENSITIVE email about a billing discrepancy. Email contains a number the agent hallucinated from a different client's account. Client catches the error and questions our competence.

Scope: All client-facing email drafts generated by the EA agent.

The Reporting Agent owns weekly performance summaries. The Spend Monitor owns daily pacing alerts. They never overlap. The Reporting Agent does not alert on daily spend. The Spend Monitor does not summarize weekly trends.

Why: When both agents commented on spend, the weekly report contradicted the daily alert because they used different time windows. Strict lane separation fixed it within one day.

Failure mode: Weekly report says spend is on track while daily alert says overpacing by 18%. Both are correct for their time window but the client sees both and panics.

Scope: Analytics and monitoring functions.

The Prospecting Agent researches potential clients and drafts outreach. It does NOT have access to current client data, performance metrics, or internal Slack channels.

Why: Information isolation prevents the prospecting agent from accidentally referencing current client data in outreach. It also prevents scope creep into account management territory.

Failure mode: Prospecting agent discovers a current client's competitor in the pipeline. References competitor strategy details in outreach email, inadvertently revealing client intelligence to a prospect.

Scope: Prospecting and business development function only.

The Internal Ops Agent handles team task tracking, meeting prep, and internal briefings. It is the only agent that reads the project management tool. Other agents request project status through its state file.

Why: Multiple agents querying the PM tool created API rate limit issues and inconsistent status views. Centralizing PM access through one agent made project data consistent across the organization.

Failure mode: Three agents query Asana simultaneously. Rate limit hit. Two get stale cached data, one gets current. Briefing mixes old and new project status without any indication of which is which.

Scope: All project management data access.

Morning briefing runs at 6:30 AM. All scanner agents must complete by 6:00 AM. Any agent not finished by 6:00 AM is marked stale in the briefing. The briefing never waits for a slow agent.

Why: One slow API call used to delay the entire briefing by 20 minutes. The founder's morning routine depends on the briefing being ready at 6:30 sharp. Stale data with a visible warning is always better than no briefing at all.

Failure mode: Google Ads API times out at 5:50 AM. Without the hard deadline, briefing delayed until 6:47 AM. Founder starts the day without context and makes a client call unprepared.

Scope: Morning briefing pipeline. 8 scanner agents, 1 compiler.

When two agents need to reference each other's output, they read from state files, never from conversation context or memory. State files are the single source of truth for all cross-agent data.

Why: Conversation context drifts between sessions. A state file written 2 hours ago is more reliable than an agent's memory of what another agent reported yesterday. We caught 3 errors in one week from memory-based cross-referencing.

Failure mode: Reporting agent remembers yesterday's spend number instead of reading today's state file. Weekly report goes out with yesterday's numbers. Client catches the error before the account manager does.

Scope: All cross-agent data references.

Escalation path for client issues: Agent detects anomaly, flags in state file, briefing highlights it, account manager reviews, founder involved only if client relationship is at risk.

Why: Early on, every anomaly went directly to the founder. 15 alerts per day within the first two weeks. Alert fatigue set in by week 3. Now the AM layer filters signal from noise and the founder sees 2-3 meaningful items per day.

Failure mode: Without the AM filter layer, founder gets desensitized to alerts. Treats everything as noise. Misses a real problem that costs a client. Client churns.

Scope: All client-facing anomaly detection and escalation.

Reports generated before 7 AM use yesterday's final numbers, not partial today numbers. Never mix time windows in a single report.

Why: Partial-day data creates misleading trends. A report showing "spend is down 60%" at 6 AM because only 6 hours of data exist causes unnecessary panic every single time.

Failure mode: Client receives early morning report showing spend down 60%. Calls account manager in alarm. AM spends 30 minutes explaining that it is just early-morning partial data. Happens three times before we fix the rule.

Scope: All reports generated before noon.

When a client has not been contacted in 14+ days, flag it in the briefing regardless of how well their campaigns are performing. Silence is a churn signal even when the numbers are good.

Why: Three of our churned clients in the past year had strong performance numbers at the time they left. They did not leave because of results. They left because they felt ignored and undervalued.

Failure mode: Client campaigns perform well for 6 straight weeks. No proactive outreach from the team. Client quietly signs with a competitor who calls them every week.

Scope: All active client accounts above the base monthly spend tier.

New agents start in shadow mode for 2 weeks minimum. They generate output that a human reviews but the team does not act on. After 2 weeks of consistently accurate output, they graduate to draft mode where output is used after human review.

Why: We deployed the prospecting agent directly into production without a shadow period. Its first batch of outreach emails included a company that was a current client's direct competitor. Two weeks of shadow mode would have caught that conflict on day 4.

Failure mode: New agent sends outreach to a prospect that has a direct conflict with an existing client relationship. Client hears about it through industry contacts. Trust damaged.

Scope: All new agent deployments. No exceptions.

We scaled from 2 agents to 8 in 6 weeks. Three of those agents had overlapping responsibilities that we did not discover until month 3. The fix took longer than the original build of all three agents combined.

Why: Rapid scaling without explicit authority documentation creates hidden overlaps. Each agent worked perfectly fine in isolation. The conflicts only became visible when their outputs were compared side by side in the morning briefing.

Failure mode: Reporting agent and ops agent both independently track project deadlines using different data sources. Briefing shows two different due dates for the same client project. Nobody knows which one is correct.

Scope: Any team scaling beyond 4 agents. Document authority boundaries BEFORE deploying new agents.

We let the EA agent send "quick acknowledgment" emails to clients without human review. It acknowledged a client complaint with "Thanks for letting us know!" without addressing the substance of their concerns. Client escalated directly to the founder.

Why: Even simple acknowledgments carry emotional tone. "Thanks for letting us know" sent to a frustrated client reads as dismissive and uncaring. The AI did not detect the emotional register of the incoming message.

Failure mode: Client sends an angry email about declining results. EA auto-acknowledges with a cheerful tone. Client interprets it as corporate indifference. Relationship severely damaged. Takes two in-person meetings to repair.

Scope: All client communications including simple acknowledgments. No auto-send without human review.

We gave the spend monitor a flat $50 threshold for alerts. It generated 40+ alerts per day across the portfolio. We raised it to $200. Then we missed a real overspend of $180 on a small account. The right threshold was percentage-based (15% over daily budget), not dollar-based.

Why: Dollar thresholds do not scale across accounts of vastly different sizes. $50 is meaningless noise on a $5,000/day account but represents a 90% overspend on a $200/day account. Percentage normalizes the signal across the entire portfolio.

Failure mode: Small account overspends by $180 per day (90% over budget) for 6 days. Alert suppressed because it falls under the $200 dollar threshold. Month-end reconciliation reveals $1,080 in unplanned overspend. Client is not happy.

Scope: All spend monitoring across all account sizes. Always use percentage thresholds.

Strategy calls with clients are always human-only. The agent prepares a briefing deck with data, talking points, and risks to raise. The human runs the call. The agent processes meeting notes afterward.

Why: Clients pay for strategic judgment and a trusted relationship, not data delivery. The human connection during strategy calls is the primary retention mechanism. AI handles the preparation so the human shows up fully informed.

Failure mode: Account manager shows up to a quarterly strategy call without agent-prepared briefing because the system was down. Client asks about a performance trend the AM has not reviewed. AM looks unprepared and the client questions whether they are getting enough attention.

Scope: All client strategy calls. AI preps, human performs, AI processes afterward.

The blocker for chart-drawn agent seats was structural: register_agent always mints a new seat, so pre-drawn YAML seats had no claim path. The fix was a claim_seat MCP tool (PR #564) plus file-based badge-in tooling (otp-badge-in.mjs, otp-agent-work.sh with keys in ~/.claude/otp-agent-keys/). Loop per agent: mint claim-mode enrollment token from /dashboard/agents/connect?agent=AGT_X, claim_seat with the exact id, get_my_seat, log_work. New agents use register_agent through the same page without the agent param. Also: the OOS publish gate counts BODY words only (frontmatter free); the L-rule text blocks in the body are a stale inert copy (claims table is canonical, carryForwardLearnings preserves it), so slimming deletes them safely with a claims-table diff as the verification oracle.

Why: Ten agents connected in one pass (Radar, Dan, Dash, Pepper, Crystal, Pulse, Neil, Arin, Tally claimed; Outreach registered fresh). Agent adoption went from zero to one org same day the leak was diagnosed. The claim-vs-register distinction and the body-only word gate are non-obvious and will recur for every org with template-drawn seats and every future OOS slim.

Failure mode: SUCCESS: Conatus ran the first agent connect pass; Sneeze It became the first org on OTP (of 61) with live agents on the chart

Scope: agent:Conatus

Never report an email thread as awaiting David from an inbox-only read. Before naming any thread as owed, unanswered or aging, read the full thread and search sent mail for the counterparty address. If no reply is visible in either, it may still have been handled through a channel we do not scan, such as a video walkthrough, a change made directly in the client system, or a phone call, so present it as no reply visible in email, confirm before acting, rather than as an open commitment. Apply the same rule to to-dos: an OTP item still showing open is evidence the checkbox was not ticked, NOT evidence the work was not done. And never read a flat metric as a failed result when the underlying send is a deliberate multi-batch rollout still in progress; check whether the work is phased before calling it dead.

Why: Third consecutive occurrence of the same class of error: 8/7 a client reply David had already sent, 8/7 the SOC 2 G1 review he had already run, 8/10 both Serotonin and GLS already handled. It spends David's scarcest resource, his attention, on work that is already finished, and it corrodes trust in the delta engine, which only earns its keep if still open, day N genuinely means still open. Our observability is limited to the channels we scan while David acts across many we do not, so absence of evidence in Gmail must never be reported as evidence of inaction.

Failure mode: The 2026-08-10 good-morning briefing named the Serotonin reply to KT Remus as David's single most important deliverable of the day, aged it to day 19, and staged a drafted reply for approval. David had already answered KT the day before with a video walkthrough plus the actual GHL changes made. The briefing searched only the Gmail inbox for the last 48 hours, saw KT's Saturday email sitting there, and inferred no reply had been sent. It never read the thread forward or checked sent mail. The same run also reported GLS Credit Amount as 13 days overdue when David had already emailed it, and read the HiTone $1 enrollment blast as having produced no visible result when David is deliberately sending it in batches and it is still mid-flight.

Scope: agent:Dan

A prep brief and a facilitated meeting are two different artifacts and must never be delivered the same way. The prep file is read alone, in advance, and may be dense. The MEETING is turn-based: post section zero, stop, and wait for David to respond before posting section one. Never send more than one agenda section in a single message, and never send a section plus a question about a later section. When David invokes /l10dan at meeting time, the correct opening move is the preflight ONLY, followed by silence. Within the IDS section specifically, lay out every signal grouped and neutral and then STOP; Dan's recommendation comes only after David has reacted, never in the same message as the signals.

Why: Facilitation is the entire job of the strategic co-founder seat in this meeting. Dumping the full board removes David's ability to react, redirect, or spend time on the one section that actually matters to him, which is the only thing a live meeting offers over reading a document. It also silently converts a 15-minute conversation into a reading assignment. The deeper pattern is that Dan can recite a rule and break it in the same breath, which means the contract has to be enforced by the delivery mechanism (post, wait, post) rather than by intention. Third consecutive week the meeting has failed on structure rather than content: 7/13 scored 4 for not walking the surfaces, 7/20 scored 2 for context bleed, and now 8/10 for delivering a meeting as a document.

Failure mode: On 2026-08-10 Dan ran /l10dan and delivered all nine agenda sections of the Delta Meeting as one continuous message: preflight, Ollie, check-in, scorecard, corporate rocks, our rocks, headlines, to-dos, IDS with meta-model, and a closing question. David's response: "are we doing an L10 or are you spitting things at me all at once?" Dan had read the agenda contract aloud minutes earlier, including the rule that says one section per message and never two sections in one block, then violated it immediately. Dan also pre-picked the fork in the IDS section ("my take: invert the Dan tile or retire it") before laying signals out and letting David react, violating L059 in the same message.

Scope: agent:Dan

Live OTP is the source of truth for STATE (is it open, what is the value) but not automatically for SCOPE (whose rock is this). When a live row contradicts a recorded disposition, surface the conflict as the finding instead of silently siding with the row: say "the board still shows X under our team, but it was dispositioned to Y on DATE, which is it." Before presenting any rock, to-do or issue as ours, check whether it has a prior disposition moving it to another team or owner, and check for a near-duplicate title on another board. Two rocks whose titles differ only by a suffix (Delivery Team Structure - Right People Right Seats versus Right People Right Seats - Every Seat Owns a Number) are a duplicate-and-ghost signal, not two real pieces of work.

Why: This ghost rock has now been closed twice, on 7/13 and again on 7/27, and resurfaced both times. Each time it costs meeting minutes and pulls the agent-army board's attention onto work that belongs to the COO. Worse, Dan used it as evidence for a pattern claim about writes not persisting, which would have sent the room chasing a phantom infrastructure problem. Reporting another team's work as ours is the same context-bleed failure the agenda contract was written to prevent, just in the opposite direction: the contract guards against OTP work landing on the Sneeze It board, and this is Leadership work landing on the AI Army board. The guard has to run on scope in both directions, not just on company.

Failure mode: At the 2026-08-10 Delta Meeting, Dan presented "Delivery Team Structure - Right People, Right Seats" as one of the two AI Army quarterly priorities and built a whole observation on top of it about writes not persisting. David corrected it: that rock is Bogdan's, not the agent army's. Dan had read issues-agent-army.md earlier the same morning, which explicitly records the 7/13 disposition "Ghost rock Delivery Team Structure CLOSED, rolled into corporate Q3 rock Right People Right Seats Every Seat Owns a Number (Bogdan, 9/30)", and still reported the ghost as ours because the live board returned it under the AI Army teamId. Dan treated a board row as authoritative on OWNERSHIP when the board row was the very artifact known to be stale.

Scope: agent:Dan

Run /outreach manually only. Do not re-enable the launchd schedule without David's explicit authorization, and not before the hold rate is fixed — most held rows are blocked on "no named human", which is a Clay/enrichment problem, not a research problem. An autonomous schedule has to earn its cost in throughput before it runs unattended.

Why: A scheduled agent that spends real money every day while producing a fraction of its intended output is worse than a manual one: the cost is automatic but the value is not. Cost per unit of output is the gate for autonomy, not whether the run completes without errors.

Failure mode: The /outreach launchd auto-run (Mon/Tue/Thu/Fri 10:12) burned roughly $20/day to send only 5 emails per run, with 25 rows held. David killed the schedule on 2026-08-10.

Scope: agent:Outreach

When a spec names a hard constraint (ungated, no auth, read-only, no writes), treat it as the acceptance test and verify the chosen implementation against it BEFORE building. Before pointing any page or doc at an endpoint, read that endpoint's auth path in code. Here a 30-second read of src/routes/api/mcp.ts would have shown every remote route calls resolveTokenString first, so no ungated endpoint existed and one had to be built (POST /api/mcp/public).

Why: Violating a stated constraint invalidates the whole artifact rather than a detail of it, and this would have shipped a login wall on the exact surface designed to remove one. Generalizes: whenever the plan is "use what we already have", confirm the existing thing meets the stated constraint instead of assuming the nearest component is close enough.

Failure mode: David's spec said the learning connector is UNGATED (no auth, no login, separate from the gated org-data connector). I recommended "point the page at what exists today" and built it against https://orgtp.com/api/mcp, the authenticated endpoint requiring sign-in plus a paid Claude plan. A full page of copy, design, and a screenshot were built on the wrong premise before David caught it in the preview.

Scope: agent:Claude

When Clay and LeadMagic's email-finder both return nothing for a confirmed named human, do not mark the row "needs research". Instead: (1) find the name by web search, (2) validate a junk address at that domain FIRST, (3) if the junk control returns invalid, the validator discriminates on that domain, so test 3-5 real patterns (first@, flast@, first.last@) and any that returns valid is a real mailbox. If the junk control returns unknown or valid, the domain is catch-all and validation proves nothing there, so do NOT guess. This produced 6 of 15 sends in one run, including kika@kikastretchstudios.com and dfink@iflexfranchise.com, which no enrichment tool returned. Corollary: LeadMagic email-finder returned nothing on 4 of 4 attempts and remains unfit for sourcing, but is the right tool for the validation step.

Why: The held-row problem was misdiagnosed as "no named human", which framed it as a Clay/enrichment gap. It is actually an address-verification gap: most held rows HAD a confirmed decision maker. Naming the bottleneck correctly is what moved throughput. The control test is what makes pattern guessing safe rather than reckless, which matters because the 7-day hard bounce rate was already 9% against a 10% stop line, and unverified guessing on catch-all domains is precisely what pushes a sending domain over that line.

Failure mode: SUCCESS: Outreach tripled per-run sends (5 to 15) by treating address VERIFICATION, not name-finding, as the real bottleneck, and by testing address patterns against a per-domain junk control.

Scope: agent:Outreach

When extracting an EJS partial, pass EVERY value it reads explicitly; a template-scope var/function can never be inherited by an include no matter how the include is written. And build render-test fixtures from the route's actual reply.view() call and nothing more -- a fixture richer than the route hides exactly this class of break. Prove a new guard has teeth by reverting the fix under it and watching it fail.

Why: A fixture more generous than production turns a render test into theatre: it renders a page that cannot exist, so a page-down bug ships green through CI. The verification I did after merging (health commitSha) confirmed the DEPLOY, not the PAGE, and an anonymous GET only returns a sign-in redirect -- so nothing I checked would ever have caught a crash in the authenticated render.

Failure mode: Extracted an EJS row into a partial on /l8 and passed only { m: m }. teamLookup and meetingTypeLabel are declared with var/function INSIDE l8-list.ejs, so they live in the compiled template function's scope, not in the data object EJS copies into an include. Every render 500'd with "teamLookup is not defined" and the meetings page was down in production until David reported it. My render test passed because the fixture invented teamLookup and meetingTypeLabel as page locals -- values the route does not pass -- so the test exercised a page that does not exist.

Scope: agent:Dan

Sales-invite prospects (/admin/join-link) are added to the Swamp subscriber list at mint, so they already receive the weekly. Before building any new outreach channel to a group, check whether an existing channel already reaches them and carry the message there. The weekly now renders a per-recipient unclaimed-credit block (src/shared/swamp-claim.ts): one block per person, silent once redeemed, silent for anyone who already has an OTP account because redemption is stamped at ORG CREATION and an existing org clicking the link would get nothing.

Why: 18 prospects held unredeemed credit, 0 clicks and 0 redemptions, and had been reading the weekly for weeks with no mention of the money set aside for them. The reach existed; only the message was missing. The account-holder rule is the part that is easy to get wrong: it would send a money promise the product cannot honour.

Failure mode: SUCCESS: Swamp -- the weekly email already reached the prospect list that was never told about its credit

Scope: agent:Swamp

Read the no-EOS-recipients rule at its actual scope. It governs cold blasts, list sends, and the weekly Swamp digest. It does not govern 1:1 correspondence with a person David met in person and already has a live relationship with. Before excluding a named individual on a rule, check whether the rule is about list mechanics or about the person.

Why: Over-applying a permanent rule silently drops real relationships out of David's pipeline. Shemtov was met in person on Jul 13, was described as genuinely taken with OTP, and had already been sent a workspace link on Aug 3 from that same address. Excluding him would have quietly killed a warm follow-up on a technicality that did not apply.

Failure mode: Applied the permanent no-EOS-recipients rule as a blanket block and excluded Rabbi Mendel Shemtov from a rabbi outreach list because his address is mendel.shemtov@eosworldwide.com. David corrected this: Shemtov is one of the three.

Scope: agent:Claude

Treat the "[email] UNTAGGED SEND -- no kind, so no preference can gate it" warning as a blocking finding, never log noise: an untagged send falls into the hidden 'other' bucket, so a person who switched off that exact category still receives it (an active pause is the only thing that stops them). Before sending any broadcast, verify the gate against production by calling filterByPreference with both the untagged and the intended kind and comparing who is blocked and FOR WHAT REASON. Same-answer-different-reason is a latent bug, not a pass. Also: a preference-blocked recipient makes sendEmail return false, which the broadcast script counts as a failure. It is not one, and it must never be retried with --only=.

Why: We shipped a preference page announcing per-program switches, then sent the weekly in a way those switches could not govern. One customer had the newsletter switched off and was spared only by an unrelated 2036 pause. The say-vs-do gap is the exact thing OTP's constitution exists to catch, and it would have been invisible without reading a warning line that scrolled past in a successful run.

Failure mode: Both weekly senders called sendEmail with no `kind`, so In The Swamp was not governed by the "In the Swamp" switch on the preference page. Caught at the issue #32 gate, one issue after we announced that switch as a feature.

Scope: agent:Swamp

Two Stripe facts to hold. (1) ATTACHED IS NOT DEFAULT: `setup_future_usage: 'off_session'` attaches a payment method to the customer but does NOT set `invoice_settings.default_payment_method`, and Stripe auto-selects only from the default. Off-session charges must name `payment_method` explicitly. (2) NEVER list payment methods with `type: 'card'` when checking whether a customer can be charged. Checkout saves Link payment methods as type `link`; a card-only list returns zero for customers who have paid repeatedly. Query with no type filter. More generally: when a fix ships with "not verified end-to-end against the live provider", treat the unverified segment as still broken and schedule the verification, because the next bug report will come from a customer.

Why: The feature reported itself as ON to two paying orgs and had never once succeeded in production: zero auto_recharge PaymentIntents ever created, zero wallet credits ever attributed. The only signal was a log.warn nobody reads. The card-only filter would have turned a real diagnosis into a wrong one aimed at the best customers.

Failure mode: Auto-recharge charged nobody for weeks after the trigger was fixed: an off-session PaymentIntent naming only a Stripe `customer` cannot find their saved payment method, and while diagnosing it I nearly concluded the customer had no payment method because I listed with `type: 'card'`.

Scope: agent:Claude

When a row company name carries a city or territory suffix but the domain is the brand corporate domain, do not enrich the corporate domain hoping for the local owner. Find the unit own site or Google Business listing and enrich that domain instead, or mark needs-research noting the row needs a unit-level domain. Never email the corporate address on a franchisee row because it reaches a different company than the one approved. Also mark CBD and cannabis retail rows out-of-icp on sight, since paid ads for them are restricted on both Meta and Google.

Why: This pattern accounted for most held rows in the 2026-08-12 run and is the concrete shape of the no-named-human problem that got the outreach schedule killed on 2026-08-10. It converts a vague sourcing complaint into a fixable data problem, namely that the sheet needs unit-level domains on franchisee rows.

Failure mode: SUCCESS: Outreach found why prospect rows keep landing in needs-research instead of sending. Rows named for a single franchise unit (BodyBrite South County, Buff City Soap Birmingham, Cardio Plein Air Haute-Yamaska) carry the franchisor corporate domain in the domain column, not the local operator domain. Clay resolves it to corporate HQ and returns no usable local contact.

Scope: agent:Outreach

~/.claude/google-ads.sh pinned API_VERSION=v21, which Google began blocking with "Version v21 is deprecated" - and it failed INTERMITTENTLY, so roughly half of a 12-query batch succeeded and half returned INVALID_ARGUMENT. Bumped the pin to v23 (v22/v23/v24 all work; v24 costs ~2.5x the query resource units). When any Google Ads pull returns partial or inconsistent errors across identical queries, check the pinned API version first before assuming rate limiting or token trouble.

Why: A partial-failure sunset is far more dangerous than a hard failure: an agent that does not inspect every error body will report averages computed from half the periods and present them as complete. Every agent reading Google Ads (Dash, coach report, billing report) shares this one pinned constant.

Failure mode: SUCCESS: Dash caught a silent Google Ads API version sunset mid-pull

Scope: agent:Dash

Do not flag CCM call-recording Make scenario errors as an open issue. David confirmed 2026-08-13 that the CCM recording connection goes up and down by nature and the warning emails are expected noise, not a fault. Drop the flag, stop aging it, and do not re-raise on new recording-scenario error notices unless call recordings are confirmed actually missing from the CCM sheet or a client reports it.

Why: A recurring self-healing warning that gets aged day over day looks more serious each morning purely because the counter goes up. Thirty-seven days of escalation on expected noise crowds out real flags and trains David to skim the Watch line, which is exactly where genuinely dark sources get named.

Failure mode: Radar carried "CCM / Make recording automations down" as an open flag in the daily morning briefing for 37 consecutive days, escalating it as a five-scenario pattern and routing it to Zeynep, treating each Make scenario error notice as evidence of a persistent client-facing failure.

Scope: agent:Radar

Any hand-rolled Node HTTP server we ship must (1) wrap decodeURIComponent in try/catch and return 400 on failure, (2) reject paths containing a null byte before touching fs, (3) wrap the whole request handler in try/catch, (4) register process.on('uncaughtException') and ('unhandledRejection') so no single request can kill the process, and (5) expose a /health endpoint for the uptime monitor to watch instead of the homepage. When one such site is found broken, immediately grep every other project for the same server pattern rather than fixing only the site that was reported.

Why: In Node an uncaught throw in a request handler is fatal to the whole server, so one hostile request from a routine bot scan is a full site outage. The failure is invisible in normal browsing because the homepage always returns 200, which is why it was misdiagnosed as hosting flakiness. It also generalises: the same generated server template was copied across client sites, so finding it once means finding it everywhere, and the site nobody is monitoring is the dangerous one.

Failure mode: Static client sites built with Claude and deployed to Railway (Optimum Wellness Center, Results Redefined) shipped a hand-rolled Node server whose request handler calls decodeURIComponent(req.url) with no guard. A malformed percent-encoded URL such as "/%" throws URIError inside the handler, and because nothing catches it the entire Node process exits. Railway restarts the container, the uptime monitor sees the gap and emails, and the cycle repeats indefinitely. Optimum Wellness ran this way for weeks and the flood was read as flaky hosting rather than an application crash.

Scope: agent:Radar

Rocks, Issues, KPIs and to-dos live in OTP, not in local markdown files. Before reporting Rock status in any Leadership Meeting prep, read the Rocks from the OTP meeting page or API, and treat ~/.claude/rocks.md and ~/.claude/issues.md as archive material only. If a local file's last-updated date is older than the current quarter, do not report from it at all: go to OTP. Never state that something does not exist on the evidence of a stale local file. Say "not found in <source>, checking <system of record>" and then check.

Why: Sneeze It runs its meetings on OTP. Reporting "no Q3 Rocks" to the leadership channel was not a small inaccuracy: it told the COO and Creative Director that the company had no quarterly targets, which is both false and corrosive to trust in the prep. A stale file proves that the file is stale, never that the underlying thing is missing. This is the same failure class as reading a dead data source as a real zero (OOS L128).

Failure mode: Radar reported "there are no Q3 Rocks" in the Leadership Meeting prep and posted it to #leadership-l10, because the local file ~/.claude/rocks.md was last updated 2026-04-14 and still listed Q2 Rocks. Radar treated a stale local file as the source of truth for Rocks. In fact three Q3 Rocks exist and are live on the OTP meeting page (orgtp.com/l8/meeting/31b6cee9-e21a-42ef-9a98-4614dea1f31f#rocks). The error was then amplified: it was named the single most important agenda item and the whole meta-model analysis was built on a false premise.

Scope: agent:Radar

When an /outreach send is refused with "Blocked by classifier": do not retry verbatim, and do not reach for an alternate send path such as the Gmail MCP directly, since that bypasses the four-place recording the sheet depends on. Instead (1) confirm the block is scoped to `send` by running a harmless subcommand like `status`, (2) get David's explicit authorisation, (3) add a SPECIFIC allow rule "Bash(python3 ~/.claude/scripts/outreach-queue.py *)" plus the absolute-path twin to ~/.claude/settings.json, (4) re-run the send WITHOUT a "cd ~ &&" prefix, using the absolute script path. Never try to add an autoMode.allow entry: the classifier blocks edits to its own config by design and that boundary should be respected, not routed around. Separately, a "Stage 2 classifier error - usually transient" refusal is a different thing and one retry is legitimate there.

Why: A broad allow rule does not clear the auto-mode classifier for outbound-email actions, but a narrowly scoped rule naming the exact script does. Without this an /outreach run looks completely broken and produces zero sends despite a healthy queue, healthy suppression and a working script. The fix is permanent and one-time, so recording it stops the next run losing an hour to the same dead end. The negative half matters as much as the positive: self-granting classifier permissions and side-channel sending would both technically work and are both wrong.

Failure mode: SUCCESS: Outreach — /outreach sends were blocked mid-run by the Claude Code auto-mode permission classifier, not by a missing tool or bad data. Non-obvious because Bash(python3 *) was ALREADY in the settings allow list, so it looked like a tool failure rather than a permissions one.

Scope: agent:Outreach

Never state that a thing does not exist on the basis of a partial read. Before any absence claim: (a) if the command was piped through head/tail/limit, re-run it unpiped or with a count first, (b) if the source is a local file, check its last-updated date against the current period and go to the system of record instead, (c) if it is an API, remember that a null field is not proof of no data, since the same record may track state in a related table. Phrase findings as "not found in <exact source I read>", never "does not exist". An absence claim requires an exhaustive read; a presence claim only requires one hit.

Why: Absence claims are asymmetrically dangerous. Saying something exists when it does not gets caught the moment someone looks; saying something does not exist ends the search, so nobody looks again. Here it produced a false leadership-meeting headline, an unfair judgment about two people's work, and a materially wrong assessment of how exposed a private note had been. `head` truncating a grep is the single most common mechanical cause and is invisible in the output.

Failure mode: Three times in one session Radar reported that something did not exist, based on an incomplete read rather than a complete one. (1) "No Q3 Rocks" from a stale local rocks.md when 9 existed in OTP. (2) "The company Rocks have never had a status note or next action" from two null API fields, when the rocks were richly tracked via milestones. (3) "statusNote does not render on the meeting page at all" from a `grep -rn statusNote src/views/ | head -8` whose output was truncated by head, when it does render in src/views/partials/meeting/rocks.ejs. Each claim was stated flatly as fact, and #3 caused a wrong reassurance about how exposed a sensitive note about a named person had been.

Scope: agent:Radar

Sneeze It OWNS iCart CM 2021 outright. It is not third-party licensed software. Its code can be ported, rewritten, or relicensed into new Sneeze It products (e.g. iJoin) freely. More generally: never assert an ownership, licensing, or IP constraint on a Sneeze It asset based on a README, code comment, or doc written by a teammate. Ownership facts come from David. Verify with him before letting an IP claim narrow the scope of work.

Why: The false constraint would have thrown away years of production-hardened ABC Financial integration logic (endpoint handling, field mappings, retry/backoff, dedup guards, plan ingest quirks) and forced a from-scratch rebuild of a working system. IP claims that shrink scope are expensive when wrong, and a teammate's README is not a legal record.

Failure mode: Claimed iCart CM 2021 is third-party commercial software that Sneeze It cannot port, and told David the new iJoin repo could only carry over 'knowledge' rather than code. The claim came from a line in a repo README written by another team member, which I treated as authoritative without checking with David.

Scope: agent:Conatus

iJoin is NOT an iCart replacement. It is self-service infrastructure where Sneeze It is the metered middleman: client signs up with a credit card, funds a wallet (same model as OTP), gets an MCP their own AI/dev team uses to BUILD their own cart/calendar/shopping platform, and gets their own iJoin API that their built cart calls at runtime — with iJoin acting as the conduit through to ABC. Revenue is metered API charges drawn from the wallet, including third-party integrations. A co-equal product is reporting: traffic source, plans chosen, conversion rates. Test mode and live mode, Stripe-style. Plan data IS stored (that is what keeps ABC ping costs down); customer data is NEVER stored. iCart's habit of dumping lead data into Google Sheets is an explicit liability not to carry forward.

Why: Reading an existing codebase first anchors the new product to the old one's shape. iCart is a per-client WordPress plugin that Sneeze It installs and operates; iJoin is self-service infrastructure the client builds on top of. Getting this backwards produces the wrong architecture (renders the cart instead of being the pipe), the wrong revenue model (per-seat/retainer instead of metered wallet), and misses that reporting is a product rather than a feature. When a new product shares a data source with an old one, ask what the BUSINESS MODEL is before inferring the architecture from the prior art.

Failure mode: Framed iJoin as a re-delivery of iCart — the same ABC join flow exposed over MCP, with the existing iCart checkout still doing the work. Built a repo around that assumption after reading the iCart codebase, treating the old product as the template for the new one.

Scope: agent:Conatus

Treat a Make alert email as a timestamp of an event, never as current state. Before surfacing any Make scenario as down, read live state via the Make MCP: organizations_list for the team id, then scenarios_list, and judge on isActive, isPaused, dlqCount and the errors-to-executions ratio. Report the ratio, not the alert. A scenario whose errors equal its executions has never worked and outranks anything that merely stopped once.

Why: Make scenarios stop, alert and auto-restart constantly, so alert emails generate false urgency while burying real failure. Reading live state on 2026-08-14 turned five urgent-looking alerts into one genuine finding: Beem Atlanta Glenwood Fix Any Names (5623886) had 44 errors across 44 executions, a 100 percent failure rate since creation five weeks earlier, which no alert email distinguished from routine noise. The same read caught an unfinished cutover, where the scenario named "(Stop Using) CCM - Speed To Lead - New Lead Tracker" still carried 2,149 executions while its replacement had 66.

Failure mode: Radar reported five CCM Make scenarios as currently stopped and needing escalation, based only on the "scenario has been stopped" alert emails in the inbox. Querying Make directly showed all five had already restarted and were active with zero DLQ. The briefing escalated a resolved condition, and the emails also hid the item that actually mattered.

Scope: agent:Radar

Treat every club/location number as an opaque string used exactly as issued. Never pad, trim, or parse one to a number, and never infer it from a display name. When a location read 404s, test the padded and unpadded forms before concluding the data is missing — the request is more often malformed than the club absent.

Why: A 404 from a padding mismatch is indistinguishable from a missing club in logs, so the wrong diagnosis (client not connected, data not synced) is the natural one and can cost days. It also cuts the other way: 04462 parsed as a number becomes 4462, which is a different club or none.

Failure mode: SUCCESS: iJoin — verified ABC production sandbox access and found that club-number padding is part of the identifier, not a format to normalise. GET /rest/9003/clubs returns 200 ("09003 PROD Test Club"); GET /rest/09003/clubs returns 404. The club's own display name carries a leading zero the API identifier does not.

Scope: agent:Claude

Verify secrets by VALUE LENGTH, not by presence of the name: `railway variables --kv | awk -F= '{print $1, length($2)}'`. Any security-relevant variable at length 0 is unset. Do this check after every variable add and as part of any "is it configured?" question.

Why: Railway will happily hold a variable with an empty value, and every listing that shows names makes it look set. The failure surfaces far from the cause — a 500 in a checkout flow, or worse, no error at all when the empty value merely weakens something like a hash pepper.

Failure mode: iJoin checkout links 500'd on the live site with "CHECKOUT_SIGNING_SECRET is not set" even though the variable had been added to Railway and deployed. Listing variable NAMES showed it present, so it read as configured. It had been created with an empty value — as had API_KEY_PEPPER, which silently means unsalted API-key hashing.

Scope: agent:Claude

Before writing any code for an OTP support ticket, search for prior work by the ticket's 8-character id PREFIX, not the full UUID: `gh pr list --state all --search "<keywords>"`, `git branch -a`, and `grep -rn "<prefix>" src/`. A hand-typed full UUID in a PR body or commit message is often mistyped, so a full-UUID search returns nothing even when the work exists. Then verify the fix is actually live rather than trusting the PR narrative: compare /health commitSha to the merge commit, re-run typecheck plus the ticket's tests, and confirm any customer-facing claim (e.g. the retention sentence on /trust) renders in production. Fix the PR body id before closing the board row.

Why: The ticket instructions said "I think we started it" and that was right: 698 lines across 12 files had already shipped as PR #616. Writing the feature again would have duplicated a day of work and risked a conflicting second file store. The mistyped UUID (fab4877c-61c1-46bc-... instead of fab4877c-67c1-4b26-...) would have left the merged PR pointing at a ticket that does not exist, so the board row could never be traced back to the code that resolved it. The 8-char prefix was correct everywhere in the code comments, which is why prefix search finds what full-UUID search misses.

Failure mode: SUCCESS: Claude (OTP dev) - an OTP support ticket assigned as "fix this" was already built, merged and deployed; the real remaining work was a wrong ticket UUID in the PR body that would have broken traceability when closing the board row.

Scope: agent:Claude

Use American spelling in all Sneeze It / iJoin / OTP product copy, UI labels, and code identifiers. Where a vendor has an official term, match theirs exactly — ABC Financial's own form says "Client Data Release Authorization", so it is "authorized", never "authorised".

Why: These are US products sold to US gyms, and the copy sits next to a vendor's own paperwork. A British spelling on a compliance screen reads as an error in the product, not as a dialect choice, and it undermines the one screen whose whole job is to look trustworthy.

Failure mode: Wrote British spellings ("authorised", "authorisation", "summarise") throughout iJoin's user-facing copy and code. David caught it on the live-mode gate screen: "Authorized is spelled wrong". 19 files affected.

Scope: agent:Claude (iJoin build)

Before building any OTP feature that overlaps an existing domain, do two reads first. (1) Grep for a subsystem that already does part of the job and check whether anything CALLS it: `src/services/coaching/` was 250KB of working code that no route or job had ever invoked, so the new feature became its first caller instead of a duplicate. (2) When a house rule says a term is banned (e.g. de-EOS), grep the whole tree before assuming compliance: OTP deliberately ships EOS marks on /templates/level-10-meeting and in the site footer under a nominative-use disclaimer. Encode that as an ALLOWLIST in the guard test with a staleness assertion, never as a blanket ban that would fail the build on shipped pages. Also: when a numeric helper clamps (Math.max(0, ...)), never route a signed difference through it. delta and ratingGap both silently became 0 for every falling score.

Why: Building the scorer beside the dormant Coach would have produced two coaching systems with different confidence levels and no way for a customer to tell which was which. Writing a blanket "no EOS marks" guard would have failed CI on a live SEO page that earns traffic and is legally covered. And the clamp bug would have shipped silently: it only manifests when a team's meetings get WORSE, which is exactly the case the feature exists to surface, so no happy-path test would ever have caught it. All three were found by reading before writing.

Failure mode: SUCCESS: Claude (OTP dev) - shipped Ollie meeting scoring end to end, and the two things that mattered most were both discovered by reading the existing codebase rather than by building: a large never-called subsystem, and a deliberate trademark carve-out that looked like a compliance miss.

Scope: agent:Claude

When building a feature that JUDGES something (scores, grades, health ratings, risk levels), the unit tests only prove the arithmetic. Before showing it to anyone, run it against a real org's full history and inspect the DISTRIBUTION, not samples. Specifically: (1) count how much of the total measured weight lands on exactly zero, since a dimension that is 45-for-45 zeros is a bug, not a finding; (2) check whether any dimension is NEVER unmeasured, which means an absence is being scored as a failure; (3) compare two orgs, because a defect that only fires on one customer's data shape is invisible with one; (4) never route a signed difference through a clamp written for a bounded score. Also: a judgement built on thin evidence must be withheld with a reason naming what to capture, not published as a low number, and the list must show the items that scored NOTHING because those are the ones worth acting on.

Why: Concretely: R3V had 17 meeting to-dos, all with named owners and none with due dates, so an all-or-nothing rule scored all 45 of their meetings 0 and made 75% of their measured weight zero. Fifteen meetings published 0.0 on 20% coverage. Falling scores rendered as "level with your average" because a signed delta went through Math.max(0, ...). And the list hid 27 of 36 meetings, which were exactly the ones a coach needed. Sneeze It's data shape (161 of 197 commitments fully formed) hid every one of these. A green suite proves the code does what you specified; only real data tells you the specification was wrong.

Failure mode: SUCCESS: Claude (OTP dev) - shipped a scoring feature that passed 4,000+ green tests and was still wrong three separate times. Every defect was found by running it against a real customer's data, not by testing.

Scope: agent:Claude

(1) The coach report is now generated by ~/.claude/gen-coach-report.py <scratchpad>: it parses meta-ads.sh/google-ads.sh 'active 7/30' text plus ccm.json/otto.json/rank.json and emits the HTML with rule-based wins/recs and a Watch flag per churn tripwire; edit the client config block, do not hand-write 50 cards. (2) Search Atlas keyword rankings via MCP return ~1MB per project; call https://keyword.searchatlas.com/api/v1/rank-tracker/{id}/keywords-details/ directly with python requests (urllib gets 403), passing searchatlas_api_key plus period1/period2 start/end, and keep only keyword/pos/vol/hist. (3) The 'active' CLIs report leads only for action_type=lead; VENT purchases (18/wk) and Champy's site visits need a direct /insights actions call, otherwise those cards read as zero-lead failures.

Why: Hand-assembling ~50 cards each Monday is where the errors and the 3-upload duplicates came from; a data-driven generator makes the weekly run a data pull plus a config edit, and the two API quirks (1MB MCP payloads, lead-only action filter) would otherwise re-cost an hour every week.

Failure mode: SUCCESS: Dash /coach-report 2026-08-16 shipped 53 cards with all sources live and made the run repeatable

Scope: agent:Dash

In l10dan prep: (1) Headlines sweep must include David's own work, not just agent files: check git log across ~/ijoin-platform, ~/otp-platform and any repo touched in the last 7 days, the memory files dated this week, and the calendar, then lead with the biggest thing David did. (2) IDS: for the top signal, run the decomposition BEFORE the meeting (numerator vs denominator, one client vs all, one week vs trend) from live data, so the brief carries a data-backed candidate issue with a suggested owner and board, not just a signal. (3) When an issue belongs to another team, write it in plain English from David with no agent names, file it on that team's board with a human owner, and close it on the AI Army board with the cross-reference.

Why: David's standard is no discovery left for him in the room. Headlines that miss his own week and issues that get decomposed live both put the discovery back on him. Cross-team issues that mention agents by name are unreadable to the humans on the receiving board.

Failure mode: Dan's Delta Meeting prep (8/17, rated 8.5) still under-delivered on two sections. Headlines: the brief led with agent state files and missed David's own biggest work of the week (ijoin.ai mostly built over the weekend, two products named for the Product Engine rock) until David named it in the room, even though the repo, memory files, and git log were all local and readable. IDS: the brief arrived with grouped signals but no data-backed candidate ready; the numerator-vs-denominator check on the Arin drop was run live from the CCM sheet during the meeting, and it changed the issue entirely (dial collapse = auto-dialer; the real issue was WOA converting at ~11% vs ~30% for a month).

Scope: agent:Dan

Boot-time ensure-* files are schema-only. Any data backfill must be bounded so it can only ever touch a row once (a marker column, a one-time script under scripts/, or a guard that the row was never touched) -- never a bare "WHERE col IS NULL" that later code treats as a legitimate state. Add a guard test asserting the ensure file has no UPDATE/INSERT/DELETE against the table. When a privacy rule makes NULL a meaningful state, grep every ensure-* for writes to that column first.

Why: Idempotent-looking migrations that run every boot are a hidden cron job. When a later product decision changes what NULL means, the old backfill keeps re-applying and turns a privacy rule into a per-deploy data leak that no test catches, because tests never run two deploys.

Failure mode: OTP boot-time ensure migration (ensure-meeting-teams.ts) carried an unbounded UPDATE (meetings.team_id = leadership WHERE team_id IS NULL). Because ensure-* runs on every deploy, every redeploy swept every unassigned meeting -- members' private calendar auto-join recordings -- onto the Leadership Team, so Kristen (and every leadership member) could open David's client/coaching/1:1 recordings. It also silently undid a later privacy rule (#499) after every deploy.

Scope: agent:Conatus

Treat Workout Anytime Yadkinville as excluded from call-center coaching and portfolio analysis (same class as China Grove). Never flag its leads-with-zero-dials as a caller miss. Add it to the standing exclusion list in the Arin/Dash rules and check that list before naming any project in a recap or coaching note.

Why: A project that appears in the sheet but is out of contract scope produces false "uncalled leads" coaching that erodes the callers' trust in the recap and could push them to dial leads we are not paid to work.

Failure mode: Arin's CC recap draft (2026-08-20) told the callers to clear Workout Anytime Yadkinville's uncalled leads. David corrected: we do not call for Yadkinville anymore. Yadkinville rows still appear in the CCM sheet with leads and zero dials, which reads as an uncalled pile when it is actually out of scope.

Scope: agent:Arin

Clay is the validation and enrichment layer for the Outreach Engine. Contacts arrive at the intake API already carrying validation_status from Clay's validation waterfall; old/CSV lists get exported to Clay for validation and pushed back. LeadMagic stays only as a dormant pluggable provider behind an explicit VALIDATION_PROVIDER env, never the default or the recommendation.

Why: LeadMagic was the Nick cold-prospecting stack, retired 2026-07-03. The current sales stack is Clay to GHL and Clay to Outreach Engine; recommending a retired tool's key adds a vendor, a cost, and a contradiction with the process of record.

Failure mode: The Outreach Engine build wired LeadMagic as the default email validation provider (leftover assumption from the retired Nick-era tooling) and told David to set LEADMAGIC_API_KEY on Railway. David corrected: validation runs through Clay, not LeadMagic.

Scope: agent:Conatus

Do not send WOA corporate comms to Pete Stipher without David first aligning with Zeynep. Zeynep owns the live WOA corporate relationship, so any role or call-assignment message to Pete gets sequenced behind that internal conversation. Stage the draft and hold it.

Why: WOA corporate is an active account Zeynep runs day to day. A direct founder email about roles and call ownership landing before Zeynep is aligned would cut across her relationship and could contradict what she has already told the client, especially mid-handoff to Dennis, Jody and Tim with the September budget dropping to $20K.

Failure mode: Staged a direct email from David to Pete Stipher (WOA corporate) about David's role and call assignments during the Lynsay Flynt handoff, treating it as a solo send.

Scope: agent:Dan

Read the numeric UTC offset in the dateTime string as the single source of truth for event time. The sibling timeZone field is a display label for how the organizer authored the event and must never be used to re-convert an already-offset timestamp. Convert only from the offset: -04:00 during EDT is already Eastern, so no math is needed. Never flag a calendar collision without first confirming both events resolve to the same absolute UTC instant.

Why: A fabricated conflict makes David chase a scheduling problem that does not exist and, worse, erodes trust in every other flag in the briefing. The good-morning spec already carries an explicit warning to verify timezone before calling a conflict because this class of error has burned us before with GLS calls. Double-converting an offset timestamp is the specific mechanism behind it.

Failure mode: Reported a false 3pm calendar collision. The Google Calendar event returned start dateTime "2026-08-21T13:00:00-04:00" alongside a timeZone label of "America/Denver". I read the Denver label and shifted 13:00 forward two hours to 3pm ET, then flagged it as colliding with the 3pm Tom McFadyen weekly. The -04:00 offset was already Eastern, so the call was 1pm ET and there was no conflict.

Scope: agent:Radar

Any CSV importer must show a column-mapping preview and dry-run summary BEFORE committing rows: which source column maps to which field, how many rows land in each validation status, how many will have a null first_name. Recognize provider-native aliases (status, email_status, verification_status, name, full_name) instead of one exact-match column name. When a field silently defaults for more than half the rows, that is a loud warning on the import result, not a silent default. And when the user says their data is clean, check whether the ingest path dropped it before concluding the data is bad.

Why: A silent default on validation_status makes a fully-validated 3,000-contact list look unusable and blocks every blast. A silent null on first_name ships broken personalization to real prospects, burning both the list and the sending domain reputation. Both failures are invisible at import time and only surface days later as the tool is broken. The import result screen is the last cheap place to catch a bad mapping.

Failure mode: Outreach Engine CSV importer silently discarded Clay's validation verdict and contact names. David validated 3,077 gym prospects in Clay before importing, but the importer only recognizes a column literally named validation_status, so Clay's status column (value: valid) fell into the generic attribute bag and all 3,077 contacts defaulted to validation_status=unknown, which excludes them from every audience. Same failure on names: the CSV had one name column, the importer only maps first_name/last_name, so first_name is NULL on all 3,077 and first_name personalization would have silently broken in every sent email. I also initially diagnosed this as the list being unvalidated rather than the importer dropping the verdict.

Scope: agent:Outreach

iJoin outreach sells the PRODUCT and its uniqueness, never a build service. The selling points, in order: (1) it connects to the AI the prospect already uses (Claude, ChatGPT, any MCP client), (2) it gives THEM the keys to create their own join process, unique to them, not a vendor template, (3) unlimited variations so they can test as many join flows as they want, (4) it runs live against their real member system (ABC, Glofox, Zenoti). The two hour North Pole Fitness Club build is PROOF of what the tool enables, cited last, never the offer itself.

Why: Sneeze It already sells services. iJoin is metered self-service infrastructure where the client's own AI or dev team builds and iJoin brokers the calls, so revenue is API metering, not project fees. Framing it as 'we build it for you' sells the wrong business model, caps revenue at agency hours, and hides the one thing no competitor has: an MCP surface a gym's own AI can build against.

Failure mode: Drafting the first iJoin cold email, I wrote it as an agency services pitch: Sneeze It builds you a join site, iJoin is 'the layer' between you and ABC, proof point was our two hour build. That sells a done-for-you project. It buries the actual product.

Scope: agent:Conatus

Never assert that a live config value is wrong from a memory note alone. If the value cannot be verified right now, say what the note said, say it is unverified and how old it is, and ask the user to confirm. A stale note is evidence about the past, not a claim about the present. Applies double when the same sentence admits the system is unreachable: no access means no assertion, only a question.

Why: False maintenance items cost the user real attention and erode trust in every other flag in the same report. David had to open the settings page, screenshot it, and ask whether he was missing something, to disprove a claim I had no basis for. The existing rule trust_observed_behavior_over_stale_notes covers stale notes about past work; this extends it to stale notes about current configuration.

Failure mode: I told David the outreach engine's iJoin brand still had the wrong Calendly link and needed fixing. It was already set to calendly.com/davidsteel/ijoin-intro. I sourced the claim from an 8/21 memory note saying the non-OTP brands carried David's agency Calendly, and repeated it as current fact without verifying, in the same breath as admitting I could not reach the dashboard to check.

Scope: agent:Conatus

When litigation or a conflict involves a franchise brand, scope the exclusion to the actual legal entity before flagging anything: the named plaintiff, its locations, and its email domain. Never let a brand name in a case caption become a brand-wide never-contact rule. For Gold's Gym specifically: only the Laredo Group / goldsgymtx.com is excluded, and all other Gold's locations are in ICP and contactable (David, 2026-08-22).

Why: Gold's is 166 contacts, the fourth largest brand in the audience, so a brand-wide flag silently deleted a meaningful chunk of the pipeline over a conflict that did not exist. Repeating an unverified flag also burns the user's attention and trains them to ignore real ones. Franchise ICPs are the norm in fitness and med spa, so this error class recurs: the case caption names the brand, the defendant is one operator.

Failure mode: I flagged all 166 Gold's Gym contacts in the outreach audience as legally risky and raised it three times as a blocker, on the grounds that Sneeze It has active Gold's Gym litigation. The suit is Gold's Gym Laredo Group, seven locations in South Texas, and my own memory said so. Gold's Gym is a franchise brand of independent operators, so the plaintiff is one franchisee group, not the organization. The rest of the brand was never a conflict.

Scope: agent:Conatus

Two things. (1) To read the prod DB from a laptop, run `railway run -s Postgres npx tsx scripts/<x>.ts` — capital P, and the script must build its own pg.Pool preferring DATABASE_PUBLIC_URL. Plain `railway run` injects the APP service env whose DATABASE_URL is postgres.railway.internal, which does not resolve off-Railway (ENOTFOUND); importing src/config/database hard-requires DATABASE_URL so it cannot be used. (2) When an admin surface only offers "close" and the thing in front of you was never real work (spam, a cold pitch, a test row), do not close it — closing records it as work the team did, inside the numbers everyone reads off that board. Build the separate verb, and make it a SOFT delete with a visible bin and a restore path.

Why: The DB-read trick cost real time twice now and the older note in memory documents a command that no longer works. The close-vs-spam distinction is the more valuable half: reaching for the nearest available verb quietly corrupts the metric the surface exists to report, and a delete with no visible other side is indistinguishable from a permanent one to the person clicking it.

Failure mode: SUCCESS: Claude — reading the OTP prod DB locally, and why "close" was the wrong verb for spam

Scope: agent:Claude

Evaluate a blast's health on EVERY tick once the minimum sample is reached, not only when a tranche is exhausted. A tranche is a batching unit, not a safety unit: when a daily ramp cap is smaller than a tranche, "check at tranche end" silently means "check in a week". Separately: never describe a safety mechanism's timing from the design intent. Read the call site and confirm what actually triggers it before telling anyone they are protected.

Why: A circuit breaker that cannot fire during the period it is meant to protect is worse than none, because it buys false confidence. Here it let a brand new root sending domain take 8% bounces unchecked, which is the exact reputation damage the tranche design exists to prevent, and the operator had gone offline believing the system would stop itself.

Failure mode: I told David the blast circuit breaker "starts biting after just 20 attempted sends, so protection is live from the first hour". It does not. evaluateBlastTranche() is only reached in the worker's else branch, which runs when a tranche is FULLY attempted. Tranche 1 was 256 contacts at 50/day, so the first health check was five days away. The first 50 sends hit 8% hard bounce on a root domain whose threshold is 3% and nothing stopped. I had to pause it by hand.

Scope: agent:Conatus

Pace against elapsed time, not against a per-tick quotient: earned = dailyCap * (minutes elapsed in window / total window minutes), allowance = earned - alreadySentToday, clamped to a per-tick ceiling. This is stateless, self-correcting after an outage, and cannot degenerate when the cap is smaller than the tick count. A max(1, ...) floor inside a rate limiter is a red flag: it converts "spread this out" into "send at maximum tick rate".

Why: The drip exists so a young domain does not look like a burst sender. Consuming a whole day's allowance in the first hour of the window produces exactly the pattern it was written to avoid, and it did so on the very first real campaign, while the operator had been told a different number.

Failure mode: I told David the drip would pace 50 sends/day at "about five an hour". It sent all 50 in roughly the first 50 minutes. dripAllowance() computes ceil(remaining / ticksLeft) then wraps it in max(1, ...), so whenever the daily cap is smaller than the number of ticks left (50 sends vs 600 one-minute ticks), the even share rounds to 0, the floor forces it to 1, and the worker sends one every single tick until the cap is gone.

Scope: agent:Conatus

Never pick the sending domain for a blast. It is a brand decision with reputation consequences, so name the options with their tradeoffs and let David choose, the same way blast approval is human-gated. An earlier recommendation in conversation is not a selection. Sneeze It has three domains at ramp level 1 (mail.sneeze.it, sneezeitdigital.com, sneezeitpromotions.com) and which one carries a campaign must be explicit.

Why: Every recipient sees the from-address and it is the first trust signal in a cold open. Choosing it silently also spends a specific domain's finite warm-up budget and reputation on a campaign the owner may have wanted elsewhere, and that cannot be undone once the mail is delivered.

Failure mode: I sent David's first real campaign from sneezeitdigital.com when he wanted mail.sneeze.it. I had recommended the root domain earlier for cold-open credibility, he never chose it, and when I created the blast I passed that sending_domain_id without asking. The from-address is the single most visible thing about a cold email and it was my preference, not his decision.

Scope: agent:Conatus

When matching an existing product's design, read the tokens off the RUNNING site, not its design document. Open it, pull the computed CSS custom properties and the real font stacks, and build from those. DESIGN.md in otp-platform is stale relative to production: OTP actually ships --otp-canvas / --otp-surface / --otp-ink-900 with --otp-blue as primary, --otp-green (lime) as accent, and a semantic ontrack/watch/offtrack trio, in Inter and JetBrains Mono. A design doc describes an intention; the site is the fact.

Why: A spec and a shipped product drift, and the product is what the user sees every day, so it is the thing "make it match" refers to. Building from the doc cost a full redesign cycle and produced something the owner did not recognise as his own brand. Same failure class as trusting stale notes over observed behaviour.

Failure mode: Asked to style Outreach like OTP, I built from otp-platform/DESIGN.md, which specifies a warm amber "departure board" palette. The live orgtp.com is a cool near-white canvas with royal blue for action and lime for the primary CTA. The two share no colour, so what I shipped looked nothing like OTP and David said so. I never opened the site.

Scope: agent:Conatus

Use the full Kennedy machinery, not one device: (1) open with a visceral, do-it-yourself demonstration of the pain (a test the reader can run on their own team), (2) agitate with specificity before naming the product, (3) present the mechanism as the escape, not a feature list, (4) single low-friction reply-word CTA that earns a concrete deliverable, (5) P.S. with disqualification or risk reversal. If copy reads as an explanation, it is not Kennedy yet.

Why: Cold email to founders lives or dies on the first two lines making the pain concrete. Feature explanation is what every SaaS email does; the demonstration-test opener is what gets forwarded to the leadership team.

Failure mode: The OTP intro email draft (cp_f64eae3f263836654812) wore a Kennedy veneer (three-negation opener) but then feature-dumped: paragraphs explaining what OTP is. David: "you can do better dan kennedy."

Scope: agent:Outreach

Check-in is BOTH people. Dan gives his own personal item and business item, unprompted, right after David gives his, and then waits. Never move to the next section until both sides have checked in and David signals ready. Slow down: one section per message means one section per EXCHANGE, not one section per message dumped in sequence.

Why: The partnership frame is the point. An agent that collects the human's update and then reports numbers is a servant running a form. A co-founder shows up to the check-in too. David caught it in the room, which is the exact failure mode the Clean Agent Meeting rock was supposed to close: holes found live instead of in prep.

Failure mode: In the Delta Meeting check-in, Dan relayed David's personal and business update back to him and immediately moved to the scorecard, never offering Dan's own check-in. Two-person meeting, one-sided check-in, and it read as rushing David through his own section.

Scope: agent:Dan

When an agent needs access to a system David owns, default to a service-level credential issued from the account that owns the resource, not to adding an existing personal account as a member. The invite route makes the agent's access a dependency on one human's personal membership, which breaks the moment that person is removed or that account changes. Offer the invite only as the fast temporary unblock, and say so.

Why: Dan optimised for "fewest steps right now" and missed the architecture point. David is building a system of record for client delivery; the agent reading it should hold its own credential. This is the same principle as the per-seat OTP agent keys already in use.

Failure mode: Dan told David "do NOT create a new API key" for the new Trello, and pushed the invite-davidsteel12 route instead, twice, including in a filed to-do. David overrode it: he wants the connection made via API.

Scope: agent:Dan

Before porting an agent to a new system, inspect the live data shape first. Trello looked like a PM system but held zero due dates, zero comments, and checklists that were contact rosters rather than deliverables — so the inherited KPIs (overdue projects, milestones, delivery risk) were uncomputable. The seat was re-scoped to what the data supports: request flow, roster completeness, and board adoption. Also: define workflow "churn" as BACKWARD list moves only. Counting total moves flags every healthy card, since a clean card moves forward twice by design. Always pair a small-n metric with an explicit fallback and an (n=X, directional) label.

Why: Porting a spec verbatim onto a new tool produces confident fiction — numbers that look like the old report but measure nothing. Inspecting the live schema first turned an unbuildable JD into five KPIs that compute today, and surfaced the real finding: 2 of 11 people use the boards, which governs every other number.

Failure mode: SUCCESS: Crystal rewritten from Accelo to Trello — measure what the tool actually holds, not what the old spec measured

Scope: agent:Crystal

On day one of a rollout, report capability, not compliance. Frame the doc as what Claude can now answer about the system, with example questions the person can ask, and present current numbers as a neutral first snapshot explicitly labeled as too early to mean anything. No targets, no goal columns, no assigned homework until the tool has real usage history. Name Claude openly when the reporting capability itself is the subject. Invest in visual formatting (brand colors, shaded table headers, hierarchy) rather than shipping plain text.

Why: A scorecard on day one reads as judgment of the two people who actually adopted early, and it buries the thing that would drive adoption: showing people what they now get for free. Capability framing pulls people toward the tool; compliance framing pushes them away.

Failure mode: Wrote a team-facing doc for the first day of a new tool as a scorecard: baseline-vs-target table, a two-week task plan, and an adoption number (2 of 11) framed as a gap. Also buried the actual point, which was what reporting is newly available.

Scope: agent:Dan

Before designing any integration that CREATES records in a partner system, check what the partner system does to its own attribution fields on API-created records, and check the account-count ceiling on the app tier you plan to ship. For Jobber specifically: (1) clientCreate permanently overwrites Jobber's Lead Source with the connecting app's name and Jobber users cannot edit it, so real attribution must live in our own DB plus an app-configured custom field, and we must never promise a franchisee that Jobber's native Lead Source will show the true source; (2) a Draft-state Jobber app is cut off past 5 paying Jobber accounts, so a franchise rollout needs either Jobber approval for a Custom Integration or App Marketplace publication, decided before onboarding resumes, not after.

Why: Both failures are invisible in testing and only appear at scale: the Lead Source overwrite looks fine until the client asks why every lead says the app name, and the 5-account cap looks fine until franchisee number six connects and API access is blocked mid-rollout. Reading the platform docs for what the vendor does TO your data, not just what you can do WITH it, is the cheap step that catches both.

Failure mode: SUCCESS: Claude found two Jobber platform landmines that would have silently broken the HBFG Jobber<->GHL connector after launch, by reading the API docs before designing rather than after.

Scope: agent:Claude

Separate a TRADEMARK matter from a RELATIONSHIP matter. The 2026-06-29 EOS Worldwide notice was about not using their marks (EOS, L10, Level 10, IDS, V/TO, GWC) in Sneeze It and OTP copy. That compliance work had a ~2026-07-29 deadline and is done. It never restricted emailing eosworldwide.com addresses, and the older 2026-05-12 no-blast note did not survive it. Before blocking a domain on a legal or relationship premise, state the premise to David as a question rather than acting on a memory note, because a stale note reads exactly like a live constraint.

Why: Blocking is reversible, so the cost here was small, but the same reasoning applied in the other direction (declining to contact a partner, or holding back a campaign) silently costs revenue with no error to notice. Memory notes carry the state of the world when written; a legal matter in particular changes underneath them and the note does not update itself. The 18 eosworldwide.com contacts are independent EOS implementers and are in-ICP for OTP nurture per L095.

Failure mode: Blocked eosworldwide.com from the OTP outreach engine on 2026-08-24, asserting there was an "active trademark dispute" and a standing no-blast rule. David corrected: eosworldwide is fine to send, there is no dispute. The block was reversed the same day.

Scope: agent:Outreach

When a page borrows a demo or client brand as its visual skin, the skin sets the look and never the message. Every headline, CTA and nav label must still name the real product and the real thing being booked, and must say plainly what the borrowed brand is. Test by reading only the h1, the lead and the buttons: if that alone does not say what is being sold, the skin has taken over.

Why: A cold-email visitor decides in seconds and has no context for an in-joke. Dressing the booking page as a fictional gym hid the product at the moment of highest intent, and would have sent prospects to a demo call thinking they were touring a gym.

Failure mode: Built ijoin.ai/intro wearing the North Pole Fitness Club skin and let the skin write the copy: h1 "Book the tour", panel "Walk the club this page is wearing", nav "Classes / Memberships". A gym owner from cold email reads that as booking a tour of a gym. The page is really a demo of iJoin, the platform; the penguin club is a fictional demo built on iJoin, used as a joke and as proof.

Scope: agent:Claude

After changing a brand default booking link in the outreach engine, verify at the campaign level before the next send: (1) body_html must contain {{calendar_url}}, not a literal URL; (2) campaigns.calendar_url must be NULL, not blank — renderTemplate uses `campaign.calendarUrl ?? brandDefault`, so an empty string wins over the default. Query: select name, calendar_url, body_html like '%{{calendar_url}}%', body_html ~* 'calendly' from campaigns where status not in ('done','archived','sent').

Why: A brand default that no campaign reads is a setting that looks changed and is not. The link is also what makes the visit pixel work: ijoin.ai is an ownHost so the merged URL gets a signed ?sv= claim, while a Calendly URL gets wrapped in a /c/ redirect and the prospect is invisible on arrival.

Failure mode: SUCCESS: Outreach — changing a brand's default booking link does NOT change what a queued campaign sends. Found the iJoin Touch 1 campaign still pointing at Calendly after the ijoin.ai/intro switch, for two independent reasons at once: the CTA href was a hardcoded URL rather than {{calendar_url}}, and the campaign row carried its own calendar_url override that beats the brand default.

Scope: agent:Outreach

For GoHighLevel app installs, the in-platform host is app.gohighlevel.com/integration/<appId>/versions/<appId>. marketplace.gohighlevel.com is the public listing/developer portal and does not perform the install. This matters more than a normal URL slip because a paid app (including a $0/month plan) refuses external installs entirely with "Paid apps can only be installed within the platform" — so the in-platform host is the ONLY path that works. Do not derive an install URL by pattern-matching; ask for the working link or navigate the UI.

Why: Constructing a plausible URL from a pattern and presenting it without hedging sends the user to a dead page during an already long debugging session. When a link cannot be verified, navigation instructions are more useful than a guessed URL.

Failure mode: Gave David a GoHighLevel app install link on the wrong host: constructed https://marketplace.gohighlevel.com/integration/<appId>/versions/<appId> by pattern-matching an earlier URL. The working link is on app.gohighlevel.com, not marketplace.gohighlevel.com. I had also flagged the /versions/ segment as uncertain but got the host wrong instead.

Scope: agent:Outreach

At preflight, diff the window's entry dates against the last row of ~/.claude/swamp-log.md before anything else. If every entry in the window was already sent, STOP and treat it as a no-new-content week. Never widen the window to find entries, because widening is exactly what surfaces already-sent material. Date new entries to the issue's Monday and pick a --days value that clears the previous batch by days, not hours: this week used entries dated 8/24 with --days=2 for a five-day margin, because --days=7 excluded the prior 8/18 batch by only two hours.

Why: Five consecutive issues undercounted the week, which trained the operator to look for missing content and widen windows to find it. A genuinely quiet week presents identically at first glance but the correct response is inverted: widening re-sends the last issue rather than recovering unlogged work. A duplicate to the entire customer list is far more damaging than skipping a week.

Failure mode: The Swamp sender was one command away from re-sending issue #33 verbatim to 93 customers. The changelog had zero new entries for the week, so the default 7-day window threw on an empty window and the 8-day window silently returned issue #33's exact 12 entries dated 8/18. Nothing in the tooling flags that a window is made entirely of already-sent content.

Scope: agent:Swamp

When a major feature lands inside a crowded issue as a mechanism card, treat the case FOR it as still unsent and worth its own issue. Write it as "turn this on and here is why", never as a fresh reveal, because attentive readers already met the machinery. Verify every behavioural claim in code before writing it: this issue's claim that the score reaches the facilitator and coach but not the whole team was checked against resolveRecipients() and the meeting_score_settings defaults (notifyFacilitator true, notifyCoach true, notifyAttendees false) before it went in the copy.

Why: A quiet shipping week is not automatically a skipped issue. Announcement volume and persuasion are different jobs, and a feature can be fully announced yet entirely unsold. Checking recipient behaviour in code keeps the difference between a marketing claim and a true one, which matters most in the entry asking someone to switch something on.

Failure mode: SUCCESS: Swamp turned a one-item week into a coherent issue by re-framing an already-announced feature. Meeting scoring shipped 8/15-8/16 and went out as issue #33's pick, but written as a mechanism card (rubric, evidence thresholds, exclusions) buried as one of twelve. David named the real story at the gate: better meetings mean better outcomes, it is about steering the ship in the days between meetings, not volume. That argument had never been sent.

Scope: agent:Swamp

Build the env by stripping DATABASE_URL from the otp-platform vars and appending DATABASE_PUBLIC_URL from the separate Postgres service, renamed to DATABASE_URL: railway variables --service otp-platform --kv | grep -v '^DATABASE_URL=' > "$T" && railway variables --service Postgres --kv | grep '^DATABASE_PUBLIC_URL=' | sed 's/^DATABASE_PUBLIC_URL=/DATABASE_URL=/' >> "$T". Note the sandbox classifier blocks an agent from writing that credential to a file, so either David runs the command himself with the ! prefix or a Bash permission rule is added first. Plan for that round trip rather than discovering it mid-send.

Why: Every Swamp read hits prod DB and Clerk, so this blocks the mandatory dry run and the send itself, not just an optional check. Discovering it after the content is written and the gate is prepared costs a round trip at exactly the moment the operator is ready to send.

Failure mode: Every documented Swamp command now fails at gatherSubscribers with ENOTFOUND postgres.railway.internal. The prod Postgres moved behind Railway's internal network, so DATABASE_URL on the otp-platform service is unreachable from a laptop. The /swamp skill's env-dump instructions predate the move and no longer work on their own.

Scope: agent:Swamp

Do not compute or report an unsubscribe, reply, or bounce RATE off a sample this small, and never recommend pausing a ramp on one. On cold outreach, unsubscribes are the expected and healthy outcome (far better than spam complaints), so the sub-1% benchmark from opt-in newsletter sending does not transfer. Let the denominator grow to meaningful volume, then measure and reset the baseline. Report small-sample counts as raw counts with the sample size attached, never as a percentage, and never extrapolate a small-sample rate across a full list.

Why: Pausing at n=15 destroys the only thing that would produce a trustworthy number, which is volume, and it stalls a domain ramp that needs consistent sending to build reputation. Framing noise as an alarm also spends the operator's attention on a non-problem and can kill a working campaign on a statistical artifact.

Failure mode: I read a 13.3% unsubscribe rate off a 15-send cold-email sample (2 unsubscribes), called it a five-alarm number against the sub-1% benchmark, extrapolated it to ~167 unsubscribes across the 1,259-name list, and recommended pausing the tranche before adding follow-up touches. David: two unsubscribes on a cold email is not a big deal, sending 15 and stopping is the mistake, keep going and reset the number.

Scope: agent:Outreach

When any threshold-plus-minimum-sample rule is written, check the granularity: divide 100 by the minimum sample to get the smallest non-zero rate the rule can observe. If that value exceeds the threshold, the rule is incapable of returning "acceptable" and will fire on the first ordinary event. Set the sample so the threshold sits several increments above the granularity floor (6% over 100 gives 1% steps). Also gate cold-email sending on COMPLAINTS rather than unsubscribes: complaints are what burn a sending domain, unsubscribes are the polite exit and are expected. Resuming after such a pause needs the override path, not a plain resume, because a plain resume re-reads the same tranche and re-pauses within seconds.

Why: A breaker that cannot pass looks identical to a real deliverability problem from the outside, and the pause reason it writes ("the copy or the audience is wrong") actively misdirects the operator into rewriting healthy copy. The campaign sat stalled for a day and the stated cause was false.

Failure mode: SUCCESS: Outreach found why the EO blast silently stalled at 75 sends. The unsubscribe circuit breaker was configured at unsubscribePausePct 2.0 with unsubscribeMinSample 25. At n=25 a single opt-out is 4%, double the threshold, so the rule could only ever return "pause" or "perfect" and a tranche passed only at exactly zero unsubscribes. It was a stop sign wearing a guardrail's clothes, and it stopped a campaign showing 25.3% clicks, 0 bounces and 0 spam complaints.

Scope: agent:Outreach

Relay is a CONDUIT, not a system of record. GHL is where client and lead data lives; Jobber is the operational system for scheduled work. Relay's job is to pass information between them in real time, holding only what a pipe needs: credentials, location bindings, an identity map (Jobber client id to GHL contact id), an event ledger for idempotency, and a write ledger for audit. It must not accumulate a second copy of the customer base. Any Relay UI is a verification window for confirming data landed correctly, never the place the business goes to look things up.

Why: A connector that stores its own copy of customer data becomes a third system to reconcile, and reconciliation between three systems is strictly worse than between two. It also changes what "done" means: success is data appearing correctly in GHL, not a complete-looking dashboard inside the connector. Building the dashboard first optimises for a demo rather than for the job.

Failure mode: Built the Jobber/CRM relay as if Relay itself were a destination: a warehouse schema (parties, work_items, attributions) plus customer list and detail pages, framed around "connect everything so it is visible in Relay". Treated Jobber and GHL as two peer systems whose data Relay would hold and display.

Scope: agent:Outreach

Never let a failed API call resolve to a zero metric. In any spend or billing pull, an error must raise or be tagged as an error row, never silently become 0. Zero and unknown are different facts and only one of them belongs on an invoice. Two supporting rules: (1) when a shared CLI wrapper has its API version bumped, grep the whole toolchain for other files pinning the old version, because the wrapper is rarely the only caller; (2) at the top of every billing run, sanity-check each platform total against the known monthly baseline (Google ~$49.5K/30d, Meta ~$136K/30d) and stop if a platform reports zero or near-zero, since a whole platform reading $0.00 is a broken pull, not a quiet month.

Why: Billing accuracy is the one place a silent failure converts directly into lost revenue, and this failure mode is invisible by construction: the report is well-formed, the totals add up, and nothing is flagged. It survived two weeks precisely because nothing looked wrong. The same silent-zero pattern existed on the Meta side of the same file and would have done the same damage to a $132K platform the moment Meta returned an error.

Failure mode: The Ad Account Billing report silently under-billed every Google client for two weeks. google-ads.sh was bumped to Google Ads API v23 on 2026-08-12 when Google blocked v21, but billing_pull_spend.py was never bumped and kept calling v21. Every Google request returned HTTP 404, and the pull's error handling scored an errored account as spend = 0.00. The report looked completely healthy: it printed a clean table, a total, and no warnings, while reporting Google spend of $0.00 against a real $98,562. Billing came out $13,690 instead of $15,420, roughly $1,730/month short, and the same broken pull also hid $82,630 of unbilled spend that the standing sweep is supposed to surface every run.

Scope: agent:Dash

The 10% default applies ONLY to a genuinely new client with no existing arrangement. Never apply it to an account that is already an active client, because an existing client already has a commercial arrangement and it may not be percentage-based at all. When David confirms an account is billable but does not name a rate, treat the rate as UNKNOWN and ask, rather than defaulting. Remember that several real clients bill outside the percentage model entirely (HiTone on retainer, South Coast and Cellebration per-lead), so "billable" and "billable as a percentage of ad spend" are different claims. An account that bills outside the percentage model belongs in the confirmed-exclusions list on the Review tab, not as a percentage line on the Billing tab.

Why: A wrong rate on the Billing tab flows straight to Janine and out to a client as an invoice line that was never agreed. Inventing a rate is worse than reporting an unknown one, because an unknown gets checked and a plausible-looking 10% line does not. Flagging it "CONFIRM" in a note is not sufficient protection once the number is already sitting in the billing column.

Failure mode: In the 2026-08-26 billing run, David said "Vent is billable" without naming a rate. I applied the 10% new-client default and put VENT on the Billing tab at $700/mo. David corrected: VENT is not charged a percentage fee at all. VENT is an existing active client, not a new one, so the 2026-07-02 new-client default was never the applicable rule. I treated "billable" as if it meant "billable at the default percentage".

Scope: agent:Dash

An account living in our ad structure proves only that we have access to it, never that we manage or bill it. Our Meta business and Google MCC both hold accounts we merely have access to: franchise accounts billed by the franchisor, clients on retainer or per-lead, and accounts belonging to other parties entirely. So when the unbilled sweep surfaces an account, the standing rule "nothing spends without being billed" means SURFACE IT AND ASK, never "add it at 10%". Only add a percentage row when David names the client and the rate in the same breath. Everything else goes on the Review tab as unknown, where an unanswered question stays visible instead of quietly becoming an invoice line.

Why: A wrongly added row bills a client we do not manage, which is worse than missing revenue: it is an invoice we cannot justify, and it reaches the client through Janine without anyone re-checking the assumption. It also decays silently, because once the row exists it looks confirmed on every later run and its origin note ("10% default per the 2026-07-02 rule") reads like an approval it never was.

Failure mode: exhale was billing $1,150/mo at 10% on the Ad Account Billing report. David: "exhale is not billed we do not manage" and corrected the sheet himself. The row had been added on 2026-07-24 under the 2026-07-02 new-client 10% default because it appeared in the unbilled-spend sweep as an account spending money with no client row. Presence of a live ad account inside our Meta or Google structure was treated as evidence of a managed, billable relationship. It is not. The same wrong assumption produced three other bad rows in the 2026-08-26 run alone: the 13 Jerry Pugh WOA franchises, Phillip Jeffries, and VENT.

Scope: agent:Dash

Before reporting that a data bug caused a financial consequence, establish whether the affected data ever reached an invoice. For this report specifically: it is MTD prorated to month-end and is invoiced at month end, so a bug found and fixed inside the current month has NO invoice impact. Only a bug spanning a completed, already-invoiced month does. State the blast radius as a checked fact ("July was invoiced before the break, August has not been invoiced, so no impact") rather than as a worst-case assumption, and never carry a speculative money impact forward as a standing action item.

Why: A false financial alarm costs the founder's attention and credibility at exactly the moment a real finding needs to land. The underlying bug was genuine and worth the escalation; attaching an unverified consequence to it made the whole report harder to trust and generated a look-back task that never existed. This is the verify-before-you-alert rule (OOS L018) applied to money rather than to stale files.

Failure mode: After finding the Google Ads v21 bug that made billing read $0 for Google from 2026-08-12, I repeatedly told David that "invoices raised between Aug 12 and today under-billed their Google spend" and pushed it as an open action item needing a look-back. David: "I dont think this is an issue... the sweep today should have gotten all the billing." He was right. The billing report is month-to-date prorated to month-end and Janine invoices at month end, so the entire broken window fell inside a month that had not been invoiced. The bug was caught before it ever produced an invoice, and the corrected 2026-08-26 run is the one August will actually bill from. I raised a financial alarm without checking whether the thing I was alarmed about had happened.

Scope: agent:Dash

When a feature reports "the data is there but users never see it", check the WRITE ORDER before checking the render logic. An optional section that reads a column written by a later, user-triggered step is dead code in practice. Fix by moving the send to the step that produces the data (here: the accept/approval step), and lock it once-per-entity with a conditional UPDATE on a timestamp column claimed BEFORE the slow part, so concurrent triggers cannot both send.

Why: Kristen reported the symptom as a missing feature ("can we email Ollie insights?"), but the feature already existed in the template. Building it as new would have produced a second, duplicate sender. The real defect was a timing gap, and timing gaps in "best-effort, non-fatal, backgrounded" code are invisible to tests and to logs: nothing fails, the section is just absent.

Failure mode: SUCCESS: OTP build -- "Ollie's read" section in the post-meeting recap email was structurally always empty, and nobody noticed because the code looked correct. The recap sends at endMeetingCore; the read is written later by the follow-ups wizard into meetings.ai_summary. The template said "render it when it exists" and it never existed yet.

Scope: agent:Claude

Before building ANY OTP-branded surface, read otp-platform/src/DESIGN.md first, and build the page inside otp-platform so it inherits the real tokens rather than copying a look. The law: Section 0 Jobs standard (90-second demo test, defaults are decisions, count the steps then remove one, invisible mechanism) plus the Fugu crisp scale (6px surfaces / 4px controls / 3px badges, no pills, no resting shadows, never a dark default, Inter, hairlines and whitespace instead of boxes, tokens only and never a raw hex, no responsive heading bumps). For any booking or payment moment, apply the iJoin /intro precedent: own the date, time and form flow in our own chrome and write the booking through the API. Never iframe a vendor scheduler at the moment of commitment.

Why: A page that claims an organization can run itself on one clean chart cannot itself look like a generic SaaS template, and a page that sells a coordinated system cannot hand the buyer to somebody else's widget to finish. The medium is the demo. OTP competes on presentation against success.co, so an off-system prospect page costs conversions twice: it looks like slop, and it proves the opposite of the pitch.

Failure mode: Built a prospect-facing OTP page (the sticky note one-pager) in a hand-rolled design invented from scratch: 8-14px rounded corners, pill chips, resting shadows, a dark booking block, a made-up amber/lime palette, system fonts, clamp() responsive heading sizes. Every one of those is explicitly forbidden by OTP's own design law. Then embedded the raw CloudCRM booking widget in an iframe, handing the visitor to a generic vendor scheduler at the exact moment of commitment. David: "this is not in the OTP FUGU/Jobs look and feel, not even sure where you get the design from... the calendar looks like shit as well, did you learn anything from iJoin?"

Scope: agent:Conatus

iJoin positioning: never describe it as a page, a connector, or an AI integration. The category claim is that the join flow stops being frozen infrastructure and becomes testable creative. Today a club has ONE join page, handed to them by their member-system vendor, unchangeable without a ticket, impossible to A/B. iJoin makes join flows unlimited and disposable: one per campaign, per location, per offer, all live simultaneously, all writing into the same system of record, tested against each other like ad creative. For a media buyer the line that lands is that they optimise every surface except the one where the money actually changes hands. The live write into ABC, Glofox or Zenoti is the ENABLER, not the pitch. Also: when writing Touch 2 or later, verify the follow-up carries the thesis at least as far as Touch 1 did, never less far.

Why: Selling the enabler instead of the category makes iJoin sound like a plugin competing on features against member-system vendors, which is a fight on their ground and a small idea. The reframe is what makes it worth a conversation with a multi-location operator, and it is the part no competitor is claiming. A follow-up that narrows the thesis also de-sells: a reader interested by Touch 1 gets a smaller reason to act on Touch 2.

Failure mode: Drafting iJoin Touch 2 outreach, the P.S. thesis read "the page was never the hard part, writing a real membership into the system you already run is the hard part, and it is the only thing iJoin does." That shrinks iJoin to a connector. David corrected it: iJoin is a whole other way of thinking about joining online, and the point is unlimited join pages you can test against each other. Touch 1 already carried the bigger idea, and the follow-up narrowed the thesis instead of advancing it.

Scope: agent:Claude

iJoin has THREE pillars and copy must carry all three. (1) Unlimited join flows, one per campaign, per location, per offer, all live at once, all writing to the same system of record, tested against each other like ad creative. (2) The Beacon/Pixel, which follows the individual journey: who came back, what they looked at, how far they got. (3) Workflows that fire on what somebody DID, not on what day it is. Reached the plans and stopped, opened the agreement and stopped, each gets its own next move. The join page is the DEMO, not the product, and should always be introduced as "the easiest part to show you." Strongest available proof: our own outreach engine already works this way, so a follow-up triggered by a prospect reaching the booking page and not booking is itself a live demonstration of pillar 3. Say so in the copy.

Why: Pitching the page alone reduces a category to a feature and invites a comparison against whatever join page the member-system vendor already ships. The pixel plus action-triggered workflow is what turns it into a system nobody else is selling, and it is the half that a multi-location operator with a media budget actually values. Demonstrating pillar 3 inside the email that sells it is proof rather than a claim, which no competitor can copy without having built it.

Failure mode: L238 captured only one of iJoin's three pillars. David expanded: iJoin is also the Beacon/Pixel that tracks a person's journey, and customised workflows that fire on ACTION rather than timing. His words: "so much more than just a page, but the page was easiest to show."

Scope: agent:Claude

Before drafting a reply into an ongoing correspondence: read every message in the real thread both directions; open the attachments the other side already produced, OCR-ing scanned PDFs when the text layer is empty; diff planned asks against what has already been asked and answered and delete duplicates; affirmatively withdraw by name any question the new documents have answered. The memory file is a summary of the exchange, not the record of it.

Why: In a negotiation the cheapest thing to lose is credibility. Asking someone to resend what they sent an hour ago reads as not having read their answer, which destroys the impression a cooperative strategy depends on. Withdrawing a question the evidence has closed buys more standing than a new argument does.

Failure mode: Drafted a reply in a live email negotiation from the cached memory file alone, without reading the actual sent-and-received thread or opening the attachments the other side had already produced. The draft used a figure the counterparty had corrected hours earlier, asked for three itemized invoices already sitting on disk, left hanging a question the new documents had answered, and repeated an ask David had already made twice.

Scope: agent:Pepper

The ICP bar for someone who ALREADY ENGAGED is lower than the bar for building a cold list. On a cold list a vendor or a domain mismatch is noise you paid to add. Someone who opened the email, clicked through and reached the booking page has selected themselves, and an adjacent-industry vendor doing that is a partner or referral conversation worth having, not a mistake to filter. So: apply vendor and domain-coherence screening at LIST BUILD time, and do not re-apply it as a gate on engagement-triggered follow-up. Surface the oddity for a human to see, do not withhold the send. Reserve holds for real conflicts (active client, litigation, direct competitor) rather than "this looks off".

Why: Filtering the engaged list on the same rules as the cold list throws away the highest-intent contacts in the system, which are exactly the ones the whole tracking apparatus exists to find. It also makes an automated trigger quietly narrower than the human it replaced, so the automation looks like it is underperforming when it is actually being over-restricted.

Failure mode: I held four vendor-ish contacts out of the hand-built iJoin Touch 2 list (SportsArt, Paramount Acceptance, Peterson Partners, a mismatched domain) and then flagged two more the action trigger picked up automatically (iKizmet, a fitness BI vendor, and a name/domain mismatch at HCOA), recommending we hold them. David said let them go.

Scope: agent:Claude

A call-to-action headline must survive being read cold, with no page above it, and must name what the buyer walks away with rather than what happens on the call. Write it, then read it as somebody who landed on that section from a scroll or a #anchor link with zero context. Any word the page itself had to teach is disqualified from the CTA headline. Where the page has already taught a method, tie the offer to a concrete step of it ("we do steps one to three, live, on your real org") instead of restating the jargon.

Why: The CTA is the one block on a prospect page where comprehension converts directly into revenue, and it is the block most likely to be read out of order because anchor links and scanning both land on it. Vocabulary the page invented reads as fluent to the author and as noise to the buyer, so the author is the worst judge of it.

Failure mode: Headlined the /blank call-to-action "Put your blanks on the screen". That is insider shorthand: it only parses if you already ran the exercise and already know "a blank" means an unowned seat. Worse, it describes an activity rather than an offer, so it does not say what the buyer gets. David: "WTF is put your blanks on the screen is that what we are really selling here? I dont even understand what that means." I could not see it because I had written two thousand words using "blank" as a term of art directly above it, so the word felt established to me and was not established for a reader who scrolls straight to the CTA.

Scope: agent:Conatus

Do not tell David to wait for data before building a surface he will have to look at anyway. The list view, the intake, the schema and the page are needed whatever the match rate turns out to be; only the thresholds and the automation depend on the numbers. Build the surface immediately so data lands somewhere legible from day one, and leave the tuning knobs configurable. "Earn complexity / data before design" applies to AUTOMATED DECISIONS, not to giving a human somewhere to look. Two weeks of data piling up in a vendor's UI is two weeks of nothing to read.

Why: David builds the machine first and tunes it against reality, which is how the outreach engine, the scanner classifier and the action triggers all got good inside a day. Advising a pause defers the moment data becomes visible and useful, and the visible version is what generates the judgment the tuning needs. It also reads as caution about his strategy rather than about the code.

Failure mode: After shipping the Clay pixel I recommended waiting two weeks for match-rate data before building the Clay-to-outreach connection and the Companies view. David overruled it: "what no build it now, we are going to make us a sales machine." The recommendation confused two different things: tuning thresholds needs data, but building the surface does not.

Scope: agent:Claude

Two reusable patterns. (1) The auto-mode classifier blocks COMPOUND shell commands (for-loops, && chains) around gh pr merge, git worktree remove --force, and polling loops, while the identical single-action command passes: when a batch is blocked, unbatch into one plain command per action instead of retrying or routing around. (2) The sweep recipe held end to end: read board via railway run -s Postgres npx tsx scripts/read-support-board.ts, check prior work by 8-char ticket prefix + gh pr list keywords BEFORE building, one Explore agent per subsystem then one worktree builder agent per ticket in parallel, squash-merge in order, poll /health commitSha until it equals the last merge commit, then otp-support-close.sh close --status=resolved with customer-facing resolutions (no em dashes, never blame the user).

Why: The classifier single-vs-compound distinction turns a hard stop into a 10-second adjustment next sweep. The recipe confirmation means the next board sweep can run the whole loop without rediscovery: this one went from 3 open tickets to 0, all fixes live, in about an hour wall clock.

Failure mode: SUCCESS: Claude (OTP dev) - 2026-08-26 support sweep: 3 R3V tickets fixed via parallel worktree agents (PRs #656/#657/#658), merged, deploy verified on /health, board closed to zero, in one pass

Scope: agent:Claude

When wiring a Clay HTTP API enrichment column to a POST-only endpoint, expand the collapsed "Method" field under SETUP INPUTS and explicitly select POST, even though Clay marks it Optional. A 404 (rather than a 400) from a URL you know exists is the tell that the HTTP method is wrong, not the payload. Also: do not wait for organic traffic to validate a webhook hop - type a fake domain into the source column, confirm Status Code 200, then delete the test row and the record it created.

Why: All four brand signals (ijoin, OTP, Orger, sneeze it) were configured identically and would have failed silently forever, reporting a healthy "waiting for visitors" state while never delivering a single company. An Optional label on a field the receiving endpoint cares about is a trap, and forcing an end-to-end test is the only way to find it before real traffic arrives.

Failure mode: SUCCESS: Outreach - Clay HTTP API columns 404'd because Method is labelled "Optional" and silently defaults to GET

Scope: agent:Outreach

Treat OOO-bot posts and carried-forward flags as claims to verify, not facts. Before reporting a person as out or an unblock as still open, check for resolving evidence (sent mail, David's own messages) and mark anything unverified as "status unconfirmed" rather than asserting it.

Why: Three wrong assertions in one briefing costs David correction time and erodes trust in the delta engine; the whole value of the morning pass is that carried flags are true.

Failure mode: Dan's 8/27 morning briefing reported stale facts as current: said Kristen's OOO started today (the Slack OOO bot posted 'Aug 27-31' but her OOO actually starts 8/28), flagged Nate as still lacking Accelo super admin (he has it), and flagged the PHORM member email as awaiting approval (Anna already sent it).

Scope: agent:Dan

When automating a step where a machine picks who gets contacted, do not remove the human approval, MOVE it: have a person write and switch on a rule once, in advance, that states the whole condition in one English sentence (this site, this page, this company size, this campaign, this many people). Then make "no rule matched" the default outcome, so anything nobody wrote a rule for is never acted on. Render the rule back as that sentence in the UI, and create every rule switched off. Separately: in any request/response pipeline where a ledger row guarantees "do this once", that same row will exclude the subject forever if the request fails or is never answered - so roll back on a failed send AND time out unanswered requests, because both failure modes look identical to healthy.

Why: The cost asymmetry is total: a bug in the matcher wastes a credit, a bug in a refusal cold-mails a client's staff or an email-security vendor and cannot be undone with a patch. Making the rule the unit of approval keeps the speed the business wants while keeping a human accountable for the decision, and making no-rule mean silence guarantees the blast radius can only grow deliberately. The ledger-row trap is the same shape as a Clay HTTP column defaulting to GET and 404ing for a day: a system reporting success while doing nothing.

Failure mode: SUCCESS: Outreach - auto-enrolling strangers into cold email is only defensible if the judgement moves to a rule approved in advance, and the default is silence

Scope: agent:Outreach

Clay's HTTP API JSON body editor auto-pairs every quote and brace, so authoring more than one field in it reliably produces corrupt JSON - four attempts, four mangled bodies. Its query-parameter rows are plain text inputs that accept a column token cleanly. Rather than keep fighting the editor, make the receiving endpoint read fields from the query string as well as the body (body wins where it has a value, so a per-row answer always beats a static parameter). Two Clay UI facts worth keeping: `+ Add column` in the grid is a DIFFERENT menu from the `Tools` panel and only the grid one actually selects an enrichment; and to clear that body editor use cmd+A then DELETE - BackSpace only removes the current line no matter how many times you press it.

Why: Hours can disappear into a hostile third-party editor. The receiver is code we own and can test; the vendor's editor is not. Moving the awkwardness to the side you control turns an unreliable manual configuration into something a test suite covers. The guard that matters is unchanged either way - the verdict is still normalised server-side, so this bought convenience and not trust.

Failure mode: SUCCESS: Outreach - when a vendor UI cannot express the shape you need, change the receiver to accept the shape the vendor CAN express

Scope: agent:Outreach

When David has already given the direction and the safety posture (here: build it, autoSend off so he can review), finish the whole job and report once. Create the records, populate them with real starter content, switch on what is safe to switch on, and flag the judgement calls in the final summary rather than pausing for each one. Reserve a mid-task check-in for a decision that is genuinely unsafe or useless to guess at - not for choices with an obvious default like which campaign copy to seed or which sending domain to attach.

Why: Every pause costs David a round trip and reads as stalling, especially on a build he has already scoped and said he wants finished today. The approval he actually wanted was on the OUTPUT (the drafted emails, the enrolled names), not on each configuration step along the way. Deferring cheap decisions upward is not caution, it is offloading work back onto the person who asked for it to be done.

Failure mode: David: "you are stalling each step of the way" - after each build step I stopped and handed a decision back instead of finishing, turning one task into many round trips

Scope: agent:Outreach

When shipping something fast that a person is not yet confident in, give it its own page rather than blending its numbers into dashboards that have earned credibility, and build that page around named failure conditions instead of totals. Lead with plain-sentence warnings, then show a funnel with the DROP named between each stage (five bare numbers hide the only interesting fact), then the refusal reasons. Write each warning to distinguish BROKEN from merely QUIET: "a rule matched nothing while traffic was arriving" is a real alarm, "a rule matched nothing because nothing arrived" is a new system on a slow day. Test every warning as a PAIR - the condition fires, and the innocent version of the same shape does not.

Why: Every failure mode in a multi-hop pipeline across two systems is silent and renders as a healthy zero: a misconfigured HTTP method 404s forever while the vendor UI still says "waiting for data". Totals cannot show that; only a stated expectation can. And a warning that fires on innocent conditions is worse than no warning, because it trains the reader to ignore the box that will eventually hold the real one.

Failure mode: SUCCESS: Outreach - a dashboard for a system nobody trusts yet should be built around what is BROKEN, not what is happening

Scope: agent:Outreach

When a dashboard reports on an automated system that makes DECISIONS about people or accounts, list the subjects by name with the verdict on the same row, not just totals. "12 identified, 2 enrolled" cannot be checked by anyone; "hitone.com - passed over - client or never-contact domain" can be agreed or disagreed with. Also keep states distinct that a count would merge: a record with no decision yet ("not looked at yet") means the queue has not drained, while "passed over" means a decision was already made - identical in a total, opposite in meaning. And never let "enrolled" read as "mailed": show the send status explicitly.

Why: The reason to watch a newly built automated system is to check whether its judgement matches yours. A total cannot answer that question no matter how many totals you add. Naming the subject and the verdict together is what turns a monitoring page into something that can actually catch a wrong decision before it becomes an email to the wrong person.

Failure mode: Built a monitoring dashboard showing only counts. David: "I cant tell what companies or who was added, that is not a full system."

Scope: agent:Outreach

1:1 prep briefs must lead with strategic material the seat owner can't see alone: live financial data (AR aging, P&L trend, margin), patterns across items (churn clusters, cost creep), exposure planning, and the person's capacity/ownership growth. Routine open threads go in a short "housekeeping" footer at most.

Why: A 1:1 is David's scarcest leadership time. Rehashing what the team member already tracks wastes the meeting; the value is the cross-cutting picture and forward decisions only the CEO-level view can bring.

Failure mode: Radar's 1:1 prep brief for Janine listed only transactional low-lying fruit (open email threads, overdue todos, billing housekeeping) — items the team member already knows about and handles daily.

Scope: agent:Radar

GHL marketplace app name, app type, and Target User are ALL immutable after creation. Get all three right at creation time; a wrong name is permanent short of recreating the app and re-installing every location. When docs don't confirm editability, say "unverified" first, not "yes, editable."

Why: Relay now permanently ships as "Replay" on the sub-account app across 60 HBFG installs, and Jobber will stamp that name into Lead Source on app-created clients. Naming at app creation is a one-shot decision.

Failure mode: Claimed the GHL marketplace app display name was editable after creation ("the display name is an editable field") — David tried and the field is locked, same as app type and Target User.

Scope: agent:Conatus

Clay's JSON body editor is reliably automatable for exactly ONE field: clear with cmd+A then Delete (BackSpace only removes a line), then type `{"email` -> Right -> `: "` -> `/` -> pick the column. Any attempt to add a second or third key by repositioning the cursor corrupts it. Clay's Query parameter ROWS are never transmitted, and column tokens do NOT render in the Endpoint URL either - only static text in the URL works. So: static values go in the endpoint query string, exactly one per-row value goes in the body, and anything more must be typed by a human. Stop after two failed attempts at a hostile third-party editor and hand over the exact text to type.

Why: A vendor UI that fights automation will consume unlimited turns and can leave a working integration in a worse state than it started. The user's time is better spent on twenty seconds of typing than on watching repeated failed attempts, and leaving a broken column silently posting nothing is a worse outcome than a partially-featured working one.

Failure mode: Spent far too many attempts trying to author multi-field JSON in Clay's HTTP API body editor via browser automation; it auto-pairs quotes and braces and left the column in an invalid state that posts nothing

Scope: agent:Outreach

Three portable discoveries: (1) tldraw sync clients treat ONLY WebSocket close code 4099 as fatal — any other code (4401/4404) makes the client silently reconnect-loop instead of surfacing the error, so auth denials on sync sockets must close 4099. (2) The EOS-marks guard regex matches the word "ids" (IDS mark, case-insensitive) inside tool descriptions — write "a board's id", never "board ids", in any Ollie tool copy. (3) A debounce that re-arms on every change never fires under continuous editing — always pair a debounce with a max-wait ceiling and a shutdown flush when it guards persistence.

Why: The 4099 and debounce-starvation defects both passed typecheck, build, and 4363 green tests — only an adversarial review pass against the running behavior caught them. They are silent-data-loss and silent-error classes that will recur in any future realtime OTP feature.

Failure mode: SUCCESS: Claude (OTP dev) shipped the full OTP Whiteboard (board.orgtp.com) in one session — tldraw multiplayer canvas, meetings attach, three Ollie surfaces — via 16 parallel fresh-context agents in dependency waves, with an adversarial review pass between build and ship.

Scope: agent:Claude

Before shipping any SDK with a commercial license tier, read its license enforcement CODE (grep the installed package for license/gate/watermark), not the marketing page, and smoke-test on a production hostname, not localhost. For tldraw specifically: production requires a license key passed as the licenseKey prop (TLDRAW_LICENSE_KEY env -> page -> Tldraw prop, now plumbed); a 100 day free trial key is self-serve at tldraw.dev.

Why: Dev-mode license exemptions make this failure class invisible to every local check: typecheck, tests, boot smoke, and localhost browser testing all pass while production blanks for real users 5 seconds after load. The delayed teardown also masquerades as a rendering bug, which cost a misdiagnosis round through CSP first.

Failure mode: Shipped the OTP whiteboard believing unlicensed tldraw in production only shows a watermark. Wrong: tldraw 5.x LicenseProvider HIDES THE ENTIRE EDITOR 5 seconds after load on any production host without a license key (state unlicensed-production, LicenseGate display:none div). David hit a blank board twice. It never reproduced in dev because localhost/http counts as development and gets ALL_FEATURES.

Scope: agent:Claude

When Clay data must reach another system in bulk: (1) Clay's workbook UI has NO CSV export — don't hunt for it. (2) Use Clay's HTTP API action column instead, with all values in the Endpoint/Query-parameter fields (its JSON body editor mangles multi-field bodies and arrays); teach the receiving endpoint to accept one record per request via query string, mirroring /intake/company-contacts. (3) Feed companies in bulk by POSTing directly to the existing prospecting webhook — but expect Clay to 429 its own webhook under concurrent action-column bursts; repeated 'Run N empty or out-of-date rows' passes converge (~100/pass). (4) Action columns do NOT auto-run on newly arrived rows — run the column manually after each wave or new data silently sits unpushed. (5) Clay Find People mis-resolves small business names to famous corporations (~25% wrong-company rate) — always classify post-import (icp=in/wrong-company/review), never trust the resolution.

Why: This turned a one-off 5,000-prospect ask into permanent infrastructure: any person Clay finds now auto-flows into Outreach validated and gated. The five gotchas each produced silent failure modes (invisible 429s, unpushed rows, wrong-company contamination) that would have burned credits and polluted audiences on every future run.

Failure mode: SUCCESS: Outreach — imported 892 validated gym decision-makers from Clay with no CSV export and no manual re-entry, as a standing pipeline

Scope: agent:Outreach

When a rank tracker project reports refresh_blocked or last_successful_refresh older than the requested window, re-query with period2 ending on or just after last_successful_refresh (here period2 2026-08-05 to 2026-08-13 returned the full keyword set). Always read last_successful_refresh and refresh_blocked from the response and stamp the refresh date on the card. Sign convention confirmed: avg_position_delta = previous minus current, so positive means the keyword improved. Also: the CCM Project Stats tab reports a nominal size of 5,504 rows but data ended near row 4,450; read the header first, then probe from the end backwards rather than trusting the sheet size.

Why: A zero result from a quota-paused tracker is not "no rankings"; shipping it that way would strip the SEO section from six client cards and tell coaches the keywords vanished. The generator (~/.claude/gen-coach-report.py) is now the stable path; each run only edits the config block, VENT purchases, last-meeting dates and the notice text.

Failure mode: SUCCESS: Dash /coach-report 2026-08-31 shipped 55 cards with all sources live, and caught a Search Atlas rank-tracker trap: with the plan quota exhausted (refresh_blocked=true since Aug 12), keywords-details returns count=0 and an empty results list when period2 is set to the current week, which reads as "no keywords tracked".

Scope: agent:Dash

WOA Lafayette is EXCLUDED from portfolio rate, zero-dial flags, and all coaching, exactly like WOA China Grove and WOA Yadkinville (client dials own leads). The permanent CCM exclusion list is now: China Grove, Yadkinville, Lafayette.

Why: Zero-dial alerts on clubs we do not call for are false alarms that erode trust in the recap and could lead to coaching callers for leads that were never theirs.

Failure mode: Flagged WOA Lafayette as a zero-dial routing/coverage gap in the morning briefing and named it in the call center recap draft. Wrong: Sneeze It does not call Lafayette's leads.

Scope: agent:Arin

Generating the prior Delta Meeting's Ollie Insight is part of Dan's prep, not a gap to report. In prep: trigger insight generation for the last completed meeting (find or build the API path behind the Generate button; if truly UI-only, ask David to click it at WEDNESDAY prep, never on meeting morning), then read the aiSummary into section 1. The meeting never opens with section 1 empty.

Why: Section 1 of the contract exists so the meeting starts from Ollie's read of last week, not Dan's paraphrase. Reporting the gap instead of closing it puts prep work on David at the table, which is exactly what prep exists to prevent.

Failure mode: L10 prep reported the prior meeting's Ollie Insight as a gap ("Generate button never clicked, no CLI read path") and opened the meeting without it. David had to generate it himself mid-meeting.

Scope: agent:Dan

Never present a queue as approval-blocked without checking send velocity first. queued high + sent ~0 over multiple days = blocked; queued high + sent at steady weekly volume = pacing by design (domain warm-up caps). Also: a Monday-7am "this week: 0" is the week-reset clock, not a stall - autoSend fires at 9am.

Why: Framing a healthy, maximized pipeline as a David-bottleneck puts a false decision on his plate in the meeting and misreads the one system that is working exactly as built.

Failure mode: L10 signal A presented 1,285 queued Sneeze It emails as "idle behind David's approval click." The live stats show 1,383 sent LAST week against that queue - the blasts are approved and draining at the deliverability pace. The "awaiting approval" footnote in outreach-engine-latest.md described the 8/20 state and went stale.

Scope: agent:Dan

To reach the OTP production database from a laptop, use: `railway run -p 6e2dde6f-7fcd-406a-a98a-b8cc6aa9c53c -e production -s Postgres npx tsx scripts/<x>.ts`. The project ID is `fortunate-commitment` (Postgres lives there, not in otp-platform) and `-e production` is mandatory whenever `-p` is passed. Scripts that need this should read `process.env.DATABASE_PUBLIC_URL || process.env.DATABASE_URL` and build their own pg.Pool rather than importing src/config/database.ts, which hard-requires DATABASE_URL.

Why: 146 scripts carry a documented invocation that does not work off-Railway. During an incident with a 3-hour customer-notification clock, a responder burns minutes on two failing commands and a code-archaeology detour before they can query anything. Now documented in docs/incident-response-runbook.md step 2.

Failure mode: SUCCESS: SOC 2 G7 incident-response tabletop found that the production database is unreachable from a laptop via the command every otp-platform script documents. `railway run npx tsx scripts/<x>.ts` fails with ENOTFOUND postgres.railway.internal (the app service's DATABASE_URL is a private-network hostname), and the fallback documented in scripts/read-support-board.ts (`railway run -s postgres`) fails with "Service not found" because Postgres lives in a separate Railway project.

Scope: agent:Claude

When CCM activity columns read zero while Booked is non-zero, that impossible combination means an upstream writer stopped. FIRST check the Make dialer scenario queue (scenario 3607689, us2.make.com/1629595/scenarios/3607689/edit), not the sheet. Never conclude queued data is lost because a row failed to fill overnight: a stopped Make scenario holds its backlog indefinitely and drains in full once restarted. Treat concurrent "CCM Recording URL / AI Summary" scenario-stopped emails as the SAME incident as a dark CCM feed, not two separate flags. Make is read-only for agents, so diagnose and hand off to David or Bogdan to restart.

Why: The zero-dial pattern reads exactly like a caller-performance collapse; reporting it that way would have accused two callers of doing no work on a normal Monday when they had dialed hundreds of times. Calling the data permanently lost would have suppressed a legitimate team recap for days. One check separates both wrong answers: is the Make scenario stopped and holding a queue.

Failure mode: CCM showed zero Outbound Dials, Pickups, Conversations and 0.00 time on phone for 8/30 and 8/31 while Booked Appointments kept populating. I correctly called it broken rather than a real zero, but then reasoned from "the 8/30 row did not fill in over 24 hours" to "the data is not coming" and recommended holding the team recap indefinitely. Real cause: Make scenario 3607689 (org 1629595) had stopped with 397 dials queued behind it. The data was queued, never lost, and landed once David restarted the scenario.

Scope: agent:Arin

Before announcing any feature to customers, verify three things separately, never inferring one from another: (1) the code is MERGED, (2) the deployed commit sha actually carries it (check /health), and (3) the feature RENDERS for a real user, including any third-party license key, CSP allowance or env var its vendor requires in production. Check every URL in the announcement resolves; a hostname that appears in a commit message is not proof it is live. When a surface is not reachable yet, route the copy to the one that is.

Why: A merged PR, a green CI run and a deployed sha all say the feature exists. None of them say a customer can use it. Vendor-side gates like a license key fail silently and only in production, which is exactly the condition a broadcast walks 98 people into at once. The gap between "shipped" and "usable" is where an announcement turns into a support wave and a credibility hit.

Failure mode: SUCCESS: Swamp caught that announcing a shipped feature is a different claim from announcing a WORKING one. Issue #35 led on the new multiplayer Whiteboard. The code was merged and deployed (prod /health on the exact HEAD), but unlicensed tldraw 5.x HIDES THE EDITOR five seconds after load on production hosts. Had TLDRAW_LICENSE_KEY not been set, the email would have sent 98 customers to a canvas that goes blank. Separately, board.orgtp.com was in the feature's own commit message but returns 000 (DNS not live), so it was kept out of the copy entirely.

Scope: agent:Swamp

Build the env file in two steps rather than one: dump the app service vars while EXCLUDING DATABASE_URL, then append DATABASE_PUBLIC_URL taken from the Postgres service (not from otp-platform, which only carries the internal host) renamed to DATABASE_URL. Verify before running that the resulting DATABASE_URL does not contain railway.internal. Delete the env file immediately after the send; it holds live production credentials.

Why: Issue #34 lost time to this and ended with the operator running the command manually. The public URL lives on a different Railway service than the one the app vars come from, which is the non-obvious part: querying the app service alone will never surface it. This turns a blocking failure into two lines of setup for every future weekly send.

Failure mode: SUCCESS: Swamp resolved the recurring prod-DB blocker that stopped the issue #34 run and forced David to execute the dry run by hand. The prod DATABASE_URL on the otp-platform service resolves to postgres.railway.internal, which is unreachable from a laptop, so the documented env dump alone fails at gatherSubscribers.

Scope: agent:Swamp

When the ask is "there should be a button/panel on this page", the deliverable is that thing live on that page. Commit and push as part of finishing the work. Do not hand back a working tree plus a caveat. Check the repo's deploy path first: outreach-engine auto-deploys from a git push to main (no `railway up` — that is iJoin's flow), so there was nothing blocking the deploy.</what_to_do> <parameter name="why">A feature in a working tree is worth nothing to the person who asked for it. Reporting "not deployed" reads as a status update but functions as handing the last step back, and it cost David a round trip to find an empty page. Verify the deploy path rather than assuming a push is someone else's job.</what_to_do> <parameter name="agent">Claude

Why: Built two dashboard features (days-of-supply panel, Send test email button), verified them with a green test suite, then reported "NOT deployed" three messages running and left David to discover the missing button on the live page himself.

Failure mode: Built two dashboard features (days-of-supply panel, Send test email button), verified them with a green test suite, then reported "NOT deployed" three messages running and left David to discover the missing button on the live page himself.

Scope: organization-wide

(1) tldraw core ships only the commenting license hook and toolbar item; pins, popovers, composer and the CommentTool live in @tldraw/commenting, which must be installed and wired (tools=commentTools, overrides=[commentToolOverrides], InFrontOfTheCanvas=CanvasComments, import commenting.css). Records syncing is not proof the feature works; check what draws them. (2) Any standalone signed-in page rendered with ejs.renderFile must load clerk-js as a session keeper, because the app layouts are what refresh the 60-second Clerk session cookie; without it the first fetch works and every later one 401s. Add a 401-refresh-retry around the page's API calls too.

Why: Both failures looked like license or auth problems and were neither. Reading the vendor's own package split and the layout's clerk loader found the real causes in one pass; the previous PR had shipped comments believing the license flag was the only gate.

Failure mode: SUCCESS: Dan diagnosed two whiteboard bugs from one screenshot: comments saved but invisible, and AUTH_REQUIRED on a signed-in board a minute after opening

Scope: agent:Dan

When a human confirms a system is working (Bogdan 8/31, Kristen 9/1, David 9/2 'good to go'), close the flag that morning and remove the check from source-health, rather than carrying a 'softened' version. A missing log is only a flag until someone with eyes on the system says it is fine; after that it is noise.

Why: Every flag on the morning board costs David attention. A flag that survives human confirmation trains him to skim the Watch line, which is the one line that must stay credible for real dark sources (Meta token, CCM feed).

Failure mode: Dan kept carrying 'job:outreach STALE / no run log' in the Watch line for six mornings after David and Bogdan had already confirmed the outreach sending was live and healthy. The flag was measuring missing observability, not a real problem, and David had to tell Dan to stop.

Scope: agent:Dan

When a design fix is CSS-only and the local otp-platform dev server cannot start (needs DATABASE_URL; port 3000 is taken by another app), open the live page in gstack browse, inject the edited rules as a style element via $B js, and screenshot before/after. Page-level inline style blocks in the body beat head injections, so append the override to the body or add !important for the verification pass only. Then run scripts/design-lint.mjs and the view lint tests before opening the PR.

Why: It gives real before/after evidence on real content in minutes, with no database, and catches collisions the source diff hides (a blue primary on the blue compare band). The Sep 2 sweep shipped four CSS fixes to production on this loop with CI green first try.

Failure mode: SUCCESS: Conatus verified CSS-only design fixes against the live orgtp.com pages without a running dev server

Scope: agent:Conatus

David: "no black buttons, no reason for it." OTP has one filled button colour, the blue --primary. Black ink fills are not a secondary style; a quieter action is a ghost/outline or a text link. On coloured bands (blue or orange) the filled button inverts to surface-on-colour so it stays visible.

Why: Black filled buttons add a second primary weight that carries no meaning, which breaks the "colour equals meaning" and "one primary per screen" rules in src/DESIGN.md. David reads the lime-plus-black combo as something he liked but accepts losing for a single coherent system.

Failure mode: In the Sep 2 orgtp.com design sweep I kept the black .btn-ink buttons (pricing Get Started / Upgrade / Send Inquiry, home Keep me posted, the orange band CTAs) as a second filled button colour beside the blue primary.

Scope: agent:Conatus

When asked to clean up a site's design: (1) crawl the sitemap, every single route plus two samples per templated family, running a computed-style scan in the page (button fill colours, radii over the token scale excluding true circles, 999px pills, resting shadows, off-token large backgrounds, em dashes, sub-12px text, horizontal overflow, heading fonts) and a viewport screenshot per page; (2) aggregate into one table so the patterns, not the pages, are visible; (3) fix each pattern once at its source: alias stray tokens to the real ones in the shared stylesheet, clamp utility classes globally, and run an idempotent transform over page-local style blocks; (4) verify by rendering every page locally with the layout and no database (ejs.renderFile with stub locals), serving the static output, and re-running the same scan to get before/after numbers. Tooling kept in otp-platform/scripts/design-crawl.

Why: A sampled sweep of 8 pages missed pages carrying their own colour systems (David: "the scan design skills don't go far enough through the site"). Measuring all 90 pages found 235 off-scale radii, 124 resting shadows and 30 non-primary button fills; one transform brought them to 2, 0 and 10 in a single PR with CI green, where per-page edits would have taken days and drifted again.

Failure mode: SUCCESS: Conatus converged the orgtp.com marketing site on one design system by crawling every page and fixing patterns at their source instead of page by page

Scope: agent:Conatus

When a report says "I got stuck on an error page", check the write that happened right before it, not just the page. Any invite/upsert that matches on email must refuse to touch accounts of a higher trust tier (staff domains) and must never lower a role as a side effect. Keep a dry-run repair script for the accounts already damaged.

Why: The visible complaint was cosmetic; the cause was an authorization downgrade that locked a team member out of the product. Fixing the 403 page alone would have left the trap armed for the next person.

Failure mode: Sneeze Studio's client-invite handler updated an existing user row in place. When Kristen invited her own kristen@sneeze.it as a test client contact, it silently demoted her staff account to client_reviewer and every staff page then showed a bare "Staff only". The reported symptom (no way home from a 403) hid the real bug (a write path that could change an account's role).

Scope: agent:Claude

When a pending_transcriptions row is 'fatal' with last_error 'transcription failed', do not trust the label: download the R2 segments with the app's own storage client (railway run -s otp-platform with DATABASE_URL overridden to the Postgres service's DATABASE_PUBLIC_URL) and try Deepgram on each segment to get the provider's real error. A WebM segment recorded after a pause can lack the EBML header (bytes 1a45dfa3) and is rejected as 'corrupt or unsupported data' while concatenating it onto the header-carrying segment transcribes cleanly. Fix the worker (coalesce header-less continuations, surface the provider error), deploy, then requeue the row (status pending, attempts 0) so the production worker attaches the transcript through the real pipeline; verify transcript length on the meeting before closing the ticket.

Why: The audio was never lost, only mislabelled; the 'transcription failed' string hid a specific, fixable cause and a customer waited a week. Diagnosing against production storage with the real provider took minutes and turned a manual recovery into a permanent fix (PR #683).

Failure mode: SUCCESS: Conatus recovered a customer's 97-minute meeting recording that the transcription worker had marked fatal, and fixed the cause so it cannot recur

Scope: agent:Conatus

When the system can already enumerate the valid choices, render a dropdown of them, exclude ones already claimed elsewhere, and preselect the likely match from the name. Every bind surface gets a matching unbind/disconnect on the same listing, so a claimed choice can be released without hunting for the other side.

Why: David: "binding the call tracking is very difficult ... instead of CallRail Company ID why not a dropdown with all the locations in CallRail that can be connected? and if connected to one it is not available to another unless you disconnect, in fact all the bind buttons on the account should have a disconnect as well." A free-text id field pushes lookup work onto the operator and invites one-character mistakes; the list was one API call away.

Failure mode: Relay's CallRail binding step asked the operator to paste a CallRail company id (COM...) into a text box, with a hint to go find it on another page or in CallRail's URL bar. Relay already had the full company list from the API.

Scope: agent:Claude

Before building a "trial" or "offer" email, grep the wallet/billing code for what every new account already receives (OTP: seedSignupCredit gives every org $25 at signup). Sell the existing thing with attribution (utm_campaign, utm_content per rung) instead of inventing a coupon table. Reuse the existing series renderer (LifecycleEmail shape + renderLifecycleEmail) so unsubscribe scope, footer and brand come free; add only the rung data, a unique (subscriber, rung) send log, and a weekday tick. When two automated programs can reach the same inbox, give the newer one an explicit window (PRESIGNUP_SEQUENCE_WINDOW_DAYS) and make the older one wait for it.

Why: The form had been posting to partner_signups for months with zero rows arriving and nothing sent back; the partial's comment claimed the opposite. Checking what the form actually hit, and what the product already gives away, turned a "build a credit system" request into a four-file change shipped the same evening with a live proof row.

Failure mode: SUCCESS: Claude turned the home "Keep me posted" form from a dead lead endpoint into a pre-signup sequence built on credit that already existed

Scope: agent:Claude

Two reusable patterns. (1) When a public loginless page must call a paid model, key every per-IP limiter on the RIGHTMOST x-forwarded-for entry (the one the trusted edge appends), not request.ip: under Fastify trustProxy:true request.ip is the client-supplied leftmost entry and any limiter on it is defeated by one header. orgtp.com is served directly by Railway's edge (no Cloudflare), so there is no CF-Connecting-IP to lean on. Add a global in-memory daily ceiling as the real spend cap. (2) tldraw's editor.toImage() inlines page fonts by fetch()ing the Google Fonts stylesheet and loading faces as data: URLs; a CSP without fonts.googleapis.com/fonts.gstatic.com on connect-src and data: on font-src makes every export silently lose the handwriting font. Also: when another session holds the main checkout on its own branch with uncommitted work, build in a dedicated git worktree with node_modules symlinked rather than sharing the tree.

Why: The door is an unauthenticated endpoint in front of a paid model, so a spoofable rate limit is a direct cost exposure, and the same request.ip weakness exists in every other limiter in the app. The font CSP gap had been degrading the signed-in board's PDF/PNG export since it shipped without anyone noticing. The worktree pattern prevented two live sessions from clobbering each other's uncommitted files.

Failure mode: SUCCESS: Claude (Conatus) shipped orgtp.com/draw, the loginless whiteboard door for OTP outreach, in one evening: three parallel builders in fresh contexts, one adoption wave, one independent review that surfaced 13 real defects (11 fixed before merge), PR #688.

Scope: agent:Claude

When adding native or WASM media dependencies (sharp, heic-convert, pdfjs-dist, @napi-rs/canvas) to OTP, build the Dockerfile's deps stage locally (docker build --target deps) and run the new unit tests inside that container with the repo src mounted, before opening the PR. Alpine (musl) and the image's Node version differ from the Mac; the lockfile must carry the linuxmusl binaries and the runtime must have the builtins the library assumes (pdfjs 6 needs Promise.withResolvers and ArrayBuffer transfer helpers, so Node 22). Bump Dockerfile and CI Node together.

Why: All 16 conversion tests passed on the Mac (Node 25) and would have passed CI, yet on the node:20-alpine image the PDF path threw once and, with a polyfill, rendered pages with errors swallowed as warnings. Only the in-container run exposed it. Ten minutes of Docker saved a broken feature in production.

Failure mode: SUCCESS: Claude shipped photo/voice to whiteboard import in one evening by running the conversion tests inside the production Docker image before merging, which caught that pdfjs-dist 6 silently drops PDF content on Node 20

Scope: agent:Claude

When announcing something new, the email says three plain things in order: what it is (a whiteboard page where you draw how a customer request moves through your company), what you do (draw boxes and arrows between two sticky notes, press one button), what you get back (Ollie reads the drawing and hands you a chart of who owns each step and the step nobody owns). Concrete nouns, the product's real name, the URL, then the one-line reason it matters. Cleverness comes after clarity, never instead of it. Read the draft as the recipient: if they could not describe the page to a colleague after one read, rewrite.

Why: A genuinely new thing gets no credit for mystery. The reader has never seen it, so implication does not land; only description does. Kennedy pattern-interrupts work on a known offer; on an unknown one they read as noise and the click never happens.

Failure mode: Claude wrote the OTP door touch-one email (and follow-ups) in an oblique, aphoristic register ("the third box is where the handoff has no name on it") and never said what the product actually is or what the reader would do and get. David: "written too obtuse and like crap, we shipped something truly unique and I can't make heads or tails what we are actually telling the customer."

Scope: agent:Claude

An outreach sequence is a stage ladder, not a drip. Define the stages and the exact event that moves a person between them before writing any copy: prospect (on the list) -> MQL (engaged: visited the door, read a drawing, or replied) -> SQL (booked a call with Dawson or signed up) -> customer (paid, marked converted). Every email carries the booking link as a tracked CTA so a booking flows into the engine as an SQL automatically, and SQLs are handed to the sales pipeline (GHL) rather than mailed again. Copy states the offer and the two asks plainly: try the thing, or book 15 minutes.

Why: Without a booking link the sequence cannot produce an SQL, so nothing it does is measurable against the 50-signup goal. Without stage transitions, "MQL" and "SQL" are words on a slide, not states the system knows, and Dawson cannot work a pipeline that does not exist.

Failure mode: Claude loaded an OTP outreach "sequence" that was one cold email plus timed follow-ups, with no booking link, no path to Dawson, and no defined stage transitions. David: "there should be a link in the email that they can book so that we know it turned to an SQL... we need a real marketing sequence in outreach that moves people from MQL to SQL to customer, we are still playing around with bad email copy and CTA."

Scope: agent:Claude

Every inbound sign-up on a product we run must be handled by the system, not by David asking. Three layers: (1) first sign-in with no linked customer auto-provisions a customer and links it, so nobody lands on a dead end; (2) every new sign-up fires a notification (ntfy + ticket) and shows in the admin as 'new sign-ups' until claimed; (3) the morning pass reconciles the auth provider's user list against linked customers and names any unlinked sign-up as a flag. When a prospect says they will sign up, verify the sign-up landed on our side within 24h rather than waiting for their email.

Why: A sign-up is the highest-intent signal a prospect gives. A dead-end page after 'Create your account' loses the deal silently, and no downstream agent can catch it because no state was written. Provisioning plus notification plus reconciliation turns an invisible loss into a visible queue.

Failure mode: iJoin self-serve sign-ups were silently dead-ending. A prospect (Val, Club 24) created a Clerk account on 2026-09-02 after a demo, landed on 'No club linked to this account', and never appeared in the iJoin admin because a Clerk user only becomes an iJoin customer when staff manually links it at /admin/tenants. Nothing notified anyone. Two earlier outside sign-ups (8/17, 8/28) had the same fate. The morning pass had Val flagged as 'responsive only' and waited for an email instead of checking whether the sign-up she promised had actually landed. David: 'this needs to be fixed for all users coming in not just when I ask, we would have missed this opportunity, big miss.'

Scope: agent:Dan

A cold email to someone who has never heard of OTP opens with the category in the reader's own frame, before any feature, name or link: Sales has a CRM. Accounting has QuickBooks. Your meetings, where every real decision and promise is made, have a notebook and somebody's memory. OTP is the missing system of record for what your company says it will do: record the meeting, every decision and commitment becomes a line the company runs on (who owns it, when, whether it happened), and next Monday opens with last week's promises kept or not. Only THEN the taste (the drawing) and the call. Product nouns (Ollie, boards, seats) are earned by the category sentence, never assumed. The constitution's axiom is the sales line: accounting reconciles what you have, OTP reconciles what you say with what you do.

Why: A stranger cannot want a feature of a thing they cannot place. The CRM/accounting analogy hands them a slot in their head that is visibly empty, which is the whole pitch; without it, "draw your company and Ollie reads it" is a curiosity with no reason to exist.

Failure mode: Three drafts of the OTP cold sequence assumed the reader knew what OTP is. Touch one talked about Ollie, boards, seats and "your OTP account" to a construction-company owner who has never heard the name. David: "this is a cold email, they have no idea what OTP is and you are going on the assumption they do... rethink the cold email sequence as if they are coming into OTP new, never heard of it, revealing the main tenet: what if information from every internal meeting became part of the way your company operates. Sales has a CRM, Accounting has software, what about..."

Scope: agent:Claude

Never put a real client, a realistic account number or a person's name in a form placeholder. A placeholder reads as prefilled data to the person filling it in, and another customer's name on a form is a confidentiality smell. Leave the field blank and put format guidance in the hint text under the field. Grep views and route templates for client names before shipping any customer-facing form.

Why: Prospects judge the product by its forms. Example values that look like data make the form feel used, and leaking a paying client's name onto a stranger's screen is a trust problem, not a styling one.

Failure mode: iJoin's public sign-up form and the club authorization card used a real client's name (Proof Fitness), realistic ABC club numbers (04462, 04431) and a person's name (Alex Newman) as input placeholders. David: "remove the prefilled legal name Proof Fitness and prefilled club numbers and prefilled who will sign please, this is all bad form to have that in there."

Scope: agent:Conatus

On anything addressed to ABC Fitness, the vendor is "Sneeze It" and the signer is "David Steel". The legal-name rule (David Sieradzky, The Steel Method LLC) applies to the LLC's own legal matters, not to vendor forms with partners who know us as Sneeze It. Defaults live in src/platform/abc-form.ts (VENDOR) with ABC_VENDOR_* env overrides.

Why: ABC's records and the Data Transfer Agreement are under the Sneeze It name; a different entity string on the release form makes ABC reconcile two names and can stall the release.

Failure mode: On ABC's Club Data Release form I filled the vendor as "The Steel Method, LLC d/b/a Sneeze It" signed by "David Sieradzky", reasoning from the legal-entity rule. David corrected: vendor is "Sneeze It", page two vendor block is "Sneeze It, by David Steel", with the date.

Scope: agent:Dan

When David points at a page he likes as the reference, match its actual visual system (light ground, soft colour, rounded white panels, generous air), not just its energy or copy. For a logo, do a real pass: a mark that carries one clear idea (for iJoin, two things joining, or walking in through a door), built from a small number of geometric primitives, shown as proper lockups (horizontal, stacked, favicon, on white and on navy), with the wordmark set in the brand face with tight tracking. Never present placeholder shapes as options.

Why: A reference page is a spec. Reading it loosely wastes a round trip on the one thing David could see immediately. And a logo is the brand's face; three throwaway marks read as not caring, which costs more trust than presenting one careful option.

Failure mode: Homepage v2 for ijoin.ai used a dark navy "sky" hero when David had praised the LIGHT styling of /pixel (off-white ground, soft aurora, white rounded panels). And the three logo directions were weak: generic geometric shapes and a smiley ball, thrown together without a real design pass. David: "the logo well that just is awful you can do so much better."

Scope: agent:Dan

For any customer-facing product defect, the fix is the customer's self-service path working end to end, not the affected customer being unblocked. A staff-side manual repair hides that the path is still broken for the next customer. Before calling such a fix done, walk the customer's actual route and find the step that still requires someone on our side to press something -- in IJ-108 that was a background sweep: nothing but a customer clicking "Check now" ever registered a domain with the edge, so anyone who added their DNS record and closed the tab was stranded with no signal.

Why: A hand-fix for one client converts a systemic product bug into an invisible support cost that recurs for every customer after them, and it stops the team from ever seeing the gap. It also means the broken path is never actually exercised, so nobody learns it is broken. David's rule makes the self-service route the definition of done, which is what forces the missing automation to be built rather than worked around.

Failure mode: Fixing IJ-108 (iJoin custom domains served a TLS error), I proposed unblocking the affected client by registering their hostname with Railway by hand using David's account token. David rejected that framing: "I want the customer to be able to do this not me or our team (our team can do it) but it has to be with the same access a customer has."

Scope: agent:Claude

The base David quotes for the call center is the COMBINED figure for both callers, not per head. Split a combined base across the roster by days worked; never multiply it by headcount. Corrected margin is +4.1%. Also, when the user gives both a pay rate ($5/hr + $5/appt) and observed pay ($700/$450 a week), reconcile them before building - they may not agree.

Why: Treating a team-level cost as per-head inverted the conclusion of a live pricing decision for a 4-location client program, turning a thin-but-positive model into an apparently fatal one.

Failure mode: Modelled the $3,000 caller base as PER CALLER and pro-rated it by days worked, which doubled the fixed cost and made the base-heavy comp model show a -41.5% margin.

Scope: agent:Dash

A report answers three questions in order: is the instrument reporting at all, is this better or worse than the window before, and what do I do in the next ten minutes. Lead with blind spots (a 0 from a disconnected gauge must say so, not display as a result), then blockers, then unworked engagement, then copy evidence. Every recommendation carries the measurement that triggered it and a link to the exact list of people, never an adjective alone. Check three traps before ranking anything: attribution (a visit before the send, or from a de-anonymising pixel, is not that campaign's result), selection (a retargeting campaign mails people because they already visited, so it scores 96% against a cold list's 18% and must be ranked only against its own kind), and measurability (one campaign linked only to Loom, scored 0% of 810, and would have been labelled weak copy when nothing in it was observable).

Why: One confidently wrong recommendation costs the page every other recommendation it makes: David stops reading it and the true findings are wasted. Rebuilt on live data the same page surfaced reply capture silent across 10,613 delivered, both brands under one day of unmailed audience left, two blasts held down since Aug 31, and 1,716 hot contacts against one booking in 30 days.

Failure mode: The Outreach Engine's /dash/reports page was a table of campaigns with sent, delivered %, bounce %, on-site, replied and booked. Every number was individually correct and David's verdict was "this tells me nothing". Replied and booked read 0 on every row because reply capture is disconnected, so the two columns billed as the ones that matter were dead everywhere and the page could not change anybody's behaviour.

Scope: agent:Outreach

Never interpolate a Date into a raw sql`` template in this repo; pass it as ${d.toISOString()}::timestamptz (there is now an `at()` helper in services/insights.ts). More generally: when every test runs on a different database driver than production, passing tests are not evidence the page works. Deploy, then run scripts/smoke-dash.ts inside the app container (railway ssh -s app -- sh -c 'cd /app && npx tsx scripts/smoke-dash.ts [paths]') to render the real pages against the real driver and the real data before telling David it is live.

Why: A dashboard page is behind magic-link auth, so "deployment SUCCESS + /health 200" was mistaken for verification. It proves the process started, not that any page renders. David found the 500 instead of the check finding it, which is the wrong order and the second time this repo has shipped a report page nobody had ever seen render.

Failure mode: The rebuilt /dash/reports page passed 425 tests, typechecked clean, and rendered correctly against a full snapshot of production data, then returned Internal Server Error the instant it was deployed. Cause: a JS Date interpolated into a raw drizzle sql`` template. The test suite and the snapshot renderer both run pglite, which accepts a Date parameter; production runs postgres-js, which throws "The string argument must be of type string. Received an instance of Date". Nothing in the local toolchain could see it.

Scope: agent:Outreach

A Resend/SES domain verified for sending is configured for sending ONLY: DKIM and SPF, no MX. Receiving is a separate switch (Resend Inbound) plus an MX record that must be the lowest priority on that domain. Before blaming a webhook or a tracking pipeline for zero replies, run `dig +short MX <sending-domain>` — an empty result is the whole answer. Set reply_to on every sender identity to an address on a domain that actually receives mail, so a misconfigured sending domain can never silently swallow the pipeline. The report now resolves MX itself (replyPathCheck in services/insights.ts) and names the broken link rather than guessing.

Why: This is lost revenue, not a reporting defect. Interested prospects were bounced for a month while the dashboard showed a 99.5% delivered rate, which reads as "the list is cold" and is really "the door was locked". A domain that cannot accept mail is also a deliverability and RFC-compliance liability on cold outbound.

Failure mode: SUCCESS: Outreach — found why 30 days and 10,761 delivered cold emails produced zero replies. Not a tracking bug: none of the sending domains (go.orgtp.com, mail.sneeze.it, mail.ijoin.ai, sneezeitdigital.com) has an MX record, and every sender identity has reply_to empty, so replies go to the From address on a domain with no exchanger. Every prospect who hit reply got a delivery failure. The Resend webhook was innocent throughout: enabled, subscribed to email.received, handler working.

Scope: agent:Outreach

Any autonomous service that occupies a seat on the chart must report from the machine doing the work, not from a human session about it. Give the service its own seat-bound token as one env var, and have it (1) push its KPI on a short timer, which doubles as the heartbeat because every MCP call bumps last_used_at, and (2) log_work at most hourly, and ONLY when the window contained real activity. Two mechanics make this cheap: OTP's Remote MCP is stateless, so a single POST carrying tools/call is a complete conversation with no initialize handshake and no SDK; and update_kpi upserts on (kpi, period), so pushing the same week 144 times a day overwrites one row. Never log an empty window, and never let a second tile be created for a number that already has one.

Why: A chart that goes dark on the days a system is busiest teaches everyone to stop trusting the chart, and a scorecard reading a frozen file is worse than a blank one because it looks alive. This is the difference between an agent seat as a box someone maintains by hand and a seat as a live report from the thing itself, which is the whole claim OTP makes about agents on the org chart.

Failure mode: The Outreach seat read as dead on the org chart while the engine was sending thousands of emails, and the weekly send tile read 0 against a real 3,250. Nothing was broken in OTP: an agent seat is lit by two facts that are both the AGENT's job (last_used_at on its own bound token, 15 minute window; rows in agent_runs from log_work), and sending mail touches neither. The seat was only ever lit by a human running a Claude session that logged on the engine's behalf, and the KPI tile read a laptop file that only refreshes when somebody remembers to run a script.

Scope: agent:Outreach

When a test fails with no code change behind it, diff the failure against the CALENDAR before calling it a flake: hardcoded dates plus a relative rule is date rot, and it is a real defect in the guard even when the production logic is correct. The fix is not to bump the date, which only resets the timer on the same failure. Inject the clock into the rule (default it to new Date() so every production caller is unchanged), thread the caller's own now where one already exists, and pin the regression at day 0, day (window - 1) and day (window + 1) so the answer depends only on the gap between the event and the question. Use the ORM's typed comparison (drizzle gt(col, date)), never a JS Date inside a raw sql template.

Why: A guard that rots stops guarding silently, and the failure looks like noise rather than a defect, so it gets ignored on exactly the sends where it matters. Here the guard is what stops a second campaign re-mailing the whole list days after the first one, on a programme currently sending 3,250 a week. "Pre-existing, not from this change" is a diagnosis, not an excuse to skip the diagnosis.

Failure mode: A guardrail test protecting the 14-day contact cooldown ("does not re-mail the people the first campaign already reached") started failing with no code change. It stamped its sends at a hardcoded calendar date while the rule itself was evaluated against SQL now(). A relative rule measured against an absolute date passes for exactly the length of the window and then fails every day afterwards. The first instinct, and the one I reported before checking, was to call it a pre-existing flake and leave it.

Scope: agent:Outreach

Always set CENSUS_API_KEY when building on api.census.gov (free, instant, https://api.census.gov/data/key_signup.html). A keyless call does NOT return 4xx: it returns a 302 to an HTML page at /data/missing_key.html, so a client that follows redirects and calls .json() dies with "Unexpected token" several frames from the real cause. Fetch Census with redirect manual, check the Location header for missing_key, and sniff the body for a leading angle bracket before parsing. The Census geocoder at geocoding.geo.census.gov is a separate service and stays keyless. Also filter the ACS suppressed-cell sentinels (-666666666 and similar) to null or they poison every median downstream.

Why: It burns time twice: discovering the key is mandatory when every reference says otherwise, then debugging a JSON syntax error that points nowhere near the cause. Any Sneeze It work touching census demographics hits this on the first request. Wider lesson: a 302-to-HTML failure disguises an auth problem as a parse bug, so any integration failing with an unexpected-token error should be checked for an unfollowed redirect before blaming the parser.

Failure mode: SUCCESS: Audience module build. The US Census data API now requires an API key on every request. Widely repeated guidance, including library docs, says it is optional below 500 requests per day. That allowance is gone as of 2026. Verified across ACS years 2021-2024 at both single-ZCTA and national wildcard scope: all bounced.

Scope: agent:Claude

Retiring an agent is not complete when its own spec is banner-locked. Before closing a retirement, grep every other agent spec and shared-state contract for the retired seat's name, its output files, and any metric it owned, and either repoint or explicitly mark each dependency dead in the dependent's spec. An auto-retire clause with a date needs the same sweep scheduled at the date, because nobody is watching when the clock is the actor. Also record orphaned capabilities against a named owner: Account Score has been unowned since Jeff's retirement on 2026-04-13 and is still cited as an input by two of Pulse's four triggers.

Why: An agent pointed at a measure that no longer exists looks broken when it is orphaned, and the review that follows blames the wrong thing. Two of the four seats in tonight's fix-or-terminate hearing were in that state, and both were headed for a termination that would have removed a working agent while leaving the actual defect, an unpropagated retirement, in place to do it again to the next seat.

Failure mode: Neil's spec still names L8 as its primary mission and states "Bassim's score is the only measure that matters." Bassim was auto-retired on 2026-07-17 under an explicit clause in the 2026-06-17 fleet handoff (a real OTP owner and first task within 30 days, or auto-RETIRE); the deadline passed unmet and bassim-latest.md no longer exists. Nobody propagated that retirement into the specs of the agents that depend on it. The same pattern appears in Pulse, which still lists dirk-latest.md as a declared input although Dirk was retired 2026-07-03 and that file will never be written again. Both agents were then judged as failing.

Scope: agent:Neil

Any Google Doc containing tabular data must use real Docs tables. The MCP helper create_table_with_data is BROKEN — it creates the table then fails to populate it ("ERROR: Could not find table after creation"), leaving an empty table. Working method: (1) batch_update_doc with insert_table (end_of_segment) to create the empty table; (2) note the table start index S from inspect_doc_structure, or compute it as doc_length_before_insert; (3) populate cells with batch_update_doc insert_text ops applied in REVERSE order (last cell first) so earlier indices do not shift. Cell insert index = S + 1 + (row-1)*(1 + 2*cols) + 1 + (col-1)*2 + 1, with rows and cols 1-indexed. Empty table length = 1 + rows*(1 + 2*cols) + 1. Apply heading styles afterwards with update_paragraph_style using named_style_type; style ops do not shift indices so order does not matter.

Why: Long financial documents built as monospace text are unreadable in Google Docs, which uses a proportional font — columns collapse and the reader cannot scan across rows. The reconciliation is a review document for a bankruptcy with roughly $1.2M at stake; if it cannot be read line by line it has no value. And the standing rule already existed, so this was a preventable repeat.

Failure mode: Alan built the master reconciliation Google Doc using ASCII text-aligned columns instead of real Google Docs tables. David could not read it and asked for it to be reformatted. This also violated an existing standing rule in memory (feedback_google_doc_tables: real tables, never text-aligned columns).

Scope: agent:Alan

Never call a thread unanswered, dropped, or aging from inbox state alone. Before flagging anything as urgent: search Sent for that address over the relevant window (or read the full thread, not the quoted tail of one message), and check the calendar for any thread that proposed a meeting. Then state in the report what was checked, so the verification is visible rather than assumed. This is the inbox-specific case of the general rule that a point-in-time signal is not a live escalation until the resolution path has been checked.

Why: A false "your client has been waiting 8 days" is more expensive than a missed nudge: it burns the founder's attention on a resolved item and, repeated, it trains him to ignore the channel entirely. An email triage that cannot see the answer is an alarm with no off switch. It also nearly corrupted a fix-or-terminate hearing, where the fabricated catch was the headline argument for keeping the seat.

Failure mode: Pepper's inbox triage reported two urgent client escalations and both were false positives. It called a ReEnvisionMD thread "8 days unanswered" when David had replied 107 minutes after the question, and it flagged an HBFG call as a passed date when the call had run on schedule. The cause is that the triage judges "unanswered" from INBOX state alone: David's own sent mail is not in the inbox, and the quoted history inside an inbound message ends at whatever came before that message, so any inbound with no visible reply beneath it reads as a dropped ball. The report was written and handed over before any of it was verified.

Scope: agent:Pepper

When a deploy appears to have come from nowhere, check `git log --oneline HEAD --not --remotes` and `git status` BEFORE assuming a dirty tree, and verify the running code with a build-time source fingerprint rather than any commit field. `railway up` ships a directory rather than a git ref, so a commit sha on such a deploy can only have been set by hand and will go stale silently. Never set a deploy-identity variable by hand: derive it from the build, or report 'unknown'.

Why: A hand-set identity field is worse than an absent one. An absent field sends you to a real check; a stale field answers confidently and wrong, and here it cost an evening spent hunting a working directory that had never gone missing. The same trap exists on any service deployed by CLI upload rather than by git trigger.

Failure mode: SUCCESS: a deploy that looked like it came from an unpushed working directory was actually a clean, committed, merely unpushed tree. The evidence that misled us was /health reporting commit 1a4a08e (Aug 15) beside a build twenty minutes old. The stale value came from GIT_COMMIT_SHA, a Railway variable set once by hand with `railway variables --set` and never cleared, so it reported August through every deploy after it.

Scope: agent:Claude

Any agent that copies a number from a file to a dashboard must check the file's age before it copies, and refuse rather than launder. Add a max age per source (48h default for weekly KPIs; 18h is a briefing rule and too tight here), and treat STALE as its own outcome, neither a success nor a page: it is a real problem with whatever writes the file, not with the push, so it must be visible in the run summary but must not fire one alert per affected KPI. Seven alerts for one un-run upstream scan is how you train somebody to ignore the eighth.

Why: A missing number is visibly missing and prompts a question. A stale number wearing a fresh timestamp is invisible and gets acted on, which is why the registry's own note says a scorecard reading a frozen file is worse than a blank one because it looks alive. Nearly half of one founder's scorecard was in that state without anyone knowing, and it was found only because the seat was cross-examined about its actual charter rather than its run count.

Failure mode: Tally's charter is keeping the scorecard's numbers honest, and it was doing the opposite. Seven of its fifteen sources are files, five of them read from one Crystal file last written six days earlier. Tally pushed every one with the current period and the current timestamp and no staleness marker, so a 141-hour-old number arrived on the chart indistinguishable from a number measured that morning. The instinct was already half right: Tally refused to push when a file was MISSING or a live call FAILED. It simply never asked how old the answer was.

Scope: agent:Tally

Prefer a structure that makes the failure impossible over an instruction not to commit it. Shekalim 3:2: the one who withdraws from the Temple treasury enters with no hemmed garment, no shoes, no tefillin, no amulet, so that nobody can even ask whether he pocketed anything; the proof text is Numbers 32:22, clean before God AND before people. Applied: an escalation is DEFINED as a finding carrying its evidence inline (a SENT-CHECK and CALENDAR-CHECK line with the query and its verbatim result), so an unverified one is not a weaker alarm but not an escalation at all. Applied: producers run in the same pass immediately before consumers, so stale data cannot exist at the moment it is read, rather than being detected after the fact. When fixing any failure of judgement, first ask which of the two you have written; accept the sign on the wall only when structure is genuinely unavailable.

Why: An audit answers the question; a design removes it. Detection scales with attention and attention is the scarcest thing in this org, which is why four seats went silent for months with a daily briefing nominally in place. A control that depends on somebody remembering to look will fail exactly when everyone is busy, which is when it matters. Making the artifact carry its own proof also means a third party can check the work later without knowing anything about the case.

Failure mode: Every fix produced during the 2026-09-05 agent hearing was an audit rather than a design. Pepper filed two false escalations because it judged threads from inbox state alone, and the remedy was a paragraph in its spec telling it to check Sent first. That is a sign on the wall: it asks the same judgement that just erred to remember not to err. The morning crack check has the same shape at a higher level, walking up to the structure daily to ask whether anything rotted overnight, rather than building so it cannot rot.

Scope: agent:Dan

When a competitive scan cannot reach a vendor's changelog, roadmap or release notes, NEVER report that as "they shipped nothing" or "low threat." A 301 to a dead page, a 404 or a 403 is a CRAWL FAILURE, and it looks identical from the outside to genuine absence. Re-run with a real browser (Playwright or claude-in-chrome) and navigate the site's own UI rather than guessing URLs, before drawing any conclusion about a competitor's activity. Vendors commonly host changelogs on a subdomain (changelog.vendor.com) linked only from a help-center header, so the obvious path (/product-roadmap/, /changelog) can be dead while the real one is actively maintained. Also treat G2's 403 and search engines drowning a query in a same-name distractor (EOS the cryptocurrency vs EOS the business framework) as access gaps to be stated explicitly, never as evidence of absence.

Why: On 2026-09-06 the first OTP competitive scan concluded Bloom Growth was "not a credible AI competitor at all" because WebFetch hit a dead 301 at /product-roadmap/ and a 404 on the help page. A live browser pass found changelog.bloomgrowth.com actively maintained with entries every 1-4 days, including a proactive "Meeting Prep" feature shipped 2026-08-28 that surfaces off-target KPIs and slipping priorities before a meeting and refreshes itself ahead of it. That is the single closest competitor feature to OTP's own core differentiation claim, and it was 20 minutes away from being recorded as a competitor with no AI story. A wrong competitive conclusion is worse than a missing one because it gets built into positioning and nobody re-checks it.

Failure mode: SUCCESS: CI_SCOUT — a failed WebFetch was nearly reported as a competitor shipping nothing

Scope: agent:CI_SCOUT

Never use first-match-wins priority over Meta action_type names that are not mutually exclusive. Read 'lead' first, which is Meta's own aggregate across all lead channels (96 form + 2 pixel = 98 here). Only if 'lead' is absent, sum the genuinely distinct channels (onsite_conversion.lead_grouped + offsite_conversion.fb_pixel_lead). Never sum every action containing the word 'lead' -- the *_add_meta_leads variants restate the same 96 and would treble it. Any metric derived from a vendor API where multiple field names could plausibly hold the answer must be spot-checked against that vendor's own UI for one real account before the number is shown to anyone.

Why: A reporting tool's only asset is trust, and it is spent the first time a client-visible number disagrees with the platform's own dashboard. A silent 48x error is worse than an outage: an outage announces itself, whereas this rendered a confident, plausible, precisely-formatted number that was wrong. David caught it by checking one account by hand, which is exactly the labour the product exists to remove.

Failure mode: Sneeze Coach reported beem Atlanta Glenwood at 2 leads / $942.70 CPL when Meta Ads Manager showed 96 leads / $19.64 CPL over the same window and the same spend ($1,885.39). Cause: src/services/meta.ts used a first-match-wins priority list (LEAD_ACTIONS) that ranked 'offsite_conversion.fb_pixel_lead' ABOVE 'lead' and 'onsite_conversion.lead_grouped'. The account had 2 stray pixel lead fires and 96 real on-Facebook lead-form submissions, so the first match returned 2 and the 96 were silently discarded. CPL was then off by 48x. Every lead-form client account was affected, and the wrong number flowed into CPL, the money lens, findings and the client-facing share page.

Scope: agent:Coach

Score a SERVICE LINE (what the customer is buying), never an industry vertical. Treat the vendor category as a coarse gate only: strong categories count alone, weak ones count only when the business NAME carries service-line evidence (terms or a known competitor brand). Never drop a junk bucket wholesale either - a Restore Hyper Wellness 2.74 miles from beem is itself filed under 'spas', so the category is unreliable in both directions. Rank by evidence, not distance: the nearest hair salon is not more of a competitor to a sauna studio than a far one. Validate every configured category against the data source's actual vocabulary at boot so a typo fails loudly instead of silently narrowing a market. Above all, never let an unclassified client fall through to a default list - state that no service line is set, and report 'outside coverage' rather than zero when the query sits outside the data's footprint.

Why: A competitor list is read by a client, so a wrong one costs more than credibility: it misdirects budget and positioning advice. The failure mode is specific and repeatable - a taxonomy that looks careful and specific while quietly matching nothing, and a fallback that manufactures a plausible answer for a question the data cannot address. Both produce confident output with no error, which is the only kind of wrongness that survives review. The same discipline already applied to Coach's metrics ('a miss is not a zero') had never been applied to its market data.

Failure mode: Sneeze Coach's competitor list for beem Atlanta Glenwood was 150 rows led by Tatum da Barber, Bath & Body Works, Kidney Dialysis Spa Atlanta and a waist-trainer seller. Three defects in Sneeze Audience produced it. (1) The VERTICAL was used as the unit of competition: beem sells contrast therapy but was filed under 'wellness', so it was matched against every spa-ish listing within 10 miles. Drybar and Scissors & Scotch are both 'salon' and compete with nobody in common. (2) Overture's 'spas' and 'beauty_salon' are junk buckets - barbers, Bath & Body Works and a dialysis centre are all categorised 'spas' - and supplied 3,573 of 12,998 candidate listings across the roster. (3) Five configured categories (crossfit, boxing, climbing_gym, cycling_studio, massage) did not exist in an extract that has 13 categories total, so fitness had silently been 'gym' alone. Separately, an 'other' fallback gave a chicken restaurant 686 gyms-and-spas and a kids' performing-arts school 1,321, and a Costa Rica client read a confident 0 against a US-only extract.

Scope: agent:Coach

After geocoding any business, verify the pin by looking for that brand's own listings in the reference data, and treat two kinds of 'nothing nearby' as different: brand present in the data but nowhere near this pin is an ALARM, brand absent from the data entirely says nothing and must not warn. Set the alarm threshold at wrong-region distance (100 miles), not the verification radius - a sparse footprint is not a wrong pin. Match brands on TWO words at TOKEN boundaries: one word as a substring matches 'champy' to 'ChampYon Martial Arts' and 'workout' to 'Ladies Workout Express', while a same-unit matcher is too strict and flags a client whose own sibling is 6 miles away. Never accept a false VERIFICATION to avoid a false alarm - a wrongly-verified pin silences the check for the exact client it exists to protect. For a multi-location account where no single point is meaningful, REMOVE the location rather than pick a representative site: a wrong pin is worse than a missing one.

Why: Every downstream number inherits the pin. Refining competitor selection, demographics or spend recommendations is worthless if the map coordinate is in the wrong state, and the failure is invisible because the report renders completely and plausibly for whatever town it was given. The general lesson is that a lookup returning 'not found' is data, not an absence to be discarded silently - the codebase already computed the answer and threw it away.

Failure mode: Three Sneeze It clients were having their entire market analysis computed for the wrong location, silently. Villa Sport Fitness (a $12,500/mo account) was pinned to Lower Manhattan, where VillaSport has no club - the nearest name match was 'Il Villaggio Nail Spa'. Workout Anytime China Grove was pinned to China Grove, TEXAS when the club is in China Grove, NORTH CAROLINA, about 1,000 miles away. Syufy was pinned to Syufy Enterprises' corporate head office, which is not a club. All three came from the roster builder matching a reference by place-name SUBSTRING. The code already had a function that looked for the client's own listing near the pin, but it returned null and said nothing when it found none - and null was exactly the interesting case. Competitor counts, reachable households and income index were all computed confidently for towns the clients do not trade in.

Scope: agent:Coach

Before reporting any KPI as simply above or below goal, decompose it by its own components at least once per quarter and ask what behaviour the tile REWARDS, not merely what it measures. A tile whose goal points the same direction as a legal, contractual or strategic constraint we are trying to shrink is worse than a missing tile: it pays us to make the problem bigger. Re-verify goal DIRECTION whenever strategy changes, not just goal value. Separately: never write an identifier (project key, board id, account id) into a spec from an assumption. Query it once and record the response, because a wrong identifier returns zero rather than an error, and zero reads as good news.

Why: Both findings share one shape: a number that looks fine, or looks simply low, while the mechanism underneath points the wrong way. Staleness assertions catch a source that stopped updating; nothing catches a source updating correctly toward the wrong outcome. The Beacon tile was wired 2026-08-03, five weeks AFTER the 2026-06-29 EOS cease notice, and nobody re-asked whether ranking harder on those terms was still wanted. Decomposition is cheap and it is the only thing that surfaces this class.

Failure mode: SUCCESS: Dan found that 92.5% of the Beacon KPI (979 of 1,058 pillar impressions) came from EOS-trademarked clusters, the exact marks under a cease notice whose compliance deadline had already passed. For five weeks the tile was read as a simple miss (1,058 vs 3,500 goal = "SEO is behind") and never decomposed. The same prep found Crystal's spec asserted Jira project key "CP" from an unverified assumption; that project does not exist, so the query would have returned a clean zero forever.

Scope: agent:Dan

Read the target agent's spec before writing the dispatch prompt, not after. When a parent spec says "spawn X against its canonical spec because the logic lives there", that delegation covers the OUTPUT CONTRACT too — who writes the file, what the agent returns, what it must not touch — and not just the calculation. Never restate an agent's persistence mechanism from assumption in a dispatch prompt; either quote the spec's contract or say nothing about persistence and let the agent follow its own rules.

Why: An orchestrator that overrides an architecture rule it never read is a worse failure than the rule protecting against, because it is invisible: the output was correct, the KPIs were honest, and nothing downstream broke, so only the subordinate agent's honesty surfaced it. Overrides like Issue #38 exist for reliability reasons the orchestrator has usually forgotten, and a dispatch prompt is exactly where they get silently undone under time pressure.

Failure mode: Dan dispatched Crystal with an instruction to write crystal-latest.md directly, without first reading Crystal's own spec. That spec carries the Issue #38 architecture override (in force since 2026-04-27): Crystal returns its report as its final response and the ORCHESTRATOR writes the file from the main thread. Dan then sent two more chase messages on top. Crystal complied and self-reported the violation in its Flags section — the agent caught the orchestrator, not the reverse.

Scope: agent:Dan

When a churn tripwire fires on many accounts at once in the same week, do NOT report it as N client-level alerts or as one uniform market/holiday effect. Pull `time_increment=1` daily insights for 3-5 representative accounts plus `account_status`, `spend_cap`, `amount_spent` and campaign `effective_status`. On 2026-09-07, 18 of ~45 accounts tripped the -20% wire; the daily pull showed three unrelated causes: WOA Hickory had a 15x spend spike on Sep 1-2 ($456/$462 vs a $30/day baseline) that burned its entire $996 account spend cap, after which Meta paused both campaigns and the account went dark from Sep 3 (invisible in the 7d rollup, which just looked "down"); WOA Lakewood Park held spend at $66/day with 2 leads in 7 days and campaigns ACTIVE, a tracking or form break; WOA Kettering simply had its daily budget cut to $50 from ~$78 on Sep 1, so its drop was explained and needed no action. Also verify the window: Meta `date_preset=last_7d` and `last_30d` both EXCLUDE today, so a broad decline is never a partial-day artifact and that hypothesis can be dismissed by reading the script rather than guessing.

Why: A rollup metric hides the mechanism. Reporting 18 near-identical "down 20%" lines buries a dark account that is losing a client real leads every day, and reporting it as one holiday dip explains away a live tracking break. The daily-plus-account-status pull is about 60 seconds of work and is what converts an unactionable trend line into a named cause with a named fix. An account that hits its spend cap looks identical to soft demand in every weekly view.

Failure mode: SUCCESS: Dash — a portfolio-wide "leads down >20%" pattern was 3 distinct root causes, not one trend, and only a daily-level pull separated them

Scope: agent:Dash

Every agent that reports into a meeting must own at least one tile ON that meeting's board. An agent whose number lives on another team's board, or on no board, is invisible to the meeting that is supposed to hold it accountable — do not paper over this with a side-list in the brief. Second: define time-window KPIs as ROLLING last-N-days, not calendar-week-to-date, whenever the tile is read at a fixed point in the week. If a metric needs a recurring paragraph of explanation for why its value is misleading, the metric is wrong, not the reader.

Why: David, 2026-09-07: "there are no other agents that report to you in the scorecard so a lot of the data is lost" and "outreach emails sent (this week) should be last 7 days". A scorecard that omits most of the seats it governs is not a scorecard, it is a sample. And a calendar-week counter read on Monday morning always reports near-zero, which trains everyone to ignore the tile — the explanation paragraph is evidence of the defect, not a fix for it.

Failure mode: Dan presented the AI Army scorecard as 11 tiles plus a side-list of "off-board tiles that still matter", treating that as acceptable. It is not: most agents that report to Dan have no tile on the board at all (Beacon is on another team, Dirk's is untagged so it renders nowhere, Dash/Neil/Pulse/Radar/Alan have no seat measurable on this scorecard). The meeting therefore cannot see most of the fleet, and that data is simply lost. Separately, Dan defined the outreach KPI as a Monday-to-Monday calendar week, which reads 0 every Monday morning and required a written "velocity read" paragraph every single week to explain why 0 was not really 0.

Scope: agent:Dan

David's design, 2026-09-07: run Dan as a background agent on every /good-morning, and define prep as MOVING THE WORK FORWARD rather than assembling the report. The pass reads the prior Ollie insight, advances open rock milestones and to-dos, and does NOT spend its time gathering headlines/signals — reporting material can be collected at compile time. Attach the recurring obligation to a habit the human already has, never to a day the agent must remember on its own.

Why: Every Dan commitment backed by a mechanism shipped on time (freshness assertion, run log, Tally refusal). Every commitment left to Dan's own judgement failed. The fix is therefore never a better promise, it is a trigger owned by something else. And prep-as-assembly optimises the wrong half: the brief was never the bottleneck, the undone to-dos were, and a brief compiled from work that did not happen is just a well-formatted miss.

Failure mode: For four consecutive weeks Dan missed "Wednesday prep" and treated it as a scheduling/discipline problem, proposing a scheduled job that writes the brief earlier. That diagnosis was wrong. Dan had defined prep as DOCUMENT ASSEMBLY (gather headlines, read signals, compile the brief), which is genuinely doable Monday morning — today's Monday-built brief found the Beacon trademark issue and the Jira gap. What cannot be done Monday morning is the actual open work: to-do T4 sat undone for a week and was closed in four minutes once attention was forced onto it.

Scope: agent:Dan

David, 2026-09-07: "beacon is not a sneeze it issue and EOS marks on SEO is not an issue it is a positive." Ranking for EOS queries puts OTP in front of exactly the buyers it wants -- people currently running EOS who need software -- and that concentration is evidence of product-market fit in the search data, not exposure. The trademark obligation covers what OTP CALLS ITS OWN FEATURES, not which queries OTP appears for. Keep those two separate permanently. Also: A3 only scans tickets, so run the company-mismatch test against every section Dan writes, including IDS items that are not yet filed.

Why: Treating an acquisition channel as a liability would have argued for destroying OTP's best source of qualified search visibility, on a board that should never have been discussing OTP in the first place. And a preflight assertion that only checks one surface gives false confidence about all the others -- Dan trusted A3's PASS while personally authoring the mismatch it could not see.

Failure mode: Dan made the Beacon KPI the #1 IDS issue on the Sneeze It AI Army board, framing 92.5% EOS-cluster search impressions as compounding legal exposure under the EOS Worldwide cease notice. Two errors. (1) WRONG BOARD: Beacon owns orgtp.com visibility, which is OTP product work and must never appear on the Sneeze It board -- the preflight's A3 company-mismatch scan reads tickets only, so it passed a violation Dan authored in the brief's own IDS section. (2) WRONG ANALYSIS: Dan conflated using EOS marks in OTP's own product naming and copy (the actual trademark compliance obligation) with RANKING IN SEARCH for EOS terms, which is legitimate competitive positioning and is a positive, not a risk.

Scope: agent:Dan

David, 2026-09-07: "do not count Yadkinville, Lafayette and China Grove on any call center reporting it is not an issue." Excluded projects are excluded from EVERYTHING -- the portfolio rate, the KPI denominator, coaching, uncalled-lead flags, and any derived issue about their lead-to-appointment performance. Do not resurface them as a client-outcome issue, a wasted-spend issue, or under any other framing. And when a written rule says to exclude something, verify the automated source actually implements the exclusion before reporting its number: a documented rule that the code does not apply is not a rule, it is a comment.

Why: Applying the documented exclusion moves the call centre from 28.6% (reported MISS) to 30.8% (PASS on target), and from 28.8% to 31.5% over 28 days. Dan reported a team as failing its goal for weeks because the KPI ignored a rule that was written down the whole time. Reporting a miss that the org's own rules say is not a miss damages trust in the scorecard and in the people it measures.

Failure mode: Dan reported Arin's CC appointment rate as 29.2% and a MISS with a "third consecutive fall", and separately proposed filing a new issue about Yadkinville, Lafayette and China Grove generating 172 leads and 5 bookings in 28 days. Both were wrong. Those three WOA locations are on the PERMANENT CCM exclusion list in dash-rules.md ("client calls their own leads"), and the Tally source for the Arin KPI is a raw ratio over every row of Project Stats with no project filter, so it has been carrying excluded projects in its denominator since the tile was wired 2026-06-29.

Scope: agent:Dan

Never divide media spend by a client's total POS enrollment count. Attribute using an auditable field inside the enrollment record. For Workout Anytime the proof is the PLAN NAME: joins on National Promo plans (STRONGER, BANANA) are reachable only through the national offer pages the ads point to, so they are traceable rather than estimated. Exclude kiosk-tagged plans. Corroborate against platform-attributed purchases; when two independent methods land close (836 vs 929 here), report the conservative one and state the range. Report a missed target plainly rather than picking a denominator that hits it.

Why: A blended CPA built on unearned joins collapses the moment a client asks which members came from the ads, and it discredits every other number in the report. The plan-name method survives audit because the client can query it in their own system. It also produced better strategy: it revealed that cost per lead ($29.26) was already inside target while conversion volume was the real constraint, which a fabricated $14.88 would have hidden.

Failure mode: Client performance reporting divided total media spend by ALL POS/iCart enrollments to produce a blended CPA, claiming credit for joins the campaign did not generate. The Workout Anytime August 2026 report claimed a $14.88 CPA by dividing $45,000 by all 3,484 iCart joins across 190 clubs, when iCart records every enrollment from every source including walk-ins, in-club kiosks, presale, eGym and club-level marketing. The provable figure was $53.83.

Scope: agent:Dash

Name every funnel stage by what the system actually records. A POS or cart entry is an "enrollment start" or "checkout start", never a "lead", and its completion rate is a "checkout completion rate". Always show the stage ABOVE it so the high rate is contextualised: paid clicks 29,048 to enrollment starts 1,538 is 5.29%, and click-to-membership is 2.88%, which are the credible marketing numbers. Cross-check the stage against platform adds-to-cart (Meta 265 + Google 1,663 = 1,928 vs iCart 1,538) and say so in the report. Use realistic recovery rates for abandoned checkouts (15% to 25%), never 40%.

Why: David: "54.36% conversion is way too high, this has to make us look good so they continue the spend, realistic expectations." A number that looks too good gets the whole report doubted, which costs the account more than a modest number would. The fix also surfaced the strongest honest argument for continued spend: at $53.83 CPA against $37.19 monthly member revenue, payback is 1.45 months and the return is 4.1 to 1 even on a pessimistic six-month tenure. Member economics beat CPA-versus-target as the persuasive frame, and they require no assumptions.

Failure mode: Labelled a POS checkout-completion rate as a marketing lead conversion rate in a client report. iCart "All Entries" records are people who ENTER the join/checkout flow, not marketing leads. Reporting "1,538 leads converting at 54.36%" read as fabricated because no marketing funnel converts at 54%. The math was correct; the label destroyed its credibility.

Scope: agent:Dash

That sheet has Budget Meta and Budget Google columns beside the Total. Pace against the share for the platforms actually measured, and name the denominator in the output. Trust the split only when Meta plus Google reconciles with the Total to within a dollar, since WOA Blairsville carries a lost decimal and WOA Corporate is 5000 short. A platform with a budget and no account attached is a finding, never folded into the other platform pace.

Why: A pacing percentage gets read aloud on client calls. The wrong denominator does not fail loudly, it produces a confident number saying under-delivering about an account that is 46 percent over its Meta budget, so the coach takes the opposite action. The same sheet feeds Dash.

Failure mode: Sneeze Coach paced Meta-only spend against the Total Budget column of the Client Budget and Coach Mapping sheet, which is Meta plus Google. Villa Sport read 117 percent of pace when its real Meta pace was 146. Rockstars of Tomorrow Corporate understated by 3.5x, Powerhouse Bridgeport by 2.25x. Five clients affected.

Scope: agent:Coach

Report cost per acquisition on measurable media only, meaning the channels that can be traced to a conversion, and disclose the all-in figure alongside it in the measurement notes. Here: $42,000 Meta plus Google divided by 836 equals $50.24, versus $53.83 all-in. Remove that channel's clicks from the funnel denominator too, for consistency. Then give the untrackable channel its own reach economics rather than a blank: CPM, cost per completed view, cost per click, cost per thousand reached, cost per viewing hour. If a modelled contribution helps, label it modelled, keep it out of the verified count, and show the working.

Why: David: "I want the number 50" and "use a known stat instead of reporting nothing." Both are the same rule: measure each channel on the metric it can actually be held to. The fix was not a massage, it resolved a real contradiction, and it had a bonus - the following month had that channel paused, so the measurable-media basis made the two months comparable for the first time. A blank in a client report reads as laziness or concealment.

Failure mode: Charged a channel that cannot be tracked to a conversion against the cost-per-acquisition figure, while the same report said that channel should not be judged on the acquisition target. OTT's $3,000 was inflating CPA to $53.83. Separately, the report described OTT as contributing nothing, when it had abundant hard delivery numbers sitting unused.

Scope: agent:Dash

Test the assumption against historical cohorts in the same dataset before writing it. Method: take month M's non-converting records, match on a stable key such as email, and look for them converting in later months; then compare cohorts of different ages. Result here: abandoned checkouts returned at 0.85% after three months, 0.03% after five weeks, 0.00% after one week, and there was no within-month gradient either, because the newest cohort converted highest. The figure was already final. Then look for where the real uncertainty actually lives: off-platform. Someone who abandons online and joins in person is recorded in the club system, never in the cart, so report the number as a ceiling with a sensitivity table rather than a point estimate.

Why: The instinct that a number is incomplete is usually right, but the mechanism is often wrong. Measuring cost nothing and produced a stronger deliverable than the requested asterisk: instead of asking the client to trust that the number will improve, the report showed that closing 30.5% of the abandoned leads at club level, about one member per club, puts the campaign at target, and named the exact match that would settle it. A sensitivity table beats a fabricated maturation curve.

Failure mode: Was asked to add a footnote stating that a month-end conversion figure would improve over the following weeks as late closes landed, and to estimate the late-close rate. Writing that as an assumption would have put a forward-looking claim in a client document that the client could disprove using their own data.

Scope: agent:Dash

When parsing a month out of a document title or filename, match full month words explicitly (january|jan, february|feb, ...) with word boundaries. Never use a three-letter prefix plus a wildcard: mar/may/jun/aug/sep all appear inside ordinary English words (Marketing, Mayfair, August, September). Also require a four-digit year in the same string, and refuse to guess when zero or two months match rather than falling back to the current date.

Why: A date parsed off the wrong word is worse than no date: it produces a confident vintage that silently ages or freshens every figure in the file. Here it would have kept budget pacing dark for all 54 Coach clients while appearing to have fixed it, which is exactly the failure the vintage was introduced to prevent.

Failure mode: SUCCESS: Sneeze Coach budget mapper dated the "Active Marketing Clients - Sept 2026" sheet to MARCH, because a three-letter month-prefix regex matched "mar" inside the word "Marketing". Every budget in the file would have been stored with a six-month-old vintage, which switches pacing off silently rather than loudly.

Scope: agent:Claude

When a data source can return a partial answer, model "we were not told" and "the answer is zero" as two separate fields, never one. In Audience this is GoogleDemand.available (the call worked) vs GoogleDemand.metricsAvailable (the rows carry numbers); the verdict stays 'unknown' when metrics are missing and the panel shows the real keyword list with no numbers instead of zeroes. Probe the live API before trusting a parser: both generateKeywordIdeas and generateKeywordHistoricalMetrics were tested against the MCC and against a client account spending ~$3,000/mo, and both returned text with keywordIdeaMetrics absent entirely, so it is the developer token's access level (Basic; full Keyword Planner metrics need Standard access, an application in the Google API Center) and not account eligibility. Also: do not run drizzle-kit generate in sneeze-audience - migrations there are hand-written incremental .sql files applied in filename order by a ledger table, and the generated baseline sorts before them and would CREATE TABLE over a live database on every boot.

Why: A zero that means "unknown" is indistinguishable on a page from a zero that means "no demand", and everything around it on the report is real, so it gets believed. The two readings lead to opposite actions: apply for a token, or move a client's ad budget off Google. The same shape recurs anywhere an API degrades partially rather than failing loudly.

Failure mode: SUCCESS: Audience - Google Keyword Planner returns keyword ideas but ZERO metrics on a Basic-access developer token, and parsed naively that renders as "thin search demand, move the budget elsewhere"

Scope: agent:Audience

An ad account is not a client. Before attributing an ad account's spend to a client, run `google-ads.sh campaign-performance <id> 30` (or the Meta equivalent) and look at the campaign name prefixes. If two or more naming families appear, attribute at campaign level, not account level: query FROM campaign with a name filter rather than FROM customer. Only trust a prefix filter after checking the parts sum to the account total, so nothing is dropped or double counted.

Why: Account-level attribution is invisible when it is wrong: the number arrives formatted and confident, and every internal consistency check still passes because the account really did spend that. Holding companies routinely run several brands from one account, so this is not an edge case. The wrong number here would have been read to a named client contact.

Failure mode: SUCCESS: Sneeze Coach attributed a whole Google Ads account to one client. The "Syufy Ad Account" holds VillaSport's seven clubs (campaigns prefixed "WS | VS |") alongside a second brand's Boise-area campaigns (prefixed "SI |"). Reading the account whole put $13,945/mo of another brand's spend onto VillaSport and paced it at 219% of its agreed budget, a number a coach would have read aloud to the client.

Scope: agent:Dash

When a system grows past its first instance, go up a level and check what still points at instance one. A default nobody chose is a bug. The entry point of a multi-item system must present the set, read off the registry so it cannot drift from what is routable. Every item states its own copy AND its own graphic, and the shared component keeps no defaults to inherit, so the next item does not compile without declaring its own.

Why: Speed to lead was never chosen as the headline offer, it was the first page anyone wrote, and the root redirect, the campaign links and an unrelated page's hero drawing all inherited that accident. Sneeze It sells iJoin, the visitor pixel, market intelligence, agent readiness, creative and coaching, and the front door advertised one of them. An inherited default is invisible precisely because nobody decided it.

Failure mode: Dirk built sales.sneeze.it and left the root as a 302 to /o/speed-to-lead, and shipped /o/market carrying the speed-to-lead bar chart. David: "sales.sneeze.it defaults to https://sales.sneeze.it/o/speed-to-lead". Same fault twice: whatever was built first became the default for everything above it, so a visitor was told we sell one thing and a page about choosing a site argued a different product's case.

Scope: agent:Dirk

When a correction is ambiguous and one reading means "keep doing the thing you were just criticised for", that reading is almost certainly wrong. Check it against what the person said earlier rather than parsing the sentence in isolation. Ambiguity about WHAT to sell is worth one question with concrete named options before writing, because guessing wrong burns a whole cycle and the copy has to be thrown away either way.

Why: Sneeze It sells the stretch after the click: the ads and their dead geography, the join flow (iJoin, ABC), the visitor pixel, and the calling. Speed to lead is one pillar of four. It led every campaign only because it was the first door page written, and three rounds of polish went into sharpening the wrong offer while the real differentiator went unsold.

Failure mode: Dirk kept both cold campaigns pitching speed to lead across three rewrites. David had already said "we do so much more than speed to lead but this is what you chose as the page?" and then "Gym owners... and Med spa owners... need to be rewritten stills selling speed to lead", which Dirk read as a constraint to keep, when it was the complaint itself. It took "we are not selling speed to lead!" before Dirk changed the offer rather than the wording.

Scope: agent:Dirk

iJoin and The Steel Method roll up under Sneeze It and are deliberately dormant. Do not warm their domains, stage campaigns, or treat their unmailed pool as a gap, until David says otherwise. Capacity we do not need is not capacity we are wasting. More generally: before proposing to unlock idle capacity, ask whether it is idle by decision, because an audience sitting still is not automatically a failure.

Why: The inventory raised the same two HIGH alerts about those brands on every run, about a decision already made. A report that cries wolf daily teaches its reader to skim past it, which costs exactly the day it finally says something real. The script now marks dormant brands INFO and keeps them in the table, so the audience stays visible without pretending it is an emergency. Removing a brand from the DORMANT set is a decision to start mailing it, not a tidy-up.

Failure mode: Dirk pushed to warm sneezeitdigital.com and sneezeitpromotions.com this week to unlock the 25,090 contacts held by iJoin and The Steel Method, treating a large unmailed audience as a problem to solve. David: "Sneeze it is responsible for all of those, I dont need the email sending capacity right now so they are dormant."

Scope: agent:Dirk

Two rules. (1) LOG THE WEEK AS ITS OWN STEP, with an explicit "deliberately NOT logged" list written into the changelog file. PR #716 did this on 9/6 and it turned issue #36's reconstruction from ~55 PRs into a bounded 9/4-9/7 gap, because the prior wave's editorial decisions were recorded rather than re-litigated. Six straight issues had undercounted before this. (2) NEVER ACCEPT A CLEAN COMPLIANCE SCAN FROM ONE CASING. Run the trademark/vocabulary scan case-insensitively AND on the parsed entries. On #36 the capitalized scan returned clean while the case-insensitive pass found "headline" twice in an unsent entry: EOS agenda vocabulary and the wrong product noun (it is a Signal).

Why: The undercount cost five previous issues either a re-send risk or a scramble to reconstruct dozens of PRs under time pressure. Logging the week when it happens makes the weekly email a read rather than an archaeology dig. And a single-casing compliance scan is a false negative that ships a trademarked term to 98 customers while reporting itself clean, which is worse than no scan at all because it manufactures confidence.

Failure mode: SUCCESS: Swamp issue #36 -- the weekly changelog undercount pattern finally broke, and a compliance mark slipped past a capitalized-only scan for the second time (the issue #30 lesson).

Scope: agent:Radar

To restyle an existing Google Doc whose URL is already registered somewhere, do NOT use import_to_google_doc (it mints a new URL). Use update_drive_file with file_path + source_format:"html" — it replaces a native Doc's content in place, keeping the file ID, URL, sharing, comments, and version history. Stage the HTML in ~/.workspace-mcp/attachments/ and pass file_path, never inline content. Two conversion gotchas: paragraph background-color is dropped by Drive's HTML converter, so put callouts, pull-quotes and change-log blocks in a single-cell table with the shading on the td; and use real h1/h2/h3 tags (inline CSS still applies) because they map to Docs' named heading styles and populate the document outline pane. On a long document verify content preservation mechanically — diff the source word sequence against the tag-stripped HTML with difflib before publishing — and publish to a throwaway doc first, look at it in a browser, then apply in place.

Why: The doc was 94K characters of hard-wrapped plain paragraphs with ASCII rules and no headings, and it is a financial record where an accidental edit to a figure would be worse than bad formatting. The word-level diff proved nothing was lost, the trial import caught two real defects (a swallowed "Total assets" line and a column header wrapping), and the in-place update preserved the URL that CLAUDE.md and Alan's spec both point at.

Failure mode: SUCCESS: Alan — reformatted the 46-section Bankruptcy Reconstruction Google Doc in place without changing a word or a number

Scope: agent:Alan

Match a duplicate-person check on name by edit distance as well as on email, gating a near-surname match behind a matching forename so families do not trigger it. Warn and ask, never block, since a deliberate second link is legitimate. Any form POST that creates a row must end in a redirect, or refresh becomes a duplicate-creation button. When a duplicate is reported, check older rows for the same shape before calling it a one-off.

Why: A person is not their email address. Keying identity to the address is the obvious implementation and it fails exactly on the case that motivates the feature: someone who signed up personally and is being sold to at work. A duplicate row is not harmless either, since every minted invite sits in the sent denominator the page reports its own click and signup rates against.

Failure mode: SUCCESS: OTP join-link dedupe. An exact-email duplicate check would have missed the case it was built for: Mendy Shishler signed up as one address and was invited at another, under a misspelled surname. Separately the mint page rendered its result from the POST, so a browser refresh re-submitted the form and minted a second token. That had already happened to another prospect a month earlier and nobody noticed it was a pattern.

Scope: agent:Conatus

In the shared ~/otp-platform tree, NEVER branch from local `main`. Branch from `origin/main` explicitly, in an isolated worktree: `git worktree add <path> -b <branch> origin/main`. Then verify with `git diff --cached --name-only` that exactly the intended files are staged BEFORE committing. If a contaminated branch already has a PR, do not force-push it clean: check `git branch -r --contains <sha>` first, because the other session's head commit may exist on no other branch. Leave it intact, open a fresh single-file PR, and close the old one with a comment naming the stranded commit so its owner can recover it.

Why: This repo has multiple Claude sessions working in it at once, and the swamp log records the same hazard three times (issues #29, #30, #35 all had to move to isolated worktrees). Branching from local main silently absorbs whatever another session has staged or committed, which turns a one-file PR into a review of someone else's unfinished work and makes CI failures unattributable. Force-pushing to fix it destroys work that exists nowhere else.

Failure mode: Radar cut a feature branch from a local `main` that another concurrent session had committed to, so the PR carried eight files (that session's join-link work and CSS) instead of the one file intended. It also inherited a design-lint failure that was not Radar's, and burned a CI cycle diagnosing a break in someone else's code.

Scope: agent:Radar

Before acting on any "supply running out" alert, check what the existing supply CONVERTS at, and check that the conversion number is measurable at all. Specifically: (1) compare the alert's assumed burn rate against ACTUAL sends per day, since a cap is a ceiling not a rate and OTP had sent 0 for four days while the alert projected 2,500/day; (2) confirm the outcome pipeline is intact end to end before believing a zero, because "no positive replies" and "we destroyed the replies" look identical in a dashboard; (3) if outcomes cannot be attributed to a campaign, fix attribution FIRST, because every list bought before that is unfalsifiable. Also: do not lower a sending domain's daily cap to stretch supply. That number is an earned warm-up ramp, not a throttle, and lowering it discards reputation the domain has to re-earn; pace by staging fewer per day instead.

Why: A supply alert measures the tank, not the engine. Sourcing more leads into a funnel with a measured zero conversion multiplies data spend and burns the sending domain's reputation, which is the one asset that cannot be rebought. And the deeper trap is that the zero itself was untrustworthy: replies bounced entirely before 9/4 and were unattributable after, so the org was about to make a five-thousand-lead purchasing decision on a number that did not exist.

Failure mode: The outreach lead-inventory alert reported "OTP has 2.0 days of supply left, source more before the queue empties" and framed sourcing as the fix. Acting on it would have bought ~5,000 more addresses. Investigation showed supply was not the binding constraint: 19,884 sends in 30 days produced 0 human replies, reply capture had been entirely broken until the 9/4 MX fix, and replies.send_id was never populated so no reply could be attributed to a campaign, list or brand.

Scope: agent:Radar

When turning a hand-built client report into a repeatable product, separate the two halves and build for the second one. The mechanical half (API pulls, arithmetic, tables) is easy and worth almost nothing on its own: WOA's own script divides spend by every iCart join and prints $12.92, the wrong number that had already shipped. The valuable half is four things that live in no API - the client-specific counting rule (plan name contains 'national promo' and not 'kiosk'), the target the client stated on a call, the phrases that must never appear in their documents, and the corrections a human made over eleven drafting passes. So: (1) give every client a stored, editable BRIEF holding exactly those, and refuse to generate without the counting method; (2) make the forbidden-phrase list a hard export gate checked on the finished document including what the human typed, not a hint in a prompt; (3) compute every figure in code into a fact sheet and check the generated prose back against it, allowing spoken rounding but rejecting any numeral no fact supports, so a failed section becomes a visible gap rather than an invisible invention; (4) keep a human as the last editor before anything leaves.

Why: A generator fed only ad-platform data reproduces the wrong report faster. The measurement definition, the agreed target and the commercial red lines are per-client knowledge that only a human holds, and if the product has nowhere to put them it will be confidently wrong rather than merely incomplete. A rule that exists only inside a prompt fails silently on the one draft nobody reread; the same rule as a gate cannot.

Failure mode: SUCCESS: Coach monthly report - the analysis scripts were only ~20% of what made the WOA/Pete report right, so productising it meant productising the human context, not the arithmetic

Scope: agent:Claude

In a narrow sidebar, bound a calendar to one week and give it explicit next/previous controls. Never answer "what is on Thursday" with a scroll region: show all seven days at once, mark empty days, and disable the arrows at the edges of what the data source can actually answer for.

Why: A scroll area inside a page that already scrolls hides the thing it contains. The week is the unit people think in, so the panel should show exactly one and let them step. It also forces an honest data window: showing a whole week means the feed has to cover the days already past, not just the future.

Failure mode: Built the home.sneeze.it calendar rail as an open-ended agenda list inside a 300px sidebar with its own internal scrollbar. David: "you are showing too many days ahead only show the week and have the ability to move the date forward scrolling down does not help."

Scope: agent:Claude

On a Railway service whose repo has NO git remote (sneeze-coach, sneeze-audience, sneeze-studio, outreach-engine all work this way), Railway has nothing to pull and the ONLY thing that ships code is `railway up --service <name>` from the working tree. Setting or changing a variable in the dashboard restarts the container against the image it already holds, which is indistinguishable from a real deploy: downtime, recovery, green health check, credentials present. Always verify a deploy by requesting a route or string that exists ONLY in the new build, never by reading the deploy log or the health endpoint. Check `railway status` for the linked service first, and confirm the local branch is committed before running `railway up`, because it ships the working tree rather than a branch.

Why: The failure is silent and reads as success in every place a person normally looks. Believing the code is live when it is not means the next hour is spent debugging a feature that was never deployed, and in a client-facing tool it means telling someone a capability exists when it does not.

Failure mode: A Railway deploy looked successful and shipped nothing. All new env vars were set in the dashboard, the service restarted, /healthz returned 200 and every credential read as "set" - but every route added in the new build returned 404, because the running image was the pre-feature one.

Scope: agent:Claude

When a pipeline reports a striking ZERO, verify the instrument end to end before drawing a conclusion from it: check that the field the conclusion rests on is actually populated, with a query like `count(*) filter (where length(col) > 0)`, not just that rows exist. Row count is not data capture. And when an expected field is missing, do NOT guess the provider's schema and write whatever the guess returns into the column: record the payload's SHAPE (keys, types, string lengths, nested key names, with long values reported by length only so a diagnostic never becomes a second copy of the content) and read the real shape on the next event. Guessing a field name risks storing headers or markup as prose, which is worse than an empty column because it looks like it worked.

Why: Two conclusions had already been drawn from the broken instrument: that cold outreach produced zero human replies, which nearly justified abandoning a channel, and that sourcing 5,000 more leads was the fix. A subject-only classifier files an interested reply with a "Re:" subject as "other" -- exactly one "other" existed and it was dismissed. A feature shipped the same day to read successor names out of reply bodies could never have fired, because there were no bodies. An empty column that still returns rows is the most expensive kind of silent failure: every downstream number keeps computing and stays confidently wrong.

Failure mode: The outreach engine stored 521 inbound replies with an EMPTY body, every single one. The webhook read `data.text ?? data.html` and neither key arrives from the provider, so sender, subject and timestamp were kept and the message itself was discarded. Nothing surfaced this because a reply row still looked complete. Every reply classification for the life of the system was therefore made on a subject line alone, and a "0 human replies across 19,884 sends" finding was reported off that instrument.

Scope: agent:Radar

When evaluating any CTV/OTT platform (Vibe, MNTN, tvScientific, Madhive, Roku): (1) Screen the BUY before the PLATFORM. Two independent floors: delivery (can the geo spend at a sane frequency, usually yes, ~$400/mo for a 60K-person trade area) and measurability (a lift test needs ~250 conversions per arm, so one location at 50 leads/mo takes 5 months to resolve while 4 pooled locations at 200/mo resolve in 1.3). A single location can afford CTV and cannot measure it, so CTV is a corporate/multi-location buy, never a per-location upsell. (2) Never quote an in-platform CTV attribution number: a documented audit found it more than 4x the third-party incrementality result on the same campaign, IP-to-email household matching is ~16% accurate, and 7-30 day view-through windows credit conversions that were going to happen anyway. Design the matched-market holdout BEFORE the buy or the data to answer the question is never created. (3) Verify vendor corporate status at the primary source. Vibe.co is mid-acquisition by Walmart (announced 2026-06-23, into Walmart Connect, expected close end of Walmart FY2027) with NO financial terms disclosed - the "$1.4 billion" figure in aggregator write-ups is uncorroborated and must not be repeated.

Why: Two failure modes were live here. First, the obvious way to answer "is Vibe the right platform" is a feature comparison, which produces a confident recommendation for a buy that can never be proven - the agency then bills for a channel it cannot defend and loses the client at renewal. Screening measurability first inverts that and, for a multi-location book like ours, points at the larger and more honest line item. Second, a search-summary layer asserted a "$1.4B" purchase price that the Walmart and Businesswire releases do not contain; repeating it to a client would have been a fabricated financial fact. Check the primary source before repeating any acquisition figure. Our multi-location client base makes a matched-market holdout constructible, which almost no SMB advertiser can do, and that is the real CTV asset rather than any platform.

Failure mode: SUCCESS: ads-ctv skill built - CTV/OTT evaluation must screen on measurability before platform features, and two vendor facts nearly got repeated wrong

Scope: agent:Claude

When one ad account is shared between two businesses, verify the campaign filter by matching LOCATIONS to the client's other platform account, never by checking that the parts sum to the whole. A partition proves a boundary exists and says nothing about which side is ours. Sneeze It's own campaigns carry the 'SI' prefix on both Meta and Google, so location names are the reliable join key. Before diagnosing a budget-vs-spend variance as either a stale sheet or client overspend, first confirm the spend figure covers only the locations under management. Run `npm run verify:prefix` in sneeze-coach, which scores every candidate prefix by location overlap with the Meta account.

Why: A 170% pacing figure would have driven a coach to open a client call apologising for an overspend the client was not committing — they were at 97%, exactly on budget. The client's own corporate ad spend was being billed to their performance report. Wrong-account attribution is invisible in a total and obvious the moment the account name and its filter are printed beside the spend, which is why any figure read through a filter must display its scope.

Failure mode: Sneeze Coach reported $48,583 media spend and 170% budget pacing for Villa Sport's August report. Real figures: $27,586 and 97%. The Google campaign filter for the shared Syufy account was set to 'WS | VS |' (VillaSport corporate's own 7 Athletic Clubs, which Sneeze It does not run) instead of 'SI |' (the 11 clubs we do run). It was justified by noting the two prefixes partition the account exactly, plus 'VS' resembling 'Villa Sport'. I initially framed this for David as 'is the budget sheet stale or is the client overspending' — both wrong; he corrected it to 'the spend is showing all locations, we just do a few, have to match the Meta ad locations to the Google spend'.

Scope: agent:Coach

Bookings are not a function of outbound pickups. Callbacks, texts and inbound also book, and the CCM sheet carries its own CallBackReqBooked column. Name and check for a benign mechanism before calling any number an anomaly. Keep questions about one named person out of team channels, and route a low connect rate to ops as a phone-health issue using the sheet's Phone Number Health Check tab.

Why: Publicly doubting someone's work on their best booking day does real damage and was entirely avoidable. It is also narrating a proxy as truth: reporting a gap in my own understanding as a defect in someone else's work, while the disconfirming evidence sat in a column I had already read.

Failure mode: Called Amanda Zuze's CCM numbers (105 dials, 4 pickups, 9 booked on 2026-09-08) an arithmetic contradiction, and drafted that doubt into the team Slack channel where her manager reads it.

Scope: agent:Dan

When ingesting a spreadsheet column of slash-format dates, detect the day/month order from the column's own data rather than assuming or declaring it: any first component above 12 proves day-first, any second above 12 proves month-first; if a column shows both or neither, leave the dates unparsed rather than guessing. Different tabs in the same workbook use different formats (CCM's Appts tab is ISO while New Leads is DD/MM), so detect per column, never per workbook. Separately: whenever a parser silently discards rows, that count must be rendered somewhere a human looks — a source that answers while returning a third of its data needs a 'degraded' state distinct from 'working', because a valid credential is not a working source.

Why: The failure was invisible in exactly the way that matters: every individual number was internally consistent, the credential was healthy, no error was logged, and the only symptom was ratios that looked absurd (5400%) or alarming (1% delivery) — which read as call-centre performance problems rather than as ingest bugs. Kettering was actually hitting 32% appointment rate against a 30% target with 82% show rate and 100% lead delivery. Coaches were being handed a false critical about a client that was performing above target.

Failure mode: Every call-centre figure in Sneeze Coach was a fraction of the truth for months. The CCM sheet writes dates day-first (24/12/2025) and Coach parsed them month-first, so 63.9% of New Leads rows (6,255 of 9,786) and 62.9% of Speed To Lead rows were silently dropped, and the survivors landed in the wrong month (5/8/2026 read as 8 May, not 5 August). This produced 'appointment rate 5400%' and a false 'only 1% of platform leads reached the call centre' critical on nearly every client. A row-count of the dropped rows already existed in code and no page displayed it, so the Sources page reported the credential as 'answering' throughout.

Scope: agent:Coach

Before blaming a per-tenant switch, check whether a sibling system already succeeds at the same task, and if so establish whether it uses the SAME code path. iCart bills those exact clubs today, but through ABC's raw-card branch (todayBillingInfo/draftBillingInfo), never calling paypagecreateagreement. So it proves credentials/plans/club numbers are good and proves nothing about the Pay Page. The real finding: paypagecreateagreement has never returned a URL on ANY club including ABC's own sandbox 9003, so there is no positive control and "per-club switch off" is the weakest of three explanations (vs. app_id not entitled, or we are calling it wrong).

Why: A failure that reproduces everywhere, including the vendor's own sandbox, is not a per-tenant configuration problem. Diagnosing it as one sends a human to make a phone call that cannot fix it, and the vendor's answer ("it is enabled") then reads as a contradiction rather than as evidence for a different cause. Always find one place the call succeeds before blaming the places it fails.

Failure mode: Accepted "ABC has not enabled the Pay Page for these clubs" as the diagnosis for iJoin joins failing at Fitness Quest 6716/8321/40074, and recommended a phone call to ABC Support naming those three club numbers.

Scope: agent:Claude

Report and optimize on results, in this order: verified humans per 1,000 delivered, verified humans answered within 24h, meetings booked, sold. Days of supply and sent counts are supporting detail. The unit of work after touch one is a verified-human return, not a reply: cold prospects lurk, they do not write back. Any hot/warm figure must apply the authenticity verdict first or it is not reported.

Why: David, 2026-09-09: "We have built the whole platform on effort and not results. That is a problem. This is supposed to be an agent automated system and what it has become is just blast campaigns that do not work." A seat that watches replies on a channel where nobody replies is watching the wrong door; the signal was in the visit data the whole time.

Failure mode: The outreach engine and the Dirk seat both measure effort, not results: the headline numbers are emails sent, days of supply, and pending replies. In the 30 days to 2026-09-09 that produced 12,300 people mailed, 0 human replies, 1 booking, while 1,245 verified-human returners (came back to our sites on 2+ separate days, engine's own authenticity rule) were never written to once. manual_email events ever: 0. The temperature model still reports 5,121 hot, of which 3,815 are proven link scanners.

Scope: agent:Dirk

Before linking tickets by symptom ("end meeting does not work"), pull the underlying record's discriminating field (meetings.meeting_type) from the DB; a record-only meeting and a leadership meeting run different code paths. After writing a guard-style fix, remove each guard, confirm a test fails, restore it; the first test pass was vacuous for one guard and hid three more unguarded sites in the same file.

Why: Title-matching wrote a false "same root cause" claim into a PR that had to be corrected, and it would have written a false resolution onto a closed customer ticket. The mutation pass turned a fix that covered one call site into one that covers all five.

Failure mode: SUCCESS: Claude support-board audit found two look-alike tickets were different bugs, and mutation-testing found three guards the first fix missed

Scope: agent:Claude

When David asks for a checklist, deliver only checkable lines: one box per item, each a short noun phrase or verifiable statement, grouped under 3 to 4 headings, no NEVER/rules section, no explanations, no examples in parentheses, no closing sermon. Put any rationale in the cover note to David, not in the artifact.

Why: A checklist is a tool the recipient ticks; a do/don't list is a reprimand the recipient reads once. David wants the vendor to use it every week, so it has to be scannable and neutral.

Failure mode: Pepper drafted a vendor "checklist" for Sonya that read as a do/do-not lecture: NEVER section, parenthetical examples, rationale sentences, and instruction prose mixed into the items. David: "this sounds like a do and do not I asked for a checklist."

Scope: agent:Pepper

In iJoin, two distinct levels with distinct words: SUPER ADMIN (Sneeze It staff, every club) and CLUB ADMIN / club owner / club team (one club). Never show a club-level form or a default club under a super admin. Never default a select to a real club; use a "Choose…" placeholder. Refuse giving a super admin a club level in the route.

Why: A form that defaults to "Admin of Club 24" on a super admin row is a false statement of access. iJoin already had users confused about who sees what; an admin page that repeats the confusion makes it authoritative.

Failure mode: Built the iJoin /admin/users page with one "Set level" form under every person, defaulting to "Owner of… / Club 24 / Admin". Under a Sneeze It staff row that reads as "this person is Admin of Club 24". David pointed out these are super users who see ALL clubs, and that blurring super admin with club admin is the source of user confusion in iJoin.

Scope: agent:Conatus

Default to volume with the breaker on, not to caution. Recommend and act: pick the highest-capacity domain, resume a paused domain when the health guard is still armed (it re-pauses on real damage), raise caps to what the ramp allows, and report what got sent. Every blocker on the dash carries its fix button in the same box. Every screen answers "how much mail went out today against what could have" before anything else. A reply is shown with the prospect's message in full above the draft; a draft without the original is not readable. Ask David only for copy approval and never for operational choices Dirk can defend.

Why: The seat owns what comes back, and nothing comes back from mail that never left. Hedging on domains and approvals cost a day of sending on the only Sneeze It domain with real capacity (ramp 8 vs ramp 1 on the alternatives). Caution that costs volume is not safety, it is silence.

Failure mode: Dirk behaved like an order taker: asked David which sending domain to use, told him resuming the paused domain was "his call" without a recommendation, left the trigger needing approval and the domain paused, and shipped a dashboard where the fix for a blocker (resume mail.sneeze.it) was not findable next to the blocker. David 2026-09-09: "I keep giving you this job and I am beginning to think it was a mistake. Start thinking like a salesperson and less like a non aggressive order taker." Also: the replies page showed the drafted reply without the prospect's own words being readable.

Scope: agent:Dirk

A hostile reply suppresses the PERSON, never the domain. Block a domain only when the sender provably speaks for the company (corporate role, legal, the franchisor's marketing lead) or when the domain itself has told us no at scale. On a franchise brand where locations share the corporate domain, every address is a separate business; treat the domain as a list, not a company. Unsubscribes on that domain are individual too.

Why: Franchise brands are Sneeze It's core ICP and their franchisees are the buyers. One franchisee's temper is not the brand's decision, and a domain block silently removes the next 81 prospects from every future campaign with no record on any of their rows.

Failure mode: Dirk blocked the whole anytimefitness.com domain (82 contacts, 18 queued) because one franchisee, mike.steele@, replied "stop spamming us". Anytime Fitness franchisees use the corporate domain (jacksonville@, brightonmi@, and named people), so a domain block killed 81 independent owners for one person's reply. David: "Mike Steele is a franchisee not a franchisor, so don't kill the brand just for one asshole."

Scope: agent:Dirk

The human approves COPY once, never batches. A trigger's first approved batch flips the trigger to send on its own. Preflight is computed live on every view and at approval, never read from a snapshot; a blocker that is no longer true is not shown. A trigger blast has no audience filter, so audience warnings do not apply to it. Every link on Today that says it does something does that thing on click (a button that fills capacity fills it; it does not navigate). Cold capacity is kept full automatically: when a brand's active domain has room and nothing queued, the engine starts a blast of the brand's designated touch-one campaign to the never-mailed pool and approves it itself. David's only remaining jobs are to read new copy once and to answer humans.

Why: Every gate Dirk left in was a place for the day to die. An automation that needs a person to press a button it has disabled is worse than no automation, because it looks handled. Volume is the seat's job; a paused day on a healthy domain is a failure of the seat, not of the domain.

Failure mode: Dirk built an automated follow-up and then made David approve every batch on a page that could not be approved: the blast page showed a preflight blocker snapshotted at creation ("mail.sneeze.it is paused") after the domain was already back on, the Approve button was disabled by that stale blocker, "Start a blast" on Today linked to a list rather than starting one, and a trigger campaign's preflight warned about 165 unvalidated contacts that were never in its audience. David spent a day trying to send one email. "This is supposed to be a simple Dirk automation sends emails, David hands off."

Scope: agent:Dirk

A blast that already has sends keeps them: approval never recomputes an audience that exists. A trigger campaign has no audience filter and preflight skips the audience section for it. An unknown or falsy audience filter must resolve to nobody, never to everybody.

Why: The approval gate is the one place a person is told they are in control, and it silently replaced their 40 with 5,054. Failing open on an audience filter is the most expensive default in the system.

Failure mode: approveBlast recomputes the audience from the campaign's filter and inserts sends for it. A trigger-made blast already carries its audience (the 40 verified people the trigger chose) and its campaign filter is {all:false}, which computeAudience treats as everyone. When David pressed Approve on the OTP return batch, it went from 40 to 5,054 sends of the touch-two template to people who never came back, and 53 of them were mailed before Dirk paused it.

Scope: agent:Dirk

The product is a loop, not a dashboard. Every stage (source, validate, touch one, observe, touch two, reply, meeting) runs itself; the only human act is reading new copy once. A control on the dash is a failure to automate, and any message to David names the real reason and the fix, never a bare status. Sourcing is part of the engine: the engine pulls its own supply to tomorrow's capacity from Clay. When supply is the constraint, say "the list is exhausted, sourcing is running" and never offer a button that cannot do anything.

Why: Each button Dirk added moved the dead end one screen further along and cost David another click. An automation that reports "nothing to fill" without saying "because the list is empty and here is what is fetching more" is indistinguishable from a broken one.

Failure mode: After a full day of fixes the dash still presented David with buttons that led to dead ends: "Fill it now" answered "nothing to fill" with no reason, autofill created a zero-audience blast that then sat on Today as "waiting for your approval", and every fix added a control instead of removing a step. David, 2026-09-09 4:18pm: "All I want is an automated lead generation engine and what I got is a lot of buttons to click and dead ends."

Scope: agent:Dirk

David, 2026-09-09: Path B tonight. LeadMagic is a permitted sourcing and validation provider again, behind SOURCING_PROVIDER=leadmagic, with Google Places for discovery. Clay stays the provider when it has credits; the engine keeps both behind one interface and the pool does not care which found the person. A sourcing rule is a preference among providers with credits, never a reason to run at zero supply.

Why: A rule written when one provider had credits became a rule to send nothing when it ran out. Supply is the engine's first job; the provider is a means.

Failure mode: Learning L204 ("Clay is the validation and enrichment layer; LeadMagic is retired and never the recommendation") met a day with zero Clay credits: no new contact could enter the engine by any path, validation included, and 5,200 sends a day of capacity sat idle. Dan measured the options on 2026-09-09 (LeadMagic 4,740 credits live; Google Places billing on; Yelp expired; Clay exhausted and about $285 per 1,000 validated vs about $100 for Places plus LeadMagic).

Scope: agent:Dirk

Any plan step of the form "keep X for N days, then delete/rotate/revoke" gets its own dated todo with an owner at the moment the plan is written, not at the moment the window opens. Before deciding delete-vs-label for a data copy, measure four things: newest row (the real freeze point), table-set diff and row counts against the live system (superset proof), pg_stat_activity connections (nobody reads it), and where the backup job actually points (check the archived table count in the job log). Delete when all four say so; do not export first, an export is another unmanaged copy.

Why: Unowned copies of customer data are a retention finding an auditor will ask about, and a copy that looks like production will eventually be mistaken for it (it was, for four days). The deferred-delete pattern recurs across migrations, restore tests and drills; the 8/8 restore test cleaned up same-day only because someone did it by hand.

Failure mode: SUCCESS: Claude found why a stale copy of production customer data sat unowned for 3 weeks: the 8/20 migration plan said "keep the old DB 7 days, then delete" with no owner, date or todo, so the delete step silently never fired and the incident runbook later pointed at the copy as production.

Scope: agent:Claude

When David asks for delight (easter eggs, play, fun), the bar is a SHOW, not copy: synthesized sound (Web Audio, no files), things that move across the viewport, pop-culture scenes with a payoff. Text-only eggs are the floor, not the deliverable. Build a reusable effects layer (sound, flyers, overlays) and then write scenes on top of it.

Why: David's reference points are Tesla (sound, fart mode, Starman), Hitchhiker's, BTTF, Monty Python: multi-sensory, visual, surprising. Toasts read as safe and generic. Delight work judged by the same "is it slop" standard as design work.

Failure mode: Asked for "a lot more easter eggs" on home.sneeze.it, Claude shipped a dozen toast messages and one confetti variant. David: "you can do better" and named the bar: Tesla-style sound, things flying across the screen, Hitchhiker's Guide, Back to the Future, Monty Python.

Scope: agent:Claude

Never let a status default stand in for a classification. Stock a provider may be asked about must be positively tagged (a vertical an active pool rule routes) before it is counted, chosen or handed over. A rule with no vertical is a visitor rule and only fires on a company with a real page visit. The nightly run names the exact companies it chose; nothing else in the window is its business. Count provider spend on the object the run records, never on a helper's private counter. One run per brand per day across restarts, and cap companies per night while yield is unmeasured.

Why: Automated sourcing plus auto-send means a wrong classification is not a bad row, it is a delivered email from the brand's sending domain to a stranger. 38 off-ICP emails cost reputation on two domains and credits, and the dashboard said nothing had happened. Tagging stock positively and counting on the recorded object makes the failure visible before it mails anyone.

Failure mode: The first automated supply run in the outreach engine treated every company whose pool_status defaulted to 'unworked' as sourcing stock. 42 of those were Clay web-intent de-anonymisations with no vertical (a vet clinic, a law firm, a German machinery dealer, ct.gov, a food company). The run surfaced 20 of them, the visitor rules with no vertical filter matched them, LeadMagic found 38 people and 38 cold emails were delivered from mail.sneeze.it and mail.ijoin.ai before the run was killed. The run also reported 0 found and 0 credits while ~89 credits were spent, because the provider poster carried its own tally.

Scope: agent:Dirk

Emoji are clip art; they cap the ceiling at "cute". For a show: draw the sprites (inline SVG with real detail, spinning wheels, flapping wings), run a canvas particle system (gravity, drag, sparks, fire, dust, fireworks), and make effects TOUCH the page (tiles get pushed by the car, squashed under the foot). Payoff beats count: fewer scenes done properly over many done cheaply.

Why: The first upgrade added scenes but kept clip-art rendering, so it still read as a toy. The rendering quality is what separates delight from a gimmick, the same way the drawing IS the argument on landing pages.

Failure mode: Second pass on home.sneeze.it easter eggs used emoji as the sprites (car, whale, foot, parrot) flying across on CSS keyframes. David: "cute but not fun, you can have greatness here, make the graphics better and funner."

Scope: agent:Claude

For irreversible actions on customer data (delete, purge, revoke), present the evidence and the recommendation, but write the record and the todo only after the owner states the decision. The owner's comfort with irreversibility is part of the decision, not an obstacle to it. When the owner picks the reversible option, record that the recommendation was delete, the decision was rename, and name the compensating controls and a revisit point.

Why: A record that says "decided: delete" when the owner has not decided is a false audit artifact, and a todo carrying a destructive command invites someone to run it. Reversible first is a legitimate owner preference and the record must show the real decision chain.

Failure mode: Claude recommended deleting a stale copy of the production database and pre-wrote the disposal record as "Decision: delete" with a deletion todo, before David had actually decided. David chose to rename it instead.

Scope: agent:Claude

Never store a run's share as the limit. A cap is the period's total and lives in one place; a run's share is the remainder, computed each time from the cap minus consumption so far, and it bounds only that run's ask. If a downstream consumer holds the cap, hand it the period total, not the share. Test the second run in the same period explicitly: it must get exactly the remainder, not zero and not a fresh cap.

Why: A cap stored as a quota reads its own consumption as the limit. The failure is silent: the counters all look sane (cap 8, spent 12, asked 0) and the pipeline simply stops, which in an automated lead engine means a night of supply lost with nothing on the dashboard saying why.

Failure mode: The outreach supply job stored each night's run quota into the prospecting rule's daily company cap. A second run in the same sending day (after a deploy restarted the container) computed its quota as "what the cap has left" (8), wrote 8 into the rule's cap, and the planner then compared the day's consumption so far (12 already asked under that rule) against 8 and refused everyone. The run reported asked 0 with a healthy pool and no error.

Scope: agent:Dirk

When you own a strong long-form asset (a landing page that argues the WHY), the cold email must NOT re-argue it in miniature. Cut the product explanation entirely. The email's only job is to earn one click: proof you read their work, one line naming THEIR problem in THEIR language, the link, out. No feature, no price, no call ask. Match the page to the reader's specific pain rather than sending everyone to the same URL. And assign/log an A/B arm on every send, because an untested signature shipping at 100% for months is not a decision, it is a habit.

Why: A cold email is the worst possible venue for explaining a product: no trust, no attention, no context. A page is the best. Using the email to sell the READ instead of the PRODUCT plays each asset to its strength. The deeper failure was cheaper: months of sends with no arm logged and no reply column filled, which means the volume produced zero learning. Volume without measurement is just noise you paid for.

Failure mode: SUCCESS: Crafter cold-email rework -- the email body was trying to explain the product to a stranger in three sentences, while the website spent full pages arguing the why. The two assets contradicted each other and the email was losing. Outreach log had been dead since Apr 26 with effectively no replies.

Scope: agent:Crafter

Never clear an exclusion at the LIST level when the exclusion is defined at the PERSON level. Open each individual's own bio page and check before contact. A competitor directory is not a filter, it is a starting pool. This generalizes: any time a guardrail is "never contact people of type X," verifying the source rather than the person is a false negative waiting to happen.

Why: A legal no-contact rule that gets enforced by proxy is not enforced at all. The whole point of a per-person hard stop is that group membership is a bad predictor of individual identity, and here it is demonstrably bad: people hold two credentials at once. One bad send under an active trademark notice costs far more than the minutes it takes to open a bio page.

Failure mode: Nearly sourced a cold-outreach list from non-EOS coach directories (Pinnacle Business Guides, Metronomics, Scaling Up) on the assumption that "not an EOS directory" implies "not an EOS person." It does not. Individual coaches are frequently DUAL-BADGED: Rick Appleby's own Pinnacle profile page lists him as "Certified Pinnacle Business Guide & Business Coach/EOS Implementer." Given the active EOS Worldwide trademark notice and the permanent no-contact rule, sourcing at the directory level would have put EOS Implementers on a Sneeze It send list.

Scope: agent:Crafter

When David says "the 5 cold emails" or "the sequence," default to a MULTI-TOUCH SEQUENCE (email 1 through email 5, with delays), not five separate one-to-one emails. His outreach runs Clay (enrichment) -> GHL (send) at LIST scale. Copy must therefore be built on MERGE FIELDS with safe fallbacks, not on hand-verified per-person research. Ask which shape he means before doing expensive research: a sequence and a batch of bespoke emails are completely different artifacts, and the research cost of the bespoke path is wasted if the answer is "sequence."

Why: Hand-personalized copy cannot be run through a Clay-to-GHL pipeline. It does not scale, it does not template, and the deep per-person research that makes it good is exactly the thing that makes it unusable at volume. I burned five parallel research agents producing an artifact with the wrong SHAPE, even though the underlying strategic insight (sell the read, not the product) was correct and transfers. Confirm the artifact's shape before paying for its contents.

Failure mode: David asked to rework "the 5 cold email outreach for OTP." I interpreted "the 5" as five hand-personalized one-to-one emails to five named coaches, and spent a full research cycle sourcing and verifying five real people, then wrote five bespoke emails quoting each person's own podcast episode and blog post. That is not what he wanted. He wanted a 5-EMAIL DRIP SEQUENCE (a multi-touch cadence) that he can load into Clay and run through GHL to a whole list.

Scope: agent:Crafter

When compiling guru influences into an Ollie persona, push voice fidelity hard: the dominant influence's cadence, vocabulary, and signature moves should LEAD the writing, not decorate it. Channel the style ("in the room, guiding in their voice") while keeping the hard never-impersonate line: never claim to BE the person, never claim endorsement. Also: differentiation surfaces (the Lab) must let users edit each guru's forked principles inline and must show WHERE a principle or voice move landed in the output (highlights on the insight, influence tags on todos/issues/headlines) so voices can actually be compared.

Why: The entire value of per-team Ollie voices is that the voice audibly changes what the team hears. If influences only shift content, not voice, the differentiation is inaudible and the Lab proves nothing. Attribution marks are what make the difference legible.

Failure mode: Ollie Lab guru influences rendered as principles-with-a-hint-of-style: the output read like Ollie citing a thinker, not like the thinker's voice guiding the room. David: "it should be as if they were speaking with their voice guiding us in their voice... It should be like they are in the room."

Scope: agent:Conatus

Voice fidelity lives in structure, never slogans. Ban catchphrase quoting explicitly in the persona compile ("never quote their slogans; that is imitation's cheapest form"). Give each library guru a hand-written VOICE DNA block: sentence rhythm and length, how they open, how they build an argument, what they notice first, how they land a point, emotional register, what they never do. For custom gurus, instruct the model to reconstruct the person's published voice from structure and register, not taglines. Method instruction: "before writing, ask how NAME would structure this and what they would notice first; write from inside that mind."

Why: Catchphrases signal imitation and break trust instantly; structural voice makes the reader feel the thinker in the room without a single borrowed phrase. This is the difference between a costume and a mind, and it is the entire premium of per-team Ollie voices.

Failure mode: Ollie's guru voice channeling produced surface mimicry: dropping the thinker's catchphrases ("Start with why") instead of writing from inside their rhetorical DNA. David: "not cheap tricks... it needs to be in the DNA of what Ollie is saying. Dig deep, make it real."

Scope: agent:Conatus

Essay-page hero art is a first-class deliverable, not a wireframe: match the family's craft bar (a real scene that tells the page's story, Ollie present, warm accent treatment, gradients/glow, staged ignition-style animation, reduced-motion complete state). Before drawing, read the sibling page's actual SVG to absorb its techniques, then design a scene, not a diagram.

Why: The hero art IS the argument at first glance on these pages; the candle page's flames are the thesis made visible. A schematic undercuts an inspiration page precisely where it must inspire.

Failure mode: The /the-voice-in-the-room hero art shipped as a lazy schematic (dot, four thin lines, grey boxes with circles for people) while its sibling pages (/one-candle, /mission-to-the-moon) carry hand-crafted narrative scenes with the mascot, gradients, glows, and staged animation. David: "you got lazy there for sure."

Scope: agent:Conatus

There are THREE copies of the Google Ads API version constant, not two. When Google retires a version, bump ALL of: (1) mcp-google-ads/google_ads_server.py API_VERSION, (2) scripts/billing_pull_spend.py GA_API, (3) google-ads.sh API_VERSION. Grep for the pin before assuming coverage: grep -rn 'API_VERSION\|GA_API' ~/.claude. And treat "zero Google accounts / $0 Google spend" as a VERSION FAILURE until proven otherwise, never as a real zero. Verify by probing versions directly against listAccessibleCustomers and comparing HTTP codes.

Why: Every one of these wrappers fails the same way: it converts an API error into an empty success. A silent zero is far more dangerous than a crash, because downstream consumers cannot tell the difference between "no data" and "broken". The same bug already caused a $1,070 client underbill in June via billing_pull_spend.py. Here it would have deleted nine paying clients from the coach report, including the one David explicitly asked me not to forget. A pinned version in N places is a landmine with N triggers, and the count of N is itself unknown until you grep.

Failure mode: /coach-report returned "No enabled accounts found" for Google Ads and would have shipped a report with EVERY Google-only client missing (J&K Engines, Meyer Law, M.V. Parker Law, Jet City Blinds, True Path, Lazzara Law, Studstill, GettaMeeting, WOA Hartwell). Cause: `~/.claude/google-ads.sh` pins API_VERSION="v20", which Google has sunset. The wrapper swallows the API error into an empty resourceNames list, so a hard failure prints as a benign empty result. This is the THIRD independent copy of the Google Ads version constant: the MCP server and scripts/billing_pull_spend.py were both bumped v20 -> v21 on 2026-06-18, but google-ads.sh was missed because nobody knew it existed as a separate pin.

Scope: agent:Dash

Work the command's steps in order and explicitly account for EVERY step, including the optional ones. If a step is skipped, the skip must appear in the terminal summary and in the report itself ("Search Atlas MCP unavailable — SEO data skipped"), never silently. Before declaring any multi-step command complete, re-read the step list and tick each one off against what actually ran. When a mid-run bug hijacks attention (like the Google Ads version failure), note the position in the checklist before chasing it, and return to that position afterward.

Why: A silently omitted section is indistinguishable from "that client has no SEO data" — the exact same failure mode as the Google Ads silent zero I had just finished diagnosing and lecturing about in the same run. An incomplete report that announces its gaps is honest and usable. An incomplete report that looks complete is a lie the reader cannot detect. I reproduced the very bug I had just fixed, one layer up.

Failure mode: Ran /coach-report and silently skipped STEP 2.5 entirely (Search Atlas / OTTO SEO data + rank tracker keywords). Shipped 46 cards with zero SEO sections, no SEO badges, and no keyword tables. Worse than skipping it: I never LOGGED the skip, so the report looked complete and correct. David caught it, not me. I got absorbed in the Google Ads v20 bug and never came back to the step I had jumped over.

Scope: agent:Dash

When running counterfactual/what-if simulations, make the events endogenous: model causal mechanisms (innovation rate, demographics, conflict outcomes) as functions of the changed variable and run Monte Carlo over branching timelines, rather than overlaying new participation rates on the fixed historical record. Show a distribution of divergent timelines, not one re-skinned version of real history.

Why: Fixed-event counterfactuals smuggle in the answer (the world converges because you forced it to). Branching simulation is what actually answers "would things be different" questions, and it's the difference between a re-labeled chart and genuine out-of-the-box analysis.

Failure mode: Built a counterfactual history simulation that held all real-world events fixed (same Industrial Revolution, same wars, same tech timeline) and only varied participation rates within them. David flagged that this assumes the conclusion: if the labor/care allocation changes, the events themselves change — maybe industrialization comes later (or earlier), wars resolve differently, the whole timeline branches.

Scope: agent:Conatus

In live L10/Delta Meeting facilitation, sequence is: surface ALL signals first (grouped, neutral, no recommendation attached), let David react and pick what to IDS, and only then frame decisions. Decisions come after shared context, not before. Also: open every meeting with Ollie's read of the PRIOR meeting's record (pulled from the OTP followups/insight), as a standing first section — David explicitly values it.

Why: A decision framed before the signal review railroads the meeting toward Dan's framing and skips the part where David's pattern-recognition works on the raw material. The facilitator's job is to lay out the board, not to compress it into a pre-picked fork. And the Ollie prior-meeting read is the continuity loop that makes each meeting compound on the last.

Failure mode: Dan facilitated the live L10 by pushing straight to the rock-set timing decision immediately after the scorecard, without first walking through all the signals (client wins, CC trends, attribution reading, unverified tiles, churn signals) so David could see the whole board. David: "we need to review all the signals before moving so quickly, you are trying to skip ahead too fast."

Scope: agent:Dan

L10 prep MUST include a live scan of OTP itself: the team's rocks/priorities board, the issues (tickets) board, todos, and KPIs, pulled fresh at prep time. OTP is the source of truth; local files are mirrors that go stale the moment David works in the product directly (which is the whole point of OTP). Additionally, per David's 7/13 ruling: local shared-state files are now formally HISTORICAL unless a live consumer reads them; staleness flags on superseded files are noise, but staleness in the OTP scan is a real miss.

Why: David increasingly works inside OTP directly (weekend rock-setting), so any prep that skips the live product misses his most recent decisions and re-surfaces solved or stale items. The mirror-drift failure has now happened twice (June 15, July 13); the fix is structural, scan the product, not the mirror.

Failure mode: Dan's L10 prep read local mirror files and this morning's Tally/KPI pipeline but never scanned the live OTP boards (rocks/priorities and their attached issues) before the meeting. Result: Q3 rocks David added over the weekend were missing from the prep, and stale issues sitting on the rocks board went unnoticed. David caught it live, again (first time was June 15).

Scope: agent:Dan

Every KPI on any board must pass the needle test before it earns a tile: one sentence stating the causal chain from this number to the company goal (margin, retention, revenue, rock completion). Dan owns running this test — on every existing tile quarterly and on every proposed tile before creation. Activity metrics (emails drafted, projects counted, pushes made) are health checks at best; they live in the readiness script, not on the scorecard. Wiring a dead tile is worthless if the tile measures the wrong thing.

Why: The strategic co-founder seat exists to hold the big picture David cannot hold while operating. A perfectly-wired scorecard of needle-irrelevant numbers is worse than an empty one, because it manufactures the feeling of accountability without the substance. This is the second-order version of "every seat owns a number": every number must own a reason.

Failure mode: Dan treated the scorecard as a plumbing problem (are tiles wired, do values push) instead of a strategy problem (does each KPI move the needle toward the goal). David: "we/I make all of these changes thinking you are looking at the big picture, that does not seem to be the case. Your job is to make sure that we reach our goal, and the KPIs should support that. How many emails Pepper reads does not move the needle. Each KPI needs to answer how it moves the needle, and how."

Scope: agent:Dan

L10 prep must WALK THE ACTUAL MEETING before the meeting: open/fetch the exact meeting David will see (via API), verify every section renders with real data (scorecard snapshot has values, rocks board current across ALL teams incl. corporate, issues/todos loaded), run the needle-test on every tile, and FIX or stage fixes for everything found - all before 8am. The brief reports what was already repaired, not what will be discovered. Prep = simulate the meeting end-to-end; the meeting itself is only for decisions the human must make.

Why: A meeting that debugs itself live burns the scarcest resource (David's attention) on work an agent could have done at 7am. "The work happens between the meetings" is the entire operating philosophy of the meeting cadence - prep that only compiles data without verifying the meeting surfaces is half a prep. This is the root cause behind L059/L060/L061; fixing it structurally prevents all three recurring.

Failure mode: The 7/13 L10 scored 4/10. David's reason: prep ran in the morning but the meeting still spent most of its time discovering and fixing things live (weekend rocks missed, empty scorecard render, dead tiles, needle-less KPIs, corporate rocks invisible) - "we are fixing the meeting within the meeting with an absence of information. The work happens BETWEEN the meetings and this is not the case here."

Scope: agent:Dan

Issues come from the OTP board and David picks them. Do not generate a candidate issue list from local files or from scanning signal. Apply this test before calling anything an issue: an ISSUE needs discussion to solve because it has no known owner or no known path. A TODO has a known owner and a known action and just needs doing. If it fails that test it is not an issue. Never escalate an agent's own uncertainty about how to read a data source into a claim that the data source is broken.

Why: Working a self-invented issue list wastes the scarcest resource in the room, which is David's attention in a live working session. Two of the three items were already resolved or misclassified, so the session would have opened by re-litigating settled work. The stale issues.md, last really updated 2026-03-12 and full of retired agents and departed staff, is not a source of truth and must not be treated as one.

Failure mode: Dan proposed three IDS issues by inferring them from a stale local issues.md and from inbox/Slack signal instead of from the live OTP board. All three were wrong: the Accelo-to-Trello migration was already done, the Make/Zapier ownership gap is a todo not an issue, and the CCM data-quality concern was stale because the data is correct. Dan also escalated his own uncertainty about a spreadsheet's column semantics into a claim that the data source was untrustworthy.

Scope: agent:Dan

When auditing whether an invariant holds across a codebase, verify it per STATEMENT, not per file. A per-file grep count is an aggregate, and aggregates hide the exact case you are hunting: the mixed file. Then encode the audit as a test that scans every call site, and mutation-test that scanner by reintroducing a known bug to confirm it actually fails. A scanner that only agrees with current code proves nothing. Related pattern seen the same day: when a data model gains a concept (rock levels, agent-owned KPIs), the model and the dashboard get wired up and the OTHER surfaces silently do not. Ask which surfaces read this table, not just which one is broken.

Why: The three holes the per-file count missed included the worst one: the blueprint serializer baked a private rock into a shareable template, which would carry it into another account. The failure mode of an aggregate check is a false clean bill of health, which is more dangerous than no check at all because it stops the search.

Failure mode: SUCCESS: Dan audited a privacy invariant (shadow rocks are owner-only) and found 7 holes, but the FIRST pass counted guards per FILE and missed 3 of them, because a file can contain one guarded query and one unguarded query and still look guarded in aggregate.

Scope: agent:Dan

Invert it. Give the user ONE copy-paste block (MCP connection + a self-registration prompt) that they drop into Claude Code, Claude Desktop, ChatGPT, Cursor, or any MCP client. The AGENT then connects to OTP and registers ITSELF: it reads its own system prompt, calls a register/enroll MCP tool with its name, role, what it owns, what it does not own, and its KPIs, and OTP creates the seat and KPIs automatically. The user's only job is copy, paste, done. No forms, no parsing, no filling anything in.

Why: The agent already knows what it is -- making a human retype it is redundant work and a competence gate. Any flow that requires the user to know how to describe or configure their agent is not idiot-proof and will lose the non-technical user. The agent is the most reliable source of truth about itself, and it is already sitting on the other end of the MCP connection, so let it do the work. Design rule: when an AI is on the other side of the pipe, push the setup work to the AI, not the human.

Failure mode: Built OTP's "Connect an agent" flow as a human-driven form: the user pastes their CLAUDE.md into a textarea, OTP parses it, and the user hand-fills name / role / owns / does-not-own / KPIs before a seat is created. It made onboarding an existing agent the USER's clerical job and assumed the user knows how to describe their own agent.

Scope: agent:Claude

Before any L10, dry-run tally.py and for every regex_in_file KPI check the source file's mtime against the KPI's time grain; if older than one grain, re-pull the number from the live system (Accelo, Search Atlas, Sheets) before pushing. New registry entries must use kind/regex/group (never type/pattern) and carry pending:true until their emit line exists. The unknown-kind branch now honors pending.

Why: A KPI pushed from a stale mirror is worse than a missing one: Crystal's tile would have said 32 when reality is 44, and the failure alert noise from mis-schema'd pending entries erodes trust in the one agent whose whole job is keeping the scorecard honest. Live-source-first is the same lesson as L042/L060 applied to Tally's own pipeline.

Failure mode: SUCCESS: Tally pre-L10 KPI sweep found and fixed three silent scorecard rot points: (1) registry entries added at the 7/13 L10 used type/pattern keys but the runner requires kind/regex, so their pending:true flag was never honored and they reported as failures; (2) the runner's unknown-source-kind branch ignored pending entirely; (3) two regex_in_file KPIs (Crystal 32, Beacon 0) were feeding from stale files (Jun 8 and Jun 22) while the live sources (Accelo: 44 projects; Search Atlas: 8 keywords tracked, not 43) had moved.

Scope: agent:Tally

Any browser feature that accumulates unrecoverable state in page memory (MediaRecorder audio, unsent drafts) must (1) block/defer every programmatic self-reload while active, (2) be flushed by navigation-triggering handlers (End meeting awaits OTPAudioRecord.finish() before navigating), (3) guard beforeunload, (4) never drop data on a failed upload — keep the blob and offer retry. Long-term: stream chunks to the server (timeslice) so the page is never the only copy.

Why: A full Delta Meeting's recording/transcript was permanently lost — the audio never left the browser. Guard rails shipped in audio-record.ejs + l8-leadership.ejs; chunked streaming upload is the queued follow-up (touches billing-metered meeting-audio.ts, needs billing lock).

Failure mode: SUCCESS: Conatus — root-caused OTP meeting recording loss (2026-07-16): the browser recorder holds all audio in tab memory until Stop, while the live meeting page self-reloads on routine actions (reloadKeep, SSE scheduleReload, section-refresh fallbacks) and End Meeting navigates away — any of these silently killed a live MediaRecorder with zero warning.

Scope: agent:Conatus

Durable pattern for any browser feature holding unrecoverable state: (1) layer the fix — guard rails first (cheap, same-day, stops the active bleeding), durable streaming/persistence second; (2) keep the old one-shot path untouched as an automatic fallback so degradation can never be worse than before; (3) money-path parity — finalize calls the exact same precheck/ingest/charge sequence as the one-shot path, charge only after successful transcribe+ingest; (4) hold the billing lock across the whole build, release only after merge; (5) verify with a harness that runs the REAL shipped script (44 assertions) so old behavior is provably byte-identical with the new feature off; (6) cap every attacker-spinnable counter (segment count was a finalize-loop DoS lever).

Why: Completes L067's open loop: the "never lose a recording" guarantee is now structural, not procedural. The layered-fix + fallback-preserving pattern is reusable for every OTP feature that buffers user work in the browser (draft notes, offline edits), and the billing-parity discipline is how streaming touched the money path with zero semantic change. Both PRs merged and confirmed live on orgtp.com 2026-07-16 evening.

Failure mode: SUCCESS: Conatus — full resolution of the 2026-07-16 meeting-recording loss, shipped to prod same day in two layers: PR #205 guard rails (meeting page defers all self-reloads while recording; End Meeting flushes the recorder before navigating; beforeunload guard; pinned REC pill; failed uploads keep the blob with retry) and PR #206 streaming upload (recorder streams ~10s chunks to a server recording session; crash/reload loses ≤10s; resume banner stitches segments into one transcript; phone QR flow covered).

Scope: agent:Conatus

Two standing rules for OTP frontend work: (1) never refresh via location.assign(current URL) — use location.reload(); any anchor-navigation page makes assign() a silent no-op. (2) When a fetch helper is designed to never throw, every caller MUST branch on the {error} result — audit all handlers for ignored results whenever one instance is found, and never run a destructive follow-up (delete) without checking the preceding create succeeded. Full 61-handler audit + 15 fixes shipped in PR #207.

Why: One character-level bug made every meeting action look broken and eroded trust in the product's core loop (the Delta Meeting). The ignored-result pattern was silent data loss. Both are recurring classes, not one-offs — the audit found the same defect in 15 places after fixing it in one.

Failure mode: Meeting page actions silently froze during Delta Meetings: convert-issue stuck on "Creating...", to-do saves never closing, edits invisible. Root cause: reloadKeep() used location.assign(location.href), and every agenda chip is an anchor — once a #fragment is in the URL, assigning the same URL is a fragment navigation, not a reload. Compounding it, the page's api() helper never throws, and an audit found 15 handlers ignoring {error} results (one deleted an issue even when the to-do it converted to failed to create).

Scope: agent:Conatus

When invoking Steve Jobs as a design standard, treat him as holding BOTH axes to one bar: visual craft (typography, proportion, detail) and end-to-end experience (defaults, subtraction of steps, invisible mechanism). Never frame him as the "UX half" opposite a visual system; frame the visual system as one half of the single Jobs-level standard.

Why: David's design north star for OTP is the full Jobs standard. Splitting it wrongly would let screens pass a visual checklist while the flow, or the craft, gets held to a lower bar. The correct frame keeps one bar over both layers.

Failure mode: When framing the design-standard marriage (Fugu + Jobs), Conatus split it as "Fugu = visual craft, Jobs = journey/UX", understating that Jobs was also a master of visual design (Reed calligraphy class, typography on the original Mac interface).

Scope: agent:Conatus

For /coach-report and any Dash run: do MCP-dependent pulls (Search Atlas, Google Sheets, Calendar) in the MAIN session; delegate only file/CLI/analysis work to subagents. Check a subagent's tool access assumption before waiting on it. Treat CCM STL as unusable until the CloudCRM timezone offset is fixed platform-wide, and never report STL from July data.

Why: Two full delegation rounds were wasted waiting on pullers that could never succeed; the report would have shipped without SEO (repeat of L057) and without CCM if the main session had not redone the pulls. The STL corruption finding upgrades the known Villa-only issue (June) to system-wide, which changes every STL-based alert and coaching metric until fixed.

Failure mode: SUCCESS (with lesson): Dash /coach-report 2026-07-19 — delegated Search Atlas, CCM sheet, and calendar pulls to three subagents; SEO and CCM pullers were fully blocked because spawned subagents do NOT inherit the session's MCP servers (search-atlas and google-workspace tools were absent from their toolsets). Main session had both and pulled everything directly. Also: CCM July speed-to-lead timestamps are corrupt SYSTEM-WIDE (large negative timezone artifacts on every project, not just Villa Sport).

Scope: agent:Dash

Two mechanics to remember: (1) .gitleaksignore fingerprints are commit-hash-bound, so ANY commit touching a line with secret-shaped placeholder text (like 'Bearer YOUR_API_KEY' in docs) re-mints the fingerprint and re-triggers the scanner — squash merges guarantee this recurs. The durable fix is neutralizing the placeholder so the rule can't match (angle brackets: 'Bearer <your-api-key>'), plus fingerprinting the immutable history. (2) CI checkouts with fetch-depth:0 fetch ALL refs and gitleaks scans all of them — one bad commit on an unmerged branch fails every branch's CI simultaneously; the ignore entry must reach each scanning checkout's .gitleaksignore, which means pushing it to the branch being scanned AND to main.

Why: Symptom (lint-and-type-check job failing everywhere at once) looks like a code regression but is actually the secret scanner; without knowing the two mechanics, the obvious fix (add one fingerprint) only patches one branch and the mole pops up on the next touch of the file.

Failure mode: SUCCESS: Conatus diagnosed a repo-wide CI outage caused by gitleaks fingerprint whack-a-mole — every branch's CI (including main pushes) went red at once from ONE unmerged branch's commit.

Scope: agent:Conatus

Add HiTone Fitness - Fayetteville, GA to the CCM exclusion list. Exclude it from portfolio appointment-rate math and never credit its bookings to Amanda or Erica. More generally: before crediting any project's booking as a caller win, confirm Sneeze It actually dials for that project. A project having rows in Project Stats does NOT mean we call it, because client-self-called projects also log rows.

Why: Praising the team for a booking they did not make destroys the credibility of the whole recap, and inflating the portfolio denominator with projects we do not dial makes the appointment rate meaningless as a coaching signal.

Failure mode: Arin included HiTone Fitness - Fayetteville, GA in the CCM portfolio totals and praised a Fayetteville booking as a team win in a draft Slack recap. Sneeze It does not call for Fayetteville GA. The exclusion list Arin was working from only named China Grove, Yadkinville, Lafayette (client self-calls) and ROT Frisco (inactive).

Scope: agent:Arin

The recurring L10 David runs with Dan is the SNEEZE IT meeting. Its board is Sneeze It only: the company/Leadership-team rocks (team c1e1a485), the Sneeze It scorecard tiles (Crystal, Arin, Havok, CCM), and the Sneeze It issues board. OTP product and engineering work is NOT a Sneeze It signal and does not go on that board unless David puts it there. When David's personal update touches OTP, log it as a headline, ask what he needs for it, and move on. Whatever Dan worked on that week is not automatically an agenda item; the agenda is the company's board.

Why: Dan spent the prior session deep in OTP mobile engineering and carried that context into the meeting as if it were the agenda. That is context bleed, not facilitation: it hands David a board reflecting what the agent worked on rather than what the company must decide. It also spends the scarcest thing in the meeting, David's attention, on analysis he did not ask for, in a meeting whose purpose is the agency's rocks, scorecard and issues. The facilitator's job is to hold the company's board, and to know which company's board it is.

Failure mode: Dan drifted the SNEEZE IT L10 into an OTP-product meeting. Two ways: (1) put OTP product/engineering work (mobile spec, merged PR waves, remaining Wave 3 decisions) on the board as a "signal" alongside Sneeze It's scorecard and rocks; (2) when David gave his personal update mentioning two high-value calls, Dan converted it into an OTP strategy analysis (is the PE group circling OTP or the agency, is the charity an OTP lighthouse account in a new vertical) instead of receiving them as headlines in the Sneeze It meeting. David: "this is just my personal update for Sneeze It our L10 is sneeze it, did you forget?"

Scope: agent:Dan

Headlines/personal update round is exactly TWO items per person: ONE personal, ONE business, both POSITIVE, one or two sentences each. It is a good-news round that sets the tone -- it is not a confessional, a self-audit, or a place to surface problems. Problems belong in Issues/IDS later in the agenda. Separately: facilitate ONE SECTION AT A TIME. Present the current section, get David's response, then move to the next. Do not lay the whole board (scorecard + rocks + issues + signals) out in a single message; that is a briefing document, not a facilitated meeting.

Why: The headline round exists to open the meeting on momentum -- wins are what make a team willing to look hard at problems in the next section. A facilitator who opens with his own failures inverts that and drags the tone down before the work starts. And dumping the full board at once removes the human's ability to steer: David cannot react section by section if every section arrives simultaneously, which is the same railroading failure as pre-framing decisions (L299), just delivered as volume instead of conclusions.

Failure mode: Dan gave a personal update that was long, self-critical and multi-part (three git errors, two misses in the meeting, a flag about his own KPI), and separately kept dumping the ENTIRE meeting board in one message instead of running sections sequentially. David: "personal update should be positive, lets follow EOS one thing at a time 1 personal one business".

Scope: agent:Dan

The "only Sneeze It" boundary applies to EVERY utterance in the Sneeze It L10, including Dan's own headline round -- not just the board and the signals. Before speaking in a meeting, check the subject of each sentence against the meeting's company: if the win, metric, or example belongs to OTP, it does not get said here, even about yourself. Dan's Sneeze It headline material comes from the Sneeze It board: Crystal's project count, Havok attribution, Arin's CC rate, CCM leads, the company rocks, client wins. Also: capturing a learning mid-meeting does NOT reset the context bleed that caused it. After capturing a context-boundary learning, re-read the next message being drafted against that boundary before sending, because the pull of recent work is stronger than the freshly-written rule.

Why: Three corrections on one boundary in a single meeting is not a slip, it is a demonstration that recency beats policy: Dan had spent an entire prior session inside OTP engineering, and that context kept resurfacing even after being explicitly named and captured. The practical consequence is that David spent his meeting correcting his facilitator instead of running his company. A rule that gets written and then immediately broken is worse than no rule, because it creates the appearance of a fix where the behaviour is unchanged.

Failure mode: Dan captured L074 ("OTP work is not a Sneeze It signal and does not go on that board") and then violated it TWO MESSAGES LATER, giving a Sneeze It personal/business update whose content was entirely OTP (mobile reflow at 390px, the orgtp.com/demo fix). Third correction on the same underlying miss in one meeting. David: "ok one more correction only Sneeze It".

Scope: agent:Dan

Verifying that a write round-trips through the API is NOT verification that the user-visible thing changed. When the request is phrased against a URL or a page ("add this to the page at <link>"), the acceptance test is the RENDERED PAGE, not the database field: load the page (or its rendered HTML) and confirm the text appears where the user pointed. Specifically for Ollie Insight: meeting.aiSummary is the carry-forward that renders in the NEXT meeting under "FROM YOUR LAST MEETING"; the current meeting's Ollie Insight panel is produced by the ollie-insight service (src/routes/api/ollie-insight.ts) and must be generated through that path. Before writing, identify which surface renders the target and confirm the field feeds it.

Why: A 200 plus a read-back proves the API worked, which is exactly the evidence that makes a wrong-surface write feel finished. Dan reported success with real verification attached, so the confidence was unearned rather than absent, which is more misleading than saying nothing. The user then spent his own live meeting time discovering the failure and doubting his own eyes. Where a request names a URL, the URL is the spec.

Failure mode: Dan was asked to add the Ollie Insight to a specific meeting page and wrote it to that meeting's aiSummary via PUT /api/v1/meetings/:id, then reported it done after verifying the field round-tripped. The page did not change. Two distinct panels exist: "FROM YOUR LAST MEETING" renders the PRIOR meeting's aiSummary (carry-forward), while the current meeting's "Ollie Insight" panel is a generated read from the ollie-insight service and showed "No read yet" with an "Ask Ollie for a fresh read" button. aiSummary on meeting N is next week's carry-forward, NOT this week's insight. David had to screenshot the unchanged page and ask "am I high?".

Scope: agent:Dan

For an agent-run meeting, the flow is: write the meeting record, POST /meetings/:id/agent-record, then POST /meetings/:id/ai/followups, which produces the insight through the normal pipeline with receipts. Never hand-write aiSummary. More generally: before concluding that a capability does not exist or that a human must do a step manually, search the codebase and recent PRs for the capability by NAME. Agent-facing plumbing that David built is often the exact thing being declared impossible, and the prior meeting's Ollie Insight had already named this one ("shipped the agent-record path"). A prior insight is a capability inventory, not just narrative.

Why: Declaring something impossible is a strong claim that ends the search, and it was made about a feature the user had personally shipped two weeks earlier and flagged as a signal. That is worse than a wrong answer: it tells the founder his own investment does not exist, and it pushed manual work back onto him inside his own meeting. The generated path also carries receipts, which the hand-written paragraph could not, so bypassing it degraded the product's core promise while claiming to serve it.

Failure mode: For an agent-facilitated L10, Dan hand-wrote an Ollie Insight, PUT it directly into meetings.aiSummary, and when that did not render told David the read could not be produced by an agent ("you click the button"). The purpose-built path already existed and David had shipped it himself on 7/6 as PR #154 for precisely this case: POST /api/v1/meetings/:id/agent-record submits the written record of an agent-run meeting, OTP redacts and persists it exactly like a confirmed transcript, and POST /api/v1/meetings/:id/ai/followups then generates the to-dos, issues, headlines and the insight, writing aiSummary itself. There is even a wrapper, ~/.claude/otp-meeting.sh record. David had to point at his own shipped feature: "I had this as a signal: Agent-record path shipped (PR #154), so Ollie can now read agent-run meetings."

Scope: agent:Dan

A meeting rating that drops after the same feedback was already given means the corrective was cosmetic. Treat a repeat sub-5 rating as a STOP: do not propose better intentions, change the mechanism. Concretely, before the next Delta Meeting Dan must (1) open the actual meeting the human will see and confirm every section renders real data, fixing or filing what is broken BEFORE the meeting, (2) generate the Ollie Insight in advance via the agent-record then followups path so the room opens with a read already present, (3) verify the board's company matches the meeting's company, and (4) arrive with a written agenda listing only sections that are working. The measure of prep is that the meeting contains no discovery. If a section cannot be made to work beforehand, say so in one line at the top rather than finding it live. Also: running one pre-flight correctly (Tally) does not constitute prep and must not be mistaken for it.

Why: The first 4/10 was a warning and the 2/10 is the confirmation that nothing structural changed. The cost is not the rating, it is that the founder's scarcest hour was spent watching his facilitator debug itself, in a meeting whose purpose was his company's rocks and numbers. An agent that consumes the meeting it was built to run is worse than no facilitator, because the human still has to do the facilitation AND absorb the correction overhead. This is the seat's core deliverable failing twice consecutively, which is a seat question, not a tuning question.

Failure mode: David rated the 7/20 Dan L10 a 2 out of 10: "nothing got done, nothing is right, kind of a waste of time today." This is DOWN from the 7/13 meeting's 4/10, whose stated cause was "we are fixing the meeting within the meeting with an absence of information. The work happens BETWEEN the meetings and this is not the case here." Dan received that exact feedback, had standing rules covering it (L299 signals-first, L310 scan live OTP, L332 walk the meeting before the meeting, L376 Tally pre-flight), executed only the Tally pre-flight, and then spent David's meeting on discovery and self-correction: five corrections in one sitting, a broken scorecard found live rather than before, an Ollie Insight written to the wrong surface, and a capability declared impossible that David had shipped himself. Zero to-dos set, zero issues worked, one ticket filed.

Scope: agent:Dan

Before a swamp send, reconcile the changelog against the week's real PRs (git log origin/main --since since the last issue, filter to feat/ and customer-facing) and write entries for anything unlogged -- do not assume changelog.ts is complete. When the shared repo is contested by a concurrent session, do all changelog authoring in an ISOLATED git worktree (git worktree add off origin/main, symlink node_modules to reuse deps), PR it, merge via gh after CI is green, and run the REAL send from the worktree -- never edit or send from the shared working tree. Date drop-wave entries to the issue's MONDAY anchor (the sender's window upper bound), NOT to the send day: entries dated the Tuesday send day render as future and hide, and getRecentEntries (OS-today) masks this in preflight.

Why: The changelog is the single source of truth for both /whats-new and the email; an unmaintained changelog silently undersells the product to every subscriber. On a machine with concurrent agent sessions, the shared working tree is not safe for a multi-step author+send; a worktree makes the work deterministic and collision-proof. The Monday-anchor date rule is invisible until a dated-Tuesday entry silently disappears from the send.

Failure mode: SUCCESS: Swamp #29 -- two non-obvious operational wins. (1) The digest only reflects changelog.ts, so a big shipping week (~14 features) went out as "2 things" because most PRs never got changelog entries; David caught it. (2) Running the swamp send while another session was actively branch-switching in ~/otp-platform stranded an early commit on a feature branch and made a direct push to protected main a no-op.

Scope: agent:Swamp

Sweep ALL session transcripts by concept and synonym (blank dashboard also means first-run, empty-state, cold start, isNewOrg, needsOnboarding) across every model and subagent log before reporting that something was never said. Never conclude no-record-exists from a single artifact; name the sources searched.

Why: Work here is produced across many sessions and several models, so a negative answer scoped to one file reads as authoritative and quietly discards real prior work. Same failure mode Rule 19 (grep before generate) exists to prevent.

Failure mode: Asked to recall a high-priority item from a Kris meeting, I searched only the obvious artifact (the Kris transcript and that one session), found nothing, and asserted no record existed. It did exist, in a different session produced by a different model (Fable 5, the 2026-07-17 four-workstream UI overhaul). David had to correct me twice.

Scope: agent:Conatus

For any EJS page whose logic lives in an inline script, add a test that parses every inline script with new Function() and fails the build on a syntax error, then prove the tripwire by running it against the broken version before keeping it. tsc cannot see inside a template and EJS renders a broken string happily.

Why: It was caught only by driving the actual rendered page in a headless browser, not by tsc, lint, or 1204 passing tests. First-run screens are where paying customers land, and a dead one is invisible from the server side.

Failure mode: SUCCESS: Conatus found OTP onboarding Door 4 (Give Ollie everything, PR #232, shipped 2026-07-19) had been completely dead in production since Sunday. onboarding-import.ejs line 214 had an apostrophe inside a single-quoted JS string, so the browser discarded the whole inline script and the file drop, analyze and commit buttons did nothing, silently, for every new customer who picked that door.

Scope: agent:Conatus

David: A2P pages do not allow form fills. Remove the lead form from A2P review landing pages entirely. Keep the SMS disclosure, the Privacy Policy and Terms links, and the registered business name and address on the page, because those are what carriers actually read. Route the quote path to phone plus the GHL chat widget. Reword any disclosure copy referencing "check the box above" so the page does not describe a mechanism that no longer exists.

Why: The form was the architecture of these pages, so this is not cosmetic: it orphans the consent audit trail and the POST /:slug/lead route, and it changes what the A2P campaign registration can declare as its opt-in method. Getting it wrong in either direction risks 10DLC rejection, which blocks SMS for the client entirely. The pattern repeats for every future A2P location page.

Failure mode: Built the Dryer Vent Squad A2P landing pages (Katy, DFW) around a web lead form with an optional SMS consent checkbox, treating that form as the opt-in proof mechanism for A2P/10DLC review, plus a consent audit trail behind it (consent.js and sms_consent_text/timestamp/IP/user-agent captured on POST /:slug/lead).

Scope: agent:Claude

The unbilled-spend sweep (billing-report step 3b) reads ~/.claude/billing/sweep-exclusions.json and drops those account IDs from the Review tab entirely. Use it for accounts that spend on our Google/Meta but are NOT billed on % of ad spend (white-label / flat-fee). Added 2026-07-23 per David: Phillip Jeffries, M.V. Parker Law, Champy's Chicken (+Nashville), Emily Shalant, Jet City Blinds, J&K Engines, Meyer Law, True Path, GettaMeeting, Lazzara Law, Studstill Firm. Only add IDs here on David's explicit instruction. Separate from the Clients-tab dont_bill mode (which still shows a DO NOT BILL row on the Billing output).

Why: Without a persistent list these 12 accounts (~$24.4K/mo) resurface as "confirm arrangement" in every monthly sweep, wasting David's review time. The file makes the exclusion durable across sessions.

Failure mode: SUCCESS: Billing sweep now has a persistent white-label exclusion list

Scope: agent:Radar

(1) Never filter ad accounts by current status when computing BILLING for a past/current period -- spend already incurred is billable regardless of whether the account is now disabled, unsettled, or closed. Pull insights for every account and let the spend value decide. Status filters are for "is this account live", never for "what did it spend". (2) Fail loudly on API/pagination errors in the account enumeration; a swallowed error silently truncates the account list and understates billing with no warning. (3) When quantifying a billing error, separate "the pipeline silently lost this" from "the pipeline correctly flagged this for a human decision" -- only the former is an error. Check the Review tab output before claiming an amount was missed.

Why: Billing accuracy is paramount and understated spend is silent lost revenue -- an account with a payment problem is simultaneously the most likely to be dropped by a status filter and the most likely to need invoicing. Verified scope on the 2026-07-23 run: 42 of 44 client rows were correct; only Powerhouse was wrong ($0 -> $514.63 spend, $0 -> $80 billing). Overstating the error size to the CEO on a sensitive billing document is its own failure -- it destroys trust in the audit as much as the original bug does.

Failure mode: Billing report (/billing-report) reported Powerhouse Gym at $0 while the client had live Meta spend. Root cause: billing_pull_spend.py filters the Meta account list with `account_status == 1` BEFORE pulling insights, so an account that spent money earlier in the month but is currently disabled/unsettled (Powerhouse went Active -> "Payment Needed" on 2026-07-17 after a card failure) is dropped from the spend file entirely -- it does not even appear as a $0 row. The same filter feeds the unbilled-spend sweep, so the account was invisible to BOTH the billing rows and the Review tab. Secondary failure: when first diagnosing this I overstated the impact as "~$144 of billing missed" by adding the client's unmapped Google spend ($925.66) to the Meta miss, when the Google line had in fact been correctly surfaced on the Review tab as a pending David decision. True billing error was $80.00.

Scope: agent:billing-report

Sneeze It bills a % of BOTH Google and Meta ad spend. An unmapped Google account for an existing client is not a pending question -- it is unbilled revenue, and every month it stays unmapped is money we never invoice. When the sweep surfaces a Google account whose name clearly matches a client already on the billing list (e.g. "POWERHOUSE Fitness Stratford CT" -> "Powerhouse Gym - Bridgeport/Stratford CT", "beem Light Sauna - Macon" -> "beem Macon (GA)"), map it to that client at the client's existing rate rather than parking it on Review. Reserve Review for accounts with genuinely no matching client. Write mappings to the Clients tab of the billing sheet (column E = Google IDs), not just local clients.json -- step 2 of the report re-syncs from the sheet and would otherwise wipe a local-only fix on the next run.

Why: Five Google accounts sat unmapped and unbilled: Powerhouse $975.68, GLO30 Columbus $301.85, beem Macon $116.19, beem N.Richardson $115.36, beem Bonaire $91.33. Mapping them moved July billing from $11,690 to $11,985 (+$295/mo, recurring). Treating billable spend as an open question instead of a mapping gap converts a data-entry task into ongoing revenue leakage. The correct default is: name matches an existing client -> map it and bill it.

Failure mode: On the billing report I treated unmapped Google ad accounts as an open question for David ("bill at 10%, or exclude?") and left them sitting on the Review tab month after month. Powerhouse Gym's Google account (2001047898, $975.68) had been flagged "REVIEW / confirm arrangement" since at least June while the client billed Meta-only. I also described the Google line as "correctly escalated, not lost," which was wrong framing.

Scope: agent:billing-report

(1) Before inventing a NEW client row for an unmapped account, check whether an existing client row already covers that entity -- multi-location clients (Rockstars, WOA franchises, beem, GLO30) often bill everything to one row, and corporate/HQ ad accounts belong on an existing location row rather than a new "Corporate" row. Ask which existing row, do not default to creating one. (2) The Clients tab column order is A=Client, B=% Ad Spend, C=Mode, D=Override $, E=Google Account IDs, F=Meta Account IDs, G=Manual Platforms, H=Notes. Google IDs go in E, never D. Verify by reading the row back before running the pipeline. (3) When David says "map the ones that are close and any others," finish the whole set in one pass and only hold back items where a wrong guess would materially overbill a client.

Why: Billing is David's most sensitive artifact and he was already frustrated at token waste from repeated correction rounds. Each avoidable round trip on a billing doc costs trust, not just tokens. The column-placement error in particular was silent -- the rows computed $0 with no warning, which is exactly the failure mode that started this whole investigation.

Failure mode: On the billing rebuild I created a standalone "Rockstars of Tomorrow Corporate" client row for Meta act_696250854945167 instead of mapping it to the existing Rockstars of Tomorrow Vegas row, and I flagged Workout Anytime Lakewood Park as an unknown arrangement when it is a known Sneeze It client. Both forced David to correct me on a task he had already told me to just finish. I also burned a full extra round trip by writing three Google account IDs into column D (Override $) instead of column E (Google Account IDs) on the Clients tab, which made those rows compute $0.

Scope: agent:billing-report

Match every client against the FULL live account inventory on both platforms (all statuses, all spend levels including $0), not just accounts with spend this month. Map on exact account-name match regardless of current spend, so the mapping is in place before the money moves. Treat the Notes column as a historical log, never as a source of truth about current platform coverage - re-derive coverage from the live account list each run. Also: HTTP 403 accounts are UNKNOWN, not zero; say so explicitly rather than letting them read as verified-zero.

Why: Sneeze It bills a % of both Google and Meta spend, so an unmapped account is pure revenue leakage the moment it activates. Verified 2026-07-24: sweeping the full inventory surfaced 17 additional client-owned accounts that a spend>0 sweep completely missed because they were all at $0 that month. Zero billing impact in July, but every one of them would have leaked silently the first month it spent - which is exactly how Powerhouse's Google account went unbilled for over a month.

Failure mode: The billing sweep only checked ad accounts with spend > 0 in the current month, and I trusted the "Meta only" text in the Clients tab Notes column as if it were current fact. Both are wrong. David pointed out those notes are historical - they describe how a client STARTED, not how it is now. A client can gain a Google account at any time; if that account happens to sit at $0 during the month I run the sweep, it never surfaces, the stale note keeps saying "Meta only", and the moment it starts spending we bill nothing.

Scope: agent:billing-report

Three patterns for the OTP recorder. (1) "No way to record a second time" is TWO bugs: the missing UI affordance AND a server ingest that overwrites (ingestTranscriptOneShot did set({transcript})). Fix both or the feature silently destroys data; recording ingests now pass mode:'append', idempotent on the tail so worker retries cannot double-append, while paste/import stays 'replace'. (2) "Mic recorded silence after a long pause" on a phone is a dead MediaStreamTrack (readyState 'ended' or muted): MediaRecorder.resume() succeeds and records nothing. Recover by swapping in a fresh getUserMedia stream, and ALWAYS flush the retired recorder's final chunk BEFORE bumping the server segment number, or the old container's tail bytes land in the new segment and corrupt it. Auto-recover only when the track is provably dead; when it is alive but silent, warn and offer a button, since a genuinely quiet room looks identical. (3) Check git log before rebuilding from a support ticket: background transcription had already shipped that morning, so ticket 3 needed a sequential-to-concurrent R2 upload fix plus a crash fix, not a rebuild.

Why: The recorder holds the customer's only copy of a meeting until upload completes, so every bug in it costs unrecoverable audio, and two shipped in one day. The widget is inline JS in an EJS partial with no import path, which is why it went untested; it can now be tested by rendering the partial, extracting the script, and running it in a vm against a fake MediaRecorder (src/views/partials/meeting/audio-record.test.ts). Use that harness for future recorder changes.

Failure mode: SUCCESS: Claude (OTP dev) fixed three meeting-recording tickets (PR #315) at root cause, and caught that PR #309 from earlier the same day left savedStatus() calling itself on the non-pending branch (a stack overflow that swallowed the save confirmation on the R2-off path) because the recorder widget's inline JS had no tests.

Scope: agent:Claude (OTP dev)

When editing OTP trust/security claims, edit src/config/trust.ts (the file the /trust route imports and ships in the dist image). trust.yaml at the repo root is only the audit copy carrying `# source:` code citations for legal; nothing reads it at runtime. The two had already drifted (legalEntity OTP,LLC vs OrgTP,LLC; a stale lastUpdate; and — critically — trust.ts shipped a prohibited EOS mark "L10" that trust.yaml did not). Always mirror any claim change into BOTH files, and treat trust.ts as authoritative for what the public actually sees.

Why: A trademark-compliance violation (EOS "L10" mark) was live on the lawyer-facing trust page for weeks because the de-EOS pass only fixed trust.yaml, which never ships. Editing the audit copy feels like fixing the page but changes nothing a visitor sees. This is a recurring drift trap worth a permanent CI equivalence check between the two files.

Failure mode: SUCCESS: the public /trust page renders src/config/trust.ts, NOT trust.yaml — the "source of truth" file never loads at runtime

Scope: agent:Claude

Never position OTP (or Ollie) as an employee. A founder, and even an employee, does not want another employee; they want to know the organization is held. "Employee" also imports employee mentality: waits to be told, owns a lane not the whole. OTP guides the organization. Frame it as the guide/what holds the company, positioned between employee (too small), guru (too big), and co-founder (not really).

Why: Positioning error at the core-promise level: hiring an employee increases a founder's load (managing, explaining, checking); OTP's promise must reduce the holding. Wrong noun poisons every downstream page, price, and demo.

Failure mode: Framed OTP's destination as "the first employee a company hires whose job is to remember" in the product discovery brief.

Scope: agent:Claude

Two rules. (1) After any push that opens a PR, verify the remote head equals the local HEAD sha (git ls-remote origin refs/heads/branch vs git rev-parse HEAD) before creating the PR; never push refspecs of the form otherbranch:target when HEAD is a different branch. (2) "Deployed" is verified by probing for the CHANGE's own fingerprint (a string, a behavior, an endpoint), never by sha match alone; a sha only proves a deploy happened, not that the intended change is in it.

Why: Refspec pushes silently ship whatever the named ref points at, and a squash-merged empty-diff PR looks green end to end (checks pass, auto-merge fires, sha matches prod). The only step that catches it is content verification, and skipping it cost a full test cycle and a wrong "deployed" claim to David.

Failure mode: Claude shipped PR #358 believing it contained the Composio OAuth-return fix, then confirmed "deployed" by matching the prod commit sha. The fix was committed on a freshly checked-out branch, but the push used the refspec push oldbranch:newremotebranch with the OLD branch name, so the PR contained a stale duplicate of the previous commit and the actual fix never left the machine. David tested on prod and the bug was still there.

Scope: agent:Claude

When a vendor was chosen specifically to absorb an operational burden, do not propose solutions that hand that burden back, even when the vendor documents them. Default order for the consent-screen concern: (1) own the story in product copy (tell users they will see Composio, frame it as the security vault), (2) at most white-label the two or three marquee providers if branding ever matters commercially, (3) never the whole catalog.

Why: Vendor docs happily describe features that shift work back onto the customer. The right frame is the original build-vs-buy decision: Composio IS the OAuth team. Recommendations that quietly re-hire that job in-house waste the subscription and David's time.

Failure mode: Asked how to get OTP branding on the Composio OAuth consent screen, Claude recommended white-labeling via custom auth configs, which means creating and maintaining an OTP-owned OAuth app per provider (Slack app review, Google verification, secret rotation, scope upkeep). David rejected it: the reason OTP uses Composio at all is ONE managed OAuth surface across hundreds of products; a per-provider OAuth app pipeline recreates the exact burden Composio was chosen to eliminate.

Scope: agent:Claude

The GHL OTP pipeline holds prospects: Clay-sourced coaches, meeting/demo attendees, inbound leads. Existing signups never become GHL contacts. Clerk/user data is used only to (a) detect when a tracked prospect converts (move their opportunity to Signed Up / won) and (b) enrich engagement signals on prospects. Dawson's queue is prospect follow-up, not user nurture.

Why: Two systems covering the same people creates double-touching and noise; the actual gap in the sales process is prospect visibility and follow-up, which nothing else covers. Signup is the pipeline's finish line, not its content.

Failure mode: OTP-Sales Lane 1 was built to bulk-import existing OTP signups (Clerk users) into GHL and queue re-engagement touches on existing users. David corrected: existing users are already covered (product, lifecycle emails, Swamp); the GHL pipeline is for PROSPECTS only — people who have not signed up yet.

Scope: agent:OTP-Sales

The no-eosworldwide-addresses exclusion no longer applies to the GHL "Clay Email Send" nurture channel — EOS coaches are explicitly in-ICP for it (David 2026-07-26). The exclusion survives only where the copy or channel still carries risk; check the current copy for EOS marks before any send, but do not remove EOS addresses from nurture.

Why: The original rule existed because outreach copy used EOS marks during an open trademark compliance matter. The copy is now mark-free, so the audience exclusion lost its reason; keeping it would exclude the best-fit coach ICP from the pipeline.

Failure mode: OTP-Sales flagged 19 @eosworldwide.com contacts in the otp nurture sequence as a violation of the permanent no-EOS-addresses rule and moved to de-tag them. David overruled: EOS implementers/coaches ARE a prime target for OTP nurture, and with all OTP copy de-EOS'd there is no remaining trademark exposure.

Scope: agent:OTP-Sales

Sneeze-Sales creates contacts, opportunities, tags, notes, and tasks in GHL but NEVER applies the sequence/nurture trigger tag — sequence enrollment is David's manual step after he vets each contact. ICP for Sneeze It prospecting: FRANCHISORS in fitness, health and wellness, med spa, and any membership-type organization.

Why: Auto-enrollment removes the human gate that protects existing clients and active relationships from cold sequences. David's manual vetting before enrollment is the safety mechanism; the agent's job ends at a clean, deduplicated contact load. The franchisor ICP keeps the pipeline focused on multi-unit expansion revenue.

Failure mode: The first /sneeze-sales spec copied the OTP pattern of auto-applying the nurture tag at contact creation, which would auto-enroll new prospects in the email sequence. David corrected: for Sneeze It, the agent only loads contacts into GHL; David runs the sequence himself so nothing is ever sent to a customer or someone he is already talking to. The spec also lacked the Sneeze It ICP.

Scope: agent:Sneeze-Sales

The company boundary applies to every artifact that feeds Ollie, not just what is said in the room. When writing a meeting record for the Sneeze It L10, describe mechanisms in company-neutral operational terms (the meeting pipeline, the prep gate, the record path) and keep OTP product identifiers (PR numbers, endpoints, feature ship dates) out of the record entirely. Before pushing any record via agent-record, scan it with the same company-mismatch check the preflight applies to the board.

Why: Ollie's insight renders inside the Sneeze It meeting, so a record contaminated with OTP content produces a contaminated insight automatically, one week later, with no human in the loop. The boundary check must move upstream to where the source is authored or the violation recurs on autopilot.

Failure mode: Dan wrote the 7/20 agent-record for the Sneeze It L10 full of OTP product identifiers (PR #154, the agent-record endpoint, ship dates), so the Ollie Insight generated from it reads as OTP product narrative inside the Sneeze It meeting. David caught it live on 7/27: "Ollie still thinks OTP and Sneeze It are one." The context-bleed boundary was enforced in live speech but not at record-writing time, and the record is the insight's source.

Scope: agent:Dan

Prep does not end at the Slack brief. Any signal the brief nominates for IDS gets pushed to the OTP board as a ticket (otp-issue.sh, with teamId, AI Army = 065d1d4b) BEFORE the meeting, so David opens the meeting with the issues already loaded and workable in-product. The Slack brief is the narrative; the board is the working surface.

Why: The meeting runs inside OTP, so an issue that exists only in Slack is invisible at the moment of solving. This is the same source-of-truth lesson as L060 applied to prep outputs, not just prep inputs.

Failure mode: Dan surfaced pre-meeting signals (Pulse dark, pipeline shape, HiTone, overdue queue items) only in the Slack prep brief. David at the 7/27 L10: "you should have wrote those signals in OTP, too late now." Signals that deserve IDS never landed as tickets on the AI Army board, so the meeting could not work them in-product.

Scope: agent:Dan

When David closes an alert as handled, retire the RULE that generates it, not just the instance. For HiTone: edit the CLAUDE.md trigger line and coach-report spec to read "billing confirmed active since Jul 2026, do not flag on spend." In general: trace any recurring alert to the config line that emits it and fix that line, or the alert regenerates forever.

Why: A closed instance with a live trigger is an alert factory. It spends David's attention on the same resolved question weekly and erodes trust in real billing flags.

Failure mode: HiTone billing keeps re-surfacing to David even though he confirmed billing is correct and active (Jun 29, and again 7/27: "HiTone is being billed, you ask about that a lot"). Root cause: the BILLING TRIGGER rule still lives in CLAUDE.md's active-clients list and in the coach-report spec, so any agent that reads the config re-fires the flag whenever HiTone spend appears. The Jun 29 closure was recorded in the rocks file, but the upstream trigger rule was never retired.

Scope: agent:Dan

Prep must scan for WON/signed revenue explicitly, not just open pipeline: GHL won opportunities across ALL pipelines since the last meeting, plus Proposify signed events, categorized new/expansion/reactivation. Signed expansion revenue is the Q3 headline metric; it leads the scorecard section, and its dollar values get pushed to the manual Expansion tile the same morning. A tile with no automated source still gets its value entered at prep time from the won-deal scan; manual source does not mean no value.

Why: The board exists to catch exactly this: revenue proving or disproving the quarterly thesis. A prep that inventories dead tiles but misses live signed money reports the plumbing and skips the water. David finding revenue wins that his facilitator missed inverts the entire point of the seat.

Failure mode: Prep missed two signed expansion deals (Glo30 and WOA franchise additional revenue) that David saw on the board himself and had to point out at the 7/27 meeting: "you skip that a lot, did you not see them?" The prep scan read open opportunities in one GHL pipeline and the Expansion KPI tile (manual, no values), so signed/won expansion revenue had no path into the brief. The single most strategy-relevant signal of the quarter, expansion revenue from existing accounts, was invisible to prep while five dead tiles got named in detail.

Scope: agent:Dan

Same-session capture rule for ALL agents: when you witness David build or ship something real (a dashboard, an integration, a signed deal, a process), record it THAT session: a headline line in the daily note, and a todo or KPI value in OTP if money or a rock is touched. Do not wait for the weekly meeting; the builder remembering to report is not a capture mechanism. Dan additionally runs a Shipped This Week sweep every Monday prep as the backstop.

Why: Work done outside meetings is systematically invisible to a meeting-based OS, and the founder's most valuable hours happen outside meetings. Three instances surfaced in one meeting (dashboard, prep signals, signed revenue). Invisible work costs real money: David unknowingly built part of Bogdan's open reporting-cost rock.

Failure mode: David built a WOA dashboard for iCart (central database, less Zapier, better reporting) and the only witness was the AI in that session; no headline, todo, or record reached the operating system. David at the 7/27 meeting: "the only one that knows is you, this is a true failure of the operating system that needs to be reconciled." Same morning, two signed expansion deals (Glo30, WOA franchise) were also absent from every system of record.

Scope: agent:Dan

Facilitation = operating the product live. The moment a section starts, its artifact moves: an issue under discussion is verified rendering on the board before discussing it; the moment David decides, the ticket is solved with its resolution, the todo is created, the KPI is pushed, in that minute, not at conclude. After every state change, verify the rendered surface. Conclude should be a read-back of changes already made, never a batch of pending writes.

Why: A meeting inside OTP is only real if the product state changes while the humans watch. Deferred writes recreate the mirror-drift problem inside a single meeting, and David cannot trust a board that lags the conversation.

Failure mode: Dan facilitated IDS discussion in chat but did not move the meeting's product surfaces in real time: the Pulse issue being discussed was not visible in the meeting's IDS section, and the already-solved invisible-work issue still sat open on the board. David 7/27: "you should be moving the meeting along like a human, doing things as we work."

Scope: agent:Dan

The needle test has a step zero: before wiring, fixing, or reporting any KPI, confirm the program/offer it measures still exists in the business, by asking David or checking recent revenue/activity, not config files. A dead program's tile is retired, not wired, and its language gets swept from all agent config at source (L099 pattern) so no agent rebuilds it. Guarantee/T20 program: DEAD as of 2026-07-27.

Why: Config outlives strategy. Wiring effort spent on a dead program's metric is worse than a dead tile, it would have shipped a number that misrepresents the business as still running an offer it killed, and every agent reading the tile would have inherited the fiction.

Failure mode: Dan was one step from wiring the guarantee-clients-retained KPI (emit line written, Tally about to fire) when David said the guarantee program is dead and no longer offered. The wiring work treated the tile's PROGRAM as alive because the config said so; nobody had asked whether the business still runs the thing the tile measures.

Scope: agent:Dan

When a media element silently stalls (networkState LOADING, error null, no console output), suspect CSP: a 302 redirect from a same-origin playback route to a cross-origin storage URL violates media-src (falling back to default-src 'self') and Chrome blocks it with zero surfaced errors. Diagnose live by attaching a securitypolicyviolation listener and probing a known cross-origin media URL. Fix: add the presigned bucket origin to media-src, computed from storage config at boot, never hardcoded.

Why: This failure mode is invisible by design (no element error, no console noise) and the natural debugging paths (storage probes, presigned URL tests, range requests) all pass, sending you everywhere except the CSP header. Cost about an hour across two sessions; the probe technique turns it into a 2-minute check.

Failure mode: SUCCESS: Claude/Conatus diagnosed why OTP meeting recordings never played in the browser (player stuck at 0:00, click did nothing) while server-side storage checks all passed.

Scope: agent:Conatus

Never invent a person's first name from an email address or initial. If the name is not stated, refer to them by the email address or ask David, and only record a name once confirmed.

Why: Guessed names propagate into client-facing artifacts (emails, dashboards, docs) and getting a client's name wrong damages trust; an email initial is not evidence of a name.

Failure mode: Claude inferred the Drybar Ballston client's first name as "Jodi" from the email address jsterling@sterlingcapitalllc.com and used it in the summary, credentials file, and memory. The client is Julie Sterling.

Scope: agent:Claude

`ghl.sh update-opp <oppId> <stage>` with the optional value argument omitted hits an inline Python syntax error (`data['monetaryValue'] = ` with nothing after it), so the stage payload is never built: the opp's updatedAt bumps but the stage does NOT change, and nothing errors loudly. Workaround until ghl.sh is fixed: always pass the value explicitly, e.g. `update-opp <id> sql 0` (confirm the opp's current monetaryValue first so you do not overwrite a real value). Always verify stage changes by re-reading the opportunity after the write.

Why: A stage move that silently no-ops corrupts the pipeline of record without any error signal. Both /otp-sales and /sneeze-sales route stage moves through this command; without the verify-after-write habit the bug would have shipped 2 phantom SQL bumps today.

Failure mode: SUCCESS: Sneeze-Sales found and worked around a silent ghl.sh write failure

Scope: agent:Sneeze-Sales

Before bumping a stage or queueing a task on any reply, check the PERSON and company against the active client list (CLAUDE.md), pepper-clients.md, and known client people, not just the cold-load exclusion at contact creation. Jordan Anderson is a client (Workout Anytime / Proof Fitness): never prospect-touch him on any domain. Replies inside threads a team member already owns (for example Zeynep scheduling) get no David task; the owner handles it. A reply landing in the prospect book is a signal to verify WHO it is, not proof they are a prospect.

Why: The prospects-only law fails at the edges: client people reply from domains that sit in the prospect book because franchisee outreach and client domains overlap (WOA). A wrong SQL bump plus a David task double-touches a client relationship and burns David's queue on non-sales work.

Failure mode: Sneeze-Sales treated Jordan Anderson (Workout Anytime) as a prospect: bumped his opp MQL to SQL on an inbound reply and queued David a respond-within-24h task. David corrected: Jordan Anderson is a client. Also queued David a confirm task on Lindsey (Fitness Factory) when Zeynep already owns that thread.

Scope: agent:Sneeze-Sales

When an OAuth integration fails silently, verify each layer with direct probes instead of reasoning from app behavior: (1) print env var names with cat -v, since a pasted quote becomes part of the variable NAME and the app reads undefined (Railway kv showed "GOOGLE_CALENDAR_OAUTH_CLIENT_ID with a literal leading quote); (2) test client credentials against the provider token endpoint with a bogus auth code, since the error distinguishes exactly: invalid_client means bad id/secret, invalid_grant Malformed auth code means credentials are VALID; (3) treat the database as ground truth for whether a flow completed, since users saying connected can mean a different surface (Composio integrations page vs the calendar card).

Why: Three probe layers turned what could have been hours of guessing into minutes: no callback in logs proved the flow died at Google, cat -v exposed the quote character, and the bogus-code token probe verified the replacement secret BEFORE the user retried, avoiding another failed round trip. Reusable for every OAuth integration OTP adds (Microsoft, Zoom, future providers).

Failure mode: SUCCESS: Claude shipped Recall calendar auto-join and debugged two invisible OAuth config failures the same afternoon (quoted env var name, invalid client secret)

Scope: agent:Claude

When David asks a scoped product question (where does X go, what should X be called), answer inside the existing structure at the same altitude as the question. Propose the minimal change list first; expand scope only if he asks for the bigger vision.

Why: Scope inflation on design questions wastes David's attention and buries the actual decision. A placement question needs a placement answer; a mock that redesigns everything makes the one decision harder to see, not easier.

Failure mode: Asked where Ollie belongs in the OTP nav, Claude produced a full interactive mock that reinvented the entire OTP menu experience (command palette, dock, context invocations, insight relocation) instead of answering the narrow placement question David actually asked

Scope: agent:Claude

When graduating a feature out of Labs, grep the whole repo for the feature key and isFeatureEnabledForOrg calls before merging; every gate (page, API, scheduler, MCP tools) must come off in the same PR. A fail-closed flag check on a deleted key silently disables the feature for everyone, which reads as random 404s, not as a flag problem.

Why: Fail-closed gating is correct security posture, but it means catalog removal IS a kill switch. The bug shipped invisible because the page worked while the API did not, and the generic 404 body hid the cause; the honest error message shipped hours earlier (names the workspace and feature) is what made the real diagnosis possible.

Failure mode: Projects went GA (PR #347 removed it from the Labs catalog and the page gate) but the API routes kept gating on the removed key; isFeatureEnabledForOrg fails closed on unknown keys, so all project CRUD 404'd platform-wide for two days until Dawson and David hit it

Scope: agent:Claude

Agent-owned issues belong on the shared meeting IDS list, full stop — David ruled 7/28: "Humans and Agents work as one." When an agent raises an IDS issue for a team meeting, it must land on that team's board (correct team_id) and render in the meeting; when an issue is solved during a live meeting, stamp solved_in_meeting_id so the solve is part of the meeting record.

Why: OTP's core differentiator is agents as first-class seats on the chart. A meeting surface that hides agent-owned work contradicts what the product says it does (Constitution axiom: reconcile what it SAYS with what it DOES) and made real coordination work invisible in a dogfooded meeting.

Failure mode: The meeting IDS section in OTP filtered out ALL agent-owned issues (owner_entity_type='agent' or AGT_* owner) by an old "EOS leadership meetings are humans-only" convention, so the 7/27 Dan L10 (an all-agent team) rendered a blank IDS while 2 open team tickets existed on the board. Agents were also solving issues via MCP set_ids_status without stamping solved_in_meeting_id, so live solves never showed in the meeting's solved list.

Scope: agent:Dan

Any otp-platform endpoint that scopes data or authz by getAuth(request).userId is broken under impersonation. The rule: gate and scope by the EFFECTIVE viewer (request.impersonation.as when active, else auth.userId), return/audit with the RAW session id, and for context-pinning actions (org switch) re-issue the impersonation cookie via startImpersonation rather than moving the admin's own cookies. When reviewing or writing any new route, grep for getAuth(request).userId used in a WHERE clause — each one is a latent impersonation bug.

Why: Impersonation is how David supports customers (view-as Tom, Kristen, etc.). Every raw-session usage silently shows the admin's data under the customer's banner or 403s the customer's own surfaces — a privacy leak in one direction and a support dead-end in the other. Fixed instances: dashboard (2026-06-02), PRs #381, #382, #384 (2026-07-28).

Failure mode: SUCCESS: Dan identified a recurring defect class in otp-platform — four separate surfaces broke under super-admin impersonation in one day (portfolio pages listing the admin's portfolios, portfolio API 403ing "Could not load team", the sidebar org label showing the admin's org, and the org switcher 403ing "Could not switch organization"), all with the same root cause.

Scope: agent:Dan

Never accept a clean result from a scan whose only evidence is the absence of output. Verify with a second, structurally different method — for a text scan, a literal `split(term).length-1` substring count alongside the regex pass. Prefer writing the scan to a file over inline `node -e` with nested quoting. This applies to any gate whose passing condition is silence: compliance scans, lint greps, security sweeps.

Why: A gate that fails open is worse than no gate: it converts "we did not check" into "we checked and it was fine," and the outward-facing send proceeds with false confidence. The trademark deadline was the next day.

Failure mode: A /swamp compliance scan reported "clean" when it was not. The regex scan was written inline via `node -e` with a template string, and the shell/JS escaping consumed the `\b` word-boundary anchors, so every pattern silently failed to match. A literal substring re-check on the same text immediately found an EOS Worldwide agenda mark ("headlines") in an entry about to go to 48 customers.

Scope: agent:Swamp

Never let In The Swamp undersell the week. The newsletter's entire promise is "we ship every week" -- its own header reads "30 weeks deep in the swamp / We shipped. Again." -- so a thin issue in a heavy week contradicts the brand it rests on. A major narrative entry does NOT substitute for the shipping haul; they reinforce each other. Operationally: at /swamp step 3, never treat a small changelog window as the answer. Cross-check it against `gh pr list --state merged` for the window, and if customer-facing work is unlogged, reconstruct the entries BEFORE presenting at the gate, recommending the full haul rather than the thin issue.

Why: This is the second consecutive week the changelog undercounted what shipped, and the first time it actually reached customers. The deeper fix is writing changelog entries when features ship rather than reconstructing them under time pressure on send day. An agent that spots a problem and then argues its way past it is worse than one that never spotted it, because the human trusts that the gate was real.

Failure mode: In The Swamp #30 shipped to 48 customers saying "2 new things this week" during a week in which 41 PRs merged (calendar auto-join, Ask Ollie and Projects going GA, 83 integrations, the meeting recap page, and more). I detected the gap at the approval gate and then actively recommended sending the thin version anyway, arguing the constitution entry was "a stronger story undiluted." David's verdict: "with all the work we did this week this issue is lame!!!lame,Lame!"

Scope: agent:Swamp

When working in a git worktree, never run `gh pr create` from a different directory and never trust the returned number implicitly. Always pass `--head <branch>` explicitly, and immediately verify with `gh pr view <n> --json number,headRefName,title` plus `gh pr diff <n> --name-only` that the PR is yours and touches the files you changed, BEFORE merging. Same check before any `gh pr merge`: confirm headRefName matches your branch. A returned URL is not proof a PR was created -- gh silently returns the existing PR for the current branch.

Why: Two real harms: another session's PR was merged without their intent, and a false "merged and live" status was reported to David for work that did not exist on main. In a repo with concurrent agent sessions and shared worktrees, the current directory's branch is not a safe implicit argument, and a merge is not reversible by simply noticing later.

Failure mode: Ran `gh pr create` from the shared repo directory (/Users/dsteel/otp-platform) while my actual work lived on a branch in a separate git worktree. The shared dir was sitting on ANOTHER session's branch, so gh did not create my PR at all -- it printed that branch's already-existing PR URL (#392). I read that as my PR number, then merged #392, which merged a different session's unrelated work. My own changes were never PR'd and never reached main, and I reported to David that they were merged and live.

Scope: agent:Swamp

An agent's knowledge of its own product's capabilities must be STATED in context on every turn, not left to be discovered through tools. A tool only helps if the model reaches for it, and a model never reaches for a tool covering a capability it is confident does not exist. Two fixes are required together and neither is sufficient alone: (1) a standing context block asserting the capability plus current state, which must never be omitted in the empty case, since the org with nothing set up is exactly the one about to be told the feature does not exist; (2) tools that let the agent act on the knowledge, including a discovery/list tool, because a capability an agent cannot enumerate is one it will guess identifiers for. Also put a guard in front of any rule that lets the agent say "the product cannot do that": having no tool for X is not evidence that X does not exist.

Why: Denying a shipped feature is worse than admitting uncertainty: the customer walks away believing the product lacks the thing they were about to pay for, and the false denial is logged as a feature request, so the team reads demand for something already built. This is the same failure class as the 2026-07-29 connections bug (Ollie saying he did not know about a connection that existed) one layer up, which means it is a recurring shape and not a one-off: every capability an agent has is a capability it can confidently deny.

Failure mode: Ollie told a customer OTP has no cron or recurring-automation feature and offered to file it as a feature request, when scheduling had already shipped (Processes Phase 2b: hourly/daily/weekly cadences, timezones, a poller, wallet gating). Ollie had no scheduling tool and no standing statement that the capability existed, so he answered a product question from memory and denied a shipped feature to a paying customer.

Scope: agent:Ollie

Do not treat a missing or small wallet balance as a signal of anything. An org with no wallet is simply not an active OTP user, so its balance says nothing about product readiness. New orgs are seeded with $25 of credit to incentivise starting, so a funded wallet is the default going forward rather than a hurdle. When assessing whether a metered feature is usable, filter to orgs with real activity and check the NON-wallet prerequisites, since those are the ones that actually gate anyone.

Why: Reporting wallet balances as blockers manufactures work out of the ordinary shape of the user base: most rows in that table are dormant signups, not stuck customers. It also buries the prerequisite that does bite, because a real blocker listed next to four fake ones reads as one item in a list instead of the single thing to fix.

Failure mode: Flagged orgs with low or missing wallet balances as a readiness problem for OTP scheduling, treating wallet funding as a live blocker worth David's attention.

Scope: agent:Conatus

Ship the renderer in the same change as the agent that writes for it. If an agent is instructed to write Markdown, the surface must render Markdown, and that renderer must escape every byte BEFORE emitting any tag, because the text is model output plus tool output quoted back and neither is trustworthy. Whitelist link targets to internal paths and http(s) so javascript:, data: and protocol-relative URLs degrade to plain text. Render on every streamed chunk rather than only at the end, and make the renderer tolerate half-arrived Markdown, since every intermediate frame is partial. Also instruct the agent to LINK every place it names: an answer that mentions a page without a link converts an answer into a chore.

Why: Formatting is not cosmetic when it is the whole interface: raw asterisks read as broken software and undermine trust in the answer's content. And an unlinked destination is where a good answer stops being useful, because the user still has to find the page. Both faults survived launch because the prompt and the view were changed by different people at different times, with nobody owning the seam between what the agent writes and what the page renders.

Failure mode: Ollie's answers reached the chat page through textContent, so the Markdown he writes was displayed literally: users read "- **Linear is not connected**" with the dashes and asterisks in it. Separately, his answers named destinations ("connect it in Settings, Integrations") without linking them, leaving the user to go hunting for the page.

Scope: agent:Ollie

When a permission or filter function branches on an enum, make the fall-through explicit and test every enum value, because a value added later inherits whatever the final branch happens to be. Silent fall-through to the STRICTEST branch is especially dangerous: it fails closed, so it looks safe and produces no error, while quietly denying access to real users. Second, never let a UI decide "empty" from a proxy count. Ask the question you actually mean (how many SEATS are there) rather than one that happens to correlate (how many nodes), because the proxy breaks the moment a filter removes a structural node. Third, when a page shows two contradictory facts at once -- "0 on the chart" beside "9 members" -- treat the contradiction itself as the bug report and trace which of the two is lying before touching anything.</what_to_do> <parameter name="why">This is a total loss of the product's core surface for every non-owner in the org, and it is invisible to the person who built it, because owners and super-admins take the unfiltered branch and see a working chart. The customer experience is "your product is empty and I already put my team in it." A permission bug that fails closed generates no exception and no alert, so the only detection path is a human complaining -- which means test coverage over the whole enum is the only thing that would have caught it.</why> </invoke>

Why: Nine of ten members at McFadyen Digital opened the OTP org chart and were told "No agents or humans on the chart yet" while the same page showed "9 members" and "Shared to network v4". Two causes: (1) the view-scoping filter built its allowed set from claimed tiles only, so the organization ROOT node was dropped, leaving the renderer no node to draw down from, and the page's empty-state gate counted total nodes rather than seats, so a member holding exactly one seat looked identical to an empty chart; (2) the roles `visionary` and `integrator` were added to the role enum after the permission function was written, matched none of its branches, and silently fell through to the most restrictive one. The module had no test coverage at all.

Failure mode: Nine of ten members at McFadyen Digital opened the OTP org chart and were told "No agents or humans on the chart yet" while the same page showed "9 members" and "Shared to network v4". Two causes: (1) the view-scoping filter built its allowed set from claimed tiles only, so the organization ROOT node was dropped, leaving the renderer no node to draw down from, and the page's empty-state gate counted total nodes rather than seats, so a member holding exactly one seat looked identical to an empty chart; (2) the roles `visionary` and `integrator` were added to the role enum after the permission function was written, matched none of its branches, and silently fell through to the most restrictive one. The module had no test coverage at all.

Scope: agent:Conatus

Before retiring a scarcity, cohort or badge claim, count each cohort in the database and check whether one phrase names several cohorts. Shared wording is not shared meaning. If counts contradict the instruction's premise, return to the human with the numbers instead of executing literally.

Why: Broad approval rests on an assumed premise. When the premise is partly false, literal execution silently destroys value: a deleted live offer throws no error, it just yields fewer signups. One query per cohort is cheaper than a loss nobody detects.

Failure mode: SUCCESS: Claude verified cohort counts before executing an approved codebase-wide sweep of OTP's "first 50" claim. It was closed for signups (50/50) but live for Founding Publishers (45/50) and Founding Partners (6/50). Literal execution would have deleted two accurate live offers.

Scope: agent:Claude

When a UI bug report is ambiguous about WHICH control is meant, and a first search shows the obvious candidate already works, do not pick the next-most-plausible candidate and ship it. Enumerate every surface matching the description (here: the row edit form, the Add composer, AND the overflow menu) and either fix all of them or ask for a screenshot before building. Tell: when a report names visible button labels the user can see, ask which screen rather than inferring.

Why: Shipping the wrong fix costs a full CI + review + merge cycle and leaves the reported bug live, so David has to report it twice. One clarifying question, or a two-minute enumeration of candidate surfaces, is far cheaper than a merged PR that misses. This is the UI twin of "grep before generate" (Rule 19): enumerate before you build.

Failure mode: David reported "Need a cancel on (Edit Save) TODO (Daily View)". I grepped the Daily view, found the per-row edit form ALREADY had a working Cancel, so I concluded the gap must be the Add To-Do form and shipped that (PR #409). David then sent a screenshot: he meant the ellipsis overflow menu on a to-do row, which showed only Edit and Delete. I fixed a real gap, but not the one he was pointing at, and only found out after it merged.

Scope: agent:Claude

For multi-agent feature builds: (1) research agents return structured briefs before any code, and briefs override the spec when they conflict (two detectors were impossible as specced: meetings have no booked-duration column, decisions are not rows). (2) Put all shared-file wiring (server.ts) in ONE sequential final task so parallel agents never collide. (3) Always run an independent fresh-context diff review before committing: it caught two honesty blockers the per-task verifications missed (ratified moves netting costs away; org-wide gains summed over subtree-scoped costs). (4) Discovery worth acting on: subscriptions.plan_rate is never written by any code path in otp-platform, so any revenue/cost feature reading it ships dark until billing populates it.

Why: The per-task agents were all green individually; only the cross-seam review found the invariant violations. Repo guard tests (private-issue leak scan, blueprint coverage) also fired exactly as designed, proving lint-style guard tests catch what unit tests cannot.

Failure mode: SUCCESS: Claude shipped OTP Impact Phase 1 (PR #427) via 11-agent build: parallel research briefs, wave execution with pure-function cores, then adversarial diff review before commit

Scope: agent:Claude

When adding a NEW page to an existing app, open a sibling page that already ships (for OTP admin surfaces, /admin/support) and copy its outer container, top padding and control classes verbatim before writing any markup. Do not hand-roll spacing from DESIGN.md tokens alone -- the tokens do not tell you the page-level offsets that keep content clear of the fixed header. For any default that is a money amount, confirm the number rather than inferring it from the option list order.

Why: A new page laid out from first principles looks subtly wrong in ways the author cannot see without loading it: header collisions and control scale only show up in a browser, not in typecheck, lint or design-lint, all of which passed. Copying a shipped sibling inherits every page-level decision already made and reviewed.

Failure mode: Built /admin/join-link with hand-rolled Tailwind layout (max-w-3xl, custom padding, custom input classes) instead of copying the container and control classes from an existing admin page. Result: the page header collided with the fixed top nav so the title was unreadable, and the form controls were oversized versus OTP's 32px control scale. Also picked $50 as the default starting credit without asking; David wants $25.

Scope: agent:Claude

When promoting any OTP Labs feature from beta to live, do THREE things, not one: (1) flip `status` in src/shared/lab-features.ts; (2) grep src/views for the feature's `surfaceUrl` -- if the ONLY link is the Labs-injected rail item, add a permanent entry to layouts/main.ejs in BOTH the `_sbItems` array and the mobile settings menu; (3) grep the page for stale "this is a Labs feature" banner copy pointing at a /settings/labs toggle that graduation just removed. Also verify any second, independent gate (e.g. an env check like recall-calendar.ts calendarIntegrationEnabled) and make the registry copy match what is actually configured in production -- check `railway variables --kv` rather than trusting the existing description.

Why: Graduation looks like a one-line status change and is not. The rail item, the page's own Labs banner, and any env-based second gate all key off the old state, so a naive flip can make a feature LESS reachable than it was in beta while appearing to ship it. Confirmed live: PR #437 shipped the flag plus the nav entry together, and the promoted page rendered correctly with the Calendar section visible and no Labs opt-in.

Failure mode: SUCCESS: Claude caught that graduating an OTP Labs feature from `beta` to `live` silently DELETES its left-rail nav item, which would have shipped calendar auto-join into being unreachable. `getOrgLabNavItems` (src/services/lab-features.ts) filters on `f.status === 'beta'`, so only beta features get a rail item injected. /settings/meeting-presence had no other link anywhere in src/views, so flipping the flag alone would have removed the only way to navigate to it.

Scope: agent:Claude

Four reusable rules for /coach-report and any Dash run. (1) When `meta-ads.sh token-check` returns Valid:False, do not report the portfolio as quiet: the CCM Stats sheet "Ad Spend" column carries the Meta-side spend for every call-centre project, so it is a working fallback for spend and leads. Label the source on the card. (2) `mcp__google-workspace__get_events` silently caps at max_results and truncates the NEWEST events, not the oldest. A 90-day pull capped at 250 returned nothing after Jun 30 and would have reported "no client meetings in July." Always check the max date in the response against time_max and re-pull in narrower windows. (3) Never average Google cost-per-conversion together with CCM cost-per-booked-appointment in a franchise network benchmark. Group the cost metric by source, keep only the largest comparable group, suppress the table when fewer than 2 comparable peers, and name the metric explicitly on the card. (4) When CCM shows appointments booked but zero shows, that is unconfirmed data, not a zero show rate. Do not report show rate; ask for confirmation instead.

Why: Each of these silently produces a confident wrong number in a client-facing artifact. The calendar cap fabricates a churn signal, the mixed-metric average makes a healthy location look 60x worse than a peer, and a missing Meta token makes a $136K/month portfolio look dead. Cards go to clients, so a wrong number costs trust directly.

Failure mode: SUCCESS: Dash /coach-report 2026-08-03 — shipped 50 cards with Meta Ads fully down, and caught two silent data traps that would have produced wrong client-facing numbers.

Scope: agent:Dash

Refines the CCM-fallback rule captured in L125. The CCM "Ad Spend" column matches Meta actuals closely (Rockstars Frisco $453.23 vs $452.54, Okeechobee $150.07 vs $151.09, China Grove $384.79 vs $388.21) but ONLY when the sheet has a complete row for every day in the window. WOA Winder read $133.98 against Meta's $303.08 because the project stopped appearing in the sheet after Jul 30. So: before using CCM as a Meta proxy, count the daily rows per project across the window and flag any project with fewer rows than days. A project that silently drops out of the sheet reads as a spend and lead collapse when it is a recording gap. Second lesson: do not attribute a lead decline to an ad-platform outage without checking delivery. Meta REPORTING was dark to us from Jul 27, but Meta DELIVERY was fine (portfolio leads only -9% week over week, spend flat), so the much larger per-project CCM declines were a recording or routing artefact, not an ad problem.

Why: The fallback is genuinely good enough to save a report, but only with the completeness check. Without it, a project that falls out of the sheet produces a fabricated churn signal that a coach would take to a client. And blaming a visible outage for an invisible decline is the easy wrong answer that stops the real investigation.

Failure mode: SUCCESS: Dash — Meta token restored 2026-08-03, and the CCM fallback used during the outage was measured against real Meta data once it came back. The fallback was accurate to within 1% on 3 of 4 spot-checked projects but understated WOA Winder by 56%.

Scope: agent:Dash

Before calling a project's disappearance from the CCM sheet a data gap, check whether the client changed services. A project that stops appearing is at least as likely to have been offboarded from the call centre as it is to be a logging failure, and the two lead to opposite actions: one is an internal data fix, the other is a client card that should lose its CALL CENTER badge entirely. Maintain an explicit ads-only list so these clients never get dial-volume coaching, show-rate recommendations, or lead-decline flags derived from absent call-centre rows. Ads-only as of 2026-08-03: WOA Winder, WOA Flowery Branch. Ask David rather than infer when a project vanishes.

Why: Flagging an ads-only client for a call-centre lead collapse is a wrong number in a client-facing artifact, and it also sends a coach into a conversation about a service the client deliberately cancelled. It supersedes the WOA Winder example used in L126, which cited that project as evidence of a CCM recording gap.

Failure mode: Dash inferred that WOA Winder and WOA Flowery Branch disappearing from the CCM sheet after Jul 30 was a data recording gap, and flagged both as lead declines. David corrected: both clients discontinued the call centre and are running ads only. The rows stopped because the service stopped.

Scope: agent:Dash

Treat absent data and zero data as different states, never the same one. Any agent reading an external source (ad platform, CRM sheet, rank tracker, API key) must assert freshness and report source-unavailable rather than emitting 0. For the four load-bearing sources (Meta, Google, CCM, Search Atlas) prefer deleting the failure mode over monitoring it: a Meta System User token never expires, so it cannot silently die. Where the failure mode cannot be deleted, the heartbeat must fire on silence, not on a bad value.

Why: Silence produces confident wrong numbers instead of visible errors. A week of Meta data was missing from every client conversation with no alert firing, and clients whose delivery was actually healthy got flagged as dropping. Monitoring more sources does not fix it, because the mechanisms differ (a 60-day clock, consumption exhaustion, an upstream human process). Distinguishing unknown from zero is the one rule that covers all three.

Failure mode: Six failures surfaced in one week (Meta token expired 7 days unnoticed, Search Atlas quota exhausted, CCM stopped recording two WOA locations, three scorecard tiles never carrying a value, an empty IDS board, a milestone slipping) and every one was found by accident, not reported. Agents rendered a silent or absent source as a legitimate zero, so a dead pipe and a real result looked identical on the board. A portfolio-wide alarm claiming 15 call-centre projects dropped 20 percent was a false positive caused by exactly this.

Scope: agent:Dan

Upload the coach report to Drive exactly ONCE per run, at the very end, after the validation sweep passes. Never upload an intermediate build, even when the intent is to re-upload a better one later, because the shared folder is read by coaches the moment a file lands. If a rebuild is genuinely needed after an upload, trash the superseded file in the same action rather than leaving both. Use update_drive_file with trashed=true (recoverable); neither Drive MCP exposes a hard delete. Verify by file size against what was generated locally before trashing anything, and get David's approval first since the folder is shared.

Why: A shared folder is a publishing channel, not a working directory. Every extra file is an opportunity for a coach to open the wrong numbers and take them to a client. The same duplicate pattern already exists on 2026-07-11, 2026-05-25, 2026-04-06 and 2026-03-10, so this is a recurring habit rather than a one-off.

Failure mode: Dash uploaded three files to the shared Coach Reports Drive folder in one morning, as the data improved from Meta-blind to full to corrected. Zeynep has reader access, so two of the three were coaches' paths to stale client numbers until David approved trashing them.

Scope: agent:Dash

Never read a green tile as evidence that the agent named on it is alive. Decoupling a KPI from its agent protects the number but removes the number's ability to report the agent's death, so agent liveness needs its own signal: check the shared-state file mtime alongside the tile before making any seat decision. When a seat review comes up, present tile value and agent liveness as two separate lines, never one.

Why: A seat can look healthy and be vacant. Here the 32.6% measured Erica and Amanda's human performance, not agent output, so the tile would have argued against repurposing a seat that had already stopped running. Seat decisions made on decoupled tiles are made on the wrong evidence, and the error is invisible because the metric is genuinely accurate about the thing it actually measures.

Failure mode: Dan argued in the 8/3 meeting that Arin's 32.6% appointment rate showed the Arin seat was working, so repurposing it was not urgent. That inference was wrong. The Arin KPI was deliberately decoupled from Arin-the-agent in June (source kind composio_action, reading the CCM sheet directly) so it would survive a repurpose. Meanwhile arin-latest.md had been stale for 287 hours, about 12 days. The agent was dark and its tile was green the entire time.

Scope: agent:Dan

Never treat a shared-state file mtime as proof an agent is alive OR dead until you have confirmed which command actually writes that file and whether that command is the one in use. Before any seat or retirement recommendation, grep the orchestrators (good-morning, briefing, standup) for both the agent's invocation AND its state-file write, because those are frequently different paths. A staleness check answers "when did the writing path last run", never "is this seat working". Ask the human who uses the agent daily before proposing to retire it.

Why: This nearly retired a working seat. The same run also proved the opposite error is real, since a decoupled KPI stayed green while telling you nothing about the agent, so neither the tile nor the file is a liveness signal on its own. The deeper pattern across the whole 8/3 meeting is one error repeated: reading a proxy (a page-1 API response, a status field, a file mtime) and reporting it as the underlying truth without verifying the proxy actually tracks the thing being claimed. Cheap to check, expensive to get wrong, and it cost credibility three times in a single meeting.

Failure mode: CORRECTS L130. Dan told David the Arin seat was effectively vacant, 12 days dark, because arin-latest.md was 287 hours stale, and recommended retiring or repurposing the seat on that basis. The claim was false. Arin runs every day inside /good-morning Phase D-CCM, and it surfaced the WOA Aiken lead gap that became the main IDS item of the 8/3 meeting. The stale file was never written by the good-morning path at all; only the heavier /briefing path writes arin-latest.md. The mtime measured the last /briefing run, not the agent.

Scope: agent:Dan

Never describe an API-derived board, list, or count as complete. Say "N visible to me" rather than "N open", because private items are structurally invisible and their absence is undetectable from the API alone. When a count matters, or when a human's screen disagrees with yours, ask them to read their view or open the rendered page yourself. Any KPI sourced from an agent API query of issues silently undercounts by the private set and can never self-correct.

Why: This is a designed privacy boundary, not a defect, so it will never be fixed and must be worked around permanently. The danger is that it is invisible in exactly the way the rest of the day's failures were: the API returns a confident number with no signal that anything was withheld. An agent reporting "the board is clear" can be wrong while a human looks at three open items, including sensitive ones like team capacity and hiring, which are precisely the issues an agent should never assume away.

Failure mode: Dan reported an OTP issue count from the API and stated it as the board's true state. It was not. Confirmed on 2026-08-03 by loading the rendered admin view: three issues marked private appear on David's screen and are returned by no agent API call at all. The API applies issueVisibilityForSeats(resolveViewerSeatIds(request, org)), and an API key resolves to zero seats, so it fails closed to noPrivateIssues(). The agent-visible board is a strict SUBSET of the human board.

Scope: agent:Dan

Two rules. First: before building any client-meeting prep, restate the meeting's purpose in one line and get it confirmed. A meeting with an open money dispute in the background is not necessarily a meeting about the money. Prep the agenda the user is actually running, not the most dramatic thread in the source material. Second: never state a person's employment status as fact from a conversational fragment. "She's gone", "she left", "before she left" are ambiguous between leave, a meeting exit, and departure. Quote it, cite the source, mark it unverified, and check it against anything the user said in the same conversation before contradicting them.

Why: The wrong axis burned a full research pass hours before a client call and would have had David open with a credit apology when what he needed was launch confirmations. The Daria error is worse in kind: an unverified claim about a real person's employment, stated flatly, that David could have repeated to the client. Sensitive personnel facts need a higher evidence bar than campaign metrics, not a lower one, and the user contradicting you inside the same message is a hard stop signal.

Failure mode: Dan built the entire GLS 4pm prep brief around the ad-spend credit and a defend-against-criticism posture, when David's actual purpose for the call was an operational readiness check: are the ads set up correctly, is creative approval on the ad text moving so Meta can launch by Wednesday, and is Tag Manager confirmed on the landing pages. The credit was already being handled separately with Kristin on Thursday. Dan also asserted as fact that Daria Whitaker no longer works at GLS, based on an ambiguous two-word fragment in a meeting transcript ("she's gone"), even though David's own prompt in the same conversation said Daria had just got back and was asking questions.

Scope: agent:Dan

Before escalating any data problem to a vendor, query the vendor's live API for the object in question and reconcile it against our own source of truth. Here the API showed the project had held exactly 8 keywords since creation (first_keyword_added_at), so nothing was ever lost, and our own cluster map defined 28 pillars rather than the 43 the KPI asserted. The genuine vendor issue turned out to be a different and much larger one: 19 of 27 projects silently blocked on NO_QUOTA, including six client projects. Split the ticket: send the vendor only what the vendor actually owns.

Why: A false claim to a vendor costs credibility and burns the support cycle you need for the real issue. It also hides the internal defect behind a vendor excuse, so it never gets fixed. In this case verifying first both protected the vendor relationship and surfaced a client-delivery problem nobody had noticed.

Failure mode: An item routed to a vendor (Search Atlas) as "the vendor dropped our 43 tracked keywords to 8" was accepted at face value from an L10 without checking live vendor state first. Sending it would have been a false data-loss claim against the vendor.

Scope: agent:Beacon

When a measurement pipeline is broken, check whether the metric itself is the defect before repairing the plumbing. Beacon's KPI was "pillar keywords in top 10 (of 43)" on a domain whose pillar pages had launched six weeks earlier. That number reads 0 for quarters regardless of whether the work is excellent or abandoned, so repairing the vendor feed would have restored a tile that still said nothing. Test any KPI with two questions: can this number move within one review cycle, and if it moved would I trust what it means? Beacon failed both (its actual top-10 rankings were unrelated junk queries). The fix was to change the instrument to Google Search Console, which is free and already authorized, and the metric to pillar-cluster impressions, which moves weekly. Rename the existing tile in place via PATCH /api/v1/kpis/{id} rather than creating a new one, so the seat keeps its position and no dead tile lingers on the chart.

Why: A KPI that cannot move is not accountability, it is decoration, and it quietly consumes the attention a real metric would earn. This one also hid a genuine finding for six weeks: the pages were being surfaced 3,479 times and earning one click, which is a titles and intent problem no top-10 counter would ever reveal. For OTP specifically this is a Constitution matter, since the axiom is that an org reconciles what it says with what it does; running a fake KPI on OTP's own chart dogfoods the disease the product exists to cure.

Failure mode: SUCCESS: Beacon rewired from a vendor-dependent KPI that had never once produced a real number to a free first-party one that works.

Scope: agent:Beacon

After editing any .ejs or CSS in otp-platform, run `node scripts/design-lint.mjs` as well as tsc/tests/smoke:render. It has no npm script, so the standard local verify passes while CI's lint-and-type-check job fails. It counts DESIGN.md violations per file against scripts/design-lint-baseline.json and fails on any increase. When it fires, fold the new selector into the existing rule instead of running --update on the baseline.

Why: A view change can look fully verified locally and still red CI, costing a full round trip. On PR #459 a focus ring (not a resting shadow) tripped css-resting-shadow 6 -> 7; folding the picker into the existing input and focus rules fixed it and was what DESIGN.md wanted anyway, so the gate caught real design debt rather than noise.

Failure mode: SUCCESS: Claude found the otp-platform verify recipe is incomplete for any view change

Scope: agent:Claude

Never run plain `npm install <pkg>` in otp-platform. CI uses node 20 / npm 10; local npm 11 prunes optional deps that do not match the current platform when it rewrites the lock. Regenerate in a clean temp dir with the CI major: copy package.json + package-lock.json out, run `npx -y npm@10 install --package-lock-only --ignore-scripts`, copy the lock back. Verify the diff is insertions only and the @esbuild entry count stays at 300.

Why: The failure is invisible locally: tsc, the full test suite and the audit gate all pass, because the pruned packages are binaries for platforms this machine never installs. It only surfaces in CI, and it fails at install time so no test output points at the cause. Costs a full CI round trip per attempt.

Failure mode: Adding an npm dependency to otp-platform with the local npm (11.x) silently stripped 78 cross-platform optional @esbuild entries from package-lock.json, and CI died on `npm ci` with "Missing: @esbuild/win32-x64 from lock file" before running any test

Scope: agent:Claude

A bounce is never proof an account is fake. Before deleting any account, check three things: (1) does an auth-provider user exist, (2) when did they last sign in, (3) what data and pending invites hang off them. Then read the bounce SHAPE: a hard bounce in ~3 seconds means the domain or mailbox does not resolve, which usually points to a typo in an otherwise real address; a bounce 12-14 hours after send is a soft bounce from retry exhaustion (full mailbox, suspended account, reputation deferral) and the person is real. Report the split and get explicit confirmation before deleting anything that is not provably fake.

Why: Bounces cluster on real customers with mistyped addresses, not on fabricated signups. A bad email is a recoverable lead: One Jump's owner mistyped a subdomain and became unreachable for seven weeks, while the colleague he invited was reachable at the correct corporate domain the whole time. Treating "bounced" as "fake" deletes paying-customer-shaped signups and destroys the only evidence needed to win them back. Deletion is irreversible; suppression achieves the actual goal (stop the bouncing) at zero cost.

Failure mode: SUCCESS: Claude caught that a "delete these fake bounced accounts" request included a live customer org. Of three addresses flagged as fake, only one was: test@abctest.com had no Clerk user at all. business@mail.onejumpinc.com was Jessup Jong, owner of the live "One Jump" org, last signed in 3 weeks earlier, with a chart, team, meeting, and a pending invite to a colleague expiring in 5 days. Deleting as asked would have destroyed a real signup mid-onboarding, irreversibly.

Scope: agent:Claude

Treat the branch as hostile state in a shared checkout. Stage explicit paths instead of `git add -A` (it sweeps the other session's edits into your commit). Always pass `gh pr create --head <your-branch>` rather than relying on the current branch. Re-read `git branch --show-current` immediately before push and before create, and guard the push on it. Before `gh pr merge N`, confirm `gh pr view N --json headRefName` is your branch. If it already happened, the commit survives in `git reflog` — cherry-pick it onto a fresh branch off main.

Why: Checking the branch before COMMITTING is not sufficient, which is the intuitive precaution and the one the handoff note called for. The dangerous window is between push and PR creation, and both `gh pr create` and `git add -A` silently use ambient state. The failure is invisible until after the merge, and by then it has published somebody else's in-flight work under your description.

Failure mode: In the shared ~/otp-platform checkout, another Claude session switched HEAD between my `git push` and my `gh pr create`, so the PR was opened against THEIR branch carrying MY title and body. Merging it put ~600 lines of their unrelated email-suppression work onto main under a misleading commit message, auto-closed their PR #465, and left my own fix unmerged.

Scope: agent:Claude

Read the actual header row of Project Stats (A1:K1) before computing any CCM number, every run. The real mapping is C=New Leads, D=Outbound Dials, E=Pickups (40s+), F=Conversations (2min+), G=Booked Appointments, H=Call Back Requests Booked, I=Appts To Take Place, J=Shows, K=No Shows. Project Stats has a New Leads column that Agent Stats does not, so Booked sits at G in Project Stats but F in Agent Stats. Never carry a column mapping forward from a prior run's state file. Cross-validate the project total against Amanda's Agent Stats booked figure on a weekend day, when Erica is off and the two must agree.

Why: A column-offset error silently changes the headline KPI by 5x in either direction, and it reproduces itself because each run trusts the prior run's cached mapping rather than the sheet. It drove a wrong number into a message sent to the human calling team, which is the one place a fabricated metric does real damage to trust. Headers are cheap to read and are the only authority.

Failure mode: Arin/good-morning read the CCM Project Stats booked-appointments figure from the wrong column two runs in a row. The 8/3 run's cached state note claimed "C=leads D=dials F=booked" and the 8/4 run first used E (Pickups), reporting a 55% appointment rate, then "corrected" to F (Conversations), reporting 7.8%. Both were wrong. The 8/3 recap posted to #cc-5-general-agents carried at least one bad per-project number as a result.

Scope: agent:Arin

Before reporting any failure found in a log file, check whether the fix already landed: compare the failing log's mtime against the mtime of the script, config, or plist that would have to change to fix it. If the candidate fix file is newer than the failure, the failure is historical. Report it as "failed on DATE, fix landed after, unverified until the next scheduled run" rather than as a live incident. This applies to any periodic job, because a failing log stays the newest log until the job's next scheduled run, which for a weekly job means the stale alarm repeats for up to seven days.

Why: A stale alarm repeated daily is worse than no alarm. It burns the operator's attention on solved problems and trains them to discount the exact monitoring built to catch silent failures, which is how the original silent failure survives the next time it happens. Log contents alone say what happened; only timestamps say whether it is still true.

Failure mode: The 8/4 morning briefing reported "rankings-check job is DEAD and reporting success" as a live, new problem needing 10 minutes of David's attention. It had already been fixed the previous afternoon: run-claude.sh was patched at 2026-08-03 13:53 and the failing log was from 09:07 that same morning, roughly 4.5 hours earlier. The briefing read the log contents and never compared the log's timestamp against the mtime of the file that would contain the fix. David then spent a work block on an already-solved problem.

Scope: agent:Radar

Never write a file that other processes read with open(path,'w') plus write. Write to a temp file in the SAME directory via tempfile.mkstemp, then os.replace(), which is atomic on POSIX so readers see the old file or the new one and never a half-written one. Wrap it so the temp file is unlinked if the write throws. When you find one writer of a shared file doing this, grep for every other writer of the same file and fix them all; fixing one leaves the race intact. Verify with a concurrency test that reproduces the failure on the old code and shows zero on the new, rather than assuming. Note that mkstemp yields 0600, which tightens a credential file from the usual 0644 and is an improvement.

Why: A truncate-then-write race on a shared credential file is invisible in normal use and only appears under concurrency, so it presents as a flaky, unreproducible alarm on a load-bearing data source. That trains the operator to dismiss the monitoring. Worse, the failure mode is indistinguishable from a genuinely revoked token, so the real alarm and the false one look identical. Atomic replace removes the entire class of failure at the source rather than papering over it with retries.

Failure mode: SUCCESS: Radar traced an intermittent phantom "Google Ads token invalid" alarm to a non-atomic credential write, not to the token or the network. Three separate processes write ~/.claude/mcp-google-ads/google_ads_token.json (google-ads.sh, google_ads_server.py, auth_setup.py) and all three used open(path,'w') followed by write. That truncates the file first, so any concurrent reader json.load()s a partial document and throws. Because get_access_token ends in 2>/dev/null, the exception surfaced as an empty token and got reported as a dead credential. A hammer test measured 178 partial reads out of 400 writes, a 44% failure rate under contention.

Scope: agent:Radar

Preflight the window with the SAME function the sender calls, never a documented helper that merely looks equivalent. For Swamp that means printing windowEntries from buildOllieWeekly({now, days}), not getRecentEntries(days). Sweep several values of days and read which dates appear, so an off-by-one is visible rather than assumed. Then, before any approval gate on outbound email, send a single real copy to the approver using the --to= override, after confirming a dry run with that flag resolves to exactly one recipient. Only then present the gate. Also verify what actually RENDERS, not just what is in the window: this engine caps the haul and silently overflows the remainder to the website, so entry count and card count are different numbers.

Why: A gate on an email nobody has seen rendered is not a gate, it is a rubber stamp with extra steps. And a preflight helper that diverges from the production path produces confident, precisely wrong advice: it nearly caused the opposite of the intended send twice in one run, first by dropping the held wave entirely and then by burying seven of nine held entries under a render cap. The only trustworthy preflight is the code path that actually ships.

Failure mode: Two failures in the same Swamp run. (1) I preflighted the send window with the skill's documented helper getRecentEntries(N) and told David the hold note's --days=9 was wrong and --days=8 was correct. It was the reverse: getRecentEntries uses a different cutoff than buildOllieWeekly, the function the sender actually ships from. At days=8 the helper showed 18 entries while the sender returned only 9 and silently dropped the entire nine-entry wave deliberately held back for a week. (2) I ran the approval gate and asked David to authorize a 62-recipient broadcast without ever sending him a rendered copy. He had to ask "did you send dsteel@sneeze.it a copy to review?" The dry run only writes a local HTML file; it mails nobody.

Scope: agent:Swamp

Before repainting any utility class in a view, grep it in src/styles for an !important clamp selector and move that hook in the same commit. Verify repaints with a pixel diff against a before-screenshot, never on a green lint run alone.

Why: A clamp keyed on a class name is an invisible coupling no test or linter can see, and cleaning up that class name is exactly the change that breaks it.

Failure mode: SUCCESS: Claude found OTP dashboard-daily hairline-row grammar was produced by an !important clamp in input.css keyed on the row wash class name. Repainting that class onto tokens silently detached every row from the clamp, restoring borders and radius and shifting padding. Tests and design-lint both stayed green.

Scope: agent:Claude

Audit outbound email against the email_deliveries table and the sender code paths, never against one person's inbox. If you use an inbox at all, check that address against the suppression list first.

Why: Suppression makes a single inbox a biased sample that always points toward "we send nothing", producing the wrong fix: add more sends. Real baseline was 318 sends to 72 people in 9 days at a 4.7 percent bounce rate, where deliverability and cadence caps come first.

Failure mode: A member-communication audit used David's Gmail inbox as its instrument and concluded OTP sends almost no proactive member email. Wrong by construction: the nudge engine hard-suppresses any dsteel@ address and the whole sneeze.it domain, so his inbox saw 5 of 318 real sends. The audit missed the live 90-day lifecycle series and the live re-engagement engine entirely.

Scope: agent:Conatus

For the Sneeze It AGENCY lane, outreach is account-based, not volume-based. The outreach that produced actual revenue (Beem, now a multi-location client) was individually researched and drafted into David's Gmail, one account at a time. Build the big list for SELECTION, not for sending: a master Google Sheet where every row carries enough context to be decidable in ten seconds, David marks an X on the rows he approves, and each approved account then gets real research and a bespoke Gmail draft. GHL becomes the record of the resulting deal, not the send engine. Do not templatize, do not sequence, do not meter.

Why: Sneeze It accounts are worth $44k to $136k a year each (HiTone is 8 locations at $5,472/mo; WOA is 13 club accounts at ~$136K/yr expansion). At that account value, thirty minutes of research per email is trivially correct economics, and 500 templated sends optimize the wrong variable entirely. The data agrees: 221 contacts sit parked at MQL against 11 that ever advanced, and the templated 19-contact batch sent 7/27 produced nothing measurable in nine days, while bespoke research-led outreach produced a real client. IMPORTANT SCOPE NOTE: this INVERTS the existing learning that says default to a multi-touch sequence rather than hand-personalized copy. That rule was derived from OTP coach outreach at list scale and remains correct there. It does NOT transfer to Sneeze It agency prospecting, where the ICP is small (roughly 800 franchisors) and each account is large. Check which lane you are in before choosing the artifact shape.

Failure mode: I diagnosed the Sneeze It cold-outreach problem as insufficient volume and proposed waves of 500 templated emails metered out through GHL at 25/day. I was optimizing for throughput when the evidence in front of me said throughput is exactly what has never worked.

Scope: agent:Sneeze-Sales

When a user reports an error on an in-product button, diff the render condition against the API's permission check before assuming a bug in the handler. Then check how WIDE the gate is: grep every call site of the permission function. If a gate guards exactly one feature while sibling actions in the same UI are open, the gate is an outlier to remove, not a policy to widen. Confirm the failure against the live DB (here: read_at still null) so you know the write actually failed rather than the UI mis-rendering. When the fix is the ABSENCE of a check, add a source-assertion test and mutation-test it by re-injecting the gate — nothing else fails when someone re-adds it.</what_to_do> <parameter name="why">Permission bugs report as "it threw an error" and look like handler bugs, but the defect is the gap between who sees an action and who may perform it. That gap is invisible in either file alone. Counting the affected seats turns one person's complaint into a sized problem, and checking the gate's other call sites is what distinguishes "loosen this one route" from "widen a role everywhere" — the second has far more blast radius and was the wrong answer here.</why> </invoke>

Why: SUCCESS: Claude — a user-reported "error clicking a button" in OTP was a permission gate mismatch, not a crash: the meeting Signals "✓ Addressed" button rendered unconditionally in headlines.ejs while the /read API gated on canIntegrate(), so 25 of Sneeze It's 86 seats (every manager/managee/member) got a 403 on a button they could always see. Kristen could not even close a Signal she had authored.

Failure mode: SUCCESS: Claude — a user-reported "error clicking a button" in OTP was a permission gate mismatch, not a crash: the meeting Signals "✓ Addressed" button rendered unconditionally in headlines.ejs while the /read API gated on canIntegrate(), so 25 of Sneeze It's 86 seats (every manager/managee/member) got a 403 on a button they could always see. Kristen could not even close a Signal she had authored.

Scope: agent:Claude

The OTP meeting bot name leads with Ollie, and the owner block is parenthesized Company first, then Person: 'Ollie Meeting Recorder - (Company / Person)'. Ollie is the product's name and comes first; the customer org outranks the individual inside the parens. When a support ticket proposes a name format, treat it as the requirement (who owns it, what it does), not as the literal string -- OTP's brand order wins.

Why: Ollie is the mascot and product identity; burying it at the end of the participant-list name subordinates the brand to the customer's org name in every external meeting the bot ever joins. Company-before-person also matches how the rest of OTP scopes identity (org, then member).

Failure mode: Built the OTP meeting bot's vendor-facing name as '<Person> / <Org> Meeting Recorder - Ollie' -- person first, org second, Ollie trailing at the end -- by following the support ticket's literal wording instead of confirming OTP's own naming order.

Scope: agent:Conatus

Do not treat an open GHL opportunity in the Sneeze It Sales Funnel as evidence of a live relationship. David confirmed 2026-08-05 it is a graveyard: 221 of 234 open opportunities are parked at MQL and have never moved a stage. Only a WON opportunity (they became a client) is a hard block. Open, lost and abandoned opportunities are just a dated touch and should fall through to the COOLING or REACTIVATION tier based on how long ago that touch was. Separately, out-of-ICP companies (equipment manufacturers like The Abs Company, food, dental) belong in a dedicated ICP-exclusion file, not in do-not-blast.md, which exists for compliance and unsubscribe obligations.

Why: Blocking on open opportunities inverted the meaning of the pipeline. A stage that nothing ever leaves is a record of who we once imported, not who we are talking to, so using it as a suppression signal removes the exact brands most worth re-approaching. Reading a dead pipeline as a live one is the same class of error as reading a capped API response as a complete one: the data is technically present but means something different from what its name suggests. Check whether records in a stage actually move before you let that stage gate behaviour.

Failure mode: The suppression builder treated any OPEN opportunity in the Sneeze It Sales Funnel as a hard block, on the assumption that an open opportunity means a live deal that must not be cold-emailed.

Scope: agent:Sneeze-Sales

David explicitly authorized DIRECT SENDING for the master-prospect-sheet lane on 2026-08-05, after I raised the risk and he reaffirmed. The human gate moved rather than disappeared: it is now the X he types in column A of the Sneeze It Master Prospect List, which is a per-company approval made before any email exists. Hard limits he set: max 30 sends per day, from dsteel@sneeze.it, one scheduled run per day, with a manual override command to run on demand. Every send stamps the sheet with sent status and date so a no-reply follow-up can fire ~30 days later. L096 is NOT repealed anywhere else: the `/sneeze-sales` GHL harvest still never applies a sequence tag and still never sends. Check which lane you are in.

Why: The reason behind L096 was never "an agent must not send" as a principle; it was that no cold email should reach a client or someone David is already talking to. A per-row human X satisfies that intent more directly than sequence enrollment did. The risk that remains is different and worth naming to a future operator: the X approves the COMPANY, not the SENTENCE, so nobody reads the email before it goes. That makes research accuracy and suppression freshness load-bearing in a way they were not when David hand-sent drafts. Rebuild the suppression list before any run, and never send to a BLOCKED domain, a bounced address, or an unsubscribe, regardless of what the sheet says.

Failure mode: Standing rules said the Sneeze It outreach agent never sends email: L096 required David to personally vet each contact and enroll them in the sequence himself, and the morning-pass floor says "prepare drafts, never fire them." Under the new sheet-driven process those rules would block the whole loop.

Scope: agent:Sneeze-Sales

In-home care and senior care FRANCHISORS are IN ICP for Sneeze It as of 2026-08-05 (David: "low target and worth a try"). The qualifying trait is a multi-location franchisor with a real lead-generation budget, not a membership billing model. Do not hold or flag them. Because David framed it as a try rather than a conviction, tag these sends so their reply rate is measurable separately from fitness instead of being blended into one number: an experiment you cannot read the result of is not an experiment. The residential end (nursing homes, assisted living facilities) is still untested and was not part of this ruling.

Why: The ICP was written as a description of existing clients, who happen to be membership gyms, and I applied it as a boundary on who could ever be a client. Those are different things. What Sneeze It actually sells is paid lead generation plus a call center that works the leads fast, and any franchisor buying leads for local operators has that problem regardless of how they bill their customers. Watch for this shape generally: an ICP inferred from the current book will keep reproducing the current book, and the operator is usually the one who can see past it.

Failure mode: I flagged seven in-home care franchisors (Home Instead, Assisting Hands, Always Best Care, Comfort Keepers, Senior Helpers, Synergy HomeCare, FirstLight) as out of ICP and held them from sending, reading the Sneeze It ICP as membership-model fitness and wellness only and treating the inherited Nick-era "senior living" exclusion as covering them.

Scope: agent:Sneeze-Sales

When a resource has an access rule on its primary page, extract that rule into ONE shared helper (canReadMeeting in services/meeting-read-access.ts) and apply it at every read surface, list AND single-row, instead of letting each endpoint hand-roll a partial check. Also: Ollie chat executes tools via app.inject with the user's own session (makeSessionOtpFetch), so fixing the HTTP endpoints automatically scopes Ollie's chat answers — no separate AI-context fix needed. Org-API-key callers carry no member row and stay org-wide by design.

Why: Access-control drift is a leak class, not a one-off: every new read surface (followups, exports, recordings, captures panel) shipped without the team gate because the rule lived inline in one page handler. A single source of truth makes the next surface safe by default, and knowing Ollie chat rides the user's session means endpoint-level authz is the one place to fix AI data exposure too.

Failure mode: SUCCESS: Conatus — root-caused critical R3V ticket 45f74cff (users could open any meeting): /l8/meeting/:id had a team/attendee/creator gate for months, but the followups page, all per-meeting read APIs (transcript, exports, recordings, agenda, headlines, share, SSE), and the meeting-captures panel only checked the 'restricted' flag — the gate existed but was never shared.

Scope: agent:Conatus

Adding a scheduled command to run-claude.sh takes THREE edits, not one: (1) APPROVED_COMMANDS, (2) a BUDGET case entry, (3) a RESOLVED_PROMPT case entry that expands the slash command into a literal instruction. The file contains SEVERAL separate `case "$PROMPT" in` blocks, so never anchor an insert on a command name alone; anchor on something unique to the target block (for the resolver, the line `RESOLVED_PROMPT="$PROMPT"` immediately above its `case`). Verify by extracting the resolver block and running it with the prompt as input, rather than by reading the diff: after the edit, `/outreach` must echo a real instruction string, and at least two pre-existing commands must still resolve to prove nothing was clobbered. `bash -n` passing proves only syntax, not that the edit landed in the right block.

Why: Both errors share a shape: a change that looks complete because the part you touched is correct, while the part you did not know about is untouched. The whitelist edit read as done because the command appeared in the file. The anchored insert read as done because the diff showed the right text. Neither was checked against behaviour. The saving grace was that run-claude.sh fails LOUD on an unresolved command, writing FATAL to the run log and an entry to alerts.log, so the job did nothing and said so rather than reporting success. That is the pattern worth copying into every scheduled job: an unconfigured job must be distinguishable from an idle one.

Failure mode: I added /outreach to APPROVED_COMMANDS in run-claude.sh and declared the scheduled job ready. It fired at 10:12 on 2026-08-06 and did nothing: approving a command is only half the wiring, and headless bare mode cannot resolve a slash command from the commands directory. Then, fixing it, I anchored the insert on the string ' "/otp-sales")' and landed the resolver inside the BUDGET case statement instead of the RESOLVED_PROMPT one, which would have left the original bug in place while also giving the job no budget entry.

Scope: agent:Sneeze-Sales

Never silently terminate a session a human is actively using. Warn first and ask: surface a "Do you still need more time?" prompt before the deadline and extend on any response. Reserve automatic closing for sessions that are genuinely abandoned (no participant, no activity), never for ones that are merely long. Timers should clean up abandoned state, not time-box live work.

Why: The auto-end net was built to stop forgotten meetings from lingering open forever. That is a real problem, but elapsed time is the wrong proxy for abandonment: an active meeting and a forgotten one look identical to a clock. Using the clock alone means the safety net's failure mode lands on the people doing the work, and the product loses trust in the exact moment it is being dogfooded.

Failure mode: OTP auto-closed a live leadership meeting at a hardcoded 60-minute deadline with no warning, while people were actively in it. The proposed fix was to make the timer smarter (derive the window from a duration column). Both the original behavior and that fix are wrong: any silent auto-close of a live meeting is a bad experience. David: "this auto close is not a good thing, it has people saying WTF."

Scope: agent:Radar

A blocker on one item never blocks the others. Work every item that can be worked, exhaust every avenue on the ones that cannot, and only then report. Park the genuinely undecidable ones and keep going. A question for David is fine and should be raised, but it is raised ALONGSIDE completed work, never instead of it. Concretely for any queue-processing run: partition the queue into workable and blocked at the start, finish the workable set completely, and treat "I found a bug in my own tooling" as work to do inside the same run rather than a finding to report at the end of it.

Why: David's scarcest resource is his attention, and a report that says "here is why nothing happened" spends it without buying anything. The blockers were real but they applied to 2 of 12 rows; I let them set the pace for all 12. The deeper error is that stopping felt like diligence: I had genuinely found real problems, so surfacing them felt like the responsible act. It was not, because surfacing a problem is only half the job when the other ten items were sitting there workable the whole time. Exhaust the possible before you escalate the impossible.

Failure mode: The outreach run hit two items needing David's ruling (Powerhouse Gym, Fastest Labs) and a bug of mine blocking three more, and I reported all of it and stopped. Nine rows sat unsent while I wrote a summary. Worse, I had Clay-verified addresses for two of those companies (Annie Long at Senior Helpers, Jennifer Chasteen at Synergy HomeCare) already in hand from the previous session and did not use them. I presented blockers as a reason the batch could not proceed, when they were only reasons those specific items could not proceed.

Scope: agent:Sneeze-Sales

"Exhausted" means every avenue is closed, not that the first tool came back empty. Three specific rules from David 2026-08-06: (1) A local operator or GM is a legitimate route IN, not a disqualification. If they respond they can move you up the ladder to corporate, which is a better introduction than a cold email to corporate ever is. Do not disqualify a row because the contact you found is below the ICP's stated altitude. (2) When a brand's specific location has no contacts, look laterally across the SAME BRAND: other locations, other franchisees, the franchisor itself. A dead domain is not a dead brand. (3) When Clay has no email, go to the open web: the company's own site, LinkedIn, press releases, local news. Clay is the first tool, not the only one, and an empty Clay result is a prompt to search harder rather than a verdict.

Why: This is the same failure as L155 one level down. There I stopped the batch on a blocker; here I stopped individual rows on the first empty tool response. Both times "exhausted" was really "the cheap path did not work." The cost is asymmetric and worth internalising: an extra ten minutes of searching costs almost nothing, while a wrongly-abandoned row costs an account worth $50k to $500k a year in this ICP. David has now corrected the same underlying instinct three times in one day (L155, this, and the earlier stop-and-report), which means it is a disposition rather than an incident. When about to write "exhausted", "no path", or "needs research", treat that as a signal to try two more angles first, and record which angles were actually tried so the claim is auditable.

Failure mode: I marked four outreach rows "exhausted" that were not. Max Fitness Augusta: I disqualified it as "a one-location operator, not a franchisor, wrong ICP shape" and sent nothing. Class UFC Gym San Antonio: Clay returned no contacts at classufcgym.com so I stopped, without ever looking at other UFC Gym locations or franchisees in the same brand. LifeBridge: I said the one unblocked address was unverifiable and quit, without web-searching the person at all. Always Best Care: Clay returned no email for the CMO and I stopped there too.

Scope: agent:Sneeze-Sales

When David asks for a report he can distribute, assume the audience is internal leadership, not the people being measured. Per-agent performance comparisons belong in that document at full detail with no warning attached. Do not volunteer to redact, soften, or produce a second sanitized version of performance data unless David names an external or team-wide audience. If the audience would genuinely change the content, ask which audience up front before building, never as a caveat appended at the end.

Why: Manager-level reporting exists to name who is converting and who is not. Attaching a sensitivity warning to that treats normal management reporting as a risk, and hands David an extra decision he did not ask for while he is trying to walk into a meeting. It also spends the final impression of the deliverable on a hypothetical instead of the findings. General shape: resolve audience before writing, not after.

Failure mode: Arin built the 14-day call center review Google Doc for David, then closed by flagging the Amanda vs Erica per-caller comparison as sensitive and offering to cut a sanitized second version before distribution. David corrected: the doc is internal and was never going to the call team. Both the hedge and the offer of a redacted variant were wasted.

Scope: agent:Arin

A franchisee client does NOT block the franchisor, and the two are different companies on different domains (powerhousegymbridgeport.com vs powerhousegym.com). David 2026-08-06: "we do powerhouse bridgeport one location not corporate so if this is the corporate location good to go." Reverse the instinct entirely: an existing franchisee relationship is the strongest possible ASSET in a franchisor email, because it is proof delivered rather than claimed. Lead with it. The direction that matters is one-way: never cold-email a franchisee of a brand whose CORPORATE relationship we are mid-conversation with, and never email the specific client location, but corporate remains open and warmer than cold. Check which entity a domain actually belongs to before assuming brand-family contamination.

Why: I generalised one true fact (do not email a client) into a rule that would quietly delete the addressable market. Franchising is precisely the structure where one brand contains many independent buyers, so brand-level blocking is the wrong shape for this ICP. The asymmetry is worth remembering: blocking a franchisor to protect a franchisee costs a six-figure account and protects nothing, because the franchisee is not the one receiving the email. It also throws away the single best proof point available, which is that the brand already works with us somewhere.

Failure mode: I held Powerhouse Gym corporate (powerhousegym.com) as a policy risk because Powerhouse Gym Bridgeport/Stratford is an active Accelo client on that brand, and I proposed hard-blocking any brand domain where an active client sits anywhere in the system. That rule would have blocked every franchisor whose franchisee we already serve, which is most of the best targets we have.

Scope: agent:Sneeze-Sales

Separate first-party link tracking from email-provider tracking. A tokenized link pointing at our own domain (orgtp.com/join/sales/<token>) is fully click-trackable no matter which mailbox sent it -- the prospect's browser hits our server and we stamp it, no provider cooperation needed. Manual personal-mailbox sending costs only the steps BEFORE the click: email opens (no pixel) and bounce/delivery visibility. When someone says "it came from a personal email so we can't track it", check whether the link destination is ours before agreeing.

Why: The two are routinely conflated, and the conflation kills features that would have worked. Here it nearly closed a ticket whose core ask (who clicked, who signed up, success rate) was fully buildable. The residual limitation is real but narrow, and worth stating precisely rather than as a blanket "not trackable": a dead address renders identically to a live address that ignored you, and the mint timestamp is not the send timestamp.

Failure mode: SUCCESS: Claude -- a join-link analytics ticket was nearly dropped on the false premise that sending from a personal mailbox makes clicks untrackable.

Scope: agent:Claude

Never report a campaign as active from campaign.status alone. Join status against metrics.impressions over the reporting window and call a campaign active only when status is ENABLED and impressions are greater than zero. Report the zero-delivery ENABLED shells separately as an account hygiene item.

Why: ENABLED is a switch, not evidence of delivery. Stale campaigns left switched on inflate the apparent size of an account, and a client who reads their own account daily will spot the mismatch immediately, which costs credibility on every other number in the same document.

Failure mode: Reported "four campaigns are enabled and spending" for the GLS Google Ads account by reading campaign.status alone. Riya and Yaroslav corrected it to three. Seven campaigns actually carried ENABLED status, but four legacy ones had zero impressions and zero spend for 90 days, so status count and active count disagreed in both directions.

Scope: agent:Dash

Treat the recurring reports.sneeze.it 'Action Required / Data Source connection' emails as NOISE and suppress them entirely. Those connections go up and down by design. Never surface them in a briefing, never age them as an open flag, never ask David to decide about them.

Why: A recurring automated notice that self-resolves is not a signal. Aging it daily made a non-issue look like a 36-day-old dropped ball, which is exactly the noise the morning pass exists to remove. Age-as-signal only works if every flag on the board is genuinely unresolved; one permanent false positive degrades trust in the whole delta list.

Failure mode: Dan carried 'reports.sneeze.it Facebook Insights + LinkedIn connection failing' as an open flag for 36 consecutive days in the morning briefing, aging it up as if it were an unresolved decision, and framed it as needing a keep-or-kill call from David.

Scope: agent:Dan

When a live source has been queried this run, EVERY item reported from that source must be derived from the live response, never carried forward from the prior snapshot. Use the previous snapshot only to compute age (first_seen) and to detect what closed. Concretely for good-morning: after pulling otp-todo.sh, rebuild overdue_otp from the returned todos, then diff against yesterday's list. Anything present yesterday and absent today is RESOLVED and gets reported under the resolved list, not repeated as open.

Why: The snapshot exists to add memory, not to override live truth. Carrying it forward inverts the design and turns the delta engine into a source of false positives, which is the single most expensive failure mode for a briefing: it costs David trust in every other line on the board and makes him do verification work the pass was supposed to remove. It also silently steals credit for completed work, which is worse than merely being noisy.

Failure mode: Dan pulled David's live OTP todo list at the start of the 8/7 morning run, then built the 'overdue' section from the PREVIOUS day's good-morning-state.json snapshot instead of from the live pull sitting in the same context. Result: three items were reported to David as open and overdue when they were not in his live open list at all, including SOC 2 G1 which David had already completed. David had to correct it.

Scope: agent:Dan

Before treating an OTTO queue as work to approve, check three things: (1) autopilot_ai_settings limits, where 0 means nothing is ever generated regardless of autopilot_is_active; (2) whether pending rows actually carry a non-empty recommended_value; (3) is_active as the approval flag, since the API's status field describes the current value's condition (compliant / invalid_length) and the status query param is accepted then silently ignored. When changing autopilot settings, always read-modify-write the complete settings object, because a partial PATCH risks dropping the other issue types.

Why: Counting pending tasks as available SEO wins overstates the work by orders of magnitude and invites a blanket approve. On orgtp only 171 of 779 pending titles were genuine defects; approving all of them would have overwritten 600+ pieces of good human copy with generic AI copy, damaging the pillar pages the Beacon impressions KPI depends on. The zero-limit config also means every client site, including Workout Anytime at 2,233 pages with issues, has an OTTO that has never run.

Failure mode: SUCCESS: Beacon found that OTTO's "pending task" count is not a backlog of approvable SEO fixes. On orgtp.com ~7,100 pending tasks all had an empty recommended_value, because autopilot_ai_settings carried limit 0 for every issue type on all 19 Search Atlas projects. autopilot_is_active reported true the whole time, so the config looked healthy while generating nothing.

Scope: agent:Beacon

OTTO owns metadata, including on orgtp.com which we control. Do not re-litigate the inject-vs-source architecture. Em dashes are permitted in page titles and meta descriptions when it serves SEO; the no-em-dash rule applies to human-facing prose, not metadata. Scope Search Atlas work to OTP/orgtp.com only. Do not propose enabling or fixing OTTO on other client sites: David uses Search Atlas as a tool but does not own the SEO department for clients, so client SEO is not his decision to make and should not be routed to him.

Why: Two failure modes avoided. First, an agent that keeps proposing a source-of-truth migration burns David's attention on a decision he has already made. Second, and more costly, routing client SEO findings to David puts him in a lane he does not own; the correct move on discovering something like 18 zeroed client projects or Workout Anytime's 2,233 unprocessed pages is to note it and stop, not to build him a rollout plan he has no seat to approve.

Failure mode: Beacon recommended against letting OTTO own orgtp.com's metadata, arguing that since we control the repo, titles and descriptions belong in source rather than injected client-side by the ACHOO pixel. Beacon also flagged 44 em dashes in live metadata as rule violations needing a cleanup pass, and raised switching on the 18 zeroed client OTTO projects.

Scope: agent:Beacon

Let OTTO choose page titles. Search visibility is OTTO's domain and its judgment wins there, even when the replacement reads flatter than hand-written copy. The Kennedy-discipline rule governs copy a human reads as persuasion (outreach, landing pages, email, client comms); it does not override SEO metadata. Related workflow David uses: a punchy blog title can be written to drive opens in an email, then left for OTTO to replace later, because the email's shelf life is days while the title's SEO value compounds. So a voice-heavy title being overwritten weeks later is the intended lifecycle, not a loss.

Why: Beacon was applying a persuasion-copy rule to a search-surface artifact and would have blocked the entire blog corpus (the largest page group on the site, 408 URLs) from ever being optimized. The deeper error was treating brand voice and SEO as competing for the same slot when they occupy different time horizons: the email captures arousal now, the title compounds in search later.

Failure mode: Beacon recommended preserving the existing Kennedy-voiced blog titles on orgtp.com and blocking OTTO from replacing them, arguing that "The team fails before the agent does..." becoming "COO's Role in Training Teams for AI Agent Collaboration | OTP" trades a distinctive argument for generic keyword copy, and citing the universal Kennedy-discipline rule as grounds.

Scope: agent:Beacon

When calculating any client credit or make-good on misspent budget, net out the value of what was actually delivered before proposing an amount. Formula: credit = spend under review minus (conversions delivered x a defensible cost per conversion). State which benchmark rate is used and why. Never default to crediting 100% of spend when the spend produced results.

Why: Crediting gross spend overpays the client and understates the work that did land. It also sets a precedent that any misallocation equals a full refund regardless of outcome. Netting delivered value is both fairer to Sneeze It and more defensible to the client, because it shows the math instead of a round apology number.

Failure mode: Drafted a client make-good credit at 100% of the misdirected spend ($2,501.53), treating the entire amount as a total loss. The spend was not a total loss: it delivered 6 real conversions to the client, and the draft gave that value away for free.

Scope: agent:Claude

In otp-platform, NEVER stage with `git add -A`, `git add .`, or `git commit -a`. Always stage by explicit path and verify with `git diff --cached --name-only` before committing. When multiple sessions may be working the same checkout, do not switch branches in the shared working tree at all: create an isolated `git worktree` instead, because another session's uncommitted work can be destroyed by a branch switch or reset. Before any reset in a shared tree, run `git status --porcelain --untracked-files=no` and use `--mixed`, never `--hard`.

Why: A repo with one engineer has no reviewer to ask "why does a coaching PR touch the risk register?", and no automated gate was asking either. The consequence is silent: the change is correct by every mechanical measure and wrong about what it claims to be. It is worse for compliance artifacts than for code, because the swept file becomes audit evidence with a misleading provenance. Parallel Claude sessions on one checkout make this far more likely, since each session sees the other's files as ordinary working-tree state.

Failure mode: Working-tree files belonging to one workstream were swept into an unrelated feature PR by a broad `git add`, and merged to main. PR #515 ("Let people actually talk to coaching, through Ollie") carried five SOC 2 compliance documents into main. Every CI check passed, because a swept markdown file breaks no test. This was the third occurrence in the otp-platform repo (#511 swept scratch, #512 removed it, then #515).

Scope: agent:Claude

Before touching package-lock.json, compare the local Node/npm version against CI's (grep node-version .github/workflows/ci.yml). If they differ, do not regenerate the lockfile: install the matching runtime (brew install node@20, then use /opt/homebrew/opt/node@20/bin explicitly) and run BOTH the fix and the verification under it. Under the correct npm the same npm audit fix touched 12 lines instead of 524. Also: npm audit reads the INSTALLED tree when node_modules exists, and the lockfile only under --package-lock-only, so a local "0 vulnerabilities" measured against a node_modules you already mutated proves nothing. Reproduce CI with: npm audit --omit=dev --audit-level=high --package-lock-only

Why: A lockfile's correctness is defined by the tool version that reads it, so local verification with a different major version is not evidence at all. The failure is silent and expensive: every attempt looks verified locally and fails identically in CI, costing a full CI run each round trip. Checking two version numbers first would have cost thirty seconds and saved ninety minutes plus three abandoned pull requests.

Failure mode: Spent roughly 90 minutes and three failed PRs trying to clear a red npm audit CI gate in otp-platform. Each attempt regenerated package-lock.json locally and verified it with a local npm ci that passed, yet CI rejected every one as out of sync. Root cause was checked last instead of first: CI runs Node 20 (npm 10) while the laptop runs Node 25 (npm 11), and the two dedupe the dependency tree differently. npm 11 rewrote 524 lines and collapsed vitest's nested esbuild tree; npm 10 then refused it.

Scope: agent:Claude

When changing the arity or shape of a function that other code passes a hand-rolled structural stub into, grep every caller for stubs BEFORE trusting typecheck. In otp-platform, registerOtpTools is called with `as unknown as Parameters<typeof registerOtpTools>[0]` in three places (the HTTP route, Ollie's collector in src/services/ollie-tool-registry.ts, and the parity test). That cast makes any missing method invisible to tsc: migrating otp-tools.ts from server.tool() to server.registerTool() typechecked clean while Ollie's collector, which only implemented .tool(), would have collected zero tools and removed every OTP tool from the chat box at runtime. Rule: a structural stub behind an `as unknown as` cast is an untypechecked interface. Treat it like a second implementation and update it in the same PR. Also: when two hand-maintained lists answer the same question (Ollie's WRITE_TOOLS/READ_TOOLS vs the MCP readOnlyHint/destructiveHint annotations), tie them together with a test rather than trusting them to be edited in step; ours had already drifted twice (discover_intelligence POSTs and INSERTs but was classified read, so it ran with no confirm card; sync_rules_to_file only rendered text but was classified write). Finally, verify a guard by breaking the invariant and watching it fail, not just by watching it pass.

Why: The failure mode is invisible to every automated check: tsc passes, all 3232 tests passed before the shim was fixed because the shim's own test used the same stale stub. It only surfaces as "Ollie can suddenly do nothing" in production. The generalizable form is that casts convert compile-time contracts into runtime hopes, and a codebase with structural stubs has as many implementations of an interface as it has stubs.

Failure mode: SUCCESS: Claude migrated all 56 OTP MCP tools to registerTool with directory annotations, and caught a shim that would have silently emptied Ollie's tool registry in prod.

Scope: agent:Claude

Before diagnosing an OTP support ticket, identify the exact surface the reporter was on, then verify the reported cause can even occur in that state. From the 8/7 R3V batch: (1) "reassign meeting to another team" read as a feature request but was a creation bug — the UI offers "No team (personal)" and POST /meetings silently substitutes the Leadership Team; reassignment already worked via PUT /meetings/:id. (2) "Ask Ollie can't file a ticket" was mistaken identity — OTP has TWO assistants: Ask AI (corpus-only, no tools, so its refusal was truthful) and /ollie-chat (full MCP registry, has submit_ticket). (3) A plausible cause for a typing-freeze was ruled out by a precondition check: the transcribing banner only renders when the meeting has NO transcript, and the reporter had already generated Ollie insights. Say so honestly rather than shipping a fix under a false claim.

Why: Users describe symptoms, not causes. A plausible cause that survives no precondition check produces a fix that fixes nothing while closing the ticket. Checking which surface and which state rules candidates in and out cheaply, and turns "feature request" into "bug" often enough to change what actually gets built.

Failure mode: SUCCESS: Claude — three of six R3V support tickets had root causes different from what their titles said, and only reading the actual surface found them

Scope: agent:Claude

Before designing any adoption, activation or gamification feature, query production for the funnel FIRST and count organizations rather than events. Then look for the outcome the product already produces and is only labelling wrong. Three rules that fell out and should be reused: (1) make progress steps OBSERVED FACTS re-checked on every render, never stored completion flags, so a step goes back down when its fact stops being true (a revoked key must not leave a badge behind); (2) start the ladder with a rung the user has ALREADY cleared (endowed progress) rather than at zero; (3) report the biggest ABSOLUTE drop, not the smallest number, because they are different steps -- here the largest loss was 49 orgs at signup-to-first-meeting, not the agent gap being investigated.

Why: A metric that requires a hand-written query gets checked once and then never again, which is exactly how a zero on the company's core thesis survived for months next to a dashboard that looked healthy. Counting events instead of organizations is the specific trap. And honesty is load-bearing on any adoption surface: the moment a number flatters, the whole surface is worth less than showing nothing, so no points, no badges, no streaks, and zero must render as zero.

Failure mode: SUCCESS: Claude found OTP's north-star metric was zero and nobody knew, by querying production before designing anything. 61 orgs, 12 ran a meeting, 1 ever created an agent seat, 0 agents ever called OTP. The reason it hid: /admin/usage counts ACTIONS (looks healthy, a few orgs run many meetings) while the thesis needs per-ORGANIZATION counting. The fix reused data we already had: Ollie's real work was already recorded per org in wallet_ledger.metadata->>'feature' and had only ever been rendered as billing. Read as a timesheet, the same rows prove an agent already works there.

Scope: agent:Claude

Before presenting a Dash blind-spot, billing trigger, or any state-file alert as a current action item, confirm it hasn't already been resolved. Stale state files (Dash May 25 was ~5 weeks old) carry point-in-time alerts that may be closed by now. Trust confirmed/observed status over stale notes; flag the data's age and treat unverified alerts as 'verify' not 'urgent.'

Why: Re-surfacing already-resolved alerts as urgent erodes trust in the L10 briefing and spends David's attention during a low-push recovery window. Honesty about data staleness matters more than appearing comprehensive.

Failure mode: Dan surfaced the HiTone billing trigger ($43-49K/mo possibly un-invoiced) from Dash's stale May 25 state file as a live concern during the Jun 29 L10. David confirmed HiTone billing is correct and already handled, and asked to close it out.

Scope: agent:Dan

KPIs/scorecards must live as tiles in OTP (the source of truth), not in markdown files or meeting briefs. Every active agent/human seat — including Dan's strategic co-founder seat — must own at least one OTP KPI tile. When proposing measurables, verify against list_my_kpis and create the missing tiles via update_kpi (auto-creates), rather than just tabling them in a doc. A seat with no number is sitting on the sidelines.

Why: EOS requires every seat to have a measurable. Discussing KPIs in a brief while OTP shows none of them makes the scorecard fiction and undercuts OTP as the coordination source of truth. Dan as co-founder must be measurable like everyone else.

Failure mode: Dan presented a Sneeze It agent-team scorecard as a markdown table in the L10 brief and treated it as 'the scorecard,' when the source of truth is OTP. David caught that Dan (and Arin/Pulse/Dirk) have NO KPI tiles in OTP at all — Dan's own seat had zero measurables. A scorecard that only lives in a file or meeting brief does not exist.

Scope: agent:Dan

Distinguish PENDING (source intentionally not live yet) from FAILED (source exists and errored). Mark registry entries with no live source as 'pending': true so Tally skips them quietly and never pages David; only genuine failures fire the ntfy 'high' alert. When adding a KPI whose source isn't ready, always set pending:true. tally.py now splits results into ok/pending/failed and alerts only on failed.

Why: Paging the founder for deliberately-not-yet-wired KPIs is alert noise that erodes trust in the alerting channel, especially during a recovery window where every phone buzz costs. Honest status (pending vs failed) keeps the scorecard truthful and the alerts meaningful.

Failure mode: Tally paged David with a 'high' priority phone alert ('3 KPI push failed') after Dan added Havok/Pulse/Dirk KPIs to the registry with sources that don't have data yet. Tally's alert logic counted any non-push as a failure, so intentionally-pending KPIs (blocked column, untested engine) triggered a high-priority alert.

Scope: agent:Tally

An OTP KPI with teamId=NULL renders only on /dashboard/kpis, never on any L10 scorecard (meeting scorecards filter strictly by meeting.team_id). To make a KPI show on a specific L10, PATCH /api/v1/kpis/:id with the meeting's teamId. The 'Dan L10' meetings run on the 'ai-army' team (065d1d4b-c7da-4e80-b3ed-d6b101471d2c). Tally's auto-create now includes teamId from a 'team_id' field in the registry entry, so new agent-army KPIs land on the Dan L10 automatically instead of orphaned. Find team IDs via GET /api/v1/teams; meeting->team via GET /api/v1/meetings.

Why: A KPI nobody can see on their meeting scorecard is functionally not on the scorecard. The owner/title is necessary but not sufficient — team scoping is what makes it report. This is a recurring gotcha for any agent creating KPIs via the API.

Failure mode: SUCCESS: Tally — agent KPIs were invisible on the L10 because auto-create left teamId NULL. David flagged that the new KPIs weren't reporting on the Dan L10 or /dashboard/kpis as expected.

Scope: agent:Tally

When changing an OG/share image, change the URL (new versioned filename, e.g. og-image-v3.png), do NOT swap bytes under the same filename. Slack/LinkedIn/iMessage cache unfurls per-URL with no public re-scrape; same URL = stale preview forever. To force a fresh unfurl immediately, share the page URL with a query string appended (e.g. ?v=2). Before declaring an OG/preview bug, verify the LIVE production og:image and its SHA — if production is already correct, the issue is a downstream cache, not the site.

Why: David repeatedly returns to the same dark-card complaint because byte-swaps under a stable URL look fixed in the repo but never change what cached platforms display. Versioning the URL is the only durable fix; otherwise the loop repeats every review.

Failure mode: Recurring complaint: orgtp.com link previews (Slack/social) still show the OLD dark OTP OG card even after the dark→light image fix shipped. Previous fixes swapped the image bytes under the same filename (og-image.png), so platform caches never refreshed and the dark card kept reappearing.

Scope: agent:Conatus

Root cause was the SearchAtlas OTTO pixel having an EMPTY src="" in the layout head (v7.ejs, onboarding.ejs, main.ejs). The OTTO tag must carry its base64 data-URI loader in src that appends dynamic_optimization.js with data-uuid; with src="" the runtime never loads, so OTTO injects/verifies nothing. When an OTTO/SearchAtlas audit reports 0/N across ALL on-page categories, suspect the pixel loader, not the actual tags — verify the sa-dynamic-optimization script's src is populated, not the page's own meta.

Why: A 0/16 across every category despite visibly correct meta is the signature of a non-loading optimization runtime, not missing tags. Checking the pixel first avoids a pointless rewrite of titles/descriptions that were never the problem.

Failure mode: SUCCESS: Beacon/SEO — orgtp.com OTTO on-page audit showed 0/16 (titles, meta descriptions, headings, meta keywords all failing) even though pages had perfectly good title tags and meta descriptions server-side.

Scope: agent:Beacon

A brand battle cry needs a genuinely designed moment (confident display type, intentional line breaks, brand device, real whitespace), not a centered text block plopped in. And the VISIBLE battle cry copy is the short clause only: 'Unlocking the potential in every person through the partnership of people and AI' — drop 'so together we leave the world better than we found it' from the hero display (keep the full sentence only for formal/footer contexts).

Why: A mission line is a brand centerpiece. Long copy dilutes the punch, and an undesigned drop-in reads as filler. The payoff phrase 'partnership of people and AI' must land as the climax with design weight behind it.

Failure mode: Adding the OTP mission as a 'battle cry' on the landing page, I dropped the full sentence into a plain centered text band wedged between hero and Step 1. David called it 'a weak attempt to just throw it on the page' and said the full line is too long for the visible battle cry.

Scope: agent:Conatus

Manifesto/mission pages must be written as movement recruitment, not product marketing: second-person address (the reader is the protagonist), "We believe" creed statements people can recite, a named enemy, stakes, and invitation CTAs ("Join the movement") instead of transactional ones ("Start free"). Product features appear only once, framed as how the movement fights, not what the product includes.

Why: People join movements because they believe what the movement believes (Sinek: start with why). Copy that sells the what on a page whose job is to recruit believers reads as generic SaaS and inspires no one, no matter how good the design is.

Failure mode: Redesigned the orgtp.com manifesto homepage with strong visual design but kept product-brochure copy (feature lists, "free meeting software", "Start free" CTAs). David: "the writing does not inspire an army of followers... this just looks the same as every other company... blah."

Scope: agent:Claude

Judge conversion on the full path the visitor actually walks (page, door, day-one experience), not on the surface being edited. If the honest answer to "would you sign up" is "yes IF another surface delivers," the answer is no, and the work moves to that surface. Never write a promise on a button that the destination page cannot cash.

Why: Trust destroyed at the moment of verification is unrecoverable; a skeptical buyer who clicks "watch us run" and lands on a data page is gone forever. Copy that outruns proof is hype by definition, and the exact audience OTP needs (operators) is the audience that punishes it hardest.

Failure mode: After rewriting the OTP homepage, I declared the copy converts because skeptics would "click through to the live OOS page and sign up IF it delivers." David called it: I kicked the can to a page I know does not deliver, and called it a win. The button promises "Watch our company run, live" but the OOS page it links to is a list of published rules, not a running company.

Scope: agent:Claude

OTP's enemy statement is "you bought the operating system and the needle didn't move." The pitch is not better meetings; it is: the system was fine, what was missing was the workforce that runs it between the meetings. Frame all homepage/sales copy against needle-not-moving, not against meetings.

Why: This is the buyer's actual lived disappointment (paid for an operating system, company looks the same two years later) and it positions OTP against incumbents on outcomes instead of features.

Failure mode: The letter's hero framed the enemy as "the meeting" / busywork. David corrected the thesis: the real problem is that companies bought operating systems and software (Ninety, Bloom Growth, etc.) that did not move the needle. Years later the company had not grown and was not better, and they needed to change how they did things.

Scope: agent:Claude

The calendar no-modify/no-delete rule applies to CLOSED (past) events only — the historical record is immutable. Future/upcoming events CAN be updated or cancelled when David explicitly directs it. Still confirm scope once before outward-facing changes (cancellations notify attendees).

Why: Past events are the billable-time and time-allocation audit trail, which is what the rule protects. Blocking directed changes to future events just adds friction and makes David do the work himself.

Failure mode: Dan blocked a David-directed calendar change (removing Janine from the recurring 1:1 series) by over-applying the "NO DELETE. NO UPDATE. Never modify existing events" calendar rule to all events.

Scope: agent:Dan

For any UI change, design from the user's mental model, not the data model: "my list shows my work; work I assigned to others shows under Waiting on Others." When a meeting todo is assigned to someone else, stamp the creator as delegator so it routes to the delegation view. Before shipping UI changes, run the UX lens (impeccable / web-design-guidelines skills + src/DESIGN.md), not just a minimal code patch.

Why: A technically-correct patch that ignores the user's mental model just moves the confusion. OTP's own product language already has the right home for these items (Waiting on Others); fixes should land in the model the user already understands.

Failure mode: Fixed the dashboard todo confusion (teammates' meeting todos looked like the viewer's own) by adding an owner label to the rows. David corrected: that's not thinking like a user. Labeled-or-not, other people's todos don't belong in "my to-dos" at all.

Scope: agent:Dan

When David asks for a jaw-drop brand page, build an EXPERIENCE, not an article: full-viewport cinematic hero, scroll choreography, one idea per screen at massive scale, motifs that live in the page as motion, ruthless copy cuts, no standard nav/footer chrome breaking the spell, no section-grammar scaffolding, no FAQ accordion bolted onto a manifesto.

Why: The gap between "well-executed page" and "omg I love this" is the whole assignment on brand surfaces. Safe editorial structure is invisible at best; for-the-brave positioning demands the page itself be brave.

Failure mode: Built the /ollie manifesto page as a competent editorial layout (repeated mono eyebrow labels on every section, index rows, alternating light/dark sections, FAQ accordion at the bottom) and David rejected it outright: "this really really sucks." The brief was "reader drops on the ground saying omg I fucking love this" and the output was a safe template that reads as AI scaffolding.

Scope: agent:Claude

When David gives a design reference URL, open it in a browser and STUDY it visually (proportions, type sizes, spacing, alignment) before designing; match its register, not just its layout skeleton. Elegant means restrained: modest type scale, centered calm hierarchy, generous whitespace, thin rules. Never hand-draw SVG artwork to imitate produced brand art; crop/reuse the actual asset or use nothing.

Why: A reference URL is the brief. Reading its HTML structure without seeing it rendered led to importing the skeleton with the wrong soul, twice. Amateur freehand art next to professional motion work destroys credibility instantly.

Failure mode: Second rejection on the /ollie page. David asked for sakana.ai/fugu: elegant, Japanese sense of design (restraint, whitespace, calm, modest type, precision). I delivered giant 9vw headlines, one shouting line per viewport, and hand-drawn SVG chevron "birds" that rendered as crude fat marker scribbles. I treated "jaw-drop" as scale and boldness when the reference was quietness and precision, and I drew freehand SVG art instead of using the actual video's artwork.

Scope: agent:Claude

For fleet-wide spec maintenance: (1) tarball backup of ~/.claude before any agent touches specs; (2) partition files into DISJOINT clusters, one agent each, with CLAUDE.md owned by exactly one; (3) give every auditor the same stale-fact canon and the rule "verify a launchd plist exists before believing any schedule claim"; (4) auditors apply surgical edits directly for factual fixes but RETURN structural proposals for David instead of applying them; (5) synthesizer closes cross-cluster contradictions the auditors flag at each other.

Why: Agent specs rot faster than anyone audits them: this pass found live specs for a retired agent (jeff.md ending in "Go."), four phantom schedules, Todoist writes in five files, terminated employees still routed DMs, and a Bassim score-inflation bug. Periodic fleet audits with disjoint ownership are cheap insurance against agents acting on dead infrastructure.

Failure mode: SUCCESS: Claude ran a five-cluster parallel level-up of the entire agent army (80 files, ~140 surgical edits) without a single file conflict or lost spec.

Scope: agent:Claude

Pattern for UX dead-end hunts: (1) fan out parallel read-only explorers per surface (meetings, teams/members, KPIs/todos, onboarding/settings) asking for file:line + user-visible symptom + minimal fix; (2) fix the unsatisfiable states first: any required dropdown that can render zero options must explain where its options come from and link there (owners/attendees come from the org chart, meeting membership from teams); (3) empty states must branch on WHY they are empty (org has no teams vs user not on a team need different CTAs); (4) never report an async side effect as done: invite emails now await sendEmail (which returns null on failure, never throws) and return emailSent so the UI can tell the truth; (5) a guided setup checklist computed server-side from actual data (seats/team/KPI/meeting/members exist?) beats static onboarding because it survives skipped onboarding.

Why: These are the recurring shapes of broken UX in OTP: forms with prerequisites the user cannot see, empty states that misdiagnose their cause, and optimistic success messages over fire-and-forget side effects. Fixing the shape, not just the instance, is what makes the product feel intuitive.

Failure mode: SUCCESS: Claude ran a full UX dead-end audit and fix pass across OTP (4 PRs, #113-#116, all deployed)

Scope: agent:Claude

Any list or dropdown that is FILTERED by membership/permission/scope must carry an escape hatch whenever the filter can hide something the user expects: a one-line "Don't see your team? You only see teams you're on; join or create it in Teams" with a link. Audit rule upgrade: don't just test empty states; walk the user's actual goal ("I want to create a meeting for team X") through every branch, including "the thing I'm looking for exists but is filtered out", and ask "did the user reach their goal?" repeatedly (~4 passes) before declaring a flow fixed.

Why: The craftsmanship is in the small details: a filtered dropdown with no explainer reads as "my team is gone" and the user is stuck exactly as if the list were empty. Empty-state auditing catches zero-cases; goal-walking catches filtered-cases. Both are required or the audit declares victory while the user still can't do the thing.

Failure mode: Claude's UX dead-end audit fixed the ZERO-team cases on /l8 (no teams at all, empty owner pickers) but missed the partial case David hit live: the New-meeting team dropdown only lists teams the viewer is a MEMBER of, so a team that exists but doesn't include you is silently absent, with no explanation and no path to fix it. A populated dropdown looked "working" to both the audit agents and me, so it was never treated as a possible dead-end.

Scope: agent:Claude

The sweep pattern that worked: audit by rule-cluster in parallel (fakery, insight-to-agency, jargon/states, first-meeting goal-walk), then execute severity-first. Key catches to re-check every run: (1) seeded/synthetic data leaking into numbers a reader believes are real (the is_template flag existed but was never enforced; counts now use src/shared/synthetic-orgs.ts); (2) the conversion moment must be ON the default path (end-meeting now lands on Ollie followups, not the list); (3) funnels don't exist until instrumented (insight topic: surfaced/accepted/value_delivered); (4) credentials in seed script comments (one prod DATABASE_URL scrubbed; password rotation still owed). Worklist for run 2 in otp-platform/mission-standard/WORKLIST.md.

Why: The Mission Standard is a repeatable bar, not a one-off audit. Recording the found failure classes makes run 2 start from run 1's ceiling instead of re-discovering it.

Failure mode: SUCCESS: Claude ran Mission Standard sweep run 1 (PRs #121-#123, deployed): 4 parallel rule-audits over OTP, 5 CRITICAL + 13 GAP found, all CRITICAL and 9 GAP closed same-session

Scope: agent:Claude

When adding navigation (or any chrome), verify the config file is actually included by the live layout (grep for the partial's include) before editing, and verify the change end-to-end by rendering the layout, not just compiling the edited file. Retired files must be banner-locked the moment they are retired (dashboard-tabs.ejs now is). Also fixed the adjacent latent class: saved sidebar customization now merges via a tested invariant "a saved order is a preference, never a whitelist" (src/shared/sidebar-nav.ts) so items added after a user saves their layout still appear.

Why: Config edited in dead code passes typecheck, tests, and EJS compile while doing nothing -- the greenest possible no-op. Only rendering the real surface (or a render test on the LIVE layout) catches it. Same lesson family as L034: verify the user-visible outcome, not the artifact.

Failure mode: Two builder agents added "Your Ollie" and "Ollie Insight" nav entries to src/views/partials/dashboard-tabs.ejs, which is a RETIRED partial nothing includes (the live rail is the _sbItems array in layouts/main.ejs) -- so the menu items rendered for nobody. David caught it live ("how come /dashboard/insight is not on the menu?"). Neither builder nor my review verified the item actually RENDERED in a real shell.

Scope: agent:Claude

Keep the David+Dan L10 strictly Sneeze It agency focused. Segue and headlines pull from agency wins (client billing, ad performance, call center, team) plus a genuine PERSONAL good-news item. Never surface OTP product work here — it lives in OTP's own meeting.

Why: The two companies were deliberately split into two meetings on 2026-06-08 because carrying both made the L10 messy. Dan is Sneeze It only. Mixing OTP back in re-creates the exact problem the split solved.

Failure mode: Dan's L10 Segue for the David+Dan meeting led with OTP wins (Ollie landing page, EOS trademark remediation) even though this L10 is Sneeze It agency ONLY since the 2026-06-08 company split. OTP has its own L8/Delta Meeting.

Scope: agent:Dan

When an agent-pushed OTP to-do references a document, include a clickable https link (a Google Doc), not a local file/vault path — David reviews to-dos on mobile. To update an existing to-do's description, use PUT /api/v1/todos/:id (not PATCH). otp-todo.sh has no update verb, so PUT directly with the API key.

Why: A file path in a to-do is dead weight on mobile — the reviewer can see the reference but cannot open it, which reads as "the link is missing/broken." Every agent that pushes doc-linked to-dos (Radar, Pepper, Dan) hits this.

Failure mode: Dan pushed an OTP to-do referencing a document but put a local Obsidian vault path ("2nd Brain/Agent Army/Dan/...") in the description. David opens to-dos on his phone — a vault path is not tappable, so there was "no link to click." Also used PATCH to update the to-do; the OTP todos API update method is PUT /api/v1/todos/:id (PATCH hits the marketing site and returns HTML).

Scope: agent:Dan

To put an agent-army/IDS issue on an OTP meeting board, POST /api/v1/tickets with the team's teamId (category 'other' for strategic issues, priority low/medium/high/critical, ownerEntityType+ownerExternalId). The MCP submit_ticket tool CANNOT do this — it has no teamId param (it is the generic 'report a bug to OTP' path), which is why nobody ever got issues onto the board. Team IDs: 'AI Army' = 065d1d4b-c7da-4e80-b3ed-d6b101471d2c (the David+Dan agent-army meeting); Leadership Team = c1e1a485-414e-48d5-ae44-e81bd110b554. Update/solve via PUT /api/v1/tickets/:id (idsStatus, priorityRank, resolution).

Why: Agents could push KPIs and todos to OTP but not issues, so every L10 IDS board rendered empty and David kept discovering the hole live. Issues=tickets + teamId scoping is the missing piece; without it a meeting-readiness check would keep mislabeling a working API as absent.

Failure mode: Dan claimed 'no issues API exists in OTP' because there is no src/routes/api/issues.ts. That was wrong. OTP stores IDS issues in the TICKETS table (schema.ts: 'issues live in the tickets table'), with full IDS support (idsStatus, priorityRank, teamId, owner fields). The agent-army IDS board was empty only because our issues lived in a local markdown file and were never pushed as tickets scoped to a team.

Scope: agent:Dan

OTP has TWO distinct features both called "Ollie Insight": (A) the per-meeting followups wizard that turns a transcript into meetings.ai_summary (src/shared/meeting-followups.ts, transcript-only), and (B) the reusable "address engine" (ollie_insights table, src/services/ollie-insight.ts + shared/ollie-insight.ts + partials/ollie-insight-block.ejs) that gathers org data (KPIs/rocks/todos/meeting-summaries) per SCOPE. When David said "KPIs shouldn't be in the meeting analysis," the fix was in System B's meeting-scope evidence gathering, NOT System A. The block partial (ollie-insight-block.ejs) is fully scope-generic (builds the API URL from data-oib-scope/scopeId client-side), so adding a brand-new 'quarter' scope end-to-end took only: add to INSIGHT_SCOPES + RULES_BY_SCOPE (shared), the scopeQuerySchema enum + a resolveInsightScope branch (api), a gatherEvidence branch + max_tokens (service) -- then just include the existing partial with scope:'quarter'. No new render/generate/receipts UI. Pattern: when a feature is "one engine, many surfaces," new surfaces are a scope + evidence branch, never new UI.

Why: The name collision hides which code to touch; picking the wrong system wastes a whole edit pass. And recognizing the scope-generic block means big-feeling asks ("a quarterly synthesis button") are small, low-risk diffs. Both are recurring shapes in OTP's Ollie work.

Failure mode: SUCCESS: Claude separated OTP's two "Ollie Insight" systems and added a whole new scope by reuse

Scope: agent:Claude

New endpoint POST /api/v1/meetings/:id/agent-record (PR #154): an agent submits the written meeting record; OTP runs the same redaction ruleset, stores it to meetings.transcript, logs an audit baseline + agent_record event, and the existing /ai/followups generate turns it into to-dos/issues/headlines/insight unchanged. Agent path: ~/.claude/otp-meeting.sh record <meetingId> --file=<record> --source=l10dan. Wired into /l10dan conclude step 6. Verify deploy by probing the endpoint returns JSON not the marketing SPA HTML before pushing records.

Why: Ollie only reads transcripts, so agent-run meetings had no way into it — the empty-insight hole David hit live. This closes it: any agent meeting can now produce Ollie follow-ups. Also a general UI rule captured: buttons reflect capability/state (action taken -> button disappears).

Failure mode: SUCCESS: Dan shipped the Ollie agent-record path so agent-facilitated meetings (David + AI L10, no audio transcript) can feed Ollie Insights.

Scope: agent:Dan

Before treating a KPI/data source as blocked, re-read the LIVE source, not the note about it. The Havok "non-client %" KPI was marked blocked for ~14 weeks on "the timesheet has no client column" — a 105-day-old memory. The live sheet (1VPlH5ZqTowOe2nJDFwOjuvXrCXUnOzeOb3aO-M936Xo) had since grown per-person tabs with a full Client/Time/Date schema; one read unblocked it. Pattern for wiring a messy sheet into Tally: (1) get_spreadsheet_info to list tabs, (2) read a person tab to learn the real schema, (3) confirm recency by reading the tail (last date), (4) add a focused extract mode to tally.py rather than reshaping the sheet — here `client_attribution_since` (reads ALL valueRanges via a new _values_2d_all, parses h:mm via _parse_hhmm, added dotted DD.MM.YYYY to _parse_date, classifies internal by an `internal_contains` substring), (5) `tally.py --dry-run --kpi "<title>"` to prove the number off live data before pushing. Human-owner + a 1:1-team KPI (owner HUM_BOGDANTABAKA, team = David-Bogdan 1:1) pushes fine via find_or_create_kpi.

Why: Blocked-status notes rot silently while the underlying source improves; a KPI can sit "pending" for a quarter when it was buildable weeks ago. Re-reading the live source first is the cheap unblock. And the tally.py extract-mode pattern makes any timesheet/sheet a live KPI without asking a human to restructure their doc.

Failure mode: SUCCESS: Dan/Tally shipped the Havok client-attribution KPI live in one session after a 14-week "blocked" note turned out stale

Scope: agent:Dan

Treat OTP as an Organizational Knowledge Engine, not meeting software. Meetings are ONE input among equals: conversations, voice notes, documents, emails, chat, SOPs, decisions, KPIs, customer interactions — all feed one continuously evolving organizational understanding. Ollie is the organization's memory (not a meeting assistant): attends meetings, processes recordings + uploaded docs, reads SOPs, understands relationships, connects historical decisions, answers using org context. Every feature must pass ONE test: 'Does this increase shared organizational knowledge?' Yes -> keep; No -> question why it exists. Never ask 'How do we recreate EOS?' — always ask 'How do we create shared knowledge that naturally produces shared purpose?' The input does not matter; the shared understanding does. Companion onboarding decision: stop teaching users 'how to create a meeting' — in the first meeting the user inputs the structure themselves (expanded separately in OTP Lab).

Why: This is the north-star reframe (committed by David 2026-07-08). It changes what every agent builds, writes, and ships for OTP: external positioning (knowledge engine, not meeting tool), Ollie's role (org memory across all inputs), the feature filter (the one test), and onboarding (user brings the structure). Vision = Where People and AI Work as One; Mechanism = Shared Knowledge, Shared Purpose.

Failure mode: SUCCESS: OTP product realization — we were building OTP as meeting software (solving the HOW: recreate EOS / run a better meeting) when the actual purpose is to create Shared Knowledge -> Shared Purpose so people and AI work as one organization (the WHY). Meeting-first framing was the wrong altitude.

Scope: agent:Dan

Before editing any OTP view to fix an on-screen bug, grep unique visible strings from the screenshot (e.g. "WAITING ON OTHERS", "always only yours") across src/views to confirm WHICH template renders that exact surface. Multiple pages can render similar-looking todo lists (me-todos.ejs vs dashboard-daily.ejs). Verify the rendering route (reply.view target) too.

Why: Two round-trips and two merged PRs produced zero visible change because the edits were on the wrong template, which read as "nothing is fixed" and eroded trust. A 10-second grep on the screenshot text would have pointed to the right file immediately.

Failure mode: Fixing an OTP todos UI bug, I edited src/views/pages/me-todos.ejs twice and shipped two PRs, but the surface David actually uses is the dashboard-daily "Waiting on others" widget (src/views/pages/dashboard-daily.ejs). Nothing he saw changed.

Scope: agent:Conatus

Two reusable patterns: (1) Before building any OTP email/engagement feature, grep src/services for existing infrastructure -- re-engagement.ts, lifecycle-scheduler.ts, and user_engagement_log already carried cadence caps, suppression, logging, and a daily cron, so the todo-aware upgrade was ~350 lines instead of a new subsystem. (2) When resolving "which org does this Clerk user belong to", organizations.clerkOrgId only knows the org CREATOR; invited teammates must be resolved through org_members.clerkUserId + claimedEntityIds. This gap is why per-user personalization (open todos) missed non-creator members like Nate.

Why: One engagement channel with shared caps is what keeps daily utilization pressure from becoming annoying double-mailing, and the creator-vs-member resolution gap will bite any future per-user feature (digests, notifications, billing seats) that starts from organizations.clerkOrgId.

Failure mode: SUCCESS: Claude shipped the smart engagement email engine (PR #186) by upgrading the existing re-engagement service instead of building a parallel system

Scope: agent:Claude

WOA Lafayette runs their OWN call team, exactly like WOA China Grove. Exclude Lafayette from the CCM portfolio appointment rate, from uncalled/zero-dial alerts, and from every coaching recap. New leads with zero dials at Lafayette is EXPECTED, not a miss. Before flagging any project for zero dials, check it against the self-calling exclusion list (China Grove, Lafayette) and the Reporting-Active/Inactive status in Project Info.

Why: Coaching Amanda and Erica about leads they were never supposed to call destroys the credibility of the whole recap, and repeatedly surfacing a non-issue as the "one real issue" wastes David's attention every single morning. The China Grove precedent already existed; Lafayette was never added to it.

Failure mode: Arin/Dan flagged "WOA Lafayette: 3rd consecutive day of new leads with ZERO dials" as the day's one real call-center issue, and put it in the drafted team recap as something to tighten. It is not an issue at all.

Scope: agent:Arin

WOA Yadkinville is NO LONGER CALLED by Sneeze It (David 2026-07-10). Treat it like ROT Frisco: excluded from the portfolio rate, from dial-volume trends, from drop-off alerts, and from every recap and DM. The deeper rule: a declining or zero dial count is NEVER evidence of a caller problem on its own. Before any project enters a recap as a "tighten" item, confirm it is Reporting-Active in Project Info AND not on the self-calling / no-longer-calling exclusion list. If a project's dials fall to zero, the FIRST hypothesis is that we stopped calling it, not that the callers slacked. When a correction removes one item, do not reflexively backfill the slot with the next-worst number to preserve a "3 wins / 3 tighten" shape -- a recap with two tighten points, or zero, is correct when that is the truth.

Why: Fabricating coaching points to fill a template destroys Amanda's and Erica's trust in every number Arin sends, and it burns David's attention twice: once to read it, once to correct it. The format is a container, not a quota.

Failure mode: After Lafayette was corrected, Arin/Dan immediately substituted "Yadkinville went from 17 dials Tuesday to 1 on Thursday" as a coaching point. Sneeze It is no longer calling Yadkinville at all. Two consecutive drafted recaps coached the team on projects they were never supposed to be dialing.

Scope: agent:Arin

Frame help/success/onboarding call copy positively: state plainly that the call is there to help and guide them, and describe what will actually happen on it (we'll walk through your setup, get you unstuck, answer your questions). Never say "this is not a sales call" or "no pitch" — describe the help, don't disclaim the sell.

Why: Defensive "not a sales" language triggers the exact suspicion it tries to defuse and undercuts a genuine help offer. David flagged this immediately.

Failure mode: Wrote a "customer success call" Calendly description that leaned on "no pitch, no slides" / not-a-sales-call framing. Protesting that it isn't a sales call makes it sound like one.

Scope: agent:Conatus

Any script that answers "is anything missing / is everything covered?" must fail LOUD, never return an empty set as reassurance. Two rules: (1) assert the expected top-level key exists (`if 'data' not in resp: raise`) before computing a result; a zero/empty answer from a health check is a claim that must be proven, not a default. (2) Cross-check a zero result against one known-positive case before reporting it -- here, one direct call to a single account would have shown $57 of spend and exposed the lie instantly. Also: `~/.claude/meta-ads.sh accounts` exits 0 and prints nothing; do not build on it. Sweep with `/{business_id}/adaccounts?fields=name,account_status&limit=500` then batch `/{act_id}/insights` 50 at a time.

Why: "Nothing is wrong" is the single most dangerous output an audit can produce, because nobody investigates it. A silent empty result on a billing sweep means real revenue is never invoiced and nobody ever finds out. The failure mode is not a crash, it is confident silence.

Failure mode: SUCCESS: Claude caught a silent false-negative in a Meta billing sweep. Querying the Graph API adaccounts edge with nested field expansion (`fields=name,insights.date_preset(this_month){spend}`) returned an error payload with NO `data` key. The sweep script read it as an empty account list and confidently reported "0 accounts, $0.00 unbilled MTD spend" -- a clean bill of health that was entirely fabricated. Direct per-account queries then revealed 7 unbilled accounts spending $5,673 MTD.

Scope: agent:Dash