sync: agent-ops from agentic-framework v1.1.131

agent-ops/.version

@@ -1 +1 @@
-1.1.129
+1.1.131

agent-ops/skills/common/code-review/SKILL.md

@@ -94,11 +94,11 @@ 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`: 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.
+- `local`: first-pass and review-detectable work, including multi-file or API/call-site reviews when scope and required context are 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 alone as an implicit cloud route; context volume is separate lane evidence.
 - Repair non-behavioral review artifact drift during review instead of failing solely for it when implementation correctness, tests, and contracts remain judgeable.
-- `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.
+- `cloud`: reviews requiring stronger-than-local judgment, larger-than-local context, or evidence recovery: weak verification that review cannot compensate for, security/auth, storage/migration, concurrency, protocol/schema, broad 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, 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.
 
 Directory states:
 
@@ -237,7 +237,7 @@ If the user-review gate does not trigger, write new routed plan/review files usi
 - Header tag is `REVIEW_<PARENT_TAG>`.
 - If the selected task group is `m-<milestone-slug>`, write the follow-up plan/review under the same `m-<milestone-slug>` 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 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.
+- 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, evidence, or context-volume 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:
@@ -245,6 +245,7 @@ If the user-review gate does not trigger, write new routed plan/review files usi
   - 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 the follow-up requires more source/test/diff/log context than local can hold without dropping material evidence, or the failure spans broad cross-module/cross-domain context that cannot be safely split, 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.

agent-ops/skills/common/plan/SKILL.md

@@ -96,11 +96,11 @@ 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 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.
+- `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` when risk can be contained by explicit planning, focused code review, deterministic tests, split subtasks, and bounded required context.
+- Use `cloud-GNN` when the task needs stronger reasoning, larger-than-local context, 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, verification trust failures, or required source/test/call-site/log/review context that local cannot hold without omitting material evidence.
+- 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` for review-detectable work with bounded scope, bounded context, and rerunnable verification, and choose `cloud` for reviews requiring frontier-level judgment, larger-than-local context, weak tests, security/auth, storage/migration, concurrency, protocol/schema, cross-domain behavior, repeated Required issues, or untrusted verification evidence.
 - Treat non-behavioral review artifact drift as reviewer-repairable unless it prevents judging implementation correctness, tests, or contracts.
 - Raise `GNN` with scope, ambiguity, missing tests, irreversible behavior, and blast radius after lane selection; keep grade model-independent.
 
@@ -189,11 +189,13 @@ Complete all items below before creating active plan/review files. Work through
 
 GXX is an output of analysis, not an input. Determine lane and grade only after Step 2 is fully complete.
 
-- [ ] **Assess change scope** — count affected files, interface impact, and call-site count.
+- [ ] **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: concurrency, storage/migration, protocol/schema, auth, 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 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 `local` when the task can be made explicit, deterministic, and review-detectable; when affected files, call sites, and required context are bounded; when tests or focused smoke checks can be rerun locally; or when split subtasks can contain risk.
+  - 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 security/auth, storage/migration, concurrency, or protocol/schema risk has hard-to-review failure modes.