ticlawk 0.1.17-dev.11 → 0.1.17-dev.13

package/README.md

@@ -230,8 +230,8 @@ Commands:
   profile  list or switch saved local identities
   message  send/read chat messages (agent CLI surface)
   task     claim/update/list tasks (agent CLI surface)
-  goal     report FSM transitions / signal goal changes (agent CLI surface)
-  approval canonical goal-loop approval request/resolve (agent CLI surface)
+  goal     report FSM transitions (agent CLI surface)
+  approval resolve/list goal-loop approvals (agent CLI surface)
   charter  get/set conversation goal and role spec (agent CLI surface)
   group    create/list/delete groups, manage charters/members (agent CLI surface)
   dashboard   set/get conversation dashboards (agent CLI surface)

package/bin/ticlawk.mjs

@@ -57,9 +57,7 @@ import {
   runMessageCheckCommand,
   runMessageReactCommand,
   runMessageReadCommand,
-  runGoalChangedCommand,
   runGoalReportCommand,
-  runApprovalRequestCommand,
   runApprovalResolveCommand,
   runApprovalListCommand,
   runMessageSearchCommand,
@@ -134,8 +132,8 @@ Commands:
   profile  list or switch saved local identities
   message  send/read chat messages (agent CLI surface)
   task     claim/update/list tasks (agent CLI surface)
-  goal     report FSM transitions / signal goal changes (agent CLI surface)
-  approval canonical goal-loop approval request/resolve (agent CLI surface)
+  goal     report FSM transitions (agent CLI surface)
+  approval resolve/list goal-loop approvals (agent CLI surface)
   charter  get/set conversation goal and role spec (agent CLI surface)
   group    create/list/delete groups, manage charters/members (agent CLI surface)
   dashboard   set/get conversation dashboards (agent CLI surface)
@@ -487,10 +485,6 @@ async function main() {
       process.exitCode = await runGoalReportCommand(args);
       return;
     }
-    if (sub === 'changed') {
-      process.exitCode = await runGoalChangedCommand(args);
-      return;
-    }
     console.error(`unknown goal subcommand: ${sub}`);
     process.exit(1);
   }
@@ -501,10 +495,6 @@ async function main() {
       console.log(AGENT_COMMAND_HELP.approval);
       return;
     }
-    if (sub === 'request') {
-      process.exitCode = await runApprovalRequestCommand(args);
-      return;
-    }
     if (sub === 'resolve') {
       process.exitCode = await runApprovalResolveCommand(args);
       return;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticlawk",
-  "version": "0.1.17-dev.11",
+  "version": "0.1.17-dev.13",
   "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/adapters/ticlawk/api.mjs

@@ -302,31 +302,6 @@ export async function reportGoalTransition({
   });
 }
 
