trekoon 0.4.5 → 0.4.6

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.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: trekoon
3
- description: "Use for Trekoon-based planning and execution: creating epics, tasks, and subtasks; breaking work into dependency-aware graphs; checking status and progress; planning backlog or sprint work; and coordinating agent execution from Trekoon. Prefer this whenever the user wants tracked implementation planning or Trekoon entity management, even if they do not explicitly say \"Trekoon\"."
3
+ description: "Use for Trekoon-based planning and execution: epics, tasks, subtasks, dependency-aware graphs, status and progress, sprint or backlog work, and agent execution. Prefer whenever the user wants tracked implementation planning or Trekoon entity management, even if they do not say Trekoon."
4
4
  ---
5
5
 
6
6
  # Trekoon Skill
@@ -12,17 +12,15 @@ them.
12
12
 
13
13
  ## Mode Contracts
14
14
 
15
- - `trekoon plan <goal>`: create an execution-ready epic in Trekoon.
16
- - `trekoon <id>`: orient on the epic/task/subtask and report current state,
17
- blockers, and next action.
18
- - `trekoon <id> execute`: own the epic until it is done, hard-blocked, or needs
19
- user input. Use subagents by default for meaningful work that can run
20
- independently when the harness exposes them.
21
- - `trekoon <id> team execute`: same completion contract, using Claude Agent
22
- Teams only when the user explicitly asks and the environment supports it.
15
+ - `trekoon plan <goal>`: create an execution-ready epic.
16
+ - `trekoon <id>`: orient on the epic/task/subtask; report state, blockers, next.
17
+ - `trekoon <id> execute`: own the epic until done, hard-blocked, or needs user
18
+ input. Use subagents by default for meaningful independent work.
19
+ - `trekoon <id> team execute`: same contract, using Claude Agent Teams only
20
+ when the user explicitly asks and the environment supports it.
23
21
 
24
- Do not stop at analysis when Trekoon shows ready work. Do not invent a parallel
25
- plan outside Trekoon.
22
+ Do not stop at analysis when ready work exists. Do not invent a parallel plan
23
+ outside Trekoon.
26
24
 
27
25
  ## Load Rules
28
26
 
@@ -30,29 +28,36 @@ plan outside Trekoon.
30
28
  |---|---|
31
29
  | Any Trekoon request | This file |
32
30
  | Plan, break down, design tracked work | `reference/harness-primitives.md`, then `reference/planning.md` |
33
- | Execute, implement, complete tracked work | `reference/harness-primitives.md`, then `reference/execution.md` |
34
- | User explicitly asks for Claude team execution | `reference/harness-primitives.md`, then `reference/execution-with-team.md` |
31
+ | Execute, implement, complete tracked work | `reference/harness-primitives.md`, then `reference/execution.md` (Team appendix at end) |
35
32
  | Sync gaps, conflicts, shared-storage questions | `reference/sync.md` |
36
33
  | Status transition error or status uncertainty | `reference/status-machine.md` |
37
34
 
38
- `reference/harness-primitives.md` is required before planning or execution
39
- because those modes may need local task displays, user questions, subagents,
40
- review agents, testing tools, and Trekoon evidence recording.
35
+ `reference/harness-primitives.md` is required before planning or execution; it
36
+ holds the canonical claim/append/finish recipe, harness runtime notes, local
37
+ task tool rules, and review guidance.
41
38
 
42
39
  ## Route Input
43
40
 
44
- Resolve the first non-mode argument as an epic, task, or subtask:
41
+ Resolve the first non-mode argument as an epic, task, or subtask in one call:
45
42
 
46
43
  ```bash
44
+ trekoon --toon session --item <id>
45
+ ```
46
+
47
+ Returns `kind` (`epic`|`task`|`subtask`), `parentEpicId`, the entity payload,
48
+ epic-scoped readiness, and `suggestedNext`. Use this instead of the legacy
49
+ three-call fallback:
50
+
51
+ ```bash
52
+ # Legacy fallback (kept working, but burns ~3x the tokens):
47
53
  trekoon --toon epic show <id> 2>/dev/null || \
48
54
  trekoon --toon task show <id> 2>/dev/null || \
49
55
  trekoon --toon subtask show <id> 2>/dev/null
50
56
  ```
51
57
 
52
- If the ID is a task or subtask, resolve its parent epic and scope `session`,
53
- `suggest`, and `epic progress` to that epic. If the user asked to execute a task
54
- or subtask, start with that item; continue broader epic execution only when it
55
- matches the user intent.
58
+ If the ID is a task or subtask, scope `suggest` and `epic progress` to its
59
+ `parentEpicId`. If the user asked to execute that item, start with it;
60
+ continue broader epic execution only when it matches the user intent.
56
61
 
