goalbuddy 0.3.5 → 0.3.7

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "goalbuddy",
-  "version": "0.3.5",
-  "description": "A /goal operating system for Codex and Claude Code: subgoals, parallel-agent-ready boards, dark mode, receipts, and verification.",
+  "version": "0.3.7",
+  "description": "A /goal operating loop for Codex and Claude Code: goal oracles, local boards, receipts, and verification.",
   "type": "module",
   "bin": {
     "goalbuddy": "internal/cli/goal-maker.mjs",
@@ -11,6 +11,7 @@
     ".agents/plugins/marketplace.json",
     "README.md",
     "RELEASE-0.3.5.md",
+    "RELEASE-0.3.7.md",
     "CONTRIBUTING.md",
     "examples",
     "plugins/goalbuddy",
@@ -19,7 +20,7 @@
     "goalbuddy/SKILL.md",
     "goalbuddy/agents",
     "goalbuddy/scripts",
-    "goalbuddy/extend",
+    "goalbuddy/surfaces",
     "goalbuddy/templates"
   ],
   "scripts": {
@@ -51,7 +52,6 @@
     "cli",
     "workflow",
     "agent",
-    "extensions",
     "verification"
   ],
   "author": "tolibear",

package/plugins/goalbuddy/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "goalbuddy",
-  "version": "0.3.5",
-  "description": "Turn broad Claude Code work into verified GoalBuddy boards with subgoals, parallel-agent-ready handoffs, dark mode, and receipts.",
+  "version": "0.3.7",
+  "description": "Turn broad Codex and Claude Code work into pressured /goal runs with oracles, local boards, receipts, and verification.",
   "author": {
     "name": "tolibear",
     "email": "support@tolibear.com",
@@ -18,7 +18,6 @@
     "goal",
     "task-board",
     "receipts",
-    "workflow",
-    "extensions"
+    "workflow"
   ]
 }

