mixdog 1.4.1 → 1.4.3

package/src/defaults/skills/goal-management/SKILL.md

@@ -1,169 +0,0 @@
----
-name: goal-management
-description: Manage the task list of approved work carried across turns, its progress, approvals, and completion.
-when_to_use: 'Explicit Goal (`goal` tool) requests, approved multi-turn work in progress (migrations, improvement passes); not single-turn tasks or recurring schedules.'
-dependencies:
-  tools:
-    - type: tool
-      value: goal
----
-
-# Goal management
-
-Use `goal` to maintain durable tasks and their idle reminders. The tool schema
-owns arguments and limits; this guide owns the lifecycle and completion policy.
-
-## Admission and current state
-
-Create a Goal for an explicit user or system/developer Goal request, or for
-user delegation or approval of work that runs past a single turn: a staged
-refactor or migration, repeated improvement passes, a partition list or
-candidate inventory carried between turns, or an open-ended objective that
-must be finished. A time budget is optional, and the user need not name Goal —
-approval of an assistant-proposed scope also qualifies. Resolve a short
-approval against the preceding proposal and retain any user constraints.
-
-Create the Goal so that scope and state survive the turn boundary instead of
-being rebuilt or dropped. A single-turn task, planning, estimates, and
-deadlines alone do not qualify, and neither does an unaccepted assistant
-proposal.
-
-If work needs approval, obtain it first; then create the
-Goal, or reconcile an existing one, before starting the approved work,
-including execution-stage exploration. An existing Goal does not authorize
-new scope.
-
-For creation, use the requested or approved budget for `time_limit_minutes`;
-omit it when no budget was agreed — an untimed Goal runs on its objective
-alone. A stated budget commits that time: "a 5-hour Goal", "improvement
-rounds for 3 hours", or polishing for a period use `time_mode: duration`, the
-default when a budget is given. Use `time_mode: max` only when the user frames
-the budget as an upper bound ("at most", "within", "최대", "안에").
-
-Use the latest returned state and revision. If unknown or stale, read `status`
-and reconcile before mutating. Never replay a stale mutation blindly.
-For multi-step work, record the approved milestones and keep them durable.
-One-step work does not need a ceremonial plan or a separate verification row.
-
-## Additional rounds
-
-An approved request to continue for another period changes the work commitment,
-not just the conversation. Reconcile the Goal before research or execution:
-
-- For the same unfinished objective, use `resume` with the approved remaining
-  budget in `time_limit_minutes` and new tasks or task updates in one call.
-  This also covers a paused Goal or exhausted budget with all old rows done.
-  Preserve completed rows and unfinished requirements; record the new round's
-  work rather than leaving the old completed checklist unchanged.
-- The resume budget runs from now and retains elapsed work. Omit it for a
-  plain continuation with no approved time change. Preserve `time_mode`
-  unless the new request explicitly changes the time commitment.
-- If the prior Goal is complete or stopped, create a new Goal for the approved
-  round; the runtime archives the prior record. Do not falsely complete or
-  abandon unfinished work merely to get a fresh clock.
-- Proceed only after the returned state has the intended active status,
-  remaining budget, and tasks. A statement that work will continue is not a
-  substitute for the mutation. Reconcile a rejected update before continuing.
-
-## Maintain progress
-
-- Update tasks at meaningful milestones and scope changes. Preserve unfinished
-  requirements; drop a task only after the user changes its scope.
-- Prefer `update_tasks` for changed items; `set_tasks` replaces the full list.
-  Serialize mutations to the same Goal. `resume` accepts updates and additions
-  atomically. `resume` a blocked Goal when the user's reply supplies what it
-  was waiting for or asks to continue, and a cancelled-turn pause when the next
-  instruction carries the objective forward; a user-initiated pause resumes
-  only when the user asks. Bookkeeping alone does not authorize execution.
-- Batch related task changes and independent work. Creation, status, and resume return full state; other
-  successful replies are brief and need no confirmation read.
-
-## Approval and waiting
-
-Finish every approved step and decide choices within the objective yourself,
-including any option you would recommend; state those decisions in the report
-instead of asking. Park as `awaiting_approval` only work that needs the user's
-own action (a sign-in, a device check) or scope outside the objective,
-including a commit, push, release, deployment, or payment the user has not
-requested, together with anything its answer could invalidate. Record additions
-immediately and continue unaffected approved work.
-
-Foreground app or window control, local and test-environment runs and the test
-resources they consume, reversible changes, and time or cost belong to in-scope
-work, not approval gates. Wanting confirmation for in-scope work is never a
-reason to stop.
-
-Never pause on your own initiative: `pause` is only for the user's explicit
-request to pause this Goal. When no approved work can proceed without the user,
-ask the parked questions together and report that impasse with `block`.
-Respect a user-initiated pause until the user asks to continue; routine errors
-and retries are not reasons to stop.
-
-A cancelled turn pauses the Goal with `pauseReason: cancelled`. The user stopped
-that turn, not the objective, and only the stop control retires a Goal. Judge the
-next instruction: resume and continue the work when it carries this objective
-forward or redirects it, and leave the Goal paused when it is unrelated or asks
-you to stay stopped.
-
-Each continuation should do concrete work or wait on a verified live handle.
-Evidence that changes the next action is progress; repeated reports and plan
-updates alone are not. Reassess a no-progress turn and take the next safe action.
-Observation timeouts do not terminate the observed work or justify restarting it.
-An automatic continuation that ends without a tool call stops automatic turns
-until the task list changes, the user acts, or the time boundary arrives; end a
-turn that way only when no safe action remains, not to idle out the clock.
-
-## Completion and recovery
-
-Distinguish a turn boundary, objective completion, and a budget stop. A Goal
-can stay active across turn-ending progress reports; never present such a
-report as completion of the whole objective.
-
-Complete only after auditing every user condition against evidence. Reuse valid
-checks; a separate verification task is optional, verification itself is not.
-A maximum time budget allows verified early completion. A full-period
-commitment does not. Preserve an existing Goal's time mode; never extend its
-budget or change its meaning on your own.
-Do not end a Goal merely because a partial result is available.
-
-For an achieved objective, reconcile the task records, call `complete`, and
-check the returned status before claiming Goal completion. A tool call or a
-plausible final response is not itself confirmation.
-
-### Time-budget extension
-
-Elapsed-time budgets are a Mixdog extension to the persistent Goal lifecycle.
-Keep `max` upper bounds distinct from explicitly requested `duration` periods.
-An advance deadline warning does not stop the Goal or request an early final
-report; prioritize bounded approved work and needed verification. Under a
-`max` budget, do not invent unfinished tasks merely to fill remaining clock
-time. Under a `duration` commitment, when the recorded rows are done, find the
-next round's real improvements within the objective and record them as new
-tasks instead of idling or reporting completion.
-
-At the boundary, the runtime first records `duration_reached`, disables
-automatic Goal work, and delivers closeout without cancelling the current
-turn. Finish or safely park only in-flight work, then report once. The elapsed
-period proves only that the time condition ended: call `complete` only if the
-whole objective is verified; otherwise retain unfinished tasks and the limited
-status. Do not resume or extend the Goal without the user's approval.
-
-### Blocked and redirected work
-
-`block` stops the Goal immediately, with a stable description of an impasse
-that only external state or the user can clear. Do not block the first time a
-blocker appears: block only after the same condition has repeated for three
-consecutive Goal turns, counting the user-triggered turn and automatic
-continuations; after a resume, count only turns since that resume. Until then,
-continue any available work and re-check the blocker against current state with
-a tool each turn rather than restating it. When current state verifies an
-impasse that only the user can clear (their action, approval, credentials, or a
-resource they control), block on that turn. Once the threshold is met, block
-instead of reporting the same blocker again. Treat equivalent blockers as the
-same condition even when their wording or stated next step changes. Never block for difficulty, slowness,
-uncertainty, a choice you can make, confirmation for in-scope work, or
-clarification that would only help. Use `abandon` only when the user redirects away from
-the objective; it preserves a stopped record rather than declaring success.
-
-Done when the returned Goal state accurately represents completed work,
-remaining approved work, or the justified waiting/terminal condition.