57
62
  | User signal | Mode |
58
63
  |---|---|
@@ -74,21 +79,18 @@ matches the user intent.
74
79
 
75
80
  ## Execution Defaults
76
81
 
77
- - Start with `trekoon --toon session`; scope with `--epic <id>` when known.
82
+ - Start with `session`; scope with `--epic <id>` when known.
78
83
  - If ready work exists, keep moving. After each `task done`, inspect
79
84
  `unblocked`, `warning`/`openSubtaskIds`, and `next`.
80
- - When executing an epic, use subagents by default for any meaningful work that
81
- can run independently. Keep small or tightly coupled tasks in the parent
82
- agent.
85
+ - When executing an epic, use subagents by default for meaningful independent
86
+ work. Keep small or tightly coupled tasks in the parent agent.
83
87
  - Use your context for orchestration, dependency decisions, user communication,
84
88
  and final synthesis. Your job is to finish the epic, not personally perform
85
89
  every implementation step.
86
90
  - If a higher-priority harness rule blocks subagents without explicit user
87
- wording, ask immediately and explain that Trekoon execution preserves the
88
- parent context for orchestration.
89
- - For non-trivial implementation, run relevant tests and a separate review pass
90
- when a review agent/skill is available. Record checks and review results in
91
- Trekoon before closing work.
91
+ wording, ask immediately.
92
+ - For non-trivial implementation, run relevant tests and a separate review pass.
93
+ Record checks and review results in Trekoon before closing work.
92
94
 
93
95
  ## Non-Negotiables
94
96
 
@@ -113,15 +115,14 @@ matches the user intent.
113
115
 
114
116
  ## Status Reminder
115
117
 
116
- Normal status flow is `todo -> in_progress -> done`; `blocked` requires an
117
- appended reason. Use `task done` for task completion because it auto-transitions
118
- from `todo` or `blocked` through `in_progress`. Load
119
- `reference/status-machine.md` for transition errors or uncertainty. For
120
- subtasks, claim or move through `in_progress` before marking `done`.
118
+ `task done` auto-transitions from `todo` or `blocked` through `in_progress`,
119
+ so prefer it for completion. Subtasks must claim or move through `in_progress`
120
+ before `done`. Load `reference/status-machine.md` for transition errors or
121
+ uncertainty.
121
122
 
122
123
  ## Recovery
123
124
 
124
- If Trekoon diagnostics show `recoveryRequired`, stop task selection and run:
125
+ If diagnostics show `recoveryRequired`, stop task selection and run:
125
126
 
