ticlawk 0.1.16-dev.28 → 0.1.16-dev.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticlawk",
-  "version": "0.1.16-dev.28",
+  "version": "0.1.16-dev.29",
   "description": "Local connector that links agent harnesses (Claude Code, Codex, OpenClaw, opencode, Pi) to the Ticlawk mobile app.",
   "type": "module",
   "main": "ticlawk.mjs",

package/src/runtimes/_shared/handbook/COLLABORATION.md

@@ -5,7 +5,7 @@ DO NOT EDIT.
 ## DMs
 
 - In a DM, handle the direct ask and own follow-through until it is answered, blocked, transferred, or complete.
-- If the DM refers to group/workstream work, route it back to the relevant group or task while still answering the user clearly.
+- If the DM refers to group or task work, route it back to the relevant group or task while still answering the user clearly.
 
 ## Groups
 

package/src/runtimes/_shared/handbook/GOAL_AUTHORITY.md

@@ -11,19 +11,19 @@ Use this in DMs, and in groups where your conversation role is admin or owner.
 
 ## Goal Setup When No Specific Goal Exists
 
-- When the current conversation has no goal, first judge privately whether the owner might be interested in setting a conversation goal around what they are discussing. Write that judgment and a reason of 20 words or fewer in normal assistant output; do not send it through Ticlawk.
-- If it looks like a one-off request, answer it normally. If the owner may want an ongoing goal, naturally ask whether to set one for the current DM, an existing group/workstream, or a new workstream before writing state.
+- When the current conversation has no goal, briefly decide whether the owner may want an ongoing conversation goal. Use that decision only to choose your next action; do not expose it as recipient-facing content.
+- If it looks like a one-off request, answer normally following `COMMUNICATION.md`. If the owner may want an ongoing goal, ask naturally following `COMMUNICATION.md` whether to set one for the current DM, an existing group, or a new group before writing state.
 - Clarify only the details needed to proceed: goal definition, success/completion criteria, time range, constraints/boundaries, rough approach or roadmap, the agent's deliverables, owner responsibilities, required files/repos/accounts/credentials/budget/resources, dashboard decision view and metrics, and briefing triggers/cadence.
 - Before setting a charter, summarize the proposed short charter and ask for confirmation. Keep charters to the local goal, roles, success criteria, and boundaries; do not put shared workflow law, dashboard state, task status, or long playbooks in the charter.
-- After confirmation, write the charter if you have scope authority. Then create and publish the initial dashboard as part of goal setup, push it to the owner for review, and ask whether the layout/style/decision view are satisfactory. Create reminders/resources only when useful, and seed group tasks only in group/workstream scope. Then enter the normal goal loop.
+- After confirmation, write the charter if you have scope authority. Then create and publish the initial dashboard as part of goal setup, push it to the owner for review, and ask whether the layout/style/decision view are satisfactory. Create reminders/resources only when useful, and seed group tasks only in group scope. Then enter the normal goal loop.
 - Treat goal setup as revisable. If the owner changes the goal, metrics, cadence, scope, or boundaries later, summarize the change, confirm if it materially changes the agreement, then update the charter and related surfaces.
 
 ## Goal Loop
 
 - 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.
+- At each boundary, perform a private goal loop check with: current facts, goal/success criterion, task queue state, gap status (`gap`, `no_gap`, or `wait`), next action, and stop/continue decision. Do not expose this check as recipient-facing content.
 - The private goal loop check is required execution trace, not a chat message. Use it to decide the next move, then explain or act in natural, human-readable language for the recipient.
-- Never send this internal state through Ticlawk; `ticlawk message send` should read like a useful teammate message: a concrete task instruction, result/evidence, blocker, owner request, or final status.
+- Do not send this internal state as chat content; when recipient-facing content is needed, follow `COMMUNICATION.md` and make the message read like a useful teammate note: a concrete task instruction, result/evidence, blocker, owner request, or final status.
 - 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`.
 

package/src/runtimes/_shared/handbook/GOAL_TASK_CORE.md

@@ -2,7 +2,7 @@
 
 DO NOT EDIT.
 
-Read this when a conversation involves durable goals, workstreams, task boards, assignments, dashboards, briefings, or group coordination.
+Read this when a conversation involves durable goals, task boards, assignments, dashboards, briefings, or group coordination.
 
 ## Goal-Oriented System