@sorenllm/opencode-forge 0.2.1 → 0.2.2

package/README.md

@@ -8,7 +8,8 @@ OpenSpec spec workflows remain a third, separate lane.
 
 ```
 /plan fix login timeout   → read-only recon → plan_write (draft, writes denied)
-                           → present → plan_approve (user dialog = approval gate)
+                           → present, end turn → USER REVIEW (revise / discard / go-ahead)
+                           → plan_approve (user dialog = final gate) on explicit go-ahead
                            → execute task by task, plan_tick on each (timestamped audit)
                            → all ticked → per-criterion self-check → plan_close
                              (user dialog = completion gate) → done

package/dist/index.js

@@ -13270,9 +13270,9 @@ var PLAN_COMMAND_TEMPLATE = [
   "",
   "Plans are short-horizon, single-task-goal documents (.opencode/plan/<date>-<slug>.md). The harness enforces the hard parts (draft write-ban, approval/close dialogs); you supply the engineering judgment. Never edit or create plan files by hand — every change goes through the plan_* tools.",
   "",
-  "1. Reconnaissance (read-only): explore with read/grep/glob only — all write tools, bash, and subagents are DENIED while a draft exists; do not attempt them, do not ask the user to bypass. Gather concrete evidence with file:line references (verified findings, not guesses). If the goal is ambiguous on scope, behavior, or acceptance, ask the user 1-3 focused questions FIRST — do not plan against assumptions the user could settle in one line.",
+  "1. Reconnaissance and alignment (read-only): explore with read/grep/glob only — all write tools, bash, and subagents are DENIED while a draft exists; do not attempt them, do not ask the user to bypass. Gather concrete evidence with file:line references (verified findings, not guesses). If the goal is ambiguous or leaves meaningful choices open (scope, approach, acceptance), settle them with the user FIRST — 1-3 focused questions — and only write the draft once the shape is agreed; never plan against assumptions the user could settle in one line.",
   "2. Draft (plan_write): call plan_write with structured fields; the tool renders and validates the fixed sections, so a malformed plan cannot exist. Quality bar: goal = one line, the outcome not the activity; context = verified findings with file:line evidence, including what you ruled out and why; approach = the chosen approach AND at least one rejected alternative with the reason (a plan with no considered alternative is a guess); tasks = 3-8 concrete, independently verifiable steps, each doable in one sitting ('improve the code' is invalid; 'extract the timeout constant into config.ts and default it to 3000' is valid); risks = what could break, blast radius, rollback path; acceptance = criteria verifiable by a command, a file, or an observable behavior (vague criteria will fail the close); nonGoals = explicit out-of-scope items. To revise after feedback, call plan_write again — while in draft it overwrites the same file.",
-  "3. Approval (plan_approve): present briefly — goal, chosen approach with one line why, the numbered task list, the acceptance criteria — then call plan_approve. The user's confirmation in the dialog IS the approval; if they object, revise with plan_write and present again. Never implement before approval succeeds.",
+  `3. User review, then approval (plan_approve): after plan_write, present the plan in chat — goal, chosen approach with one line why, the numbered task list, the acceptance criteria — then STOP: end your turn and wait. The user owns the review, at their own pace: feedback → revise with plan_write, re-present, and wait again; rejection → /plan discard (or re-plan together); explicit go-ahead (e.g. "execute", "批准", "looks good") → call plan_approve — its confirmation dialog is the final hard gate, and the user's Allow starts execution. Never call plan_approve in the same turn that presents a draft, and never implement before approval succeeds.`,
   "4. Execution (tick as you go): work tasks in order; call plan_tick with the task number immediately after EACH task's work is actually done — never batch ticks, never tick ahead of reality (tick timestamps are an audit trail). If the plan turns out wrong mid-execution, do not silently improvise: tell the user what changed and either finish the affected task or ask about revising (/plan with the same goal re-enters planning).",
   "5. Completion (plan_close): when all tasks are ticked, self-check EVERY acceptance criterion with concrete evidence (file:line, command output, test result), then call plan_close with one check per criterion, pass/fail honest — a failing check refuses the close, and that is the design working, not an inconvenience. The user confirms closure in a dialog.",
   "",
@@ -13434,7 +13434,7 @@ async function gate(ask, permission, title) {
   await ask({ permission, patterns: ["*"], always: [], metadata: { title } });
 }
 var planApproveTool = tool({
-  description: "Ask the user to approve the session's draft plan (draft -> approved). The permission layer pins this call to a confirmation dialog — the user's Allow IS the approval. After approval the draft-phase write ban is lifted. Optionally pass a one-line summary of what changed since the last revision.",
+  description: "Approve the session's draft plan (draft -> approved). Call it ONLY after presenting the plan and receiving the user's explicit go-ahead in chat — never in the same turn that presents the draft. The permission layer pins this call to a confirmation dialog — the user's Allow is the final hard gate and lifts the draft-phase write ban. Optionally pass a one-line summary of what changed since the last revision.",
   args: {
     summary: tool.schema.string().optional().describe("One-line summary presented alongside the approval request")
   },
@@ -14135,7 +14135,7 @@ var server = async (input) => {
       if (active) {
         const p = progressOf(active.doc);
         const rel = relFrom(state.worktree, active.path);
-        const rule = active.doc.status === "draft" ? "while in draft, write operations are denied at the tool layer; present the summary then call plan_approve for approval, or /plan discard to abandon" : "call plan_tick immediately after each completed task; when all are done, self-check every acceptance criterion and call plan_close";
+        const rule = active.doc.status === "draft" ? "while in draft, write operations are denied at the tool layer; present the plan then end your turn to await the user's review — on feedback revise via plan_write and re-present; call plan_approve only after the user explicitly approves in chat (their confirmation dialog is the final gate); /plan discard to abandon" : "call plan_tick immediately after each completed task; when all are done, self-check every acceptance criterion and call plan_close";
         output.system.push(`[forge:plan-notice] This session is bound to a plan: ${rel} (status: ${active.doc.status}, ${p.done}/${p.total} tasks done). Rule: ${rule}. If the user has not mentioned this plan yet, relay its path and progress to them in one short line at the start of your reply.`);
       }
       if (forgeDisabled)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sorenllm/opencode-forge",
-  "version": "0.2.1",
+  "version": "0.2.2",
   "description": "Single general-purpose forge agent for opencode with two orthogonal harnesses: a plan harness (file-backed plans in .opencode/plan/, approve/close confirmation gates, tick discipline, hard write-ban while planning) and a goal harness (autonomous, host-verified objectives in .opencode/goal/ — idle continuation under turn/minute budgets, shell + file-contract checks re-run by the plugin at the completion gate, no-progress/transport/budget auto-pause, queueing).",
   "type": "module",
   "main": "./dist/index.js",