@linimin/pi-letscook 0.1.45 → 0.1.47

package/CHANGELOG.md

@@ -2,6 +2,15 @@
 
 ## Unreleased
 
+## 0.1.47
+
+### Changed
+
+- removed inline `/cook <text>` argument support so bare `/cook` is now the only supported workflow entrypoint
+- made runtime, deterministic regressions, README guidance, and packaged release parity fail closed when command arguments are passed instead of discussion driving proposal derivation
+- made bare `/cook` weight the latest clear implementation intent ahead of older background discussion, preserve alternate recent missions for chooser-driven disambiguation, and summarize each candidate directly in the active-workflow chooser instead of forcing a single guessed replacement path
+- made bare `/cook` suppress reopening already completed or already verified work by comparing recent discussion against canonical mission, active-slice, and verification-evidence context before startup/refocus proposal confirmation
+
 ## 0.1.44
 
 ### Fixed
@@ -18,7 +27,7 @@
 
 ### Changed
 
-- allowed `/cook <hint>` as an analyst-only high-priority prompt that focuses proposal derivation without bypassing the existing approval-only Start/Cancel confirmation gate or canonical fail-closed routing
+- historically allowed `/cook <hint>` as an analyst-only high-priority prompt that focused proposal derivation without bypassing the existing approval-only Start/Cancel confirmation gate or canonical fail-closed routing; that inline-argument path has since been removed so bare `/cook` is now the only supported entrypoint
 
 ## 0.1.41
 

package/README.md

@@ -32,33 +32,32 @@ Then run `/reload` in Pi.
 
 ## Quick start
 
-Primary entrypoints:
+Primary entrypoint:
 
 ```text
 /cook
-/cook <hint>
 ```
 
-Use `/cook` after you discuss the mission in the main chat. If the recent context is fuzzy, `/cook <hint>` can provide a short high-priority user hint for the proposal analyst while still relying on recent discussion to fill in scope, constraints, and acceptance. The same command can:
+Use bare `/cook` after you discuss the mission in the main chat. The same command can:
 
 - start a brand-new workflow from recent discussion
 - continue the current workflow when recent discussion still matches it, or when discussion is too weak or ambiguous to justify a refocus
 - 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`
 
-`/cook` expects recent main-chat discussion to describe concrete repo changes. README/CHANGELOG updates still count as concrete repo changes, but assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts do not. An inline `/cook <hint>` only guides proposal derivation; it does not bypass confirmation or become canonical state on its own.
+`/cook` expects recent main-chat discussion to describe concrete repo changes. README/CHANGELOG updates still count as concrete repo changes, but assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts do not. `/cook <text>` is no longer supported; put mission text in the main chat, then rerun bare `/cook`.
 
-On startup and next-round flows, if recent discussion is missing, weak, ambiguous, assistant-produced, or only describes planning artifacts instead of concrete repo changes, `/cook` fails closed, leaves canonical `.agent/**` state unchanged, and tells you to clarify the mission in the main chat before rerunning `/cook`. If an inline hint conflicts with the recent discussion, `/cook` also fails closed instead of guessing.
+On startup and next-round flows, if recent discussion is missing, weak, ambiguous, assistant-produced, or only describes planning artifacts instead of concrete repo changes, `/cook` fails closed, leaves canonical `.agent/**` state unchanged, and tells you to clarify the mission in the main chat before rerunning `/cook`.
 
 ## How `/cook` works
 
-Bare `/cook` and `/cook <hint>` are the supported workflow entrypoints.
+Bare `/cook` is the only supported workflow entrypoint.
 
 | Repo state | `/cook` behavior |
 |---|---|
-| No workflow yet | Summarizes recent main-chat discussion, optionally focused by `/cook <hint>`, into a startup proposal, then asks for approval with **Start** or **Cancel**. If the discussion is weak, ambiguous, assistant-produced, or only a plan/spec/design-doc/proposal artifact instead of concrete repo changes, `/cook` fails closed without writing `.agent/**` state and tells you to clarify the mission in the main chat before rerunning `/cook`. |
-| Active workflow exists | Reads the current mission plus recent non-command main-chat discussion, with any inline hint treated as extra proposal-analysis guidance only. Matching or unclear discussion resumes from canonical `.agent/**` state. Clear replacement discussion about different concrete repo changes opens a chooser first, then only rewrites canonical state after the follow-on **Start** confirmation. Assistant/summary artifacts or plan/spec/design-doc/proposal-only context do not refocus the workflow. |
-| Previous workflow is `done` | Starts the next round from recent main-chat discussion, optionally focused by `/cook <hint>`, then asks for approval with **Start** or **Cancel**. Weak, ambiguous, assistant-produced, or planning-artifact-only discussion fails closed without rewriting canonical state and tells you to clarify the mission in the main chat before rerunning `/cook`. |
+| No workflow yet | Summarizes recent main-chat discussion into a startup proposal, weighting the latest clear implementation intent ahead of older background discussion, then asks for approval with **Start** or **Cancel**. If the discussion is weak, ambiguous, assistant-produced, or only a plan/spec/design-doc/proposal artifact instead of concrete repo changes, `/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 main-chat discussion. Matching or unclear discussion resumes from canonical `.agent/**` state. Clear replacement discussion about different concrete repo changes opens a chooser first, then only rewrites canonical state after the follow-on **Start** confirmation. If recent discussion implies more than one plausible replacement mission, `/cook` keeps the current workflow parked behind a multi-candidate chooser instead of silently resuming or guessing. Assistant/summary artifacts or plan/spec/design-doc/proposal-only context do not refocus the workflow. `/cook <text>` is rejected without running proposal routing or rewriting workflow state. |
+| Previous workflow is `done` | Starts the next round from recent main-chat discussion, then asks for approval with **Start** or **Cancel**. Weak, ambiguous, assistant-produced, or planning-artifact-only discussion fails closed without rewriting canonical state and tells you to clarify the mission in the main chat before rerunning bare `/cook`. Recent discussion that only restates already-completed or already-verified work also fails closed instead of reopening the finished mission. `/cook <text>` is rejected before any next-round proposal is derived. |
 
 ## Approval-only confirmation and fail-closed behavior
 
@@ -68,17 +67,18 @@ 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 `/cook` cannot derive a clear startup, next-round, or replacement proposal for concrete repo changes from recent main-chat discussion plus any optional inline hint, 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 `/cook`. Tracked docs-only work such as README/CHANGELOG updates is still execution-ready, but assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts are not enough to start or refocus a workflow on their own.
+When `/cook` cannot derive a clear startup, next-round, or replacement proposal for concrete repo changes from recent main-chat 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 `/cook`. Tracked docs-only work such as README/CHANGELOG updates is still execution-ready, but assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts are not enough to start or refocus a workflow on their own. `/cook <text>` also fails closed immediately and tells you to move that text into the main chat before rerunning bare `/cook`.
 
-When an active workflow already exists and recent discussion clearly suggests a different workflow, `/cook` shows a separate chooser first:
+When an active workflow already exists and recent discussion suggests a different workflow, `/cook` shows a separate chooser first. The chooser can stay conservative or list multiple candidate replacements when the latest discussion contains more than one plausible implementation goal:
 
 - **Continue current workflow**
 - **Start new workflow from recent discussion**
+- **Start alternate workflow from recent discussion** (when a second plausible mission exists)
 - **Cancel**
 
-Only the follow-on startup/replacement proposal uses the approval-only Start/Cancel gate, and canonical `.agent/**` state changes happen only after **Start** is accepted.
+Chooser options summarize each candidate mission with its latest scope/constraint/acceptance highlights before the follow-on approval-only Start/Cancel gate. Canonical `.agent/**` state changes still happen only after **Start** is accepted.
 
-When you accept startup or refocus from that flow, `/cook` persists the chosen `task_type` and `evaluation_profile` across `.agent/profile.json`, `.agent/state.json`, `.agent/plan.json`, and `.agent/active-slice.json`, and records the accepted critique outcome in canonical continuation state before the re-ground round begins.
+When you accept startup or refocus from that flow, `/cook` persists the chosen `task_type` and `evaluation_profile` across `.agent/profile.json`, `.agent/state.json`, `.agent/plan.json`, and `.agent/active-slice.json`, and records the accepted critique outcome plus any alternate-mission / suppression notes in canonical continuation state before the re-ground round begins.
 
 ## Observability