126
127
  ```bash
127
128
  trekoon --toon init
@@ -1,17 +1,20 @@
1
1
  # Execution Reference
2
2
 
3
3
  You are an orchestrator. Execute work from Trekoon, not markdown plan files.
4
- Execution is complete only when the epic is marked `done`, all remaining work is
5
- blocked with recorded reasons, or real user input is required.
4
+ Execution is complete only when the epic is `done`, all remaining work is
5
+ `blocked` with recorded reasons, or real user input is required.
6
6
 
7
- When executing an epic, use subagents by default for any meaningful work that
8
- can run independently. Keep small or tightly coupled tasks in the parent agent.
9
- Use your context for orchestration, dependency decisions, user communication,
10
- and final synthesis.
7
+ Use subagents by default for meaningful independent work. Keep small or tightly
8
+ coupled tasks in the parent. Use your context for orchestration, dependency
9
+ decisions, user communication, and synthesis.
11
10
 
12
11
  If the plan has unclear requirements or meaningful tradeoffs, ask before
13
12
  starting. Do not stop at status reporting when ready work exists.
14
13
 
14
+ The atomic-claim, append-progress, and `task done` recipes live in
15
+ `reference/harness-primitives.md`. This file references them rather than
16
+ restating.
17
+
15
18
  ## Choose Shape
16
19
 
17
20
  - Direct work: one ready task, tiny change, narrow scope, or tightly coupled
@@ -79,40 +82,28 @@ Scope:
79
82
  - Read first: <paths/patterns to inspect before editing>
80
83
  - Do not touch: <paths owned by other lanes>
81
84
 
82
- Before each task:
83
- - trekoon --toon task claim <id> --owner <lane-name>
84
- - trekoon --toon task update <id> --append "Starting implementation"
85
-
86
- While working:
87
- - Complete required subtasks and update subtask statuses.
88
- - Append meaningful progress notes; do not rewrite task descriptions.
89
- - Respect status flow: todo -> in_progress -> done. Use task done for task
90
- completion; for subtasks, claim or move through in_progress before done.
91
- - Assume other agents may edit unrelated files. Do not revert unrelated changes.
85
+ For each task use the atomic-claim + append-progress recipe in
86
+ reference/harness-primitives.md:
87
+ - claim with --owner <lane-name>
88
+ - append progress, verification, and blockers; do not rewrite descriptions
89
+ - task done on completion; for subtasks move through in_progress first
90
+ - on block: append reason + dependency id + failing command output, then
91
+ --status blocked
92
92
 
93
- On completion:
94
- - Append verification evidence.
95
- - trekoon --toon task done <id>
96
- - Read and report unblocked tasks, open subtask warnings, and next candidate.
97
- - For non-trivial code changes, report review result or review gap.
93
+ Assume other agents may edit unrelated files. Do not revert unrelated changes.
98
94
 
99
- If blocked:
100
- - Append blocker reason, dependency id, and exact failing command/output.
101
- - trekoon --toon task update <id> --append "Blocked by <reason>" --status blocked
95
+ Claude Code parallel tool calls:
96
+ - Parallel Trekoon Bash calls must stay read-only (session, progress, ready,
97
+ suggest, targeted show).
98
+ - Do not issue multiple status-changing Bash commands in one parallel batch.
99
+ Use task/subtask claim for atomic races, then serialize updates and
100
+ completion commands.
101
+ - If a parallel batch reports sibling cancellation, re-read the affected task
102
+ before retrying; recover from current Trekoon state.
102
103
 
103
104
  Use --compact in noisy Trekoon reads. Do not create branches, commits, pushes,
104
105
  or PRs unless the user explicitly asked and harness policy allows it.
105
106
 
106
- Claude Code parallel tool calls:
107
- - Parallel Trekoon Bash calls are for read-only commands such as session,
108
- progress, ready, suggest, and targeted show.
109
- - Do not issue multiple Trekoon status-changing Bash commands in one parallel
110
- tool batch. Use task/subtask claim for atomic races, then serialize updates
111
- and completion commands.
112
- - If a parallel batch reports sibling cancellation, re-read the affected task or
113
- subtask before retrying; recover from current Trekoon state, not the cancelled
114
- command text.
115
-
116
107
  Final report: tasks completed, files changed, checks, review result/gap,
117
108
  task done response, blockers.
118
109
  ```
@@ -144,26 +135,13 @@ lanes are already delegated.
144
135
  2. If diagnostics show `recoveryRequired`, stop and run `trekoon --toon init`.
145
136
  3. If behind or conflicts exist, resolve sync before claiming work. Load
146
137
  `reference/sync.md` for conflict handling.
147
- 4. Claim:
148
- ```bash
149
- trekoon --toon task claim <task-id> --owner <name>
150
- ```
151
- 5. Work and append notes:
152
- ```bash
153
- trekoon --toon task update <task-id> --append "Started implementation"
154
- ```
155
- 6. Update important subtasks explicitly:
138
+ 4. Claim, append, finish per the recipe in `reference/harness-primitives.md`.
139
+ 5. Update important subtasks explicitly:
156
140
  ```bash
157
141
  trekoon --toon subtask claim <subtask-id> --owner <name>
158
142
  trekoon --toon subtask update <subtask-id> --append "Verified with fixture set" --status done
159
143
  ```
160
- 7. Finish or block:
161
- ```bash
162
- trekoon --toon task update <task-id> --append "Completed implementation and checks"
163
- trekoon --toon task done <task-id>
164
- trekoon --toon task update <task-id> --append "Blocked by <reason>" --status blocked
165
- ```
166
- 8. Repeat from the returned `unblocked`/`next` data. A fresh `session` is not
144
+ 6. Repeat from the returned `unblocked`/`next` data. A fresh `session` is not
167
145
  needed mid-loop unless you need updated diagnostics or switch epics.
168
146
 
169
147
  If `task done` warns about open subtasks, decide whether the task is genuinely
@@ -195,27 +173,21 @@ All applicable checks must pass before marking the epic done.
195
173
  ### Review
196
174
 
197
175
  For non-trivial implementation, run a separate review pass before closing the
