ticlawk 0.1.17-dev.4 → 0.1.17-dev.5
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/package.json
CHANGED
|
@@ -17,15 +17,15 @@ const STEP_GUIDES = {
|
|
|
17
17
|
title: 'GAP ANALYSIS',
|
|
18
18
|
body: `Compare the current state of the work against the goal and success criteria. Read whatever you need (charter, dashboard, task board, repo, prior messages) to judge where things actually stand. The dashboard is the owner's at-a-glance visualization of how far this goal has progressed — this step owns keeping it true to reality: if a durable goal has no dashboard yet, create it (\`ticlawk dashboard set\`); if overall progress has moved materially, refresh its content/data. See SURFACES.md.
|
|
19
19
|
- If there is concrete executable work toward the goal, first make sure the next unit exists as a task (create/assign it with \`ticlawk task ...\` when a task fits), then report outcome=gap.
|
|
20
|
-
- If the goal/milestone is fully met with no meaningful gap, make sure the dashboard reflects the completed state,
|
|
20
|
+
- If the goal/milestone is fully met with no meaningful gap, make sure the dashboard reflects the completed state, then report outcome=no_gap. (The completed result is something the owner is waiting on — surface it per the briefing rule below.)
|
|
21
21
|
- If closing the gap depends on a future or external state that nobody can act on right now, schedule a reminder for the resume condition, then report outcome=wait.`,
|
|
22
22
|
outcomes: ['gap', 'no_gap', 'wait'],
|
|
23
23
|
},
|
|
24
24
|
execute: {
|
|
25
25
|
title: 'EXECUTE',
|
|
26
|
-
body: `Do the next concrete unit of work toward the goal (or drive the current task to completion). Send interim
|
|
26
|
+
body: `Do the next concrete unit of work toward the goal (or drive the current task to completion). Send routine interim progress with \`ticlawk message send --phase progress\`; if an update clears the briefing bar below (e.g. it is a result the owner explicitly asked to be told about), surface it as a briefing instead.
|
|
27
27
|
- When the unit of work is finished and ready to be checked, report outcome=task_completed.
|
|
28
|
-
- If you cannot proceed without an owner approval, decision, or permission, park ONE canonical approval with \`ticlawk approval request --title "<what you need approved>" [--detail "<context>"]\`,
|
|
28
|
+
- If you cannot proceed without an owner approval, decision, or permission, park ONE canonical approval with \`ticlawk approval request --title "<what you need approved>" [--detail "<context>"]\`, tell the owner what you need and why, then report outcome=needs_approval. The owner's approval (button or a natural-language reply) resumes you automatically.
|
|
29
29
|
- If you are blocked by something else (missing input, external failure, a needed resource), explain it to the owner, then report outcome=blocked.`,
|
|
30
30
|
outcomes: ['task_completed', 'needs_approval', 'blocked'],
|
|
31
31
|
},
|
|
@@ -74,10 +74,16 @@ export function buildGoalStepPrompt(msg) {
|
|
|
74
74
|
`Current step: ${guide.title}`,
|
|
75
75
|
guide.body,
|
|
76
76
|
``,
|
|
77
|
+
`Briefing rule (independent of which step you are on): a briefing (\`ticlawk briefing publish\`) interrupts the owner — it is only for things worth their attention. Default to NOT sending one; routine progress belongs on the dashboard (the owner pulls it) or a chat \`ticlawk message send\`. Send a briefing only when one of these holds:`,
|
|
78
|
+
` (a) the owner must act or decide — e.g. an approval you parked (\`--mode approval\`);`,
|
|
79
|
+
` (b) the owner asked to be told about this — a standing request, a scheduled time, or a threshold they set (\`--mode info\`);`,
|
|
80
|
+
` (c) something happened the owner would be wrong not to know now — goal done, blocked, materially off-track, or a result they are waiting on (\`--mode info\`).`,
|
|
81
|
+
`If you are unsure, it is NOT a briefing — put it on the dashboard. The dashboard is the always-current pull surface; briefings are scarce pushes — over-notifying trains the owner to ignore them.`,
|
|
82
|
+
``,
|
|
77
83
|
`When the step is done, advance the state machine by running EXACTLY ONE report:`,
|
|
78
84
|
` ${reportCmd}`,
|
|
79
85
|
``,
|
|
80
|
-
`Reporting the outcome is what continues the loop: a running next state arrives as a fresh step, and the loop parks itself when there is no gap or it must wait. Reach the owner only through
|
|
86
|
+
`Reporting the outcome is what continues the loop: a running next state arrives as a fresh step, and the loop parks itself when there is no gap or it must wait. Reach the owner only through Ticlawk surfaces — \`ticlawk message send --target ${target}\` (chat), \`ticlawk briefing publish\` (push, per the rule above), \`ticlawk dashboard set\` (goal report); see \`SURFACES.md\`. Any owner-facing text is for the owner in their language: say what changed, why it matters, and what (if anything) they must do; never expose internal task titles, file paths, step numbers, or harness tokens. Report exactly once; do not loop inside this single turn.`,
|
|
81
87
|
`[/goal_step]`,
|
|
82
88
|
].join('\n'));
|
|
83
89
|
} else {
|