patchwork-os 0.2.0-beta.9.canary.92 → 1.1.0-beta.1

package/templates/recipes/incident-to-pr.yaml

@@ -0,0 +1,187 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/patchworkos/recipes/main/schema/recipe.v1.json
+apiVersion: patchwork.sh/v1
+version: 1.0.0
+name: incident-to-pr
+description: |
+  FLAGSHIP — the end-to-end AI-native incident-response loop. Turns a
+  production incident into a reviewed, ready-to-merge pull request. Every
+  primitive Patchwork added during the connector + judge→refine campaign
+  shows up here in one pipeline:
+
+    1. investigate — an agent root-causes the incident against THIS repo
+                     using the read/git tools it has via MCP (no writes).
+    2. draft_fix   — an agent writes the smallest correct patch + a PR
+                     title/body. This is the draft the judge reviews.
+    3. review_fix  — a JUDGE step (agent.kind: judge) gives the draft a
+                     cold-eyes senior-engineer review. On `request_changes`
+                     it DRIVES the judge→refine loop: the draft step is
+                     re-run with the judge's fix-list injected, up to
+                     `max_revisions` cycles, until the judge approves. This
+                     is the moat — quality is gated by an AI reviewer, not
+                     by hope.
+    4. open_pr     — an agent opens the PR via the githubCreatePR MCP tool.
+                     Opening a PR is a high-risk WRITE, so the runtime
+                     approval gate pauses here for a human to sign off — the
+                     human-in-the-loop checkpoint before anything lands.
+    5. notify      — posts the PR link + judge verdict to Slack.
+
+  REQUIREMENTS
+    - Bridge running with `--driver subprocess` so the agent steps have MCP
+      tool access (read files, git, githubCreatePR).
+    - GitHub connector connected (for the PR) and Slack connector connected
+      (for the alert) — visit /connections, or `patchwork connect github` /
+      `patchwork connect slack`.
+    - An approval gate of "high" or "all" to exercise the open_pr pause
+      (with the gate off, the PR opens unattended).
+
+  MANUAL RUN
+    patchwork recipe run incident-to-pr \
+      --var INCIDENT_TITLE="checkout 500s on /api/pay" \
+      --var STACK_TRACE="TypeError: cannot read 'id' of undefined at pay.ts:42"
+
+  WEBHOOK CONVERSION (PagerDuty / Sentry / Datadog)
+    Replace the trigger block with:
+      trigger:
+        type: webhook
+        path: /hooks/incident-to-pr
+    and reference {{payload.title}} / {{payload.body}} in place of the vars.
+
+trigger:
+  type: manual
+  vars:
+    - name: INCIDENT_TITLE
+      description: "One-line incident summary (seeds the PR title)"
+      required: true
+    - name: STACK_TRACE
+      description: "Stack trace / error text to root-cause (optional, recommended)"
+      required: false
+    - name: SEVERITY
+      description: "critical | high | medium | low"
+      required: false
+      default: "high"
+    - name: SLACK_CHANNEL
+      description: "Slack channel for the resolution alert"
+      required: false
+      default: "#incidents"
+
+steps:
+  - id: investigate
+    agent:
+      driver: claude-code
+      prompt: |
+        A production incident has fired. Root-cause it against THIS repository.
+
+        Incident: {{INCIDENT_TITLE}}
+        Severity: {{SEVERITY}}
+        Stack trace / error:
+        {{STACK_TRACE}}
+
+        Use the read and git tools available to you — read files, search the
+        codebase, inspect recent commits and run git blame on the implicated
+        files. Do NOT write any files in this step.
+
+        Respond with a concise root-cause analysis containing:
+          - the offending file(s) and line(s)
+          - what is going wrong and why
+          - the commit that most likely introduced it (if identifiable)
+          - the smallest correct fix you would make
+      into: investigation
+    risk: low
+
+  - id: draft_fix
+    awaits:
+      - investigate
+    agent:
+      driver: claude-code
+      prompt: |
+        Using the root-cause analysis below, write a concrete, MINIMAL fix.
+
+        Root-cause analysis:
+        {{investigation}}
+
+        Output exactly these four markdown sections and nothing else:
+
+        ## PR title
+        <conventional-commit-style title, <= 70 chars>
+
+        ## Summary
+        <2-4 sentences: what the bug was and how this change fixes it>
+
+        ## Patch
+        <a unified diff of the smallest change that fixes the root cause —
+         touch as few lines as possible; no drive-by refactors>
+
+        ## Test
+        <the test you would add or modify to prove the fix (a diff), or a
+         short note if existing coverage already exercises the path>
+
+        Do NOT write files in this step — only emit the four sections.
+      into: fix_draft
+    risk: low
+
+  - id: review_fix
+    awaits:
+      - draft_fix
+    agent:
+      kind: judge
+      reviews: fix_draft
+      max_revisions: 2
+      on_exhausted: proceed
+      driver: claude-code
+      prompt: |
+        You are a senior engineer doing a cold-eyes review of the proposed
+        fix below BEFORE it becomes a pull request. Judge it on:
+          - correctness:  does it actually fix the root cause?
+          - minimality:   smallest possible change, nothing unrelated?
+          - safety:       regression risk, edge cases, missing guards?
+          - tests:        is there a test that would FAIL without the fix?
+          - PR hygiene:   clear, accurate title and summary?
+
+        Return a verdict: approve | request_changes | unparseable.
+        If request_changes, list concrete, actionable fixes — each one a
+        specific change the author must make. Those drive the revision loop;
+        the draft is regenerated with your fix-list and re-reviewed.
+      into: review
+    risk: low
+
+  - id: open_pr
+    awaits:
+      - review_fix
+    agent:
+      driver: claude-code
+      prompt: |
+        The fix below has passed judge review. Open a pull request for it.
+
+        Approved fix:
+        {{fix_draft}}
+
+        Do this:
+          1. Create a branch off the default branch named
+             fix/<short-slug-derived-from-the-PR-title>.
+          2. Apply the change from the "## Patch" section and add the test
+             from the "## Test" section.
+          3. Open a pull request using the githubCreatePR tool, with the
+             "## PR title" as the title and the "## Summary" — followed by a
+             line "Fixes incident: {{INCIDENT_TITLE}}" — as the body.
+
+        Opening a PR is a write action; it will pause at the approval gate
+        for a human to confirm before it lands. After it succeeds, respond
+        with ONLY this JSON object (no markdown fences):
+        {"prUrl": "<url>", "prNumber": <number>, "branch": "<branch>"}
+
+        If the GitHub connector is not connected, respond with:
+        {"error": "GitHub connector not connected — visit /connections"}
+      into: pr
+    risk: high
+
+  - id: notify
+    awaits:
+      - open_pr
+    tool: slack.post_message
+    channel: "{{SLACK_CHANNEL}}"
+    text: |
+      :white_check_mark: Incident fix ready for review
+      *Incident:* {{INCIDENT_TITLE}} ({{SEVERITY}})
+      *Pull request:* {{pr}}
+      *Judge review:* {{review}}
+    risk: medium

