@linimin/pi-letscook 0.1.37 → 0.1.40

package/CHANGELOG.md

@@ -1,11 +1,38 @@
 # Changelog
 
+## Unreleased
+
+## 0.1.40
+
+### Changed
+
+- treated bare `/cook` README/CHANGELOG/docs-only deliverables as concrete repo-change missions instead of preserving generic planning phrasing
+- made bare `/cook` ignore assistant/branch/compaction summary artifacts for startup/refocus readiness and fail closed on plan/spec/design-doc/proposal-only context without rewriting canonical state
+- refreshed the context-proposal regressions, README guidance, and packaged release parity so the new execution-ready bare `/cook` behavior stays truthful
+- internalized the repo-local `pi --no-extensions` isolation inside the packaged verifier scripts so direct `npm run smoke-test`, direct `npm run release-check`, and direct `bash .agent/verify_completion_stop.sh` stay truthful even when `@linimin/pi-letscook` is also installed globally on the same machine
+
+## 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 +123,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/PUBLISHING.md

@@ -9,6 +9,8 @@ npm run smoke-test
 npm run release-check
 ```
 
+Those direct verifier entrypoints self-isolate the repo-local extension when they shell back into `pi`, so no extra `pi --no-extensions` wrapper is required even if this package is also installed globally on the publishing machine.
+
 ## GitHub release flow
 
 ```bash

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,19 @@ 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:
+Bare `/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.
 
-```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, ambiguous, assistant-produced, or only describes planning artifacts instead of concrete repo changes, 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 main-chat discussion 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 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. 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, 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`. |
 
 ## Approval-only confirmation and fail-closed behavior
 
@@ -71,7 +67,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 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 bare `/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 an active workflow already exists and recent discussion clearly suggests a different workflow, `/cook` shows a separate chooser first:
 
@@ -226,6 +222,8 @@ npm run release-check
 
 `npm run release-check` is the broad packaged-release verifier. It begins with `bash .agent/verify_completion_control_plane.sh`, so missing or stale `.agent/verification-evidence.json` parity fails closed before the broader suite runs, then asserts the shipped single-command `/cook` public parity surfaces in `README.md`, `CHANGELOG.md`, and the `/cook` help/fail-closed copy in `extensions/completion/index.ts`, reruns the startup/refocus/context checks — including the critique-aware `/cook` confirmation regression and the smoke auto-resume prompt path — includes deterministic canonical evidence artifact coverage and includes deterministic active-slice contract coverage plus observability coverage, evaluator calibration, and the rubric-contract regression, and finishes with `npm pack --dry-run`.
 
+The direct package-root verifier commands above intentionally self-isolate the repo-local extension when they shell back into `pi`, so you should not need to wrap them with `pi --no-extensions` even if `@linimin/pi-letscook` is also installed globally on the same machine.
+
 ## Release
 
 See [PUBLISHING.md](https://github.com/linimin/pi-letscook/blob/main/PUBLISHING.md) for GitHub and npm release steps.