ticlawk 0.1.16-dev.22 → 0.1.16-dev.23

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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "ticlawk",
3
- "version": "0.1.16-dev.22",
3
+ "version": "0.1.16-dev.23",
4
4
  "description": "Local connector that links agent harnesses (Claude Code, Codex, OpenClaw, opencode, Pi) to the Ticlawk mobile app.",
5
5
  "type": "module",
6
6
  "main": "ticlawk.mjs",
@@ -119,13 +119,11 @@ Goal authority overlay: responsible for this conversation's goal and tasks
119
119
  - You are responsible for driving the conversation toward its goal, not only replying to isolated messages.
120
120
  - Maintain or infer the current goal from the direct ask, charter, dashboard/briefing quote, task board, and conversation context.
121
121
  ${buildGoalSetupRules()}
122
- - Run the goal loop as a state machine. At each goal-loop boundary, explicitly write a private goal loop check in normal assistant output with: current facts, goal/success criterion, state, gap, next action, and stop/continue decision. This is required execution trace, not a chat message. Never send this internal state through ${BRAND_NAME}; \`ticlawk message send\` should contain only the effective external message: a task instruction, result/evidence, blocker, owner request, or final status.
123
- - State \`clear_gap\`: there is a concrete gap the agent system can act on now. Execute the next task yourself when appropriate, or create/assign a group task when coordination is needed. If you delegate substantive work, use the task board and send a clean task instruction.
124
- - State \`unclear_gap\`: the gap or success criterion is not concrete enough to act on. Gather the smallest missing context yourself, create an investigation task, or ask one bundled clarification in the group/briefing depending on who can answer it.
125
- - State \`owner_blocked\`: progress needs owner input, resources, permission, confirmation, or a decision. Publish one briefing with a clear bundled request, then stop until the owner responds.
126
- - State \`external_wait\`: progress depends on an external or time-based future state and no agent or owner can act now. Use a reminder or explicit resume condition, then stop. Do not use reminders to defer an executable next step or owner decision/request.
127
- - State \`returned_task\`: returned work is ready for review. Evaluate the evidence against the task and current goal before accepting it. If complete, update task state, then immediately run another private goal loop check against the updated facts before dashboard, MEMORY.md, briefing, or wrap-up updates. If incomplete, keep or return the task with a clean redo/blocker instruction.
128
- - State \`complete\`: there is no meaningful gap and the goal or milestone is complete. Publish a final \`info\` briefing summarizing what was completed and why it matters, update the dashboard when the goal-level report changed, and send only a clean completion message where useful.
122
+ - Run the goal loop as a simple state machine after goal setup, and again whenever returned task work is accepted or the task queue becomes empty. At each boundary, explicitly write a private goal loop check in normal assistant output with: current facts, goal/success criterion, task queue state, gap status (\`gap\`, \`no_gap\`, or \`wait\`), next action, and stop/continue decision. This is required execution trace, not a chat message. Never send this internal state through ${BRAND_NAME}; \`ticlawk message send\` should contain only the effective external message: a task instruction, result/evidence, blocker, owner request, or final status.
123
+ - If the task queue has open work, work the queue before inventing new work: make sure the next task is assigned or claimed, review returned work against the task and goal, mark accepted work \`done\`, return incomplete work with a clean redo/blocker instruction, then assign the next queued task. When the queue is empty, return to evaluating the goal for \`gap\`, \`no_gap\`, or \`wait\`.
124
+ - State \`gap\`: current facts show a concrete gap from the goal. Create or assign the next concrete task, or execute it yourself when you are the right worker. Do not create duplicate tasks for a gap already covered by open task-queue work. If the next required action is an owner resource, permission, confirmation, or decision, publish one bundled owner-request briefing and stop until the owner responds.
125
+ - State \`wait\`: whether a gap exists, or whether it can close, depends on an external/time-based future state and no agent or owner can act now. Schedule a reminder or explicit resume condition, then stop. Do not use reminders to defer executable work or an owner decision/request.
126
+ - State \`no_gap\`: there is no meaningful gap and the goal or milestone is complete. Publish a final \`info\` briefing summarizing what was completed and why it matters, update the dashboard when the goal-level report changed, send only a clean completion message where useful, then stop.
129
127
  - Keep persistent state surfaces distinct: dashboard for goal-level reporting, MEMORY.md for your local continuity, and briefings for active owner notifications.
130
128
  - Publish briefings and update dashboards only from DMs you own or groups where you are admin/owner.
131
129
  `);