mixdog 1.4.1 → 1.4.2

package/src/defaults/skills/code-tidy/references/test-suite-slop.md

@@ -1,31 +1,20 @@
 # Test-suite slop
 
-Read this when tests are in scope for agent-level cleanup. Tests accumulate
-through repeated agent corrections the same way production code does:
+Read this when tests are in scope. Pruning rules and the test workflow belong
+to the `test-suite` skill (Prune); this file only adds the cleanup gate.
 
-First distinguish redundant coverage from removing a supported behavior.
-Keep distinct observable success, rejection, error, and compatibility cases.
-Before removing a behavior and its tests, require independent evidence from
-current requirements, real callers, or a specification; tests existing only
-for that branch are neither proof of necessity nor permission to delete it.
+First tell redundant coverage from removing a supported behavior. Keep
+distinct observable success, rejection, error, and compatibility cases. Before
+removing a behavior and its tests, require independent evidence from current
+requirements, real callers, or a specification; a test existing only for that
+branch is neither proof of necessity nor permission to delete it. A closed
+loop (a fallback justified by its test, a test justified by the fallback) is
+no evidence either; unresolved intent blocks deletion.
 
-- **Dominated tests** — several tests reach the same branch and the same
-  result; one asserts the observable output, the others only check
-  construction, type, or non-emptiness. Keep the strongest, delete the rest
-  and the fixtures that served only them.
-- **Accumulated regression tests** — a near-identical test appended after each
-  correction, or parameter permutations whose values never cross a new branch,
-  equivalence class, or failure mode. Keep the smallest set that still covers
-  distinct regressions, and a permutation only where it marks a real boundary.
-- **Tautological assertions** — assertions that cannot fail: `assert True`,
-  two equal literals compared, a state the fixture itself guarantees, a mock
-  verifying the setup that fed it. Delete, or rewrite against the observable
-  result.
-- **Verification theater** — checksums, receipts, validators, or
-  recomputation where producer and verifier share the same information and
-  failure domain. They cannot fail independently; delete.
-- **Closed justification loop** — a fallback exists because a test exercises
-  it and the test exists because the fallback was added. Neither is evidence
-  for deleting the pair. Apply the independent-evidence gate above first;
-  unresolved intent blocks deletion. A distinct externally observable
-  rejection, error, or compatibility test is not a loop; preserve its coverage.
+Delete a test only when it is dominated (same branch and result as a stronger
+test), tautological (cannot fail), a permutation crossing no new branch, or
+verification theater (verifier and producer share one failure domain), or it
+asserts a removal, a restated constant or copied production logic, and name
+the test that still owns the contract. Deleting a contract test needs the
+user's approval. Merging into an owner, rewriting source-text assertions, and
+everything else follows `test-suite`.

package/src/defaults/skills/computer-use/SKILL.md

@@ -182,13 +182,21 @@ GNOME with Mixdog's own shell extension, which the app sets up); prefer accessib
    the turn, like any session exit, releases what the session pressed, and a
    failed release is reported rather than assumed.
    Execution stops at the first failure or when the target transitions
-   (popup, dialog, window change) and returns one fresh observation. An act
+   (a popup, dialog, or window change present at the settle check, about
+   150 ms after the input) and returns one fresh observation. An act
    whose first action uses a `ref` returns accessibility only (`ax`) unless
    that tree is unusable; pass `observe: "state"` when the next step needs
    pixels, a `frame_id`, or visual confirmation.
 4. Read the returned observation, including any successor target. It replaces
    the pre-action state: continue from it without another capture when usable.
    Recapture only when evidence is missing, failed, expired, or invalidated.
+   That observation shows one window, never the others on screen. Windows the
+   settle check saw are in `window_transition.opened_windows`; a window that
+   opened later is named by the next command's
+   `windows_opened_since_last_action` (since, not necessarily caused by, your
+   last action). After a click that may open a popup (sign-in, OAuth,
+   connect, continue, authorize), run `list` (kind windows, `query` with the
+   app or expected title) before concluding nothing opened.
 
 Prefer semantic `ref` > SOM/OCR `element` > coordinates. When pixels are
 reported `pixel_unavailable`, coordinate input fails closed but fresh semantic
