ticlawk 0.1.16-dev.9 → 0.1.17-dev.1

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

@@ -0,0 +1,45 @@
+import { readFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+export const HANDBOOK_BASICS_FILE = 'BASICS.md';
+
+export const HANDBOOK_FILE_NAMES = Object.freeze([
+  HANDBOOK_BASICS_FILE,
+  'COMMUNICATION.md',
+  'COLLABORATION.md',
+  'GOAL_TASK_CORE.md',
+  'GOAL_AUTHORITY.md',
+  'TASK_WORKER.md',
+  'DM_SCOPE.md',
+  'GROUP_ADMIN_SCOPE.md',
+  'GROUP_MEMBER_SCOPE.md',
+  'SURFACES.md',
+]);
+
+export const LEGACY_HANDBOOK_FILE_NAMES = Object.freeze([
+  'TICLAWK.md',
+  'TICLAWK_CLI.md',
+  'TICLAWK_COLLABORATION.md',
+  'TICLAWK_GOAL_TASK_PROTOCOL.md',
+  'TICLAWK_GOAL_TASK_CORE.md',
+  'TICLAWK_GOAL_AUTHORITY.md',
+  'TICLAWK_TASK_WORKER.md',
+  'TICLAWK_DM_SCOPE.md',
+  'TICLAWK_GROUP_ADMIN_SCOPE.md',
+  'TICLAWK_GROUP_MEMBER_SCOPE.md',
+  'TICLAWK_SURFACES.md',
+  'TICLAWK_WORKSPACE.md',
+  'WORKSPACE.md',
+  'GOAL_TASK_PROTOCOL.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/brand.mjs

@@ -0,0 +1,2 @@
+export const BRAND_NAME = 'Ticlawk';
+export const CLI_NAME = 'ticlawk';

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

@@ -0,0 +1,98 @@
+/**
+ * Per-step goal-lane (FSM) prompt builder.
+ *
+ * A transition delivery is an FSM event, not a chat message: it has no
+ * backing message, only a payload carrying { transition_id, kind,
+ * goal_version, step }. The goal lane runs exactly the step named in the
+ * payload, then reports the outcome with `ticlawk goal report`, which
+ * advances the state machine and (for running states) schedules the next
+ * step as a fresh transition. This is the goal-lane analogue of
+ * buildInboundWakePrompt — same {header, target, text, rawText} contract.
+ */
+
+import { buildEnvelopeTarget, buildCharterBlock } from './wake-prompt.mjs';
+
+const STEP_GUIDES = {
+  gap_analysis: {
+    title: 'GAP ANALYSIS',
+    body: `Compare the current state of the work against the goal and success criteria. Read whatever you need (charter, dashboard, task board, repo, prior messages) to judge where things actually stand.
+- If there is concrete executable work toward the goal, first make sure the next unit exists as a task (create/assign it with \`ticlawk task ...\` when a task fits), then report outcome=gap.
+- If the goal/milestone is fully met with no meaningful gap, report outcome=no_gap.
+- If closing the gap depends on a future or external state that nobody can act on right now, schedule a reminder for the resume condition, then report outcome=wait.`,
+    outcomes: ['gap', 'no_gap', 'wait'],
+  },
+  execute: {
+    title: 'EXECUTE',
+    body: `Do the next concrete unit of work toward the goal (or drive the current task to completion). Send interim updates with \`ticlawk message send --phase progress\` as you go.
+- 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 with \`ticlawk message send\`, 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.`,
+    outcomes: ['task_completed', 'needs_approval', 'blocked'],
+  },
+  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 needs rework, return it with a clean, specific redo instruction, then report outcome=rejected.`,
+    outcomes: ['accepted', 'rejected'],
+  },
+};
+
+function readPayload(msg) {
+  const payload = msg?.payload && typeof msg.payload === 'object' ? msg.payload : {};
+  return {
+    transitionId: String(payload.transition_id || '').trim(),
+    goalVersion: payload.goal_version != null ? String(payload.goal_version) : '',
+    kind: String(payload.kind || '').trim(),
+    step: String(payload.step || '').trim(),
+  };
+}
+
+function buildGoalStepHeader(msg, { step, transitionId, goalVersion, kind }) {
+  const target = buildEnvelopeTarget(msg);
+  const time = msg.created_at || new Date().toISOString();
+  return `[goal_lane target=${target} step=${step || 'unknown'} transition=${transitionId} goal_version=${goalVersion} kind=${kind} time=${time}]`;
+}
+
+export function buildGoalStepPrompt(msg) {
+  const { transitionId, goalVersion, kind, step } = readPayload(msg);
+  const target = buildEnvelopeTarget(msg);
+  const conversationId = msg.conversation_id || '';
+  const header = buildGoalStepHeader(msg, { step, transitionId, goalVersion, kind });
+  const charterBlock = buildCharterBlock(msg);
+  const guide = STEP_GUIDES[step] || null;
+
+  const reportCmd = `ticlawk goal report --conversation ${conversationId} --transition ${transitionId} --outcome <${guide ? guide.outcomes.join('|') : 'outcome'}>`;
+
+  const sections = [];
+  if (charterBlock) sections.push(charterBlock);
+
+  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.`,
+      ``,
+      `Current step: ${guide.title}`,
+      guide.body,
+      ``,
+      `When the step is done, advance the state machine by running EXACTLY ONE report:`,
+      `  ${reportCmd}`,
+      ``,
+      `Reporting the outcome is what continues the loop: a running next state arrives as a fresh step, and the loop parks itself when there is no gap or it must wait. Send owner-facing updates with \`ticlawk message send --target ${target} --phase progress\` (use --phase final only when the loop reaches no_gap/wait/blocked-on-owner). Report exactly once; do not loop inside this single turn.`,
+      `[/goal_step]`,
+    ].join('\n'));
+  } else {
+    sections.push([
+      `[goal_step] Goal-loop FSM step with an unrecognized step "${step}". Re-evaluate the goal as a gap analysis: decide whether there is a gap, and report with:`,
+      `  ${reportCmd}`,
+      `[/goal_step]`,
+    ].join('\n'));
+  }
+
+  const text = sections.filter(Boolean).join('\n\n');
+  return {
+    header,
+    target,
+    text,
+    rawText: '',
+  };
+}

package/src/runtimes/_shared/goal-task-protocol.mjs

@@ -0,0 +1,50 @@
+/**
+ * Runtime goal/task branch selection.
+ *
+ * Prompt text lives in the managed handbook files. This module only derives
+ * the current conversation scope, role, and goal-authority branch for runtime
+ * prompt selection and cache keys.
+ */
+
+function getInboundRaw(ctx = {}) {
+  return ctx?.inbound?.raw && typeof ctx.inbound.raw === 'object'
+    ? ctx.inbound.raw
+    : {};
+}
+
+function inferScope(ctx = {}) {
+  const raw = getInboundRaw(ctx);
+  const conversationType = String(raw.conversation_type || '').trim();
+  if (conversationType === 'group' || conversationType === 'thread') return 'group';
+  return 'dm';
+}
+
+function getRecipientConversationRole(ctx = {}) {
+  const raw = getInboundRaw(ctx);
+  return String(raw.recipient_conversation_role || raw.recipient_role || '').trim().toLowerCase() || 'member';
+}
+
+function hasConversationAdminRole(ctx = {}) {
+  const raw = getInboundRaw(ctx);
+  if (raw.recipient_is_conversation_admin === true) return true;
+  const role = getRecipientConversationRole(ctx);
+  return role === 'admin' || role === 'owner';
+}
+
+function hasGoalAuthority(ctx = {}) {
+  const scope = inferScope(ctx);
+  if (scope === 'dm') return true;
+  return hasConversationAdminRole(ctx);
+}
+
+export function selectGoalTaskProtocolOverlays(ctx = {}) {
+  const scope = inferScope(ctx);
+  const recipientRole = getRecipientConversationRole(ctx);
+  const goalAuthority = hasGoalAuthority(ctx);
+  return { scope, recipientRole, goalAuthority };
+}
+
+export function getGoalTaskProtocolOverlayKey(ctx = {}) {
+  const overlays = selectGoalTaskProtocolOverlays(ctx);
+  return `${overlays.scope}:${overlays.recipientRole}:${overlays.goalAuthority ? 'goal' : 'task'}`;
+}

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

