@linimin/pi-letscook 0.1.37 → 0.1.39

package/CHANGELOG.md

@@ -1,11 +1,27 @@
 # Changelog
 
+## 0.1.39
+
+### Changed
+
+- aligned public docs and packaged release-gate parity around bare `/cook` as the only supported workflow entrypoint
+- updated operator-facing fail-closed guidance to send users back to the main chat to clarify the mission before rerunning bare `/cook`
+- refreshed `scripts/release-check.sh` so packaged parity now fails closed on the bare-only contract while still covering the supported startup, refocus, and context flows
+
+## 0.1.38
+
+### Changed
+
+- normalized discussion-derived `/cook` missions through shared proposal finalization so planning-phrased startup, next-round, and bare active-refocus discussions now resolve to implementation-result missions only when scope or acceptance clearly point to shipped code/test/doc/runtime changes
+- preserved genuine planning missions for explicit plan/spec/design-doc/migration-plan/proposal and support-docs-only discussions, while keeping ambiguous generic scope fail-closed instead of promoting it into a new mission
+- aligned analyst-derived and strict structured-fallback `/cook` proposal paths behind the same mission-normalization rules, added deterministic regressions for planning-only preservation and ambiguous-scope fail-closed behavior, and kept the existing approval-only Start/Cancel rewrite gate intact
+
 ## 0.1.37
 
 ### Changed
 
 - documented `/cook` as the single public discussion-first workflow command for startup, active-workflow continue/refocus, and done-workflow next-round flows
-- reframed `/cook <text>` in public docs/help copy as a temporary compatibility shim instead of the primary workflow entrypoint, without removing it from the shipped runtime
+- reframed the public docs/help copy around `/cook` as the discussion-first workflow entrypoint and documented the conservative fail-closed clarification path before the later runtime removal
 - documented the fail-closed ambiguous-discussion behavior and approval-only Start/Cancel gate before canonical-state writes
 - added release-gated public-parity assertions for README/help/changelog `/cook` single-command copy so docs drift fails closed before packaging
 - simplified the README opening so first-time users can understand the problem `/cook` solves, what the extension provides, and how to start using it without reading the full control-plane details first
@@ -96,7 +112,7 @@
 ### Changed
 
 - `/cook` with no goal can now propose a context-derived startup plan for confirmation when no active workflow exists, including starting a fresh next round after the previous workflow already reached `done`
-- `/cook <goal>` now builds a goal-anchored, context-enriched startup proposal before writing canonical state, uses more explicit active-workflow replacement wording, and starts the next round directly from the explicit goal after a completed workflow instead of reopening continue/refocus choices
+- historically added goal-anchored startup proposals from inline `/cook` arguments before canonical writes, plus more explicit active-workflow replacement wording and direct next-round startup after a completed workflow; that old inline-argument path is no longer supported now that bare `/cook` is the only public entrypoint
 
 ## 0.1.24
 

package/README.md

@@ -19,7 +19,7 @@ Normal chat is good for one-off tasks. It is much worse for work that needs to:
 - repo-local canonical state in `.agent/**`
 - resumable long-running workflows
 - discussion-first startup, continue, refocus, and next-round routing
-- temporary `/cook <text>` compatibility input when you need to anchor the mission explicitly
+- fail-closed guidance that sends you back to the main chat when the mission still needs clarification
 - deterministic verification, review, audit, and stop checks
 
 ## Install
@@ -45,23 +45,17 @@ Use bare `/cook` after you discuss the mission in the main chat. The same comman
 - surface a conservative refocus chooser when recent discussion clearly points to a different workflow
 - start the next workflow round after the previous one is `done`
 
-Temporary compatibility shim when you need to anchor the mission explicitly:
-
-```text
-/cook build feature X end-to-end with tests and docs
-```
-
-On startup and next-round flows, if recent discussion is missing, weak, or ambiguous, bare `/cook` fails closed and leaves canonical `.agent/**` state unchanged until the discussion is clarified.
+On startup and next-round flows, if recent discussion is missing, weak, or ambiguous, bare `/cook` fails closed, leaves canonical `.agent/**` state unchanged, and tells you to clarify the mission in the main chat before rerunning bare `/cook`.
 
 ## How `/cook` works
 
-Bare `/cook` is now the primary workflow entrypoint. `/cook <text>` is still supported as a temporary compatibility shim, and it uses the same proposal/routing pipeline while treating the explicit text as the mission anchor when provided.
+Bare `/cook` is the only supported workflow entrypoint.
 
-| Repo state | Bare `/cook` (primary) | Temporary `/cook <text>` compatibility shim |
-|---|---|---|
-| No workflow yet | Summarizes recent discussion into a startup proposal, then asks for approval with **Start** or **Cancel**. If the discussion is weak or ambiguous, `/cook` fails closed without writing `.agent/**` state. | Uses the same startup proposal and approval-only **Start**/**Cancel** gate, but the explicit text anchors the proposed mission. |
-| Active workflow exists | Reads the current mission plus recent non-command discussion. Matching or unclear discussion resumes from canonical `.agent/**` state. Clear replacement discussion opens a chooser first, then only rewrites canonical state after the follow-on **Start** confirmation. | Uses the same discussion-first routing pipeline. The explicit text is only a temporary compatibility anchor; `/cook` can still continue unchanged or route through the chooser plus final **Start**/**Cancel** replacement confirmation. |
-| Previous workflow is `done` | Starts the next round from recent discussion, then asks for approval with **Start** or **Cancel**. Ambiguous discussion fails closed without rewriting canonical state. | Uses the same next-round proposal and approval-only gate, but the explicit text anchors the next mission. |
+| Repo state | Bare `/cook` |
+|---|---|
+| No workflow yet | Summarizes recent discussion into a startup proposal, then asks for approval with **Start** or **Cancel**. If the discussion is weak or ambiguous, `/cook` fails closed without writing `.agent/**` state and tells you to clarify the mission in the main chat before rerunning bare `/cook`. |
+| Active workflow exists | Reads the current mission plus recent non-command discussion. Matching or unclear discussion resumes from canonical `.agent/**` state. Clear replacement discussion opens a chooser first, then only rewrites canonical state after the follow-on **Start** confirmation. |
+| Previous workflow is `done` | Starts the next round from recent discussion, then asks for approval with **Start** or **Cancel**. Ambiguous discussion fails closed without rewriting canonical state and tells you to clarify the mission in the main chat before rerunning bare `/cook`. |
 
 ## Approval-only confirmation and fail-closed behavior
 
@@ -71,7 +65,7 @@ All startup, next-round, and replacement proposals are **approval-only**:
 - actions are only **Start** and **Cancel**
 - **Cancel** is side-effect free: discuss changes in the main chat and rerun `/cook`
 
-When bare `/cook` cannot derive a clear startup, next-round, or replacement proposal from recent discussion, it fails closed instead of guessing. That means no canonical `.agent/**` state is created or rewritten until the discussion is clarified or you temporarily pass `/cook <text>`.
+When bare `/cook` cannot derive a clear startup, next-round, or replacement proposal from recent discussion, it fails closed instead of guessing. That means no canonical `.agent/**` state is created or rewritten until the discussion is clarified in the main chat and you rerun bare `/cook`.
 
 When an active workflow already exists and recent discussion clearly suggests a different workflow, `/cook` shows a separate chooser first: