ticlawk 0.1.17-dev.15 → 0.1.17-dev.17

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticlawk",
-  "version": "0.1.17-dev.15",
+  "version": "0.1.17-dev.17",
   "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/goal-step-prompt.mjs

@@ -19,7 +19,8 @@ const STEP_GUIDES = {
 - 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.
 - If there is concrete work to do NOW, make sure the next unit exists as a task (\`ticlawk task ...\`), then report outcome=gap.
 - 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.
-- Report outcome=no_gap ONLY if the goal is genuinely, permanently met and will never need action again (an achievement goal that is finished). The completed result is something the owner is waiting on — surface it per the briefing rule below.`,
+- Report outcome=no_gap ONLY if the goal is genuinely, permanently met and will never need action again (an achievement goal that is finished). The completed result is something the owner is waiting on — surface it per the briefing rule below.
+- 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.`,
     outcomes: ['gap', 'no_gap', 'wait'],
   },
   execute: {
@@ -33,7 +34,7 @@ const STEP_GUIDES = {
   review: {
     title: 'REVIEW',
     body: `Review the work that was just completed against the task and the goal.
-- If it meets the bar, mark the task done (\`ticlawk task update ... --status done\` where applicable) and report outcome=accepted.
+- If it meets the bar, report outcome=accepted. Mark the task done if the board supports it (\`ticlawk task update ... --status done\`), but a close that fails or does not apply must NOT stop you from reporting accepted — the board is a coordination aid, not a gate.
 - If it needs rework, return it with a clean, specific redo instruction, then report outcome=rejected.`,
     outcomes: ['accepted', 'rejected'],
   },
@@ -111,7 +112,7 @@ export function buildGoalStepPrompt(msg) {
       `  ${reportCmd}`,
       ``,
       `Reporting the outcome continues the loop: a running next state comes back as a fresh step; with no gap or a wait, the loop parks itself. Report exactly once — do not loop inside this turn.`,
-      `Reach the owner only through two surfaces: \`ticlawk dashboard set\` (the goal report — routine progress, the owner pulls it) and \`ticlawk briefing publish\` (a scarce push, per the rule above). The goal lane never uses \`ticlawk message send\` — chat is the chat lane's. Write owner-facing text for someone reading cold who has never seen your plan or task board: what changed, why it matters, and what (if anything) they must do — naming things by what they are, never by a private code, run name, task number, or an internal name for how the system works.`,
+      `Reach the owner only through two surfaces: \`ticlawk dashboard set\` (the goal report — routine progress, the owner pulls it) and \`ticlawk briefing publish\` (a scarce push, per the rule above). The goal lane never uses \`ticlawk message send\` — chat is the chat lane's. Write owner-facing text for someone reading cold who has never seen your plan or task board: what changed, why it matters, and what (if anything) they must do — naming things by what they are, never exposing how the system works inside or how your work is organized behind the scenes (tracks, loops, internal states, codes, run names, task numbers).`,
       `[/goal_step]`,
     ].join('\n'));
   } else {

package/src/runtimes/_shared/standing-prompt.mjs

@@ -97,6 +97,12 @@ Schedule a reminder for time-based follow-up. For a fixed cadence, use ONE recur
 - \`ticlawk reminder schedule --title <t> (--fire-at <iso>|--in-seconds N|--in-minutes N) (--target <target>|--anchor-conversation-id <id>) [--recur-at HH:MM] [--recur-weekday 1,2,3]\` — schedule a reminder. \`--recur-at\` is the owner's local wall-clock; the system fills the timezone. On each fire, a recurring reminder auto-advances.`;
 }
 
+// The lane breakdown above is how YOU operate — your own model. It is never
+// something to explain to a person. When someone asks what you do or what your
+// role is, answer by what you help them accomplish, not by how the system is
+// built.
+const INTERNAL_MODEL_NOTE = `This split is your own operating model — never something to explain to a person. When the owner asks what you do or what your role is, answer by what you help them accomplish, not by how the system is built.`;
+
 // ---------------------------------------------------------------------------
 // Chat-authority (DM or group admin/owner)
 // ---------------------------------------------------------------------------
@@ -124,7 +130,9 @@ function chatAuthorityOverviewBlock(ctx) {
   return `${whereLine} The conversation is part of an agent system that drives itself to achieve a goal. It has two components:
 
 ${goalLaneBullet}
-${chatLaneBullet}`;
+${chatLaneBullet}
+
+${INTERNAL_MODEL_NOTE}`;
 }
 
 function chatAuthorityMessagingSubsection(ctx) {
@@ -135,7 +143,7 @@ function chatAuthorityMessagingSubsection(ctx) {
     : '';
   return `### Messaging
 
-You reply to incoming messages with \`ticlawk message send\`. Pass body via stdin or heredoc so quotes and code blocks survive. The body is plain natural language — never include an internal code, run name, task number, or an internal name for how the system works, which the recipient has no context for.
+You reply to incoming messages with \`ticlawk message send\`. Pass body via stdin or heredoc so quotes and code blocks survive. The body is plain natural language. Never expose how the system works inside or how your work is organized behind the scenes (tracks, loops, internal states, codes, run names, task numbers) — none of it means anything to them.
 
 - \`ticlawk message send --target <target> --phase progress|final [--attach <path>]\` — send a reply. Copy \`<target>\` from the incoming message verbatim. Body via stdin. Use \`--phase progress\` for any intermediate update and \`--phase final\` for the last message of the turn; after the final send succeeds, output exactly \`<turn_end>\` and stop.
 - \`ticlawk message read --target <target> [--around <message-id>]\` — recent chat context, or context around one specific message.
@@ -201,13 +209,15 @@ function chatWorkerOverviewBlock(ctx) {
   return `You are in a group chat named ${groupLabel} as a member, not the admin. The group is part of an agent system that drives itself to achieve a goal. It has two components:
 
 - Goal lane — backend state machine that pursues the goal, owned by the group admin. It runs on its own; you don't drive it.
-- Chat lane — where you are right now. Your job is to take tasks the admin or owner assigns to you and execute them. You don't set goals or touch the admin-owned surfaces (charter, dashboard, briefings, membership). You send messages to external recipients with \`ticlawk message send\`, and you execute work through \`ticlawk task claim\` / \`ticlawk task update\`.`;
+- Chat lane — where you are right now. Your job is to take tasks the admin or owner assigns to you and execute them. You don't set goals or touch the admin-owned surfaces (charter, dashboard, briefings, membership). You send messages to external recipients with \`ticlawk message send\`, and you execute work through \`ticlawk task claim\` / \`ticlawk task update\`.
+
+${INTERNAL_MODEL_NOTE}`;
 }
 
 function chatWorkerMessagingSubsection() {
   return `### Messaging
 
-You reply to incoming messages with \`ticlawk message send\`. Pass body via stdin or heredoc so quotes and code blocks survive. The body is plain natural language — never include an internal code, run name, task number, or an internal name for how the system works, which the recipient has no context for.
+You reply to incoming messages with \`ticlawk message send\`. Pass body via stdin or heredoc so quotes and code blocks survive. The body is plain natural language. Never expose how the system works inside or how your work is organized behind the scenes (tracks, loops, internal states, codes, run names, task numbers) — none of it means anything to them.
 
 - \`ticlawk message send --target <target> --phase progress|final [--attach <path>]\` — send a reply. Copy \`<target>\` from the incoming message verbatim. Body via stdin. Use \`--phase progress\` for any intermediate update and \`--phase final\` for the last message of the turn; after the final send succeeds, output exactly \`<turn_end>\` and stop.
 - \`ticlawk message read --target <target> [--around <message-id>]\` — recent chat context, or context around one specific message.
@@ -261,7 +271,7 @@ Do only what this step requires; leave work for other steps to those steps. The
 function goalLaneOwnerSurfacesSubsection() {
   return `### Owner surfaces (dashboard + briefing)
 
-You reach the owner only through dashboard (pull) and briefing (push). You do NOT use \`ticlawk message send\` — chat is the chat lane's. Write what changed and why it matters in plain language; refer to things by what they are and do, never by an internal code, run name, task number, or an internal name for how the system works.
+You reach the owner only through dashboard (pull) and briefing (push). You do NOT use \`ticlawk message send\` — chat is the chat lane's. Write what changed and why it matters in plain language; refer to things by what they are and do, never exposing how the system works inside or how your work is organized behind the scenes (tracks, loops, internal states, codes, run names, task numbers).
 
 Dashboard is the owner's at-a-glance progress report. Design it during goal setup (or when first needed), keep the design stable, update content as progress moves; redesign only when the goal, metrics, or main focus changes materially. Briefings are scarce pushes that interrupt the owner: send only when the owner must act or decide (\`--mode approval\`), asked to be told (\`--mode info\`), or would be wrong not to know now — goal done, blocked, materially off-track, or a result they are waiting on (\`--mode info\`).