# The `maximum` agent preset: every model-facing capability this deployment
# can compose, driven by a three-role delivery pipeline.
#
# Two things distinguish it from `standard`. It adds the capabilities the other
# shipped presets leave out — persistent terminals, language-server queries,
# session history, durable time and tmux context, reminders, self-modification,
# the extra editor, and Code Mode beside the native schemas. And it adds three
# ROLE delegation tools over the same `spawn` backend, each carrying its own
# child persona: `subagent_architect` writes the specification,
# `subagent_implementer` builds it, `subagent_reviewer` verifies it. The
# orchestrating persona below owns the order they run in; the child personas
# own what each role must produce.
#
# COST: this preset is deliberately the expensive one. Every row here adds tool
# schemas and prompt sections to every request, `mode: both` sends the native
# catalog AND a generated Code Mode SDK, and one pipeline pass is three child
# agents with their own contexts. Copy it and delete rows to trade capability
# for tokens; `standard` and `economy` are the smaller shipped points.
#
# TRUST: `cordis_mount` evaluates model-written JavaScript against the live
# runtime, and the external product agents below run whatever their own CLI and
# account allow. Treat a session on this preset as shell access.
#
# This file is an AGENT-PLANE composition. The roster mounts it ONCE under a
# standing scope; every session naming it joins by scope parentage, so the tools
# and prompt sections registered here cover each joined agent while a session's
# own state stays keyed per Session/Agent inside the plugins. The host
# composition (`base.cordis.yml` + `web.cordis.yml`) keeps everything a preset
# must not own: the registries themselves, the sandbox and approval stack,
# persistence, and the model route.
#
# A service row here MUST sit inside a group carrying an `isolate` realm.
# Without one it publishes into the root realm, where it is process-global —
# another preset publishing the same name collides, and a host reader would
# resolve one preset's instance for every session; `dsh-agent-presets` rejects
# that at mount. `true` means an entry-local realm: this standing mount's own
# private instance, apart from every other preset's.

# ── identity ────────────────────────────────────────────────────────────────

# The preset's own persona, shadowing the deployment default for this agent.
# `{{model}}` and `{{cwd}}` resolve from the agent's own route and workspace.
# It states the pipeline the three role tools below exist for; each role's own
# instructions live on that role's tool row, not here, because a child never
# reads this section — the delegation replaces it with the role persona.
- id: persona
  name: '@deepseek-ai/dsh-persona'
  config:
    text: |-
      You are the lead agent of a three-role delivery pipeline, powered by the {{model}} model. Your working directory is {{cwd}}.

      Every change to the repository passes through three delegated roles, in this order:

      1. `subagent_architect` turns the request into a specification: the goal, the files and subsystems involved, the ordered change plan, the acceptance checks, and the risks. It reads and never writes.
      2. `subagent_implementer` receives that specification and makes the repository satisfy it, running the checks the specification names.
      3. `subagent_reviewer` receives the specification and the implementer's report, inspects the working tree itself, and returns PASS with its evidence or FAIL with a numbered defect list.

      On FAIL, hand the defect list plus the original specification back to `subagent_implementer` and review again. Stop after the third failed review and bring the disagreement to the user rather than starting a fourth round.

      Each role runs as a fresh agent that cannot see this conversation or the other roles' sessions. Everything a role needs goes into its prompt as complete text — paste the specification and the verdict, never "as discussed above" or a session id.

      Skip the pipeline for work that is not a change: questions, read-only investigation, running a command the user asked for, or a fix the user dictated line by line. Use it for anything that changes behavior, and say which stage you are in as you go.

      Do your own reading, searching, and answering. Delegate the three roles, not your judgment.

- id: agent-instructions
  name: '@deepseek-ai/dsh-agent-instructions'
  config:
    maxBytes: 65536

# ── shell ───────────────────────────────────────────────────────────────────

# `shell-env` stays in the HOST composition: `apps/cli/src/web.ts` injects it to
# publish `DSH_WEB_URL`/`DSH_WEB_MODE`, and a host row that injects a service is
# the criterion for host-plane ownership — injection resolves before any session
# exists, so there is no agent to key by. Both shell tools consume the host
# registry from here; their executors (`bash-sandbox`/`pwsh-sandbox`) are
# host-plane too.
- id: tool-bash
  name: '@deepseek-ai/dsh-tool-bash'
  disabled: !!js process.platform === 'win32'

- id: tool-pwsh
  name: '@deepseek-ai/dsh-tool-pwsh'
  disabled: !!js process.platform !== 'win32'

# ── persistent terminals ────────────────────────────────────────────────────

# The PTY registry is an agent-owned service, so it lives in an entry-local
# realm; the backend still consumes the host sandbox policy and subprocess
# implementation. `tool-terminal` rather than `tool-bash-persistent` is what
# joins the one-shot shell above: the persistent-bash tool registers under the
# name `bash`, which this preset's `tool-bash` already owns, while the six
# `terminal_*` tools add long-lived sessions under their own names.
#
# The backend starts an interactive `bash`. A machine without one fails
# `terminal_open`, not the composition, exactly like the external agents below.
- id: persistent-terminals
  name: cordis:group
  group: true
  isolate:
    terminals: true
  config:
    - id: pty
      name: '@deepseek-ai/dsh-terminal'

    - id: terminal-bash
      name: '@deepseek-ai/dsh-terminal-bash'
      config:
        timeoutMs: 300000

    - id: tool-terminal
      name: '@deepseek-ai/dsh-tool-terminal'
      config:
        enableRunInBackground: true
        maxResultBytes: 262144

# ── filesystem ──────────────────────────────────────────────────────────────

# All three register into the host `tools` registry and provide nothing, so
# they need no realm. The `fs` service and its policy stay in the host.
# `str_replace_editor` is the standalone view/create/replace/insert editor; it
# overlaps `edit` deliberately, since this preset's contract is that every
# shipped model-facing tool is present.
- id: tool-fs
  name: '@deepseek-ai/dsh-tool-fs'

- id: tool-fs-search
  name: '@deepseek-ai/dsh-tool-fs-search'
  config:
    sampleOverCapGlobResults: false

- id: tool-str-replace-editor
  name: '@deepseek-ai/dsh-tool-str-replace-editor'
  config:
    maxOutputChars: 16000

# ── language servers ────────────────────────────────────────────────────────

# The `lsp` registry has no consumer outside an agent, so it lives in an
# entry-local realm with the tool that reads it. Without a provider the tool
# stays in the catalog and every query answers the structured `LSP_UNAVAILABLE`
# error, which is why the tool row is unconditional and the provider row is not.
#
# `lsp-stdio` resolves every configured executable AT LOAD and fails the mount
# when one is missing, so a shipped preset cannot enable it: the language server
# is a machine-local install, not a deployment fact. The row below is the
# worked example — copy this preset, drop `disabled`, and name the servers this
# machine actually has.
- id: language-servers
  name: cordis:group
  group: true
  isolate:
    lsp: true
  config:
    - id: lsp
      name: '@deepseek-ai/dsh-lsp'

    - id: lsp-stdio
      name: '@deepseek-ai/dsh-lsp-stdio'
      disabled: true
      config:
        servers:
          typescript:
            command: typescript-language-server
            args: ['--stdio']
            extensionToLanguage:
              .ts: typescript
              .tsx: typescriptreact
              .mts: typescript
              .cts: typescript
              .js: javascript
              .jsx: javascriptreact

    - id: tool-lsp
      name: '@deepseek-ai/dsh-tool-lsp'

# ── background jobs ────────────────────────────────────────────────────────

# Only the model-facing controls. The task REGISTRY stays on the host plane:
# its producers sit outside any realm this file could put it in — `tool-bash`
# and `tool-terminal` above resolve it with `ctx.get`, and an entry-local realm
# here is invisible to every sibling row, so `run_in_background` would answer
# "background jobs unavailable" while these controls sat in the catalog. The
# registry is keyed by owning agent anyway, so one host instance serves every
# session.
- id: tool-jobs
  name: '@deepseek-ai/dsh-tool-jobs'

# ── skills ──────────────────────────────────────────────────────────────────

# The skill REGISTRY lives in the host composition and is layered per scope:
# these rows register into THIS preset's layer of it, so they need no realm.
# The merged catalog carries the project and user roots this provider always
# scans, whatever the deployment registered globally, and the two custom roots
# below.
#
# The first custom root is this preset's own `skills/`, which travels with it.
# The second is the `cordis` preset's, so composition authoring is documented
# for the `cordis_*` tools this preset also carries; a copy of this preset that
# lands beside no `cordis` directory simply scans a missing path, which is
# valid empty state for this provider.
- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  config:
    customSkillDirs:
      - !!js "process.getBuiltinModule('node:url').fileURLToPath(new URL('skills/', baseUrl))"
      - !!js "process.getBuiltinModule('node:url').fileURLToPath(new URL('../cordis/skills/', baseUrl))"

