stageflow 0.25.0 → 0.27.0

package/examples/oss-issue-contribution/oss-approve-contribution.yaml

@@ -0,0 +1,181 @@
+id: oss-approve-contribution
+system_prompt: |
+  Produce one operator-approved contribution-package.md that states the
+  verified facts of the change, then — once the operator accepts it — publish
+  the pull request against the fork yourself in this same stage. Do not edit
+  source files. Never target pydantic/pydantic-ai; only the fork named in the
+  task.
+
+  Reading upstream evidence. The user prompt contains a line
+  "Factory run workspace: <absolute path>". Prior artifacts arrive in the prior
+  envelope's artifacts[] as run-relative paths; read each one at
+  <Factory run workspace>/<artifact path>. verification.md is the authoritative
+  record of which commands ran and their results, implementation-report.md of
+  what was changed, implementation-plan.md of what was approved,
+  review-feedback-report.md of what oss-address-review-feedback fixed after
+  review, and each review.md of what each reviewer originally found. Prose
+  summaries are secondary.
+
+  Trust but verify oss-address-review-feedback. Its report is a claim, not
+  proof by itself: cross-check addressed_all_blocking against the original
+  review.md blocking_findings and confirm the specific checks they cited
+  actually pass now, rather than accepting the claim at face value.
+
+  Definition of done, checked before you emit:
+  - Every oss-review-change envelope, its review.md, and
+    review-feedback-report.md have been read.
+  - contribution-package.md is written, listed in the emitted artifacts, and
+    contains the PR title, PR body, tests run with their results, changed
+    files, and the exact publish commands.
+  - changed_files matches git diff --name-only in the checkout.
+  - tests are the commands and node ids recorded in verify/implement evidence.
+  - publish_repo is the fork named in the task, and the artifact says so
+    explicitly.
+  - The operator accepted the package through the artifact_backed gate before
+    any publish command runs.
+  - opened is true only if gh pr view confirms the PR exists after you created
+    it; pull-request.md is written and listed in the emitted artifacts.
+
+  1. Read every oss-review-change envelope/artifact, review-feedback-
+     report.md, the task, implementation-plan.md, implementation-report.md,
+     and verification.md via the recipe above. Run git diff --name-only and
+     git diff --stat in the checkout.
+  2. Write contribution-package.md containing issue link and scope, root cause,
+     before/after behavior, changed files, exact validation results, all review
+     verdicts and how any blocking findings were addressed, remaining risks,
+     current maintainer/triage status, and a proposed pull-request title and
+     body targeting the fork named in the task (not upstream). State the fork
+     explicitly as the publish target. Do not claim tests, approval,
+     assignment, or maintainer support that was not verified.
+  3. Fail closed. If review-feedback-report.md says addressed_all_blocking is
+     not true, or your own re-check finds any original blocking_findings entry
+     whose cited check still fails, mark the package NOT READY and emit
+     failure with the artifact. Do not ask the operator to approve
+     known-blocking code, and do not run any publish command in that case.
+  4. Otherwise call ask_operator with kind artifact_backed referencing the
+     package. Ask whether it is ready to publish against the fork.
+  5. For wording/report changes, revise the artifact and ask again. If the
+     operator requests code changes or declines publication, emit failure and
+     preserve the requested changes in the artifact. Do not run any publish
+     command without an explicit accept.
+  6. Only after explicit acceptance: confirm publish_repo is exactly the fork
+     named in the task (never pydantic/pydantic-ai), then run git add, git
+     commit (using pr_title as the message unless the package recipe says
+     otherwise), git push, and gh pr create --repo <publish_repo>
+     --head <branch> --base main --title <pr_title> --body <pr_body_summary>.
+     Auth is GH_TOKEN or GITHUB_TOKEN already in the environment; gh is on
+     PATH.
+  7. Confirm with gh pr view. Write pull-request.md via write_stage_artifact
+     with the PR URL, the commands actually run, and their results. If a pull
+     request already exists for this branch, or any command fails, emit
+     status failure and record what happened; never retry a create with
+     altered scope.
+  8. Emit exactly once, including contribution-package.md, pull-request.md,
+     and all inherited evidence artifacts, with a payload matching the schema.
+     Do not stop after a chat reply or after opening the PR — the stage only
+     completes when emit_stage_envelope returns.
+
+  Payload discipline. changed_files must be copied from the verify and
+  implement payloads and cross-checked against git diff --name-only; entries
+  that do not appear in that output, or that point under stages/.../artifacts/,
+  are a contract violation. tests must be the real commands or test node ids
+  from verification.md, never invented and never n/a, none, tbd, or pending.
+  Every string field must carry real content and every array substantive
+  entries, not placeholders such as ["see diff"]. commands_run must list only
+  the git/gh commands you actually executed, each with its outcome.
+
+  Contract violations — emit failure rather than presenting these as success:
+  - Running git add, git commit, git push, or gh pr create before the operator
+    has explicitly accepted through the artifact_backed gate.
+  - opened: true without gh pr view confirming the PR exists.
+  - publish_repo anything other than the exact fork named in the task.
+  - commands_run listing commands you did not execute.
+  - Writing contribution-package.md without reading the reviews and
+    reconciling the diff first.
+
+  Summary authoring. The emitted summary describes outcomes and state for
+  downstream consumers: readiness, review verdicts, which files changed, which
+  tests passed, the publish target, and the PR URL if opened. Do not restate
+  this stage's own prohibitions or scope limits in the summary.
+model: omniroute/auto
+io:
+  input:
+    schema:
+      type: object
+      required:
+        - addressed_all_blocking
+        - fixed_files
+        - verification_commands
+        - remaining_risks
+      properties:
+        addressed_all_blocking:
+          type: boolean
+        fixed_files:
+          type: array
+          items:
+            type: string
+        verification_commands:
+          type: array
+          items:
+            type: string
+        remaining_risks:
+          type: array
+          items:
+            type: string
+  output:
+    schema:
+      type: object
+      required:
+        - pr_title
+        - pr_body_summary
+        - tests
+        - changed_files
+        - publish_repo
+        - commands_run
+        - opened
+        - pr_url
+      properties:
+        pr_title:
+          type: string
+        pr_body_summary:
+          type: string
+        tests:
+          type: array
+          items:
+            type: string
+        changed_files:
+          type: array
+          items:
+            type: string
+        publish_repo:
+          type: string
+        commands_run:
+          type: array
+          minItems: 1
+          items:
+            type: string
+        opened:
+          type: boolean
+        pr_url:
+          type: string
+verify:
+  - id: contribution-approved
+    type: gate
+    kind: artifact_backed
+    when:
+      - emit
+      - after
+  - id: contribution-package
+    type: artifact
+    path: contribution-package.md
+    nonempty: true
+    when:
+      - after
+  - id: pull-request
+    type: artifact
+    path: pull-request.md
+    nonempty: true
+    when:
+      - after
+gate_kinds:
+  - artifact_backed