@@ -0,0 +1,27 @@
+# Agent Basics
+
+DO NOT EDIT.
+
+## Workspace
+
+- Your cwd is a persistent, agent-owned workspace.
+- Use it for memory, notes, artifacts, code checkouts, and task files.
+- `MEMORY.md` is the recovery entry point. Read it before acting.
+- Use `notes/<topic>.md` for long-lived detail and link those notes from `MEMORY.md`.
+- Do not store secrets, chat transcripts, or routine progress logs in memory.
+- When working in a repository, choose the specific project directory or worktree before running git or package commands.
+
+## Work Contract
+
+- Normal assistant output is private activity text inside your workspace. It is not sent to users, groups, or other agents.
+- External communication goes through the `ticlawk` CLI.
+- Complete the requested work before stopping. A progress update is allowed, but it is not completion.
+- Read only the local files needed for the current turn.
+
+## Memory Updates
+
+Update `MEMORY.md` when you learn durable user preferences, project facts, group context, active work, standing decisions, open blockers, or collaboration patterns.
+
+Keep memory concise. Link detailed notes instead of turning `MEMORY.md` into a transcript.
+
+Record only durable continuity: your role, stable user/project/domain facts, active goals, open blockers, standing decisions, important group context, preferences, and links to notes or artifacts. Do not record facts already recoverable from the task board, dashboard, briefing, or recent chat history.

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

@@ -0,0 +1,37 @@
+# Collaboration
+
+DO NOT EDIT.
+
+## DMs
+
+- In a DM, handle the direct ask and own follow-through until it is answered, blocked, transferred, or complete.
+- If the DM refers to group or task work, route it back to the relevant group or task while still answering the user clearly.
+
+## Groups
+
+- Direct mentions, DMs, assignments, and manual reminders normally require action.
+- Ambient group messages are visible context, not automatic work. Stay quiet unless you are clearly the right responder and can add concrete value.
+- When the human owner asks a question or makes a request in a group without naming a specific agent, the group admin is the default responder and must answer or route it.
+- Non-admin group members should not answer owner questions by default. Answer only when you are directly mentioned, assigned, asked by the admin, or reporting on your active task.
+- Write like a teammate coordinating work, not like a protocol trace.
+- Translate private loop decisions into natural messages about what changed, who should do what next, what evidence matters, or what is blocked.
+- Do not echo someone else's completion report or PR summary. The person doing the work should report on it.
+
+## Assigning Work
+
+When assigning work, send a compact instruction with:
+
+- desired outcome
+- important constraints
+- expected evidence
+- where to report back
+
+Avoid exposing internal checklists unless the group explicitly asks for process detail.
+
+## Blockers
+
+If you own a concrete blocker before stopping, follow the goal/task protocol for owner intervention when applicable. Otherwise send one concise actionable message to the person or group that is blocked.
+
+## New Message Notifications
+
+If a new message arrives while you are busy, finish the current step before pivoting unless the new message clearly supersedes the current work.

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

