marketing: FRE-199 third pair of informational pages (drafts) + pitch narrowed to the no-figure shape

Pair 3 (internal target Thu 2026-11-12, six days early): - agent-worktree-contention — 'How do you manage worktrees when your agents end up waiting on each other?' (backlog 1xlz2bs, Scan 6 #4); git worktree + Docker Compose project-name docs fetched and read 2026-11-05. - agent-keeps-asking — 'Why does your coding agent keep stopping to ask you questions?' (handback cluster: 1xlfqmo, 1xk0ghj, 1xlxw0q); permission + hooks claims re-verified live 2026-11-05 against code.claude.com; the 1xlfqmo poster's measurement figures deliberately not cited. Pitch narrowed per CTO reopening verdict: trial→paid placeholder deleted (FRE-202 cohort too young; ratio waits for FRE-197), second breakage chosen (NOOK-815 uninvoked suite), any count named as activations, downloads never quoted.
marketing: FRE-199 CTO review fixes — B1 precedence order, B2 false git-push example dropped, N1 hooks-guide attribution
2026-11-05 22:54:53 +00:00 · 2026-11-05 21:42:26 +00:00 · 2026-11-05 20:23:03 +00:00 · 2026-11-05 20:15:30 +00:00 · 2026-11-05 19:58:59 +00:00 · 2026-11-05 19:54:45 +00:00
15 changed files with 1214 additions and 0 deletions
--- a/marketing/approved/agent-done-signal/copy.md
+++ b/marketing/approved/agent-done-signal/copy.md
@@ -0,0 +1,92 @@
 # How do you know when your coding agent is done?
 > **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 fact-check
 > card, verdict: "Approve both — move to approved/"). Not published; a human
 > places it on nook.freno.me from `approved/`.
 > This page never names a product of ours and never names a competitor.
 > Internal target: first page of the FRE-199 pair, Thu 2026-11-06.
 > CTO review 2026-11-05: changes requested and applied — the `osascript`
 > example is attributed to the hooks guide, not the hooks reference; pair-1
 > citations standardised to code.claude.com.
 Often, you don't — not from the terminal alone. A coding agent's turn can end in
 silence: the prompt returns, the cursor blinks, and a finished turn looks exactly
 like one that stalled, is still running, or is waiting on you. The fix is to stop
 trusting silence and wire the two moments that matter — *the turn ended* and *the
 agent needs you* — to something you will actually see.
 ## Why silence is the failure mode
 A terminal coding agent ends a turn by printing a prompt. If you are in another
 window, another room, or running several agents at once, nothing in that output
 distinguishes "finished" from "blocked on a permission prompt" from "dead". The
 task being done and you finding out are two different events, and the second one
 has no default signal.
 Practitioners keep rediscovering this. One operator running a self-hosted queue
 of autonomous agent sessions described sessions that "finished their work but
 never sent the done signal, and held their slots for hours" — their fix was to
 derive "done" from git state plus an idle transcript instead of trusting the
 agent's own signal. A public service post about a code-review plugin described
 the mirror image: a green checkmark and "No findings" when the review had not
 run at all. An empty result and a successful result rendered identically.
 That is the trap in one sentence: **zero looks exactly like success.**
 ## What the turn-ending signal actually is
 Claude Code gives you two hooks that bracket the moments worth surfacing:
 - **`Stop`** fires when the agent finishes responding — the end of a turn.
 - **`Notification`** fires when Claude Code sends a notification. A permission
  prompt is one of these: the hook's payload carries a `notification_type` of
  `permission_prompt` and a message like "Claude needs your permission".
 - **`StopFailure`** fires instead of `Stop` when the turn ends on an API error —
  rate limits, authentication problems, and the like.
 All three can run a command of your choosing. The hooks reference documents the
 events; the hooks guide includes a desktop-notification example built on
 macOS's `osascript`.
 ## What to check or do
 1. **Wire turn-end to a notification you will actually notice.** A `Stop` hook
   that calls `osascript -e 'display notification …'` (or your terminal's
   notification escape) turns the silent prompt-return into a visible event.
   A terminal bell is not this — it is mute the moment you switch windows.
 2. **Route permission waits separately from completions.** The `Notification`
   hook's payload tells you which kind it is. A permission wait means the agent
   is *blocked on you*; treating it as "done" hides the one state that costs the
   most time.
 3. **Don't trust the exit signal alone.** Check the artifacts: `git status`,
   `git log`, whether the transcript has gone idle. The queue operator's rule
   generalises — a "done" that has to name what it is waiting on is a "done"
   you can act on.
 4. **Surface the failure path too.** A turn that ends on an API error fires
   `StopFailure`, not `Stop` — an alert wired to the wrong one misses exactly
   the runs that need attention.
 One next step: take the agent command you run most often and give its end-of-turn
 a notification you would notice from across the room. That single wire closes the
 most expensive silence in the workflow.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about Claude Code's
 behaviour come from its own documentation, re-read 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | `Stop` fires when the agent finishes responding (end of a turn); hook cadence is "per turn: UserPromptSubmit, Stop, StopFailure" | Claude Code hooks reference — https://code.claude.com/docs/en/hooks |
 | 2 | `Notification` fires "when Claude Code sends a notification"; example payload carries `notification_type: "permission_prompt"`, message "Claude needs your permission" | same hooks reference (Notification event section) |
 | 3 | `StopFailure` "runs instead of Stop when the turn ends due to an API error" (rate limits, authentication) | same hooks reference (StopFailure section) |
 | 4 | Hooks run a command of your choosing; a desktop-notification example using `osascript` is in the hooks guide | Claude Code hooks guide — https://code.claude.com/docs/en/hooks-guide (desktop-notification example) |
 | 5 | Operator anecdote: sessions that finished work but never signalled done, holding slots for hours; fix = derive done from git + idle transcript | r/ClaudeCode thread 1xjb3j0 ("Are you running a self-hosted queue of autonomous Claude Code sessions?", 2026-10-31), quoted in `drafts/listening.md` Scan 4 addendum. Quoted as one operator's described practice, not a measurement. |
 | 6 | PSA anecdote: code-review plugin showed green check + "No findings" without running | r/ClaudeCode 1xmnz2c (2026-11-03), logged in `drafts/listening.md` Scan 6. |
 | 7 | "Zero looks exactly like success" | Verbatim buyer phrasing, three independent instances (1xm09fs, 1xmnz2c, plus HN repeats) in `drafts/listening.md` Scans 5–8. Used as the problem's name, attributed to no one. |
 **Ban compliance:** no product of ours named · no competitor named · no
 superlatives · no benchmark numbers · no invented testimonials (anecdotes are
 real threads, described without handles) · no price · no roadmap dates.
--- a/marketing/approved/agent-done-signal/rationale.md
+++ b/marketing/approved/agent-done-signal/rationale.md
@@ -0,0 +1,72 @@
 # Rationale — "How do you know when your coding agent is done?"
 FRE-199 item 1, page 1 of the first pair. Drafted 2026-11-05 by CMO.
 ## The phrase
 Primary: **"how do you know when your coding agent is done"** (variants: "agent
 finished silently", "claude code waiting for permission" overlaps on the
 blocked-half; this page owns the *done*-half).
 Chosen by the FRE-199 selection rule: strongest buying intent we can answer
 honestly without naming a product. It is on the standing phrase list
 (`drafts/listening.md` §The phrase list: "how do I know when my agent is done").
 ## Why this phrase won the slot
 - **Recurrence with independence.** The "zero looks exactly like success"
  pattern appears in at least four separate sources across Scans 5–9: 1xm09fs,
  the code-review PSA (1xmnz2c), and two HN commenters (fhub, sadilek), plus
  the queue operator's done-signal workaround (1xjb3j0). Four independent
  formulations of one pain in seven days is the strongest recurrence the
  backlog shows.
 - **Buying intent.** The people describing it are running agents unattended
  right now and are losing time to the gap — they are past curiosity.
 - **Answerable honestly, generically.** The mechanism (Stop / Notification /
  StopFailure hooks) is documented in the agent's own reference; every claim in
  the page traces to it. Nothing about our product is needed to answer it.
 - **Wedge-aligned.** "An agent blocked is the most expensive kind of idle" —
  the done-half of that sentence (idle you never learn about) is this page.
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeCode 1xjb3j0 — "self-hosted queue of autonomous Claude Code sessions" | 2026-10-31 | Sessions "finished their work but never sent the done signal, and held their slots for hours"; operator derives done from git + idle transcript; "a waiting one has to name what it's waiting on" |
 | r/ClaudeCode 1xm09fs | 2026-11-02 | First "zero looks exactly like success" instance (verbatim buyer phrasing) |
 | r/ClaudeCode 1xmnz2c — code-review plugin PSA | 2026-11-03 | Green check + "No findings" when the review never ran; third independent instance |
 | HN comments (fhub, sadilek) | 2026-11-04/05 | Human-attention concurrency ceiling quantified twice more |
 All rows live in `drafts/listening.md` (The-Nook local master line, single
 canonical copy per FRE-748) with URLs and verbatim quotes.
 ## Gates before this page ships
 1. **Sponsor fact-check** of the claims table in `copy.md` (owner: Michael
   Freno). Page moves `pending/` → `approved/` on his read, per the marketing
   tree's hard rule.
 2. **CTO eyes on the agent-behaviour claims** — all four are sourced to the
   Claude Code hooks reference re-read 2026-11-05, but anything asserted about
   an agent's behaviour is CTO-verifyable, and the FRE-199 plan routes it to
   him.
 3. **Publish path:** `pending/` → `approved/` → a human places it on
   nook.freno.me (blog route). Nothing posts itself.
 ## Ban compliance (FRE-199 + positioning.md rule 1)
 - The Nook: not named. The notch, the island, the companion: not mentioned.
 - Competitors (notch apps, agent monitors, Remote Control–style tools): not
  named. Remote Control is not mentioned either — the page answers the done-half
  without touching the away-from-desk half.
 - Claude Code is named only as the subject whose documented behaviour the page
  explains, with its own docs as the source — the same status the listening
  phrase list already gives it. It is the agent, not a competitor.
 - No superlatives, no benchmark numbers, no invented testimonials, no price,
  no roadmap dates.
 ## Cadence note
 This page and `agent-waiting-on-permission/` are the first pair. The queue
 behind them (multiple-agents tracking, invisible-permission cluster) holds well
 above the three-candidate floor, so the two-a-week cadence holds without
 inventing phrases.