package/src/defaults/skills/skill-creator/references/source-review.md

@@ -1,94 +0,0 @@
-# Reviewing public skills
-
-Use this reference to decide whether a public skill should be used as-is,
-reimplemented, or rejected.
-
-## Research order
-
-Look for evidence in this order:
-
-1. current first-party documentation;
-2. the maintainer's source repository;
-3. maintained community implementations;
-4. indexes and lists for discovery only.
-
-Stop when the decision has enough evidence. Popularity and search position do
-not prove quality or compatibility.
-
-## Candidate record
-
-For each viable candidate, capture:
-
-- the exact capability and trigger boundary;
-- source URL plus release or commit when available;
-- target agent and supported platforms;
-- license and redistribution conditions;
-- last meaningful maintenance;
-- file layout and runtime assumptions;
-- scripts, dependencies, network calls, secret access, and side effects;
-- tests or examples that demonstrate behavior.
-
-Compare candidates against the user's required outcome, not against each
-other's feature count.
-
-## Integration decision
-
-### Reimplement the behavior
-
-Prefer a local implementation when the useful part is a small set of ideas or
-requirements. Write a new structure and new language from Mixdog constraints
-and local evidence. Do not translate or lightly rearrange upstream text.
-
-This path avoids carrying incompatible conventions and usually produces a
-smaller skill. It does not permit copying protected prose or code without
-following its license.
-
-### Import third-party material
-
-Use exact upstream material only when its implementation is necessary and its
-license is acceptable. Preserve required notices, identify modifications, and
-test the imported behavior in Mixdog. Upstream test results do not validate a
-local adaptation.
-
-### Reject the candidate
-
-Reject it when:
-
-- no usable license is present;
-- executable behavior is unexplained or excessive;
-- it depends on unavailable tools or private infrastructure;
-- its trigger overlaps a stronger local owner;
-- adapting it would cost more than a focused local design;
-- maintenance or security evidence is insufficient.
-
-## Executable-content audit
-
-Read scripts rather than trusting their documentation. Look for:
-
-- vendor-specific subprocesses;
-- writes into hidden product directories;
-- downloads, telemetry, or remote execution;
-- environment and credential collection;
-- package installation or privilege elevation;
-- deletion, overwrite, publishing, deployment, or recurring scheduling;
-- unbounded concurrency, retries, waits, or external spend;
-- hard-coded local paths and platform-specific shell commands.
-
-Removing an unnecessary executable is often safer than wrapping it in warnings.
-When it is necessary, make its dependency and side effects visible in the main
-skill.
-
-## Extracting useful ideas safely
-
-Record abstract lessons such as:
-
-- a decision the workflow should make;
-- a failure mode worth detecting;
-- a completion condition;
-- a useful separation of responsibilities;
-- a test category or compatibility concern.
-
-Then design the local workflow from those requirements without consulting the
-source phrasing while drafting. Review the result for accidental product names,
-foreign paths, commands, metadata, or structural assumptions.
-