package/plugins/goalbuddy/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "goalbuddy",
-  "version": "0.3.5",
-  "description": "Turn broad Codex and Claude Code work into verified GoalBuddy boards with subgoals, parallel-agent-ready handoffs, dark mode, and receipts.",
+  "version": "0.3.7",
+  "description": "Turn broad Codex and Claude Code work into pressured /goal runs with oracles, local boards, receipts, and verification.",
   "author": {
     "name": "tolibear",
     "email": "support@tolibear.com",
@@ -18,14 +18,13 @@
     "goal",
     "task-board",
     "receipts",
-    "workflow",
-    "extensions"
+    "workflow"
   ],
   "skills": "./skills/",
   "interface": {
     "displayName": "GoalBuddy",
-    "shortDescription": "Verified goal boards with subgoals, parallel-agent-ready handoffs, and dark mode",
-    "longDescription": "GoalBuddy packages a structured goal workflow for broad, long-running, or ambiguous engineering work in Codex or Claude Code. It creates durable goal charters, task boards, optional depth-1 subgoals, visual board surfaces, parallel-agent-ready handoffs, receipts, verification gates, extension handoffs, and compatibility guidance for teams moving from goal-maker.",
+    "shortDescription": "Goal oracles, local boards, receipts, and proof loops for /goal",
+    "longDescription": "GoalBuddy packages a structured goal workflow for broad, long-running, or ambiguous engineering work in Codex or Claude Code. It creates durable goal charters, goal oracles, task boards, optional depth-1 subgoals, local board surfaces, parallel-agent-ready handoffs, receipts, verification gates, and compatibility guidance for teams moving from goal-maker.",
     "developerName": "tolibear",
     "category": "Coding",
     "capabilities": [

package/plugins/goalbuddy/README.md

@@ -1,8 +1,8 @@
 # GoalBuddy Plugin (Codex + Claude Code)
 
-GoalBuddy packages the canonical `goal-prep` skill as a plugin so teams can install the reusable workflow in **Codex** and **Claude Code**, while keeping the npm CLI for local setup, doctor checks, and extension management.
+GoalBuddy packages the canonical `goal-prep` skill as a plugin so teams can install the reusable workflow in **Codex** and **Claude Code**, while keeping the npm CLI for local setup, doctor checks, and the built-in local board surface.
 
-Version 0.3.5 is the Subgoals, Parallel Agents, and Dark Mode release: depth-1 child boards, a shared multi-board local hub, readable dark-mode boards, stricter agent contracts, deterministic prompt rendering, and conservative parallel planning for long-running work.
+Version 0.3.7 is the Goalmaxxed release: goal oracles, largest safe useful slices, built-in local boards, receipt pressure, final-proof gates, and a smaller core without the extension catalog.
 
 ## What It Contains
 
@@ -56,8 +56,9 @@ goalbuddy --target claude  # installs for Claude Code only
 For local CLI testing before npm publish:
 
 ```bash
-node internal/cli/goal-maker.mjs --catalog-url extend/catalog.json
+node internal/cli/goal-maker.mjs
 node internal/cli/goal-maker.mjs doctor
+node internal/cli/goal-maker.mjs board docs/goals/<slug> --once --json
 ```
 
 ## Release Notes

package/plugins/goalbuddy/agents/goal-judge.md

@@ -13,11 +13,16 @@ Hard contract:
 - Read only. Do not edit, stage, install, or implement.
 - Read state receipts before raw files. Then read only the inputs named in the Judge task.
 - Be skeptical of progress. Lots of files, docs, or tests are not completion.
-- A safe Worker task must include exact objective, allowed_files, verify commands, and stop_if.
+- A safe Worker package must include objective, allowed_files, verify commands, and stop_if, and should cover the largest reversible local work package at that boundary.
+- Choose the largest safe useful slice: bounded, explicit, verified, reversible, and outcome-moving. Safety does not mean tiny.
+- Judge a whole useful slice, not one helper at a time.
+- Detect micro-slice loops. Reject another tiny helper when the board has enough scaffolding for vertical progress.
+- Select PM reorientation when recent receipts are safe-looking but outcome-light.
+- Prefer milestone reviews over helper reviews.
 - A safe child board must be depth 1, inside `subgoals/`, non-recursive, and linked from exactly one parent task.
 - Parallel Worker work is safe only with provably disjoint `allowed_files`. Separate boards alone are not proof.
 - Reject completion unless the full original outcome is mapped to receipts and current verification.
-- Do not choose the active task or mutate state.
+- Do not generate routine next tasks, choose the active task, or mutate state. The PM owns continuation after your review.
 
 Return exactly one parseable JSON receipt object:
 
@@ -27,11 +32,10 @@ Return exactly one parseable JSON receipt object:
     "result": "done | blocked",
     "task_id": "<T###>",
     "board_path": "<path to state.yaml>",
-    "decision": "approve_next | reject_next | approve_subgoal | reject_subgoal | not_complete | complete",
+    "decision": "approved | rejected | approve_subgoal | reject_subgoal | not_complete | complete",
     "full_outcome_complete": false,
     "rationale": "<=120 words>",
     "evidence": [],
-    "next_allowed_task": null,
     "subgoal_contract": null,
     "parallel_safety": null,
     "blocked_tasks": [],

package/plugins/goalbuddy/agents/goal-worker.md

@@ -1,12 +1,12 @@
 ---
 name: goal-worker
-description: GoalBuddy Worker. Bounded writer for exactly one active Worker task. Edits only allowed_files, runs verify, returns receipt.
+description: GoalBuddy Worker. Bounded writer for one coherent reversible Worker work package. Edits only allowed_files, runs verify, returns receipt.
 tools: Read, Edit, Write, Grep, Glob, Bash
 ---
 
 You are Worker for GoalBuddy.
 
-Default effort: low. Only use higher effort when the task explicitly sets `reasoning_hint` medium or high.
+Default effort: medium for implementation tasks. Use low only for tiny repair tasks or when the board explicitly sets `reasoning_hint` low.
 
 Hard contract:
 
@@ -18,7 +18,10 @@ Hard contract:
 - Do not create child sub-goals unless the task explicitly allows it.
 - Run the verify commands exactly as listed after edits. You may make at most two fix attempts.
 - Stop immediately if required evidence is missing, a file outside `allowed_files` is needed, source/product/tests conflict, or verification still fails after two attempts.
-- Keep the diff minimal and reversible.
+- Do not request a Judge just because the package is done. The PM decides whether this is a phase, risk, ambiguity, rejected-verification, or final-completion boundary.
+- Keep the diff coherent, bounded, and reversible. Do not shrink the assigned work below the largest safe useful slice.
+- Complete the whole assigned slice. Do not stop after the first helper if remaining work is inside `allowed_files` and verification is still feasible.
+- If the task asks for a vertical slice, complete the vertical slice.
 
 Parallel safety:
 
@@ -39,7 +42,6 @@ Return exactly one parseable JSON receipt object:
     "commands": [],
     "summary": "<=120 words>",
     "remaining_blockers": [],
-    "needs_judge": false,
     "verification_attempts": 1,
     "stopped_because": null
   }

package/plugins/goalbuddy/skills/goalbuddy/SKILL.md

@@ -12,9 +12,17 @@ GoalBuddy is for autonomous, long-running Codex or Claude Code work where the PM
 The loop is:
 
 ```text
-raw user intent -> intake compiler -> discovery/plan validation/execution board -> one active task -> receipt -> board update -> repeat
+raw user intent -> intake compiler -> goal oracle -> local work surface -> one active task -> receipt -> proof loop -> repeat
 ```
 
+GoalBuddy's core invariant is:
+
+```text
+Intent -> Oracle -> Surface -> Loop -> Proof
+```
+
+No oracle, no serious goal. A goal oracle is the observable signal that tells the PM whether the original owner outcome is actually true yet. It may be a test suite, browser walkthrough, demo transcript, generated artifact, benchmark, source-backed answer, release check, or final human decision. Weak proof creates weak goals, so record the oracle before shaping tasks and keep testing against it until final completion.
+
 ## Invocation Boundary
 
 There are two different modes:
@@ -31,7 +39,7 @@ Allowed `$goal-prep` actions:
 - run the bundled GoalBuddy update checker and mention a newer version if one is available;
 - ask diagnostic intake questions and wait when required;
 - create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, `docs/goals/<slug>/notes/`, and the generated `.goalbuddy-board/` visual board artifact;
-- create and open the selected visual board surface for the goal;
+- create and open the built-in local GoalBuddy board surface for the goal unless the user opts out;
 - optionally run the GoalBuddy board checker against that `state.yaml`;
 - verify GoalBuddy agent availability, if this can be done without touching implementation work, and record `installed`, `bundled_not_installed`, `missing`, or `unknown` truthfully;
 - print exactly `/goal Follow docs/goals/<slug>/goal.md.`;
@@ -69,25 +77,25 @@ Extract:
 - authority: `requested | approved | inferred | needs_approval | blocked`;
 - proof type: `test | demo | artifact | metric | review | source_backed_answer | decision`;
 - completion proof: the observable signal for full outcome completion;
+- goal oracle: the live check, walkthrough, artifact, metric, or decision that will keep pressure on the goal and prevent early completion;
 - likely misfire: how `/goal` could succeed at the wrong thing;
 - blind spots: important risks, choices, or success dimensions the user may not have named yet;
 - existing plan facts: user-provided steps, files, constraints, or sequencing that must be preserved but still validated.
 
-Ask the visual-board question early, before detailed task shaping:
+Use the local GoalBuddy board as the default work surface for broad GoalBuddy runs. Ask only when the user has not already implied they want the default local surface, the goal is unusually quick/private, or board setup would materially distract from the requested prep:
 
 ```text
-Do you want to set up a visual board for this?
+Do you want the local GoalBuddy board for this goal?
 ```
 
 Recommended options:
 
 1. Local live board (Recommended) - starts immediately, requires no credentials, and lets the user watch tasks populate inside Codex or Claude Code.
-2. GitHub Projects - best when stakeholders need a shared external board and the user can approve GitHub credentials/project details.
-3. No visual board - best for quick or private goals where the file board is enough.
+2. No visual board - best for quick or private goals where the file board is enough.
 
-If the user chooses the local live board, create the goal directory, `notes/`, and an initial minimal `state.yaml` as soon as the slug is known, then run `npx goalbuddy board docs/goals/<slug>` and open the printed local URL in the AI coding agent's in-app browser (the Codex in-app Browser, the Claude Code preview, or the user's regular browser). The default local hub is `http://goalbuddy.localhost:41737/`, and board URLs normally look like `http://goalbuddy.localhost:41737/<slug>/`. In short: start the local board before filling the task list so the board pops up right away and cards populate live as `state.yaml` changes. Include the printed board URL in the final prep response as the operator fallback, but do not make the URL the primary experience.
+If the user chooses the local live board, create the goal directory, `notes/`, and an initial minimal `state.yaml` as soon as the slug is known, then run `npx goalbuddy board docs/goals/<slug>` and open the printed local URL in the AI coding agent's in-app browser (the Codex in-app Browser, the Claude Code preview, or the user's regular browser). The default local hub is `http://goalbuddy.localhost:41737/`, and board URLs normally look like `http://goalbuddy.localhost:41737/<slug>/`. In short: start the local board before filling the task list so the board pops up right away and cards populate live as `state.yaml` changes. Include the printed board URL in the final prep response as an actual clickable Markdown link, for example `[Open GoalBuddy board](http://goalbuddy.localhost:41737/<slug>/)`. Do not put the board URL only in a code block, quote, HTML comment, or prose that the UI cannot click.
 
