@linimin/pi-letscook 0.1.67 → 0.1.69

package/.agent/README.md

@@ -13,8 +13,7 @@ This repository uses the `completion` workflow for long-running coding tasks.
 ## Ignored canonical execution state
 
 - `.agent/state.json`
-- `.agent/startup-plan.json`
-- `.agent/startup-plan.md`
+- `.agent/startup-brief.json`
 - `.agent/plan.json`
 - `.agent/active-slice.json`
 - `.agent/slice-history.jsonl`
@@ -23,7 +22,7 @@ This repository uses the `completion` workflow for long-running coding tasks.
 - `.agent/*.log`
 - `.agent/tmp/`
 
-`.agent/startup-plan.json` plus `.agent/startup-plan.md` preserve the approved workflow startup plan captured at `/cook`. `completion-regrounder` consumes that plan as planning input, then derives canonical slices in `.agent/plan.json` from current repo truth.
+`.agent/startup-brief.json` preserves the confirmed `/cook` startup intent as canonical intake for re-grounding. It does not replace `.agent/plan.json` or `.agent/active-slice.json`, which remain under regrounder authority.
 
 `.agent/verification-evidence.json` is the durable canonical record of deterministic verification for the selected slice or current HEAD. Recovery, review, audit, and stop-check reminder surfaces consume it instead of temp-only artifacts or conversational summaries when it is populated.
 

package/.agent/verify_completion_control_plane.sh