--- a/marketing/approved/agent-parallel-tracking/copy.md
+++ b/marketing/approved/agent-parallel-tracking/copy.md
@@ -0,0 +1,113 @@
 # How do you keep track of multiple coding agents?
 > **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 pair 2
 > fact-check card, verdict: "Approve both — move to approved/"). Not published;
 > a human places it on nook.freno.me from `approved/`. Internal target:
 > Mon 2026-11-09, met four days early. This page never names a product of ours
 > and never names a competitor.
 The honest answer: not by watching them. Run three agents and the watching
 already fails — the session you are not reading is the one that finished, or
 the one sitting on a question, and both states look identical from the outside.
 The fix is not more windows; it is giving each agent a way to announce its own
 state, so checking becomes something that happens to you instead of something
 you have to remember.
 ## Why attention is the limit
 Parallel agents are cheap to start and expensive to supervise. Every running
 session can stop and wait for you — a permission prompt, a question, a finished
 turn — and from your side of the screen those are invisible until you go look.
 Operators who run agents at scale keep describing the same wall in different
 words. One practitioner running dozens of parallel threads a day put it as the
 limit moving "from tokens to my attention"; another, asked how many sessions
 they could run, got the answer from their own comment section: not compute —
 you. A developer who ran agents unattended for a month summarised the failure
 as silence: "the six hours of silence was the real problem, not the dialog
 itself." And the most common collision is the simplest — two agents waiting on
 you while you are deep in the third, and one of them idle so long you lost the
 thread of what you asked it to do.
 None of that is a speed problem. It is a visibility problem: *which* of your
 agents needs you, and *how do you find out without touring every window?*
 ## What a per-agent signal actually is
 A terminal coding agent has no shared dashboard by default — each session is
 its own process, its own window. But its state changes are events, and events
 can be wired outward. Claude Code documents the pieces:
 - **Every state you care about fires an event.** `Stop` fires when Claude
  finishes responding — the end of a turn. `Notification` fires when Claude
  Code sends a notification, and the notification's type tells you which kind
  of waiting it is: a `permission_prompt`, an `idle_prompt`, `agent_needs_input`,
  or `agent_completed`. `SessionStart` and `SessionEnd` bracket the whole
  session.
 - **The event names the session it came from.** Every hook payload carries a
  `session_id`, so one handler can serve every window and still know which
  agent fired.
 - **A hook is just a command you choose.** The events are configured in the
  settings files and run whatever command you point them at — append to a log
  file, update a status line, send a desktop notification that names the
  project.
 - **The status line can carry per-session state.** Claude Code's status line
  is a customizable bar driven by a script you write; it receives session data
  on every render, and the docs name "work across multiple sessions and need
  to distinguish them" as a reason it exists.
 The pattern in all four: stop touring windows and make each agent's
 running / waiting / finished state observable where you already are.
 ## What to check or do
 1. **Name the states before naming the tools.** For your workflow the states
   are usually three — running, waiting on you, finished — and the expensive
   one is always "waiting on you". A tracking setup that cannot distinguish a
   permission wait from a completion will quietly hide the state that costs
   the most.
 2. **Wire the waiting events first.** A `Notification` hook matched on
   `permission_prompt` and `agent_needs_input` catches the blocked cases; the
   payload's `session_id` lets one handler label each alert with the project
   it came from.
 3. **Route completions separately.** `Stop` means the turn ended — not that
   the work was right, and not that nothing is blocked elsewhere. Treating
   "finished" and "needs you" as one notification is how a waiting agent gets
   buried under a pile of done messages.
 4. **Make the state visible without switching windows.** A per-session status
   line, a log file the hook appends to, or a desktop notification that names
   the project all work — the test is whether you can answer "does anything
   need me?" without leaving the window you are in.
 5. **Expect the ceiling to be yours.** Operators consistently find the
   bottleneck before the machines do. The number of agents you can run is the
   number whose waiting state reaches you reliably — not the number your
   terminal can host.
 One next step: run two agents side by side and wire only their permission-wait
 events to a notification that names the project. The first time the second
 agent's prompt reaches you before you happen to check its window is the whole
 argument.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about Claude
 Code's behaviour come from its own documentation, re-read 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | `Stop` fires when Claude finishes responding; `SessionStart`/`SessionEnd` are per-session events | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (hook events table; "per session: SessionStart and SessionEnd; per turn: UserPromptSubmit, Stop, and StopFailure") |
 | 2 | `Notification` fires when Claude Code sends a notification; matcher supports notification types including `permission_prompt`, `idle_prompt`, `agent_needs_input`, `agent_completed` | same hooks reference (matcher table: "Notification | notification type") |
 | 3 | Every hook payload carries `session_id`, the current session identifier | same hooks reference (Common input fields: `session_id` — "Current session identifier") |
 | 4 | Hooks are configured in the settings files and run a command of your choosing | same hooks reference (configuration and command-hook examples) |
 | 5 | The status line is a customizable bar driven by a script, receives JSON session data, and the docs name "work across multiple sessions and need to distinguish them" as a use | Claude Code status line doc — https://code.claude.com/docs/en/statusline |
 | 6 | "The limit moved from tokens to my attention" / "fifty a day add up to something I could feel by Friday" | r/ClaudeCode 1xh5cum (2026-10-27, "Four months of 50+ parallel agent threads a day"), logged in `drafts/listening.md` Scan 3. Practitioner's own account, not a measurement. |
 | 7 | "How many sessions before you become the bottleneck" — the thread went to compute; the attention half stayed on the table | r/ClaudeCode 1xdjb2g (2026-10-23, 72 comments), logged in `drafts/listening.md` Scan 1. |
 | 8 | "The six hours of silence was the real problem, not the dialog itself" | r/ClaudeCode 1xipsk0 (2026-10-29, "~40 Claude Code agents unattended for a month"), quoted by the OP in-thread, logged in `drafts/listening.md` Scan 2. |
 | 9 | Two agents waiting while the human is in the third; idle so long the thread of the task was lost; "most of my idle time came from agents waiting on a permission prompt while I was in another window" | r/ClaudeAI 1xmzp2n (2026-11-03, "How do you keep track of multiple coding agents running in parallel?"), two independent commenters, logged in `drafts/listening.md` Scan 9. |
 | 10 | "You're the bottleneck agents were meant to eliminate" — approvals routing through one person | r/ClaudeCode 1xk0ghj (2026-10-31, "multiple agents working on multiple projects"), commenter's words, logged in `drafts/listening.md` Scan 4. |
 **Ban compliance:** no product of ours named · no competitor named (herdr,
 tmux, dashboards: none named — the page answers generically) · no handles · no
 superlatives · no benchmark numbers · no invented testimonials (anecdotes are
 real threads, described without handles) · no price · no roadmap dates.
--- a/marketing/approved/agent-parallel-tracking/rationale.md
+++ b/marketing/approved/agent-parallel-tracking/rationale.md
@@ -0,0 +1,71 @@
 # Rationale — "How do you keep track of multiple coding agents?"
 FRE-199 item 1, page 1 of the second pair. Drafted 2026-11-05 by CMO (internal
 target Mon 2026-11-09, beaten by four days — the backlog held, so drafting
 early cost nothing).
 ## The phrase
 Primary: **"how do you keep track of multiple coding agents running in
 parallel"** (variants: "how many sessions before you become the bottleneck",
 "which agent is waiting", "agent tracking dashboard").
 ## Why this phrase won the slot
 - **Strongest recurrence in the backlog.** Seven independent threads across
  nine scans state the multi-agent attention problem in their own words — more
  than any other cluster after the pair-1 phrases. It is the natural next page:
  the pair-1 pages answer *one* agent's silence (done-signal) and *one*
  permission wait (waiting-on-permission); this is the fleet-scale version of
  the same pain, and the buyers are already at fleet scale.
 - **Buying intent.** Every quoting operator is running multiple agents *now*
  and losing time to supervision, not exploring.
 - **Answerable honestly, generically.** The mechanism (per-session hook events
  with `session_id`, typed notifications, the status line) is documented in the
  agent's own reference; every claim traces to it. No product needed.
 - **Distinct from pair 1.** Done-signal owns "one agent, is it finished";
  waiting-on-permission owns "one agent, why is it blocked". This page owns
  "several agents, which one needs me" — the phrase, the evidence, and the
  mechanism (typed Notification matchers, `session_id`, status line) do not
  overlap pair 1's.
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeAI 1xmzp2n — "How do you keep track of multiple coding agents running in parallel?" | 2026-11-03 | The exact question as a fresh thread: "How do you notice when one is waiting, done, or stuck?"; two commenters independently: agents "sat waiting on a permission prompt while I was deep in the third", idle "long enough that I lost the thread of what I had asked it to do" |
 | r/ClaudeCode 1xh5cum — "Four months of 50+ parallel agent threads a day" | 2026-10-27 | "The limit moved from tokens to my attention"; "fifty a day add up to something I could feel by Friday" |
 | r/ClaudeCode 1xdjb2g — "How many sessions can you run before you become the bottleneck?" | 2026-10-23 | 72 comments; the thread went to compute and left the attention half open |
 | r/ClaudeCode 1xipsk0 — "~40 Claude Code agents unattended for a month" | 2026-10-29 | "The six hours of silence was the real problem, not the dialog itself" |
 | r/ClaudeCode 1xk0ghj — "multiple agents working on multiple projects" | 2026-10-31 | "If every decision routes through you, you're the bottleneck agents were meant to eliminate" |
 | Hacker News 50298436 (herdr launch) | 2026-10-30 | A 30-year tmux user's stated switch reason: "visual indication which agent is working and which is waiting for an input" — used in rationale only; the page does not name any tool |
 All rows live in `drafts/listening.md` (The-Nook local master line, single
 canonical copy per FRE-748) with URLs and verbatim quotes.
 ## Gates before this page ships
 1. **Sponsor fact-check** of the claims table in `copy.md` (owner: Michael
   Freno). Page moves `drafts/` → `pending/` → `approved/` on his read, per
   the marketing tree's hard rule.
 2. **CTO eyes on the agent-behaviour claims** — five doc-sourced claims
   (hooks reference ×4, statusline doc ×1), all re-read 2026-11-05. Routed to
   the CTO per the FRE-199 plan.
 3. **Publish path:** `approved/` → a human places it on nook.freno.me.
   Nothing posts itself.
 ## Ban compliance (FRE-199 + positioning.md rule 1)
 - The Nook: not named. The notch, the island, the companion: not mentioned.
 - Competitors: not named. The herdr evidence is rationale-only; the page's
  "what to check" recommends no tool at all — states and wiring, not products.
 - Claude Code is named only as the subject whose documented behaviour the page
  explains, with its own docs as the source — same status as pair 1.
 - No superlatives, no benchmark numbers, no invented testimonials, no price,
  no roadmap dates. Anecdotes are real threads, described without handles.
 ## Cadence note
 Second pair. Queue behind it: the run-without-asking cluster (same pair), the
 fan-control phrase, and the invisible-permission variants — above the
 three-candidate floor. Two a week holds.