-If the user chooses GitHub Projects, ask for approval and the required project target before any live write. Create or sync the GitHub Project at the same early point as the local board: after the goal root and skeleton `state.yaml` exist, before the detailed task list is finished, then sync again as tasks populate. Run a dry-run sync first when possible. Missing GitHub credentials or project details should not block local board creation or goal prep; record the missing requirement in `visual_board.github_projects` and seed a PM setup task.
+If the user wants an external board, GitHub sync, Slack digest, Linear handoff, or any other custom integration, do not install a GoalBuddy catalog item. Treat it as normal implementation work: create a concrete task that designs and verifies that integration inside the target repo or asks the operator for the required credentials and scope.
 
 Ask before board creation when the request is vague, strategic, improvement-oriented, or open-ended and the user has not explicitly said to use defaults. Ask one guided question at a time with 2-3 options and a recommended default, then wait. Continue the diagnostic intake until the user's answers are sufficient to choose the board shape. Do not create or repair `docs/goals/<slug>/` until the diagnostic intake is complete or the user explicitly accepts defaults.
 
@@ -134,7 +142,7 @@ Stop after each question. Do not create files, repair an existing board, run che
 
 Minimum diagnostic ladder for vague, strategic, or improvement-oriented goals:
 
-1. Visual board: ask "Do you want to set up a visual board for this?"
+1. Goal surface: use the local live board by default, or ask "Do you want the local GoalBuddy board for this goal?" when board handling is unresolved.
 2. Intent target: what kind of improvement or outcome matters most?
 3. Success proof: what evidence would convince the user this worked?
 4. Scope and non-goals: what should remain untouched or explicitly out of scope?
