patchwork-os 0.2.0-beta.0 → 0.2.0-beta.10

package/templates/automation-policies/strict-lint.json

@@ -1,6 +1,6 @@
 {
   "_comment": "strict-lint — triggers on every save and error, enforces zero-warning policy.",
-  "_usage": "Copy to automation-policy.json. Requires --automation --automation-policy <path> --claude-driver subprocess",
+  "_usage": "Copy to automation-policy.json. Requires --automation --automation-policy <path> --driver subprocess",
 
   "automationSystemPrompt": "Automation bot. Drop articles/filler. Fragments OK. Abbreviate: DB/auth/config/req/res/fn. X→Y arrows. ≤5 lines. No preamble. Call tools → report results only.",
 

package/templates/automation-policies/test-driven.json

@@ -1,6 +1,6 @@
 {
   "_comment": "test-driven — enforces test coverage and runs tests automatically on every relevant change.",
-  "_usage": "Copy to automation-policy.json. Requires --automation --automation-policy <path> --claude-driver subprocess",
+  "_usage": "Copy to automation-policy.json. Requires --automation --automation-policy <path> --driver subprocess",
 
   "automationSystemPrompt": "Automation bot. Drop articles/filler. Fragments OK. Abbreviate: DB/auth/config/req/res/fn. X→Y arrows. ≤5 lines. No preamble. Call tools → report results only.",
 

package/templates/automation-policy.example.json

@@ -1,6 +1,6 @@
 {
   "_comment": "Example automation policy with LSP-aware prompts. Copy to automation-policy.json and adjust as needed.",
-  "_usage": "Start bridge with: claude-ide-bridge --automation --automation-policy ./automation-policy.json --claude-driver subprocess",
+  "_usage": "Start bridge with: claude-ide-bridge --automation --automation-policy ./automation-policy.json --driver subprocess",
 
   "onFileChanged": {
     "enabled": true,

package/templates/co.patchwork-os.bridge.plist

@@ -8,7 +8,7 @@
   <key>ProgramArguments</key>
   <array>
     <string>__BINARY_PATH__</string>
-    <string>--claude-driver</string>
+    <string>--driver</string>
     <string>subprocess</string>
   </array>
   <key>RunAtLoad</key>
@@ -24,7 +24,7 @@
     <key>HOME</key>
     <string>__HOME__</string>
     <key>PATH</key>
-    <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string>
+    <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
   </dict>
   <key>WorkingDirectory</key>
   <string>__HOME__</string>

package/templates/recipes/approval-queue-ui-test.yaml

@@ -0,0 +1,205 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/patchworkos/recipes/main/schema/recipe.v1.json
+apiVersion: patchwork.sh/v1
+name: approval-queue-ui-test
+description: |
+  End-to-end UI test for the dashboard Approval queue page. Drives a real
+  browser via the Playwright MCP server to exercise every button on
+  /approvals, verifies the expected side effects (network calls, clipboard
+  writes, DOM state, keyboard shortcuts), and writes a PASS/FAIL report to
+  ~/.patchwork/inbox/.
+
+  Coverage:
+    Header — DecisionsTabs (Pending / Suggested / History), Sync inbox
+    Risk filters — All / Low / Medium / High chips
+    Card body — params toggle (▸/▾), Copy JSON, Approve (E), Reject (X),
+                Edit & approve (clipboard), Open in terminal (clipboard)
+    Selection — per-card checkbox, Select all, batch Approve, batch Reject
+    Empty state — Clear filter (filtered) and Clear filter (session banner)
+    Suggestions card — Copy allow rule, Dismiss (×), Clear all patterns
+    Keyboard — J / K (focus), E / X (decide)
+
+  PREREQUISITES
+    1. Bridge running with --driver subprocess so the agent has MCP
+       access to the Playwright server.
+    2. Dashboard reachable at DASHBOARD_URL (defaults to localhost:3000;
+       Patchwork's Next.js dev typically mounts under /dashboard, so the
+       page at $DASHBOARD_URL/approvals must respond 200).
+    3. approvalGate must be "all" or "high" — if "off", every POST
+       /approvals auto-allows ({decision:"allow",reason:"gate_off"}) and
+       the queue stays empty. The agent toggles it on at the start of the
+       run and restores it at the end.
+    4. Seeded pending approvals — the agent creates them via POST
+       /api/bridge/approvals with nohup+disown durability (so the curl
+       process survives shell exit; see seeding step). Default TTL is
+       5 min, so all UI work must finish before re-seeding.
+    5. Trigger from the dashboard Recipes page (NOT `patchwork recipe run`)
+       — the local subprocess shell has no MCP context.
+
+  IMPLEMENTATION NOTES (learned from 2026-05-07 dogfood)
+    - Click via mcp__playwright__browser_click (real Playwright clicks),
+      NOT browser_evaluate(.click()) — Chromium's clipboard.writeText
+      requires "transient activation" which programmatic clicks don't
+      provide. Edit & approve / Open in terminal silently fail otherwise.
+    - Same goes for checkboxes — programmatic input.click() doesn't
+      always trigger React's onChange synthetic event reliably.
+    - Use the URL ?session= param to force the session-banner branch;
+      no need to find a real session.
+    - Use the "Low (0)" filter to hit the empty-state branch deterministically
+      (without rejecting cards mid-test).
+trigger:
+  type: manual
+  vars:
+    - name: DASHBOARD_URL
+      description: "Base URL where the dashboard is reachable from the agent's browser"
+      required: false
+      default: "http://localhost:3000"
+steps:
+  - id: drive_browser
+    agent:
+      driver: claude-code
+      model: claude-haiku-4-5-20251001
+      prompt: |
+        You are running an end-to-end UI test of the Patchwork Approval
+        queue page. Use the Playwright MCP tools (mcp__playwright__*) to
+        drive a real browser. Do not skip steps. If a tool call errors,
+        record the failure and continue — every checkpoint must be
+        attempted so the report is complete.
+
+        BASE_URL: {{DASHBOARD_URL}}
+        TARGET:   {{DASHBOARD_URL}}/approvals
+
+        Use mcp__playwright__browser_snapshot between actions to confirm
+        DOM state. Use mcp__playwright__browser_evaluate to read
+        navigator.clipboard.readText() (after granting clipboard-read
+        permission via browser_evaluate of the appropriate Permissions
+        API call) to verify clipboard-writing buttons.
+
+        ## Checklist — record PASS / FAIL + a one-line note for each
+
+        ### A. Page load + tabs (DecisionsTabs)
+        A1. browser_navigate to TARGET. Snapshot. Confirm h1 contains
+            "Approval queue".
+        A2. Click the "Suggested" tab. Confirm URL becomes /suggestions.
+        A3. browser_navigate_back. Confirm URL returns to /approvals.
+        A4. Click the "History" tab. Confirm URL becomes /decisions.
+        A5. browser_navigate_back to /approvals.
+
+        ### B. Header controls
+        B1. Click "Sync inbox". Use browser_network_requests to confirm a
+            GET request to /api/bridge/approvals fired within 2s.
+
+        ### C. Risk filter chips (All / Low / Medium / High)
+        For each label in [All, Low, Medium, High]:
+          C{n}. Click the filter chip with text starting with that label.
+                Confirm aria-pressed="true" on the clicked chip and
+                aria-pressed="false" on the others. Confirm the URL
+                ?risk= param matches (or is absent for "All").
+
+        ### D. Per-card controls — pick the FIRST visible approval card
+        Skip section D with a clear note if the queue is empty.
+        D1. Click the card's "Full params" toggle (▸). Confirm it
+            switches to ▾ and the params JSON region expands.
+        D2. Click "Copy JSON". Read clipboard; confirm it parses as JSON
+            and equals the card's params.
+        D3. Click "Edit & approve". Read clipboard; confirm it starts
+            with "patchwork approve --edit ".
+        D4. Click "› Open in terminal". Read clipboard; confirm it
+            starts with "patchwork approve " (no --edit).
+        D5. Note the card's callId, then click the per-card checkbox.
+            Confirm the checkbox is checked and the BatchActionBar
+            renders with "1 selected".
+        D6. Uncheck the same checkbox. Confirm BatchActionBar disappears.
+
+        ### E. Select-all + batch (only if filtered.length > 1)
+        Skip with a note if there are fewer than 2 cards.
+        E1. Click "Select all". Confirm every visible card checkbox is
+            checked.
+        E2. Confirm BatchActionBar shows "Approve selected (N)" and
+            "Reject selected (N)" with N === visible card count.
+        E3. Do NOT click batch Approve / Reject in this run — they fire
+            real POSTs and would mutate state. Just record that the
+            buttons render and are not disabled.
+        E4. Uncheck "Select all". Confirm all card checkboxes clear.
+
+        ### F. Empty-state "Clear filter"
+        F1. Click the "High" risk filter. If the resulting list is empty,
+            confirm the EmptyState renders with a "Clear filter" button.
+            Click it; confirm the filter resets to All.
+            If the High filter still has cards, record SKIP with reason.
+
+        ### G. Keyboard shortcuts
+        G1. Press "j" via browser_press_key. Confirm focus advances to
+            the next card (outline: 2px solid var(--accent) on the
+            second card).
+        G2. Press "k". Confirm focus returns to the first card.
+        G3. Do NOT press E or X — they fire real decisions. Record only
+            that the keyboard hint row renders KeyChip pills for J, K,
+            E, X, ⌘K.
+
+        ### H. Suggestions card (best-effort)
+        H1. Scroll to bottom. If "Pattern suggestions" card is visible
+            (depends on local approval history, may not exist), click
+            "Copy allow rule" on the first row and confirm clipboard
+            contains JSON like {"allow":["<toolName>"]}. Otherwise
+            record SKIP: "no suggestions in queue".
+
+        ### I. Session-filter banner
+        I1. browser_navigate to {{DASHBOARD_URL}}/approvals?session=test1234.
+            Confirm the info banner renders with text containing
+            "Showing approvals for session". Click the banner's
+            "Clear filter" link; confirm URL becomes /approvals.
+
+        ## Final step — write the report
+        Output ONLY the markdown block below, nothing else:
+
+        ```
+        # approval-queue-ui-test — {{date}} {{time}}
+
+        Base URL: {{DASHBOARD_URL}}
+        Browser: <user-agent from snapshot>
+
+        ## Result: PASS / FAIL  (FAIL if any checkpoint failed)
+
+        ### A. Page load + tabs
+        - A1 ... A5 — PASS / FAIL / SKIP — <note>
+
+        ### B. Header controls
+        - B1 — ...
+
+        ### C. Risk filters
+        - All — ...
+        - Low — ...
+        - Medium — ...
+        - High — ...
+
+        ### D. Per-card controls
+        - D1 ... D6 — ...
+
+        ### E. Select-all + batch
+        - E1 ... E4 — ...
+
+        ### F. Empty-state Clear filter
+        - F1 — ...
+
+        ### G. Keyboard shortcuts
+        - G1 ... G3 — ...
+
+        ### H. Suggestions card
+        - H1 — ...
+
+        ### I. Session-filter banner
+        - I1 — ...
+
+        ### Failures
+        <bullet list of every FAIL with the full error / screenshot ref;
+         "none" if clean>
+
+        ### Verdict
+        <one sentence>
+        ```
+      into: report
+
+  - id: write_report
+    tool: file.write
+    path: ~/.patchwork/inbox/approval-queue-ui-test-{{date}}.md
+    content: "{{report}}\n"

package/templates/recipes/ctx-loop-test.yaml

@@ -5,7 +5,7 @@ description: |
   appears in the result. Output lands in ~/.patchwork/inbox/ for manual inspection.
   Run this after deploying a new bridge build to confirm the memory moat is live.
 
-  NOTE: requires --claude-driver subprocess and a running bridge with HTTP port
+  NOTE: requires --driver subprocess and a running bridge with HTTP port
   so the agent subprocess has MCP access. Running via `patchwork recipe run`
   (local yamlRunner) will fail at Step 1 — the local claude -p subprocess has
   no bridge MCP context. Trigger from the dashboard Recipes page instead.

package/templates/recipes/fix-errors-on-save.yaml

@@ -0,0 +1,71 @@
+apiVersion: patchwork.sh/v1
+name: fix-errors-on-save
+description: |
+  On every save of a .ts/.tsx file, check for TypeScript errors. If errors exist,
+  an agent reads the broken code, navigates to the relevant type definitions, and
+  applies a minimal targeted fix — without refactoring surrounding code.
+
+  Requires: bridge running with --driver subprocess so the agent subprocess has
+  MCP access to getBufferContent, goToDefinition, getHover, getDiagnostics, editText.
+
+trigger:
+  type: on_file_save
+  glob: "**/*.{ts,tsx}"
+
+steps:
+  - tool: diagnostics.get
+    uri: "{{file}}"
+    filter: error
+    into: errors
+
+  - agent:
+      prompt: |
+        A TypeScript file was just saved: {{file}}
+
+        Current errors reported by the language server:
+        {{errors}}
+
+        If there are NO errors (empty list above), output nothing (empty string) and stop.
+
+        Otherwise, fix the errors by following these steps IN ORDER:
+
+        ## Step 1 — Read the file
+        Call getBufferContent for {{file}} to see the current code. Note the line
+        numbers of each error.
+
+        ## Step 2 — Understand the types involved
+        For each error, use getHover at the error location to read the type information.
+        If the error references a symbol whose definition you need (e.g. "Property X does
+        not exist on type Y"), call goToDefinition on that symbol and then getBufferContent
+        on the definition file to read the actual shape of the type.
+
+        ## Step 3 — Apply a minimal fix
+        Call editText to fix each error at its exact line. Rules:
+        - Fix only what the error points to — do not refactor surrounding code
+        - If fixing one error would require restructuring multiple files, stop and report
+          why instead of applying a partial fix
+        - Prefer adding a missing property/cast over restructuring the type
+
+        ## Step 4 — Verify
+        Call getDiagnostics for {{file}} after your edits. If new errors appeared, revert
+        your change with another editText call and report the failure.
+
+        ## Step 5 — Report
+        Output a concise markdown summary:
+        ```
+        ## fix-errors-on-save — {{file}}
+        **Errors found:** <count>
+        **Fixed:** <list each fix: "line N: <what was wrong> → <what was done>">
+        **Remaining:** <count, or "none">
+        **Skipped:** <any errors you couldn't safely fix, and why>
+        ```
+      driver: claude-code
+      model: claude-haiku-4-5-20251001
+      into: result
+
+  # Only append to the inbox when fixes were applied. When no errors exist
+  # the agent outputs nothing (empty string) and {{result}} is empty → falsy → skip.
+  - tool: file.append
+    path: ~/.patchwork/inbox/auto-fixes.md
+    content: "{{result}}\n\n"
+    when: "{{result}}"

package/templates/recipes/morning-brief.yaml

@@ -61,8 +61,11 @@ steps:
         6. **Linear** — list in-progress and unstarted issues by priority; omit this section entirely if the list is empty or returned an error
 
         Be concise. Skip newsletters and automated notifications.
-      # Use claude (not gemini) — Gemini free tier hits daily quota mid-recipe
-      driver: claude
+      # Use the claude-code driver (subprocess `claude -p`) — runs under
+      # your existing Claude Code subscription, no ANTHROPIC_API_KEY
+      # required. Switch to `driver: claude` only if you have an API key
+      # set and want the Anthropic API path (different billing).
+      driver: claude-code
       into: brief
   - tool: file.write
     path: ~/.patchwork/inbox/morning-brief-{{date}}.md

package/templates/recipes/project-health-check.yaml

@@ -38,7 +38,10 @@ steps:
         2. **Issues** — issues needing attention today; omit if empty
         3. **PRs** — PRs waiting on review or action; omit if empty
         4. **Health** — one-sentence overall assessment (on track / needs attention / blocked)
-      driver: claude
+      # Use the claude-code driver (subprocess `claude -p`) — runs under
+      # your existing Claude Code subscription. Switch to `driver: claude`
+      # only if you have ANTHROPIC_API_KEY set and prefer the API path.
+      driver: claude-code
     awaits: [gather]
   - id: write
     tool: file.write

package/templates/recipes/sentry-to-linear.yaml

@@ -1,77 +1,111 @@
+apiVersion: patchwork.sh/v1
 name: sentry-to-linear
 description: |
-  Fetch a Sentry issue, enrich it with git blame, and create a triage-ready
+  Fetch a Sentry issue, enrich its stack trace with git blame (via
+  enrichStackTrace built into fetchSentryIssue), and create a triage-ready
   Linear ticket. Requires both Sentry and Linear connectors connected.
   Run ad-hoc or trigger via webhook / automation policy.
 
-# Example manual trigger:
-#   patchwork-os run-recipe sentry-to-linear --var SENTRY_ISSUE_ID=12345678
+# Manual run:
+#   patchwork recipe run sentry-to-linear --var SENTRY_ISSUE_ID=12345678
 #
-# Example automation trigger (add to ~/.patchwork/automation-policy.json):
-#   "onFileSave": { ... }  — or fire from a Sentry webhook handler
+# Webhook trigger (convert this recipe to webhook type after install):
+#   trigger:
+#     type: webhook
+#     path: /hooks/sentry-to-linear
+#   Then POST from a Sentry alert rule to https://<bridge-url>/hooks/sentry-to-linear
 
 trigger:
   type: manual
   vars:
     - name: SENTRY_ISSUE_ID
-      description: "Sentry issue ID or URL (e.g. '12345678' or 'https://sentry.io/...')"
+      description: "Sentry issue ID or URL (e.g. '12345678' or 'https://sentry.io/organizations/my-org/issues/12345678/')"
       required: true
     - name: LINEAR_TEAM_KEY
-      description: "Linear team key to create the issue in (e.g. 'ENG'). Defaults to first team."
+      description: "Linear team key (e.g. 'ENG'). Leave blank to use your first team."
       required: false
     - name: LINEAR_PRIORITY
-      description: "Linear priority: 1=urgent, 2=high, 3=medium, 4=low (default: 2)"
+      description: "Linear priority: 1=urgent 2=high 3=medium 4=low"
       required: false
       default: "2"
 
 steps:
   - agent:
       prompt: |
-        You are a triage assistant. Your job is to:
-        1. Fetch the Sentry issue using fetchSentryIssue with issueId "{{SENTRY_ISSUE_ID}}"
-        2. Create a Linear issue using createLinearIssue with the data you received
+        You are a triage assistant. Follow these steps exactly — do not skip any.
 
-        For the Linear issue:
-        - title: Use the Sentry issue title verbatim
-        - description: Write a structured Markdown body with these sections:
-            ## Error
-            (one-line error type + message from the Sentry title)
+        ## Step 1 — Fetch Sentry issue with git blame enrichment
 
-            ## Stack trace
-            (the top 5 frames from the stackTrace field, formatted as a code block)
+        Call `fetchSentryIssue` with:
+          issueId: "{{SENTRY_ISSUE_ID}}"
+          maxFrames: 15
 
-            ## Suspect commit
-            (if topSuspect is present: sha, author, date, subject — otherwise write "No suspect commit identified")
+        `fetchSentryIssue` automatically runs git blame on every stack frame and
+        returns `topSuspect` (the commit most likely to have introduced the bug),
+        `confidence` (high/medium/low), and per-frame `commit` attribution.
 
-            ## Confidence
-            (the confidence field value + a one-sentence explanation of what it means)
+        ## Step 2 — Create the Linear issue
 
-            ## Sentry link
-            (a link back to the Sentry issue — construct from the issueId: https://sentry.io/issues/{{SENTRY_ISSUE_ID}}/)
+        Call `createLinearIssue` with:
+          title:       The Sentry issue title verbatim
+          teamKey:     "{{LINEAR_TEAM_KEY}}" (omit the key entirely if the value is blank)
+          priority:    {{LINEAR_PRIORITY}} (integer — not a string)
+          labelNames:  ["bug"]
+          description: A Markdown body structured exactly as follows:
 
-        - teamKey: "{{LINEAR_TEAM_KEY}}" (pass as-is; if blank the tool picks the first team)
-        - priority: {{LINEAR_PRIORITY}} (as an integer)
-        - labelNames: ["bug"]
+        ---
+        ## Error
+        <one-line error type + message from the Sentry title>
 
-        After creating the ticket, respond with ONLY a JSON object:
+        ## Stack trace
+        ```
+        <top 10 frames from the stackTrace field>
+        ```
+
+        ## Suspect commit
+        <If topSuspect is non-null, format as:>
+        - **SHA:** `<sha>`
+        - **Author:** <author>
+        - **Date:** <date>
+        - **Subject:** <subject>
+        - **Frames blamed:** <frameCount> of <framesBlamed> workspace frames
+        - **Confidence:** <confidence>
+
+        <If topSuspect is null, write:>
+        No suspect commit identified (confidence: <confidence>).
+        Git blame ran on <framesBlamed> frames; none resolved to a workspace commit.
+
+        ## Sentry link
+        <full Sentry URL — use issueId to construct: https://sentry.io/issues/{{SENTRY_ISSUE_ID}}/>
+        ---
+
+        ## Step 3 — Respond with JSON
+
+        After both tool calls succeed, respond with ONLY this JSON object
+        (no markdown fences, no extra text):
         {
-          "sentryIssueId": "<the issueId from fetchSentryIssue>",
-          "sentryTitle": "<the title>",
-          "linearIdentifier": "<e.g. ENG-101>",
-          "linearUrl": "<the url from createLinearIssue>",
+          "sentryIssueId": "<issueId from fetchSentryIssue>",
+          "sentryTitle": "<title from fetchSentryIssue>",
+          "linearIdentifier": "<identifier from createLinearIssue, e.g. ENG-101>",
+          "linearUrl": "<url from createLinearIssue>",
           "confidence": "<high|medium|low>",
-          "suspectCommit": "<sha or null>"
+          "suspectCommit": "<sha or null>",
+          "framesBlamed": <integer>,
+          "gitAvailable": <boolean>
         }
 
-        If either tool returns an error (sentryConnected: false or linearConnected: false),
-        respond with the same JSON shape but set linearUrl to "" and add an "error" key
-        explaining which connector is not connected.
+        If `sentryConnected` is false in the fetchSentryIssue response, stop and respond:
+        {"error": "Sentry connector not connected — visit /connections to authenticate"}
+
+        If `linearConnected` is false in the createLinearIssue response, stop and respond:
+        {"error": "Linear connector not connected — visit /connections to authenticate"}
       driver: claude-code
       model: claude-haiku-4-5-20251001
       into: result
+
   - tool: file.write
-    path: ~/.patchwork/inbox/sentry-to-linear-{{date}}.md
+    path: ~/.patchwork/inbox/sentry-{{SENTRY_ISSUE_ID}}-{{date}}.md
     content: |
-      # Sentry → Linear triage ({{date}})
+      # Sentry → Linear: {{SENTRY_ISSUE_ID}} ({{date}})
 
       {{result}}

package/templates/recipes/webhook/apple-watch-health-log.yaml

@@ -0,0 +1,145 @@
+apiVersion: patchwork.sh/v1
+name: apple-watch-health-log
+description: |
+  Logs Apple Watch sleep duration, quality, and activity rings from an iOS
+  Shortcut. Each fire writes a daily journal entry, generates a warm AI Coach
+  insight (Fitbit-Gemini style) via Claude, appends the insight to the
+  journal, and pushes it to your phone via ntfy.sh. Two conditional nudges
+  fire only when the payload looks off:
+
+    - "Short night" — separate priority-5 push when sleep_hours_under_6 is set
+    - "Watch off your wrist" — different topic when move_percent is 0
+
+  Conditional steps are gated by `when:` and read precomputed boolean fields
+  from the iOS Shortcut payload (template substitution can't do arithmetic).
+
+  Suggested triggers:
+    - iOS Shortcut ("Log my watch" — pulls Health stats + POSTs JSON)
+    - Stream Deck button for manual end-of-day log
+    - NFC tag on your nightstand
+    - curl from any device that can POST HTTP
+
+  Payload conventions (all optional — missing fields render blank):
+    sleep_hours              numeric, e.g. 7.4
+    sleep_quality            "deep" | "restful" | "light" | "restless" | free text
+    sleep_hours_under_6      "1" if sleep_hours < 6 (Shortcut precomputes)
+    move_percent             0-100+ (rings can exceed 100%)
+    move_percent_zero        "1" if move_percent == 0 (likely watch was off)
+    move_calories            active kcal burned
+    exercise_percent         0-100+
+    exercise_min             exercise minutes recorded
+    stand_percent            0-100+
+    notes                    free-form journal text
+
+  Setup:
+    1. Replace NTFY_TOPIC, NTFY_NUDGE_TOPIC, and NTFY_ALERT_TOPIC with your
+       own unguessable ntfy topics and subscribe to all three in the app.
+    2. Drop this file in ~/.patchwork/recipes/.
+    3. Start the bridge with `--driver subprocess` so /hooks/* is live.
+
+  Example request:
+    curl -X POST http://localhost:3101/hooks/apple-watch-health \
+      -H 'Content-Type: application/json' \
+      -d '{"sleep_hours":7.4,"sleep_quality":"restful","move_percent":112,"move_calories":645,"exercise_percent":150,"exercise_min":45,"stand_percent":100,"notes":"Closed all three rings."}'
+
+trigger:
+  type: webhook
+  path: /apple-watch-health
+
+steps:
+  - id: write_journal
+    tool: file.append
+    path: ~/.patchwork/health-journal/{{date}}.md
+    content: |
+      ## {{date}} Apple Watch Summary
+
+      ```
+      SLEEP   {{payload.sleep_hours}}h   {{payload.sleep_quality}}
+      MOVE    {{payload.move_percent}}%   {{payload.move_calories}} kcal
+      EXER    {{payload.exercise_percent}}%   {{payload.exercise_min}} min
+      STAND   {{payload.stand_percent}}%
+      NOTE    {{payload.notes}}
+      ```
+
+      ---
+
+  - id: coach_insight
+    agent:
+      driver: claude-code
+      model: claude-haiku-4-5-20251001
+      into: insight
+      prompt: |
+        Read the Apple Watch numbers below and write a short, warm coaching note in the voice of a friend who knows health data well. The tone should celebrate something specific, name one pattern, and end with one small doable tip for today. No preamble, no markdown headers, no bullets, no sign-off, no emojis. Plain prose, 80-150 words, 2-3 short paragraphs.
+
+        Hard rules (response is rejected if any are broken):
+        - Anchor every compliment in a number from the data. No generic "great job".
+        - Never lecture, never list ideal ranges, never use clinical jargon.
+        - Never start with "Sure," "Here's," "Of course," or any preamble.
+        - End with one concrete tip for today, framed as a tiny win — not a lifestyle overhaul.
+
+        Tone reference (match the register, not the content):
+
+          Hey there. Your sleep performance hit 87/100 last night — solid 7 hours 45 minutes with a nice chunk of deep sleep. Recovery is looking strong at 82/100 thanks to that solid HRV of 62 ms. The pattern I notice: when you wrap exercise before 6pm your sleep lands in the high 80s pretty reliably. One small win for today: try wrapping up screens 30 minutes earlier tonight. You've got this.
+
+        Apple Watch numbers for today:
+        Sleep: {{payload.sleep_hours}} hours, {{payload.sleep_quality}}
+        Move ring: {{payload.move_percent}}% closed, {{payload.move_calories}} active calories
+        Exercise ring: {{payload.exercise_percent}}% closed, {{payload.exercise_min}} minutes
+        Stand ring: {{payload.stand_percent}}% closed
+        User's notes for the day: {{payload.notes}}
+
+        Write the coaching note now. Output only the prose, nothing else.
+    silentFailDetection: false
+
+  - id: append_insight
+    tool: file.append
+    when: "{{insight}}"
+    path: ~/.patchwork/health-journal/{{date}}.md
+    content: |
+      ### Coach's note
+
+      {{insight}}
+
+      ---
+
+  - id: push_to_phone
+    tool: http.post
+    when: "{{insight}}"
+    url: https://ntfy.sh/NTFY_TOPIC
+    contentType: text/plain
+    headers:
+      Title: "{{date}} - the body report"
+      Tags: watch,zzz,fire
+    body: |
+      {{insight}}
+
+  # Fires only when payload.sleep_hours_under_6 is truthy ("1", "true", etc.)
+  - id: short_night_nudge
+    tool: http.post
+    when: "{{payload.sleep_hours_under_6}}"
+    url: https://ntfy.sh/NTFY_NUDGE_TOPIC
+    contentType: text/plain
+    headers:
+      Title: Short night - go easy today
+      Tags: sleeping_face,warning
+      Priority: "5"
+    body: |
+      You logged {{payload.sleep_hours}}h ({{payload.sleep_quality}}).
+      No PR attempts. Hydrate. Move at half-throttle.
+
+  # Fires only when payload.move_percent_zero is truthy — likely the watch
+  # was off your wrist all day, not that you genuinely moved 0%.
+  - id: watch_off_alert
+    tool: http.post
+    when: "{{payload.move_percent_zero}}"
+    url: https://ntfy.sh/NTFY_ALERT_TOPIC
+    contentType: text/plain
+    headers:
+      Title: Watch reported 0% move
+      Tags: warning,watch
+    body: |
+      Move ring at 0% for {{date}}. Battery dead? Forgot the watch?
+      Today's journal entry may not reflect actual activity.
+
+output:
+  path: ~/.patchwork/health-journal/{{date}}.md