--- a/marketing/approved/agent-run-without-asking/copy.md
+++ b/marketing/approved/agent-run-without-asking/copy.md
@@ -0,0 +1,102 @@
 # Should you let your coding agent run without asking permission?
 > **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 pair 2
 > fact-check card, verdict: "Approve both — move to approved/"). Not published;
 > a human places it on nook.freno.me from `approved/`. Internal target:
 > Mon 2026-11-09, met four days early. This page never names a product of ours
 > and never names a competitor.
 > CTO review 2026-11-05: changes requested and applied — the `Bash(git commit *)`
 > allowed / `Bash(git push *)` denied example removed (the docs' own
 > "What a Bash rule doesn't match" table shows a Bash rule does not stop every
 > invocation); the precedence claim stands.
 You can — and the honest answer is that "should" is not one decision but two:
 what you are letting it do, and what happens when it does the wrong thing.
 Every operator who runs agents unattended converges on the same split — a free
 hand on what git can undo, a confirmation on what it can't — and the agent's
 own permission modes exist to draw that line somewhere you choose, not
 somewhere a flag chooses for you.
 ## The mechanism: a spectrum, not a switch
 Claude Code's permission modes form a ladder from "ask for everything" to "ask
 for almost nothing", and each rung has a documented meaning:
 - **`default`** prompts on the first use of each tool.
 - **`acceptEdits`** auto-accepts file edits and common filesystem commands
  (`mkdir`, `touch`, `mv`, `cp`) inside the working directory.
 - **`plan`** reads files and runs read-only shell commands but does not edit
  your source files — the agent explores, you approve the plan.
 - **`auto`** runs without routine prompts; before actions such as shell
  commands and network requests run, a background classifier checks that they
  align with your request.
 - **`bypassPermissions`** skips permission prompts, except for actions no mode
  auto-approves.
 Two documented facts should shape where you stop on that ladder. First, the
 docs' own warning on the top rung: in `bypassPermissions` mode Claude Code
 skips prompts — including for writes to protected paths such as `.git` — and
 the mode belongs "in isolated environments like containers or VMs where Claude
 Code can't cause damage". Second, enforcement is real, not advisory: the docs
 state plainly that "permission rules are enforced by Claude Code, not by the
 model" — a `CLAUDE.md` instruction asking nicely for permission changes
 nothing.
 ## What to check or do
 1. **Decide by blast radius, not by annoyance.** The question "how do I get
   fewer prompts?" tempts a jump to the top of the ladder. The better
   question: which of this agent's actions would be *undoable* if wrong? Edits
   inside a git worktree are; `rm -rf` on the wrong path, a pushed commit, and
   a message sent to a third party are not.
 2. **Move down the ladder one rung at a time.** `acceptEdits` in a worktree
   covers most of the prompt volume with the undo still in reach. If you
   consider `auto` or `bypassPermissions`, the docs' own container-or-VM
   condition is the bar: isolation first, autonomy second.
 3. **Write the rules instead of trusting the mode.** Rules are evaluated in
   order — deny, then ask, then allow — and the first match wins, so a broad
   deny holds even against a narrower allow. (What a Bash rule cannot do is
   match every way the same binary gets invoked — see the next step.)
 4. **Know what the rules do not cover.** A Bash rule matches the command text
   Claude writes, and the docs are explicit that this "isn't a security
   boundary around the program" — the same binary invoked by another path is
   not matched. For filesystem and network enforcement that does not depend
   on command text, the docs point at sandboxing.
 5. **Use hooks as the programmable layer.** A `PreToolUse` hook sees every
   tool call before it runs and can return a `deny` decision — the reference
   builds one that blocks `rm -rf`. A silent hook does not approve anything;
   the call just continues through the normal permission flow.
 6. **Leave the failure path a way to reach you.** An unattended run that hits
   a prompt nobody sees stops silently — that is the failure mode of unattended
   work, not of permissions. Whatever mode you pick, wire the
   "waiting on you" event somewhere you will actually notice.
 One next step: write down the three actions your agent takes that you could
 not undo, and put them in `deny` or `ask` rules today. Whatever mode you run
 above them, those three now require a human — which is the whole point of the
 ladder.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about Claude
 Code's behaviour come from its own documentation, re-read 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | Mode meanings: `default` prompts on first use; `acceptEdits` auto-accepts file edits and common filesystem commands (`mkdir`, `touch`, `mv`, `cp`) in the working directory; `plan` reads files and runs read-only shell commands but doesn't edit source; `auto` runs without routine prompts with a background classifier checking alignment; `bypassPermissions` skips prompts except actions no mode auto-approves | Claude Code permissions doc — https://code.claude.com/docs/en/permissions (Permission modes table) |
 | 2 | Docs' warning: in `bypassPermissions` mode Claude Code skips prompts including for writes to protected paths such as `.git`; "Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage" | same permissions doc (warning under the modes table) |
 | 3 | "Permission rules are enforced by Claude Code, not by the model" | same permissions doc (note under Manage permissions) |
 | 4 | Rules evaluated in order deny → ask → allow; first match wins; a broad deny holds against a narrower allow | same permissions doc (Manage permissions) |
 | 5 | A Bash rule matches the command text Claude writes and "isn't a security boundary around the program" (`Bash(curl *)` doesn't stop `/usr/bin/curl …`); for filesystem/network enforcement independent of command text the docs point at sandboxing | same permissions doc (What a Bash rule doesn't match) |
 | 6 | A `PreToolUse` hook fires before a tool call executes, can block it, and can return a `permissionDecision` of `"deny"`; the reference builds a hook that blocks `rm -rf`; a silent hook does not approve — the call continues through the normal permission flow | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (PreToolUse decision control walkthrough) |
 | 7 | Undo-split practice ("free hand on what git can undo, confirmation on what it can't") | r/ClaudeCode 1xkoz06 (2026-10-31), commenter's described practice, logged in `drafts/listening.md` Scan 3 addendum; also r/ClaudeCode 1xexhwf commenters (VM, worktrees, blast-radius split). Described as operator practice, not a rule. |
 | 8 | An unattended run that hits a prompt nobody sees stops silently | r/ClaudeCode 1xipsk0 (2026-10-29), commenter: "A run started from launchd or a background service can hit a prompt that no one will ever see", logged in `drafts/listening.md` Scan 2. |
 | 9 | The trust asymmetry: comfortable with a model writing code, "considerably less comfortable giving an autonomous agent broad access to my development environment" | r/ClaudeCode 1xk8imc (2026-10-31, "Has anyone built a safe, autonomous coding workflow…?", 43 comments), OP's words, logged in `drafts/listening.md` Scan 4. |
 | 10 | The operator's own safety menu: "committing before every run? containers? `--dangerously-skip-permissions` and hoping?" | r/ClaudeAI 1xk277d (2026-10-31, "How often has a coding agent done something you had to undo?"), OP's words, logged in `drafts/listening.md` Scan 4. Quoted as the question's shape, not as guidance. |
 **Ban compliance:** no product of ours named · no competitor named · no
 handles · no superlatives · no benchmark numbers · no invented testimonials ·
 no price · no roadmap dates. The docs' container/VM warning is quoted as the
 agent's own documentation, not as our policy.