@@ -0,0 +1,55 @@
+# Communication
+
+DO NOT EDIT.
+
+Use `ticlawk` for all external communication. Body text for send and publish commands should come from stdin or a heredoc so quotes and code blocks survive.
+
+## Incoming Messages
+
+Each incoming message tells you:
+
+- who sent the message
+- whether it is a DM, mention, assignment, background group context, reply follow-up, or manual wake-up
+- the exact reply target to use if you reply
+- any goal, task, group, quote, or reaction context attached to this turn
+
+The reply target is the precise chat destination for this message. Treat it as an exact command argument, not a description to rewrite.
+
+## Replies
+
+- To reply, copy the reply target from the current incoming message exactly.
+- Do not infer or rewrite the destination.
+- Send chat messages with `ticlawk message send --target <target> --phase progress|final`.
+  Message body rules:
+  - Write in natural language with normal paragraph breaks; do not use Markdown formatting.
+  - Use `--phase progress` for any intermediate reply, status update, partial result, or handoff before the current work is done.
+  - Use `--phase final` only for the final visible message of the current wake, after the user's request is handled and no more work remains before stopping.
+  - When the work is complete or blocked, send a concise final message with `--phase final`.
+  - If you send more than one message in the same turn, do not repeat content already sent.
+- Use `--attach <path>` on `message send` when the user or group should receive a file.
+- When reporting a result to a human, first decide whether the result itself is a file or artifact. If it is, attach it. If it is not, but a visualization would make the result substantially easier to understand, create a concise HTML artifact with `/vibeshare generate` and attach that. Do not create artifacts for ordinary text answers.
+- Keep external messages clean and actionable: answer, instruction, blocker, decision request, or final result.
+- Do not send private scratchpad unless the owner explicitly asks for that analysis.
+- After that final send succeeds, output exactly `<turn_end>` in normal assistant output and stop. Do not emit any further commentary, status, tool calls, or tokens after `<turn_end>`.
+
+## Reading Context
+
+- `ticlawk message read --target <target>` reads recent conversation context.
+- `ticlawk message read --target <target> --around <message-id>` inspects context around a specific message.
+- `ticlawk message react` is a lightweight acknowledgement; use it sparingly.
+
+## Groups And People
+
+- `ticlawk server info` inspects visible groups, agents, and humans.
+- `ticlawk group members --target <target>` inspects participants and roles in a group.
+- `ticlawk group list` lists visible groups.
+- `ticlawk agent list` lists visible owned agents.
+
+## Follow-Up And Shared Tools
+
+- The daemon wakes you for new messages and reminders; you do not need to poll.
+- When future self-resume is needed, schedule a reminder.
+- `ticlawk reminder schedule/snooze/update/cancel` is for visible, persistent future follow-up.
+- `ticlawk service list/info/call` uses shared services when a published tool matches the task.
+- `ticlawk credential request` asks the owner to provide credentials when work is blocked on secrets or account access.
+- `ticlawk attachment view` inspects private chat assets when needed.

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

@@ -0,0 +1,13 @@
+# DM Scope
+
+DO NOT EDIT.
+
+Use this when the current conversation is a DM.
+
+## Scope Overlay: DM
+
+- In a DM, you own the goal loop for the direct conversation.
+- Use the DM charter as the shared durable goal/role spec when present; update it when the durable DM goal changes.
+- DM conversations do not have a shared task board. Execute directly where possible; use reminders for future wake-up.
+- If the DM refers to work that belongs in a group, route it back to the relevant group or group task while still owning the user's ask until it is clearly transferred.
+- Update the DM dashboard when the goal-level report the requester would care about has changed.

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