package/templates/recipes/outcome-ingester.yaml

@@ -0,0 +1,53 @@
+# yaml-language-server: $schema=https://patchwork.dev/schemas/recipe.v1.json
+#
+# Outcome Ingester — polls GitHub for issues filed by the Test Guardian Worker
+# and records their dispositions (confirmed / junk / unknown) to
+# ~/.patchwork/outcome-log.jsonl. The worker trust-replay reads this file to
+# flip junk filings to good:false past the 24h durability window, so the ramp
+# demotes workers that file noise rather than rewarding them.
+#
+# Schedule: every 6 hours. Stagger from the triage recipe so the outcome poll
+# runs well after new issues have settled (most "junk" signals appear within
+# hours of filing).
+#
+# Prerequisite: GitHub connector authorised. This ingester scopes its poll by
+# the `label` var below (default "test-failure" — the exact label the
+# triage-failing-tests-autofile recipe's `file_issue` step applies). If you
+# change the label the worker files under, change `label` here to match, or the
+# poll returns nothing and no dispositions are ever recorded.
+apiVersion: patchwork.sh/v1
+name: outcome-ingester
+description: Poll GitHub for Test Guardian issues and record outcome dispositions to the trust-replay store.
+trigger:
+  type: cron
+  at: "0 */6 * * *"
+  vars:
+    - name: repo
+      default: ""
+      description: "owner/repo to poll — SET THIS to the SAME repo the autofile recipe files against; a blank repo makes the search qualifier malformed (`repo: label:...`) so no worker issues are found and no dispositions are recorded"
+    - name: label
+      default: "test-failure"
+      description: "Label that marks worker-filed issues (default matches the Test Guardian Worker)"
+    - name: max
+      default: "50"
+      description: "Max issues to poll per run"
+steps:
+  - id: list_issues
+    tool: github.search_issues
+    query: "repo:{{repo}} label:{{label}}"
+    max: 50
+    into: issues
+
+  # Deterministic — no LLM in the classification path. An earlier LLM-judge
+  # agent step here was non-deterministic in production: the SAME closed/
+  # COMPLETED issues flipped between "confirmed" and "unknown" on alternating
+  # cron fires, and checkedAt was a hallucinated epoch spanning 2023-2027.
+  # Trust-replay reads this log to decide good:true/false, so the
+  # classification step MUST be pure data (state/stateReason/labels) plus
+  # the real clock, not a model's freehand judgment.
+  - id: classify_and_persist
+    when: "{{issues.json}}"
+    tool: outcomes.classify_issues
+    issues: "{{issues.json}}"
+    recipeName: outcome-ingester
+    into: outcome_result