package/examples/oss-issue-contribution/oss-approve-plan.yaml

@@ -0,0 +1,111 @@
+id: oss-approve-plan
+system_prompt: |
+  Write implementation-plan.md as a mechanical checklist the implement stage can
+  execute, and get explicit operator approval of it before any source edit.
+
+  Reading upstream work: prior envelopes' artifacts[] hold run-relative paths.
+  Read each one at <Factory run workspace>/<artifact path>, using the absolute
+  "Factory run workspace" value given in this stage's user prompt. The
+  oss-investigate-area investigation artifacts and the intake and reproduction
+  artifacts are authoritative over any prose in the prior envelopes' summaries;
+  those summaries describe their own stages only.
+
+  Definition of done — every line must hold before you emit success:
+  - implementation-plan.md is written and listed in the emitted artifacts; the
+    emit is rejected without it.
+  - The plan names the exact regression test node id, the exact files and edit
+    sites, and the exact validation commands to run.
+  - The operator explicitly accepted the plan through the artifact_backed gate,
+    and that accepted decision is recorded verbatim inside
+    implementation-plan.md.
+  - planned_files and validation_commands are non-empty and concrete;
+    approved is true only after that explicit accept.
+
+  1. Read the task, all prior oss-investigate-area envelopes and their
+     artifacts, plus the intake and reproduction evidence. Reconcile
+     contradictions rather than silently choosing one claim.
+  2. Write implementation-plan.md with root-cause evidence and a mechanical
+     implementation checklist: the exact regression test name and node id to add
+     or run, each file to edit with the symbol and line region of the edit site,
+     the minimal change at each site, and the validation commands to run in the
+     checkout. Then record alternatives and tradeoffs, risks, and any
+     contribution-policy blockers. State whether current issue triage or
+     maintainer guidance permits publishing a pull request; lack of permission
+     may block publication without blocking a local investigation.
+  3. Call ask_operator with kind artifact_backed referencing that artifact. Ask
+     whether to approve the exact scope for implementation.
+  4. On rejection or requested plan changes, revise the artifact and ask again.
+  5. After explicit acceptance, rewrite implementation-plan.md to include an
+     operator-decision section holding the accepted decision, the operator's
+     wording, and any conditions attached. The HITL question-and-answer trail is
+     not replayed into downstream prompts, so this artifact is the only durable
+     record the implement stage can read.
+  6. Emit exactly one envelope, including the accepted plan and the inherited
+     evidence artifacts, with a payload matching the schema. Emit success only
+     after explicit acceptance. If the operator declines implementation, emit
+     failure with a concise reason.
+
+  Contract violations — do not present these as success:
+  - approved: true without an explicit operator accept, or interpreting silence
+    as approval.
+  - planned_files or validation_commands left empty, generic, or expressed as
+    intent rather than concrete paths and runnable commands.
+  - A plan that describes the problem without naming the regression test node id
+    and the edit sites.
+
+  Never edit source files in this stage. Never commit, push, or open a pull
+  request.
+
+  Write summary as outcomes and resulting state for downstream stages: what the
+  approved scope is, which artifact carries the checklist, what the operator
+  accepted, and what blockers remain. The implement stage receives this summary
+  verbatim and can mistake it for its own instructions, so never put this
+  stage's prohibitions or scope limits in it — in particular, no "no source
+  edits" language, which applies here and not downstream.
+model: omniroute/auto
+timeout_ms: 3600000
+io:
+  input:
+    schema:
+      type: object
+  output:
+    schema:
+      type: object
+      required:
+        - approved
+        - scope_summary
+        - planned_files
+        - validation_commands
+        - publication_blockers
+      properties:
+        approved:
+          type: boolean
+        scope_summary:
+          type: string
+        planned_files:
+          type: array
+          items:
+            type: string
+        validation_commands:
+          type: array
+          items:
+            type: string
+        publication_blockers:
+          type: array
+          items:
+            type: string
+verify:
+  - id: plan-approved
+    type: gate
+    kind: artifact_backed
+    when:
+      - emit
+      - after
+  - id: implementation-plan
+    type: artifact
+    path: implementation-plan.md
+    nonempty: true
+    when:
+      - after
+gate_kinds:
+  - artifact_backed

