fix(self-driving): scout-gate source is on by default, not create-always

context/skills/self-driving/references/4-sources.md

@@ -30,7 +30,7 @@ Reach the source-config tools through the PostHog `exec` tool — `info` then `c
 
 | Source | When | Payload |
 |---|---|---|
-| Scout gate | **Always** — it lets the step-6 troop's findings reach the inbox | `signals_scout` / `cross_source_issue` |
+| Scout gate | **On by default — never create a row.** The server lets scout findings into the inbox with no config row; a `signals_scout` / `cross_source_issue` row only exists to opt OUT. If you find one with `enabled: false` (an earlier opt-out), flip it back on with `inbox-source-configs-partial-update`; with no row, do nothing and record "on by default" | `signals_scout` / `cross_source_issue` — existing disabled row only |
 | Health checks | **Always** — instrumentation issues (missing events, proxy gaps, outdated SDKs) are always actionable and a good thing for the agent to fix | `health_checks` / `health_issue` |
 | Error tracking | **Enable by default**, even with no current signal — teams adopt error tracking sooner or later, and with no errors there are no findings and no cost. Evidence (report, exception autocapture ON, or error issues from the step-2 probe) only raises confidence; its absence is **not** a reason to skip | **All three rows**: `error_tracking` / `issue_created`, `error_tracking` / `issue_reopened`, `error_tracking` / `issue_spiking` — the product UI treats them as one switch |
 | Session replay | **Enable by default**, same reasoning — arm it now even with no current signal; recordings are only analyzed once they exist, so an idle source costs nothing and teams turn replay on eventually. Evidence (recording opt-in ON, recordings from the step-2 probe, or the report) only raises confidence; its absence is **not** a reason to skip | `session_replay` / `session_analysis_cluster` — don't pass a `config`; the server injects the default sample rate. A 400 mentioning AI approval is unexpected (approval is enforced upstream) → skip this source and record a follow-up |

context/skills/self-driving/references/6-scouts.md

@@ -4,7 +4,7 @@ next_step: 6b-tailor-scouts.md
 
 # Step 6 — Configure the scout troop
 
-Scouts are the pull side of Signals: scheduled agents that scan the project on an interval and emit findings as `signals_scout` / `cross_source_issue` signals (which step 4's scout gate lets into the inbox). Every enabled scout is a recurring LLM spend — it costs a full run every tick even when it finds nothing — so the troop is kept **deliberately selective**: the `general` scout, plus the **three to five specialists** for the products this project uses most. Everything else is disabled.
+Scouts are the pull side of Signals: scheduled agents that scan the project on an interval and emit findings as `signals_scout` / `cross_source_issue` signals (which reach the inbox by default — step 4's scout gate row exists only as an opt-out). Every enabled scout is a recurring LLM spend — it costs a full run every tick even when it finds nothing — so the troop is kept **deliberately selective**: the `general` scout, plus the **three to five specialists** for the products this project uses most. Everything else is disabled.
 
 **The whole troop shares one ceiling of about ten enabled scouts** — `general` + 3–5 specialists from this step + 3–5 custom scouts from step 6b, traded against each other so the total stays at or under ten. That ceiling is about quality, not cost: across the fleet, the share of runs that produce a finding holds steady from roughly five to ten enabled scouts and then drops by about half past ten, because a troop that big stops being selective about which surfaces it watches.