quest-loop 0.3.2 → 0.3.3

package/CHANGELOG.md

@@ -6,6 +6,14 @@ All notable changes to this project are documented here. The format follows
 
 ## Unreleased
 
+## [0.3.3] — 2026-07-08
+
+### Changed
+- `$quest:plan` now makes the planning parent session adopt
+  `$quest:orchestrate` by default after creating and linting quests, stopping
+  before dispatch only when the user explicitly asks for create-only or
+  no-dispatch behavior.
+
 ## [0.3.2] — 2026-07-08
 
 ### Added

package/README.md

@@ -22,8 +22,8 @@ actually read.
 ```
 you:    $quest:plan add dark mode to the settings page
 agent:  creates quest 12 — Objective, Done-when, Validation loop… (quest create)
-you:    $quest:orchestrate
-agent:  dispatches a worker on quest 12; it iterates: milestone → validate →
+agent:  becomes $quest:orchestrate and dispatches a worker on quest 12:
+        milestone → validate →
         commit → checkpoint. You review evidence, not vibes.
 ```
 
@@ -187,11 +187,11 @@ required:
 quest-run 12 --worker codex --codex-goal-mode require
 ```
 
-When a `$quest:plan` result is accepted from Plan Mode, the parent agent should
-stay the orchestrator: create/lint quest records if needed, set the wave goal,
-spawn subagents, verify checkpoints, and rule on reviewer findings. Product
-implementation belongs to the spawned executor for each quest, not to the parent
-session via `$quest:work`.
+When a `$quest:plan` result is accepted from Plan Mode, the parent agent
+automatically stays the orchestrator: create/lint quest records if needed, set
+the wave goal, spawn subagents, verify checkpoints, and rule on reviewer
+findings. Product implementation belongs to the spawned executor for each quest,
+not to the parent session via `$quest:work`.
 
 Each iteration ends by recording evidence — a checkpoint a fresh session can
 resume from:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "quest-loop",
-  "version": "0.3.2",
+  "version": "0.3.3",
   "description": "Goal-loop engineering for coding agents: quest contracts, iterative execution with evidence checkpoints, Claude + Codex workers. Ships the `quest` store CLI and the `quest-run` headless runner.",
   "type": "module",
   "engines": { "node": ">=20" },

package/skills/plan/SKILL.md

@@ -25,18 +25,19 @@ extra context.
 ## Plan Mode handoff
 
 In Codex Plan Mode, do **not** implement product code after the user accepts a
-plan. Your role is to make the quest records real, then ask before orchestration:
+plan. The same parent agent/session that processes `$quest:plan` owns the
+handoff: make the quest records real, then adopt `$quest:orchestrate` by
+default.
 
 1. Create or confirm the quest records with `quest create` and `quest lint`.
-2. If the user accepted a plan and asked to implement it, your next role is
-   `$quest:orchestrate`, not `$quest:work`. Do not start editing product code in
-   the parent session.
-3. If the user only asked to create quests, ask whether to enter
-   `$quest:orchestrate` and dispatch the ready quests now. Do not silently
-   switch modes.
-4. In `$quest:orchestrate`, set the orchestrator goal for the wave, then spawn
-   goal-mode workers. If the user declines orchestration, stop after listing the
-   ready quest ids and validation commands.
+2. If the user accepted a plan and asked to implement it, the same parent
+   session becomes `$quest:orchestrate`, not `$quest:work`. Do not start editing
+   product code in the parent session.
+3. In `$quest:orchestrate`, set the orchestrator goal for the wave, then spawn
+   goal-mode workers.
+4. Stop after listing the ready quest ids and validation commands only when the
+   user explicitly asked for create-only/no-dispatch behavior such as "only
+   create quests", "do not dispatch", or "stop after planning".
 
 The parent session owns dispatch, checkpoint verification, reviewer rulings, and
 epic closure. The spawned executor owns implementation for exactly one quest.