From 1a91f4995f514e48901a48ec099b143c2158c7a7 Mon Sep 17 00:00:00 2001 From: toki Date: Wed, 17 Jun 2026 23:21:08 +0900 Subject: [PATCH] sync: agent-ops from agentic-framework v1.1.149 --- agent-ops/.version | 2 +- agent-ops/skills/common/code-review/SKILL.md | 15 ++++++------ agent-ops/skills/common/plan/SKILL.md | 25 ++++++-------------- 3 files changed, 16 insertions(+), 26 deletions(-) diff --git a/agent-ops/.version b/agent-ops/.version index 683ec8c..4f706ff 100644 --- a/agent-ops/.version +++ b/agent-ops/.version @@ -1 +1 @@ -1.1.148 +1.1.149 diff --git a/agent-ops/skills/common/code-review/SKILL.md b/agent-ops/skills/common/code-review/SKILL.md index 9851b47..c135920 100644 --- a/agent-ops/skills/common/code-review/SKILL.md +++ b/agent-ops/skills/common/code-review/SKILL.md @@ -89,12 +89,13 @@ Milestone task group contract: Review routing rules: -- 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`: review-detectable work where edited files, direct call sites, and rerunnable tests are enough to judge correctness. -- `local-G01` through `local-G10` and `cloud-G01` through `cloud-G10` are valid. Do not treat high grade alone as an implicit cloud route; context volume is separate lane evidence. +- Prefer `local` whenever the scope is bounded and verifiable; high local usage is fine. Do not choose `cloud` just to balance lane usage. +- `local` is for bounded, explicit, locally verifiable review: required behavior is explicit in the plan or existing pattern; relevant context fits in edited files plus nearby types/helpers, direct call sites, and existing or planned targeted tests/fixtures; correctness can be checked by code inspection plus type/build/unit tests or deterministic commands; no open-ended product/design judgment, live external provider/runtime semantics, broad cross-domain context, or evidence-trust diagnosis is decisive. +- `cloud` is required when any local condition is false, including when correctness depends on behavior promised outside the bounded context, wider context, or evidence-trust diagnosis. Repeated Required issues are evidence only when they show a local condition is false. +- `local-G01` through `local-G10` and `cloud-G01` through `cloud-G10` are valid. Lane is capability fit; grade is complexity within the chosen lane. Do not raise `local-GNN` to compensate for missing judgment, missing context, weak verification, or a previous loop failure. - Repair non-behavioral review artifact drift during review instead of failing solely for it when implementation correctness, tests, and contracts remain judgeable. -- `cloud`: reviews where a wrong but plausible implementation could pass local tests because correctness depends on behavior promised outside the edited files, wider context, repeated Required issues, or evidence trust. - `cloud-G07` or higher is mandatory only when terminal-agent or external interactive behavior is central and cannot be made deterministic for local review, or when the review requires more source/test/diff/log context than local can hold without omitting material evidence: 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, rerun-mismatched verification trust failures, or very large cross-module/cross-domain changes that cannot be safely split for review. +- Previous loop lane does not matter. Recompute lane from the current review or follow-up scope using these rules. Directory states: @@ -236,13 +237,13 @@ 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 still adequate. Raise `local-GNN` for explicit, deterministic, review-detectable follow-ups, but move `local -> cloud` when edited files, direct call sites, and tests were not enough. +- Choose lane/grade again from the current follow-up scope using Review routing rules. Ignore the prior lane and do not increment GNN solely because the previous loop failed. - 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. - Write an `Archive Evidence Snapshot` section in every WARN/FAIL follow-up plan. Copy enough prior-loop evidence from the archived plan/review logs for the next implementer to act without rereading archive by default: current archived plan/review log paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap/spec carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not instruct the implementer to search `agent-task/archive/**` broadly. - Copy the follow-up plan's `Archive Evidence Snapshot` section exactly into the follow-up review stub. -- 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, keep the follow-up on `local` only when the fix is visible from edited files, direct call sites, and rerunnable tests; otherwise move to `cloud`. +- Before choosing the follow-up route, apply this gate: + - Keep the follow-up on `local` when all local allowlist conditions are true for the current fix; otherwise use `cloud`. - 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. diff --git a/agent-ops/skills/common/plan/SKILL.md b/agent-ops/skills/common/plan/SKILL.md index 8ea6517..c32895f 100644 --- a/agent-ops/skills/common/plan/SKILL.md +++ b/agent-ops/skills/common/plan/SKILL.md @@ -95,12 +95,12 @@ Task directory naming rules: Routing rules: -- 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 alone as an implicit `cloud` threshold; context volume is separate lane evidence. -- Use a higher `local-GNN` only when the edited files, direct call sites, and rerunnable tests are enough to judge correctness. -- Use `cloud-GNN` when correctness depends on behavior promised outside the edited files, especially when a plausible but wrong test could still pass. +- Prefer `local` whenever the scope is bounded and verifiable; high local usage is fine. Do not choose `cloud` just to balance lane usage. +- `local` is for bounded, explicit, locally verifiable work: required behavior is explicit in task evidence, contracts, or existing pattern; relevant context fits in edited files plus nearby types/helpers, direct call sites, and existing or planned targeted tests/fixtures; correctness can be checked by code inspection plus type/build/unit tests or deterministic commands; no open-ended product/design judgment, live external provider/runtime semantics, or broad cross-domain context is decisive. +- Use `cloud` when any local condition is false, including when a plausible but wrong implementation could pass local checks while breaking behavior promised outside the bounded context. +- `local-G01` through `local-G10` and `cloud-G01` through `cloud-G10` are valid. Lane is capability fit; grade is complexity within the chosen lane. Do not raise `local-GNN` to compensate for missing judgment, missing context, weak verification, or a previous loop failure. - Use `cloud-G07` or higher only when terminal-agent or external interactive behavior is central and cannot be made deterministic for local handling, or when the task requires more source/test/diff/log context than local can hold without omitting material evidence: 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, real bin/smoke/integration failures after unit tests passed, or very large cross-module/cross-domain changes that cannot be safely split. -- Review uses the same balance: choose `local` when edited files, direct call sites, and tests are enough to judge correctness, and choose `cloud` when behavior promised outside edited files, wider context, repeated Required issues, or verification trust decide correctness. +- Previous loop lane does not matter. Recompute lane from the current plan or follow-up scope using these rules. - Treat non-behavioral review artifact drift as reviewer-repairable unless it prevents judging implementation correctness, tests, or contracts. - Treat obvious non-behavioral source nits as reviewer-repairable too: typos, stale comments, docs, or formatting only, with no behavior/test/API contract change. - Raise `GNN` with scope, ambiguity, missing tests, irreversible behavior, and blast radius after lane selection; keep grade model-independent. @@ -196,19 +196,8 @@ GXX is an output of analysis, not an input. Determine lane and grade only after - [ ] **Assess change scope** — count affected files, interface impact, call-site count, and the amount of source/test/review context that must stay loaded together. - [ ] **Check risk factors** — mark any that apply: behavior promised outside edited files, persisted-state rule, permission boundary, shared-state risk, irreversible behavior. - [ ] **Evaluate test confidence** — judge whether existing tests sufficiently verify the changed behavior. -- [ ] **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 a wrong implementation would be visible from the edited files, direct call sites, and rerunnable tests. - - Prefer `cloud` when the task is too large for local context to hold the required source files, tests, call-site graph, generated artifacts, logs, or review evidence without omitting material context. - - Prefer `cloud` when split subtasks still require broad cross-module or cross-domain context to be understood safely, even if each edit could be applied locally. - - 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 a wrong but plausible implementation could satisfy local tests while breaking behavior promised outside the edited files. - - 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. +- [ ] **Decide lane** — apply `Routing rules` as a gate. Use `local` only when all local allowlist conditions are true; otherwise use `cloud`. Ignore previous loop lane. +- [ ] **Decide GNN** — assign 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 lane evidence supports them. Do not increment GNN solely because a previous loop failed. ## Step 4 - Archive Existing Active Files