pi-do-always 0.9.0 → 0.12.0

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/README.md CHANGED
@@ -11,26 +11,23 @@ type to filter, scroll or click, or navigate with arrows + Enter → the task's
11
11
  ```text
12
12
  do-always — pick a task
13
13
 
14
+ # TASK DESCRIPTION ORDER
14
15
  PLAN
15
- ▸ 1. ⚡ Review changes Review the current code changes (Plan)
16
- 2. ⚡ Review code Review the whole project's code quality (Plan)
17
- 3. ⚡ Cleanup Clean up dead code and duplicates (Plan)
18
- 4. ⚡ Security Security audit (Plan)
19
- 5. ⚡ Performance Performance review (Plan)
20
- 6. ⚡ Propose features Propose new features (Plan)
16
+ 1 ⚡ Review changes Review the current code changes (Plan) ·
17
+ 2 ⚡ Review code Review the whole project's code quality (Plan) [1]
18
+ 3 ⚡ Cleanup Clean up dead code and duplicates (Plan) [2]
19
+ 4 ⚡ Security Security audit (Plan) ·
20
+ 5 ⚡ Performance Performance review (Plan) ►[3]
21
+ 6 ⚡ Propose features Propose new features (Plan) ·
21
22
  DO
22
- 7. Build Test build is ok and fix issues
23
- 8. Tests Run tests and fix failures
23
+ 7 Build Test build is ok and fix issues ·
24
+ 8 Tests Run tests and fix failures ·
24
25
  DOCS
25
- 9. Readme Update the README.md
26
- OPS
27
- 10. Release Prepare a release (version, changelog, tag)
28
- 11. Commit Prepare a clean commit
26
+ 9 Readme Update the README.md ·
29
27
 
30
- Review changes — prompt:
31
- Review the changes on branch fix/login-null (3 changed files: auth.ts, login.ts,
32
- test/auth.test.ts). Last commit: Fix null check in login. Check `git status` and
33
- `git diff` to see what changed, then double-check the changes for bugs, edge …
28
+ ──────────────────────────────────────────────────────────────────────────────────────────────────
29
+ Run the chain (3)
30
+ ← tasks • ⏎ remove • esc • ctrl+u clear
34
31
 
35
32
  1-9 pick by number • type to filter • ↑↓ navigate • enter select • esc cancel • ⚡ auto-runs
36
33
  ```
@@ -59,6 +56,84 @@ not filled): the `Plan` category does this by default, and any task can opt in o
59
56
  In non-interactive modes (no TUI) there is no editor to fill, so the selected prompt is sent
60
57
  as a user message instead.
61
58
 