@@ -253,7 +261,9 @@ and a trailing short `wait`; verify with `verify` rather than another capture.
 `alt+f4` is blocked in every delivery mode. To close a window, obtain the
 user's go-ahead and use `window` with the `close` operation.
 
-**Dialog appears mid-sequence** — `act` halts automatically. Use its successful
+**Dialog appears mid-sequence** — `act` halts when the settle check sees it; a
+dialog that opens later arrives in the next command's
+`windows_opened_since_last_action`. Use its successful
 successor observation to handle the dialog; capture only if it is unusable.
 Returning to the original window also requires a fresh observation, whether
 returned by the action or obtained through `capture`.

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

@@ -1,7 +1,7 @@
 ---
 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.'
+when_to_use: 'Goal requests or approved multi-turn work in progress; not one-turn tasks or recurring schedules.'
 dependencies:
   tools:
     - type: tool

package/src/defaults/skills/setup/references/actions.md

@@ -52,7 +52,7 @@ Read this when choosing a `setup` mutation.
 | Permanently delete confirmed, unchanged, unused model files | `delete_local_model` |
 | TUI system shell | `set_system_shell` |
 | Automatic updates | `set_auto_update` |
-| Mixy's heartbeat: a regular check that wakes her only when something needs attention and only after the user had no operation for 30 minutes (no sent turn, no keyboard/mouse/wheel input in the desktop app's windows) (on by default; `status features` reports `heartbeat.enabled` and `heartbeat.intervalMinutes`) | `set_heartbeat_enabled` |
+| Mixy's heartbeat: a regular check that wakes her only when something needs attention and only after the user had no operation for 30 minutes (no sent turn, no keyboard/mouse/wheel input in the desktop app's windows) (off by default; `status features` reports `heartbeat.enabled` and `heartbeat.intervalMinutes`) | `set_heartbeat_enabled` |
 | How often the heartbeat checks: `minutes` 30, 60 (default), 120 or 240; applies from the next tick, counted from the last check | `set_heartbeat_interval` |
 | Bots' emoji reactions on the user's messages (on by default; `status features` reports `reactions.enabled`) | `set_reactions_enabled` |
 | Worktree defaults: new tasks on the current branch or a new worktree, branch prefix, large-repository warning size, automatic cleanup | `set_worktree_settings` |
@@ -103,7 +103,7 @@ Read this when choosing a `setup` mutation.
 | Read a Project's connector switches | `read_project_connectors` |
 | An agent's action permission (block/ask per action kind) | `set_agent_permission` |
 | Switch a connector off for an agent / a Project (switching it back on is done in the desktop app) | `set_agent_connector`, `set_project_connector` |
-| One connector tool of an agent to needs_approval or disabled | `set_agent_connector_tool` |
+| One connector tool of an agent to disabled, needs_approval or auto (a widening asks the user on an approval card) | `set_agent_connector_tool` |
 | Bring back an archived bot or agent (`definitionKind: "agent"`) | `restore_definition` |
 | Bot display order (Bots page, Sessions bot section; `status agents` `botOrder`) | `set_bot_order` |
 
@@ -344,10 +344,16 @@ markers are read with `status desktop`.
   `status mcp` afterwards. `add_mcp_server` with the service URL is not the
   sign-in flow; never use it for a catalog service.
 - Agent permissions and connector switches change only toward less: `block`
