ticlawk 0.1.17-dev.12 → 0.1.17-dev.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticlawk",
-  "version": "0.1.17-dev.12",
+  "version": "0.1.17-dev.14",
   "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/core/agent-home.mjs

@@ -10,7 +10,7 @@
 import { existsSync, lstatSync, mkdirSync, readFileSync, symlinkSync, unlinkSync, writeFileSync } from 'node:fs';
 import { join } from 'node:path';
 import { AF_HOME } from './config.mjs';
-import { buildAgentHandbookFiles, LEGACY_HANDBOOK_FILE_NAMES } from '../runtimes/_shared/agent-handbook.mjs';
+import { LEGACY_HANDBOOK_FILE_NAMES } from '../runtimes/_shared/agent-handbook.mjs';
 
 export const AF_AGENTS_DIR = join(AF_HOME, 'agents');
 
@@ -38,31 +38,14 @@ export function ensureAgentHome(agentId, { displayName } = {}) {
   if (!existsSync(memoryPath)) {
     writeFileSync(memoryPath, buildInitialMemoryMd({ displayName, home }), 'utf8');
   }
-  writeManagedHandbookFiles(home);
+  // Handbook content is now inlined into the standing prompt — nothing
+  // to sync. We still sweep any historical handbook .md files left in
+  // existing workspaces from earlier versions.
+  removeLegacyManagedHandbookFiles(home);
   ensureSkillSymlinks(home);
   return home;
 }
 