198
- task or epic. Prefer a specialized review agent/skill when available. Review
199
- the actual diff for correctness, regressions, missing tests, security,
200
- reliability, performance, and integration risks. Tiny docs/mechanical changes
201
- may skip separate review, but record that decision.
202
-
203
- ### Tests and Manual Checks
204
-
205
- - Run the relevant automated tests for touched scope.
206
- - Run broader tests when shared behavior, cross-module contracts, or user flows
207
- changed.
208
- - Exercise CLI/API/parser/integration changes with realistic inputs when
209
- possible.
176
+ task or epic. Prefer a specialized review agent/skill. Review the diff for
177
+ correctness, regressions, missing tests, security, reliability, performance,
178
+ and integration risks. Tiny docs/mechanical changes may skip separate review
179
+ but record that decision.
180
+
181
+ ### Tests And Manual Checks
182
+
183
+ - Run relevant automated tests for touched scope.
184
+ - Run broader tests when shared behavior or cross-module contracts changed.
185
+ - Exercise CLI/API/parser/integration changes with realistic inputs.
210
186
  - Record gaps when credentials or external services are unavailable.
211
187
  - Fix confusing errors, noisy output, inconsistent behavior, or rough DX.
212
188
 
213
- Append evidence:
214
-
215
- ```bash
216
- trekoon --toon task update <task-id> --append "Verified: <commands/results>"
217
- trekoon --toon task update <task-id> --append "Review: <result or accepted gap>"
218
- ```
189
+ Append evidence with the `task update --append` recipe in
190
+ `reference/harness-primitives.md`.
219
191
 
220
192
  ## Close The Epic
221
193
 
@@ -238,7 +210,7 @@ remaining blockers, and dependency state.
238
210
 
239
211
  ## Update And Read Policies
240
212
 
241
- Use descriptions as the durable work log. Append progress instead of rewriting
213
+ Descriptions are the durable work log. Append progress instead of rewriting
242
214
  descriptions unless the plan itself is wrong.
243
215
 
244
216
  Preferred commands:
@@ -265,3 +237,35 @@ Bulk updates:
265
237
  - `--append` and `--description` are mutually exclusive.
266
238
  - Use `--all` only for clear maintenance sweeps or when the user explicitly
267
239
  wants broad updates.
240
+
241
+ ## Claude Agent Teams (Appendix)
242
+
243
+ Use this section only when the user explicitly asks for Claude Code Agent
244
+ Teams and `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true`. Otherwise use the
245
+ standard subagent flow above.
246
+
247
+ Team-specific surface:
248
+
249
+ | Purpose | Tool |
250
+ |---|---|
251
+ | Create team | `TeamCreate` |
252
+ | Manage shared tasks | `TaskCreate` / `TaskList` / `TaskUpdate` / `TaskGet` |
253
+ | Spawn teammates | `Agent` with `team_name` |
254
+ | Communicate | `SendMessage` |
255
+ | Clean up | `TeamDelete` |
256
+
257
+ Flow:
258
+
259
+ 1. Build the graph and mark the epic in progress per the standard flow.
260
+ 2. `TeamCreate` with name `<epic-slug>` and a description naming the epic.
261
+ 3. One `TaskCreate` per lane. Reuse the standard subagent prompt body
262
+ (claim, append, task done, blocker handling). Use `blockedBy` for
263
+ sequential lanes.
264
+ 4. `Agent` with `team_name` to spawn one teammate per parallel lane.
265
+ Use `general-purpose`; reserve `Explore`/`Plan` for read-only research.
266
+ Use 3-5 teammates for most epics.
267
+ 5. Coordinate via `SendMessage`. Update Trekoon owners with
268
+ `task update <task-id> --owner <teammate-name>`. When all teammates
269
+ block, run `suggest --epic <epic-id>`.
270
+ 6. Close the epic per the standard flow. Then `shutdown_request` each
271
+ teammate and `TeamDelete`.
@@ -78,3 +78,40 @@ checks and record the review gap or decision:
78
78
  ```bash
79
79
  trekoon --toon task update <task-id> --append "Review: <summary or accepted gap>"
80
80
  ```
