From 97ccb3bfb3ff86d55539daaae6246586c1f2aee5 Mon Sep 17 00:00:00 2001 From: toki Date: Tue, 2 Jun 2026 21:49:44 +0900 Subject: [PATCH] sync: agent-ops from agentic-framework v1.1.122 --- agent-ops/.version | 2 +- agent-ops/skills/common/code-review/SKILL.md | 21 ++++++------ agent-ops/skills/common/plan/SKILL.md | 36 ++++++++++---------- 3 files changed, 30 insertions(+), 29 deletions(-) diff --git a/agent-ops/.version b/agent-ops/.version index 51f88d3c..b176d896 100644 --- a/agent-ops/.version +++ b/agent-ops/.version @@ -1 +1 @@ -1.1.119 +1.1.122 diff --git a/agent-ops/skills/common/code-review/SKILL.md b/agent-ops/skills/common/code-review/SKILL.md index fdaa668e..f97d84f8 100644 --- a/agent-ops/skills/common/code-review/SKILL.md +++ b/agent-ops/skills/common/code-review/SKILL.md @@ -91,10 +91,11 @@ Milestone task group contract: Review routing rules: -- `local`: narrow, low-risk, or first-pass review where tests and scope are clear. -- `cloud`: multi-file, API/call-site impact, meaningful test judgment, plan deviation, weak verification, security/auth, storage/migration, concurrency, protocol/schema, cross-domain, or repeated Required issues. -- `cloud-G07` or higher is mandatory for terminal-agent follow-up work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks. Merely running deterministic tests such as `go test` does not make a task terminal-agent work. -- `cloud-G07` or higher is mandatory for follow-up plans when a local implementation failed a real bin/smoke/integration command after unit tests passed, when the success condition depends on an interactive TUI/PTY/browser/external CLI or screen repaint/cursor stream, or when verification trust is Fail because recorded stdout/stderr does not match a rerun. +- Route reviews so a normal mixed backlog can use both lanes substantially. This is not a per-review quota; neither `local` nor `cloud` is the default catch-all. +- `local`: first-pass and review-detectable work, including multi-file or API/call-site reviews when scope is bounded and verification can be rerun or reasoned about locally. +- `local-G01` through `local-G10` and `cloud-G01` through `cloud-G10` are valid. Do not treat high grade as an implicit cloud route; grade is scoped within the selected lane. +- `cloud`: reviews requiring stronger-than-local judgment or evidence recovery: weak verification that review cannot compensate for, security/auth, storage/migration, concurrency, protocol/schema, cross-domain behavior with hard-to-review failure modes, repeated non-trivial Required issues, or untrusted verification evidence. +- `cloud-G07` or higher is mandatory only when terminal-agent or external interactive behavior is central and cannot be made deterministic for local review: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, terminal benchmark-style tasks, real bin/smoke/integration failures after unit tests passed, TUI/PTY/browser/screen repaint/cursor stream behavior, or rerun-mismatched verification trust failures. Directory states: @@ -233,15 +234,15 @@ If the user-review gate does not trigger, write new routed plan/review files usi - Header tag is `REVIEW_`. - If the selected task group is `m-`, write the follow-up plan/review under the same `m-` task group. - Base the follow-up scope directly on the archived review findings. Keep it narrow and actionable. -- Choose lane/grade again; preserve the prior route only when it was adequate, otherwise raise `GNN` and/or move `local -> cloud`. +- Choose lane/grade again; preserve the prior route when it was adequate. Raise `local-GNN` for explicit, deterministic, review-detectable follow-ups, but move `local -> cloud` when the failure exposes reasoning, risk, or evidence gaps that local review should not own. - If the finding is only missing or untrusted verification evidence that an appropriate follow-up lane can produce by rerunning commands or collecting artifacts, do not write `USER_REVIEW.md` solely for that reason. Write a follow-up plan that reruns the exact commands in an appropriate lane and records actual stdout/stderr. - If follow-up verification involves mobile/UI hangs, timeouts, or no progress for 2 minutes, stop blind retries; require focused rerun output plus screenshot/window/UI-tree evidence path, or the exact reason capture is impossible. - Before choosing the follow-up route, apply this escalation gate: - - If the archived plan was `local-*` and the verdict is `FAIL` for correctness, completeness, test coverage, or verification trust, move the follow-up build lane to `cloud` unless the issue is trivially deterministic and review-detectable without live environment behavior. - - If the follow-up work is terminal-agent work (shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks), use `cloud-G07` or higher. - - If unit tests passed but a real bin/smoke/integration command failed, use `cloud-G07` or higher. - - If the task depends on interactive TUI/PTY/browser/external CLI behavior, screen repaint/cursor stream parsing, or live command-palette state, use `cloud-G07` or higher. - - If verification evidence is missing, reconstructed, stale, untrusted, or mismatched on rerun, use `cloud-G07` or higher and make verification trust recovery a plan item. + - If the archived plan was `local-*` and the verdict is `FAIL` for correctness, completeness, test coverage, or verification trust, keep the follow-up on `local` with a higher grade when the issue is explicit, deterministic, and review-detectable; move to `cloud` only when the failure shows local capability or evidence trust is likely insufficient. + - If the follow-up work is terminal-agent work that cannot be reduced to deterministic commands and evidence, use `cloud-G07` or higher. + - If unit tests passed but a real bin/smoke/integration command failed and local follow-up cannot isolate the failure with deterministic evidence, use `cloud-G07` or higher. + - If the task depends on interactive TUI/PTY/browser/external CLI behavior, screen repaint/cursor stream parsing, or live command-palette state that cannot be captured deterministically, use `cloud-G07` or higher. + - If verification evidence is missing, reconstructed, stale, untrusted, or mismatched on rerun, use a local follow-up only when exact commands and actual stdout/stderr capture are enough; use `cloud-G07` or higher when evidence trust recovery needs stronger diagnosis. - `FAIL`: one plan item per Required issue. - `WARN`: one grouped plan item for Suggested issues, plus related Nit issues if useful. - Each plan item needs problem, solution with before/after when non-trivial, checklist, test decision, intermediate verification. diff --git a/agent-ops/skills/common/plan/SKILL.md b/agent-ops/skills/common/plan/SKILL.md index be26d0e2..c59ba293 100644 --- a/agent-ops/skills/common/plan/SKILL.md +++ b/agent-ops/skills/common/plan/SKILL.md @@ -94,14 +94,13 @@ Task directory naming rules: Routing rules: -- Build defaults to `local` when the plan is explicit, tests are runnable, and failure is review-detectable. -- Use `cloud` for weak tests, broad API/call-site impact, ambiguity, storage/concurrency/protocol/auth risk, or prior local failure. -- Use `cloud-G07` or higher for terminal-agent work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks. Merely running deterministic tests such as `go test` does not make a task terminal-agent work. -- Use `cloud-G07` or higher when acceptance depends on a real interactive external tool, TUI, PTY, browser, screen repaint/cursor stream, or bin-level smoke output. This is mandatory when unit tests pass but the real smoke/integration command fails. -- Use `cloud-G07` or higher when a prior review found missing, untrusted, reconstructed, or rerun-mismatched verification evidence. -- Keep high-risk design judgment on `cloud` with a higher grade; the runtime may map `cloud-GNN` to frontier-class models. -- Review may be `local` for narrow/low-risk checks and `cloud` for multi-file/API/test-meaning reviews, security/auth, storage/migration, concurrency, protocol/schema, cross-domain, or repeated Required issues. -- Raise `GNN` with scope, ambiguity, missing tests, irreversible behavior, and blast radius; keep grade model-independent. +- Build routing should be calibrated so a normal mixed backlog can use both lanes substantially. This is not a per-task quota: choose from the task's evidence, but do not let either lane become the default catch-all. +- `local-G01` through `local-G10` and `cloud-G01` through `cloud-G10` are valid. Do not treat `G06+` or high complexity as an implicit `cloud` threshold; grade is scoped within the chosen lane. +- Use a higher `local-GNN` when risk can be contained by explicit planning, focused code review, deterministic tests, or split subtasks. +- Use `cloud-GNN` when the task needs stronger reasoning or evidence recovery than local should be expected to provide: unclear external behavior, weak or missing verification for user-visible behavior, high-risk architecture judgment, security/auth/storage/concurrency/protocol changes with hard-to-review failure modes, repeated local failure, or verification trust failures. +- Use `cloud-G07` or higher only when terminal-agent or external interactive behavior is central and cannot be made deterministic for local handling: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, terminal benchmark-style tasks, TUI/PTY/browser/screen repaint/cursor stream behavior, or real bin/smoke/integration failures after unit tests passed. +- Review uses the same balance: choose `local` for review-detectable work with bounded scope and rerunnable verification, and choose `cloud` for reviews requiring frontier-level judgment across weak tests, security/auth, storage/migration, concurrency, protocol/schema, cross-domain behavior, repeated Required issues, or untrusted verification evidence. +- Raise `GNN` with scope, ambiguity, missing tests, irreversible behavior, and blast radius after lane selection; keep grade model-independent. Directory states: @@ -190,16 +189,17 @@ GXX is an output of analysis, not an input. Determine lane and grade only after - [ ] **Assess change scope** — count affected files, interface impact, and call-site count. - [ ] **Check risk factors** — mark any that apply: concurrency, storage/migration, protocol/schema, auth, irreversible behavior. - [ ] **Evaluate test confidence** — judge whether existing tests sufficiently verify the changed behavior. -- [ ] **Decide lane** — use `local` if the plan is explicit and tests are sufficient; use `cloud` if any of the following apply: - - Tests are weak or do not cover the changed behavior - - Broad API/call-site impact - - Concurrency, storage, protocol, or auth risk - - Prior local build failure on this task - - Terminal-agent work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks - - Real bin/smoke/integration verification failed after unit tests passed - - Interactive TUI/PTY/browser/external CLI automation or screen-rendered output is part of the success condition - - A prior review marked verification trust Fail/Warn because recorded command output did not match a rerun -- [ ] **Decide GNN** — assign a higher grade as scope, ambiguity, irreversibility, and blast radius increase. Grade is complexity-based, not model-name-based. +- [ ] **Decide lane** — choose between `local` and `cloud` after weighing both sets of signals. Across a normal mixed backlog, both lanes should appear regularly; do not force a quota for one task, and do not let either lane become the catch-all. + - Prefer `local` when the task can be made explicit, deterministic, and review-detectable; when affected files and call sites are bounded; when tests or focused smoke checks can be rerun locally; or when split subtasks can contain risk. + - Prefer `cloud` when required behavior depends on unclear external systems or user-visible behavior that cannot be verified deterministically. + - Prefer `cloud` when verification is weak or missing in a way that review cannot reliably detect. + - Prefer `cloud` when security/auth, storage/migration, concurrency, or protocol/schema risk has hard-to-review failure modes. + - Prefer `cloud` when prior local attempts failed for non-trivial reasoning or evidence-trust reasons. + - Prefer `cloud` when terminal-agent work is central: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks. + - Prefer `cloud` when real bin/smoke/integration verification failed after unit tests passed. + - Prefer `cloud` when interactive TUI/PTY/browser/external CLI automation or screen-rendered output is part of the success condition and cannot be reduced to deterministic evidence. + - Prefer `cloud` when a prior review marked verification trust Fail/Warn because recorded command output did not match a rerun. +- [ ] **Decide GNN** — assign a higher grade within the selected lane as scope, ambiguity, irreversibility, and blast radius increase. Grade is complexity-based, not model-name-based; both `local-G10` and `cloud-G01` are valid when the lane evidence supports them. ## Step 4 - Archive Existing Active Files