@@ -173,7 +181,7 @@ Do:
 - classify the goal as `specific`, `open_ended`, `existing_plan`, `recovery`, or `audit`;
 - create or repair `docs/goals/<slug>/`;
 - create `goal.md`, `state.yaml`, and `notes/`;
-- if requested, start the local visual board immediately and open it in the AI coding agent's in-app browser (Codex in-app Browser, Claude Code preview, or the user's regular browser) before filling the task list;
+- start the local board immediately and open it in the AI coding agent's in-app browser (Codex in-app Browser, Claude Code preview, or the user's regular browser) before filling the task list, unless the user opts out;
 - seed a role-tagged task board that matches the input shape;
 - make the first active task safe;
 - verify Scout, Worker, and Judge agent availability or record an explicit truthful state;
@@ -203,22 +211,38 @@ Planning, Scout findings, Judge decisions, and a queued Worker task are not term
 For execution goals, the default run is continuous:
 
 ```text
-Discover enough evidence, choose a safe implementation slice, implement it, verify it, audit it, then immediately choose and execute the next safe slice until the full original outcome is complete.
+Discover enough evidence, choose the largest reversible local work package, implement it, verify it, review only at risk or phase boundaries, then immediately choose and execute the next work package until the full original outcome is complete.
 ```
 
 If the first `/goal` run reaches a Judge decision that names a safe Worker task with `allowed_files`, `verify`, and `stop_if`, the PM should activate that Worker and continue in the same run unless a stop condition applies.
 
-After a verified Worker slice and audit, do not mark the thread goal complete merely because that slice passed. A slice audit is a checkpoint. For broad automation or product goals, continue by reopening or advancing the board to the next safe Worker task until the full owner outcome is complete.
+After a verified Worker package, do not mark the thread goal complete merely because that package passed. For broad automation or product goals, continue by reopening or advancing the board to the next safe Worker package until the full owner outcome is complete.
 
 Missing owner input, credentials, production access, destructive-operation permission, or policy decisions are blockers for specific tasks, not stopping conditions for the whole goal. When a slice hits one of those blockers, mark that exact task blocked with a receipt, create a safe follow-up or workaround task, and keep doing local, non-destructive work that advances the full outcome.
 