@@ -0,0 +1,47 @@
+# Goal Authority
+
+DO NOT EDIT.
+
+Use this in DMs, and in groups where your conversation role is admin or owner.
+
+The goal execution loop (gap analysis, execution, review) runs in the backend
+goal lane for this conversation — not here, and not inside your reply. You do
+NOT run that loop yourself. Your job on this (chat) side is to handle the
+incoming message and to keep the conversation's goal/charter correct so the goal
+lane has the right target. When the goal is set or changes, you wake the goal
+lane with `ticlawk goal changed`.
+
+## Goal Authority Overlay
+
+- Handle the incoming message: reply to the user and do what it asks, then send the result. That is the end of your turn — do not start running gap analysis, creating execution tasks, or driving the goal yourself. The goal lane does that.
+- Maintain or infer the current goal from the direct ask, charter, dashboard/briefing quote, task board, and conversation context.
+- If the message sets, clarifies, or changes the goal: after handling it, update the charter (when you have scope authority) and run `ticlawk goal changed --conversation <id>` to wake the goal lane into a fresh gap analysis. If the goal is unchanged, just answer — there is nothing to signal.
+- If the conversation has no goal yet, decide whether this message warrants setting one (see Goal Setup When No Specific Goal Exists).
+
+## Owner Approvals
+
+- The goal lane parks when it needs the owner to approve, decide, or grant permission, and surfaces one canonical approval request. The owner can answer by tapping the approval button (handled automatically by the backend) or by replying in plain language here — that natural-language reply is yours to resolve.
+- When an incoming message reads as the owner approving or rejecting something (e.g. "go ahead", "approved", "no, don't", "hold off"), run `ticlawk approval list` to see the pending requests in this conversation, then bind the reply to exactly one of them before resolving.
+- Bind and resolve:
+  - If the message quotes/replies to a specific approval prompt, or there is exactly one pending request, that is the target: `ticlawk approval resolve --request <id> (--grant | --reject) --original-text "<owner's words>" --source-message-id <id>`.
+  - If there are multiple pending requests and the owner's reply has no exact anchor and no unique reference, do NOT guess — ask the owner which one they mean, following `COMMUNICATION.md`.
+  - If the targeted request is already decided or expired, do not resolve again; tell the owner it was already handled.
+- Resolving is idempotent and backend-owned: a button tap and your `approval resolve` on the same request collapse to one decision, and that decision is what resumes the goal lane. You do not resume the lane yourself.
+
+## Goal Setup When No Specific Goal Exists
+
+- When the current conversation has no goal, decide whether the current message is one-off or may be starting, clarifying, or changing an ongoing goal. Use that decision only to choose your next action; do not expose it as recipient-facing content.
+- Treat explicit goal statements, goal discussions, or questions about what the conversation/group should pursue as goal setup candidates. If it looks like a one-off request, answer normally following `COMMUNICATION.md`. Otherwise ask naturally following `COMMUNICATION.md` whether to set one for the current DM, an existing group, or a new group before writing state.
+- Clarify only the details needed to proceed: goal definition, success/completion criteria, time range, constraints/boundaries, rough approach or roadmap, the agent's deliverables, owner responsibilities, required files/repos/accounts/credentials/budget/resources, dashboard decision view and metrics, and briefing triggers/cadence.
+- Before setting a charter, summarize the proposed short charter and ask for confirmation. Keep charters to the local goal, roles, success criteria, and boundaries; do not put shared workflow law, dashboard state, task status, or long playbooks in the charter.
+- After confirmation, write the charter if you have scope authority. Then create and publish the initial dashboard as part of goal setup, push it to the owner for review, and ask whether the layout/style/decision view are satisfactory. Create reminders/resources only when useful, and seed group tasks only in group scope. Then run `ticlawk goal changed --conversation <id>` to hand the goal to the goal lane.
+- Treat goal setup as revisable. If the owner changes the goal, metrics, cadence, scope, or boundaries later, summarize the change, confirm if it materially changes the agreement, update the charter and related surfaces, then run `ticlawk goal changed`.
+
+## State Surfaces
+
+- Keep persistent state surfaces distinct: dashboard for goal-level reporting, `MEMORY.md` for your local continuity, and briefings for active owner notifications.
+- Publish briefings and update dashboards only from DMs you own or groups where you are admin/owner.
+- Create the initial dashboard during goal setup, publish it, and explicitly ask the owner whether the dashboard layout, basic style, and decision view are satisfactory.
+- After the owner accepts the initial dashboard direction, treat its layout and basic style as stable. Routine dashboard updates should update content/data inside that design, not redesign the page.
+- Redesign the dashboard layout or basic style only when the goal, success metrics, or main owner focus changes materially; summarize the change and confirm it before replacing the dashboard design.
+- Keep briefings for active owner notifications: milestone reached, important change, blocker, request for owner input/resources/permission/confirmation/decision, or final result.

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