package/templates/recipes/release-notes.yaml

@@ -0,0 +1,30 @@
+# yaml-language-server: $schema=https://patchwork.dev/schemas/recipe.v1.json
+# Body for the Release Worker (templates/workers/release-notes.worker.yaml).
+# Self-waking on every commit (git_hook → onGitCommit, wired in #1016/#1018).
+apiVersion: patchwork.sh/v1
+name: release-notes
+description: After a commit lands, draft a changelog entry from the new commits into the inbox.
+trigger:
+  type: git_hook
+  event: post-commit
+steps:
+  - tool: git.log_since
+    since: 24h
+    into: commits
+  - agent:
+      prompt: |
+        New commits landed in the last 24h:
+        {{commits}}
+
+        Write a concise changelog entry as a markdown bullet list — one line per
+        user-facing change, grouped under feat / fix / chore. Omit pure noise
+        (merge commits, formatting-only). If nothing is user-facing, say so.
+      # subprocess `claude -p` under your existing subscription (no API key)
+      driver: claude-code
+      into: notes
+  - tool: file.write
+    path: ~/.patchwork/inbox/release-notes-{{date}}.md
+    content: |
+      # Release notes draft — {{date}}
+
+      {{notes}}

package/templates/recipes/triage-failing-tests-autofile.yaml