81
+
82
+ ## Atomic Claim And Append-Progress Recipe
83
+
84
+ Canonical recipe for owning a Trekoon item and recording progress. Other
85
+ references point here instead of restating these commands.
86
+
87
+ Atomic claim before editing:
88
+
89
+ ```bash
90
+ trekoon --toon task claim <task-id> --owner <name>
91
+ trekoon --toon subtask claim <subtask-id> --owner <name>
92
+ ```
93
+
94
+ `task claim` races safely across parallel subagents; the loser sees the
95
+ existing owner. `task update --status in_progress` does not race; prefer
96
+ `claim` for ownership transitions.
97
+
98
+ Append progress, verification, blocker notes:
99
+
100
+ ```bash
101
+ trekoon --toon task update <task-id> --append "Started implementation"
102
+ trekoon --toon task update <task-id> --append "Verified: <commands/results>"
103
+ trekoon --toon task update <task-id> --append "Review: <result or accepted gap>"
104
+ trekoon --toon task update <task-id> --append "Blocked by <reason>" --status blocked
105
+ ```
106
+
107
+ Append, do not rewrite descriptions. Use `--ids <csv>` for bulk append; bulk
108
+ mode supports only `--append` and/or `--status`.
109
+
110
+ Finish:
111
+
112
+ ```bash
113
+ trekoon --toon task done <task-id>
114
+ ```
115
+
116
+ `task done` auto-walks `todo` or `blocked` through `in_progress`. For subtasks,
117
+ move through `in_progress` (claim or status) before `done`.
@@ -94,29 +94,25 @@ Can run in parallel with: billing-lane. Blocked by: task-types.
94
94
 
95
95
  ## Design For Delegated Execution
96
96
 
97
- Plan so meaningful independent work can run in subagents:
98
-
99
97
  - Tasks with no dependency edge are parallel candidates.
100
98
  - Different subsystems usually become different lanes.
101
99
  - Same subsystem work should usually be grouped or sequenced.
102
- - Keep each active subsystem lane to about 3-4 tasks.
103
- - Add owners after creation when lanes are clear:
100
+ - Keep each active lane to about 3-4 tasks.
101
+ - Add owners after creation:
104
102
  ```bash
105
- trekoon --toon task update <task-id> --owner auth-lane
106
- trekoon --toon task update <task-id> --owner billing-lane
103
+ trekoon --toon task update <task-id> --owner <lane-name>
107
104
  ```
108
105
 
109
- Use dependencies only for hard prerequisites. Prefer task-to-task dependencies.
110
- Use subtask dependencies only when task-level ordering is too coarse.
106
+ Use dependencies for hard prerequisites only. Prefer task-to-task; use subtask
107
+ dependencies only when task-level ordering is too coarse.
111
108
 
112
109
  ## Create Records Efficiently
113
110
 
114
- Use `--toon` on every planning command. It saves tokens and gives agents a
115
- stable structured response.
111
+ Use `--toon` on every planning command for stable structured responses.
116
112
 
117
- Prefer one transactional planning command over repeated single-item creates. If
118
- you know the epic, tasks, subtasks, and dependencies, one-shot the whole epic
119
- with `epic create --task ... --subtask ... --dep ...`. This saves tool calls and
113
+ Prefer one transactional command over repeated single-item creates. If the
114
+ epic, tasks, subtasks, and dependencies are known, one-shot with
115
+ `epic create --task ... --subtask ... --dep ...`. This saves tool calls and
120
116
  keeps the graph internally consistent.
121
117
 
122
118
  | Situation | Command |