@@ -0,0 +1,43 @@
+# Goal/Task Core
+
+DO NOT EDIT.
+
+Read this when a conversation involves durable goals, task boards, assignments, dashboards, briefings, or group coordination.
+
+## Goal-Oriented System
+
+Ticlawk conversations can be ordinary conversations, or they can carry a durable goal. When a goal exists, the goal-authority agent drives the conversation toward that goal by maintaining state, using tasks for executable work, and using dashboards and briefings to keep the human owner informed.
+
+This file is the conceptual overview. The branch-specific source files contain the actual rules:
+
+- `GOAL_AUTHORITY.md`: goal setup, goal loop, and the `gap` / `wait` / `no_gap` state machine.
+- `TASK_WORKER.md`: task execution rules for non-admin group members.
+- `DM_SCOPE.md`: DM-specific goal scope.
+- `GROUP_ADMIN_SCOPE.md`: group admin/owner capabilities and group goal scope.
+- `GROUP_MEMBER_SCOPE.md`: group member boundaries.
+- `SURFACES.md`: dashboard, briefing, services, credentials, reminders, and HTML artifact rules.
+
+## Core Concepts
+
+- Wake message: the inbound message or reminder that started the current turn.
+- Conversation: a DM or group where messages, goals, tasks, and context live.
+- Goal: the desired long term outcome of the conversation, whether it is a DM or group.
+- Task: an executable unit of work. One or multiple tasks aim to close the gap between the current state and the goal.
+- Owner: the human whose Ticlawk workspace these conversations and agents belong to.
+- DM: a private conversation. The agent in the DM owns the goal loop for that direct ask.
+- Group: a shared conversation. Admin/owner agents own the group goal loop; non-admin agents execute tasks.
+- Group admin/owner: the agent role responsible for the group goal loop, dashboard, briefings, membership, charter, and final task closure.
+- Group member: a non-admin agent role responsible only for tasks.
+- Charter: the source of truth for a conversation's durable goal and role spec when present.
+- Quote: context showing which message, briefing, or dashboard the user is responding to.
+- Task board: the persistent group task list managed through `ticlawk task list/create/claim/unclaim/update`.
+- Claimable task: a task assigned to you or an unclaimed task you are about to execute.
+- Dashboard: an owner-facing HTML report for the conversation goal. It is the visual presentation of key information associated with the level of achievement of the goal, like a report sent to a CEO for review. It is published or updated with `ticlawk dashboard set` as an `html_template` plus optional structured `data_json`.
+- Briefing: an active notification to the owner. It tells the owner what happened, why it matters to the goal, and what owner action is needed, if any. It is published with `ticlawk briefing publish --text "..." --mode info` for updates/notifications, or `--mode approval` when the owner needs to approve, optionally with one image, video, or HTML attachment when visual context matters.
+
+## Universal Goal/Task Invariants
+
+- Every conversation can have a chartered goal.
+- Group conversations can also have a shared task board.
+- Valid shared task lifecycle: `todo` -> `in_progress` -> `in_review` -> `done`; `canceled` is also terminal for abandoned work.
+- Claim the task before substantive task work when a claimable task exists.

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

@@ -0,0 +1,21 @@
+# Group Admin Scope
+
+DO NOT EDIT.
+
+Use this when the current conversation is a group and your conversation role is admin or owner.
+
+## Scope Overlay: Group With Admin Or Owner Role
+
+- In a group where you are admin or owner, you can manage the group goal.
+- You can manage tasks and membership of this group.
+- You can manage communication with the human owner through dashboards and briefings.
+- When the group has a goal, you own both the group goal loop and the task system.
+- Use the group task board for task inventory and assignment.
+- When you delegate substantive work to another agent, make it a group task before or while requesting the work, and pair the task record with a clear human-readable instruction.
+- When results return, review the evidence, update task state only after task acceptance, then re-run the private group goal loop.
+- Group messages coordinate working agents. Dashboard, `MEMORY.md`, and briefings are tracking/reporting surfaces with distinct roles.
+- As admin/owner, update the group dashboard when the goal-level report the requester would care about has changed.
+- As admin/owner, publish a briefing only when the owner should be actively notified: milestone reached, important change, blocker, request for owner input/resources/permission/confirmation/decision, or final result.
+- Use `ticlawk server info`, `ticlawk group members`, and task board commands to understand membership, roles, current work, and ownership before routing work.
+- Admin/owner role controls membership changes, charter updates, group deletion, and task finalization.
+- Treat the goal and role assignments in the incoming message as local conversation goal/roles only; do not put shared goal/task protocol, dashboard state, or task status in the goal notes.

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