-function writeManagedHandbookFiles(home) {
-  removeLegacyManagedHandbookFiles(home);
-  for (const { name, content } of buildAgentHandbookFiles()) {
-    const path = join(home, name);
-    try {
-      let stat = null;
-      try { stat = lstatSync(path); } catch { /* not present */ }
-      if (stat && !stat.isFile()) continue;
-      const next = `${content.trim()}\n`;
-      if (stat) {
-        const current = readFileSync(path, 'utf8');
-        if (current === next) continue;
-      }
-      writeFileSync(path, next, { encoding: 'utf8', mode: 0o600 });
-    } catch (err) {
-      console.warn(`[agent-home] failed to write ${path}: ${err?.message || err}`);
-    }
-  }
-}
-
 function removeLegacyManagedHandbookFiles(home) {
   for (const name of LEGACY_HANDBOOK_FILE_NAMES) {
     const path = join(home, name);

package/src/runtimes/_shared/agent-handbook.mjs

@@ -1,20 +1,23 @@
-import { readFileSync } from 'node:fs';
-import { dirname, join } from 'node:path';
-import { fileURLToPath } from 'node:url';
+/**
+ * Legacy handbook cleanup.
+ *
+ * As of the lane-separation refactor, all handbook content is inlined into
+ * the standing prompt (see standing-prompt.mjs). The daemon no longer
+ * syncs handbook .md files into per-agent workspaces. This module now
+ * exists only to enumerate the historical filenames so `agent-home.mjs`
+ * can remove them from workspaces that still have them.
+ */
 
-export const HANDBOOK_BASICS_FILE = 'BASICS.md';
-
-export const HANDBOOK_FILE_NAMES = Object.freeze([
-  HANDBOOK_BASICS_FILE,
+export const LEGACY_HANDBOOK_FILE_NAMES = Object.freeze([
+  // Previously active set (inlined into standing-prompt.mjs).
+  'BASICS.md',
   'COMMUNICATION.md',
   'COLLABORATION.md',
   'GOAL_TASK_CORE.md',
   'GOAL_AUTHORITY.md',
   'TASK_WORKER.md',
   'SURFACES.md',
-]);
-
-export const LEGACY_HANDBOOK_FILE_NAMES = Object.freeze([
+  // Older names from prior reorganizations.
   'TICLAWK.md',
   'TICLAWK_CLI.md',
   'TICLAWK_COLLABORATION.md',
@@ -33,13 +36,3 @@ export const LEGACY_HANDBOOK_FILE_NAMES = Object.freeze([
   'GROUP_ADMIN_SCOPE.md',
   'GROUP_MEMBER_SCOPE.md',
 ]);
-
-const MODULE_DIR = dirname(fileURLToPath(import.meta.url));
-const HANDBOOK_DIR = join(MODULE_DIR, 'handbook');
-
-export function buildAgentHandbookFiles() {
-  return HANDBOOK_FILE_NAMES.map((name) => ({
-    name,
-    content: readFileSync(join(HANDBOOK_DIR, name), 'utf8').trim(),
-  }));
-}

package/src/runtimes/_shared/goal-step-prompt.mjs

@@ -15,7 +15,7 @@ import { buildEnvelopeTarget, buildCharterBlock } from './wake-prompt.mjs';
 const STEP_GUIDES = {
   gap_analysis: {
     title: 'GAP ANALYSIS',
-    body: `Compare the current state against the goal and success criteria. The [goal_context] block above gives you the open tasks, active reminders, and dashboard state — judge from it; read the charter/repo/prior messages only for what it doesn't cover. The dashboard is the owner's at-a-glance visualization of how far this goal has progressed — this step owns keeping it true to reality: create it if a durable goal has none, refresh it when progress moved materially (\`ticlawk dashboard set\`; see SURFACES.md).
+    body: `Compare the current state against the goal and success criteria. The [goal_context] block above gives you the open tasks, active reminders, and dashboard state — judge from it; read the charter/repo/prior messages only for what it doesn't cover. The dashboard is the owner's at-a-glance visualization of how far this goal has progressed — this step owns keeping it true to reality: create it if a durable goal has none, refresh it when progress moved materially (\`ticlawk dashboard set\`).
 - 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.
@@ -105,7 +105,7 @@ export function buildGoalStepPrompt(msg) {
       `Current step: ${guide.title}`,
       guide.body,
       ``,
-      `Briefings are scarce pushes that interrupt the owner; routine progress belongs on the dashboard (the owner pulls it). Send one (\`ticlawk briefing publish\`) only when the owner must act or decide (\`--mode approval\`), asked to be told, or would be wrong not to know now — goal done, blocked, off-track, or a result they are waiting on (\`--mode info\`). The exact bar is in SURFACES.md "Briefing"; if unsure, it is not a briefing.`,
+      `Briefings are scarce pushes that interrupt the owner; routine progress belongs on the dashboard (the owner pulls it). Send one (\`ticlawk briefing publish\`) only when the owner must act or decide (\`--mode approval\`), asked to be told, or would be wrong not to know now — goal done, blocked, off-track, or a result they are waiting on (\`--mode info\`). If unsure, it is not a briefing.`,
       ``,
       `When the step is done, advance the state machine by running EXACTLY ONE report:`,
       `  ${reportCmd}`,

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

@@ -1,9 +1,25 @@
 /**
  * Standing prompt injected into every runtime turn.
  *
- * Keep this thin. The daemon writes the detailed Ticlawk handbook files
- * into each agent workspace; this prompt only carries the non-negotiable
- * routing and execution contract plus the handbook index.
+ * Three audiences, each fully separated:
+ *   - goal lane:          one backend FSM step (transition delivery)
+ *   - chat-authority:     DM agent, or group admin/owner
+ *   - chat-worker:        group member, no goal authority
+ *
+ * Chat-authority is further branched on whether a charter exists in the
+ * conversation — the no-charter and with-charter prompts have different
+ * chat-lane overview bullets and different goal-control subsections
+ * because the agent's job is materially different in each.
+ *
+ * Every audience prompt is built as:
+ *   1) Overview (audience + lane breakdown)
+ *   2) ## Workspace (private cwd + MEMORY.md format)
+ *   3) ## Tools that you can use
+ *      ### subsection per tool family (short workflow intro + command bullets)
+ *   4) ## Conduct (groups only — DM is trivial; goal lane has no conduct)
+ *
+ * The per-turn user-message wrapper still comes from wake-prompt.mjs
+ * (chat lane) or goal-step-prompt.mjs (goal lane).
  */
 
 import { selectGoalTaskProtocolOverlays } from './goal-task-protocol.mjs';
@@ -12,32 +28,6 @@ function promptBlock(text) {
   return text.trim();
 }
 
-function buildBaseStandingPrompt(ctx = {}) {
-  return `${buildCurrentConversationGuide(ctx)}
-
-${buildReadInstructions(ctx)}
-
-Read other local files only when the current work clearly needs them.`;
-}
-
-// A goal-lane turn is a single backend FSM step, not a chat message. Its
-// per-step instructions and exact CLI commands (`goal report`, `task`,
-// `dashboard set`, `briefing publish`) live in the goal-step (user) prompt
-// built by goal-step-prompt.mjs. The system prompt here therefore stays
-// minimal: identity + the one reply invariant. It deliberately omits the
-// chat-lane role framing and handbook read-list, which would compete with
-// the narrow step instruction and pull the model toward proactive
-// assistant behavior. See system.md "Lane-aware standing prompt".
-function buildGoalLaneStandingPrompt(_ctx = {}) {
-  return `You are executing one backend goal-loop step for this conversation, dispatched by the system — not a message from a person. Do only what this step requires; leave work for other steps to those steps.
-
-Your normal output is private and reaches no one. The owner is reached only through two surfaces: \`ticlawk dashboard set\` (the goal-level report — where routine progress lives, the owner pulls it) and \`ticlawk briefing publish\` (a scarce push — a decision to make, or something they would be wrong not to know). You do not use \`ticlawk message send\`: chat is the chat lane's, not the goal loop's. The step tells you which surface to use; \`SURFACES.md\` holds the rules. Read \`SURFACES.md\` or \`MEMORY.md\` only if the step needs them.`;
-}
-
-function isGoalLane(ctx = {}) {
-  return ctx?.inbound?.lane === 'goal' || readDeliveryReason(ctx) === 'transition';
-}
-
 function getInboundRaw(ctx = {}) {
   return ctx?.inbound?.raw && typeof ctx.inbound.raw === 'object'
     ? ctx.inbound.raw
@@ -49,6 +39,10 @@ function readDeliveryReason(ctx = {}) {
   return String(raw.reason || '').trim() || 'unknown';
 }
 
+function isGoalLane(ctx = {}) {
+  return ctx?.inbound?.lane === 'goal' || readDeliveryReason(ctx) === 'transition';
+}
+
 function readString(value) {
   return typeof value === 'string' ? value.trim() : '';
 }
@@ -62,102 +56,266 @@ function readConversationName(ctx = {}) {
   return readString(raw.conversation_name || raw.conversation_display_name || raw.conversation_id);
 }
 
-function readQuoteKind(ctx = {}) {
-  const raw = getInboundRaw(ctx);
-  const meta = raw.message_metadata || raw.metadata || null;
-  const quote = meta && typeof meta === 'object' ? meta.quote : null;
-  return readString(quote?.kind).toLowerCase();
-}
+// ---------------------------------------------------------------------------
+// Shared: Workspace (varies on the "don't record" tail by audience)
+// ---------------------------------------------------------------------------
 
-function hasTaskContext(ctx = {}) {
-  const raw = getInboundRaw(ctx);
-  return raw.task_number != null || readString(raw.task_status) || readString(raw.task_title);
+function workspaceBlock(audience) {
+  const dontRecordTail = audience === 'worker'
+    ? `that is the admin's job and its source of truth is in ticlawk.`
+    : audience === 'goal'
+      ? `its single source of truth is the charter, dashboard, and task board, accessed through ticlawk.`
+      : `its single source of truth is maintained by ticlawk tools (\`ticlawk charter set\`, \`ticlawk approval resolve\`, etc.).`;
+  return `## Workspace
+
+Your cwd is your private workspace. Unless told otherwise, you keep \`MEMORY.md\` and all artifacts you generate in this directory. If told to work in another directory, record that in \`MEMORY.md\` and cd into it for your work.
+
+\`MEMORY.md\` keeps key context and learnings of all conversations you are in, organized like:
+
+\`\`\`
+#<conv id>
+<your memory>
+
+#<conv id>
+<your memory>
+\`\`\`
+
+Do not record any goal-lane setup or status data in memory — ${dontRecordTail} Never record secrets.`;
 }
 
-function hasGoalSurfaceContext(ctx = {}) {
-  const kind = readQuoteKind(ctx);
-  return kind === 'dashboard' || kind === 'briefing';
+// ---------------------------------------------------------------------------
+// Shared: Reminders (identical text for all audiences; reminder routing is
+// handled automatically by the backend per fire_due_reminders — see
+// 20260529170000_reminder_wakes_goal_lane.sql)
+// ---------------------------------------------------------------------------
+
+function remindersSubsection() {
+  return `### Reminders
+
+Schedule a reminder for time-based follow-up. For a fixed cadence, use ONE recurring reminder rather than many one-shots.
+
+- \`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.`;
 }
 
-function buildCurrentConversationGuide(ctx = {}) {
-  const { scope, recipientRole, goalAuthority } = selectGoalTaskProtocolOverlays(ctx);
+// ---------------------------------------------------------------------------
+// Chat-authority (DM or group admin/owner)
+// ---------------------------------------------------------------------------
+
+function chatAuthorityOverviewBlock(ctx) {
+  const { scope, recipientRole } = selectGoalTaskProtocolOverlays(ctx);
   const name = readConversationName(ctx);
-  const lines = [];
+  const hasCharter = !!readCharter(ctx);
 
+  let whereLine;
   if (scope === 'group') {
-    const groupLabel = name ? `#${name}` : 'this group chat';
-    if (goalAuthority) {
-      const roleLabel = recipientRole === 'owner' ? 'owner' : 'admin';
-      lines.push(`You are in a group chat named ${groupLabel}. You are the ${roleLabel}.`);
-    } else {
-      lines.push(`You are in a group chat named ${groupLabel}. You are a member of the group.`);
-      lines.push('You are not the group admin.');
-    }
+    const groupLabel = name ? `#${name}` : 'a group chat';
+    const role = recipientRole === 'owner' ? 'owner' : 'admin';
+    whereLine = `You are in a group chat named ${groupLabel} as the ${role}.`;
   } else {
-    lines.push('You are in a one-on-one conversation with a human user.');
-    lines.push('The incoming message is from a human user.');
+    whereLine = `You are in a one-on-one conversation with a human.`;
   }
-  return lines.join('\n');
-}
-
-const FILE_DESCRIPTIONS = {
-  'MEMORY.md': 'your durable memory.',
-  'BASICS.md': 'workspace and memory basics.',
-  'COMMUNICATION.md': 'replying via the ticlawk CLI.',
-  'COLLABORATION.md': 'DM/group conduct.',
-  'GOAL_TASK_CORE.md': 'the goal system, the two lanes, and core vocabulary.',
-  'GOAL_AUTHORITY.md': 'your goal-side job: keep the charter right (the goal lane runs the loop).',
-  'TASK_WORKER.md': 'executing assigned tasks as a group member.',
-  'SURFACES.md': 'dashboards, briefings, reminders, and shared tools.',
-};
-
-function describeFile(name) {
-  const desc = FILE_DESCRIPTIONS[name];
-  return desc ? `\`${name}\` — ${desc}` : `\`${name}\``;
-}
-
-function buildReadInstructions(ctx = {}) {
-  const files = buildReadFileNames(ctx);
-  const list = files.map((name, index) => `${index + 1}. ${describeFile(name)}`).join('\n');
-  return `To reply, use \`ticlawk message send --target <target> --phase progress|final\`. Normal assistant output is private and reaches no one. Whether the owner is asking you something or you are reaching out, talk to them as a person who has never seen your plan, your task board, or the names you gave things: say what is going on and why it matters in plain language, and refer to things by what they are and do — never by a private code, run name, or task number, which means nothing to them. Details are in \`COMMUNICATION.md\`.
-
-Read these once if you haven't this session, then only when the current work needs them:
-${list}`;
-}
-
-function buildReadFileNames(ctx = {}) {
-  const { scope, goalAuthority } = selectGoalTaskProtocolOverlays(ctx);
-  const reason = readDeliveryReason(ctx);
-  const taskContext = hasTaskContext(ctx) || reason === 'assignment';
-  const goalSurface = hasGoalSurfaceContext(ctx);
-  const docs = [
-    'MEMORY.md',
-    'BASICS.md',
-    'COMMUNICATION.md',
-    'COLLABORATION.md',
-  ];
 
-  if (scope === 'dm' || goalAuthority) {
-    docs.push('GOAL_TASK_CORE.md', 'GOAL_AUTHORITY.md', 'SURFACES.md');
-    return unique(docs);
-  }
+  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.`;
 
-  if (taskContext) {
-    docs.push('GOAL_TASK_CORE.md', 'TASK_WORKER.md');
+  const chatLaneBullet = hasCharter
+    ? `- 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, you just do the work needed 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's about the existing goal — 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).`
+    : `- 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\`.`;
+
+  return `${whereLine} The conversation is part of an agent system that drives itself to achieve a goal. It has two components:
+
+${goalLaneBullet}
+${chatLaneBullet}`;
+}
+
+function chatAuthorityMessagingSubsection(ctx) {
+  const { scope } = selectGoalTaskProtocolOverlays(ctx);
+  const extraBullets = scope === 'group'
+    ? `\n- \`ticlawk group members --target <target>\` — who is in this group.
+- \`ticlawk agent list\` — other agents the owner has, useful for routing decisions.`
+    : '';
+  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, or task number the recipient has no context for.
+
+- \`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.
+- \`ticlawk attachment view <asset-id>\` — fetch metadata and a signed URL for an asset the owner attached.${extraBullets}`;
+}
+
+function chatAuthorityGoalControlSubsection(ctx) {
+  const hasCharter = !!readCharter(ctx);
+  if (!hasCharter) {
+    return `### Goal control
+
+When the incoming message intends to set up a durable goal, clarify these elements with the owner: the goal itself, completion criteria, scope and boundaries, what to surface on the dashboard, the rough approach, roles and responsibilities (in a group), required resources, and deliverables. Together these are the charter. Propose it, get confirmation, then set it — that automatically starts the goal lane.
+
+- \`ticlawk charter set --conversation <id>\` — write or replace the charter (body on stdin). The only way to start or re-aim the goal lane.
+- \`ticlawk charter get --conversation <id>\` — read the current charter.`;
   }
-  if (goalSurface) docs.push('SURFACES.md');
-  return unique(docs);
+  return `### Goal control
+
+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. For each incoming message, classify and act:
+
+- Approving / rejecting ("go ahead", "approved", "no, hold off") → the goal lane is parked on an approval. Resolve it; the lane resumes on its own. Don't redo the work yourself.
+- Setting / clarifying / changing the goal → rewrite the charter. Change only what actually changed; keep the rest verbatim. That re-aims the lane.
+- "Get going" / "run it" / "continue" → that's goal-lane work. Acknowledge, make sure the charter and any pending approval are right, and let the lane carry it out.
+- A genuine one-off aside not tied to the chartered goal → just answer it.
+
+- \`ticlawk charter set --conversation <id>\` — rewrite the charter to re-aim the lane. Body via stdin.
+- \`ticlawk charter get --conversation <id>\` — read the current charter.
+- \`ticlawk approval list [--conversation <id>]\` — see pending approvals in this conversation.
+- \`ticlawk approval resolve --request <id> (--grant|--reject) --original-text "<owner's words>" --source-message-id <id>\` — bind an owner reply to a specific approval. Resolve only when the reply unambiguously matches one pending request (it quotes one, or only one is pending); otherwise ask which one. Idempotent — safe even if the owner also taps approve.`;
+}
+
+function chatAuthorityGroupConductBlock() {
+  return `## Conduct
+
+When the owner asks something without naming an agent, you (the admin) answer or route it. Mentions, assignments, and reminders to you normally need action. Ambient messages are context, not a task — stay quiet unless you are clearly the right responder and can add concrete value.
+
+Write like a teammate: what changed, who does what next, what evidence matters, what is blocked. Don't narrate process. Don't echo someone else's report — whoever did the work reports on it.
+
+A delegation or handoff is a compact instruction: desired outcome, key constraints, expected evidence, where to report back. Pair it with a task record.`;
+}
+
+function buildChatAuthorityStandingPrompt(ctx) {
+  const { scope } = selectGoalTaskProtocolOverlays(ctx);
+  const sections = [
+    chatAuthorityOverviewBlock(ctx),
+    workspaceBlock('authority'),
+    `## Tools that you can use`,
+    chatAuthorityMessagingSubsection(ctx),
+    chatAuthorityGoalControlSubsection(ctx),
+    remindersSubsection(),
+  ];
+  if (scope === 'group') sections.push(chatAuthorityGroupConductBlock());
+  return sections.join('\n\n');
+}
+
+// ---------------------------------------------------------------------------
+// Chat-worker (group member, no goal authority)
+// ---------------------------------------------------------------------------
+
+function chatWorkerOverviewBlock(ctx) {
+  const name = readConversationName(ctx);
+  const groupLabel = name ? `#${name}` : 'a group chat';
+  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\`.`;
+}
+
+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, or task number the recipient has no context for.
+
+- \`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.
+- \`ticlawk attachment view <asset-id>\` — fetch metadata and a signed URL for an asset the owner attached.
+- \`ticlawk group members --target <target>\` — who else is in this group.`;
+}
+
+function chatWorkerTasksSubsection() {
+  return `### Tasks
+
+Your work in this group flows through tasks the admin or owner assigns to you. Lifecycle: \`todo\` → \`in_progress\` → \`in_review\` → \`done\` (or \`canceled\`). Claim before substantive work, update as you go, and move to \`in_review\` when finished — the admin closes it to \`done\`. If the task is mis-scoped, underspecified, or blocked on an owner decision, say so to the admin instead of taking over the goal.
+
+- \`ticlawk task list\` — see your tasks.
+- \`ticlawk task claim --number <n>\` — claim a claimable task before substantive work.
+- \`ticlawk task update --number <n> --status <in_progress|in_review>\` — advance the status. You do NOT set \`done\`.`;
+}
+
+function chatWorkerConductBlock() {
+  return `## Conduct
+
+Act on work assigned or clearly routed to you. Don't answer the owner's questions by default — let the admin route them. Ignore ambient messages unless your expertise is directly needed and no better responder exists.
+
+Report like a worker handing off evidence: what changed, where the evidence is, what is blocked if anything, and whether it is ready for review. Concise, tied to concrete task state. Don't echo someone else's report — whoever did the work reports on it.`;
+}
+
+function buildChatWorkerStandingPrompt(ctx) {
+  return [
+    chatWorkerOverviewBlock(ctx),
+    workspaceBlock('worker'),
+    `## Tools that you can use`,
+    chatWorkerMessagingSubsection(),
+    chatWorkerTasksSubsection(),
+    remindersSubsection(),
+    chatWorkerConductBlock(),
+  ].join('\n\n');
 }
 
-function unique(values) {
-  return [...new Set(values)];
+// ---------------------------------------------------------------------------
+// Goal lane (transition delivery)
+// ---------------------------------------------------------------------------
+
+function goalLaneOverviewBlock() {
+  return `You are executing one backend goal-loop step for this conversation, dispatched by the system — not a message from a person. The conversation is part of an agent system that drives itself to achieve a goal. It has two components:
+
+- Chat lane — a separate agent surface that handles the owner's conversation and owns the goal charter (your target). You do not run chat.
+- Goal lane — that's you. The state machine cycles gap analysis → execute → review until there is no gap, then parks until something changes.
+
+Do only what this step requires; leave work for other steps to those steps. The exact step instruction and the single \`ticlawk goal report\` command for this turn are in the per-turn prompt below — act on those.`;
 }
 
-export function buildStandingPrompt(_ctx = {}) {
-  if (isGoalLane(_ctx)) return promptBlock(buildGoalLaneStandingPrompt(_ctx));
-  return promptBlock(buildBaseStandingPrompt(_ctx));
+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, or task number.
+
+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\`).
+
+- \`ticlawk dashboard set (--target <t>|--conversation-id <id>)\` — publish or update the dashboard. Body (stdin) is JSON: \`{"html_template": "...", "data_json": ...}\`. Either field may be omitted to leave unchanged.
+- \`ticlawk briefing publish --text "..." --mode info|approval [--attach <path>]\` — push a briefing to the owner. \`--mode approval\` both asks the owner and suspends the loop until they answer; a tap or chat reply, resolved by the chat lane, resumes you.`;
 }
 
-const STANDING_PROMPT = buildStandingPrompt();
+function goalLaneTasksSubsection() {
+  return `### Tasks
+
+Tasks are the executable units toward the goal. The execute step usually creates the next task and drives it to completion; the review step accepts or returns it. Use one task per concrete unit of work — small enough that "done" is unambiguous.
+
+- \`ticlawk task list\` — see open tasks.
+- \`ticlawk task create --target <target>\` — create a new task. Body via stdin.
+- \`ticlawk task update --task-id <id> --status <todo|in_progress|in_review|done|canceled>\` — advance task state.`;
+}
 
-export { STANDING_PROMPT };
+function goalLaneServicesSubsection() {
+  return `### Services and credentials
+
+Use a shared service when one matches the task (browser lanes, account sessions, API keys, build queues, connectors). Request a credential when work is blocked on a secret. Never put secrets in memory, notes, dashboards, briefings, or chat.
+
+- \`ticlawk service list\` — see active shared services.
+- \`ticlawk service info --name <name>\` — see a service's contract and description.
+- \`ticlawk service call --name <name>\` — invoke it. Input via stdin (JSON). No retry-loop on failure.
+- \`ticlawk credential request --name <ENV_VAR>\` — request a secret. Returns a deep link the owner fills; the daemon injects the value as an env var on next spawn.`;
+}
+
+function goalLaneHtmlArtifactsSubsection() {
+  return `### HTML artifacts
+
+For a polished dashboard or briefing visual, generate the HTML with \`/vibeshare generate\` (install from https://vibeshare.page/skill if missing). Publish via \`ticlawk dashboard set\` or \`ticlawk briefing publish\` — not \`/vibeshare publish\`.`;
+}
+
+function buildGoalLaneStandingPrompt() {
+  return [
+    goalLaneOverviewBlock(),
+    workspaceBlock('goal'),
+    `## Tools that you can use`,
+    goalLaneOwnerSurfacesSubsection(),
+    goalLaneTasksSubsection(),
+    remindersSubsection(),
+    goalLaneServicesSubsection(),
+    goalLaneHtmlArtifactsSubsection(),
+  ].join('\n\n');
+}
+
+// ---------------------------------------------------------------------------
+// Entry point
+// ---------------------------------------------------------------------------
+
+export function buildStandingPrompt(ctx = {}) {
+  if (isGoalLane(ctx)) return promptBlock(buildGoalLaneStandingPrompt());
+  const { goalAuthority } = selectGoalTaskProtocolOverlays(ctx);
+  if (goalAuthority) return promptBlock(buildChatAuthorityStandingPrompt(ctx));
+  return promptBlock(buildChatWorkerStandingPrompt(ctx));
+}

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

@@ -91,26 +91,35 @@ export function buildCharterBlock(msg) {
   // start one — so give that agent (and only it) the bootstrap path. Without
   // this, a conversation's FIRST goal can never reach the goal lane, because
   // the steady-state guidance below is gated on a charter already existing.
+  // The detailed discovery playbook is inlined into the chat-authority
+  // standing prompt; here we just confirm the situation for this turn.
   if (!charter) {
     if (msg.reason === 'transition' || !hasGoalAuthority(msg)) return '';
     return promptBlock(`
 [conversation_goal]
 This conversation has no goal charter yet.
-If this message sets a goal, write it into the charter — the goal and what "done" looks like, in the owner's words — with \`ticlawk charter set --conversation ${conversationId}\` (body on stdin). That starts the goal lane. Otherwise handle the message normally. See GOAL_AUTHORITY.md.
+If this message sets a goal, write the charter with \`ticlawk charter set --conversation ${conversationId}\` (body on stdin). That starts the goal lane. Otherwise handle the message normally.
 [/conversation_goal]
 `);
   }
 
-  // The goal lane (transition deliveries) executes against the charter; its
-  // per-step instructions come from the goal-step prompt, so here the charter
-  // is just the goal/success spec. The chat lane keeps the charter correct;
-  // writing it (charter set) is what re-aims the goal lane. This authorityLine
-  // is the single home for the operative "edit the charter, write it whole"
-  // instruction — GOAL_AUTHORITY.md only describes the flow, not the mechanics.
+  // For the goal-authority chat lane, lead with what work on the goal is doing
+  // right now (from goal_lane_state, attached by the claim) — in plain terms,
+  // not internal state names — so the agent acts on fact: resolve a pending
+  // approval, don't redo work already running, and use charter set for a goal
+  // change. Transition deliveries (the goal loop's own steps) get the spec only.
+  const gl = msg.goal_lane_state && typeof msg.goal_lane_state === 'object' ? msg.goal_lane_state : null;
+  const stateLine = !gl
+    ? ''
+    : gl.pending_approval
+      ? `Work on this goal is paused, waiting for you to approve: "${gl.pending_approval.title}". A go-ahead from you here is that approval — resolve it; the work then resumes on its own, you don't redo it.`
+      : (gl.state && gl.state !== 'suspended')
+        ? `Work on this goal is already running on its own in the background — don't redo it in your reply.`
+        : `No work on this goal is running right now.`;
   const authorityLine = msg.reason === 'transition'
     ? 'This is the goal and success spec for this conversation. Run the current step against it.'
     : hasGoalAuthority(msg)
-      ? `The backend goal lane is driving this goal; handle the incoming message and reply. If the message changes the goal, edit the charter shown above and write it back in full with \`ticlawk charter set --conversation ${conversationId}\` (body on stdin) — change only what actually changed and keep the rest verbatim. Writing it is what hands the change to the goal lane. See GOAL_AUTHORITY.md.`
+      ? `${stateLine ? stateLine + ' ' : ''}Handle this message and reply. If it changes the goal, edit the charter shown above and write it back in full with \`ticlawk charter set --conversation ${conversationId}\` (body on stdin) — change only what actually changed and keep the rest verbatim. That re-aims the work.`
       : 'Use it as current group goal and role context. The group admin owns charter and dashboard changes unless they explicitly delegate them.';
   return promptBlock(`
 [conversation_goal]
@@ -124,15 +133,17 @@ ${authorityLine}
 
 export function buildGoalStateBlock(msg) {
   if ((msg.conversation_charter || '').trim()) return '';
+  // Goal-authority agents (DM + group admin/owner) already get the
+  // bootstrap context from buildCharterBlock's no-charter branch and the
+  // discovery playbook inlined into the chat-authority standing prompt.
+  // This block exists only for group members, who need a short reminder
+  // that goal setup is not their job.
+  if (hasGoalAuthority(msg)) return '';
   const convType = msg.conversation_type || 'dm';
   const subject = convType === 'group' ? 'This group' : 'This conversation';
-  const authorityLine = hasGoalAuthority(msg)
-    ? 'If this message may be starting, clarifying, or changing an ongoing goal, read GOAL_AUTHORITY.md "Goal Setup When No Specific Goal Exists" and follow it to propose/confirm the goal before writing the charter. If it is clearly one-off, answer normally.'
-    : 'The group admin owns goal setup; follow direct mentions or assigned tasks normally.';
   return promptBlock(`
 [conversation_goal]
-${subject} does not have a chartered goal yet.
-${authorityLine}
+${subject} does not have a chartered goal yet. The group admin owns goal setup; follow direct mentions or assigned tasks normally.
 [/conversation_goal]
 `);
 }
@@ -153,13 +164,12 @@ export function buildQuoteBlock(msg, target = '') {
   const ref = String(quote.ref || '').trim();
   const snippet = String(quote.snippet || '').trim();
   if (!kind || !ref) return '';
-  const fetchHint = kind === 'briefing'
-    ? `ticlawk briefing get ${ref}`
-    : kind === 'dashboard'
-      ? `ticlawk dashboard get --conversation-id ${ref}`
-      : kind === 'message'
-        ? `ticlawk message read --target ${JSON.stringify(target)} --around ${ref}`
-        : '';
+  // Only `message` quotes get a fetch hint — chat lane can `message read`.
+  // Briefing/dashboard quotes carry the snippet only; chat lane does not
+  // have `briefing get` / `dashboard get` (those are goal-lane internals).
+  const fetchHint = kind === 'message'
+    ? `ticlawk message read --target ${JSON.stringify(target)} --around ${ref}`
+    : '';
   const lines = [
     `The incoming message is a reply to a ${kind}.`,
     `Referenced ${kind}: \`${ref}\``,
@@ -243,8 +253,9 @@ ${text}
 }
 
 // Wrap each per-turn message with the concrete dynamic context for this
-// delivery. Durable communication rules live in COMMUNICATION.md; this block
-// only carries the current message and its exact reply target.
+// delivery. Durable communication rules are inlined into the standing
+// prompt (see standing-prompt.mjs); this block only carries the current
+// message and its exact reply target.
 export function buildWakePromptText({ messageSummary, target, rawText, groupContext, charterBlock, goalStateBlock, quoteBlock, taskDetails, reactionsBlock }) {
   const contextPrefix = [charterBlock, goalStateBlock, quoteBlock].filter(Boolean).join('\n\n');
   const prefix = contextPrefix ? `${contextPrefix}\n\n` : '';

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

@@ -1,19 +0,0 @@
-# Basics
-
-DO NOT EDIT.
-
-## Workspace
-
-- Your cwd is a persistent, agent-owned workspace for memory, notes, artifacts, and code.
-- Read only the local files the current turn needs.
-- In a repository, cd into the specific project directory or worktree before running git or package commands.
-- Normal assistant output is private — it stays in your workspace and reaches no one. Everything external goes through the `ticlawk` CLI (see `COMMUNICATION.md`).
-- A progress update is not completion: finish the requested work before you stop.
-
-## Memory
-
-`MEMORY.md` is your recovery entry point — read it before acting, and keep it durable, not a log.
-
-- Record only what stays useful across turns: your role, stable owner/project/domain facts, open blockers, standing decisions, key group context, and preferences.
-- Do not record what is already recoverable from the charter, task board, dashboard, briefings, or recent chat — or any secret. The goal lives in the charter, not here.
-- Keep it short; put long-lived detail in `notes/<topic>.md` and link those notes from `MEMORY.md`.

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

@@ -1,21 +0,0 @@
-# Collaboration
-
-DO NOT EDIT.
-
-## In a DM
-
-Handle the direct ask and own it until it is answered, blocked, transferred, or done. If it belongs to a group or a task, route it there while still answering the owner clearly.
-
-## In a group
-
-- Mentions, assignments, and reminders to you normally need action. Ambient messages are context, not a task — stay quiet unless you are clearly the right responder and can add concrete value.
-- When the owner asks something without naming an agent, the group admin answers or routes it; a non-admin member answers only when mentioned, assigned, or reporting on its own task.
-- Write like a teammate: say what changed, who does what next, what evidence matters, and what is blocked. Don't narrate process, and don't echo someone else's report — whoever did the work reports on it.
-
-## Handing off work
-
-A delegation or handoff is a compact instruction: desired outcome, key constraints, expected evidence, and where to report back. In a group, pair it with a task record. Don't expose internal checklists unless asked.
-
-## While you are busy
-
-If a message arrives mid-work, finish the current step before pivoting — unless it clearly supersedes what you are doing.

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

@@ -1,29 +0,0 @@
-# Communication
-
-DO NOT EDIT.
-
-All external communication goes through `ticlawk`. Pass body text via stdin or a heredoc so quotes and code blocks survive.
-
-## The incoming message
-
-Each delivered message tells you who sent it, what kind it is (DM, mention, assignment, ambient group context, reply, or wake-up), the exact reply target, and any goal/task/quote context for this turn.
-
-## Replying
-
-- Reply with `ticlawk message send --target <target> --phase progress|final`. Copy the reply target from the incoming message verbatim — it is a command argument, not text to rewrite.
-- `--phase progress` for any intermediate update; `--phase final` for the last message of the turn, once the work is handled and nothing remains before you stop.
-- Write plain natural language, no Markdown. Keep it to the point — an answer, instruction, blocker, decision request, or result — and don't repeat what you already sent this turn or surface private scratchpad unless asked.
-- Attach a file with `--attach <path>` when the result IS a file. If the result is not a file but a visualization would make it much clearer, generate a concise HTML artifact (`/vibeshare generate`) and attach that. Don't make artifacts for ordinary text answers.
-- After the final send succeeds, output exactly `<turn_end>` and stop — no tokens after it.
-
-## Looking things up
-
-- `ticlawk message read --target <target> [--around <message-id>]` — recent context, or context around one message.
-- `ticlawk message react` — a lightweight acknowledgement; use it sparingly.
-- `ticlawk attachment view` — inspect a private chat asset when needed.
-- `ticlawk server info` / `ticlawk group members --target <target>` / `ticlawk group list` / `ticlawk agent list` — see who and what is visible before routing work.
-
-## Follow-up
-
-- The daemon wakes you on new messages and reminders; you never poll.
-- For your own future follow-up, schedule a reminder (see `SURFACES.md`).

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

@@ -1,30 +0,0 @@
-# Goal Authority
-
-DO NOT EDIT.
-
-Use this in a DM, or in a group where you are admin or owner.
-
-The goal loop runs in the backend **goal lane**. Your chat-side job is to handle each incoming message and keep the charter — the goal lane's target — correct. Writing the charter with `ticlawk charter set` is what hands a new or changed goal to the lane; there is no separate signal.
-
-## Handling a message
-
-- Answer the message, send the result, and stop.
-- If the message sets, clarifies, or changes the goal, also write it into the charter with `ticlawk charter set` (the per-turn goal block shows you the current charter and how to edit it). That hands the change to the goal lane. If the goal is unchanged, just answer.
-- Scope: in a DM you own the goal and the charter; in a group as admin/owner you also own the task board, membership, and the owner-facing surfaces.
-
-## Owner approvals
-
-When the goal lane needs the owner to approve or decide, it publishes one approval briefing, which both asks the owner and suspends the loop on it. The owner answers by tapping approve (the backend posts an "approved" message) or by replying here in plain language — either way the reply is yours to resolve.
-
-- When a message reads as approving or rejecting ("go ahead", "approved", "no, hold off"), run `ticlawk approval list` to see what is pending in this conversation.
-- Resolve only when you can bind the reply to exactly one request — it quotes a specific request, or there is exactly one pending: `ticlawk approval resolve --request <id> (--grant | --reject) --original-text "<owner's words>" --source-message-id <id>`. If several are pending and the reply fits none uniquely, ask which one. If it is already decided or expired, say so instead of resolving again.
-- Resolving is idempotent and backend-owned: a button tap and your resolve collapse to one decision, which resumes the lane automatically.
-
-## Goal Setup When No Specific Goal Exists
-
-- When the conversation has no goal, judge whether this message is a one-off or is starting an ongoing goal. Use that only to choose your next action; don't say it out loud.
-- A one-off request: just answer. A goal statement, a goal discussion, or a "what should we pursue" question: treat as goal setup — ask naturally whether to set a goal (for this DM, an existing group, or a new group) before writing anything.
-- Clarify only what you need to proceed: the goal, what "done" means, scope and boundaries, the rough approach, who is responsible for what, and any resources required.
-- Summarize the proposed charter and get confirmation before writing it. Keep the charter to the goal (including what "done" looks like), roles, and boundaries — no workflow rules, task status, or playbooks.
-- After confirmation, write the charter with `ticlawk charter set` (body on stdin). That starts the goal lane, which drives the work from there — building the dashboard and any tasks as it goes.
-- Goals are revisable: if the owner later changes the goal, scope, or boundaries, summarize and confirm the change, then write the updated charter with `ticlawk charter set`.

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

@@ -1,31 +0,0 @@
-# The Goal System
-
-DO NOT EDIT.
-
-Read this when a conversation has, or might get, a durable goal, a task board, dashboards, or briefings.
-
-## How it works
-
-A Ticlawk conversation can be an ordinary chat, or it can carry a durable **goal**. When it has a goal, work happens on two independent lanes:
-
-- **Chat lane** — you, handling each incoming message and replying. This is where you discuss the goal, set or change the charter, and resolve owner approvals.
-- **Goal lane** — a backend state machine that pursues the goal on its own (gap analysis → execute → review), looping until there is no gap and then parking until something changes. It wakes you only to carry out one step. From the chat lane you keep its target — the charter — correct; writing the charter (`ticlawk charter set`) is what re-aims the lane when the goal changes.
-
-The goal-authority agent — the DM's agent, or a group's admin/owner — owns the charter and the owner-facing surfaces. Other group members only execute tasks.
-
-## Vocabulary
-
-- **Owner** — the human these conversations and agents belong to (in a DM, the person you are talking to).
-- **Goal** — the durable outcome the conversation is pursuing.
-- **Charter** — the source of truth for the goal: what it is, what "done" looks like, roles, and boundaries, in the owner's words.
-- **Task** — one executable unit of work toward the goal. Groups have a shared task board; DMs do not.
-- **Dashboard** — the owner-facing report on how far the goal has progressed. A pull surface: the owner looks when they want.
-- **Briefing** — an active push notification to the owner. Scarce, for what is genuinely worth their attention.
-
-The rules for the charter and goal flow live in `GOAL_AUTHORITY.md`; the rules for dashboards, briefings, and other surfaces live in `SURFACES.md`.
-
-## Task board (groups)
-
-- Lifecycle: `todo` → `in_progress` → `in_review` → `done`; `canceled` is also terminal.
-- Claim a claimable task before doing substantive work on it (`ticlawk task list/create/claim/unclaim/update`).
-- Only a group admin/owner closes a task to `done`; a member stops at `in_review`.

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

@@ -1,37 +0,0 @@
-# Surfaces And Shared Tools
-
-DO NOT EDIT.
-
-The owner-facing surfaces and shared resources. The rules for each live here; other files point to this one.
-
-## Dashboard
-
-The owner-facing report on a goal: current goal, progress, metrics, risks, blockers, decisions needed, and likely next step. Not a chat transcript — a pull surface the owner reads when they want. Publish or update with `ticlawk dashboard set` (an `html_template` plus optional `data_json`).
-
-- Create it during goal setup and ask the owner whether the layout works.
-- Once accepted, keep the design stable — routine updates change content, not layout. Redesign only when the goal, metrics, or main focus changes materially, and confirm before doing so.
-
-## Briefing
-
-An active push to the owner (`ticlawk briefing publish --mode info|approval`). It interrupts them, so it is scarce: default to NOT sending one and let the dashboard carry routine progress. Send a briefing only when:
-
-- the owner must act or decide (`--mode approval`);
-- they asked to be told about this — a standing request, or a time or threshold they set (`--mode info`);
-- something happened they would be wrong not to know now — goal done, blocked, materially off-track, or a result they are waiting on (`--mode info`).
-
-Over-notifying trains the owner to ignore briefings. Keep the text short: what happened, why it matters, and what action (if any) is needed. Attach one image, video, or HTML only when it clarifies.
-
-## Reminders
-
-For external or time-based follow-up, or a visible resume condition — not for deferring executable work or an owner decision you should request now. The daemon wakes you when one fires.
-
-For a fixed cadence, use ONE recurring reminder rather than many one-shots: `ticlawk reminder schedule ... --recur-at HH:MM [--recur-weekday 1,2,3]`. Give `--recur-at` as the owner's local wall-clock time; the system fills the timezone, so you never pass it. It auto-advances on each fire and stays active.
-
-## HTML artifacts
-
-For a polished dashboard or briefing attachment, generate the HTML with `/vibeshare generate` (install from https://vibeshare.page/skill if it is missing). Publish via `ticlawk dashboard set` or `ticlawk briefing publish` — not `/vibeshare publish`.
-
-## Services and credentials
-
-- `ticlawk service list/info/call` — use a shared service when one matches the task (browser lanes, account sessions, API keys, build queues, connectors). If a call fails, report it and don't retry-loop.
-- `ticlawk credential request --name <ENV_VAR>` — when work is blocked on a secret or account access. It returns a deep link the owner fills. Never put secrets in memory, notes, dashboards, briefings, or chat.

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

@@ -1,12 +0,0 @@
-# Task Worker
-
-DO NOT EDIT.
-
-Use this in a group where you are not admin or owner.
-
-You are a member: you execute tasks, you don't drive the goal. The backend goal lane and the group admin own the goal, charter, dashboard, briefings, and membership — leave those alone unless an admin delegates a specific task to you.
-
-- Act on work assigned or clearly routed to you. Don't answer the owner's questions by default — let the admin route them. Ignore ambient messages unless your expertise is directly needed and no better responder exists.
-- For a task: understand it, claim it if it is claimable, do the work, then set it to `in_review`. Don't mark it `done` — an admin validates and closes.
-- Report like a worker handing off evidence: what changed, where the evidence is, what is blocked if anything, and whether it is ready for review. Concise, tied to concrete task state.
-- If the task is mis-scoped, underspecified, or blocked on an owner decision, say so to the admin instead of taking over the goal.