package/src/runtime/agent/orchestrator/runtime-core/goal-tasks.mjs

@@ -1,156 +0,0 @@
-import { GOAL_TASK_SETTLED, GOAL_TASK_STATUSES, MAX_GOAL_TASKS, MAX_GOAL_TASK_TEXT_LENGTH } from './goal-tool-defs.mjs';
-import { clean } from '../../../shared/clean.mjs';
-
-// Fields a task entry or patch may carry. 'kind' is a retired field: stored
-// records and frozen provider schemas still send it, so it is accepted and
-// dropped on normalize rather than rejected.
-const TASK_ENTRY_FIELDS = ['id', 'text', 'status', 'kind'];
-
-// Dropped rows remain in the record but are no longer requested work. Every
-// row, completed and dropped included, still fills one of the capped slots.
-export function goalTaskProgress(tasks) {
-  return {
-    tasksCompleted: tasks.filter((task) => task?.status === 'completed').length,
-    tasksTotal: tasks.filter((task) => task?.status !== 'dropped').length,
-    taskSlotsUsed: tasks.length,
-  };
-}
-
-// Frozen schemas can populate every optional array with an anonymous blank
-// row. Only discard that filler for optional lifecycle changes; addressed,
-// populated, or malformed rows must still reach the normal validators.
-export function optionalGoalTaskChanges({ tasks, updates } = {}) {
-  const populated = (entry) =>
-    !entry ||
-    typeof entry !== 'object' ||
-    Array.isArray(entry) ||
-    clean(entry.id) ||
-    clean(entry.text) ||
-    Object.keys(entry).some((key) => !TASK_ENTRY_FIELDS.includes(key));
-  return {
-    tasks: Array.isArray(tasks) ? tasks.filter(populated) : tasks,
-    updates: Array.isArray(updates) ? updates.filter(populated) : updates,
-  };
-}
-
-export function normalizeGoalTasks(input, previous = [], { strict = false } = {}) {
-  if (input == null) return previous.map((task) => ({ ...task }));
-  if (!Array.isArray(input)) throw new Error('goal tasks must be an array');
-  if (input.length > MAX_GOAL_TASKS) {
-    // Settled rows count toward the cap; set_tasks may omit them (only
-    // unfinished tasks must be retained), which is how a long Goal makes room.
-    const settled = previous.some((task) => GOAL_TASK_SETTLED.includes(task?.status));
-    throw new Error(
-      `goal tasks support at most ${MAX_GOAL_TASKS} entries${
-        settled
-          ? '; completed and dropped tasks count, so to add more send set_tasks with only the unfinished tasks plus the new ones'
-          : ''
-      }`
-    );
-  }
-  const previousByText = new Map(previous.map((task) => [clean(task?.text), task]));
-  const reservedIds = new Set([...previous, ...input].map((task) => clean(task?.id)).filter(Boolean));
-  let nextId = 1;
-  for (const id of reservedIds) {
-    const match = /^task_(\d+)$/.exec(id);
-    if (
-      match &&
-      Number.isSafeInteger(Number(match[1])) &&
-      Number(match[1]) < Number.MAX_SAFE_INTEGER - MAX_GOAL_TASKS
-    ) {
-      nextId = Math.max(nextId, Number(match[1]) + 1);
-    }
-  }
-  const seenText = new Set();
-  const seenIds = new Set();
-  return input.map((entry, index) => {
-    const source = typeof entry === 'string' ? { text: entry, status: 'pending' } : entry;
-    if (!source || typeof source !== 'object') throw new Error(`goal task ${index + 1} is invalid`);
-    const text = clean(source.text);
-    if (!text) throw new Error('goal task text is required');
-    if ([...text].length > MAX_GOAL_TASK_TEXT_LENGTH)
-      throw new Error(`goal task exceeds ${MAX_GOAL_TASK_TEXT_LENGTH} characters`);
-    if (seenText.has(text)) throw new Error(`duplicate goal task: ${text}`);
-    seenText.add(text);
-    const id = clean(source.id) || clean(previousByText.get(text)?.id) || `task_${nextId++}`;
-    if (seenIds.has(id)) throw new Error(`duplicate goal task id: ${id}`);
-    seenIds.add(id);
-    const rawStatus = clean(source.status).toLowerCase();
-    if (strict && !GOAL_TASK_STATUSES.includes(rawStatus))
-      throw new Error(`goal task ${index + 1} has an invalid status`);
-    let status = source.satisfied === true ? 'completed' : 'pending';
-    if (GOAL_TASK_STATUSES.includes(rawStatus)) status = rawStatus;
-    return { id, text, status };
-  });
-}
-
-function taskInputRetains(entry, task) {
-  if (typeof entry === 'string') return clean(entry) === task.text;
-  if (!entry || typeof entry !== 'object') return false;
-  return clean(entry.id) ? clean(entry.id) === task.id : clean(entry.text) === task.text;
-}
-
-export function patchGoalTasks(previous, { updates, tasks } = {}) {
-  const requested = updates ?? [];
-  const entries = tasks ?? [];
-  if (!Array.isArray(requested) || !Array.isArray(entries)) throw new Error('goal updates and tasks must be arrays');
-  const byId = new Map(previous.map((task) => [task.id, { ...task }]));
-  // A new-task entry naming an id this Goal already has can only mean that
-  // task, so it is applied as the task's update. An id the Goal does not have
-  // is still refused below.
-  const addressesExisting = (entry) => byId.has(clean(entry?.id));
-  const patches = [...requested, ...entries.filter(addressesExisting)];
-  const additions = entries.filter((entry) => !addressesExisting(entry));
-  if (!patches.length && !additions.length) throw new Error('goal update_tasks requires updates or new tasks');
-  if (patches.length > MAX_GOAL_TASKS) throw new Error(`goal updates support at most ${MAX_GOAL_TASKS} entries`);
-  const seen = new Set();
-  for (const patch of patches) {
-    const id = clean(patch?.id);
-    if (!id || !byId.has(id)) throw new Error(`unknown Goal task id: ${id || '(missing)'}`);
-    if (seen.has(id)) throw new Error(`duplicate Goal task update: ${id}`);
-    seen.add(id);
-    if (Object.keys(patch).some((key) => !TASK_ENTRY_FIELDS.includes(key)))
-      throw new Error(`unknown Goal task update field for ${id}`);
-    byId.set(id, { ...byId.get(id), ...patch, id });
-  }
-  if (additions.some((task) => clean(task?.id)))
-    throw new Error('new Goal tasks must omit ids; use updates for existing tasks');
-  return normalizeGoalTasks([...byId.values(), ...additions], previous, { strict: true });
-}
-
-// Prepare a working copy without publishing it. Lifecycle actions can include
-// task changes in the same durable commit instead of exposing an intermediate
-// paused/active snapshot or consuming two revisions.
-export function applyGoalTaskChanges(goal, args = {}, { partial = false, at = Date.now() } = {}) {
-  if (['complete', 'stopped'].includes(goal.status))
-    throw new Error('cannot update tasks for a completed or stopped Goal');
-  if (!partial && (!Array.isArray(args.tasks) || args.tasks.length === 0)) {
-    throw new Error('goal set_tasks requires at least one task');
-  }
-  if (partial && goal.tasksObjectiveRevision !== goal.objectiveRevision) {
-    throw new Error(
-      'Goal objective changed; read status and reconcile the full task list with set_tasks before partial updates'
-    );
-  }
-  const previousTasks = normalizeGoalTasks(goal.tasks || []);
-  const input = partial ? patchGoalTasks(previousTasks, args) : args.tasks;
-  const omitted = previousTasks.filter(
-    (task) => !GOAL_TASK_SETTLED.includes(task.status) && !input.some((entry) => taskInputRetains(entry, task))
-  );
-  if (omitted.length > 0) {
-    const detail = omitted.map((task) => `${task.id} (${task.text})`).join(', ');
-    throw new Error(`cannot remove unfinished Goal tasks: ${detail}`);
-  }
-  const nextTasks = normalizeGoalTasks(input, previousTasks, { strict: true });
-  // Re-sending the same tasks is not progress. A newly dropped task must
-  // survive this turn before completion can retire the requested work.
-  if (JSON.stringify(nextTasks) !== JSON.stringify(previousTasks)) goal.tasksUpdatedAt = at;
-  const droppedNow = nextTasks.some(
-    (task) => task.status === 'dropped' && previousTasks.find((prev) => prev.id === task.id)?.status !== 'dropped'
-  );
-  if (droppedNow) goal.lastDropTurn = Math.max(0, Math.floor(Number(goal.turnCount) || 0));
-  goal.tasks = nextTasks;
-  goal.tasksObjectiveRevision = goal.objectiveRevision;
-  goal.updatedAt = at;
-  return goal;
-}

package/src/session-runtime/goal-tasks.mjs

@@ -1 +0,0 @@
-export * from '../runtime/agent/orchestrator/runtime-core/goal-tasks.mjs';