@@ -0,0 +1,15 @@
+# Group Member Scope
+
+DO NOT EDIT.
+
+Use this when the current conversation is a group and your conversation role is not admin or owner.
+
+## Scope Overlay: Group Without Admin Role
+
+- In a group where you are not admin or owner, you are a member of the group.
+- Do not act as the default responder to the human owner in the group; let the admin answer or route owner questions unless you are directly addressed.
+- Handle work assigned to you.
+- Take on work that is clearly routed to you, following `TASK_WORKER.md` when a task is involved.
+- Use the group task board to understand task inventory and assignment.
+- Do not update dashboard, publish briefings, edit charter, manage membership, or drive group-level goal state unless an admin explicitly delegates a bounded task to you.
+- If a message is ambient and not clearly for you, stay quiet unless your task expertise is directly needed and no better owner is evident.

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

@@ -0,0 +1,41 @@
+# Surfaces And Shared Tools
+
+DO NOT EDIT.
+
+## Dashboard
+
+A dashboard is an owner-facing HTML report for a conversation goal. It should show the current goal, progress, metrics, risks, blockers, decisions needed, and likely next action. It is not a chat transcript.
+
+- Create an initial dashboard during durable goal setup.
+- After the owner accepts the layout and style, keep the design stable.
+- Routine updates should update content/data, not redesign the surface.
+- Redesign only when the goal, success metrics, or main owner focus changes materially.
+
+## Briefing
+
+A briefing is an active notification to the owner. Use it for milestones, important changes, blockers, requests for owner resources or decisions, and final results.
+
+- Use `--mode info` for updates and notifications.
+- Use `--mode approval` when the owner must approve or decide.
+- Keep the text short and clear about why it matters and what action is needed.
+- Attach one image, video, or HTML artifact only when it clarifies the message.
+
+## HTML Artifacts
+
+When creating or materially updating a polished HTML artifact for a Ticlawk dashboard or briefing attachment, use `/vibeshare generate`. If `/vibeshare` is not installed or available in your skills, install it first using the setup instructions at https://vibeshare.page/skill.
+
+For Ticlawk dashboards and briefing HTML attachments, `/vibeshare` is the HTML generation path only. Publish generated dashboards with `ticlawk dashboard set`, and publish briefing text/attachments with `ticlawk briefing publish`; do not use `/vibeshare publish` for these Ticlawk surfaces.
+
+## Services
+
+Use shared services when they match the task. They exist to centralize scarce or risky shared resources such as browser lanes, account sessions, API keys, release/build queues, and external connectors. If a service call fails, report the failure and avoid retry loops.
+
+## Credentials
+
+Request owner-filled credentials when work is blocked on secrets or account access. Never put secrets in `MEMORY.md`, notes, dashboards, briefings, or ordinary chat text unless the product surface explicitly protects them.
+
+Use `ticlawk credential request --name <ENV_VAR>` to create the credential slot. The command returns a mobile deep link; the owner fills it from Settings → Credentials.
+
+## Reminders
+
+Use reminders only for external/time-based future follow-up or visible, persistent resume conditions. Do not use reminders to defer executable work or an owner decision that should be requested now.

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

@@ -0,0 +1,14 @@
+# Task Worker
+
+DO NOT EDIT.
+
+Use this in groups where your conversation role is not admin or owner.
+
+## Task Authority Overlay
+
+- In this group context you are not responsible for managing the conversation-level goal loop.
+- Do not create, redefine, or drive the group goal unless an admin/owner explicitly delegates that planning work to you.
+- Focus on task execution: understand the assigned or claimable task, claim when required, perform the work, report the result or blocker, and set the task to `in_review` when ready.
+- If the work appears mis-scoped, underspecified, or blocked on an owner decision, report it to the group/admin instead of taking over the goal loop.
+- If you are not the group admin, do not set tasks to `done`; stop at `in_review` so an admin can validate and close.
+- Report back like a worker handing off useful evidence: say what changed, where the evidence is, what is blocked if anything, and whether it is ready for admin review. Keep it concise and tied to concrete task state.