# The Silent Wiring Prompt Pack *Companion resource for* **Silent Wiring: The Hidden Failure Mode in AI-Generated Code.** Two kits. **Build It Loud** makes an AI coding assistant generate new event-driven integrations that can't hide a dead edge. **Audit It Loud** turns the same three checks on code you already have. Every prompt is tool-agnostic. Paste it into any AI coding assistant, fill the `[BRACKETS]`, and hold the output to the acceptance criteria beneath it. Where a repo-aware agent (Claude Code and the like) can do meaningfully more, there's a *CC variant*. The difference is that the agent *runs* the checks instead of *reasoning* about them, which is the whole point of the mutation layer. Throughout, an *edge* is one flow. The pack writes it `producer -> event -> consumer`; the Field Manual writes the same thing as `source_event -> handler -> target` (FM-2). They map term for term: the pack's *event* is the FM's `source_event`, the pack's *consumer* is the FM's `handler`, and the FM adds `target` (the thing the handler writes to), which the pack's shorthand leaves implicit. That third term is what makes flows countable: FM-2e's rule is "One source event, two handlers, two targets — two flows." So expect a pack edge count and a `flow-topology.yaml` flow count to diverge wherever one producer fans out to several consumers; the FM's flow identity, handler plus target, is what accounts for the difference. --- ## The three layers, plus a triage pass (both kits share them) The book's fix is three layers, plus a triage pass that decides where to aim first. Every prompt here builds or audits one of these, pointed either forward (build new) or backward (audit existing): 1. **Topology declaration**: every wiring edge written down as `producer -> event -> consumer`, as a checkable table, not a comment buried in code. *(Field Manual: FM-2.)* 2. **Liveness verification**: a probe per edge that proves the consumer's *side effect* actually happens when the event fires, not merely that a handler is registered. *(FM-3: canary events, handler freshness, event bus audit, meta-liveness, plus FM-3i for threshold calibration and false positives, see the vocabulary tables below.)* 3. **Mutation testing**: for each edge, the smallest change that would silently kill it, and proof the liveness probe fails under that change. A probe a mutation slips past is worthless. The book names four core operators for exactly this. See the vocabulary tables below. *(FM-4b; FM-6a adds four more for hardening once the core four are green.)* 4. **Confidence triage**: not a fourth layer but the pass that ranks edges by failure risk *first*, so you spend verification effort where death is most likely and stay honest about what you deprioritized. It runs before you build. *(FM-6c: confidence scoring.)* Structural correctness hides behavioral death. Loud wiring makes that death impossible to miss. ### Book vocabulary: the terms these prompts use So the pack and the book read as one voice, the two tables below quote the Field Manual's own labels. Use these names in your prompts when you want book-exact output. **Liveness techniques (FM-3), how to prove an edge is alive:** | Technique | What it catches | FM | |-----------|-----------------|----| | **Canary events** (the *semantic canary*) | Not *did the event arrive?* but *did the handler process it correctly?* | FM-3b | | **Handler freshness** | *Counterfeit*: a row that is fresh and wrong at the same time | FM-3c | | **Event bus audit** | *Subscription drift*: are the handlers you declared actually registered with the bus? | FM-3d | | **Meta-liveness** | The thing watching your system can't fail the same way your system does | FM-3h | **Mutation operators, the core four (FM-4b), how to prove a probe would notice a death:** | Operator | Nickname | Kills | |----------|----------|-------| | **Subscription Removal** (Type 1) | *The Severed Wire* | The handler stops receiving the event entirely | | **Handler Body Replacement** (Type 2) | *The Stunt Double* | The handler still fires but does nothing | | **Payload Corruption** (Type 3) | *The Plausible Lie* | The write happens, but the values are meaningless | | **Conditional Inversion** (Type 4) | *The Scenery `if`* | Both branches still run, but the `if` no longer decides | Get the core four green first. Only when they pass and you're hardening critical paths beyond them do the four **extended operators** (FM-6a) earn their place: *parameter perturbation*, *handler recombination*, *priority inversion*, *gradual degradation*. They stack on top of the core four. They do not replace any of them. --- --- # KIT 1: BUILD IT LOUD *Generate new integrations with the wiring already loud.* ## Prompt 1.1: "Wire It Loud" (flagship: build + self-verify) Paste the block below. Fill the `[BRACKETS]`, then hold the output to the acceptance criteria at the bottom of this prompt. ``` You are writing an event-driven integration. The failure mode I care about is SILENT WIRING: code that looks correct and passes a superficial read, but is behaviorally dead — the event fires and nothing downstream actually reacts. Structural correctness hides behavioral death. Your job is to make the wiring LOUD so that kind of failure cannot pass unnoticed. TASK Implement: [DESCRIBE THE INTEGRATION — producers, events, consumers]. Stack / framework: [LANGUAGE + EVENT MECHANISM, e.g. Node + EventEmitter, Kafka, Django signals]. Produce all four of the following. Do not skip any. Do not reorder them. 1. TOPOLOGY DECLARATION List every wiring edge explicitly as producer -> event -> consumer, in a table. One row per edge. This is a checkable artifact, not a comment buried in code. If an edge is implicit or discovered rather than declared, say so on its row. 2. LIVENESS VERIFICATION For EACH edge, write a probe/test that proves the consumer actually RUNS its side effect when the event fires — asserting the observable outcome, not merely that a handler is registered. A test that only checks "a listener exists" does not prove liveness. Each probe must fail loudly (clear message) if the edge is dead. 3. MUTATION TESTING For EACH edge, describe the smallest change that would silently kill it (unsubscribe, swallowed exception, renamed event, wrong channel). Confirm that the liveness probe from step 2 would FAIL under that mutation. If a mutation would slip past the probe, the probe is worthless — strengthen it and re-check. 4. CONFIDENCE TRIAGE (do this FIRST, before writing exhaustive probes) Rank the edges by failure risk using only what you already know: complexity, novelty, recent-change history, and the runtime state each edge depends on. Spend verification effort on the high-risk edges first. State the ranking and which edges you deprioritized. OUTPUT FORMAT - The topology table. - The liveness probes (runnable). - The mutation results (edge | mutation | probe catches it? y/n). - A short "WHAT I DID NOT VERIFY" section — honest gaps, deprioritized edges, assumptions. Never claim coverage you did not produce. ``` **Acceptance criteria (what you check in the output):** - Every edge in the topology table has a matching liveness probe and a mutation result. - No probe merely asserts a handler is *registered*. Each asserts the side effect *happened*. - Every mutation row reads "catches it? y". Any "n" is a dead probe to fix before shipping. - The "WHAT I DID NOT VERIFY" section is non-empty and specific. Silence there is the tell. **CC variant (the assistant runs the mutation testing, not predicts it):** ``` Work inside my repo at [PATH]. Do everything in Prompt 1.1, and additionally: - Write the topology table to [docs/wiring-topology.md]. - Write each liveness probe as a real test file under [TEST DIR] and run the suite; paste the actual run output. - For each mutation in step 3: apply it on a scratch branch, re-run ONLY the affected probe, and paste the real pass/fail — do not predict it. Then revert the mutation. - Report the mutation table from executed runs, marking any row you could not run and why. ``` The gap between "the probe would fail" (reasoned) and "the probe did fail" (executed) is exactly where silent wiring lives. The CC variant closes it. --- ## Prompt 1.2: Quick variant (one or two edges) When a full four-artifact output is overkill: a single new subscription, a one-hop signal. ``` You're adding an event-driven integration: [DESCRIBE — producer, event, consumer]. Stack: [LANGUAGE + EVENT MECHANISM]. SILENT WIRING is the failure I'm guarding against: the event fires and nothing downstream actually reacts, even though the code reads as correct. Make the wiring loud. Give me, for this integration: 1. The edge(s) as one line each: producer -> event -> consumer. 2. One runnable liveness test per edge that asserts the consumer's SIDE EFFECT happened when the event fired — not that a handler is registered. 3. The smallest change that would silently kill each edge, and a one-line confirmation that the test in (2) fails under it. If it wouldn't, strengthen the test. 4. One honest line: what this does NOT cover. ``` --- --- # KIT 2: AUDIT IT LOUD *Point the same three layers at code you already have. You are not building. You are hunting edges that are already dead and don't know it.* Run these in order. Each feeds the next: the topology from 2.1 is the input to 2.2 and 2.3; all three feed the ranking in 2.4. ## Prompt 2.1: Reconstruct the actual topology ``` Read the code at [PATH / REPO] and reconstruct its ACTUAL event wiring — not what the docs claim, what the code does. Produce a table, one row per edge: producer -> event -> consumer. For each row mark: - DECLARED — the edge is written down somewhere explicit (a topology file, a registration block, a manifest). - INFERRED — you found it only by tracing code (an emit here, a listener there). Rules: - Include implicit and discovered edges. The dangerous ones are usually inferred, not declared. - Flag DANGLING EMITS (a producer fires an event no consumer handles) and ORPHAN LISTENERS (a consumer is registered for an event nothing emits). Both are silent wiring by another name. - Do not invent edges to look thorough. If you're unsure an edge is real, mark it UNSURE and say what you'd need to confirm it. End with a count: declared / inferred / dangling / orphan. ``` **Acceptance:** the table separates DECLARED from INFERRED and flags dangling + orphan edges. A table of nothing but clean declared edges means the assistant read the docs, not the code. *CC variant:* run against the repo, grep the emit/subscribe patterns of [EVENT MECHANISM], trace across files, and write the table to `[docs/wiring-topology-actual.md]`. --- ## Prompt 2.2: Probe each edge for liveness ``` Here is my system's wiring topology: [PASTE THE TABLE FROM 2.1, or point at the repo]. For EACH edge, tell me whether a test TODAY actually proves the consumer's side effect runs when the event fires. For each edge, give exactly one verdict: - COVERED — name the existing test and quote the assertion that proves the SIDE EFFECT (the observable outcome), not just that a handler is registered. - REGISTRATION-ONLY — a test exists but only checks that a listener is attached / a handler is wired. This does NOT prove liveness. Say so plainly. - UNCOVERED — nothing tests this edge's behavior at all. For every REGISTRATION-ONLY or UNCOVERED edge, write a runnable liveness probe that proves the side effect and fails loudly if the edge is dead. Do not upgrade a registration check to COVERED by rewording it. If the assertion doesn't observe the outcome, it's registration-only. ``` **Acceptance:** every REGISTRATION-ONLY verdict is called out, not quietly folded into COVERED. Registration checks that pass while the edge is dead are the exact illusion the book is about. --- ## Prompt 2.3: Mutation-test the existing suite ``` For each edge in my topology [PASTE TABLE, or point at the repo], I want to know if my EXISTING test suite would notice if that edge silently died. For each edge: 1. Name the smallest silent-kill mutation using the four core operators: THE SEVERED WIRE (remove the subscription so the handler stops receiving the event), THE STUNT DOUBLE (the handler still fires but does nothing), THE PLAUSIBLE LIE (the write happens but the values are meaningless), or THE SCENERY IF (both branches run but the conditional no longer decides). Pick the one that most cheaply kills THIS edge. 2. State whether my CURRENT tests would CATCH it (some existing test goes red) or MISS it (the suite stays green while the edge is dead). 3. If you can run the suite: actually apply the mutation, run the tests, report the real result, then revert. If you can't run it, mark the verdict REASONED, not EXECUTED. Output a table: edge | mutation | caught? (executed / reasoned) | which test caught it. Every MISS is a place your suite is decorative: the edge could be dead in production and every test would still be green. ``` **Acceptance:** every row says caught or missed AND marks executed vs reasoned. All-reasoned across a repo the assistant could have run means it skipped the actual work, which is itself the failure mode you're hunting. --- ## Prompt 2.4: Rank findings by risk ``` Here are my silent-wiring findings [PASTE the outputs of 2.1–2.3: inferred/dangling/orphan edges, registration-only + uncovered edges, missed mutations]. Rank them by risk so I fix the right ones first. For each finding weigh: - BLAST RADIUS — what breaks downstream, or for users, if this edge is silently dead. - RUNTIME-STATE DEPENDENCE — does the edge fire only under specific state (a feature flag, a queue depth, a time window)? State-dependent edges hide the longest. - NOVELTY / CHANGE HISTORY — recently written or recently changed edges fail more. - DETECTABILITY TODAY — is anything at all (a test, an alert, a dashboard) watching this edge? Give me a ranked list, highest risk first, each with a one-line "why this rank" and the single next action. Then draw the line: which findings are you telling me to deprioritize — and say plainly that they are UNVERIFIED, not SAFE. ``` **Acceptance:** the output ends with an explicit deprioritized set labelled *unverified, not safe*. "Nothing left to worry about" after an audit is the tell. An honest audit always names what it chose not to chase. --- --- ## How to use this pack - **Building something new?** Run **Kit 1**. Prompt 1.1 for anything with more than a couple of edges; 1.2 for a quick one-hop. - **Inherited or long-lived code?** Run **Kit 2** in order (2.1 → 2.2 → 2.3 → 2.4). The book's advice holds here too: *pick three, then expand*. Audit your three highest-risk edges fully before widening, rather than a shallow pass over everything. *(FM-4d.)* - **Repo-aware agent (Claude Code, etc.)?** Prefer the *CC variants*. The mutation layer is only trustworthy when the mutation is actually applied and the suite is actually run. Reasoning about it reproduces the same wishful thinking that lets silent wiring ship. The honest-gaps section is load-bearing in every prompt here. An AI assistant's silence about what it *didn't* verify is the same failure this book is about, one level up: an output that looks complete and is behaviorally hollow. --- ## Grounding note This pack uses the book's own vocabulary: *silent wiring*, *topology declaration*, *liveness verification*, *mutation testing*, *canary events*, *handler freshness*, *event bus audit*, *meta-liveness*, *dead letter queue*, *wiring coverage dashboard*. *Confidence triage* is this pack's name for the ranking pass, not a term from the book. The liveness-technique terms and the four core mutation operators (with nicknames and glosses) are drawn from the locked Field Manual (FM-3b–3h, FM-4b, and FM-6a) in the vocabulary tables near the top. FM-6a's extended operators are kept explicitly separate from FM-4b's core four, following the book's own "get your core four operators green first" ordering; *parameter perturbation* is an extended operator, not one of the core four. This is a companion resource, not manuscript. If any prompt here should later *become* a locked Field Manual appendix, it routes through the drafting pipeline (`be draft`) rather than staying a companion.