@@ -0,0 +1,152 @@
+# yaml-language-server: $schema=https://patchwork.dev/schemas/recipe.v1.json
+#
+# OPT-IN variant of `triage-failing-tests` for the Test Guardian Worker.
+#
+# This is the "make it real" recipe: it does everything the base recipe does
+# (correlate the failure, write a triage note) AND files a GitHub issue — an
+# explicit, RISKY, owned action (`github.create_issue` → the `issue` action
+# class: compensable + brand-exposed). It is the action that lets the worker's
+# trust dial actually move.
+#
+# DEFAULT-OFF: the Test Guardian Worker ships pointing at the base
+# `triage-failing-tests` (draft-to-file only), so nothing here runs until you
+# switch the worker to this recipe. To enable, IN THIS ORDER:
+#   1. enable the `worker.autonomy` feature flag FIRST — this is what GATES the
+#      github.create_issue step for human approval until the worker EARNS L4
+#      trust on the `issue` class (then it flows autonomously);
+#   2. point `recipe:` in templates/workers/test-guardian.worker.yaml at
+#      `triage-failing-tests-autofile`;
+#   3. set `trigger.vars.repo` below to your "owner/repo".
+#
+# ⚠ ORDER MATTERS. With `worker.autonomy` OFF, steps 2+3 ALONE file a real issue
+# on EVERY failing test run with NO approval — an automated (on_test_run) flat
+# run is not gated unless the flag is on. The flag ADDS the gate; it is not what
+# enables filing. Enable the flag first so the very first filing is gated.
+# (Expect more approvals up front; the payoff — autonomous filing — comes after L4.)
+apiVersion: patchwork.sh/v1
+name: triage-failing-tests-autofile
+description: On a failing test run, write a triage note and FILE a GitHub issue (opt-in; gated by the worker trust ramp).
+trigger:
+  type: on_test_run
+  filter: failure
+  vars:
+    # REQUIRED to enable — the repository the issue is filed against.
+    - name: repo
+      default: ""
+      description: "owner/repo the issue is filed against (set this to enable)"
+steps:
+  - id: get_commits
+    tool: git.log_since
+    since: 12h
+    into: recent
+  - id: triage_agent
+    agent:
+      prompt: |
+        Tests just failed. Runner: {{runner}}. Failed {{failed}} / {{total}}.
+
+        Failures:
+        {{failures}}
+
+        Recent commits (last 12h) that may be responsible:
+        {{recent}}
+
+        Write a triage note (≤5 sentences): (1) which test(s) failed, (2) the
+        single most likely cause, (3) the suspect commit if any, (4) the first
+        command to run to confirm.
+      driver: claude-code
+      into: triage
+  # Dedup read (issue-hygiene, part 1). Pull the currently-OPEN `test-failure`
+  # issues so the decision step below can avoid filing a duplicate of a failure
+  # that is already tracked. `assignee: any` is REQUIRED — worker-filed issues
+  # are unassigned, so the default `@me` filter would never see them.
+  # `optional: true` makes this FAIL-OPEN: if the list call fails (token expiry,
+  # rate limit, MCP outage) the run continues and `{{existing}}` is empty — a
+  # missed dedup (one possible duplicate) is strictly better than a blocked real
+  # filing. Dedup must never gate a genuine failure behind GitHub availability.
+  # `when: "{{repo}}"` skips this read when `repo` is unset: with an empty repo
+  # the connector would drop the owner/repo filter and dedup against EVERY
+  # accessible repo's `test-failure` issues (cross-repo poisoning). Skipping
+  # leaves `{{existing}}` empty → "not a duplicate"; the misconfig still surfaces
+  # loudly at file_issue (which hard-errors on an empty repo).
+  - id: list_existing
+    when: "{{repo}}"
+    optional: true
+    tool: github.list_issues
+    repo: "{{repo}}"
+    labels:
+      - test-failure
+    state: open
+    assignee: any
+    max: 30
+    into: existing
+  # Decision gate (issue-hygiene, part 2). A worker triage is a LEAD, not a
+  # verified diagnosis — the on_test_run event can fire on a flake, a transient,
+  # or an already-fixed failure (e.g. #1046: a triage that confidently blamed a
+  # commit for a test that actually passes on `main`). This single step answers
+  # the worker's real question — "is this worth filing a NEW issue?" — which is
+  # true ONLY when the failure (1) REPRODUCES on an isolated re-run AND (2) is
+  # NOT already covered by an open issue from `list_existing`. A `false` run
+  # still writes the draft note (below) but files NO issue: strictly noise-
+  # reducing, never blocks a real, novel failure.
+  # `optional: true` is a deliberate FAIL-CLOSED-ON-FILING guard: if THIS agent
+  # step itself fails (the re-run crashes, the model returns silent-fail /
+  # narration-only output), the run does NOT halt — `{{should_file}}` is left
+  # unset, so the file_issue gate below renders falsy and SKIPS. A decision we
+  # couldn't make must never auto-file a brand-exposed issue, and the triage note
+  # (written next) is preserved either way.
+  - id: decide_file
+    optional: true
+    agent:
+      prompt: |
+        A test run reported failures and this triage was written:
+
+        {{triage}}
+
+        Open issues already labelled `test-failure` (JSON; may be empty or an
+        error object if the lookup failed — treat anything other than a clear
+        matching issue as "not a duplicate"):
+        {{existing}}
+
+        Do BOTH checks, then decide whether to file a NEW issue:
+        1. REPRODUCE: re-run ONLY the specific failing test(s) named above, in
+           isolation, on the current checkout — e.g.
+           `npx vitest run <file> -t "<test name>"`. A test that PASSES on
+           isolated re-run is a flake / transient / already-fixed.
+        2. DEDUP: check whether an OPEN issue above already tracks THIS failure
+           (same test/file and root cause). If so, it is a duplicate.
+
+        Output EXACTLY one word and nothing else:
+          true   — the failure REPRODUCED *and* is NOT already tracked (file it)
+          false  — it did NOT reproduce, OR an open issue already covers it
+      driver: claude-code
+      into: should_file
+  - id: write_note
+    tool: file.write
+    path: ~/.patchwork/inbox/test-triage-{{date}}-{{time}}.md
+    content: |
+      # Test triage — {{date}} {{time}}
+
+      Runner {{runner}} · failed {{failed}}/{{total}} · file new issue: {{should_file}}
+
+      {{triage}}
+  # The risky owned action. Runs AFTER the draft is written — and the two steps
+  # between the note and here (list_existing, decide_file) are BOTH `optional`,
+  # so a gate rejection, a missing `repo`, a non-reproducing failure, a duplicate,
+  # OR a crashed decision agent never halts before write_note: the triage note is
+  # always preserved. Files ONLY when the decision step emitted a truthy verdict —
+  # `when` skips the step (not a failure) on a falsy guard ("", "false", "0",
+  # "null", "undefined"), which also covers the unset-var case when decide_file
+  # failed fail-open.
+  - id: file_issue
+    when: "{{should_file}}"
+    tool: github.create_issue
+    repo: "{{repo}}"
+    title: "Test triage {{date}}: {{runner}} failing {{failed}}/{{total}}"
+    body: |
+      {{triage}}
+
+      ---
+      _Filed by the Test Guardian Worker from a failing {{runner}} run (reproduced on isolated re-run; no open duplicate)._
+    labels:
+      - test-failure
+    into: filed_issue

