@linimin/pi-letscook 0.1.27 → 0.1.29
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/README.md +114 -118
- package/extensions/completion/index.ts +588 -89
- package/package.json +1 -1
- package/scripts/context-proposal-test.sh +180 -16
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,19 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.1.29
|
|
4
|
+
|
|
5
|
+
### Changed
|
|
6
|
+
|
|
7
|
+
- tightened the README opening description so it correctly presents this package as a Pi extension that adds `/cook`, rather than implying `/cook` is built into Pi itself
|
|
8
|
+
|
|
9
|
+
## 0.1.28
|
|
10
|
+
|
|
11
|
+
### Changed
|
|
12
|
+
|
|
13
|
+
- added model-assisted `/cook` startup proposal analysis for natural recent discussion with a live `/cook proposal analyst` progress overlay, removed the built-in discussion-parser fallback for discussion-only startup, and preserved explicit-goal mission anchoring even when analyst output is unavailable
|
|
14
|
+
- replaced the crowded built-in `/cook` startup proposal selector presentation with a custom confirmation UI that separates proposal content from explicit Start, Edit, and Cancel actions
|
|
15
|
+
- fixed `/cook proposal analyst` overlay input handling and improved proposal body readability in the confirmation UI
|
|
16
|
+
|
|
3
17
|
## 0.1.27
|
|
4
18
|
|
|
5
19
|
### Changed
|
package/README.md
CHANGED
|
@@ -1,148 +1,141 @@
|
|
|
1
1
|
# @linimin/pi-letscook
|
|
2
2
|
|
|
3
|
-
Pi
|
|
4
|
-
|
|
5
|
-
## What it gives you
|
|
6
|
-
|
|
7
|
-
- `/cook` as the single workflow command
|
|
8
|
-
- `/cook <goal>` to bootstrap or continue with an explicit goal, enriched by recent discussion before canonical state is written
|
|
9
|
-
- `/cook` with no goal to resume an active canonical `.agent/**` workflow, or propose a new round from recent discussion when no active workflow is running
|
|
10
|
-
- `/cook <new goal>` on an active workflow asks whether to continue the current mission or abandon it for a replacement workflow; on a completed workflow it starts the next round from the new goal instead of reopening continue/refocus choices
|
|
11
|
-
- no duplicate prompt-template aliases for core workflow commands
|
|
12
|
-
- role-based isolated subprocess execution via `completion_role`
|
|
13
|
-
- completion widget sourced from canonical `.agent/**` state when no role is actively running, with no completion status line
|
|
14
|
-
- richer live role observability that keeps tool activity separate from role progress, rationale, next-step, verification, and state-delta output
|
|
15
|
-
- deterministic waiting/stalled signaling for running completion roles
|
|
16
|
-
- custom compaction continuity capsule
|
|
17
|
-
- canonical transcription of reviewer, auditor, regrounder, and stop-judge outputs
|
|
18
|
-
- repo-local verifier scripts and `.gitignore` wiring
|
|
3
|
+
A Pi extension that adds `/cook` for resumable long-running workflows backed by repo-local canonical state in `.agent/**`.
|
|
19
4
|
|
|
20
|
-
|
|
5
|
+
`@linimin/pi-letscook` is for work that does not fit in a single chat turn:
|
|
21
6
|
|
|
22
|
-
|
|
7
|
+
- start from a goal or from recent discussion
|
|
8
|
+
- resume later from repo-local workflow state
|
|
9
|
+
- refocus an active workflow without losing control of the mission
|
|
10
|
+
- drive implementation through isolated completion roles
|
|
11
|
+
- keep verification, review, audit, and stop checks tied to the repo
|
|
23
12
|
|
|
24
|
-
|
|
25
|
-
/cook build feature X end-to-end with tests and docs
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
If you stop and come back later while that workflow is still active:
|
|
29
|
-
|
|
30
|
-
```text
|
|
31
|
-
/cook
|
|
32
|
-
```
|
|
13
|
+
## Why use it
|
|
33
14
|
|
|
34
|
-
|
|
15
|
+
Use this package when you want `/cook` to behave like a real project workflow command instead of a one-shot prompt.
|
|
35
16
|
|
|
36
|
-
|
|
37
|
-
/cook fix onboarding crash first, with regression tests
|
|
38
|
-
```
|
|
17
|
+
It gives you:
|
|
39
18
|
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
19
|
+
- **one command** for start, resume, and refocus
|
|
20
|
+
- **repo-local canonical state** under `.agent/**`
|
|
21
|
+
- **model-assisted startup proposals** from recent discussion
|
|
22
|
+
- **explicit-goal anchoring** when you want the mission to stay fixed
|
|
23
|
+
- **isolated completion roles** via `completion_role`
|
|
24
|
+
- **deterministic verification** through repo-local scripts and regression checks
|
|
45
25
|
|
|
46
26
|
## Install
|
|
47
27
|
|
|
48
|
-
### Try temporarily from a local checkout
|
|
49
|
-
|
|
50
28
|
```bash
|
|
51
|
-
pi
|
|
29
|
+
pi install npm:@linimin/pi-letscook
|
|
52
30
|
```
|
|
53
31
|
|
|
54
|
-
|
|
32
|
+
Then run `/reload` in Pi.
|
|
55
33
|
|
|
56
|
-
|
|
57
|
-
pi install /absolute/path/to/pi-letscook
|
|
58
|
-
```
|
|
34
|
+
## Quick start
|
|
59
35
|
|
|
60
|
-
|
|
36
|
+
Start from an explicit goal:
|
|
61
37
|
|
|
62
|
-
```
|
|
63
|
-
|
|
38
|
+
```text
|
|
39
|
+
/cook build feature X end-to-end with tests and docs
|
|
64
40
|
```
|
|
65
41
|
|
|
66
|
-
|
|
42
|
+
Resume an active workflow:
|
|
67
43
|
|
|
68
|
-
```
|
|
69
|
-
|
|
44
|
+
```text
|
|
45
|
+
/cook
|
|
70
46
|
```
|
|
71
47
|
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
For normal installs, prefer the npm package above. Use the git source if you want to install directly from GitHub.
|
|
48
|
+
Replace the active workflow with a different goal:
|
|
75
49
|
|
|
76
|
-
```
|
|
77
|
-
|
|
50
|
+
```text
|
|
51
|
+
/cook fix onboarding crash first, with regression tests
|
|
78
52
|
```
|
|
79
53
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
After install, run `/reload` in pi. For this package, it is safest to reload when pi is idle and no `completion_role` is currently running.
|
|
54
|
+
Start the next round after the previous workflow is already done:
|
|
83
55
|
|
|
84
|
-
|
|
56
|
+
```text
|
|
57
|
+
/cook ship the next workflow round for richer /cook startup proposals
|
|
58
|
+
```
|
|
85
59
|
|
|
86
|
-
|
|
60
|
+
## How `/cook` behaves
|
|
87
61
|
|
|
88
|
-
`/cook` is the
|
|
62
|
+
`/cook` is the only public workflow command, but it behaves differently depending on the current canonical workflow state.
|
|
89
63
|
|
|
90
64
|
| Repo state | `/cook` | `/cook <goal>` |
|
|
91
65
|
|---|---|---|
|
|
92
|
-
| No canonical workflow yet |
|
|
93
|
-
| Active workflow exists | Resumes the active workflow from canonical `.agent/**` state | Asks whether to continue the current workflow or replace it
|
|
94
|
-
| Previous workflow is already `done` |
|
|
66
|
+
| No canonical workflow yet | Uses the proposal analyst to summarize recent discussion into a startup proposal, then asks for confirmation | Builds a startup proposal anchored on the explicit goal, optionally enriching it from recent discussion, then asks for confirmation |
|
|
67
|
+
| Active workflow exists | Resumes the active workflow from canonical `.agent/**` state | Asks whether to continue the current workflow or replace it |
|
|
68
|
+
| Previous workflow is already `done` | Uses the proposal analyst to summarize recent discussion into the next workflow round, then asks for confirmation | Starts the next workflow round directly from the explicit goal |
|
|
69
|
+
|
|
70
|
+
## Startup proposal behavior
|
|
71
|
+
|
|
72
|
+
### `/cook <goal>`
|
|
73
|
+
|
|
74
|
+
When you provide an explicit goal:
|
|
75
|
+
|
|
76
|
+
- the explicit goal stays the mission anchor
|
|
77
|
+
- recent discussion is supplemental only
|
|
78
|
+
- recent discussion may enrich scope, constraints, and acceptance details when analyst output is available
|
|
95
79
|
|
|
96
|
-
|
|
80
|
+
Example:
|
|
97
81
|
|
|
98
82
|
```text
|
|
99
83
|
/cook Build feature X with tests and docs
|
|
100
84
|
```
|
|
101
85
|
|
|
102
|
-
|
|
86
|
+
### `/cook` without a goal
|
|
103
87
|
|
|
104
|
-
When you
|
|
88
|
+
When you do **not** provide a goal:
|
|
105
89
|
|
|
106
|
-
|
|
90
|
+
- `/cook` uses the proposal analyst to summarize recent discussion into a startup proposal
|
|
91
|
+
- the proposal is shown in a custom confirmation UI before canonical state is written
|
|
92
|
+
- if analyst output is unavailable, provide an explicit goal with `/cook <goal>`
|
|
93
|
+
|
|
94
|
+
Example:
|
|
107
95
|
|
|
108
96
|
```text
|
|
109
97
|
/cook
|
|
110
98
|
```
|
|
111
99
|
|
|
112
|
-
|
|
100
|
+
## Confirmation UI
|
|
113
101
|
|
|
114
|
-
|
|
102
|
+
Startup confirmation uses a custom UI that:
|
|
115
103
|
|
|
116
|
-
|
|
117
|
-
/
|
|
118
|
-
|
|
104
|
+
- renders the proposal body separately from the action list
|
|
105
|
+
- keeps Mission / Scope / Constraints / Acceptance readable as a content area
|
|
106
|
+
- presents explicit actions for:
|
|
107
|
+
- **Start**
|
|
108
|
+
- **Edit**
|
|
109
|
+
- **Cancel**
|
|
119
110
|
|
|
120
|
-
|
|
111
|
+
The same confirmation flow is reused across:
|
|
121
112
|
|
|
122
|
-
-
|
|
123
|
-
-
|
|
113
|
+
- discussion-only startup
|
|
114
|
+
- explicit-goal startup
|
|
115
|
+
- next-round startup after completion
|
|
116
|
+
- replacement-workflow startup
|
|
124
117
|
|
|
125
|
-
|
|
118
|
+
## Observability
|
|
126
119
|
|
|
127
|
-
|
|
120
|
+
When canonical `.agent/**` state exists and no role is actively running, the extension shows a completion widget sourced from that state. The widget summarizes:
|
|
128
121
|
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
122
|
+
- current phase
|
|
123
|
+
- selected slice
|
|
124
|
+
- next mandatory role
|
|
125
|
+
- remaining work counts
|
|
132
126
|
|
|
133
|
-
|
|
127
|
+
There is no completion status line.
|
|
134
128
|
|
|
135
|
-
|
|
129
|
+
While a `completion_role` subprocess is running:
|
|
136
130
|
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
131
|
+
- the non-running widget is suppressed
|
|
132
|
+
- tool activity is shown separately from assistant-reported progress
|
|
133
|
+
- running-role output distinguishes tool work from `PROGRESS`, `RATIONALE`, `NEXT`, `VERIFYING`, and `STATE-DELTA`
|
|
134
|
+
- waiting and stalled states are surfaced deterministically from timestamps
|
|
140
135
|
|
|
141
|
-
|
|
136
|
+
## Canonical files
|
|
142
137
|
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
This package manages repo-local canonical workflow state under:
|
|
138
|
+
This package stores canonical workflow state under:
|
|
146
139
|
|
|
147
140
|
```text
|
|
148
141
|
.agent/
|
|
@@ -159,43 +152,44 @@ This package manages repo-local canonical workflow state under:
|
|
|
159
152
|
tmp/
|
|
160
153
|
```
|
|
161
154
|
|
|
162
|
-
Canonical truth
|
|
155
|
+
Canonical truth is the combination of:
|
|
156
|
+
|
|
157
|
+
- current repo truth, and
|
|
158
|
+
- canonical `.agent/**` state
|
|
163
159
|
|
|
164
|
-
### Tracked vs ignored
|
|
160
|
+
### Tracked vs ignored files
|
|
165
161
|
|
|
166
|
-
|
|
162
|
+
Tracked repo-contract files:
|
|
167
163
|
|
|
168
|
-
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
- `.agent/verify_completion_control_plane.sh`
|
|
174
|
-
- **Ignored execution-state files** are local high-churn workflow state used for resume and recovery and should stay out of git:
|
|
175
|
-
- `.agent/state.json`
|
|
176
|
-
- `.agent/plan.json`
|
|
177
|
-
- `.agent/active-slice.json`
|
|
178
|
-
- `.agent/slice-history.jsonl`
|
|
179
|
-
- `.agent/stop-check-history.jsonl`
|
|
180
|
-
- `.agent/*.log`
|
|
181
|
-
- `.agent/tmp/`
|
|
164
|
+
- `.agent/README.md`
|
|
165
|
+
- `.agent/mission.md`
|
|
166
|
+
- `.agent/profile.json`
|
|
167
|
+
- `.agent/verify_completion_stop.sh`
|
|
168
|
+
- `.agent/verify_completion_control_plane.sh`
|
|
182
169
|
|
|
183
|
-
|
|
170
|
+
Ignored execution-state files:
|
|
184
171
|
|
|
185
|
-
|
|
172
|
+
- `.agent/state.json`
|
|
173
|
+
- `.agent/plan.json`
|
|
174
|
+
- `.agent/active-slice.json`
|
|
175
|
+
- `.agent/slice-history.jsonl`
|
|
176
|
+
- `.agent/stop-check-history.jsonl`
|
|
177
|
+
- `.agent/*.log`
|
|
178
|
+
- `.agent/tmp/`
|
|
186
179
|
|
|
187
|
-
|
|
180
|
+
In short:
|
|
188
181
|
|
|
189
|
-
|
|
182
|
+
- tracked `.agent` files define the repo-level workflow contract
|
|
183
|
+
- ignored `.agent` files are the local control-plane state for the current run
|
|
190
184
|
|
|
191
185
|
## Package layout
|
|
192
186
|
|
|
193
|
-
- `extensions/completion/index.ts` —
|
|
194
|
-
- `skills/completion-protocol/` — shared protocol
|
|
195
|
-
- `agents/completion-*.md` — package-local completion
|
|
196
|
-
- `scripts/` — smoke and release checks
|
|
187
|
+
- `extensions/completion/index.ts` — main extension implementation
|
|
188
|
+
- `skills/completion-protocol/` — shared protocol documentation
|
|
189
|
+
- `agents/completion-*.md` — package-local completion role prompts
|
|
190
|
+
- `scripts/` — smoke, regression, and release checks
|
|
197
191
|
|
|
198
|
-
## Development
|
|
192
|
+
## Development
|
|
199
193
|
|
|
200
194
|
Run validation from the package root:
|
|
201
195
|
|
|
@@ -207,13 +201,15 @@ npm run observability-status-test
|
|
|
207
201
|
npm run release-check
|
|
208
202
|
```
|
|
209
203
|
|
|
210
|
-
`npm run release-check` is the
|
|
204
|
+
`npm run release-check` is the broad packaged-release verifier. It reruns the startup/refocus/context checks, includes deterministic observability coverage, and finishes with `npm pack --dry-run`.
|
|
205
|
+
|
|
206
|
+
## Release
|
|
211
207
|
|
|
212
208
|
See [PUBLISHING.md](https://github.com/linimin/pi-letscook/blob/main/PUBLISHING.md) for GitHub and npm release steps.
|
|
213
209
|
|
|
214
210
|
## Notes
|
|
215
211
|
|
|
216
212
|
- Canonical truth lives in repo-local `.agent/**` files.
|
|
217
|
-
- The main
|
|
218
|
-
- Package-local role prompts are loaded directly by the extension
|
|
213
|
+
- The main Pi session is the workflow driver.
|
|
214
|
+
- Package-local role prompts are loaded directly by the extension and do not depend on `~/.pi/agent/agents`.
|
|
219
215
|
- Reviewer, auditor, and stop-judge are enforced as read-only roles.
|