@@ -82,23 +82,16 @@ function trackedDiffFiles(fromCommit, toCommit) {
 
 const profile = readJson('.agent/profile.json');
 const state = readJson('.agent/state.json');
-const startupPlan = readJson('.agent/startup-plan.json');
+const startupBrief = fs.existsSync('.agent/startup-brief.json') ? readJson('.agent/startup-brief.json') : undefined;
 const plan = readJson('.agent/plan.json');
 const active = readJson('.agent/active-slice.json');
 const evidence = readJson('.agent/verification-evidence.json');
-let startupPlanMarkdown = '';
-try {
-  startupPlanMarkdown = fs.readFileSync('.agent/startup-plan.md', 'utf8');
-} catch (error) {
-  fail('.agent/startup-plan.md must be present and readable: ' + error.message);
-}
 
 ensureTrackedContractFiles();
 
 for (const [file, record] of [
   ['.agent/profile.json', profile],
   ['.agent/state.json', state],
-  ['.agent/startup-plan.json', startupPlan],
   ['.agent/plan.json', plan],
   ['.agent/active-slice.json', active],
 ]) {
@@ -109,42 +102,36 @@ for (const [file, record] of [
 const taskType = asString(profile.task_type);
 const evaluationProfile = asString(profile.evaluation_profile);
 if (asString(state.task_type) !== taskType) fail('.agent/state.json task_type must match .agent/profile.json task_type');
-if (asString(startupPlan.task_type) !== taskType) fail('.agent/startup-plan.json task_type must match .agent/profile.json task_type');
 if (asString(plan.task_type) !== taskType) fail('.agent/plan.json task_type must match .agent/profile.json task_type');
 if (asString(active.task_type) !== taskType) fail('.agent/active-slice.json task_type must match .agent/profile.json task_type');
 if (asString(state.evaluation_profile) !== evaluationProfile) fail('.agent/state.json evaluation_profile must match .agent/profile.json evaluation_profile');
-if (asString(startupPlan.evaluation_profile) !== evaluationProfile) fail('.agent/startup-plan.json evaluation_profile must match .agent/profile.json evaluation_profile');
 if (asString(plan.evaluation_profile) !== evaluationProfile) fail('.agent/plan.json evaluation_profile must match .agent/profile.json evaluation_profile');
 if (asString(active.evaluation_profile) !== evaluationProfile) fail('.agent/active-slice.json evaluation_profile must match .agent/profile.json evaluation_profile');
 
-if (asString(startupPlan.artifact_type) !== 'completion-startup-plan') {
-  fail('.agent/startup-plan.json artifact_type must be completion-startup-plan');
-}
-if (asString(startupPlan.status) !== 'approved') {
-  fail('.agent/startup-plan.json status must be approved');
-}
-const startupPlanMissionAnchor = asString(startupPlan.mission_anchor);
-if (!startupPlanMissionAnchor) fail('.agent/startup-plan.json mission_anchor must be present');
-if (startupPlanMissionAnchor !== asString(state.mission_anchor)) fail('.agent/startup-plan.json mission_anchor must match .agent/state.json mission_anchor');
-if (startupPlanMissionAnchor !== asString(plan.mission_anchor)) fail('.agent/startup-plan.json mission_anchor must match .agent/plan.json mission_anchor');
-if (startupPlanMissionAnchor !== asString(active.mission_anchor)) fail('.agent/startup-plan.json mission_anchor must match .agent/active-slice.json mission_anchor');
-if (!asString(startupPlan.goal_text)) fail('.agent/startup-plan.json goal_text must be present');
-for (const field of ['scope', 'constraints', 'acceptance', 'risks', 'notes', 'planned_surfaces', 'verification_intent', 'sequencing_hints']) {
-  if (!Array.isArray(startupPlan[field])) fail('.agent/startup-plan.json is missing ' + field);
-}
-if (startupPlanMarkdown.trim().length === 0) fail('.agent/startup-plan.md must not be empty');
-if (startupPlanMissionAnchor && !startupPlanMarkdown.includes(startupPlanMissionAnchor)) {
-  fail('.agent/startup-plan.md must mention the startup-plan mission_anchor');
-}
-const startupPlanGoalText = asString(startupPlan.goal_text);
-if (startupPlanGoalText && !startupPlanMarkdown.includes(startupPlanGoalText)) {
-  fail('.agent/startup-plan.md must render the startup-plan goal_text');
-}
-
 if (asString(evidence.artifact_type) !== 'completion-verification-evidence') {
   fail('.agent/verification-evidence.json artifact_type must be completion-verification-evidence');
 }
 
+const workflowEntryStatus = asString(state.workflow_entry_status);
+if (workflowEntryStatus === 'active' || startupBrief) {
+  if (!startupBrief) fail('.agent/startup-brief.json must exist when workflow entry is active');
+  if (asString(startupBrief.artifact_type) !== 'completion-startup-brief') {
+    fail('.agent/startup-brief.json artifact_type must be completion-startup-brief');
+  }
+  if (!asString(state.workflow_session_id)) {
+    fail('.agent/state.json workflow_session_id must be present when workflow entry is active');
+  }
+  if (asString(startupBrief.mission) !== asString(state.mission_anchor)) {
+    fail('.agent/startup-brief.json mission must match .agent/state.json mission_anchor');
+  }
+  if (asString(startupBrief.task_type) !== taskType) {
+    fail('.agent/startup-brief.json task_type must match .agent/profile.json task_type');
+  }
+  if (asString(startupBrief.evaluation_profile) !== evaluationProfile) {
+    fail('.agent/startup-brief.json evaluation_profile must match .agent/profile.json evaluation_profile');
+  }
+}
+
 const exactStatuses = new Set(['selected', 'in_progress', 'committed', 'done']);
 const activeStatus = asString(active.status);
 const exactHandoff = exactStatuses.has(activeStatus || '');

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## 0.1.69
+
+### Changed
+
+- preserved the confirmed `/cook` startup intent in canonical `.agent/startup-brief.json` so workflow entry is durable before regrounding authors canonical slices
+- moved workflow-session legitimacy away from in-memory routing activation and legacy `/skill:completion-protocol` prompt dependence toward canonical workflow-session state plus explicit `/cook` entry turns
+- simplified completion-driver continuation bookkeeping so explicit `/cook` kickoff/resume no longer rely on transient in-flight markers while auto-resume keeps only minimal duplicate-suppression state
+- updated smoke coverage, verifier expectations, and shipped docs/skills to describe canonical startup-brief intake plus active `/cook` workflow sessions truthfully
+
+## 0.1.68
+
+### Changed
+
+- simplified `/cook` startup sourcing so workflow proposals now come only from same-entry primary-agent startup-plan synthesis
+- stopped `/cook` from directly adopting old preview capsules or falling back to transcript-derived startup proposals
+- kept preview capsules advisory-only for humans while active-workflow replacement and next-round startup now depend on same-entry primary-agent synthesis from current task context
+
 ## 0.1.67
 
 ### Changed

package/README.md

@@ -34,9 +34,8 @@ Then run `/reload` in Pi.
 2. Run `/reload` in Pi.
 3. In the main chat, either implement directly with the agent or refine the concrete repo change you want.
 4. When you want workflow mode, run `/cook`.
-5. Review the startup plan and choose **Start** or **Cancel**.
-6. After **Start**, `/cook` records the approved startup plan under `.agent/` and hands the workflow to `completion-regrounder` to split canonical slices.
-7. Later, run `/cook` again to resume from canonical state or confirm a replacement or next-round startup plan.
+5. Review the startup brief and choose **Start** or **Cancel**.
+6. Later, run `/cook` again to resume from canonical state or confirm a replacement or next-round handoff.
 
 ```text
 /cook
@@ -53,15 +52,16 @@ Then run `/reload` in Pi.
 
 ## What `/cook` expects
 
-- enough current task context for a primary-agent startup-plan synthesis step to produce a concrete workflow startup plan
-- a mission, scope, acceptance, and verification intent concrete enough for `completion-regrounder` to derive truthful slices after startup
+- enough current task context for a primary-agent handoff synthesis step to produce a concrete workflow startup handoff
+- a mission and first slice concrete enough for the primary-agent handoff step to author a truthful implementation-startable handoff
+- acceptance and verification intent that can support a truthful first workflow round
 - README/CHANGELOG updates still count as concrete repo changes
-- assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts still do not count unless the primary-agent startup-plan step turns them into concrete startup intake for `/cook`
-- `/cook` first prefers a fresh explicit `cook_handoff` preview when one already exists, but otherwise calls the primary-agent startup-plan synthesis step in the same `/cook` entry
+- assistant-produced summaries and plan/spec/design-doc/proposal-only artifacts still do not count unless the primary-agent handoff step turns them into a concrete `cook_handoff` capsule
+- `/cook` first prefers a fresh explicit `cook_handoff` capsule when one already exists, but otherwise calls the primary-agent handoff synthesis step in the same `/cook` entry
 
-If the startup-plan step still cannot prepare a concrete startup plan, `/cook` fails closed, leaves canonical `.agent/**` state unchanged, and tells you to refine the mission, scope, acceptance, or verification intent in the main chat before rerunning `/cook`.
+If the primary-agent handoff step still cannot prepare a concrete handoff, `/cook` fails closed, leaves canonical `.agent/**` state unchanged, and tells you to refine the mission, first slice, or verification intent in the main chat before rerunning `/cook`.
 
-If a fresh explicit preview exists but is still workflow-worthy rather than concrete enough to seed workflow planning, `/cook` also fails closed instead of silently treating that capsule as canonical workflow state.
+If a fresh explicit handoff exists but is still workflow-worthy rather than implementation-startable, `/cook` also fails closed instead of silently treating that capsule as planning support or canonical workflow state.
 
 If you pass inline arguments to `/cook`, it also fails closed and tells you to move that intent into the main chat before rerunning bare `/cook`.
 
@@ -69,17 +69,16 @@ If you pass inline arguments to `/cook`, it also fails closed and tells you to m
 
 Only explicit `/cook` enters workflow mode. Ordinary prompts stay in the main chat and go straight to the primary agent.
 
-Ordinary chat can still directly implement repo changes. `/cook` is for the cases where you want workflow control rather than just implementation help, and the primary agent should prepare the startup plan before workflow begins.
+Ordinary chat can still directly implement repo changes. `/cook` is for the cases where you want workflow control rather than just implementation help, and the primary agent should prepare the handoff before you run it.
 
-When you explicitly run `/cook`, it first checks for a fresh explicit primary-agent startup-plan preview. If one is missing, it calls a same-entry primary-agent startup-plan synthesis step from the current task context, then asks you to **Start** or **Cancel** before rewriting canonical workflow state.
+When you explicitly run `/cook`, it first checks for a fresh explicit primary-agent handoff. If one is missing, it calls a same-entry primary-agent handoff synthesis step from the current task context, then asks you to **Start** or **Cancel** before rewriting canonical workflow state.
 
-Explicit `/cook` capsules are still valid startup intake, but they are no longer the only path because `/cook` can synthesize the primary-agent startup plan in the same entry when needed.
+Explicit `/cook` capsules are still valid startup intake, but they are no longer the only path because `/cook` can synthesize the primary-agent handoff in the same entry when needed.
 
 Important behavior:
 - `/cook` is an optional workflow boundary and manual entry point
-- startup and next-round entry stay confirm-first, using explicit primary-agent startup-plan data when present and otherwise running the primary-agent startup-plan synthesis step in the same `/cook` entry
-- after **Start**, `/cook` records the approved startup plan under `.agent/startup-plan.json` / `.agent/startup-plan.md`, then `completion-regrounder` derives canonical slices from repo truth
-- active workflows resume from canonical `.agent/**` state unless a concrete replacement startup plan is available or synthesized in the same `/cook` entry
+- startup and next-round entry stay confirm-first, using explicit primary-agent handoff data when present and otherwise running the primary-agent handoff synthesis step in the same `/cook` entry
+- active workflows resume from canonical `.agent/**` state unless a concrete replacement handoff is available or synthesized in the same `/cook` entry
 - explicit slash commands other than `/cook` continue normally in the main chat
 - ordinary main-chat discussion may clarify, propose, or directly implement repo changes without entering workflow mode
 
@@ -95,13 +94,13 @@ I want to add login redirect handling and tests.
 
 ## What happens when you run `/cook`
 
-`/cook` first checks for a fresh explicit primary-agent startup-plan preview. New-workflow entry and done-workflow next-round entry use that plan when it already exists; otherwise `/cook` calls a same-entry primary-agent startup-plan synthesis step, then immediately continues to Start / Cancel if the generated plan is concrete enough. After **Start**, the approved startup plan is written into `.agent/startup-plan.json` / `.agent/startup-plan.md`, and `completion-regrounder` uses it to derive canonical slices from current repo truth. Active workflows still resume canonical state by default unless a concrete replacement startup plan is available or synthesized in the same `/cook` entry. None of this prevents ordinary-chat implementation when you choose not to enter workflow mode.
+`/cook` first checks for a fresh explicit primary-agent handoff capsule. New-workflow entry and done-workflow next-round entry use that handoff when it already exists; otherwise `/cook` calls a same-entry primary-agent handoff synthesis step, then immediately continues to Start / Cancel if the generated handoff is concrete enough. Active workflows still resume canonical state by default unless a concrete replacement handoff is available or synthesized in the same `/cook` entry. None of this prevents ordinary-chat implementation when you choose not to enter workflow mode.
 
 | Repo state | What you'll see |
 |---|---|
-| No workflow yet | `/cook` consumes a fresh explicit primary-agent startup-plan preview when one already exists, or synthesizes one from the primary-agent view in the same entry, then asks you to choose **Start** or **Cancel**. After **Start**, the approved startup plan is persisted under `.agent/` and `completion-regrounder` derives canonical slices. Stale, planning-only, or non-startable startup plans still fail closed. |
-| Active workflow exists | Usually a resume of the current workflow from canonical `.agent/**` state. If a concrete replacement startup plan exists already or is synthesized in the same `/cook` entry and points to a different mission, `/cook` shows a chooser first and only rewrites canonical state after you confirm the replacement. Ambiguous or missing replacement startup plans stay conservative. |
-| Previous workflow is `done` | `/cook` can start the next implementation round from a fresh explicit primary-agent startup plan or from the same-entry primary-agent startup-plan synthesis step behind **Start** or **Cancel**. Weak or planning-only next-round startup plans still fail closed. |
+| No workflow yet | `/cook` consumes a fresh explicit primary-agent handoff when one already exists, or synthesizes one from the primary-agent view in the same entry, then asks you to choose **Start** or **Cancel**. Stale, planning-only, or non-startable handoffs still fail closed. |
+| Active workflow exists | Usually a resume of the current workflow from canonical `.agent/**` state. If a concrete replacement handoff exists already or is synthesized in the same `/cook` entry and points to a different mission, `/cook` shows a chooser first and only rewrites canonical state after you confirm the replacement. Ambiguous or missing replacement handoff stays conservative. |
+| Previous workflow is `done` | `/cook` can start the next implementation round from a fresh explicit primary-agent handoff or from the same-entry primary-agent handoff synthesis step behind **Start** or **Cancel**. Weak or planning-only next-round handoffs still fail closed. |
 
 ## Confirmation and fail-closed behavior
 
@@ -115,9 +114,9 @@ I want to add login redirect handling and tests.
 
 When you accept startup or refocus, `/cook` persists the chosen workflow state in canonical `.agent/**` files before the re-ground round begins.
 
-The confirmed startup plan is preserved under `.agent/startup-plan.json` / `.agent/startup-plan.md` and summarized in `state.json` as advisory intake for later re-grounding. It does not replace `.agent/plan.json` or `.agent/active-slice.json`, which remain under regrounder authority.
+The confirmed startup brief is also preserved there in `.agent/startup-brief.json` as canonical intake for later re-grounding. It does not replace `.agent/plan.json` or `.agent/active-slice.json`, which remain under regrounder authority.
 
-The pre-`/cook` preview capsule itself is not canonical workflow state. It is only startup intake for `/cook`.
+The pre-`/cook` handoff capsule itself is not canonical workflow state. It is only startup intake for `/cook`.
 
 ## Observability
 
@@ -203,8 +202,7 @@ This package stores canonical workflow state under:
   verify_completion_stop.sh
   verify_completion_control_plane.sh
   state.json
-  startup-plan.json
-  startup-plan.md
+  startup-brief.json
   plan.json
   active-slice.json
   slice-history.jsonl
@@ -231,8 +229,7 @@ Tracked repo-contract files:
 Ignored execution-state files:
 
 - `.agent/state.json`
-- `.agent/startup-plan.json`
-- `.agent/startup-plan.md`
+- `.agent/startup-brief.json`
 - `.agent/plan.json`
 - `.agent/active-slice.json`
 - `.agent/slice-history.jsonl`
@@ -244,7 +241,7 @@ Ignored execution-state files:
 In short:
 
 - tracked `.agent` files define the repo-level workflow contract
-- ignored `.agent` files are the local control-plane state for the current run, including the approved startup plan captured at `/cook`
+- ignored `.agent` files are the local control-plane state for the current run
 
 ## Package layout
 

package/agents/completion-bootstrapper.md

@@ -14,7 +14,6 @@ You are an onboarding-only control-plane role. You may:
 - create or repair tracked completion contract files under `.agent/**`
 - update `.gitignore` so tracked contract files remain tracked while execution artifacts remain ignored
 - initialize missing or invalid canonical execution-state files only when repair is required for a truthful handoff
-- preserve any approved startup plan already recorded in `.agent/startup-plan.json`
 - return the exact handoff payload for `completion-regrounder`
 
 You must not:
@@ -41,7 +40,7 @@ These lines are for workflow observability, not hidden reasoning. Keep them brie
 3. If repo intent or validation entrypoint is ambiguous, ask one short clarifying question.
 4. Create or repair `.agent/README.md`, `.agent/mission.md`, `.agent/profile.json`, `.agent/verify_completion_stop.sh`, and `.agent/verify_completion_control_plane.sh`, keeping them truthful to current repo reality.
 5. Update `.gitignore` so `.agent/*` remains ignored except the tracked repo-contract files, and keep `.agent/tmp/` ignored as scratch space.
-6. Initialize `.agent/state.json`, `.agent/startup-plan.json`, `.agent/startup-plan.md`, `.agent/plan.json`, and `.agent/active-slice.json` only when they are missing, unreadable, or structurally invalid. Preserve any existing truthful execution state.
+6. Initialize `.agent/state.json`, `.agent/plan.json`, and `.agent/active-slice.json` only when they are missing, unreadable, or structurally invalid. Preserve any existing truthful execution state.
 7. Stop after canonical bootstrap or repair is truthful and return the handoff to `completion-regrounder`.
 
 Return exactly this fixed report format:

package/agents/completion-regrounder.md

@@ -12,7 +12,6 @@ You are the canonical reconciliation role. You may:
 
 - read current repo truth and canonical `.agent` state
 - write canonical `.agent` state and `.gitignore`
-- read the approved startup plan in `.agent/startup-plan.json` and `.agent/startup-plan.md`
 - rebuild or reconcile `.agent/plan.json`
 - confirm or update `.agent/active-slice.json` and `.agent/state.json`
 - reopen slices whose acceptance criteria no longer hold
@@ -37,30 +36,25 @@ These lines are for workflow observability, not hidden reasoning. Keep them brie
 
 1. Read canonical `.agent` inputs before changing canonical state.
 2. Read current git status, recent git history, and repo surfaces relevant to the locked or remaining contract IDs.
-3. Read `.agent/startup-plan.json` / `.agent/startup-plan.md` and extract the approved mission, scope, acceptance, risks, planned surfaces, verification intent, and any sequencing hints.
-4. Treat that startup plan as planning input only, then derive the smallest truthful canonical slices from current repo truth instead of copying startup-plan structure blindly into `.agent/plan.json`.
-5. If current repo truth contradicts, narrows, or broadens the approved startup plan, preserve the startup-plan record as historical intake, explain the deviation explicitly, and reconcile `.agent/plan.json` / `.agent/state.json` to the newer truth.
-6. Emit an explicit startup-plan reconciliation outcome in your report so the workflow driver can see whether canonical slices adopted the startup plan as-is or deviated from it.
-7. Revalidate every slice's `acceptance_criteria` against current repo truth and update `status` plus `evidence` accordingly.
-8. Reopen any previously `done` slice whose acceptance criteria no longer hold.
-9. Keep `.agent/state.json` and `.agent/active-slice.json` truthful, including `current_phase`, `continuation_policy`, `continuation_reason`, `next_mandatory_role`, and any exact implementer handoff snapshot fields.
-10. Reconcile canonical state after review, audit, and final stop verification waves when required.
-11. If the latest committed slice leaves the tracked and unignored worktree dirty, treat that dirty state as a blocker, reopen or continue that latest slice for reconciliation, set `Next role to invoke` to `completion-implementer`, and do not select or hand off any different next slice until it is reconciled.
-12. When reconciling after review, audit, or dirty-worktree follow-up for the latest committed slice, emit an explicit reconciliation record decision:
+3. Reconcile `.agent/plan.json` against current repo truth.
+4. Revalidate every slice's `acceptance_criteria` against current repo truth and update `status` plus `evidence` accordingly.
+5. Reopen any previously `done` slice whose acceptance criteria no longer hold.
+6. Keep `.agent/state.json` and `.agent/active-slice.json` truthful, including `current_phase`, `continuation_policy`, `continuation_reason`, `next_mandatory_role`, and any exact implementer handoff snapshot fields.
+7. Reconcile canonical state after review, audit, and final stop verification waves when required.
+8. If the latest committed slice leaves the tracked and unignored worktree dirty, treat that dirty state as a blocker, reopen or continue that latest slice for reconciliation, set `Next role to invoke` to `completion-implementer`, and do not select or hand off any different next slice until it is reconciled.
+9. When reconciling after review, audit, or dirty-worktree follow-up for the latest committed slice, emit an explicit reconciliation record decision:
    - `accepted` only when the latest committed slice is truthfully accepted as-is
    - `reopened` only when the latest committed slice must be reopened for follow-up work
    - `none` when this re-ground was not a post-commit reconciliation decision
-13. If you emit `accepted` or `reopened`, also emit the exact reconciled slice id in the report.
-14. If a slice is already selected, ensure `.agent/active-slice.json` contains the exact implementer handoff snapshot and return that exact handoff payload for `completion-implementer` instead of implementing it yourself.
-15. If no slice is selected, return the exact next recommended slice and why.
+10. If you emit `accepted` or `reopened`, also emit the exact reconciled slice id in the report.
+11. If a slice is already selected, ensure `.agent/active-slice.json` contains the exact implementer handoff snapshot and return that exact handoff payload for `completion-implementer` instead of implementing it yourself.
+12. If no slice is selected, return the exact next recommended slice and why.
 
 Output format:
 
 - `MISSION ANCHOR: ...`
 - `Remaining contract IDs: ...`
 - `Canonical re-ground applied: yes/no - ...`
-- `Startup plan adopted as-is: yes/no - ...`
-- `Startup-plan deviations from repo truth: ...`
 - `Acceptance criteria revalidated: yes/no - ...`
 - `Tracked and unignored worktree is clean: yes/no`
 - `Reopened slices: ...`