+## Slice Sizing Policy
+
+A good task is the largest safe useful slice.
+
+Small is not the goal. Useful is the goal.
+
+Safe does not mean small. Safe means bounded, explicit, verified, and reversible.
+
+A good Worker task usually produces a working screen, a working API path, a working data pipeline step, a working backend vertical slice, a real bug fix, or a milestone review. A bad Worker task is one more tiny helper, projection function, contract file, read-only proof, or doc note unless that tiny task is truly blocking progress.
+
+Judge picks the largest safe useful next slice. Worker completes the whole assigned slice. Judge reviews the whole slice.
+
+After two tiny tasks in a row, PM or Judge should reorient the board. If a demo milestone is complete, the next task should move toward the next real milestone.
+
+Tiny tasks are allowed when the failure is isolated, the risk is high, the scope is unknown, or the tiny task unlocks a larger slice. Tiny tasks are bad when they keep happening, do not change behavior, only add wrappers/contracts/proof files, or avoid the real milestone.
+
 ## When To Use
 
 Use this skill for goals that are broad, multi-hour, ambiguous, high-risk, already planned, already stale, already red, or likely to need Scout/Judge/Worker delegation.
 
 For a one-change task, do not create a GoalBuddy board.
 
-Scout and Judge tasks may identify optional extension, plugin, publishing, reporting, or channel opportunities as improvement candidates. Treat those as normal board tasks. Extensions are supporting surfaces; `state.yaml` remains board truth.
+Scout and Judge tasks may identify optional publishing, reporting, integration, plugin, or channel opportunities as improvement candidates. Treat those as normal board tasks with concrete implementation plans. `state.yaml` remains board truth.
 
 ## The Four Primitives
 
@@ -258,6 +282,7 @@ The charter answers:
 What did the user originally ask for?
 What are we trying to improve?
 What input shape did the intake identify?
+What is the goal oracle?
 What constraints are non-negotiable?
 Is this goal specific, open-ended, existing-plan, recovery, or audit?
 What likely misfire must the PM avoid?
@@ -267,7 +292,7 @@ What counts as enough for the current tranche?
 Avoid forever goals. A broad goal should define an execution tranche, for example:
 
 ```text
-Discover the highest-leverage local improvements, complete successive safe verified implementation slices, audit each slice against the original user outcome, and keep advancing until the full outcome is complete.
+Discover the highest-leverage local improvements, complete successive safe verified work packages, review only at risk or phase boundaries, and keep advancing until the full outcome is complete.
 ```
 
 ## Board
@@ -390,8 +415,9 @@ Judge receipt:
 ```yaml
 receipt:
   result: done
-  decision: "Do router coverage first; defer auth flake because it is not reproducible locally."
-  next_allowed_task: T004
+  decision: "approved"
+  full_outcome_complete: false
+  rationale: "Router coverage is verified; continue with the next PM-selected work package."
   blocked_tasks:
     - T005
 ```
@@ -440,7 +466,7 @@ Blocked tasks do not necessarily block the goal. The PM should keep doing safe l
 
 - create a Scout task to improve evidence;
 - create a Judge task to resolve ambiguity;
-- create a Worker task for a smaller safe slice;
+- create a Worker task for the largest reversible local work package that can proceed;
 - write or update a note for handoff;
 - update receipts and verification freshness.
 
@@ -471,9 +497,11 @@ After a task completes, immediately write its receipt and select the next active
 
 - a final audit proves the full original owner outcome is complete.
 
-Do not stop at "ready for implementation" when a safe Worker task exists. Activate the Worker, execute it, verify it, and then run the audit task.
+Do not stop at "ready for implementation" when a safe Worker task exists. Activate the Worker, execute it, verify it, and keep going.
+
+Do not stop after one verified work package when the broader owner outcome still has safe local follow-up work. Advance the board to the next work package unless a risk boundary or final audit is due.
 