@@ -138,24 +134,19 @@ Compact specs use pipe-delimited values. `\` is the escape character:
138
134
  | `\r` | carriage return |
139
135
  | `\t` | tab |
140
136
 
141
- Any other `\X` is invalid. Do not paste regex-escaped or shell-escaped
142
- patterns directly into compact specs: sequences like `\?`, `\.`, `\{`, `\}`,
143
- `\(`, `\)`, `\[`, and `\]` will fail before records are created. When a task
144
- description needs a search pattern, prefer prose over exact regex syntax. Avoid
145
- operators like `!=` in descriptions because shell or compact-spec escaping can
146
- be confusing; rephrase as words.
137
+ Any other `\X` is invalid. Do not paste regex/shell-escaped patterns into
138
+ compact specs: `\?`, `\.`, `\{`, `\(`, `\[` etc. fail before records are
139
+ created. Prefer prose over exact regex in descriptions. Rephrase operators
140
+ like `!=` as words to avoid escaping confusion.
147
141
 
148
- Good:
142
+ Spec shape (status optional, defaults to `todo`):
149
143
 
150
- ```text
151
- Verify: search docs for currentUpdatedAt, updatedAt-ms, SSE auth token rides, and token query contract text.
152
- ```
144
+ - `--task <temp-key>|<title>|<description>` or `<temp-key>|<title>|<description>|<status>`
145
+ - `--subtask <temp-key>|<title>|<description>` or `<temp-key>|<title>|<description>|<status>` (subtask create-many)
146
+ - `--subtask <parent-ref>|<temp-key>|<title>|<description>` or `<parent-ref>|<temp-key>|<title>|<description>|<status>` (epic create/expand)
153
147
 
154
- Bad:
155
-
156
- ```text
157
- Verify: search with regex "currentUpdatedAt|<updatedAt-ms>|/api/snapshot/stream\?token|\?token=\{token\}" in docs and README.md
158
- ```
148
+ Prefer the shorter form. Pass an explicit `|<status>` only when seeding a
149
+ non-`todo` status.
159
150
 
160
151
  One-shot rules:
161
152
 
@@ -167,51 +158,41 @@ One-shot rules:
167
158
  handoff summaries and follow-up updates. Never show temp keys as real IDs.
168
159
  - `dep add-many` does not resolve temp keys from earlier commands. Use real IDs.
169
160
 
170
- One-shot example:
161
+ One-shot example (status omitted, defaults to `todo`):
171
162
 
172
163
  ```bash
173
164
  trekoon --toon epic create \
174
165
  --title "Checkout: add idempotent payment capture" \
175
166
  --description "Goal: prevent duplicate charges.\nVerification: bun test tests/payments" \
176
- --task "task-api|[API] add capture endpoint|Target files: src/payments/capture.ts\nRead first: src/payments/service.ts\nDo not touch: src/ui/*\nAcceptance: duplicate request returns prior result.\nVerify: bun test tests/payments/capture.test.ts\nOwner: api-lane\nCan run in parallel with: task-ui.|todo" \
177
- --task "task-ui|[UI] show capture states|Target files: src/ui/checkout.tsx\nRead first: src/ui/form.tsx\nDo not touch: src/payments/*\nAcceptance: loading and retry states render.\nVerify: bun test tests/ui/checkout.test.ts\nOwner: ui-lane\nBlocked by: task-api.|todo" \
178
- --subtask "@task-api|sub-api-tests|Write capture tests|Cover idempotent retry and conflict responses.|todo" \
179
- --subtask "@task-ui|sub-ui-states|Write UI state tests|Cover loading, success, retry, and error states.|todo" \
167
+ --task "task-api|[API] add capture endpoint|Target files: src/payments/capture.ts\nRead first: src/payments/service.ts\nDo not touch: src/ui/*\nAcceptance: duplicate request returns prior result.\nVerify: bun test tests/payments/capture.test.ts\nOwner: api-lane\nCan run in parallel with: task-ui." \
168
+ --task "task-ui|[UI] show capture states|Target files: src/ui/checkout.tsx\nRead first: src/ui/form.tsx\nDo not touch: src/payments/*\nAcceptance: loading and retry states render.\nVerify: bun test tests/ui/checkout.test.ts\nOwner: ui-lane\nBlocked by: task-api." \
169
+ --subtask "@task-api|sub-api-tests|Write capture tests|Cover idempotent retry and conflict responses." \
170
+ --subtask "@task-ui|sub-ui-states|Write UI state tests|Cover loading, success, retry, and error states." \
180
171
  --dep "@task-ui|@task-api"
181
172
  ```
182
173
 
183
174
  ## Append Efficiently
184
175
 
185
- Use `--append` for progress notes, shared findings, verification requirements,
186
- or planning refinements. Appending is cheaper and safer than rewriting full
187
- descriptions.
188
-
189
- Entity-specific append:
176
+ Use the append-progress recipe from `reference/harness-primitives.md` for
177
+ planning notes, shared findings, verification, or refinements. Appending is
178
+ cheaper and safer than rewriting full descriptions.
190
179
 
191
- ```bash
192
- trekoon --toon epic update <epic-id> --append "Planning note: <text>"
193
- trekoon --toon task update <task-id> --append "Planning note: <text>"
194
- trekoon --toon subtask update <subtask-id> --append "Planning note: <text>"
195
- ```
196
-
197
- Append to selected tasks or subtasks with IDs from `result.mappings`:
180
+ Bulk append uses IDs from `result.mappings`, `epic show --all`, or
181
+ `task ready`:
198
182
 
199
183
  ```bash
200
184
  trekoon --toon task update --ids id1,id2,id3 --append "Shared verification: bun test tests/payments"
201
- trekoon --toon subtask update --ids id1,id2 --append "Shared note: follow capture endpoint contract"
202
185
  ```
203
186
 
204
187
  Important:
205
188
 
206
189
  - `epic update <epic-id> --append ...` appends only to the epic description.
207
- - There is no scoped "append to all tasks in this epic" command. Use task IDs
208
- from one-shot mappings, `epic show --all`, or `task ready`, then
209
- `task update --ids ... --append ...`.
190
+ - There is no scoped "append to all tasks in this epic" command.
210
191
  - Do not use `task update --all --append ...` unless you truly mean every task
211
192
  in the database.
212
193
  - `epic update <epic-id> --all` is cascade status mode only and rejects
213
194
  `--append`.
214
- - Bulk append is per-row, not one atomic transaction.
195
+ - Bulk append is per-row, not atomic.
215
196
 
216
197
  ## Validate Before Handoff
217
198
 
@@ -234,15 +215,11 @@ Verify:
234
215
 
235
216
  ## Handoff Summary
236
217
 
237
- Do not stop at a prose-only design. Return the actual Trekoon epic and first
238
- execution wave.
239
-
240
- Rules:
218
+ Return the actual Trekoon epic and first execution wave, not prose-only design.
241
219
 
242
- - Always use full UUIDs for epic/task IDs in summaries.
243
- - Never use temp keys (`task-api`, `@sub-tests`) outside create commands.
220
+ - Full UUIDs in summaries; never temp keys outside create commands.
244
221
  - Render IDs in code formatting.
245
- - Group tasks by wave with title, owner/lane, and dependencies.
222
+ - Group tasks by wave with title, owner/lane, dependencies.
246
223
  - Include final verification gate.
247
224
 
248
225
  Format:
@@ -266,16 +243,9 @@ Verification: bun run build && bun run test
266
243
 
267
244
  ## Search And Replace
268
245
 
269
- Use scoped search before manual tree reads when locating repeated paths, labels,
270
- owners, or migration targets.
271
-
272
- Narrowest valid scope first:
273
-
274
- 1. `subtask search` / `subtask replace`
275
- 2. `task search` / `task replace`
276
- 3. `epic search` / `epic replace`
277
-
278
- Workflow:
246
+ Use scoped search before manual tree reads for repeated paths, labels, owners,
247
+ or migration targets. Narrowest scope first:
248
+ `subtask search`/`replace`, then `task`, then `epic`.
279
249
 
280
250
  ```bash
281
251
  trekoon --toon epic search <epic-id> "path/to/somewhere"
package/README.md CHANGED
@@ -194,6 +194,33 @@ Trekoon enforces valid transitions. You can't skip straight from `todo` to
194
194
  Exception: `task done` auto-transitions through `in_progress`, so agents can
195
195
  call it from any non-done status.
196
196
 
197
+ ## Storage and durability
198
+
199
+ Trekoon stores all state in `.trekoon/trekoon.db` (SQLite, WAL mode). The
200
+ database file lives outside the git object store; never commit it. Open-time
201
+ PRAGMAs are tuned for read+write throughput:
202
+
203
+ - `journal_mode = WAL` — required for concurrent readers + a single writer.
204
+ - `synchronous = NORMAL` — paired with WAL per the
205
+ [SQLite recommendation](https://www.sqlite.org/wal.html#performance_considerations).
206
+ On a hard kernel/OS crash, the last few unfsynced transactions may be lost,
207
+ but the database file itself never corrupts. To restore the pre-tuning
208
+ behaviour (`synchronous = FULL`), set `TREKOON_SQLITE_DURABILITY=full`
209
+ before invoking any `trekoon` command.
210
+ - `temp_store = MEMORY`, `mmap_size = 256 MiB`, `wal_autocheckpoint = 1000` —
211
+ keep hot reads in-process and bound the WAL size under sustained writes.
212
+ - `cache_size` — defaults to 64 MiB per connection. Override with
213
+ `TREKOON_SQLITE_CACHE_MIB=<N>` (non-negative integer). In daemon mode
214
+ (`trekoon serve`) up to 16 connections may be cached simultaneously, so
215
+ peak page-cache usage approaches `CACHED_DATABASES_CAPACITY × cache_size`
216
+ (e.g. 16 × 64 MiB = 1 GiB at the default). Lower `TREKOON_SQLITE_CACHE_MIB`
217
+ when memory is constrained (e.g. `TREKOON_SQLITE_CACHE_MIB=16` → 256 MiB
218
+ total for a 16-handle daemon).
219
+
220
+ These pragmas apply per open connection. Recovery path on suspected
221
+ corruption: `trekoon migrate backup`, then copy a known-good backup over
222
+ `.trekoon/trekoon.db`.
223
+
197
224
  ## Local board
198
225
 
199
226
  Trekoon includes a browser-based board for humans who like having a visual
@@ -224,6 +251,7 @@ shell, worktree, or browser tab show up live without a manual refresh.
224
251
  | Create tasks in bulk | `trekoon task create-many ...` |
225
252
  | Add dependencies | `trekoon dep add-many ...` |
226
253
  | Start an agent session | `trekoon session --epic <id>` |
254
+ | Resolve any epic/task/subtask id | `trekoon session --item <id>` |
227
255
  | Get next-action suggestions | `trekoon suggest --epic <id>` |
228
256
  | Check epic progress | `trekoon epic progress <id>` |
229
257
  | Export epic to Markdown | `trekoon epic export <id>` |
package/docs/commands.md CHANGED
@@ -10,7 +10,7 @@ the quickest way to get started, read [Quickstart](quickstart.md) first.
10
10
  - `trekoon help [command]`
11
11
  - `trekoon quickstart`
12
12
  - `trekoon epic <create|expand|list|show|search|replace|update|delete|progress>`
13
- - `trekoon session [--epic <epic-id>]`
13
+ - `trekoon session [--epic <epic-id>] [--item <id>]`
14
14
  - `trekoon suggest [--epic <epic-id>]`
15
15
  - `trekoon task <create|create-many|list|show|ready|next|done|search|replace|update|delete|claim>`
16
16
  - `trekoon subtask <create|create-many|list|search|replace|update|delete|claim>`
@@ -94,11 +94,11 @@ Board mutations from any source — board UI, CLI in another shell, or another
94
94
  worktree — propagate to every connected client through the SSE stream. The CLI
95
95
  side is driven by a WAL-watcher that diffs the snapshot when
96
96
  `.trekoon/trekoon.db-wal` changes; in-process mutations publish deltas
97
- directly. PATCH endpoints accept `If-Match: <version>` for optimistic
98
- concurrency; RFC 7232 strong or `W/`-prefixed weak ETag forms are accepted,
99
- but the `*` wildcard is not. A stale value returns `409` with
100
- `currentVersion` and `providedVersion`. Missing `If-Match` is allowed for
101
- back-compat.
97
+ directly. PATCH endpoints require `If-Match: <version>` for optimistic concurrency; RFC
98
+ 7232 strong or `W/`-prefixed weak ETag forms are accepted, but the `*`
99
+ wildcard is not. A stale value returns `409` with `currentVersion` and
100
+ `providedVersion`. A missing `If-Match` header returns `428 Precondition
101
+ Required` with error code `precondition_required`.
102
102
 
103
103
  Repos that already have an ignored `.trekoon/board` directory keep those files
104
104
  on disk, but current Trekoon versions no longer read, create, refresh, or
@@ -288,6 +288,19 @@ trekoon session --epic <epic-id>
288
288
 
289
289
  Scopes session readiness to a specific epic instead of the full tracker.
290
290
 
291
+ ## Session item resolve
292
+
293
+ ```bash
294
+ trekoon --toon session --item <id>
295
+ ```
296
+
297
+ Resolves any epic/task/subtask id in one call. Returns
298
+ `item: { id, kind, parentEpicId, entity, readiness, suggestedNext }` where
299
+ `kind` is one of `epic|task|subtask`, `entity` is the same shape as
300
+ `epic show --all` / `task show --all` / `subtask show`, and `readiness` is
301
+ scoped to `parentEpicId`. Replaces the legacy
302
+ `epic show || task show || subtask show` fallback cascade.
303
+
291
304
  ## Suggest
292
305
 
293
306
  ```bash
@@ -648,6 +648,7 @@ any `ok: false` response will be one of the following strings.
648
648
  | `outside_repo_target` | Skill install target path is outside the repository root. |
649
649
  | `permission_denied` | File-system permission denied for the requested path. |
650
650
  | `precondition_failed` | `If-Match` precondition header did not match the entity's current version. Error details include `currentVersion` and `providedVersion`. |
651
+ | `precondition_required` | `If-Match` header is required on a PATCH route but was omitted. |
651
652
  | `row_not_found` | Sync resolve target row no longer exists in the database. |
652
653
  | `status_transition_invalid` | Requested status transition is not permitted by the status machine. |
653
654
  | `stream_unavailable` | SSE snapshot stream is not available (board not initialised or shutting down). |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "trekoon",
3
- "version": "0.4.5",
3
+ "version": "0.4.6",
4
4
  "description": "AI-first task tracking that lives in your repo. You describe what to build, your agent plans it as a dependency graph, then executes it task by task",
5
5
  "keywords": [
6
6
  "ai",