package/templates/recipes/triage-failing-tests.yaml

@@ -0,0 +1,38 @@
+# yaml-language-server: $schema=https://patchwork.dev/schemas/recipe.v1.json
+# Body for the Test Guardian Worker
+# (templates/workers/test-guardian.worker.yaml). Self-waking on a FAILING test
+# run (on_test_run.filter: failure). Correlates the failure with recent commits
+# and writes a triage note — richer than the plain watch-failing-tests recipe.
+apiVersion: patchwork.sh/v1
+name: triage-failing-tests
+description: On a failing test run, correlate the failure with recent commits and write a triage note.
+trigger:
+  type: on_test_run
+  filter: failure
+steps:
+  - tool: git.log_since
+    since: 12h
+    into: recent
+  - agent:
+      prompt: |
+        Tests just failed. Runner: {{runner}}. Failed {{failed}} / {{total}}.
+
+        Failures:
+        {{failures}}
+
+        Recent commits (last 12h) that may be responsible:
+        {{recent}}
+
+        Write a triage note (≤5 sentences): (1) which test(s) failed, (2) the
+        single most likely cause, (3) the suspect commit if any, (4) the first
+        command to run to confirm.
+      driver: claude-code
+      into: triage
+  - tool: file.write
+    path: ~/.patchwork/inbox/test-triage-{{date}}-{{time}}.md
+    content: |
+      # Test triage — {{date}} {{time}}
+
+      Runner {{runner}} · failed {{failed}}/{{total}}
+
+      {{triage}}