59
+ ## Chains
60
+
61
+ Run several tasks in a row as a **chain**. The selector shows an `ORDER` column; tasks in
62
+ the chain get a `[n]` marker in execution order, and a pinned row at the bottom of the
63
+ list runs the chain.
64
+
65
+ Building a chain in the selector:
66
+
67
+ - **Enter on a task row** runs just that task (the classic pick — the cursor starts in
68
+ the task column).
69
+ - **→** moves the cursor to the ORDER column on the same row, where **Enter** toggles
70
+ that task's chain membership (`·` → `[n]` → `·`). **←** goes back to the task column.
71
+ - **↑ / ↓** move the cursor in either column. The cursor is a **►** marker in the
72
+ theme's accent color: in the left gutter in the task column, in the ORDER cell in
73
+ the order column (plus a row highlight where your theme makes it visible). From the
74
+ last task row, **↓** lands on the pinned Run row (and **↑** back).
75
+ - **Enter on the `Run the chain (n)` row** — or a mouse click on it — runs the chain.
76
+ The row is dimmed while the chain is empty. The ► marker appears on it only
77
+ while the cursor is on the row (as on task rows).
78
+ - **Backspace** (with no filter typed) undoes the last add; **ctrl+u** clears the whole
79
+ chain; **Esc** cancels and discards it.
80
+ - Clicking an ORDER cell toggles the task's chain membership.
81
+ - The classic fast paths are unchanged: **1-9** runs a task immediately, and clicking a
82
+ task row runs it — both close the selector and discard the chain.
83
+
84
+ Chains are capped at 8 tasks. Reordering is done by removing a task and re-adding it. On narrow terminals the ORDER
85
+ column is dropped and the chain is shown on its own line below the list (keyboard
86
+ chaining still works).
87
+
88
+ Running a chain sends each step as its own turn, strictly one after another — the next
89
+ step starts only after the previous run has fully finished. Before anything is sent,
90
+ every step's guards are checked against the current state (fail fast: the first blocked
91
+ step is reported and the chain doesn't start). All steps share the prompt context
92
+ captured when the chain started, so each step's placeholders and guards see the tree as
93
+ it was at that point. An aborted step (Esc), a step that errors, or a step whose send
94
+ fails to start stops the chain; steps already run are kept.
95
+
96
+ If the first task of a chain is a fill task (no `⚡`) in the TUI, step 1 is put in the
97
+ editor and the rest of the chain starts automatically once you press Enter and that run
98
+ finishes.
99
+
100
+ While a chain is running, a **status widget** is shown below the prompt: the chain's
101
+ tasks with a marker per step and a `(n/N)` progress count — the step the chain is
102
+ currently at.
103
+
104
+ ```
105
+ ⛓ do-always (2/4)
106
+ ✓ Review changes
107
+ ▶ Build
108
+ ○ Test
109
+ ○ Deploy
110
+ ```
111
+
112
+ Markers: `✓` completed, `▶` running (or waiting for your Enter on a fill-first step 1),
113
+ `○` pending, `✗` errored / failed to start, `⊘` aborted, `–` skipped because its guards
114
+ no longer hold. The widget is removed when the chain completes; if the chain stops early
115
+ it stays below the prompt as a trace of where it stopped (until your next prompt or a new
116
+ session). Starting a second chain while
117
+ one is running is refused — wait for it to finish or abort the current step with Esc.
118
+
119
+ Every chain run also writes a **report file** in the project root —
120
+ `do-always-report-tasks-YYYY-MM-DD-HHMM.md` (e.g. `do-always-report-tasks-2025-01-15-1432.md`) —
121
+ so earlier steps' results are not lost when later steps' output scrolls them off screen.
122
+ Each step appends a section as it finishes (the step's final assistant message, with its
123
+ outcome and run time), so the file is complete even if the session dies mid-chain; a
124
+ footer with the overall summary is appended when the chain ends, and the completion
125
+ notification carries the file's path. A run that produces nothing worth keeping (no
126
+ completed step and no step result text — e.g. step 1 errors before any output) leaves no
127
+ file behind. Set `"report": false` in the config to disable
128
+ it (the project file's value wins over the global one). See [Report file](#report-file).
129
+
130
+ **Inline report.** When a chain completes fully (all steps done), the full Markdown
131
+ report opens in an editor view so you can read the results without opening the file —
132
+ press Esc to dismiss it. Nothing is persisted to the session: the report lives only in
133
+ that view and in the report file on disk. A run that stops early (aborted, errored, or
134
+ skipped steps) does not show the inline report — only the status trace widget below
135
+ the prompt.
136
+
62
137
  ## Install
63
138
 
64
139
  Install it from npm as a Pi package, which loads the bundled `index.ts` (and its `tasks.ts`) without
@@ -117,6 +192,7 @@ In the object form you can also configure the selector shortcut:
117
192
 
118
193
  - `shortcut` (optional) — key that opens the selector, e.g. `"f4"`. Set to `null` to disable the shortcut. Defaults to `F4`. The project file's value wins over the global one.
119
194
  - `merge` (optional) — how project tasks combine with the global tasks: `"override"` (default) replaces a global task with the same `name`; `"append"` keeps the global tasks and only adds new project task names (a cascade, like CSS). The project file's value wins over the global one; when neither sets it, the default is `override` (the historical behavior).
195
+ - `report` (optional) — whether chain runs write a Markdown report file in the project root (one per run, appended as each step finishes). Default `true`; set `false` to disable. The project file's value wins over the global one. See [Chains](#chains).
120
196
 
121
197
  Example project file that only *adds* tasks without overriding the global set:
122
198
 
@@ -6,7 +6,7 @@
6
6
  "category": "Plan",
7
7
  "description": "Review the current code changes (Plan)",
8
8
  "requireDirty": true,
9
- "prompt": "Review the changes on branch {{branch}} ({{files_changed_count}} changed files: {{files_changed}}). Change summary: {{diff_stat}}. Last commit: {{last_commit}}. Check `git status` and `git diff` to see what changed, then double-check the changes for bugs, edge cases, security issues, and consistency with the rest of the codebase. Do a plan proposal for the fixes if needed. Do a summary of your findings"
9
+ "prompt": "Review the changes on branch {{branch}} ({{files_changed_count}} changed files: {{files_changed}}). Change summary: {{diff_stat}}. Last commit: {{last_commit}}. Check `git status` and `git diff` to see what changed, then double-check the changes for bugs, edge cases, security issues, and consistency with the rest of the codebase. Do a plan proposal for the fixes if needed. Do a summary of your findings."
10
10
  },
11
11
  {
12
12
  "name": "Review code",
@@ -36,7 +36,7 @@
36
36
  "name": "Propose features",
37
37
  "category": "Plan",
38
38
  "description": "Propose new features (Plan)",
39
- "prompt": "Review this project and propose new features that would add value. For each idea, describe the problem it solves, the user benefit, and a rough implementation approach. Prioritize by impact and effort. Do not make any changes yet. Try to evaluate how many lines this will be in term of changes, if this will breaks API, compatibility issue."
39
+ "prompt": "Review this project and propose new features that would add value. For each idea, describe the problem it solves, the user benefit, and a rough implementation approach. Prioritize by impact and effort. Do not make any changes yet. Try to evaluate how many lines this will be in terms of changes, whether this will break APIs, or introduce compatibility issues."
40
40
  },
41
41
  {
42
42
  "name": "Build",