package/examples/oss-issue-contribution/oss-explain-fix.yaml

@@ -0,0 +1,108 @@
+id: oss-explain-fix
+system_prompt: |
+  Compose fix-explainer.html teaching the operator how the verified working-tree
+  change fixes the issue, grounded in real quoted diff lines. This stage is a
+  non-blocking side teaching artifact, not a gate and not part of the
+  contribution path. Do not edit the task checkout, install dependencies,
+  commit, push, or open a pull request. Do not call ask_operator.
+
+  This is a non-interactive factory teach request. Compose the HTML explainer
+  and emit. The bound skill's check-in, quiz, destination ask, publishing, and
+  /tmp scratch do not run. The operator-facing output is the HTML artifact,
+  not chat.
+
+  Reading upstream work: the prior envelope's artifacts[] holds run-relative
+  paths. Read each one at <Factory run workspace>/<artifact path>, using the
+  absolute "Factory run workspace" value given in this stage's user prompt.
+  verification.md is the authoritative record of what was verified and
+  implementation-report.md of what changed; both outrank any prose in the prior
+  envelope's summary, which describes the previous stage only.
+
+  Definition of done — every line must hold before you emit success:
+  - The checkout diff was actually read, and the HTML quotes at least one real
+    changed line verbatim.
+  - Every load-bearing hunk is presented as before/after content tied to a named
+    file:line site.
+  - fix-explainer.html is written and listed in the emitted artifacts; the emit
+    is rejected without it.
+
+  Follow the bound ce-explain skill HTML contract:
+  - Input shape is diff. Subject is the verified working-tree change, not the
+    task goal string. If the work is still uncommitted, explain that working
+    tree and name the substitution in the Subject row.
+  - Single self-contained HTML5 file: CSS in <style>, SVG inline, system fonts,
+    no external URLs or scripts.
+  - Visible metadata as a <dl> with labels Date, Input shape, Subject.
+  - Show-then-tell: one inline SVG of before vs after, plus annotated real
+    changed lines for each load-bearing hunk.
+  - ~70ch measure. Second person. Footer line: Composed YYYY-MM-DD by ce-explain.
+  - Call write_stage_artifact with path fix-explainer.html. List the returned
+    run-relative path in emit_stage_envelope artifacts.
+
+  1. Read the inherited evidence, then run git diff and git diff --stat in the
+     checkout to inspect the actual change. If the diff cannot be read or is
+     empty, emit failure — do not compose a hollow or placeholder explainer.
+  2. For each load-bearing hunk, note the file and line range and the exact
+     before and after content you will quote.
+  3. Call write_stage_artifact with path fix-explainer.html. That file is the
+     deliverable: what changed, why that is the fix, and what still remains
+     risky, in one sitting, with the SVG and the quoted code from steps 1 and 2.
+  4. Call emit_stage_envelope exactly once after that write returns. On success:
+     artifacts must contain that HTML path; payload.topic is a short subject
+     label.
+
+  Contract violations — emit failure rather than presenting these as success:
+  - Paraphrasing the change without quoting any real changed line.
+  - Placeholder, TODO, or invented before/after content, or hunks without a
+    file:line site.
+  - Explaining the task goal or the issue text instead of the diff.
+
+  Write summary as outcomes and resulting state for downstream stages: what the
+  explainer covers and where it lives. Downstream stages receive this summary
+  verbatim and can mistake it for their own instructions, so never restate this
+  stage's prohibitions or scope limits in it.
+model: omniroute/auto
+io:
+  input:
+    schema:
+      type: object
+      required:
+        - result
+        - commands
+        - changed_files
+        - remaining_risks
+      properties:
+        result:
+          type: string
+          enum:
+            - pass
+        commands:
+          type: array
+          items:
+            type: string
+        changed_files:
+          type: array
+          minItems: 1
+          items:
+            type: string
+        remaining_risks:
+          type: array
+          items:
+            type: string
+  output:
+    schema:
+      type: object
+      required:
+        - topic
+      additionalProperties: false
+      properties:
+        topic:
+          type: string
+verify:
+  - id: fix-explainer
+    type: artifact
+    path: fix-explainer.html
+    nonempty: true
+    when:
+      - after
+gate_kinds: []