-export async function noteGoalChanged({ actingAgentId, conversationId }) {
-  return apiFetch('/api/agent/goal/changed', {
-    method: 'POST',
-    body: JSON.stringify({
-      acting_as_agent_id: actingAgentId,
-      conversation_id: conversationId,
-    }),
-  });
-}
-
-export async function requestGoalApproval({
-  actingAgentId, conversationId, title, detail, ttlSeconds,
-}) {
-  return apiFetch('/api/agent/approval/request', {
-    method: 'POST',
-    body: JSON.stringify({
-      acting_as_agent_id: actingAgentId,
-      conversation_id: conversationId,
-      title,
-      detail: detail ?? null,
-      ttl_seconds: ttlSeconds ?? null,
-    }),
-  });
-}
-
 export async function listGoalApprovals({ actingAgentId, conversationId }) {
   const params = new URLSearchParams();
   params.set('acting_as_agent_id', actingAgentId);

package/src/cli/agent-commands.mjs

@@ -383,51 +383,6 @@ export async function runGoalReportCommand(args) {
   return exitFromStatus(res.statusCode);
 }
 
-export async function runGoalChangedCommand(args) {
-  const env = requireAgentEnv();
-  const conversationId = getArg(args, 'conversation') || getArg(args, 'conversation-id') || env.currentConversationId;
-  if (!conversationId) {
-    console.error('--conversation is required');
-    return 2;
-  }
-  const res = await daemonRequest({
-    method: 'POST',
-    path: '/agent/goal/changed',
-    headers: commonHeaders(env),
-    body: { conversation_id: conversationId },
-  });
-  printJson(res.body);
-  return exitFromStatus(res.statusCode);
-}
-
-export async function runApprovalRequestCommand(args) {
-  const env = requireAgentEnv();
-  const conversationId = getArg(args, 'conversation') || getArg(args, 'conversation-id') || env.currentConversationId;
-  const title = getArg(args, 'title');
-  if (!conversationId) {
-    console.error('--conversation is required');
-    return 2;
-  }
-  if (!title) {
-    console.error('--title is required');
-    return 2;
-  }
-  const ttlRaw = getArg(args, 'ttl-seconds');
-  const res = await daemonRequest({
-    method: 'POST',
-    path: '/agent/approval/request',
-    headers: commonHeaders(env),
-    body: {
-      conversation_id: conversationId,
-      title,
-      detail: getArg(args, 'detail'),
-      ttl_seconds: ttlRaw != null ? Number(ttlRaw) : undefined,
-    },
-  });
-  printJson(res.body);
-  return exitFromStatus(res.statusCode);
-}
-
 export async function runApprovalResolveCommand(args) {
   const env = requireAgentEnv();
   const requestId = getArg(args, 'request') || getArg(args, 'request-id');
@@ -1481,7 +1436,7 @@ export const AGENT_COMMAND_HELP = {
     Compatibility alias for group admin commands. Prefer \`ticlawk group ...\`
     for groups and \`ticlawk charter ...\` for conversation charters.
 `,
-  goal: `ticlawk goal <report|changed>
+  goal: `ticlawk goal <report>
     Goal-lane (FSM) control. Normally invoked from a goal-step turn, not by hand.
   ticlawk goal report --transition <id> --outcome <outcome> [--conversation <id>] [--detail <text>] [--current-task <task-id>]
     Report the outcome of the current FSM step and advance the state machine.
@@ -1490,16 +1445,14 @@ export const AGENT_COMMAND_HELP = {
       gap_analysis: gap | no_gap | wait
       execute:      task_completed | needs_approval | blocked
       review:       accepted | rejected
-  ticlawk goal changed [--conversation <id>]
-    Signal that the conversation's goal changed; wakes the FSM into gap analysis.
+  (To change a goal, write the charter with \`ticlawk charter set\` — that re-aims the goal lane.)
 `,
-  approval: `ticlawk approval <request|resolve|list>
-    Canonical goal-loop approval flow. The goal lane parks on an approval and is
-    resumed by exactly one idempotent decision (button token OR chat resolver).
-  ticlawk approval request --title "<text>" [--conversation <id>] [--detail <text>] [--ttl-seconds <n>]
-    Park a pending owner approval on the goal_session (after EXECUTE reports
-    needs_approval). Returns request_id plus a one-time button action token.
-    --conversation defaults to the current goal-turn conversation.
+  approval: `ticlawk approval <resolve|list>
+    Goal-loop approval resolution (chat lane). The goal lane PARKS an approval by
+    publishing an approval briefing (\`ticlawk briefing publish --mode approval\`),
+    which both asks the owner and suspends the loop on it. The owner answers by
+    tapping approve (which posts an "approved" message) or replying in plain
+    language — either way the chat lane resolves it here, idempotently.
   ticlawk approval list [--conversation <id> | --target "<target>"]
     List pending approval requests in the conversation. Use this from the chat
     lane to find which request an owner's natural-language approval refers to.

package/src/core/agent-cli-handlers.mjs

@@ -416,51 +416,6 @@ export async function handleGoalReport(req, body, ctx) {
   }
 }
 
-export async function handleGoalChanged(req, body, ctx) {
-  const actingAgentId = getActingAgentId(req, body);
-  const v = validateActingAgent(actingAgentId, ctx);
-  if (!v.ok) return { status: v.status, body: { error: v.error } };
-  const conversationId = body?.conversation_id || getCurrentConversationId(req, body);
-  if (!conversationId) return { status: 400, body: { error: 'conversation_id is required' } };
-  try {
-    const data = await api.noteGoalChanged({ actingAgentId, conversationId });
-    debugLog('agent-cli', 'goal.changed', {
-      actingAgentId,
-      conversationId,
-      goalVersion: data?.goal_version,
-    });
-    return { status: data?.ok ? 200 : 400, body: data };
-  } catch (err) {
-    return { status: err?.status || 500, body: { error: err?.message || 'goal changed failed' } };
-  }
-}
-
-export async function handleApprovalRequest(req, body, ctx) {
-  const actingAgentId = getActingAgentId(req, body);
-  const v = validateActingAgent(actingAgentId, ctx);
-  if (!v.ok) return { status: v.status, body: { error: v.error } };
-  const conversationId = body?.conversation_id || getCurrentConversationId(req, body);
-  if (!conversationId) return { status: 400, body: { error: 'conversation_id is required' } };
-  if (!body?.title) return { status: 400, body: { error: 'title is required' } };
-  try {
-    const data = await api.requestGoalApproval({
-      actingAgentId,
-      conversationId,
-      title: body.title,
-      detail: body.detail || null,
-      ttlSeconds: body.ttl_seconds || null,
-    });
-    debugLog('agent-cli', 'approval.request', {
-      actingAgentId,
-      conversationId,
-      requestId: data?.request_id,
-    });
-    return { status: data?.ok ? 200 : 400, body: data };
-  } catch (err) {
-    return { status: err?.status || 500, body: { error: err?.message || 'approval request failed' } };
-  }
-}
-
 export async function handleApprovalList(req, query, ctx) {
   const actingAgentId = getActingAgentId(req, query);
   const v = validateActingAgent(actingAgentId, ctx);

package/src/core/http.mjs

@@ -39,9 +39,7 @@ import {
   handleReminderSchedule,
   handleReminderSnooze,
   handleReminderUpdate,
-  handleGoalChanged,
   handleGoalReport,
-  handleApprovalRequest,
   handleApprovalResolve,
   handleApprovalList,
   handleServerInfo,
@@ -155,18 +153,6 @@ export function startLocalHttpServer({ port, adapter, ctx }) {
         const r = await handleGoalReport(req, body, cliCtx);
         return writeJson(res, r.status, r.body);
       }
-      if (urlNoQuery === '/agent/goal/changed' && method === 'POST') {
-        const body = await readJsonBody(req);
-        if (body === null) return writeJson(res, 400, { error: 'invalid json body' });
-        const r = await handleGoalChanged(req, body, cliCtx);
-        return writeJson(res, r.status, r.body);
-      }
-      if (urlNoQuery === '/agent/approval/request' && method === 'POST') {
-        const body = await readJsonBody(req);
-        if (body === null) return writeJson(res, 400, { error: 'invalid json body' });
-        const r = await handleApprovalRequest(req, body, cliCtx);
-        return writeJson(res, r.status, r.body);
-      }
       if (urlNoQuery === '/agent/approval/resolve' && method === 'POST') {
         const body = await readJsonBody(req);
         if (body === null) return writeJson(res, 400, { error: 'invalid json body' });

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

@@ -24,10 +24,10 @@ const STEP_GUIDES = {
   },
   execute: {
     title: 'EXECUTE',
-    body: `Do the next concrete unit of work toward the goal (or drive the current task to completion). Send routine interim progress with \`ticlawk message send --phase progress\`; if an update clears the briefing bar below (e.g. it is a result the owner explicitly asked to be told about), surface it as a briefing instead.
+    body: `Do the next concrete unit of work toward the goal (or drive the current task to completion). Keep progress on the dashboard (\`ticlawk dashboard set\`); the goal lane reaches the owner only through the dashboard and briefings — never \`message send\`.
 - When the unit of work is finished and ready to be checked, report outcome=task_completed.
-- If you cannot proceed without an owner approval, decision, or permission, park ONE canonical approval with \`ticlawk approval request --title "<what you need approved>" [--detail "<context>"]\`, tell the owner what you need and why, then report outcome=needs_approval. The owner's approval (button or a natural-language reply) resumes you automatically.
-- If you are blocked by something else (missing input, external failure, a needed resource), explain it to the owner, then report outcome=blocked.`,
+- If you cannot proceed without something only the owner can grant — a decision, a permission, or approval to spend money or use a resource — ask for it with ONE approval briefing: \`ticlawk briefing publish --mode approval\` (short: what you need and why). That single call both asks the owner and suspends the loop on the approval. Then report outcome=needs_approval. Their answer (tapping approve, or a natural-language reply) resumes you automatically.
+- If you are blocked by something an owner decision cannot fix — an external failure, or a missing input no decision of theirs unblocks — surface it with \`ticlawk briefing publish --mode info\` only if they would be wrong not to know, then report outcome=blocked.`,
     outcomes: ['task_completed', 'needs_approval', 'blocked'],
   },
   review: {
@@ -100,22 +100,18 @@ export function buildGoalStepPrompt(msg) {
 
   if (guide) {
     sections.push([
-      `[goal_step] You are running the goal loop for this conversation. This is a backend FSM step, not a user message — do NOT treat it as something to reply to.`,
+      `[goal_step] You are running one step of the goal loop for this conversation — a backend FSM step. Act on it and report the outcome; there is no message to reply to.`,
       ``,
       `Current step: ${guide.title}`,
       guide.body,
       ``,
-      `Briefing rule (independent of which step you are on): a briefing (\`ticlawk briefing publish\`) interrupts the owner — it is only for things worth their attention. Default to NOT sending one; routine progress belongs on the dashboard (the owner pulls it) or a chat \`ticlawk message send\`. Send a briefing only when one of these holds:`,
-      `  (a) the owner must act or decide — e.g. an approval you parked (\`--mode approval\`);`,
-      `  (b) the owner asked to be told about this — a standing request, a scheduled time, or a threshold they set (\`--mode info\`);`,
-      `  (c) something happened the owner would be wrong not to know now — goal done, blocked, materially off-track, or a result they are waiting on (\`--mode info\`).`,
-      `If you are unsure, it is NOT a briefing — put it on the dashboard. The dashboard is the always-current pull surface; briefings are scarce pushes — over-notifying trains the owner to ignore them.`,
+      `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.`,
       ``,
       `When the step is done, advance the state machine by running EXACTLY ONE report:`,
       `  ${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 Ticlawk surfaces: \`ticlawk message send --target ${target}\` (chat), \`ticlawk briefing publish\` (push, per the rule above), \`ticlawk dashboard set\` (the goal report). 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, or task number.`,
+      `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, or task number.`,
       `[/goal_step]`,
     ].join('\n'));
   } else {

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

@@ -14,6 +14,6 @@ DO NOT EDIT.
 
 `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, active goals, open blockers, standing decisions, key group context, and preferences.
-- Do not record what is already recoverable from the task board, dashboard, briefings, or recent chat — or any secret.
+- 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/GOAL_AUTHORITY.md

@@ -4,27 +4,32 @@ DO NOT EDIT.
 
 Use this in a DM, or in a group where you are admin or owner.
 
-The goal's execution loop runs in the backend **goal lane**, not here and not inside your reply — you do not run it. Your job on the chat side is to handle the incoming message and keep the charter correct, so the goal lane is pursuing the right target. When the goal is set or changes, wake the lane with `ticlawk goal changed --conversation <id>`.
+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 and do what it asks, then send the result. That ends your turn — do not start gap analysis or execution; the goal lane does that.
-- If the message sets, clarifies, or changes the goal: after answering, update the charter (when you have authority) and run `ticlawk goal changed`. If the goal is unchanged, just answer — there is nothing to signal.
-- Scope: in a DM you own the goal and execute directly (no task board); in a group as admin/owner you also own the task board, membership, and the owner-facing surfaces.
+The goal lane does the goal's actual work — it runs the loop and carries out the goal's tasks (experiments, builds, and the like). Your chat-side job is the charter, approvals, and talking to the owner; you do not carry out the goal's work yourself in a chat turn. Read the incoming message as one of:
+
+- **Approving or rejecting** something ("go ahead", "approved", "no, hold off") — the goal lane is waiting on an approval. Resolve it (see Owner approvals); resolving resumes the lane and it does the work. Don't do the work yourself.
+- **Setting, clarifying, or changing the goal** — write it into the charter with `ticlawk charter set` (the per-turn goal block shows the current charter and how to edit it). That re-aims the lane.
+- **Telling you to start or continue the goal's work** ("get going", "run it") — that work belongs to the goal lane. Don't run experiments, builds, or its tasks here. Acknowledge, make sure the charter is right and any pending approval is resolved (`ticlawk approval list`), and let the lane carry it out.
+- **A genuine one-off aside**, not part of pursuing the chartered goal — just answer it.
+
+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 parks and posts one approval request. The owner answers by tapping the button (the backend handles that) or by replying here in plain language — the reply is yours to resolve.
+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 — don't guess. 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, and that decision resumes the lane. You do not resume it yourself.
+- 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, decide whether this message is a one-off or is starting, clarifying, or changing an ongoing goal. Use that only to choose your next action; don't say it out loud.
+- 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, roles, success criteria, and boundaries — no workflow rules, task status, or playbooks.
-- After confirmation: write the charter (if you have authority), create and publish the initial dashboard and ask the owner whether its layout works (see `SURFACES.md`), then run `ticlawk goal changed` to hand the goal to the lane. Add reminders or seed group tasks only when useful.
-- Goals are revisable: if the owner later changes the goal, scope, or boundaries, summarize and confirm the change, update the charter and surfaces, then run `ticlawk goal changed` again.
+- 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

@@ -9,7 +9,7 @@ Read this when a conversation has, or might get, a durable goal, a task board, d
 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. You never run this loop from the chat lane; you only keep its target — the charter — correct, and signal when the goal changes (`ticlawk goal changed`).
+- **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.
 

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

@@ -22,7 +22,7 @@ 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`,
-// `approval request`, `message send`) live in the goal-step (user) prompt
+// `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
@@ -31,7 +31,7 @@ Read other local files only when the current work clearly needs them.`;
 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 Ticlawk surfaces: \`ticlawk message send\` (chat update), \`ticlawk briefing publish\` (active notification/decision), \`ticlawk dashboard set\` (goal-level report). The step tells you which one to use; \`SURFACES.md\` holds the rules for each. Read \`SURFACES.md\` or \`MEMORY.md\` only if the step needs them.`;
+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 = {}) {
@@ -106,7 +106,7 @@ const FILE_DESCRIPTIONS = {
   '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 and signal changes (the loop runs in the backend goal lane).',
+  '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.',
 };
@@ -119,7 +119,7 @@ function describeFile(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 milestone code, run name, or task number, which means nothing to them. Details are in \`COMMUNICATION.md\`.
+  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}`;

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

@@ -95,20 +95,29 @@ export function buildCharterBlock(msg) {
     if (msg.reason === 'transition' || !hasGoalAuthority(msg)) return '';
     return promptBlock(`
 [conversation_goal]
-This conversation has no goal charter yet, so the backend goal loop is not running.
-If this message sets a goal for this conversation, capture it as the charter — the goal and what "done" looks like, in the owner's words — with \`ticlawk charter set --conversation ${conversationId}\` (body on stdin), then run \`ticlawk goal changed --conversation ${conversationId}\` to start the goal loop. Otherwise handle the message normally. See GOAL_AUTHORITY.md.
+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.
 [/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 must NOT run the loop — it
-  // only signals goal changes to wake the goal lane.
+  // 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)
-      ? `This is the goal the backend goal lane is already driving. Handle the incoming message and reply; do not run a goal loop or start gap/execution work yourself. If this message sets, clarifies, or changes the goal, update the charter and then run \`ticlawk goal changed --conversation ${conversationId}\` to wake 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. See GOAL_AUTHORITY.md.`
       : '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]
@@ -125,7 +134,7 @@ export function buildGoalStateBlock(msg) {
   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 charter/dashboard state. If it is clearly one-off, answer normally.'
+    ? '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]