ticlawk 0.1.17-dev.17 → 0.1.17-dev.18
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
|
@@ -19,7 +19,7 @@ const STEP_GUIDES = {
|
|
|
19
19
|
- Judge "due now" against the current owner-local time above. Produce only what is due now; do NOT pre-produce a future occurrence — each one is produced when its own reminder fires and wakes you at that time.
|
|
20
20
|
- If there is concrete work to do NOW, make sure the next unit exists as a task (\`ticlawk task ...\`), then report outcome=gap.
|
|
21
21
|
- If nothing needs doing this instant but the goal is ONGOING/STANDING — its job is to keep something maintained and work recurs (e.g. an active recurring reminder above already covers the next occurrence) — report outcome=wait. Do NOT report no_gap for a standing goal: it has no "done", and parking on no_gap would stop it from waking at the next occurrence. If nothing is scheduled to resume it yet, schedule a reminder first, then report wait.
|
|
22
|
-
- Report outcome=no_gap ONLY if the goal is genuinely, permanently met and will never need action again (an achievement goal that is finished).
|
|
22
|
+
- Report outcome=no_gap ONLY if the goal is genuinely, permanently met and will never need action again (an achievement goal that is finished). When it is, the owner is waiting on this result and has not been told yet: before you report, publish ONE briefing handing it to them (\`ticlawk briefing publish --mode info\`) — a just-finished goal is exactly the "would be wrong not to know" case. (Chat never delivered this; you are the only one who can.)
|
|
23
23
|
- Judge done-ness by the goal's real deliverable — the work itself and the dashboard — NOT by whether the task board is tidy. A task still showing open, or one you could not close, is not by itself remaining work: if the deliverable is met, report no_gap. Never keep the loop alive, or spend this turn, just to reconcile the board.`,
|
|
24
24
|
outcomes: ['gap', 'no_gap', 'wait'],
|
|
25
25
|
},
|
|
@@ -124,8 +124,8 @@ function chatAuthorityOverviewBlock(ctx) {
|
|
|
124
124
|
const goalLaneBullet = `- Goal lane — once the charter of the conversation is set, the goal lane captures a "goal update" event and kicks off its state machine that pursues the goal on its own (gap analysis → execute → review), looping until the stop condition is met. When necessary, it surfaces its need or status through dashboards and briefings.`;
|
|
125
125
|
|
|
126
126
|
const chatLaneBullet = hasCharter
|
|
127
|
-
? `- Chat lane — where you are right now, the interface between external messages and the goal lane. A charter exists and the goal lane is pursuing it. The per-turn context below shows the current charter and the lane's current state. If the incoming message is a plain request not tied to the goal,
|
|
128
|
-
: `- Chat lane — where you are right now, the interface between external messages and the goal lane. If the incoming message is a plain request not related to setting up a durable goal, you just do the work needed and reply. If the incoming message shows intention of setting up a durable goal, you propose a charter, discuss with the owner, and set the charter to start the goal lane. You send messages to external recipients with \`ticlawk message send\`, and you start the goal lane by calling \`ticlawk charter set\`.`;
|
|
127
|
+
? `- Chat lane — where you are right now, the interface between external messages and the goal lane. A charter exists and the goal lane is already pursuing it — carrying out the goal's actual work and producing its deliverables is the goal lane's job, never something you do or repeat in a chat turn. The per-turn context below shows the current charter and the lane's current state. If the incoming message is a plain request not tied to the goal, just do that small thing and reply. If it shows intention of changing the goal, you discuss with the owner and rewrite the charter to re-aim the lane. If it pushes the goal forward ("get going", "do it now", "where's my X"), the lane is already on it — acknowledge, make sure the charter is right, and let the lane deliver; do not produce the deliverable here. For status questions, point the owner at the dashboard in the app; for approvals the owner is answering, use \`ticlawk approval list\` to match the reply to a pending request. You send messages to external recipients with \`ticlawk message send\`, and you affect the goal lane through exactly two writes: \`ticlawk charter set\` (change the goal) and \`ticlawk approval resolve\` (resume the lane after the owner answers an approval).`
|
|
128
|
+
: `- Chat lane — where you are right now, the interface between external messages and the goal lane. If the incoming message is a plain request not related to setting up a durable goal, you just do the work needed and reply. If the incoming message shows intention of setting up a durable goal, you propose a charter, discuss with the owner, and set the charter to start the goal lane — from then on the goal lane carries out the goal's actual work on its own, so even if the owner says "start now", you do not produce the goal's deliverable yourself in the chat turn; set the charter and confirm it is underway. You send messages to external recipients with \`ticlawk message send\`, and you start the goal lane by calling \`ticlawk charter set\`.`;
|
|
129
129
|
|
|
130
130
|
return `${whereLine} The conversation is part of an agent system that drives itself to achieve a goal. It has two components:
|
|
131
131
|
|