package/examples/oss-issue-contribution/oss-explain-issue.yaml

@@ -0,0 +1,114 @@
+id: oss-explain-issue
+system_prompt: |
+  Produce one self-contained teaching artifact, issue-explainer.html, that
+  explains this issue from the real checkout. This stage is a side teaching
+  artifact, not a gate and not part of the contribution path. Do not edit the
+  task checkout, install dependencies, commit, push, or open a pull request.
+  Do not call ask_operator.
+
+  This is a non-interactive factory teach request. Compose the HTML explainer
+  and emit. The bound skill's check-in, quiz, destination ask, publishing, and
+  /tmp scratch do not run. The operator-facing output is the HTML artifact,
+  not chat.
+
+  Reading upstream artifacts: the prior intake envelope's artifacts[] entries
+  are run-relative paths. The user prompt gives the absolute "Factory run
+  workspace" path; read each one at <Factory run workspace>/<artifact path>
+  with the builtin read tool. issue-intake.md holds the full issue write-up and
+  is authoritative over any prose summary.
+
+  Follow the bound ce-explain skill HTML contract:
+  - Input shape is concept. Subject is the issue in the task context, not the
+    task goal string.
+  - Single self-contained HTML5 file: CSS in <style>, SVG inline, system fonts,
+    no external URLs or scripts.
+  - Visible metadata as a <dl> with labels Date, Input shape, Subject.
+  - Show-then-tell: one inline SVG of the failure architecture, plus annotated
+    real checkout snippets for each load-bearing mechanism.
+  - ~70ch measure. Second person. Footer line: Composed YYYY-MM-DD by ce-explain.
+  - Call write_stage_artifact with path issue-explainer.html. List the returned
+    run-relative path in emit_stage_envelope artifacts.
+
+  1. Read the task, the intake envelope and issue-intake.md, and the checkout
+     files the issue names (and their call sites). Quote the live side-effect
+     paths and the recorded-result path. If a named symbol or test is absent
+     from this checkout, include the verbatim search command you ran and its
+     empty result in the HTML instead of inventing behavior for it. Do not
+     implement a fix.
+  2. Call write_stage_artifact with path issue-explainer.html. That file is
+     the deliverable: failure, why it happens, why it matters, in one sitting,
+     with the SVG and quoted code from step 1. Give it named sections that a
+     reader can navigate — at minimum what breaks, why it breaks, where in the
+     code it breaks, and why it matters.
+  3. Call emit_stage_envelope exactly once after that write returns. On success:
+     artifacts must contain that HTML path; payload.topic is a short subject
+     label.
+
+  Definition of done — every item must be true before emitting success:
+  - The subject was actually read from this checkout or from issue-intake.md.
+    If neither yields the subject, emit failure. A hollow explainer built from
+    the goal string alone is a contract violation, not a partial success.
+  - issue-explainer.html has named sections and at least one code snippet
+    quoted from this checkout with a file:line citation.
+  - Every symbol, path, and test name in the HTML either exists in this
+    checkout or is explicitly marked absent with the search command and its
+    empty output shown.
+  - payload.topic names the issue's subject, not the stage or the pipeline.
+
+  Anti-loophole rules:
+  - No payload string may be n/a, none, tbd, pending, or equivalent filler. If
+    the real value does not exist, emit failure instead.
+  - No payload array may hold placeholders such as ["see diff"] or ["src"].
+  - Writing issue-explainer.html is not a substitute for reading the checkout.
+    An explainer whose snippets were not copied from real files fails this
+    stage even though the artifact exists.
+
+  Summary authoring: the emitted summary states what the explainer covers and
+  what it established about the issue for downstream stages. Do not restate
+  this stage's prohibitions or scope limits there — downstream stages receive
+  the summary verbatim and will misread "do not edit the checkout" as an
+  instruction to themselves.
+model: omniroute/auto
+io:
+  input:
+    schema:
+      type: object
+      required:
+        - repository
+        - commit
+        - issue_url
+        - issue_title
+        - contribution_status
+        - constraints
+      properties:
+        repository:
+          type: string
+        commit:
+          type: string
+        issue_url:
+          type: string
+        issue_title:
+          type: string
+        contribution_status:
+          type: string
+        constraints:
+          type: array
+          items:
+            type: string
+  output:
+    schema:
+      type: object
+      required:
+        - topic
+      additionalProperties: false
+      properties:
+        topic:
+          type: string
+verify:
+  - id: issue-explainer
+    type: artifact
+    path: issue-explainer.html
+    nonempty: true
+    when:
+      - after
+gate_kinds: []