- id: tool-skill
  name: '@deepseek-ai/dsh-tool-skill'

# ── goals ───────────────────────────────────────────────────────────────────

# Only the model-facing tool. The goal SERVICE, its session driver, and the
# `/goal` command stay on the host plane: the Gateway serves the goal domain as
# Remote endpoints whose receiver comes from a generated descriptor, so it
# resolves `goals` on the host and an entry-local realm here would hide it.
- id: tool-goal
  name: '@deepseek-ai/dsh-tool-goal'

# ── session history ─────────────────────────────────────────────────────────

# Five read-only tools over the host `sessionQuery` service, each result
# authorized from the calling agent's own session. The shipped host mounts that
# service with `openAt: never`, so `session_search` and `session_event_search`
# answer `SESSION_QUERY_SEARCH_DISABLED` while the three read and trace tools
# work; full-text search is a host decision (`openAt: first-search` in a
# profile patch), not one a preset can make.
- id: tool-session-query
  name: '@deepseek-ai/dsh-tool-session-query'

# ── durable per-step context ────────────────────────────────────────────────

# Both inject their snapshot at `agent/pre-step`, which is scope-filtered, so
# they reach only agents joined to this preset. Time context lets the model
# read relative dates in the request's own zone; tmux context names the pane
# this process runs in, and reads as "not in tmux" everywhere else.
- id: time-context
  name: '@deepseek-ai/dsh-time-context'
  config:
    refreshIntervalMs: 60000

- id: tmux-context
  name: '@deepseek-ai/dsh-tmux-context'
  config:
    refreshIntervalMs: 60000

# ── scheduled reminders ─────────────────────────────────────────────────────

# Session-scoped durable reminders (`schedule_create`/`_list`/`_delete`). The
# plugin installs on root agents created after it loads and takes its state
# from the session log through the host persistence barrier, so one instance
# per preset mount serves every session that joins — `agent/created` is
# scope-filtered, and an agent on another preset never reaches this one.
- id: schedule
  name: '@deepseek-ai/dsh-schedule'

# ── plan mode ───────────────────────────────────────────────────────────────

# Plan state is per-agent by nature, so an entry-local realm is not a
# workaround here — it is the correct lifetime.
- id: planning
  name: cordis:group
  group: true
  isolate:
    planMode: true
  config:
    - id: plan-mode
      name: '@deepseek-ai/dsh-plan-mode'
      config:
        section: |
              You are in plan mode. Stay in plan mode until exit_plan_mode succeeds or the user switches the session mode. Imperative language to implement changes means plan the implementation, not execute it. A user's conversational agreement — including an answer confirming something you asked — approves nothing and does not end plan mode; fold the confirmed decision into the plan and submit it through exit_plan_mode.

              Explore first. Use non-mutating reads, searches, static analysis, and checks to ground the plan in the actual repository. Do not edit or write files, change configuration, run formatters or code generation that rewrites tracked files, commit, or otherwise carry out the plan. Prefer existing functions and patterns over new machinery. Delegation does not lift this: a delegated role may read and report, and none of them may write while plan mode is active.

              The tool catalog stays the same across modes for request-cache stability. These plan-mode rules override any later tool description or guidance that suggests using mutation tools; those tools remain listed to keep the tool catalog unchanged. Do not use todo_write to track this planning phase: it tracks implementation after an approved plan, while the plan itself belongs in exit_plan_mode.

              Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.

              Make the plan decision-complete: state the goal and success criteria; group implementation changes by subsystem; identify public API, schema, and data-flow changes; cover edge cases, failure modes, tests, acceptance criteria, and explicit assumptions. Keep it concise enough to review but detailed enough that another engineer can implement it without making design decisions.

              When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.

# ── compaction ──────────────────────────────────────────────────────────────

# `compaction-basic` reads `toolResultPrune` through `ctx.get`, so the pruner
# must share this realm rather than sit outside it.
#
# `tokenMeter` is deliberately NOT in this realm: the meter stays on the HOST
# plane, and the rows here resolve that one instance. It keys every fold by
# Session and owns the context-meter projection units the browser reads for
# every session — behind a realm those units would come and go with whichever
# presets happen to be mounted.
- id: compaction
  name: cordis:group
  group: true
  isolate:
    compaction: true
    toolResultPruner: true
  config:
    - id: compaction-basic
      name: '@deepseek-ai/dsh-compaction-basic'

    - id: command-compact
      name: '@deepseek-ai/dsh-command-compact'

    - id: tool-result-pruner
      name: '@deepseek-ai/dsh-compaction-tool-result-pruner'
      config:
        thresholdChars: 8192
        headChars: 4096
        tailChars: 1024

# ── delegation, roles, and workflows ────────────────────────────────────────

# The `subagents` registry and its spawn/fork backends live in the HOST
# composition: the registry is a process singleton whose cross-session queries
# the api-proxy serves to the browser, and a provider name may only be
# registered once. This preset contributes the delegation TOOLS, which resolve
# that host registry.
#
# `workflows` is different — nothing outside an agent reads it — so every row
# that reaches it shares one entry-local realm here, and a consumer left
# outside would resolve a host registry this preset does not populate.
- id: delegation
  name: cordis:group
  group: true
  isolate:
    workflowEngine: true
  config:
    - id: tool-subagent-control
      name: '@deepseek-ai/dsh-tool-subagent-control'

    - id: tool-subagent-list-agents
      name: '@deepseek-ai/dsh-tool-subagent-control/list-agents'

    # The unshaped delegations, kept beside the roles: `subagent` for work that
    # is not a pipeline stage, `subagent_fork` for work that needs this
    # conversation's history.
    - id: tool-subagent
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: spawn
        toolName: subagent
        backgroundMode: continuable

    - id: tool-subagent-fork
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: fork
        toolName: subagent_fork
        backgroundMode: continuable

    # ── the three pipeline roles ────────────────────────────────────────────
    #
    # One `spawn` instance per role, distinguished only by its `toolName` and
    # its child `persona` — the provider applies that persona as a scoped
    # section shadowing `deployment:persona`, so a role child never reads the
    # orchestrating persona at the top of this file.
    #
    # All three are `one-shot`: a stage's result is the next stage's input, so
    # the default must be the foreground call that returns it. `maxDepth: 1`
    # keeps the pipeline flat — the roles are leaves and the lead agent owns
    # sequencing, so the agent count of one pass is exactly the stages run.
    #
    # A role's restrictions are stated in its persona rather than as a
    # `toolFilter`: the filter names GLOBAL tool names and fails the start when
    # one is unknown, and the shell tool's name differs by platform, so a
    # read-only filter here would be a Windows-versus-POSIX startup failure. A
    # persona cannot enforce a restriction; deployments that need enforcement
    # copy this preset and add the filter their platform actually registers.
    - id: tool-subagent-architect
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: spawn
        toolName: subagent_architect
        backgroundMode: one-shot
        maxDepth: 1
        persona: |-
          You are the ARCHITECT of a three-role delivery pipeline. You produce one specification and nothing else. An implementer who cannot see this session receives your reply verbatim and builds from it.

          Ground the specification in the repository as it actually is. Read the files the change touches, the tests around them, and the existing patterns it must follow; prefer an existing function, module, or convention over new machinery. Resolve by inspection anything you could otherwise guess at.

          Change nothing. No edits, no writes, no commits, no formatters, no code generation, no dependency installs. Running read-only commands and tests to learn how the code behaves today is expected.

          Reply with exactly these sections:

          GOAL — one paragraph: what will be true when this is done, and what is explicitly out of scope.
          CONTEXT — the files, symbols, and patterns the change must fit, each with a path, and what each one contributes.
          PLAN — ordered steps, each naming the file it changes and the change it makes, in enough detail that the implementer makes no design decisions.
          ACCEPTANCE — the checks that decide done: exact commands to run, and the observable behavior to confirm.
          RISKS — what could break elsewhere, the edge cases to cover, and every assumption you could not verify.

          When the request is ambiguous in a way that changes the design, state the interpretation you chose and why in GOAL rather than asking; you cannot see the user.

    - id: tool-subagent-implementer
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: spawn
        toolName: subagent_implementer
        backgroundMode: one-shot
        maxDepth: 1
        persona: |-
          You are the IMPLEMENTER of a three-role delivery pipeline. You receive a specification and make the repository satisfy it. A reviewer who cannot see this session checks your work against that same specification.

          Follow the plan you were given. Match the surrounding code: its naming, its idioms, its comment density, its error handling. Change what the specification calls for and leave the rest alone.

          Run the checks the specification names, plus whatever narrower test covers the code you touched. A check you did not run is not a check you may report.

          When a step is wrong or impossible, do every step that is not blocked, then say exactly what you skipped and why. Never substitute a different design in silence, and never widen the scope past the specification.

          Reply with exactly these sections:

          CHANGES — one line per file: the path and what changed in it.
          VERIFICATION — each command you ran and its outcome, quoting the failing output where it failed.
          DEVIATIONS — everything you did differently from the plan, or did not do, each with its reason. Write "none" when there is nothing.

    - id: tool-subagent-reviewer
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: spawn
        toolName: subagent_reviewer
        backgroundMode: one-shot
        maxDepth: 1
        persona: |-
          You are the REVIEWER of a three-role delivery pipeline. You receive a specification and an implementer's report, and you return a verdict on the work as it exists in the repository.

          Verify, do not trust. Read the changed files yourself, re-run the acceptance checks the specification names, and confirm each claim in the report against what you observe. An unrunnable or skipped check is a defect, not a pass.

          Judge the implementation against the specification: unmet acceptance criteria, missed edge cases and failure modes, behavior changed outside the plan, tests that assert nothing the change could break, and anything that contradicts the conventions of the surrounding code.

          Fix nothing. Do not edit files, do not commit, do not run formatters or code generation. Reporting the defect is your whole job.

          Reply with exactly these sections:

          VERDICT — the first line, either PASS or FAIL and nothing else.
          EVIDENCE — the commands you ran and the files you read, each with its outcome.
          DEFECTS — numbered, each naming the file, what the specification requires, what the code does instead, and a severity of blocking or minor. PASS requires this list to be empty; a blocking defect requires FAIL.

    # External product agents. The base host plane mounts each provider, and
    # each run needs that product's own CLI on PATH plus its own account:
    # `codex`, `claude`, and `cursor-agent`. A missing CLI fails the call it is
    # asked for rather than the composition, so a deployment without one keeps
    # an inert tool row; copy this preset and add `disabled: true` to drop it
    # from the model's roster entirely.
    - id: tool-subagent-codex
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: codex
        toolName: subagent_codex
        backgroundMode: one-shot
        maxDepth: provider-managed

    - id: tool-subagent-claude-code
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: claude-code
        toolName: subagent_claude_code
        backgroundMode: one-shot
        maxDepth: provider-managed

    - id: tool-subagent-cursor
      name: '@deepseek-ai/dsh-tool-subagent'
      config:
        provider: cursor
        toolName: subagent_cursor
        backgroundMode: one-shot
        maxDepth: provider-managed

    - id: workflow-worker-thread
      name: '@deepseek-ai/dsh-workflow-worker-thread'
      config:
        provider: spawn

    - id: tool-workflow
      name: '@deepseek-ai/dsh-tool-workflow'

    - id: tool-ralph
      name: '@deepseek-ai/dsh-tool-ralph'
      config:
        subagentProvider: spawn
        maxRounds: 64

