Files
agent-runtime-framework/task-templates/workflow/bug-verify-sonnet@2.yaml
Paul O'Reilly 8d7b3af77d fix(templates): add AGENT_UPSTREAM_REPO_URL/BRANCH to all workflow templates using the agent fork
Fresh agent branches were seeded from the stale fork main (AR-39 fell through to fork).
Work item 18efa01f-f941-4f16-bb67-9cafbb6d668a.

Claude-Session: https://claude.ai/code/session_01N218bERyNeLhbLmDRDvbWF
2026-10-02 15:03:34 +13:00

108 lines
4.6 KiB
YAML

name: bug-verify-sonnet
version: 2
description: Read-only verification of an ai-resolve-tagged bug using Sonnet planning (CP-side apply-verified self-transition; WF-COMP-25)
runtime: planning-sonnet-repo
input:
state: verify-pending
tags_required: [ai-resolve]
tags_forbidden: []
required_artifacts: []
output:
# WF-COMP-25 / WF-COMP-33 — the CP resolves this pipe-separated string as
# the closed verdict set; the literal value is NEVER PATCHed. The agent's
# packed `verdict` value (see `outputs: [verdict]` on node `agent`) is
# what gets PATCHed onto the run's item `flow_state`.
state: 'verified|rejected'
scope_budget:
files_modified_max: 1
lines_diff_max: 400
wall_clock_seconds_max: 1800
nodes:
# WF-COMP-25 / WF-COMP-25a — the agent's only side effect is its
# declared output `verdict` (one of the two closed values); the CP
# applies the flow_state change. The agent does NOT call the CP and
# does NOT read any internal-service CP credential file.
- id: agent
kind: agent
outputs: [verdict]
template: planning-sonnet-repo
model: sonnet
runtime_env:
AGENT_REPO_URL: "git@gitea.oreillyit.nz-ai-enablement:skynet/agent-runtimes-agents.git"
AGENT_UPSTREAM_REPO_URL: "git@gitea.oreillyit.nz-ai-enablement:skynet/agent-runtimes.git"
AGENT_UPSTREAM_BRANCH: "main"
AGENT_BRANCH: "bug-verify/${item.uuid}"
CP_URL: "https://agents.oreillyit.nz/api"
prompt: |
The agent-runtimes project repo is cloned at /workspace/project.
Change to that directory before doing any work.
Verify the following bug report. This is a READ-ONLY investigation —
do NOT modify any source code. Your only file changes are the
verification artifact described below.
**Title**: ${item.title}
**Bug report**:
${item.body}
Steps:
1. cd /workspace/project
2. Investigate the codebase to determine whether the reported bug
is real, reproducible, and correctly diagnosed. Do not make
code changes — this is verification, not a fix.
3. Write your findings to
spec/bugs/<slug>-verification.md (derive <slug> from this
item's own slug) with exactly these sections, in order:
- `## Reproduction` — concrete steps or evidence confirming
(or failing to confirm) the reported symptom
- `## Root-Cause Hypothesis` — the mechanism you believe
causes it, with file/line references
- `## Verdict` — exactly one of `verified` or `rejected`
- `## Rationale` — why you reached that verdict
4. Commit and push the verification artifact on this branch.
DELIVERING THE VERDICT — read carefully.
This node's declared output is the literal key `verdict`. The CP
reads your packed `verdict` value and PATCHes this work item's own
`flow_state` with it (`spec/typed-workflows.md` WF-COMP-25 / 25a,
`spec/workflow-variables.md` WV-36). You do NOT call the CP, you
do NOT run `cp-cli planner items update`, and you do NOT read any
internal-service CP credential file (the path that the legacy
`@1` flow used for its CP write is no longer mounted into your
container). The CP applies your verdict when `finalize_run` runs.
The closed verdict vocabulary is exactly two strings:
verified
rejected
Any other value — including an empty string, `VERIFIED`, `verified `,
`Verified`, `verify`, or a sentence — is rejected by WF-COMP-25a as
`self_transition_verdict_outside_set` and the run surfaces to a
human via `request_decision`. Do not invent a third outcome.
Write the verdict to your step folder with a quoted heredoc whose
terminator cannot occur in the body — example for verdict
`verified`:
cat > /variables/agent/verdict <<'__VERDICT_END__'
verified
__VERDICT_END__
The file MUST be strict UTF-8 with LF line endings; no trailing
whitespace; no header line; no body. A file that is not exactly the
one-line verdict (with optional final LF) is rejected as
`self_transition_verdict_outside_set` and surfaces to a human.
Do NOT use `wfvar set verdict <body>` — it passes the body as argv
and breaks on shell quoting.
Workflow:
1. Investigate.
2. Decide `verified` or `rejected`. Record it in
`## Verdict` of the verification artifact AND in
`/variables/agent/verdict` — the two MUST agree.
3. Commit and push the verification artifact.
4. Call task_complete. Do NOT PATCH the CP yourself.