sync: agent-ops from agentic-framework v1.1.124
This commit is contained in:
parent
4df9cc8872
commit
a2c9fe7c51
3 changed files with 9 additions and 7 deletions
|
|
@ -1 +1 @@
|
|||
1.1.122
|
||||
1.1.124
|
||||
|
|
|
|||
|
|
@ -94,6 +94,7 @@ 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.
|
||||
- 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.
|
||||
|
||||
|
|
@ -101,7 +102,7 @@ Directory states:
|
|||
|
||||
| State | Meaning |
|
||||
|-------|---------|
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub or placeholders | Implementation is pending/incomplete; review should fail completeness if invoked |
|
||||
| `PLAN-*-G??.md` + unfilled `CODE_REVIEW-*-G??.md` stub/placeholders | Implementation is not judgeable; review should fail completeness if invoked |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with filled `사용자 리뷰 요청` | Implementation claims a user-only blocker; review validates the request and writes `USER_REVIEW.md` only if justified |
|
||||
| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` | Ready for code-review skill |
|
||||
| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), before final task-directory archive move |
|
||||
|
|
@ -149,10 +150,10 @@ The diff is the starting point, not the boundary. Follow behavior and API connec
|
|||
Before writing the verdict:
|
||||
|
||||
- Compare actual source files against every planned checklist item.
|
||||
- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`; item text/order must match.
|
||||
- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`; repair non-behavioral drift when implementation remains judgeable.
|
||||
- If a checklist item contains integrated verification for a feature, treat that feature item as incomplete until both implementation evidence and the matching verification output are present. Do not accept a separate unchecked completion-criteria item as a substitute.
|
||||
- Confirm the implementation marked the matching checklist items in the active review file, including the final mandatory `CODE_REVIEW-*-G??.md` completion item.
|
||||
- Treat blank placeholder sections, missing actual implementation notes, missing checklist completion, or missing actual stdout/stderr in the active review file as a completeness or verification-trust failure. This alone does not trigger `USER_REVIEW.md`; route it to a normal follow-up plan unless there is separate user-only blocker evidence.
|
||||
- Confirm the implementation marked the matching checklist items in the active review file, including the final mandatory `CODE_REVIEW-*-G??.md` completion item; repair clear artifact drift when evidence supports completion.
|
||||
- Treat review artifact gaps as failures only when they prevent judging implementation correctness, tests, contracts, or verification trust.
|
||||
- Read the `사용자 리뷰 요청` section. If `상태` is not `없음`, validate the exact decision needed, blocker evidence, command output or not-run reason, why automatic follow-up cannot resolve it, and resume condition before deciding whether the user-review gate triggers.
|
||||
- Grep renamed/removed symbols for stale references.
|
||||
- Confirm every required test exists, name matches, and assertions are meaningful.
|
||||
|
|
@ -182,7 +183,7 @@ Severity semantics:
|
|||
|
||||
Issue severity:
|
||||
|
||||
- `Required`: correctness, API contract, missing required test, missing verification that was integrated into a feature item, plan-completeness issue, or incomplete/placeholder `CODE_REVIEW-*-G??.md` content required from the implementing agent.
|
||||
- `Required`: correctness, API contract, missing required test, missing integrated verification, plan-completeness issue, or review artifact gaps that prevent judging implementation quality.
|
||||
- `Suggested`: useful improvement that should enter the loop but does not block correctness.
|
||||
- `Nit`: tiny cleanup; may be recorded without forcing WARN.
|
||||
|
||||
|
|
@ -414,7 +415,7 @@ Report Required/Suggested counts, archive names, the final task archive path for
|
|||
| Dimension | Check |
|
||||
|-----------|-------|
|
||||
| Correctness | Logic, edge cases, concurrency, errors |
|
||||
| Completeness | All planned checklist items done, including integrated implementation+verification feature items and matching plan/review `구현 체크리스트` completion |
|
||||
| Completeness | Planned implementation/verification items are done; review artifact drift is repaired when judgeable |
|
||||
| Test coverage | Required tests present and meaningful |
|
||||
| API contract | Call sites, compatibility, docs |
|
||||
| Code quality | No debug prints, dead code, leftover TODOs |
|
||||
|
|
|
|||
|
|
@ -100,6 +100,7 @@ Routing rules:
|
|||
- 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.
|
||||
- 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.
|
||||
|
||||
Directory states:
|
||||
|
|
|
|||
Loading…
Reference in a new issue