# ── MCP servers ─────────────────────────────────────────────────────────────

# One row per external MCP server, each registering its tools on the host
# registry as `mcp__<serverName>__<rawName>`. Which servers exist is a machine
# fact — every one names a command to spawn or a URL to reach — so this preset
# ships the worked example disabled. Copy the preset, drop `disabled`, and add
# one row per server.
- id: mcp-example
  name: '@deepseek-ai/dsh-mcp-client'
  disabled: true
  config:
    serverName: example
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-everything']

# ── remaining model-facing rows ─────────────────────────────────────────────

- id: tool-ask-user
  name: '@deepseek-ai/dsh-tool-ask-user'

- id: tool-todo
  name: '@deepseek-ai/dsh-tool-todo'
  config:
    allowParallelInProgress: true

# The `web` service and its search provider stay in the host composition; only
# the model-facing tool is per-session. `fetch` stays off because the shipped
# host mounts no fetch provider: that provider defers SSRF protection and the
# model would choose the request target.
- id: tool-web
  name: '@deepseek-ai/dsh-tool-web'
  config:
    fetch: false
    searchTimeoutMs: 60000

# ── self-modification ───────────────────────────────────────────────────────

# Read the live runtime, mount a temporary plugin, unmount it. The toolset is a
# trust boundary, not a sandbox — see this file's header. The composition-
# authoring skill reaches this agent through the second custom skill root above.
- id: tool-cordis
  name: '@deepseek-ai/dsh-tool-cordis'

# ── presentation ────────────────────────────────────────────────────────────

# `both` sends the native tool schemas AND the generated Code Mode SDK, so the
# model may call a tool directly or write one TypeScript program that combines
# several. It waits for the host's `codeRuntime` rather than assuming it: a
# deployment composing no TypeScript runtime fails this preset at mount, naming
# this id, instead of at the first request.
- id: tool-presentation
  name: '@deepseek-ai/dsh-agent-tool-presentation'
  config:
    mode: both