dsh-punky-swarm 0.5.2 → 0.5.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-punky-swarm",
-  "version": "0.5.2",
+  "version": "0.5.3",
   "type": "module",
   "description": "dsh-punky-swarm — dsh 插件（DeepSeek Harness）· punky 署名 · 集群治理（swarm governance）引擎：单机多子 agent 治理，wavePlan 三层 DAG + 引擎级门禁（Entry / Plan Contract / Exit / Complete）+ 状态机 + 单写者锁 + 会话隔离 + 国标 AIP 兼容 + 全能力治理增强。附蟛蜞模式预设与 software-team 角色指引。",
   "license": "AGPL-3.0-only",

package/presets/punky-preset/agent.cordis.yml.bak-2026-10-19T12-05-11

@@ -1,285 +0,0 @@
-# The `standard` agent preset: the full coding agent, mounted once per process.
-#
-# 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. (A shared label does NOT
-# pool instances — `provide()` throws on the second registration under the
-# same realm symbol; labels join REALMS, and are not what this file needs.)
-
-# ── 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.
-- id: persona
-  name: '@deepseek-ai/dsh-persona'
-  config:
-    prefix: >-
-                你是蟛蜞模式（集群治理 on dsh）的 Leader Agent，运行于 {{model}}，工作目录 {{cwd}}。
-
-                职责面 = 分级 / 三层拆解（plan/exec/audit）/ wavePlan 派发 / 成员治理 / 门禁裁决；被派发的角色活由 worker 承担，简单任务由 Leader 自主完成。工具面 = assign_check（委派形态判定）＋ gate_status（门禁状态查询）。纪律索引（27 条）：评估派发 0/0a/0b/1/2/3/9/10 ｜ 批与交接 0c/0e/4/5/6/0i ｜ 运行模式 11 ｜ 审计验收 0k/12 ｜ 结算 0t ｜ 恢复监管 7/0d ｜ 输出·能力·指引 8/13/14/15 ｜ 两方向·编号 0p/0s ｜ 执行前检索 0u。细则面见 `references/discipline.md`。
-                0. 难度路由门禁（每轮必评，**无默认档**）：先做只读侦察，再调 `assign_check({difficulty, rationale, scope:"full"})` 写入难度与判据（A 直做 / B 单 subagent / C wave_plan 建批 / D team 席位=建批档 + team 通道）；**D 有其正当形态**：声明 durableSeats:true 时通道轴=team ⇒ 不记偏离（override=false）；声明 D 而通道未落实（无 durableSeats）⇒ 通道面拒（须重评或显式降级为 C，禁静默降级）；**单线程一律不建批**；判 C/D 未建批前禁执行型动作。细则见 #§0。
-                0a. 会话显式化：评估 / 建批 / 结算三件套传同一 session（会话 ID 或命名黑板 `<task>-<date>`）；显式 session 与执行会话不同则自动镜像，**只升不降**。细则见 #§0a。
-                0b. 三层门禁：C 必先 `wave_plan` 建批；派发 / 结算 / 完成 / 装配声明由引擎把关，`assembly.auditLane` 必填；`team` 为可选自由标签。细则见 #§0b。
-                0c. 任务粗拆：拆到可派发粒度即可（角色 / 目标 / 契约 / 验收 / 产物格式）。细则见 #§0c。
-                0e. 执行 lane 任务包只含（角色 / 目标 / 关键契约 / 验收标准 / 产物契约 / 期望输出格式）；实现由被指派 worker 完成。细则见 #§0e。
-                1. 任务指派：`wave_plan` 按依赖 DAG 分层为 waves（启动后不重算）；`member_status` 派发。细则见 #§1。
-                2. 状态：批次 / 成员状态以状态文件为唯一事实源（`batch_status` / `member_status` / `member_settle`）。细则见 #§2。
-                3. 并发与锁：写同一 lane 前 `lane_claim` 取单写者锁；同 wave 同物理资源域先取域级隔离单元并把路径注入任务包。细则见 #§3。
-                4. 黑板：治理真源 = 批次黑板（`wavePlan.tasks[]` + `handoffs` + 事件流）；跨上下文只写元数据、不复制正文。细则见 #§4。
-                5. 结算与终门禁：完成 / 失败用 `member_settle`；终门禁先消重、标注冲突、核证据再下结论。细则见 #§5。
-                6. 门禁：review 阶段按门禁语义裁决 merged / conflict；批次终态后不再写。细则见 #§6。
-                7. 恢复：`idle` = 空闲态，`idle→running` 即返工 / 续跑入口；进程重启后 in-flight 落 idle，`batch_status` 核对后重派。细则见 #§7。
-                8. 输出偏好：总结用「对比表 + 清单 + 摘要」三层；对用户只报治理结论与关键状态。细则见 #§8。
-                9. 消费方契约摸底先行：实现前先摸底被消费方约束（摸底归 plan 层 produce、实现 lane 只 consume，缺则拒派）；产物 `survey/<target>-contract.md`。细则见 #§9。
-                10. 宿主级自验证 DoD：产出运行于真实宿主 / 消费路径时，完成判据必含宿主级加载 / 启动冒烟（RED→GREEN 作中间 checkpoint）。细则见 #§10。
-                11. 运行模式：星型直驱（`leader-direct`）——R-1 结算即派 ｜ R-2 复核并行 ｜ R-3 单点派发 ｜ R-4 真源 = `lanes[].deps` + `handoffs` ｜ R-5 监管二源 ｜ R-6 模式可退出。细则见 #§11。
-                12. **audit 非盲审**：audit 审核 exec 层必须**消费 plan 层产物做对照**；audit lane 的 `consume` 缺**判据源**锚点（`plan/` 前缀产物）即**拒派**，锚点正文须含裸标题 `## 验收标准`。 **`consume` × `deps` 对称性必核**（建批期**单点判定** = `lib/wave-plan.ts#validateLayerContract`；口径 = `consume` 项与他 lane 的 `produce ∪ outputs` **精确字符串相等**，不做 glob／目录语义）：某 `consume` 项的来源 lane 未写进 `deps` ⇒ ① 来源**非 `plan` 层**（audit 面 ＋ 同层链）**拒建批** `GATE_CONSUME_DEPS_ASYMMETRY`（消息逐缺口回显）；② 来源 `plan` 层且下游非 audit ⇒ **不拒**、落 `gate.consume_deps_asymmetry` 并在 `wave_plan` 回显 `consumeDepsAsymmetry`；③ 来源 `plan` 层且下游 audit ⇒ 静默豁免（批级不变量）。`smoke: true` 同键豁免。**缺边在上游结算后永久不可补** ⇒ 写 `consume` 时逐条核对 `deps`。细则见 #§12。
-                13. **指引维护**：改注入面或正文后必须跑 `node scripts/check-guidance-sync.mjs`（五件同 sha ＋ 双向指针）；**GREEN（exit 0）才算收口**。细则见 #§13。
-                14. **任务包预算**：单 lane `W` ∈ 4M–10M（`W ≈ 轮次 × 232K`）；派发前必带预算行（`预算：W≈…M；切法：…`）。细则见 #§14。
-                15. 判据 / 基线 / 并行读数：判据带限定量词；改动前落 sha256 快照；`baselines/**` 单写者 = Leader；并行窗口 lane 自证写域子集；新增校验须给可达构造；批边界归属须留痕。细则见 #§15。
-                0d. 记忆语义：复盘 / 归档产物落盘即可，记忆沉淀优先 dsh-mneme。细则见 #§0d。
-                0k. audit 收敛口径：audit 层 = 验收，按 plan 验收标准逐条核对；未决项进 `gap-list`（标 blocking / followup）。细则见 #§0k。
-                0p. 两方向规格：dispatch 方向 = 写黑板后引擎自动派发（`owner` + `member.dispatch`）；team 方向 = `spawn_teammate` 拉起并写黑板（`roster`），由事件队列交接；一批一方向，不混用。细则见 #§0p 与 #§0o。
-                0s. 编号规范：跨批引用带批次短码（如 `AG-04@realign`）；`AG-xx` 权威定义面 = 批 A `audit/gap-list.md`。
-                0t. 完成发现与结算：audit lane 不自动结算 ⇒ 显式 `member_status(review)` → `member_settle(merged|conflict)`；完成发现靠三查（`batch_status` / `log_export` / 产物根 glob）；abort 批的 `danglingLanes` 属预期残留。
-                0u. 执行前经验检索：每任务第一步 = `weknora_search` 查知识库经验；命中即按其「正向做法」执行并登记来源，无命中照常推进；库不可达记一行后继续。细则见 #§0u。
-
-- 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. Behind a preset realm those variables
-# never reached the model's shell at all. 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'
-
-# ── filesystem ──────────────────────────────────────────────────────────────
-
-# Both register into the host `tools` registry and provide nothing, so
-# they need no realm. The `fs` service and its policy stay in the host.
-- id: tool-fs
-  name: '@deepseek-ai/dsh-tool-fs'
-
-- id: tool-fs-search
-  name: '@deepseek-ai/dsh-tool-fs-search'
-  config:
-    sampleOverCapGlobResults: false
-
-# ── 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`
-# above resolves 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. What a preset
-# chooses is whether its agent can collect and stop background work at all.
-- 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.
-# `skill-filesystem` contributes local-root discovery for agents on this preset, and
-# `tool-skill` gives them the catalog and loader; the merged catalog also
-# carries whatever the deployment registered globally (repository plugins).
-- id: skill-filesystem
-  name: '@deepseek-ai/dsh-skill-filesystem'
-
-- 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. The
-# registry is keyed by session anyway, so one host instance serves every
-# session. What a preset chooses is whether its agent can call the goal tool.
-- id: tool-goal
-  name: '@deepseek-ai/dsh-tool-goal'
-
-# ── 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.
-
-              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 takes no configuration,
-# 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. What a preset chooses is whether
-# its agent compacts at all, which is `compaction-basic` below.
-- 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 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.
-#
-# `tool-subagent-report` is host-plane for the same reason as the registry,
-# not because a preset may not want it: it registers a CONTINUABLE SETUP on
-# that singleton rather than a tool this agent calls, and the setup list is
-# not scope-aware — one copy per mounted preset means every child gets
-# `report` registered once per live session, which throws on the second.
-- 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'
-
-    - 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
-
-    # Product providers are host-plane singletons. Copy this preset, then
-    # remove `disabled` from either ordinary tool row to expose that product
-    # only to agents composed from the copy.
-    - id: tool-subagent-codex
-      name: '@deepseek-ai/dsh-tool-subagent'
-      disabled: true
-      config:
-        provider: codex
-        toolName: subagent_codex
-        enableRunInBackground: false
-        maxDepth: provider-managed
-
-    - id: tool-subagent-claude-code
-      name: '@deepseek-ai/dsh-tool-subagent'
-      disabled: true
-      config:
-        provider: claude-code
-        toolName: subagent_claude_code
-        enableRunInBackground: false
-        maxDepth: provider-managed
-
-    # ── 双线适配（0.1.7-rc.2 / 0.2.0-rc.1）依据 · 单行两线通吃 ─────────────────────
-    # `@deepseek-ai/dsh-base` 在 0.1.7-rc.1 / 0.1.7-rc.2 / 0.2.0-rc.1 **三版全部**依赖本包
-    #   ⇒ 本行**不需要**按宿主版本分支（内核**无**宿主版本变量 ⇒ 条件行不可达；见批 6 取证 §二/§四）。
-    # **禁**回加旧推进器行：那会在两线之一新增**必失败行**，且旧线存在同服务**双挂载**风险。
-    # 双副本一致性（本行 ↔ `cordis.patch.yml` 的 `dsh-agent-preset-punky.config.plugins`）由
-    #   `test/patch-preset-duplicate-consistency.test.js` 机检（漂移即红）。
-    - id: workflow-ptc
-      name: '@deepseek-ai/dsh-workflow-ptc'
-      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
-
-# ── 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.
-- id: tool-web
-  name: '@deepseek-ai/dsh-tool-web'
-  config:
-    fetch: false
-    searchTimeoutMs: 60000