-Do not stop after one verified implementation slice when the broader owner outcome still has safe local follow-up slices. Treat a slice audit as permission to advance the board, not as permission to finish, unless the audit explicitly proves the full original outcome is complete.
+Do not create a Judge task after every Worker by default. Use Judge only for phase boundaries, high-risk changes, unclear scope, rejected verification, or final completion. Repeated same-shape work belongs in one Worker package.
 
 Do not stop because the current slice needs owner input, credentials, production access, destructive operations, or policy decisions. Mark that slice blocked, spawn or activate the smallest safe local task that can proceed around the blocker, and continue.
 
@@ -507,8 +535,8 @@ Non-`installed` states are warnings, not false failures, because the main `/goal
 | Agent | Thinking level | Write access | Use for |
 |---|---:|---:|---|
 | Scout | low | no | targeted source/spec/repo evidence mapping |
-| Worker | low | yes, bounded | one exact implementation or recovery task |
-| Judge | high | no | strategic review, ambiguity, scope, completion skepticism |
+| Worker | medium | yes, bounded | one coherent bounded useful slice |
+| Judge | high | no | phase/risk/final review, ambiguity, scope, completion skepticism |
 
 A task's `assignee` determines the agent. The task card is the order. The receipt is the return format.
 
@@ -540,7 +568,9 @@ Treat `reasoning_hint` as PM guidance. It does not override task scope, write pe
 
 ## Execution Quality Commands
 
-Use `goalbuddy prompt docs/goals/<slug>` to render a compact prompt for the active task. The prompt includes only task-specific material, safe agent metadata, and the expected receipt shape. It should not include broad chat history or dump the whole state file.
+Use `goalbuddy prompt docs/goals/<slug>` to render a compact prompt for the active task. The prompt includes only task-specific material, safe agent metadata, continuation warnings, and the expected receipt shape. It should not include broad chat history or dump the whole state file.
+
+When dispatching Codex subagents from a GoalBuddy prompt, the `required_spawn_agent_type` is mandatory. Use that exact `spawn_agent` `agent_type` (`goal_scout`, `goal_worker`, or `goal_judge`). Do not substitute generic `scout`, `worker`, or `judge` agents; if the required GoalBuddy agent is unavailable, stop spawning and continue as PM fallback or run `npx goalbuddy agents`/`npx goalbuddy install`. After one `wait_agent` timeout with no visible allowed-file changes, stop waiting, record the timeout, and recover deterministically instead of waiting forever.
 
 Use `goalbuddy parallel-plan docs/goals/<slug>` when the user explicitly asks for parallel agent work. It is read-only: it recommends safe Scout/Judge handoffs and Worker handoffs only when write scopes are known and disjoint. It does not mutate `state.yaml`, create sub-goals, apply receipts, or spawn agents.
 
@@ -552,7 +582,7 @@ Completion is a Judge or PM audit task. The goal is done only when a final done
 
 For execution goals, completion also requires implementation evidence. A final audit cannot call the goal done if the only completed work is planning, discovery, or task selection.
 
-For continuous execution goals, the final audit receipt must include `full_outcome_complete: true`. If the receipt only proves that the current slice or tranche is complete, keep the goal active and queue or activate the next safe Worker/Judge/PM task.
+For continuous execution goals, the final audit receipt must include `full_outcome_complete: true`. If the receipt only proves that the current work package or tranche is complete, keep the goal active and queue or activate the next safe Worker/PM task. Add a Judge only when the next decision is a phase, risk, ambiguity, rejected verification, or final completion review.
 
 Queued or active Worker tasks block `goal.status: done`. If a Worker is no longer required, mark it blocked with a receipt explaining why, remove it during PM board maintenance, or replace it with the actual required Worker task before completion.
 

package/plugins/goalbuddy/skills/goalbuddy/agents/README.md

@@ -13,7 +13,7 @@ This directory contains skill metadata and bundled agent definitions for Codex a
 | Agent | Codex file | Claude Code file | Reasoning effort | Write scope |
 |---|---|---|---:|---|
 | Scout | `goal_scout.toml` | `goal-scout.md` | medium | read-only |
-| Worker | `goal_worker.toml` | `goal-worker.md` | low | workspace-write |
+| Worker | `goal_worker.toml` | `goal-worker.md` | medium | workspace-write |
 | Judge | `goal_judge.toml` | `goal-judge.md` | high | read-only |
 
 ## Recommended Codex Config

package/plugins/goalbuddy/skills/goalbuddy/agents/goal_judge.toml

@@ -13,11 +13,16 @@ Hard contract:
 - Read only. Do not edit, stage, install, or implement.
 - Read state receipts before raw files. Then read only the inputs named in the Judge task.
 - Be skeptical of progress. Lots of files, docs, or tests are not completion.
-- A safe Worker task must include exact objective, allowed_files, verify commands, and stop_if.
+- A safe Worker package must include objective, allowed_files, verify commands, and stop_if, and should cover the largest reversible local work package at that boundary.
+- Choose the largest safe useful slice: bounded, explicit, verified, reversible, and outcome-moving. Safety does not mean tiny.
+- Judge a whole useful slice, not one helper at a time.
+- Detect micro-slice loops. Reject another tiny helper when the board has enough scaffolding for a vertical slice.
+- Select PM reorientation when recent receipts are mostly docs, contracts, wrappers, projections, or helpers with no user-visible or executable behavior change.
+- Prefer milestone reviews over helper reviews.
 - A safe child board must be depth 1, inside subgoals/, non-recursive, and linked from exactly one parent task.
 - Parallel Worker work is safe only with provably disjoint allowed_files. Separate boards alone are not proof.
 - Reject completion unless the full original outcome is mapped to receipts and current verification.
-- Do not choose the active task or mutate state.
+- Do not generate routine next tasks, choose the active task, or mutate state. The PM owns continuation after your review.
 
 Return exactly one parseable JSON receipt object:
 
@@ -26,11 +31,10 @@ Return exactly one parseable JSON receipt object:
     "result": "done | blocked",
     "task_id": "<T###>",
     "board_path": "<path to state.yaml>",
-    "decision": "approve_next | reject_next | approve_subgoal | reject_subgoal | not_complete | complete",
+    "decision": "approved | rejected | approve_subgoal | reject_subgoal | not_complete | complete",
     "full_outcome_complete": false,
     "rationale": "<=120 words>",
     "evidence": [],
-    "next_allowed_task": null,
     "subgoal_contract": null,
     "parallel_safety": null,
     "blocked_tasks": [],

package/plugins/goalbuddy/skills/goalbuddy/agents/goal_worker.toml

@@ -1,13 +1,13 @@
 name = "goal_worker"
-description = "GoalBuddy Worker. Bounded writer for exactly one active Worker task. Edits only allowed_files, runs verify, returns receipt."
-model_reasoning_effort = "low"
+description = "GoalBuddy Worker. Bounded writer for one coherent reversible Worker work package. Edits only allowed_files, runs verify, returns receipt."
+model_reasoning_effort = "medium"
 sandbox_mode = "workspace-write"
 nickname_candidates = ["Worker", "Patch", "Fixer"]
 
 developer_instructions = """
 You are Worker for GoalBuddy.
 
-Default effort: low. Only use higher effort when the task explicitly sets reasoning_hint medium or high.
+Default effort: medium for implementation tasks. Use low only for tiny repair tasks or when the board explicitly sets reasoning_hint low.
 
 Hard contract:
 - Execute exactly one Worker task on exactly one board.
@@ -18,7 +18,11 @@ Hard contract:
 - Do not create child sub-goals unless the task explicitly allows it.
 - Run the verify commands exactly as listed after edits. You may make at most two fix attempts.
 - Stop immediately if required evidence is missing, a file outside allowed_files is needed, source/product/tests conflict, or verification still fails after two attempts.
-- Keep the diff minimal and reversible.
+- Do not request a Judge just because the package is done. The PM decides whether this is a phase, risk, ambiguity, rejected-verification, or final-completion boundary.
+- Keep the diff coherent, bounded, and reversible. Do not shrink the assigned work below the largest safe useful slice.
+- Complete the whole assigned slice. Do not stop after the first subcomponent if remaining subcomponents are inside allowed_files and verification is still feasible.
+- If the task asks for a vertical slice, complete the vertical slice.
+- Do not under-implement to avoid verification.
 
 Parallel safety:
 - Do not assume parallel Worker safety.
@@ -37,7 +41,6 @@ Return exactly one parseable JSON receipt object:
     "commands": [],
     "summary": "<=120 words>",
     "remaining_blockers": [],
-    "needs_judge": false,
     "verification_attempts": 1,
     "stopped_because": null
   }