ticlawk 0.1.16-dev.18 → 0.1.16-dev.19

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.18",
3
+ "version": "0.1.16-dev.19",
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",
@@ -126,11 +126,12 @@ ${buildGoalSetupRules()}
126
126
  4. Execute the next task yourself when appropriate, or create/assign a task when coordination is needed.
127
127
  5. Check whether the result closes the gap.
128
128
  6. Return to evaluating current facts against the goal.
129
+ - During each goal-loop iteration, explicitly write a private loop check before acting: current facts, goal/success criterion, gap, next action, and stop/continue decision. This is for your execution discipline, not a chat message. Do not send the private loop check through ${BRAND_NAME} unless the owner explicitly asks for that analysis.
129
130
  - Stop the loop only when there is no meaningful gap, progress is blocked because the owner needs to provide input/resources/permission/confirmation/decision, or progress depends on an external/time-based wait.
130
131
  - If there is no gap, say so briefly. If the goal is complete, report completion.
131
132
  - If user input, resources, permission, confirmation, or a decision is needed, publish a briefing with one clear bundled request to the owner.
132
133
  - If 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 rather than silently stalling. Do not use reminders to defer an executable next step or an owner decision/request.
133
- - When a task reaches \`in_review\` or \`done\`, re-run the goal loop before dashboard, MEMORY.md, briefing, or wrap-up updates.
134
+ - When reviewing returned task work, evaluate the evidence against the task and current goal before marking it done or using it in reports. If the task is complete, update task state, then immediately run the private loop check against the updated facts before dashboard, MEMORY.md, briefing, or wrap-up updates.
134
135
  - Keep persistent state surfaces distinct: dashboard for goal-level reporting, MEMORY.md for your local continuity, and briefings for active owner notifications.
135
136
  - Publish briefings and update dashboards only from DMs you own or groups where you are admin/owner.
136
137
  `);
@@ -164,7 +165,7 @@ function buildGroupGoalScopeOverlay() {
164
165
  Scope overlay: group with admin or owner role
165
166
  - In a group where you are admin or owner, you own both the group goal loop and the task system.
166
167
  - Use the group task board for task inventory and assignment.
167
- - When you delegate substantive work to another agent, make it a group task before or while requesting the work. When results return, update task state and re-run the group goal loop.
168
+ - When you delegate substantive work to another agent, make it a group task before or while requesting the work. When results return, review the evidence, update task state only after task acceptance, then re-run the private group goal loop.
168
169
  - Group messages coordinate working agents. Dashboard, MEMORY.md, and briefings are tracking/reporting surfaces with distinct roles.
169
170
  - As admin/owner, update the group dashboard when the goal-level report the requester would care about has changed.
170
171
  - As admin/owner, publish a briefing only when the owner should be actively notified: milestone reached, important change, blocker, request for owner input/resources/permission/confirmation/decision, or final result.
@@ -31,8 +31,11 @@ private activity text; it is not sent to users or groups.
31
31
  - Use the exact target from the current wake message when replying.
32
32
  - Complete the work before stopping. Progress updates are allowed, but they
33
33
  are not completion.
34
- - Send messages only when they carry useful content: answer, blocker,
35
- decision request, or final result.
34
+ - Use normal assistant output as private work trace. External
35
+ \`ticlawk message send\` messages should be clean, actionable
36
+ communication: answer, instruction, blocker, decision request, or final
37
+ result. Do not send private loop/checklist scratchpad unless the owner
38
+ explicitly asks for that analysis.
36
39
 
37
40
  ## Per-Turn Routine
38
41