--- a/marketing/approved/agent-run-without-asking/rationale.md
+++ b/marketing/approved/agent-run-without-asking/rationale.md
@@ -0,0 +1,75 @@
 # Rationale — "Should you let your coding agent run without asking permission?"
 FRE-199 item 1, page 2 of the second pair. Drafted 2026-11-05 by CMO (internal
 target Mon 2026-11-09, beaten by four days).
 ## The phrase
 Primary: **"do you let your coding agent run without asking permission"**
 (variants: "safe autonomous coding workflow", "approve every step or skip
 permissions", "is dangerously-skip-permissions safe").
 On the standing phrase list (`drafts/listening.md` §The phrase list: "do you
 let claude code run without asking").
 ## Why this phrase won the slot
 - **Recurrence with independence.** Four separate threads state the autonomy
  question from four angles: the direct one (1xexhwf, 24 comments), the trust
  asymmetry (1xk8imc, 43 comments), the safety menu (1xk277d), and the
  remove-permissions ask (1xfe6eh — Desktop, recorded, not answered). The
  cluster has run continuously since Scan 1.
 - **Buying intent.** These are people configuring or rejecting autonomy right
  now — the objection vocabulary came straight out of this cluster
  ("--dangerously-skip-permissions and hoping").
 - **Answerable honestly, generically.** The mode ladder, the docs' own
  container/VM warning, the enforcement note, and `PreToolUse` deny are all
  documented; every claim traces to the agent's docs. No product needed.
 - **Distinct from pair 1's permission page.** `agent-waiting-on-permission`
  answers "why is it *blocked* and why didn't I know" — the visibility of a
  single stuck prompt. This page answers "should I *grant* autonomy and how do
  I bound it" — the mode ladder, rule precedence, sandboxing, and hooks as
  enforcement. Shared vocabulary (modes, rules) exists because the docs are
  one system; the question, the claims, and the advice do not overlap.
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeCode 1xexhwf — "Do you let Claude Code run without asking, or approve every step?" | 2026-10-25 | The direct question, 24 comments; the thread became a safety argument (VM, worktrees, empty-variable `rm -rf`) — that argument *is* the page's subject |
 | r/ClaudeCode 1xk8imc — "Has anyone built a safe, autonomous coding workflow…?" | 2026-10-31 | "Comfortable having another model work on code. Considerably less comfortable giving an autonomous agent broad access to my development environment" — the trust asymmetry, 43 comments |
 | r/ClaudeAI 1xk277d — "How often has a coding agent done something you had to undo?" | 2026-10-31 | "What you do to stay safe today: committing before every run? containers? `--dangerously-skip-permissions` and hoping?" — the operator's own menu |
 | r/ClaudeCode 1xipsk0 — "~40 agents unattended for a month" | 2026-10-29 | "A run started from launchd or a background service can hit a prompt that no one will ever see" — the unattended failure path |
 | r/ClaudeCode 1xkoz06 | 2026-10-31 | The undo-split practice (also cited on pair 1; real thread, described without handles) |
 | r/ClaudeAI 1xfe6eh — "How can I remove Claude's need to ask me for permission…" | 2026-10-30 | Recorded, not used: Claude Desktop computer-use, not Code — a mention there would be noise. Shows the phrase's reach |
 All rows live in `drafts/listening.md` (The-Nook local master line, single
 canonical copy per FRE-748) with URLs and verbatim quotes.
 ## Gates before this page ships
 1. **Sponsor fact-check** of the claims table in `copy.md` (owner: Michael
   Freno). Page moves `drafts/` → `pending/` → `approved/` on his read.
 2. **CTO eyes on the agent-behaviour claims** — six doc-sourced claims
   (permissions doc ×5, hooks reference ×1), all re-read 2026-11-05. Routed to
   the CTO per the FRE-199 plan.
 3. **Publish path:** `approved/` → a human places it on nook.freno.me.
   Nothing posts itself.
 ## Ban compliance (FRE-199 + positioning.md rule 1)
 - The Nook: not named. The notch, the island, the companion: not mentioned.
 - Competitors: not named. Sandboxing and hooks are described as the agent's
  own documented mechanisms, not as anyone's product.
 - Claude Code is named only as the subject whose documented behaviour the page
  explains, with its own docs as the source — same status as pair 1.
 - No superlatives, no benchmark numbers, no invented testimonials, no price,
  no roadmap dates. Anecdotes are real threads, described without handles.
 ## Cadence note
 Second pair. Queue behind it: the fan-control phrase ("mac fan control
 claude", standing phrase list), the invisible-permission variants
 (dontallow/TCC cluster), and the notification-reliability thread (1xm6frp,
 held back for overlap with done-signal). Above the three-candidate floor; two
 a week holds.
--- a/marketing/approved/agent-waiting-on-permission/copy.md
+++ b/marketing/approved/agent-waiting-on-permission/copy.md
@@ -0,0 +1,86 @@
 # Why is my coding agent sitting on a permission prompt?
 > **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 fact-check
 > card, verdict: "Approve both — move to approved/"). Not published; a human
 > places it on nook.freno.me from `approved/`.
 > This page never names a product of ours and never names a competitor.
 > Internal target: second page of the FRE-199 pair, Fri 2026-11-07.
 > CTO review 2026-11-05: changes requested and applied — rule precedence
 > corrected to deny / ask / allow (body previously read allow / ask / deny,
 > contradicting the fact-check table and the source); pair-1 citations
 > standardised to code.claude.com.
 Because it tried to do something its permission settings don't allow, and the
 default is to wait — indefinitely and quietly — for you. The prompt is not the
 expensive part; the hour you spent not knowing it was waiting is. The way out is
 not to approve faster, it's to make the prompts rare and the waiting visible.
 ## The mechanism
 Claude Code's permission system decides, per tool call, whether to run, refuse,
 or stop and ask. In its `default` mode, it prompts for permission on the first
 use of each tool. Modes are set with `defaultMode` in the settings files, and a
 session's rules come from deny / ask / allow lists evaluated in that order —
 the first match wins.
 You can see the whole rule set at any time with `/permissions`, which lists
 every permission rule and the settings file each one came from. Rules can name
 a specific use — `Bash(npm run build)` matches exactly that command — or a
 wildcard, like `Bash(git log *)`.
 So the prompt you came back to an hour later is not a malfunction. It is the
 system working as configured, on a call your rules never covered — and the
 "waiting" state being invisible is what turned ten seconds of approval into a
 lost hour.
 ## What to check or do
 1. **Read the prompt before automating it away.** It names the tool and the
   input. The right response to "it keeps asking" is usually a rule, not a
   wider mode.
 2. **Allowlist the undoable, prompt on the irreversible.** Reads, tests, and
   status commands are safe to allow — `git` is the undo for edits. Anything
   that reaches another person or another system — network calls, deletes,
   deploys — is worth keeping on ask. Rule syntax is in the permission docs;
   `/permissions` shows what you already have.
 3. **Consider `acceptEdits` before anything broader.** It auto-accepts file
   edits and common filesystem commands inside the working directory. That is
   usually the difference between ten prompts a session and two — without
   handing over network or delete.
 4. **Bound the blast radius instead of removing the gate.** If you do widen
   what runs unattended, do it where a mistake is recoverable: a worktree per
   task, commits pushed early, nothing irreversible in reach. Operators who run
   agents unattended describe exactly this split — free hand on what git can
   undo, confirmation on what it can't.
 5. **Make the wait visible.** Claude Code fires a `Notification` hook when it
   sends a notification, and a permission prompt is one — the payload carries a
   `notification_type` of `permission_prompt`. A hook on that event, wired to a
   desktop notification you'd see from another window, turns the silent wait
   back into a ten-second approval.
 One next step: run `/permissions` today and add allow rules for the three
 commands you find yourself approving most. The prompts that remain will be the
 ones that deserve a read.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about Claude
 Code's behaviour come from its own documentation, re-read 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | In `default` mode Claude Code "prompts for permission on first use of each tool" | Claude Code permissions doc — https://code.claude.com/docs/en/permissions (Permission modes table) |
 | 2 | `defaultMode` in settings files sets the default mode for new sessions | same permissions doc (Permission modes section) |
 | 3 | Rules are evaluated deny → ask → allow, first match wins | same permissions doc (Permission rule syntax) |
 | 4 | `/permissions` lists all permission rules and the settings.json each comes from | same permissions doc (Manage permissions) |
 | 5 | `Bash(npm run build)` matches the exact command; `Bash(git log *)` wildcard form | same permissions doc (Use specifiers for fine-grained control) |
 | 6 | `acceptEdits` "automatically accepts file edits and common filesystem commands such as mkdir, touch, mv, cp for paths in the working directory" | same permissions doc (Permission modes table) |
 | 7 | A `Notification` hook fires when Claude Code sends a notification; permission prompts carry `notification_type: "permission_prompt"` and a message like "Claude needs your permission" | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (Notification event) |
 | 8 | Undo-split practice ("free hand on what git can undo, confirmation on what it can't") | r/ClaudeCode 1xkoz06 (2026-10-31, u/tomm3hshipp thread), commenter's described practice, logged in `drafts/listening.md` Scan 3 addendum. Described as one operator's approach, not a rule. |
 | 9 | The 55-minutes-lost framing | r/ClaudeAI 1xhbc71 (2026-10-28): "coming back an hour later to find it's been sitting on a permission prompt for 55 minutes". Used as the problem's shape, not quoted as a person. |
 **Ban compliance:** no product of ours named · no competitor named · no
 superlatives · no benchmark numbers · no invented testimonials · no price · no
 roadmap dates.
--- a/marketing/approved/agent-waiting-on-permission/rationale.md
+++ b/marketing/approved/agent-waiting-on-permission/rationale.md
@@ -0,0 +1,77 @@
 # Rationale — "Why is my coding agent sitting on a permission prompt?"
 FRE-199 item 1, page 2 of the first pair. Drafted 2026-11-05 by CMO.
 ## The phrase
 Primary: **"claude code waiting for permission"** and the away-from-desk variant
 ("approvals when you're away from the computer"). First phrase on the standing
 list (`drafts/listening.md` §The phrase list).
 ## Why this phrase won the slot
 - **The strongest single thread in the backlog.** r/ClaudeAI 1xhbc71 (2026-10-28,
  47 comments and moving) asks the buying question outright: kicked off a long
  task, came back an hour later, agent had been sitting on a permission prompt
  for 55 minutes. The thread's own answers (remote control, tmux+SSH,
  skip-permissions, allowlists) prove demand; none of them makes the wait
  visible at the machine — that is the honest gap this page answers without
  naming anyone.
 - **The week's objection vocabulary.** Scans 1–9 keep returning "the model keeps
  handing control back" and "stops and waits for me" — permission friction is
  the category's core complaint, not a niche one.
 - **Recurring independent accounts.** The invisible-permission theme has three
  independent accounts in one week (1xksutq — gh used without a visible prompt;
  1xkejsp's Linux panel; the scheduled-tasks silent-stall finding), so the
  search demand is not one loud thread.
 - **Wedge-aligned.** This is the literal wedge sentence's territory — "an agent
  blocked on a permission prompt is the most expensive kind of idle" — answered
  with the agent's own documented mechanism.
 ## Deliberate scoping
 This page owns the **blocked-half** of the approval problem (why prompts happen,
 how to make them rare, how to make the wait visible at the machine). The
 **away-half** (controlling a remote agent from elsewhere) is a different phrase,
 a different page, and one where the honest answer is dominated by the agent
 vendor's own remote feature — the page deliberately does not go there
 (`drafts/listening.md` Scan 1 category intel #1).
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeAI 1xhbc71 — "How do you handle Claude Code approvals when you're away from your computer?" | 2026-10-28 | 55-minute wait on a permission prompt; 47 comments of demand; "what's still annoying about your setup?" |
 | r/ClaudeCode 1xkoz06 — "How permissive are you with AI and for how long?" | 2026-10-31 | The undo-split: "file edits, tests and branches get a free hand, since git is the undo. Anything that reaches another person … stays on confirm" |
 | r/ClaudeCode 1xksutq — gh used without visible prompt | 2026-11-01 | Third independent invisible-permission account of the week |
 | r/ClaudeCode 1xkejsp — Linux panel app | 2026-10-31 | Per-session "Needs You" differentiation shipping elsewhere; the need is real and cross-platform |
 All rows live in `drafts/listening.md` with URLs and verbatim quotes.
 ## Gates before this page ships
 1. **Sponsor fact-check** of the claims table in `copy.md` (owner: Michael
   Freno); page moves `pending/` → `approved/` on his read.
 2. **CTO eyes on the agent-behaviour claims** — all eight doc-sourced claims
   re-read 2026-11-05; the FRE-199 plan routes anything asserted about an
   agent's behaviour to the CTO.
 3. **Publish path:** `pending/` → `approved/` → a human places it on
   nook.freno.me (blog route). Nothing posts itself.
 ## Ban compliance (FRE-199 + positioning.md rule 1)
 - The Nook: not named; notch/island/companion not mentioned.
 - Competitors: not named — including the agent vendor's remote feature, which
  the page never needs to mention because it stays on the at-the-machine half.
 - Claude Code is named only as the subject whose documented permission system
  the page explains, with its own docs as the source — same status the
  listening phrase list already gives it.
 - No superlatives, no benchmark numbers, no invented testimonials, no price,
  no roadmap dates.
 ## Cadence note
 Second page of the first pair. Queue behind it: multi-agent tracking ("How do
 you keep track of multiple coding agents running in parallel?", 1xm6frp,
 2026-11-03) and the invisible-permission cluster — the queue holds above the
 three-candidate floor, so the two-a-week cadence holds.
--- a/marketing/briefs/registry-wave-2.md
+++ b/marketing/briefs/registry-wave-2.md
@@ -0,0 +1,91 @@
 # Registry wave 2 — brief and copy (FRE-199 item 3)
 **Owner:** CMO prepares · sponsor submits · **Copy ready 2026-11-05** (target was
 Fri 2026-11-13) · **Submit:** week of 2026-11-16, after the wave-1 readback.
 **Status:** `briefs/` — nothing here has been posted; humans hold every account;
 no agent authenticates, posts or sends.
 ## What wave 2 is, and what it waits for
 Wave 1 is FRE-207's packet (`The-Nook` worktree `drafts/directory-submissions.md`
 + `drafts/click-list.md`): 8 targets, CTO claim verdict applied 2026-11-01
 (C1–C5 signed, C7 refused → relay sentence), sponsor-owned inputs G2 (price
 line), G3 (`@freno.me` mailbox), G4 (screenshots). **Wave-2 submission waits on
 the wave-1 readback** — what actually got submitted, what got listed, what was
 rejected and why — so targets can be re-ranked on evidence instead of guesswork.
 The readback lives on the FRE-207 issue; this brief is ready either way.
 **Copy rule inherited from wave 1:** paste the wave-1 blocks, do not improvise.
 Only claims signed by the CTO verdict ship:
 - C1 — works with 18 coding agents (compatibility fact, not a competitor mention).
 - C2 — answer an agent's approval from your Mac, iPhone or Watch.
 - C3 — sessions keep arriving while the Mac app is closed (widgets; fleet status only).
 - C4 — macOS 14.2+, universal.
 - C5 — iPhone/iPad and Apple Watch companions are **TestFlight beta**; no App Store link anywhere.
 - C7 — "no cloud service of its own" is refused; block D ships the relay sentence.
 - **Price line (G2):** "Free 14-day trial" only — no number — until CoS + sponsor
  clear the "$10 one-time licence" line for public listings (FRE-204 holds $10 in-app;
  the listing text is a separate publish decision).
 - Banned: superlatives, user counts, testimonials, competitor names.
 ## Targets — fetched live 2026-11-05, marked per the wave-1 legend
 | # | Target | What it is | How it ships | Fit | Verified |
 |---|---|---|---|---|---|
 | W2-1 | `iCHAIT/awesome-macOS` (19.4k ★) | Curated macOS app list; PR-based | PR adding one line to the relevant section from `contributing.md`; copy: block A + block B compressed | High — category fit, persistent link | ✅ repo + contributing rules read 2026-11-05 |
 | W2-2 | 1000.tools | Curated tool directory, self-serve categories (AI, developer tools, productivity) | Category submission form; copy: block A + B | Medium-high | ✅ fetched 2026-11-05 (categories listed on page) |
 | W2-3 | uneed.best | Daily product launch site | Launch submission (account needed, held by a human) | Medium — launch-format, needs assets | ✅ fetched 2026-11-05 |
 | W2-4 | devhunt.org | Daily dev-tool launches | Launch submission | Medium | ✅ fetched 2026-11-05 |
 | W2-5 | Product Hunt | Launch site | Maker/hunter flow, on-screen (403 to plain fetch — read live before filing) | Low-medium this wave; big-audience launch usually wants FRE-203's launch-day coordination | ⚠️ bot-walled; fields read on screen |
 Re-rank after the wave-1 readback: if directory listings (wave-1 §1/§3–5)
 produced traffic or referrers, wave 2 leads with W2-1/W2-2; if nothing was
 submittable, wave 2 waits until G3/G4 clear rather than submitting half-copy.
 ## Copy — paste-ready, inheriting the signed claims only
 **One-liner (≤60):** `Your coding agents, at the edge of the screen` (43 chars — wave-1 block A).
 **Short description (~250 chars):** wave-1 block B verbatim; if a field forces a
 price, "Free 14-day trial" and no number (G2).
 **awesome-macOS PR line (one row, section: menu-bar / status-bar apps or the
 section the maintainers route notch apps to — read the README section headers
 before filing):**
 ```
 - [The Nook](https://nook.freno.me/) - Puts every coding-agent session at the
  edge of your screen and lets you answer approvals from your Mac, iPhone or
  Watch. Works with 18 coding agents. [![Open-Source Software][OSS Icon]] — not
  open source; omit the badge row, keep the description.
 ```
 (The badge syntax is copied from the list's own rows; The Nook is not open
 source, so the OSS badge is **omitted** — the line above shows the shape only.
 No TestFlight mention needed in a one-row listing; add "Companions for iPhone
 and Apple Watch (TestFlight beta)" only if the PR reviewer asks for platform
 detail — C5 wording.)
 **Launch-site fields (W2-3/W2-4):** wave-1 blocks A, B, C (widgets — fleet
 status only), D (relay sentence, not C7's refused wording). Gallery needs G4's
 three real screenshots.
 ## Gates before anything here is submitted
 | Gate | Owner | State |
 |---|---|---|
 | Wave-1 readback recorded (what submitted/listed/rejected) | sponsor → FRE-207 issue, carried to FRE-199 | owed before submission week |
 | G2 price line for public listings | CoS + sponsor | pending (copy ships without a number either way) |
 | G3 `hello@freno.me` mailbox | sponsor | pending |
 | G4 three real screenshots + logo PNG | sponsor or CTO | pending — blocks every upload field |
 | Claim sign-off | CTO | **cleared 2026-10-31** for C1–C5; C7 ships as the relay sentence |
 ## Provenance
 - Targets fetched 2026-11-05: uneed.best, devhunt.org, 1000.tools (HTTP 200,
  content read); `iCHAIT/awesome-macOS` via GitHub API (19,441 stars,
  contributing.md linked from README); producthunt.com returns 403 to a plain
  fetch — marked ⚠️, read on screen before filing.
 - All claims inherited from FRE-207's CTO verdict of 2026-10-31 — no new
  claims introduced by this brief.
--- a/marketing/drafts/agent-keeps-asking/copy.md
+++ b/marketing/drafts/agent-keeps-asking/copy.md
@@ -0,0 +1,96 @@
 # Why does your coding agent keep stopping to ask you questions?
 > **Status: draft — awaiting sponsor fact-check** (FRE-199 pair 3, internal target
 > Thu 2026-11-12). Not publishable from `drafts/`.
 > This page never names a product of ours and never names a competitor.
 Most of the stopping is not the model being chatty — it is the permission system
 doing what it was told. In the default mode, the agent prompts before the first
 use of each tool; separately, its turn ends every time it finishes responding,
 and ending a turn with a question is finishing a turn. You cannot and should not
 eliminate every ask — but you can decide, once, which asks deserve an
 interruption and let the routine ones pass without you.
 ## Where the asks come from
 **Permission gates.** In the default mode the agent "prompts for permission on
 first use of each tool" — so every new tool, and often every new command shape,
 costs one prompt. The configuration decides who answers:
 - **`acceptEdits`** automatically accepts file edits and common filesystem
  commands (like `mkdir`, `touch`, `mv`, `cp`) for paths in your working
  directory — the single biggest ask category for most coding sessions, gone.
 - **Permission rules** do the fine work: `deny` rules block a tool outright,
  `allow` rules pass it silently, `ask` rules force the prompt. Order matters:
  rules are evaluated deny, then ask, then allow — the first match wins, and an
  allow rule cannot carve an exception out of a deny.
 - **Modes set the floor.** `defaultMode` in your settings picks where every new
  session starts. At the far end, `bypassPermissions` skips prompts entirely —
  the docs' own warning is that it belongs only in isolated environments like
  containers or VMs.
 One fact worth internalising: permission rules are enforced by the coding
 agent's harness, not by the model. A line in your prompt asking it to "not ask"
 changes nothing about what it is allowed to do — the configuration is the only
 lever.
 **Turn ends.** A `Stop` hook fires when the agent finishes responding — every
 turn, including the turns that end in a question. From the terminal's side of
 the glass, "it finished", "it's asking me something" and "it's waiting on a
 permission prompt" are the same silence. That is why the asking *feels*
 endless: each ask costs a context switch, and nothing distinguishes the asks
 from the completions.
 Practitioners describe the pattern in their own words. A developer who measured
 why their sessions kept stopping found that the agent "just kept handing
 control back" even with a permissive mode already on — the model's own habit of
 ending turns to stay in the loop, on top of the permission asks. An operator
 running a team of agents with per-agent autonomy levels put the other side:
 "if every decision routes through you, you're the bottleneck agents were meant
 to eliminate."
 ## What to check or do
 1. **Sort the asks by kind before touching anything.** File edits in your
   working directory: `acceptEdits` removes them wholesale. The same safe
   command every session: an `allow` rule. The commands that must never run: a
   `deny` rule. What is left is the set of questions only you can answer.
 2. **Write the rules in the right order.** Deny, then ask, then allow; first
   match wins. A broad deny stays broad — narrowing an allow elsewhere does not
   soften it.
 3. **Keep the genuinely ambiguous asks.** A mode that asks less is not a mode
   that asks smarter. `bypassPermissions` in a throwaway container is a
   documented pattern for unattended runs; using it on your daily machine is
   the docs' own caution, not a recommendation.
 4. **Make every stop visible.** Because every stop ends a turn, wire the
   turn-end and notification moments (the `Stop` and `Notification` hooks) so
   an ask reaches you where you actually are — and a permission wait is
   distinguishable from a finished job.
 One next step: run one session with the asks tallied by kind — edits, known
 commands, everything else. The first two usually turn out to be rules you
 hadn't written yet; the third is the work.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about the
 permission system and hooks were verified against the live docs on 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | Default mode "prompts for permission on first use of each tool" (labeled Manual; `manual` alias) | Claude Code permissions doc — https://code.claude.com/docs/en/permissions (permission modes table; fetched 2026-11-05) |
 | 2 | `acceptEdits` "automatically accepts file edits and common filesystem commands such as mkdir, touch, mv, and cp for paths in the working directory or additionalDirectories" | same page (permission modes table) |
 | 3 | Rules are evaluated in order deny, then ask, then allow; "the first match in that order determines the outcome"; "an allow rule can't carve an exception out of a deny rule" | same page (rule precedence section) |
 | 4 | `bypassPermissions` "skips permission prompts"; docs' caution: "Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage" | same page (permission modes table) |
 | 5 | `defaultMode` in settings files sets the default permission mode for new sessions | same page ("To change the default permission mode for new sessions, set defaultMode in your settings files") |
 | 6 | "Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows." | same page (verbatim) |
 | 7 | `Stop` fires when the agent finishes responding; hook cadence is per turn | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (verified 2026-11-05 in FRE-199 round 1; unchanged) |
 | 8 | Anecdote: "it just kept handing control back"; sessions kept stopping with a permissive mode on | r/ClaudeCode thread 1xlfqmo ("I measured why my Claude Code sessions kept stopping…", 2026-11-01, u/belovoj), logged in `drafts/listening.md` Scan 5 #1. Quoted as one developer's described experience; the thread's own measurement figures are deliberately **not** cited. |
 | 9 | Anecdote: "if every decision routes through you, you're the bottleneck agents were meant to eliminate"; per-agent autonomy levels 0–5 | r/ClaudeCode thread 1xk0ghj ("multiple agents working on multiple projects", 2026-10-31, quote by u/iceydee), logged in `drafts/listening.md` Scan 4 #2. One operator's described practice. |
 **Ban compliance:** no product of ours named · no competitor named · no
 superlatives · no benchmark numbers (the 1xlfqmo poster's measurement figures
 are deliberately not cited) · no invented testimonials (anecdotes are real
 threads, described without handles) · no price · no roadmap dates.
--- a/marketing/drafts/agent-keeps-asking/rationale.md
+++ b/marketing/drafts/agent-keeps-asking/rationale.md
@@ -0,0 +1,52 @@
 # Rationale — "Why does your coding agent keep stopping to ask you questions?"
 FRE-199 item 1, page 2 of the third pair. Drafted 2026-11-06 by CMO (internal
 target Thu 2026-11-12 — six days early).
 ## The phrase
 Primary: **"why does my coding agent keep stopping to ask me questions"**
 (variants: "agent keeps handing control back", "claude code keeps asking for
 permission"). The H1 carries the generic form; "handing control back" is the
 backlog's own added phrase (Scan 5's phrase-list finding).
 ## Why this phrase won the slot
 - **Backlog evidence.** r/ClaudeCode 1xlfqmo (2026-11-01, Scan 5 #1): "Auto mode
  was already on, so permissions weren't the issue… it just kept handing
  control back"; "the model was forcably trying to keep me in the loop." The
  phrase-list finding from the same scan added "handing control back" as a
  standing query. Corroborated by 1xlxw0q (turns ending with "nothing yet") and
  the autonomy-ladder operator (Scan 4 #2, thread 1xk0ghj: "if every decision
  routes through you, you're the bottleneck agents were meant to eliminate").
 - **Shortlist position (c)** in the plan's pair-3 shortlist, recorded at
  revision 5 — the page extends the done-signal cluster (pair 1) with the
  handback half. The distinction is kept deliberately: *agent-done-signal*
  owns "how do I know it's done"; this page owns "why does it keep stopping on
  me". Different question, different searcher.
 - **Answerable honestly from verified sources only.** Every mechanism claim
  re-reads to the permissions doc and hooks reference — the same pages and the
  same claims the CTO verified in FRE-199 rounds 1–2 (mode ladder, precedence,
  acceptEdits scope, enforced-by-harness sentence, Stop cadence). Nothing new
  is asserted about agent behaviour.
 ## What the page deliberately does not do
 - **Does not cite the 1xlfqmo poster's measurement figures** (the 28-of-73
  sample is the poster's own 18-day data, and the backlog row carries an
  explicit do-not-cite flag). The anecdote is quoted as experience, not
  measurement, and the fact-check table says so.
 - Does not promise the asks can be eliminated. The honest answer is that the
  asking is partly the permission system working as configured and partly the
  agent ending turns to stay in the loop — the page sorts which is which.
 - Does not touch environment contention (page 1 of this pair owns that half).
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeCode 1xlfqmo — "I measured why my Claude Code sessions kept stopping" | 2026-11-01 | "It just kept handing control back" with a permissive mode on; "forcibly trying to keep me in the loop" — the model-behaviour half |
 | r/ClaudeCode 1xk0ghj — "multiple agents working on multiple projects" (quote by u/iceydee) | 2026-10-31 | "If every decision routes through you, you're the bottleneck agents were meant to eliminate"; per-agent autonomy levels 0–5 — the configuration half |
 | r/ClaudeAI 1xlxw0q — "2,300 hours waiting" | 2026-11-02 | Turns ending in a one-word answer reload context each time — the per-ask cost, corroborating |
 All rows live in `drafts/listening.md` (The-Nook local master line).
--- a/marketing/drafts/agent-worktree-contention/copy.md
+++ b/marketing/drafts/agent-worktree-contention/copy.md
@@ -0,0 +1,72 @@
 # How do you manage worktrees when your agents end up waiting on each other?
 > **Status: draft — awaiting sponsor fact-check** (FRE-199 pair 3, internal target
 > Thu 2026-11-12). Not publishable from `drafts/`.
 > This page never names a product of ours and never names a competitor.
 Usually, the worktrees are not what your agents are waiting on — the environment
 they share is. Two agents can sit in two worktrees of the same repo and still
 queue up behind one dev server, one test database, one `docker compose` stack.
 The fix that scales is to multiply the environment per worktree, not to
 orchestrate the waiting.
 ## Why agents queue when the code doesn't
 Git supports parallel work out of the box: `git worktree add <path> <branch>`
 creates a second working directory linked to the same repository — shared
 history, but its own HEAD, its own index, its own checked-out branch. Git even
 enforces the ownership half for you: it refuses to check out a branch into a
 second worktree while the first one holds it.
 What git does not duplicate is everything the repo only *points at*: the dev
 server bound to port 3000, the database named after the project directory, the
 compose stack whose project name defaults to the folder you launched it from.
 Two agents in two worktrees that both bring up the same stack are two agents
 contending for one environment — and the queue looks like a worktree problem
 when it is an environment problem.
 Practitioners who hit this converge on the same verdict. One, in a thread
 asking this exact question: the queue "comes from having one test env, so I'd
 multiply the env instead of orchestrating the waiting."
 ## What to check or do
 1. **Give every worktree its own copy of the stack.** Docker Compose exists for
   exactly this: it uses a *project name* to isolate environments from each
   other, and names "multiple copies of a single environment, useful for
   running stable copies for each feature branch" as a use case. Set a unique
   one per worktree — the `-p` flag has top precedence, or use `name:` in the
   compose file — and the port and container-name collisions disappear.
 2. **Anything that cannot be multiplied, serialise on purpose.** One migration
   runner, one deploy target, one flaky hardware-in-the-loop device: put it
   behind a single serial step rather than letting two agents race it. A queue
   you chose is a queue you can reason about.
 3. **One branch, one worktree.** Git already refuses to check out the same
   branch in two worktrees; keep it that way. Two agents on one branch is a
   merge conflict waiting for both of them to finish.
 4. **Remember a fresh worktree starts unconfigured.** Env files, generated
   config and installed dependencies live in the worktree, not the repo — a new
   worktree is a new environment to set up, which is exactly why the per-worktree
   copy should be scripted, not hand-arranged.
 One next step: find the resource your agents contend for most often — usually
 the test stack — and give it a per-worktree project name. The waiting usually
 resolves before any queueing tool is needed.
 ---
 ## Fact-check table (not part of the page)
 Every technical claim above, with its primary source. Claims about git and
 Docker Compose were verified against the live docs on 2026-11-05.
 | # | Claim in the page | Source |
 |---|---|---|
 | 1 | `git worktree add <path> [<commit-ish>]` creates a worktree "linked to the current repository, sharing everything except per-worktree files such as HEAD, index, etc." | git worktree docs — https://git-scm.com/docs/git-worktree (COMMANDS › add; fetched 2026-11-05) |
 | 2 | `add` "refuses to create a new worktree when <commit-ish> is a branch name and is already checked out by another worktree" | same page (OPTIONS › `--force`) |
 | 3 | Compose "uses a project name to isolate environments from each other"; "multiple copies of a single environment, useful for running stable copies for each feature branch" is a named use case; precedence: `-p` flag > `COMPOSE_PROJECT_NAME` > `name:` attribute > directory basename | Docker Compose docs, "Specify a project name" — https://docs.docker.com/compose/how-tos/project-name/ (fetched 2026-11-05) |
 | 4 | Anecdote: "The queue comes from having one test env, so I'd multiply the env instead of orchestrating the waiting" | r/ClaudeCode thread 1xlz2bs ("How do you manage worktrees when your agents end up waiting on each other?", 2026-11-02, u/Roland_culait / u/First-Painter7431), logged in `drafts/listening.md` Scan 6 #4. Quoted as one commenter's described practice, not a measurement. |
 **Ban compliance:** no product of ours named · no competitor named · no
 superlatives · no benchmark numbers · no invented testimonials (the anecdote is
 a real thread, described without handles) · no price · no roadmap dates.
--- a/marketing/drafts/agent-worktree-contention/rationale.md
+++ b/marketing/drafts/agent-worktree-contention/rationale.md
@@ -0,0 +1,46 @@
 # Rationale — "How do you manage worktrees when your agents end up waiting on each other?"
 FRE-199 item 1, page 1 of the third pair. Drafted 2026-11-06 by CMO (internal
 target Thu 2026-11-12 — six days early).
 ## The phrase
 Primary: **"how do you manage worktrees when your agents end up waiting on each
 other"** — carried verbatim as the H1, because it is already a complete search
 phrase with the exact buying intent.
 ## Why this phrase won the slot
 - **Backlog evidence.** r/ClaudeCode 1xlz2bs (2026-11-02, ~15 h old at scan time,
  Scan 6 #4). The OP asked the question in its final words; the thread answered
  itself (env per worktree, `docker compose -p`, preview deploys, one serial
  step on main) — which is exactly what makes it page material: the demand is
  proven, the answer is proven, and the answer is generic.
 - **Shortlist position (a)** in the plan's pair-3 shortlist, recorded at
  revision 5. Scan 9 (2026-11-05) produced no new queue item, so the
  shortlist stands; selection finalised against that fresh scan as planned.
 - **Answerable honestly and generically.** Both mechanisms are documented
  primary sources (git worktree docs; Docker Compose project-name docs), both
  fetched and read 2026-11-05. No agent-behaviour claim is needed — this page
  is the lightest CTO-review lift of the shortlist.
 - **Wedge-adjacent without a mention.** "Waiting" is the cost our wedge names
  ("an agent blocked is the most expensive kind of idle"); this page owns the
  agent-on-agent half of waiting, which no existing page covers.
 ## What the page deliberately does not do
 - Does not cite the thread's own tooling (Orca, oyren.ai) or any workflow
  product — category nouns only.
 - Does not invent a measurement. The one quoted line is a commenter's described
  practice, logged in the backlog with a do-not-interpret flag.
 - Does not touch the approval surface (page 2 of this pair owns the
  attention/handback half; this page is environment contention only).
 ## Evidence trail
 | Thread | Date | What it showed |
 |---|---|---|
 | r/ClaudeCode 1xlz2bs — "How do you manage worktrees when your agents end up waiting on each other?" | 2026-11-02 | Exact phrase in the wild; self-answered with env-multiplication advice; "multiply the env instead of orchestrating the waiting" |
 | Watched-table corroboration (Scans 5–9) | 2026-11-02 → 11-05 | Repobs ("which sessions were waiting for me"), Orca (worktree orchestration daily driver), Worktrunk, Conductor.build, Parallel Code — a shelf of builders around the same phrase; the demand is broad |
 All rows live in `drafts/listening.md` (The-Nook local master line).
--- a/marketing/drafts/newsletter-postmortem-pitch/copy.md
+++ b/marketing/drafts/newsletter-postmortem-pitch/copy.md
@@ -0,0 +1,96 @@
 # Newsletter pitch — post-mortem shape (narrowed; no conversion figure)
 > **Status: draft — narrowed 2026-11-06 per the CTO's reopening verdict on
 > FRE-199.** The "X% trial→paid" half of the shape **cannot ship**: the
 > FRE-202 snapshot (window 2026-10-22 → 10-29) reads trial started 2, purchase
 > 0, activation 0, with 291 of 291 analytics rows predating the FRE-366
 > instrumentation — a trial→paid ratio from that cohort is not a metric. The
 > ratio comes from FRE-197's mature Day 28–35 cohort read when it lands.
 > **No figure in this file is a measurement.** Send gates at the bottom.
 ## Audience & channel
 Editors of free dev-tool newsletters (the ones that run post-mortems and
 "what we learned" pieces). Direct email, one editor at a time, personalised.
 No paid placements at any budget without a CoS + sponsor decision.
 ## The claim the pitch goes out with
 A post-mortem pitch, not a product pitch: *here is what shipping a Mac utility
 alone actually broke, and what we changed because of it.* The product is the
 setting; the breakage and the fix are the story. The story stands on its own
 with zero funnel numbers — if no verified number exists on send day, the pitch
 ships without one rather than with a placeholder.
 ## The pitch (shape — names and dates personalised; nothing else is a placeholder)
 **Subject:** What shipping a Mac utility alone broke (post-mortem)
 Hi <editor>,
 We build The Nook, a $10 Mac utility that surfaces coding-agent approvals at
 the notch. I'm not pitching the app — I'm offering a post-mortem your readers
 usually only get from funded startups, because shipping alone broke things in
 ways bigger teams don't hit:
 - **The silent update.** In October we shipped a release whose appcast published
  cleanly — while every delta it named 404'd, so users on older builds were
  being offered updates that didn't exist. The publish path deleted files
  before the feed that named them was live. Nothing alerted; the feed just
  lied quietly. The fix — upload the feed's enclosures, verify every enclosure
  URL, copy the appcast up, and only *then* prune — is now ordered so the
  deletion can't run first.
 - **The green suite.** Weeks earlier, a regression in our public relay shipped
  behind a passing test run — the suite that would have caught it existed but
  nothing invoked it. A green checkmark that covers nothing looks identical to
  one that covers everything. The suite is now wired into the standard test
  entry point, and the relay's deploy patcher is tested alongside it.
 - **What we're not going to quote you.** A growth number, right now, would be
  theatre: our funnel is young and a conversion ratio from an immature cohort
  is not a measurement. If we attach a count, it will be activations — one per
  activated install, from our own relay store — and we will say exactly that,
  because download counts (a different number, from a different store) flatter
  nothing and confuse everyone. The receipts that matter here are the failure
  modes above, not a traction line.
 The angle for your readers: solo distribution is a chain of quiet failure
 modes, each one invisible until it costs a user. We kept the receipts.
 Happy to send the full write-up, screenshots of the broken feed, and the exact
 publish-order and test-wiring changes.
 — <name>, FrenoCorp
 ## Where a number could come from, and what disqualifies it
 - **Trial→paid ratio: cannot ship today.** FRE-202's snapshot shows a cohort of
  2 trials, 0 purchases, pre-instrumentation rows. The ratio waits for
  FRE-197's mature Day 28–35 read. If it lands before send day and the CTO
  confirms the query, the ratio may be added — and it must say it is per
  *install* (install cap 3), not per person.
 - **Activations: the only count eligible to ship.** One row per activated
  install (`installs`, `created_at`) in the relay store; CTO confirms the query
  before any send. The pitch names it as activations, never as downloads.
 - **Downloads (S3 side) are never quoted.** Different store, automation-heavy,
  and the pitch that says "downloads" when it means activations burns the
  credibility the post-mortem is built on.
 - No number is estimated to fill any gap, ever.
 ## Gates before anything is sent
 1. Any count quoted is activations, from a CTO-confirmed query — owner: CTO.
 2. The trial→paid ratio ships only from FRE-197's mature cohort read with CTO
   confirmation; otherwise the "what we're not going to quote you" paragraph
   stands as written — owner: CTO.
 3. Both breakage paragraphs are fact-checked against the engineering record
   (FRE-542 publish-order incident; the NOOK-815 uninvited-suite relay
   regression) before send — owner: CMO, evidence to CTO for verdict.
 4. Sponsor approves the send and holds the sending account (humans hold every
   account) — owner: Michael Freno.
 ## Target dates (internal)
 - Draft with placeholders: **done 2026-11-05**; narrowed to the no-figure shape
  **2026-11-06** (CTO direction).
 - Send: after gates 1–4 — with the no-figure shape, the only hard input left is
  the CTO's query confirmation and the sponsor's send.
--- a/marketing/drafts/newsletter-postmortem-pitch/rationale.md
+++ b/marketing/drafts/newsletter-postmortem-pitch/rationale.md
@@ -0,0 +1,73 @@
 # Rationale — newsletter post-mortem pitch (shape)
 FRE-199 item 2. Drafted 2026-11-05 by CMO (plan date was 2026-11-06; FRE-201
 landed today, which was the only gate on drafting the shape).
 ## Why draft now
 The Chief of Staff's sequencing had the pitch drafted when FRE-201 landed. It
 landed 2026-11-05 (row closed `done` 18:45Z; the daily scan routine
 `2553b201` has been producing the backlog since 2026-10-30). The figures were
 never gated on FRE-201 — only the shape was — so the shape ships now and the
 figures stay placeholders behind their own gate.
 ## Why a post-mortem and not a product pitch
 The issue text's own thesis: "1,900 downloads, 6% trial→paid, here's what
 broke" outperforms a product pitch. Editors of free dev-tool newsletters run
 post-mortems; a solo shop shipping a Mac utility and keeping receipts is a
 story they can run without us asking for a review.
 ## The breakage is real, not invented
 The lead paragraph is the 0.13.4 delta incident (FRE-542): the appcast stayed
 at 0.13.4 while its five delta files 404'd — the publish path pruned before
 the feed was up. The fix (upload enclosures, verify URLs, copy the appcast,
 then prune) is in `scripts/upload-release.sh` and is engineering-verified by
 the FRE-542 record.
 **Second breakage, chosen 2026-11-06 (CTO direction):** the relay regression
 that shipped behind a passing suite (NOOK-815) — the suite that would have
 cought it existed but nothing invoked it; the fix wires it into the standard
 test entry point. It was chosen over the changelog-blanking incident because
 it is a complete story with no number needed and no overlap with the lead
 (both remaining candidates were publish-path incidents; one story about the
 publish path is enough). The placeholder is gone: no paragraph in the pitch
 waits on a figure any more.
 ## Narrowed 2026-11-06 — what the numbers can and cannot support
 The CTO's reopening verdict on FRE-199 confirmed **no figure for the pitch
 today**: FRE-202's snapshot (trial started 2, purchase 0, activation 0; 291 of
 291 rows predate the FRE-366 instrumentation) cannot yield a trial→paid ratio —
 that waits for FRE-197's mature Day 28–35 cohort read. So the pitch narrowed:
 - the "X% trial→paid" placeholder is deleted, not held;
 - if any count ships, it is **activations** (relay store, one row per activated
  install), named as activations — downloads (S3 side) are never quoted;
 - a new paragraph — "what we're not going to quote you" — turns the missing
  number into part of the post-mortem's credibility instead of a gap;
 - with the no-figure shape, the only inputs left before send are the CTO's
  query confirmation (if a count is attached) and the sponsor's send.
 ## Hard rules honoured
 - No figure in the file is a measurement; nothing is estimated to fill a gap.
 - No conversion figure ships — the ratio is FRE-197's, gated and CTO-confirmed.
 - Any count that ships is activations, named as activations; downloads are
  never quoted.
 - The two caveats (per-install conversion with install cap 3; downloads ≠
  activations) are written to travel inside the pitch, not a footnote.
 - Paid placements: out, per the issue text and the plan (TLDR ≈ $3k, no
  verifiable CPC). No placement is bought without CoS + sponsor.
 - Price appears once ($10, what the app actually charges) to identify the
  product — no discount, no countdown, no price-change copy (FRE-204 holds).
 ## Gates before send
 1. Any count quoted is activations, from a CTO-confirmed query — CTO.
 2. Trial→paid ratio ships only from FRE-197's mature read, CTO-confirmed;
   otherwise the no-figure paragraph stands — CTO.
 3. Both breakage paragraphs fact-checked against the engineering record
   (FRE-542; NOOK-815) — CMO drafts, CTO verifies.
 4. Sponsor approves the send; a human holds the account and sends — sponsor.
Author	SHA1	Message	Date
fixture	e12a063aa9	marketing: FRE-199 third pair of informational pages (drafts) + pitch narrowed to the no-figure shape Pair 3 (internal target Thu 2026-11-12, six days early): - agent-worktree-contention — 'How do you manage worktrees when your agents end up waiting on each other?' (backlog 1xlz2bs, Scan 6 #4); git worktree + Docker Compose project-name docs fetched and read 2026-11-05. - agent-keeps-asking — 'Why does your coding agent keep stopping to ask you questions?' (handback cluster: 1xlfqmo, 1xk0ghj, 1xlxw0q); permission + hooks claims re-verified live 2026-11-05 against code.claude.com; the 1xlfqmo poster's measurement figures deliberately not cited. Pitch narrowed per CTO reopening verdict: trial→paid placeholder deleted (FRE-202 cohort too young; ratio waits for FRE-197), second breakage chosen (NOOK-815 uninvoked suite), any count named as activations, downloads never quoted.	2026-11-05 22:54:53 +00:00
fixture	0137703341	marketing: FRE-199 CTO review fixes — B1 precedence order, B2 false git-push example dropped, N1 hooks-guide attribution B1 (agent-waiting-on-permission): body said 'allow / ask / deny' — inverted vs the permissions doc's deny → ask → allow. Fixed; fact-check row 3 was already correct and now matches the body. B2 (agent-run-without-asking): dropped the 'Bash(git commit ) allowed with Bash(git push ) denied is a policy the agent cannot talk its way around' example — the docs' own 'What a Bash rule doesn't match' table names Bash(git push *) as not stopping git -C . push origin main and friends. Sentence narrowed to the precedence claim, with a pointer to step 4's caveat. N1 (agent-done-signal): the osascript desktop-notification example is in the hooks guide (code.claude.com/docs/en/hooks-guide), not the hooks reference. Body and fact-check row 4 fixed. Pair-1 citations standardised from docs.anthropic.com to code.claude.com per the review's optional note. Each page's status blockquote records the revision.	2026-11-05 21:42:26 +00:00
fixture	4dac2e2928	marketing: FRE-199 fact-check verdict applied — second pair drafts/ → approved/ Sponsor fact-check card (FRE-199, interaction a7cba232) answered 2026-11-05 20:21Z: 'Approve both — move to approved/'. Status blockquotes updated to record the verdict and the date; page bodies untouched.	2026-11-05 20:23:03 +00:00
fixture	680563e3f9	marketing: FRE-199 registry wave-2 brief — targets verified, copy inherited from signed claims Five wave-2 candidates fetched live 2026-11-05 (awesome-macOS 19.4k ★, 1000.tools, uneed.best, devhunt.org; Product Hunt bot-walled and marked on-screen-read). Copy inherits FRE-207's CTO-signed claims only; price line stays 'Free 14-day trial', no number (G2). Submission gated on the wave-1 readback and G3/G4. Copy target was Fri 2026-11-13; ready 2026-11-05.	2026-11-05 20:15:30 +00:00
fixture	c5fb98af8d	marketing: FRE-199 second pair of informational pages (drafts) - agent-parallel-tracking/ — 'How do you keep track of multiple coding agents?' — the multi-agent attention cluster (1xmzp2n, 1xh5cum, 1xdjb2g, 1xipsk0, 1xk0ghj); answered with documented per-session hook events (session_id, typed Notification matchers) and the status line. - agent-run-without-asking/ — 'Should you let your coding agent run without asking permission?' — the autonomy cluster (1xexhwf, 1xk8imc, 1xk277d); answered with the permission-mode ladder, the docs' own container/VM warning, rule precedence, sandboxing pointer, PreToolUse deny. Internal target Mon 2026-11-09; drafted 2026-11-05. All doc claims re-read 2026-11-05 against code.claude.com (permissions, hooks, statusline). Ban compliance: no product of ours, no competitor, no handles, no price, no invented figures.	2026-11-05 19:58:59 +00:00
fixture	77e692273e	marketing: FRE-199 fact-check verdict applied — first pair drafts/ → approved/ Sponsor fact-check card (FRE-199, interaction 0101ee80) answered 2026-11-05 19:53Z: 'Approve both — move to approved/'. Status blockquotes updated to record the verdict and the date; page bodies untouched.	2026-11-05 19:54:45 +00:00
CMO (FrenoCorp agent)	a58b25501a	marketing: FRE-199 first pair of informational pages + pitch shape (drafts) - agent-done-signal: 'How do you know when your coding agent is done?' — the zero-looks-like-success cluster (1xjb3j0, 1xm09fs, 1xmnz2c, HN fhub/ sadilek); Stop/Notification/StopFailure hooks cited to the agent's own docs, re-read 2026-11-05. No product, no competitor, no price. - agent-waiting-on-permission: 'Why is my coding agent sitting on a permission prompt?' — the 1xhbc71 thread + invisible-permission cluster; permission modes, /permissions, rule syntax, acceptEdits cited to the permissions doc; undo-split attributed to 1xkoz06. - newsletter-postmortem-pitch: item 2's shape, placeholders only; send gated on FRE-202 or a CTO-confirmed direct relay-store read. All drafts: sponsor fact-check moves pending/ -> approved/; nothing publishes itself.	2026-11-05 19:09:46 +00:00