package/templates/workers/dependency-upkeep.worker.yaml

@@ -0,0 +1,26 @@
+# Dependency-upkeep worker — top-right beachhead. The classic low-blast,
+# continuous, verifiable job to land first (the wedge): watch for outdated /
+# vulnerable deps and open a bump PR.
+id: dependency-upkeep-worker
+name: Dependency Upkeep Worker
+sector: engineering
+recipe: dependency-bump
+responsibilities:
+  - Audit dependencies for outdated / vulnerable packages
+  - Open a bump PR with the changelog and advisory links
+owns:
+  - deps-read # auditDependencies / getSecurityAdvisories — read-only
+  - vcs-local # gitCommit / gitCheckout on a branch — reversible
+  - vcs-remote # githubCreatePR — compensable + brand-exposed
+# Opening a PR (vcs-remote) is compensable — but there is NO outcome grader for
+# PRs yet (OutcomeStore is issue-URL-keyed only), so a bump PR nobody reviews
+# would fold good:true past the 24h durability window: the same trust-by-neglect
+# the issue-class fix (#1064) closed, surviving on the PR path. Cap below the
+# compensable auto-allow rung (L2) so PR-opening stays human-approved regardless
+# of earned level — mirroring test-guardian's `issue` cap. Raise to 3 (open PRs
+# autonomously, merging still human) once a PR-outcome grader exists (merged/
+# closed-state detection feeding the OutcomeStore).
+autonomyCeiling: 1
+competence:
+  mean: 0.8
+  strength: 4

package/templates/workers/release-notes.worker.yaml

@@ -0,0 +1,17 @@
+# Release worker — top-right beachhead (high task-impact × high autonomy-tolerance).
+# Body: a chained recipe triggered on merge-to-main that drafts release notes.
+# Reversible, verifiable, internal → fast ramp evidence.
+id: release-notes-worker
+name: Release Worker
+sector: engineering
+recipe: release-notes # the recipe that forms this worker's body
+responsibilities:
+  - Watch merges to main and draft release notes / changelog entries
+  - Summarize the diff and link the PRs in the range
+owns:
+  - vcs-read # getGitStatus / getGitDiff / getGitLog — reversible, low blast
+  - fs-write # editText / createFile (the changelog) — reversible
+autonomyCeiling: 4 # internal + reversible: may earn full autonomy
+competence: # shipped competence (a prior), NOT trust — trust earns locally
+  mean: 0.85
+  strength: 4

package/templates/workers/test-guardian.worker.yaml

@@ -0,0 +1,24 @@
+# Test-guardian worker — top-right beachhead. Fires on a test-run failure
+# (on_test_run trigger), investigates the failure, and files an issue. Reversible
+# investigation + compensable issue creation → may earn full autonomy on triage.
+id: test-guardian-worker
+name: Test Guardian Worker
+sector: engineering
+recipe: triage-failing-tests
+responsibilities:
+  - On a failing test run, investigate the stack trace and identify the cause
+  - File / update an issue with the failure summary and the suspect commit
+owns:
+  - ci # runTests (re-runnable) — reversible
+  - vcs-read # getGitDiff / gitBlame to find the suspect commit
+  - issue # githubCreateIssue / addLinearComment — compensable + brand-exposed
+# Capped below the compensable auto-allow threshold (L2): the ramp has only
+# been validated on synthetic data (one planted break, 16 gate decisions) and
+# the outcome-verification signal (confirmed/junk labelling, see outcomeStore.ts)
+# has no real-world recall/false-negative track record yet. Earned trust on
+# `issue` can climb, but auto-filing stays gated for human approval until that
+# signal exists. Raise once a real-world graduation is observed and confirmed.
+autonomyCeiling: 1
+competence:
+  mean: 0.8
+  strength: 4