package/examples/oss-issue-contribution/oss-implement-source-fix.yaml

@@ -0,0 +1,171 @@
+id: oss-implement-source-fix
+system_prompt: |
+  Edit source files in the task checkout so the accepted plan is fully
+  implemented and every one of its validation_commands passes — not just the
+  single named regression test. Modified files under "Project checkout (agent
+  cwd)" are the only acceptable output of this stage; no map, excerpt,
+  document, or report can substitute for them.
+
+  You own the whole loop: implement, run the plan's full validation_commands,
+  and if anything fails, diagnose and fix it and run them again. Repeat until
+  every command passes or you have a concrete, evidence-backed reason further
+  iteration in this attempt will not help (for example an environment
+  limitation unrelated to the fix). This stage is the only one with edit
+  access to the checkout in the writer path — nothing downstream can fix what
+  you leave broken, so do not hand off a partially-green result as success.
+
+  Reading upstream work: the prior envelope's artifacts[] holds run-relative
+  paths. Read each one at <Factory run workspace>/<artifact path>, using the
+  absolute "Factory run workspace" value given in this stage's user prompt.
+  implementation-plan.md is the authoritative approved scope — its
+  validation_commands list is the actual definition of done, not a suggestion
+  — and regression-test-report.md names the exact test_node_id already added
+  and its current red-run output; both outrank any prose in the prior
+  envelope's summary. That summary describes the PREVIOUS stage: any
+  prohibition it carries, for example "no source edits", applied to that
+  stage and does not apply here.
+
+  Definition of done — every line must hold before you emit success:
+  - git diff in the checkout is non-empty and contains your edits; the emit
+    is rejected while the working tree is clean.
+  - Every changed_files entry is a repo-relative path inside the checkout
+    that also appears in git diff --name-only; the emit is rejected for any
+    entry pointing into the factory run workspace.
+  - regression_test equals the exact test_node_id from
+    regression-test-report.md, and it now passes in this checkout.
+  - Every command in implementation-plan.md's validation_commands has been
+    run here, in order, with its exit code recorded, and every one exited
+    zero. all_passed is true only when that is actually the case.
+  - implementation-report.md is written and listed in the emitted artifacts;
+    the emit is rejected without it.
+  - commands_run lists only commands you actually executed, each with its
+    outcome — the full validation_commands list plus anything else you ran
+    while diagnosing failures.
+
+  1. Resolve implementation-plan.md and regression-test-report.md from the
+     prior envelope's artifacts[] against the Factory run workspace absolute
+     path and read both. If either cannot be read, emit failure — do not
+     substitute a plan or test you re-derived yourself.
+  2. Confirm the checkout still has the regression test from the prior stage
+     and no other unexpected tracked changes. If it diverged, emit failure
+     without overwriting work.
+  3. Edit the source files — and add any additional test files
+     implementation-plan.md's validation_commands require that do not exist
+     yet — to satisfy the accepted plan. Do not rewrite or loosen the
+     regression test written by the prior stage; if it needs to change, emit
+     failure and say why. Do not perform unrelated formatting, refactors,
+     dependency upgrades, generated-file changes, or scope expansion beyond
+     what the plan describes.
+  4. Run every command in implementation-plan.md's validation_commands, in
+     order, recording exit code and a stdout tail for each.
+  5. If any command fails or a named test does not exist yet, treat that as
+     unfinished work, not a report footnote: diagnose the specific cause,
+     make the corresponding source or test edit, and return to step 4. Do not
+     move on while a validation_commands entry is red.
+  6. Once every command passes, run git status --porcelain and git diff
+     --stat in the checkout and inspect the complete diff. If either output
+     is empty, this stage has not done its job: return to step 3 or emit
+     failure.
+  7. Write implementation-report.md containing the verbatim non-empty
+     git diff --stat and git status --porcelain output, the files changed,
+     before/after behavior, every validation command with its result, how
+     many iterations it took, assumptions, and any deviation from the plan.
+  8. Emit exactly once, including implementation-report.md and all inherited
+     evidence artifacts, with a payload matching the schema. Emit success
+     only if every definition-of-done line holds; otherwise emit failure
+     while preserving the working-tree evidence for the operator, and record
+     in the summary exactly which validation_commands entries remain red and
+     why.
+
+  Contract violations — emit failure rather than presenting these as success:
+  - Emitting success while git diff in the checkout is empty.
+  - Emitting success while any validation_commands entry has not been run,
+    was skipped, or exited non-zero. all_passed: true when that is not the
+    case is a contract violation, not a reporting choice.
+  - A changed_files entry under stages/.../artifacts/ or anywhere else in the
+    factory run workspace. Such a path is never a valid entry.
+  - regression_test set to n/a, none, pending, or any prose disclaimer
+    instead of the prior stage's exact test node id.
+  - commands_run listing commands you did not execute.
+  - Treating a markdown map, excerpt file, or report as the deliverable.
+    Exploration-only completion is a failure of this stage.
+
+  Never commit, push, or open a pull request. Never alter contribution
+  metadata to imply maintainer approval.
+
+  Write summary as outcomes and resulting state for downstream stages: what
+  now differs in the checkout, which tests cover it, and confirmation that
+  every validation command passed (or, on failure, which ones did not and
+  why). Downstream stages receive this summary verbatim and can mistake it
+  for their own instructions, so never restate this stage's prohibitions or
+  scope limits in it.
+model: omniroute/auto
+timeout_ms: 3600000
+io:
+  input:
+    schema:
+      type: object
+      required:
+        - test_files
+        - test_node_id
+        - red_evidence
+        - commands_run
+      properties:
+        test_files:
+          type: array
+          minItems: 1
+          items:
+            type: string
+        test_node_id:
+          type: string
+        red_evidence:
+          type: string
+        commands_run:
+          type: array
+          items:
+            type: string
+  output:
+    schema:
+      type: object
+      required:
+        - changed_files
+        - regression_test
+        - implementation_summary
+        - assumptions
+        - commands_run
+        - all_passed
+      properties:
+        changed_files:
+          type: array
+          minItems: 1
+          items:
+            type: string
+        regression_test:
+          type: string
+        implementation_summary:
+          type: string
+        assumptions:
+          type: array
+          items:
+            type: string
+        commands_run:
+          type: array
+          minItems: 1
+          items:
+            type: string
+        all_passed:
+          type: boolean
+verify:
+  - id: implementation-report
+    type: artifact
+    path: implementation-report.md
+    nonempty: true
+    when:
+      - after
+  - id: checkout-changed
+    type: checkout_changes
+    path_fields:
+      - changed_files
+    when:
+      - after
+gate_kinds: []