-  or `ask`, a connector off, a tool to `needs_approval`/`disabled`. Anything
-  that lets an agent do more without asking (`allow`, a connector back on, a
-  tool to `auto`) is refused ("make it on the desktop"); `open agents` and let
-  the person do it. Payments and permanent deletes always ask regardless.
+  or `ask`, a connector off, a tool to `disabled`. An action permission
+  `allow` or a connector back on is refused ("make it on the desktop");
+  `open agents` and let the person do it. One connector tool's widening
+  (`set_agent_connector_tool` from `disabled` to `needs_approval`/`auto`, or
+  `needs_approval` to `auto`) asks the user instead: the call waits on an
+  approval card (on the desktop or a paired phone) offering "needs approval",
+  "auto" or Deny, whatever level was asked; the result's `permission` and
+  `note` say what was applied. Only a press on that card decides it: never
+  treat a chat reply as approval, and ask again for each change. Payments and
+  permanent deletes always ask regardless.
   Connector ids are MCP server names from `read_agent_settings`; a bot's
   thread changes only its own bot.
 - `enable_plugin_mcp` turns every server the plugin declares back on and

package/src/defaults/skills/setup/references/surfaces.md

@@ -134,8 +134,8 @@ The setup tool does not mutate:
   browser action confirmations (`MIXDOG_BROWSER_CONFIRM_ACTIONS`,
   `MIXDOG_BROWSER_CONFIRM_SUBMIT`; see the browser-use skill);
 - widening an agent's authority: action permission `allow`, a connector
-  switched back on for an agent or Project, a connector tool to `auto`
-  (setup only narrows them);
+  switched back on for an agent or Project (setup only narrows them; a
+  single connector tool's widening asks the user on an approval card);
 - the remote-access switch ("Use this PC from other devices") and this PC's
   name: turning it off from a phone would cut that phone off mid-session;
 - permanently deleting an archived bot (Sessions → Archived → delete);

package/src/defaults/skills/setup-guide/SKILL.md

@@ -106,6 +106,8 @@ done. Take the first open step, explain it in a sentence or two, ask, then act.
    provider. Give the reason in one line: a different model family catches what
    the main one misses. Suggest turning on the Maintainer with
    a cheap model at the lowest effort; it also decides turns in group rooms.
+   Offer Explore the same way, from its own picks: a cheap model that
+   searches code for the Lead in separate parallel sessions.
    A pick may carry `plans`: when the Lead provider's plan (`plan` in
    `status providers`) is listed there, recommend that model instead. A null or
    unlisted plan keeps the pick as is; never fail on an unknown plan.
@@ -152,8 +154,9 @@ step; do not insist.
   does part of a task. Users add their own on the Workflows page with the
   "에이전트 +" button. Bots are people-facing; agents work behind a task.
 - Default agents (기본 에이전트): built-in helpers listed on Workflows, such as
-  Web Search (runs the web search tool) and the Maintainer (memory upkeep and
-  session titles). They need a model route to work.
+  Web Search (runs the web search tool), the Maintainer (memory upkeep and
+  session titles) and Explore (code search for the Lead). They need a model
+  route to work.
 - Agent mode (에이전트 모드): a coding work session run by Lead and agents.
   A session a bot starts for a job is an agent task session (에이전트 작업
   세션); others are just sessions (세션).

package/src/defaults/skills/setup-guide/model-recommendations.json

@@ -328,6 +328,19 @@
           "source": "https://www.benchleader.com/best/llm-for-coding"
         }
       ]
+    },
+    {
+      "roles": ["Explore"],
+      "note": "Measured on Mixdog code searches: Haiku found the key locations; cheaper models tested missed about half on unseen questions. With no qualifying pick, leave Explore off.",
+      "picks": [
+        {
+          "provider": "Anthropic",
+          "model": "Claude Haiku 5.5",
+          "effort": "low",
+          "checkedAt": "2026-10-29",
+          "source": "https://benchlm.ai/anthropic/api-pricing"
+        }
+      ]
     }
   ]
 }

package/src/defaults/skills/skill-creator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: skill-creator
-description: Create, audit, repair, or simplify a Mixdog Agent Skill and its SKILL.md.
+description: Create, audit, repair, or simplify your Mixdog skills and their SKILL.md.
 when_to_use: 'Create, audit, repair, or edit skills, including activation failures; not ordinary feature work.'
 dependencies:
   tools:
@@ -12,195 +12,90 @@ dependencies:
 
 # Skill Creator
 
-Build a compact operating guide that makes recurring agent work more reliable.
-The result should encode useful decisions and recovery behavior, not narrate
-everything a capable model or a tool schema already knows.
+Manages the skills a user keeps in Mixdog: turning a recurring workflow into a
+skill, repairing one that misfires, and keeping the whole set small and tidy.
+A skill earns its place by changing results — decisions, procedure, recovery
+and a way to prove completion — not by narrating what the model or a tool
+schema already knows.
 
-## Select the right deliverable
+## Pick the deliverable
 
-Before writing files, classify the request:
-
-| Need | Best home |
+| Need | Home |
 |---|---|
-| Reusable judgement or a repeatable procedure using existing tools | Skill |
-| Precise new runtime capability, authentication, streaming, or binary handling | Tool or product code |
-| Repository facts and contributor conventions | Project documentation |
-| A user-specific standing preference or constraint | Memory, with approval |
-| A single task unlikely to recur | Complete the task without a skill |
-
-Do not create a routing-only skill whose main job is listing other skills.
-Improve an existing owner when the requested capability already fits there.
-
-## Choose scope before content
-
-- **Machine-global** — personal workflows useful across Projects.
-- **Plugin** — capability that ships with an independently installed extension.
-- **Built-in** — broadly useful Mixdog behavior with low context and dependency
-  cost. Niche or heavy workflows do not belong here.
-
-Mixdog does not discover project-local `.mixdog/skills` directories. Read
-`references/design.md` before choosing placement or file structure.
-
-## Creation loop
-
-### 1. Recover the real workflow
-
-Use the conversation, successful tool calls, corrections, failure recovery, and
-produced artifacts as evidence. Ask only about gaps that would change the
-design.
-
-Capture:
-
-- one recurring outcome;
-- phrases and situations that should activate the skill;
-- nearby requests that another capability should own;
-- inputs, outputs, dependencies, side effects, and approvals;
-- completion evidence and important failure recovery.
-
-Completion criterion: another agent could identify when to use the skill and
-what successful completion looks like without guessing.
-
-### 2. Check local constraints
-
-Inspect the target skill when modifying one. For a new skill, inspect only the
-runtime rules and nearest comparable skills needed to settle naming, placement,
-and integration.
-
-Treat system instructions and current tool schemas as higher authority than any
-skill. A skill may explain selection and workflow but must not redefine tool
-arguments or permission boundaries.
-
-Completion criterion: every proposed dependency and path exists in the target
-environment or is explicitly part of the implementation.
-
-### 3. Review external candidates when useful
-
-Read `references/source-review.md` when the user asks to find, import, borrow
-from, or compare public skills.
-
-Extract requirements and design lessons rather than copying prose. If exact
-third-party content is genuinely needed, surface its license obligations before
-editing. Prefer a clean local implementation when a small compatible design can
-provide the same behavior.
-
-Completion criterion: the adopt, reimplement, or reject decision is supported
-by compatibility, maintenance, executable-content, and license evidence.
-
-### 4. Draft the smallest complete skill
-
-Read the "Listing line" section of `references/design.md` before writing
-frontmatter; it owns the `description` and `when_to_use` budgets and wording.
-Write instructions and listing text in English, describing user intent
-across languages rather than listing translated keywords. Preserve exact
-literals and language-specific examples when needed.
-
-Write the body in the section order from `references/design.md`: intro,
-boundary or mode selection, prerequisites, procedure with an observable result
-per important step, pitfalls, verification, resource links. Body text never
-routes the skill. Put capabilities, tool usage, prerequisites, operating rules,
-and recovery details here, not in the trigger or UI description. Keep only
-selection conditions in the trigger; the body must stand on its own when loaded.
-
-Move conditional detail into directly referenced files. Add scripts only for
-deterministic work that would otherwise be rebuilt on repeated invocations.
-
-Completion criterion: the listing line fits its budget with the trigger
-intact, and removing any remaining body section would lose judgement,
-execution, recovery, or verification value.
-
-### 5. Validate structure
-
-Run:
-
-```text
-node "${MIXDOG_SKILL_DIR}/scripts/validate-skill.mjs" "<skill-directory>"
-```
-
-Then run checks required by the target repository. The validator catches
-portable structure, code-fence, and path problems and warns when the listing line exceeds
-its budget; the runtime parser remains authoritative for loading behavior.
-
-Completion criterion: validation passes, warnings are reviewed at their
-reported severity, resources resolve, and the folder name matches the manifest.
-
-### 6. Exercise behavior
-
-Read `references/evaluation.md`. Test realistic requests, including an implicit
-positive case, an edge case, and a close negative case. For a modified skill,
-preserve the prior version before editing and compare the same scenarios.
-
-Judge generated artifacts by observable outcomes. Use deterministic assertions
-for mechanical properties and user review for subjective quality.
-
-Completion criterion: required scenarios pass without task-specific harness
-hints, and failures have either been fixed or clearly reported.
-
-### 7. Tighten
-
-Remove duplicated rules, generic advice, stale examples, and branches that did
-not affect evaluation. When adding a corrected rule, replace the obsolete rule
-instead of accumulating exceptions.
-
-Completion criterion: the final skill is smaller or clearer than the draft
-without losing proven behavior.
-
-## Updating an existing skill
-
-- Keep its name and scope unless the user requests a change.
-- Diagnose whether the defect is routing, instructions, resources, integration,
-  or the underlying tool before editing.
-- Preserve warnings, resource bounds, user approvals, and recovery paths.
-- Read only references implicated by the defect.
-- Re-run checks affected by the edit; do not repeat checks already closed by
-  unchanged evidence.
-
-## Auditing the skill set
-
-When asked to audit, review, or tidy skills rather than fix one defect:
-
-1. List every skill directory in scope: machine-global
-   (`<mixdog-data>/skills`), enabled plugin skills, and built-ins
-   (`src/defaults/skills` in the Mixdog repository).
-2. Run `scripts/validate-skill.mjs` on each directory and collect the errors
-   and warnings; they cover the listing line, code fences, and resource paths
-   mechanically.
-3. Read each trigger and body against the audit checklist in
-   `references/design.md`: trigger content, section order, completion
-   results, duplication, and stale instructions.
-4. Report findings as one table (skill, check, current value, proposed fix)
-   before editing. Edit only after the user approves the scope.
-5. Re-run the validator on every edited directory.
-
-Completion criterion: every skill in scope validates; report unresolved
-findings with reasons, without promoting warnings to failures.
-
-## Mixdog loading facts
-
-- Discovery precedence is machine-global, enabled plugin, then built-in.
-- The directory name must equal frontmatter `name`.
-- The model sees one listing line per skill (`references/design.md`
-  "Listing line" owns its form and budget); UI descriptions are not
-  injected, and the body loads once through `Skill`.
-- `${MIXDOG_SKILL_DIR}` resolves to the active skill directory.
-- `metadata.requires` names a mandatory Mixdog built-in feature. Add it only
-  when the skill cannot function without that feature.
-- Optional frontmatter has no effect unless the current runtime implements it.
-- `dependencies.tools` declares tools loaded with the skill, without granting
-  permissions. Use `type: tool` with the exact tool name or `type: mcp` with
-  an existing server name. Keep optional tools out; `allowed-tools` is not
-  interpreted as dependencies. Imported `agents/openai.yaml` dependencies
-  are also read, but never authorize installation or activation.
-
-## Final review
-
-- Is this genuinely a reusable skill rather than another deliverable?
-- Does the trigger say only when to load the skill, strongest situation first?
-- Does every major step end in evidence, not “be careful”?
-- Are platform assumptions, external programs, network access, and secrets
-  visible?
-- Are pitfalls based on plausible or observed failures?
-- Can subjective outputs reach the user for review?
-- Are temporary evaluation files excluded from the shipped skill?
-- Were commit, publish, install, deployment, and restart left to explicit user
-  requests?
-
+| Reusable judgement or a repeatable procedure with existing tools | Skill |
+| A new runtime capability, authentication, streaming, binary handling | Tool or product code |
+| Facts and conventions of one repository | That repository's docs |
+| A standing personal preference or constraint | Memory, with approval |
+| A one-off task | Do the task; no skill |
+
+Never create a skill whose job is to list other skills. When an existing skill
+already owns the outcome, extend it instead.
+
+## Where skills live
+
+- The user's skills: `<mixdog-data>/skills/<name>/SKILL.md`, available in
+  every project.
+- Enabled plugins and Mixdog's built-ins are read in place. A user skill with
+  the same name replaces them and stops following their updates, so pick a new
+  name unless replacing is the point.
+- The folder name equals the frontmatter `name`.
+
+## Create a skill
+
+1. **Recover the workflow.** From the conversation, successful tool calls,
+   corrections and produced artifacts, capture the one recurring outcome; the
+   requests that should select the skill and the nearby requests another skill
+   or tool owns; inputs, side effects and approvals; completion evidence and
+   recovery. Ask only about gaps that change the design. Result: another agent
+   could tell when to use it and what done looks like.
+2. **Draft** with `references/design.md`: the listing line first, then the
+   body in its section order; detail that loads only in some cases goes to
+   `references/`, deterministic repeated work to `scripts/`. Every tool, path
+   and dependency it names exists. Result: the trigger fits its budget, and
+   removing any section would lose judgement, execution, recovery or
+   verification.
+3. **Validate:**
+   `node "${MIXDOG_SKILL_DIR}/scripts/validate-skill.mjs" "<skill-directory>"`.
+   Result: no errors; each warning fixed or kept on purpose.
+4. **Exercise** with `references/evaluation.md`: realistic requests, including
+   an implicit positive and a near-miss negative. Result: the scenarios pass
+   without hints, or the failures are reported.
+5. **Tighten:** delete duplicated rules, generic advice, stale examples and
+   rules no scenario needed; replace an obsolete rule instead of adding an
+   exception. Result: smaller or clearer, with the same proven behaviour.
+
+## Repair or update a skill
+
+- Keep its name and scope unless the user asks otherwise.
+- Classify the defect first (`references/evaluation.md`) and edit the part
+  that owns it: a trigger that never selects the skill is not fixed in the
+  body, and more prose does not fix a broken tool.
+- Keep a copy of the prior version and rerun the same scenarios against both.
+- Keep its approvals, bounds, warnings and recovery paths.
+- Rerun only the checks the edit affects.
+
+## Audit the set
+
+When asked to review or tidy skills rather than fix one:
+
+1. List the skills in scope: the user's (`<mixdog-data>/skills`), enabled
+   plugins, built-ins.
+2. Run the validator on each and collect its errors and warnings.
+3. Read each against the audit checklist in `references/design.md` and give a
+   verdict: **Keep**; **Improve** (name the defect); **Merge** into another
+   (name it); **Retire** (name what covers the need instead).
+4. Report one table — skill, verdict, finding, proposed fix — and edit only
+   what the user approves. Plugin and built-in skills are never edited in
+   place.
+5. Rerun the validator on every edited skill.
+
+Result: every edited skill validates; unresolved findings are reported with
+their reason.
+
+## Resources
+
+- `references/design.md` — read before drafting or auditing: ownership,
+  frontmatter, listing line, body, resources, audit checklist.
+- `references/evaluation.md` — read when exercising a skill or diagnosing a
+  failure.
+- `scripts/validate-skill.mjs` — run on every created or edited skill.