opencode-froggy 1.1.1 → 1.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/agent/build-orchestrator.md +5 -4
- package/agent/code-reviewer.md +21 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -146,7 +146,7 @@ A primary agent that delivers a development request end-to-end through coordinat
|
|
|
146
146
|
1. **Decompose** — split the request into tasks of kind `implementation`, `research`, or `verification`, with disjoint file scopes for parallel implementation tasks (overlapping scopes are serialized through dependencies), each rated `complex` or `normal`, forming a dependency DAG. Exploration can go to `explore`, hard planning to `architect`.
|
|
147
147
|
2. **Worktrees and snapshots** — verify the repo is clean, then capture the base branch and its commit. Each implementation task gets its own worktree and branch (per the environment's conventions), created only once all its prerequisites are validated, starting from the base commit plus its validated implementation ancestors merged in topological order (single ancestor: fast-path from its commit; transitive ancestors count even through research tasks). Verification tasks run in their own worktree at that same prepared snapshot and report the verified SHA and results. Research findings are passed in the prompt instead of merged. Comparison candidates share the same snapshot.
|
|
148
148
|
3. **Dispatch** — after the user approves the decomposition, spawn a `general` sub-agent per ready task in the background, with the model picked from the pool matching its complexity. Sub-agents work inside their worktree (they move their session there so all their work stays isolated); the complete delivery commit is produced during the quality gate, after simplification. Comparison tasks run the same task on every model of the pool in parallel.
|
|
149
|
-
4. **Quality gate** — on each implementation delivery, `code-reviewer` reviews all working-tree states; blocking issues go back by resuming the implementer's session (full context kept), optionally under a different model — escalate when stuck, downgrade when slow or costly. The implementer then commits exactly what was reviewed; the task is validated when build/tests pass at that exact commit in a clean worktree, recording its `validated_commit` SHA. Max 2 rework rounds; a failed task transitively fails its pending dependents while independent tasks continue.
|
|
149
|
+
4. **Quality gate** — on each implementation delivery, `code-reviewer` reviews all working-tree states; blocking issues go back by resuming the implementer's session (full context kept), optionally under a different model — escalate when stuck, downgrade when slow or costly. The implementer then commits exactly what was reviewed; the task is validated when build/tests pass at that exact commit in a clean worktree, recording its `validated_commit` SHA. Max 2 rework rounds; a failed task transitively fails its pending dependents while independent tasks continue. Comparison tasks are reviewed by a single `code-reviewer` session across all candidates, which ends with a comparative verdict; recommended parts of discarded candidates are adopted by resuming the winner's implementer for one rework round, then re-gated.
|
|
150
150
|
5. **Integration and simplification** — once **all** tasks are delivered, merge the `validated_commit` SHAs into the base branch in one topologically ordered pass, cleaning up after each integrated task (worktree, merged branch, temporary artifacts no longer needed). A conflicting merge is aborted in the base checkout first, then delegated: the implementer merges the current integration commit in its worktree, commits the resolution, re-passes the quality gate, and a replacement SHA is recorded before retrying. Dependent revalidation is bounded to one cascade. Never forced, never leaving an unfinished merge behind. After the final merge, a single `code-simplifier` pass refines the integrated changes, its edits get a focused review, build/tests re-run, and the result is committed. Then remove remaining worktrees (research, verification, failed, excluded) and stray temporary artifacts, and report a per-task summary.
|
|
151
151
|
|
|
152
152
|
#### Model configuration
|
|
@@ -40,7 +40,7 @@ normal: provider/model-c
|
|
|
40
40
|
- `objective`: what to build, find, or verify, with acceptance criteria
|
|
41
41
|
- `scope`: files or directories it may touch (empty for research and verification)
|
|
42
42
|
- `complexity`: `complex` or `normal`
|
|
43
|
-
- `compare`: optional, `true` to run the task on every model of the pool and keep the best delivery
|
|
43
|
+
- `compare`: optional, `true` to run the task on every model of the pool and keep the best delivery, possibly with parts adopted from the others
|
|
44
44
|
- `depends_on`: ids of tasks that must be validated before this one starts
|
|
45
45
|
3. **Isolation rule:** implementation tasks running in parallel must have disjoint scopes; overlapping scopes are serialized through `depends_on`. Research and verification tasks touch no code but still wait for their prerequisites.
|
|
46
46
|
4. If the request is ambiguous, ask the user before decomposing. Then present the plan (tasks, kinds, models, parallel groups) and get the user's approval before launching any task sub-agent. Read-only preparatory sub-agents (`explore`, `architect`) may run before approval — they build the plan, not code.
|
|
@@ -73,12 +73,13 @@ normal: provider/model-c
|
|
|
73
73
|
|
|
74
74
|
Research and verification reports are assessed directly against their acceptance criteria.
|
|
75
75
|
|
|
76
|
-
1. **Review:** a `code-reviewer` sub-agent reviews the delivered code in the worktree — committed, staged, unstaged, and untracked alike.
|
|
76
|
+
1. **Review:** a `code-reviewer` sub-agent reviews the delivered code in the worktree — committed, staged, unstaged, and untracked alike. Comparison tasks use a single `code-reviewer` session for every candidate, in pool order — resume that session for each candidate and each rework round, so all candidates are judged against one baseline.
|
|
77
77
|
2. **Rework loop:** blocking issues go back to the session that produced the delivery (resume it, full context kept), optionally under a different model — escalate when stuck, downgrade when slow or costly. Each round repeats review until no blocking issues remain.
|
|
78
78
|
3. **Commit:** the implementer commits the complete delivery — exactly what was reviewed; any further change goes through the rework loop.
|
|
79
79
|
4. **Validation:** build and tests pass at that commit and the worktree is clean → record the commit SHA as the task's `validated_commit`.
|
|
80
|
-
5. **Comparison tasks:** once every candidate passed the gate (or after one review round),
|
|
81
|
-
6. **
|
|
80
|
+
5. **Comparison tasks:** once every candidate passed the gate (or after one review round), the same reviewer session delivers a comparative verdict — each candidate against each acceptance criterion, a recommended winner, and optional partial-adoption suggestions (parts of a discarded candidate worth keeping). Keep discarded candidates' worktrees and branches until the winner is fully validated, then discard them.
|
|
81
|
+
6. **Hybrid adoption:** when the verdict recommends adopting parts of a discarded candidate, resume the winning candidate's implementer session (full context kept) with the adoption instructions and a pointer to the discarded branch to borrow from. The reworked delivery re-passes the full gate — review by the same reviewer session, build, tests — before its commit is recorded as the `validated_commit`. At most one adoption round, then fall back to the winning candidate as delivered.
|
|
82
|
+
7. **Limits:** at most 2 rework rounds per task, then `failed`: remove its worktree, keep its branch for possible later recovery. When a task fails, transitively mark its pending dependents `failed` (recording the failing prerequisite) and continue independent tasks so the final barrier stays reachable.
|
|
82
83
|
|
|
83
84
|
## Phase 5 — Final integration and simplification
|
|
84
85
|
|
package/agent/code-reviewer.md
CHANGED
|
@@ -26,6 +26,27 @@ permissions:
|
|
|
26
26
|
- action: shell
|
|
27
27
|
resource: "git rev-parse*"
|
|
28
28
|
effect: allow
|
|
29
|
+
- action: shell
|
|
30
|
+
resource: "git remote -v"
|
|
31
|
+
effect: allow
|
|
32
|
+
- action: shell
|
|
33
|
+
resource: "printf*"
|
|
34
|
+
effect: allow
|
|
35
|
+
- action: shell
|
|
36
|
+
resource: "gh pr view*"
|
|
37
|
+
effect: allow
|
|
38
|
+
- action: shell
|
|
39
|
+
resource: "gh pr diff*"
|
|
40
|
+
effect: allow
|
|
41
|
+
- action: shell
|
|
42
|
+
resource: "gh api repos/*"
|
|
43
|
+
effect: allow
|
|
44
|
+
- action: shell
|
|
45
|
+
resource: "gh api repos/* --method*"
|
|
46
|
+
effect: deny
|
|
47
|
+
- action: shell
|
|
48
|
+
resource: "gh api repos/* -X*"
|
|
49
|
+
effect: deny
|
|
29
50
|
---
|
|
30
51
|
|
|
31
52
|
# Code Review Agent
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "opencode-froggy",
|
|
3
|
-
"version": "1.1.
|
|
3
|
+
"version": "1.1.3",
|
|
4
4
|
"description": "OpenCode plugin with a hook layer (tool.before.*, session.idle...), agents (code-reviewer, doc-writer), and commands (/review-pr, /commit)",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"types": "dist/index.d.ts",
|