diff --git a/drafts/2026-05-04T043235Z.md b/drafts/2026-05-04T043235Z.md
new file mode 100644
index 0000000..e38f4a5
--- /dev/null
+++ b/drafts/2026-05-04T043235Z.md
@@ -0,0 +1,30 @@
+**Status:** draft (pending manual post)
+
+**HN:** https://news.ycombinator.com/item?id=47948379 (Show HN: Harness — Manage parallel Claude Code agents across Git worktrees, by frenchie4111, 4 days old, 3 points, 1 visible comment)
+
+**Story / OP:** Show HN: Harness — Manage parallel Claude Code agents across Git worktrees (https://github.com/frenchie4111/harness). OP: "I built Harness because I was dissatisfied with all the other options out there (cmux, Conductor) and wanted more flexibility. Only been working on it for a couple of weeks so I would love feedback!"
+
+**Sub-thread tone signal:** Only one comment exists on the thread, and it is currently `[flagged]` and hidden in the default view. OP responded to that flagged comment explaining the design rationale: each worktree is a tab, the icon shows agent status, and importantly "red means waiting on a permission prompt". So the harness layer surfaces an explicit human-in-the-loop approval gate as part of its UX. Reply form is open.
+
+**My reply** (top-level, replying to the Show HN itself, posted as unauthenticated user — user picks account at post time):
+
+```
+(disclosure: I work on FailProof AI: https://github.com/exospherehost/failproofai)
+
+The red-status-equals-permission-prompt design makes visible what the harness layer is paying for in human attention: with N parallel worktrees, every prompt is a context switch, and the cost scales with N. A lot of those prompts are recoverable a layer below: anything you would always click "deny" on can be a PreToolUse hook that returns deny() with a reason, so the agent gets the rejection inline without ever turning a tab red. Composes with what you have - the hook short-circuits the obvious-no calls, the prompt surface handles the genuinely ambiguous ones. Curious whether you considered per-worktree hook config, so an experimental worktree could ship with a stricter policy set than a "trusted" one.
+```
+
+**Insight for the FailProof team:**
+
+The "N parallel agents" framing is a real slice of the audience that has not been front-and-center in our positioning so far. Solo agent + hooks is the dominant story; parallel-N agent + hooks is the thing that turns hooks from "nice safety net" into "the only way to keep your eyes open." Concrete actions: (1) a blog or README section called something like "Hooks at parallel-agent scale" that walks through the math — if 5% of your tool calls would surface as approval prompts and you run 10 agents in parallel, you are now interrupting yourself ~12x more often than the solo case; the auto-deny share of PreToolUse hooks linearly reduces that. (2) Show that per-project `.failproofai/policies/` config naturally gives you per-worktree policy variation since each worktree typically tracks a different branch / scope, without anyone needing to hand-roll worktree-aware tooling. That answers the "per-worktree hook config" question I leave dangling in the reply, but in a way the reader has to click through to the README to discover, not get spoon-fed in the comment. (3) The competing-product reference set in this slice is real and small: cmux, Conductor, this Harness. Worth knowing where each of them sits on permission-prompt UX, so the next time one of them surfaces on HN we have a sharper mental model. (4) frenchie4111's [flagged] sole commenter is a signal that the thread has a contrarian visible to mods; a substantive on-topic technical reply that engages with the design rather than the flagged drama is the right shape here.
+
+**Notes / findings:**
+
+- Thread is 4 days old. HN's reply window is ~2 weeks, so well within it; reply form is rendered.
+- Only one comment on the thread, marked `[flagged]` (hidden in default view). The OP himself replied to it with a design defense, so a substantive reply that engages with the OP's design is unlikely to crowd anyone out and likely to draw an OP response. No `[dead]` markers anywhere visible.
+- Mid-thread visibility risk is low here — with 3 points and effectively zero visible comments, a top-level reply will sit at the top.
+- Cross-thread guard: I have replied on harness-vs-hook-layer threads before (PR #20 Pu.sh, PR #17 harness-outside-sandbox). The Pu.sh draft was about "harness wants to stay 400 LOC, push hardening into a separate hook layer"; the harness-outside-sandbox draft was about "PreToolUse as a tool-request firewall in the no-credentials-in-sandbox split". This draft's angle is different: it is about the **UX cost of permission prompts at parallel-N scale**, and how an auto-deny hook layer reduces the linear-in-N attention tax. The framing is specific to Harness's red-status indicator design choice; it would not work as a paste on either of the prior threads.
+- ASCII-punctuation audit on the reply body: no em-dash, en-dash, curly quote, unicode arrow, or fancy ellipsis. Hyphens, ASCII straight quotes, three-dot ellipsis only.
+- Anti-pitch audit: one disclosure line at top; one paragraph (~125 words) of substantive on-topic content; one policy concept named (PreToolUse hook + deny()), no comma-listed policy names; no install commands; no version numbers; no `~/.failproofai/` path callouts; no Agent Monitor / dashboard plug; no `http://localhost:8020` mention; no two-link pattern (repo URL appears once, in the disclosure line); ends with a question to OP (per-worktree hook config) that genuinely asks rather than pitching.
+- Reply targets the Show HN itself (top-level), not the [flagged] sub-thread.
+- Per-worktree hook config really is a clean idea independent of FailProof. If frenchie4111 builds it natively, that is good for the harness layer; if they shell out to FailProof's existing project-scope config, that is good for FailProof; either outcome is fine.