@dsh-cove/dsh-web-all 0.0.0-stage → 0.4.4

package/presets/code-vibe/skills/code-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: code-review
+description: 代码评审方法论：评审切片实现/契约/用户可见行为时加载；先算改动范围再读 diff，缺陷=位置+影响+证据，一条有据 blocker 优于一串 nit；接收评审时逐条验证，不表演式同意。Use when 评审、审查、review、merge 前检查。
+---
+
+# Code Review（评审方法论）
+
+> 提炼自 DeepSeek Harness 的 dsh-code-review（MIT），去除仓库绑定，适配许愿项目（wish-programming 切片实现 + 本地 skill 体系）。
+> **Guidance, not a complete checklist.** 先确认评审对象的真实改动范围（相对验证过的基线，而非随意 ref——见 `agent-operation` 最小验证集），再读 diff 与足够上下文理解设计。
+
+## 评审依据（Sources of truth）
+
+- `wish-programming`：五阶段流程、原话优先、报告协议——切片是否遵守已锁定规范单？
+- `frontend-design`：设计类愿望的字段门/白名单——实现是否发明组件/布局/样式？
+- `quality-review`：验收证据标准——测试/截图是否证伪过？
+- `dsh-prose-standard` + `dsh-trim-cot-leakage`：注释/文档/文案质量与思维链泄漏。
+- `dsh-ci-test-reliability`：切片测试的确定性与反 flake。
+- 决策记录（docs/wish/<id>/ 的 design-spec 备选方案节）：与已记录决策冲突 = 设计讨论而非自动否决。
+
+## Blocking requirements（机器查不出的才列在这里）
+
+1. **契约与规范对照**：实现与 design-spec/需求清单（N/O 编号）逐条一致；与原话冲突处有登记或回用户。
+2. **证据存在且匹配声明**：作者声明的测试/截图真存在、真跑过（对照 `agent-operation` 报告纪律：只报实跑命令）；CI/门禁已覆盖的不重复提。
+3. **白名单合规**：新组件/布局/样式出现 → blocker（除非用户在拍板点批准过；`check_whitelist.py` 是机械下限，评审补语义判断）。
+4. **用户可见行为有证据**：文案改了但确认包没同步 → blocker；模型/用户可见字符串必须有对应证据（多视口截图或快照）。
+5. **生命周期与副作用**：资源/订阅/监听有清理（dispose）；失败路径不静默吞错（空 catch 具名）。
+6. **文档随代码**：README/注释/模板与实现同 PR 更新；推理转录与 review 历史不写进注释。
+7. **不越范围**：评审目标之外顺手改动 → 要求拆出或说明必要性（投机泛化：为不存在的未来加的抽象/配置项）。
+
+## Manual checks（按需逐项）
+
+- **意图与接口**：切片 brief 与实现一致（含错误、取消、所有权、清理）；public 新方法只有一个内部调用者 = 疑似过度扩展。
+- **状态与并发**：异步设置/回调/拆除顺序；取消中的 await；发布前竞态；回调包含；重入前所有权。
+- **用户视角**：目标用户 + 做完后用户能看到什么——切片若无可观察面应显式声明（对照 wish-programming 阶段 3）。
+- **边界覆盖最终操作**：小/精确极限、超大单块、多字节文本（字节边界）；分页/滚动/表单校验按 quality-review 证伪刀。
+- **测试强度**：断言在目标回归上必失败（负对照）；验证外部状态而非自报；覆盖是必要不充分。
+- **实现笔记对齐**：若评审的改动改写了设计决策——设计-spec 备选方案节/决策记录同步了吗？（翻案须新记录+互链，不静默改写）
+- **双语/文案**：中英确认包/README 配对一致（本环境约定：与 `dsh-prose-standard` 术语与〔原话〕/〔PM 推断〕标注一致）。
+
+## 报告与接收
+
+- 报告 = 缺陷 + 位置 + 影响 + 证据；局部问题 inline 在最紧 diff 范围，跨切面问题汇总级；blocker 与建议分开。
+- 门禁已覆盖的不重复提（绿灯即机器已查）；「一条有据 blocker 优于一串 nit」。
+- **接收评审**：逐条验证（跑命令/读代码），技术上有理就修、无理就 rebut；**不表演式同意**（"收到"不算完成，证据才算）。
+- 评审会话只读：不越权改实现（诊断请求 ≠ 修改授权，除非用户明说）。

package/presets/code-vibe/skills/dsh-ci-test-reliability/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: dsh-ci-test-reliability
+description: 测试可靠性/防 flake/确定性测试； Design, review, and diagnose DeepSeek Harness tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown. Use when adding or changing tests with those risks, investigating flaky CI, or reviewing test isolation; use pre-push minimal-evidence discipline separately to select outgoing commands.
+
+<!-- provenance: ported from deepseek-ai/deepseek-harness/.agents/skills/dsh-ci-test-reliability @ 00102833dfaee1da9f48a3a8eae9d34005a75218 (MIT License, Copyright (c) 2026 DeepSeek). Content adapted for self-contained operation outside the upstream repo. -->
+---
+
+# Reliable DSH CI tests
+
+Build tests that remain correct under the repository's real CI topology, not only when run alone on a quiet workstation. This skill owns isolation and reliability decisions; it does not replace the repository's test-tier policy or select every command for a push.
+
+## Read the owning rules
+
+- Use the testing policy（单元/覆盖/期望输出/快照/浏览器/真 API 证据分层，源自 DeepSeek Harness） to select unit, coverage, expected-output, snapshot, browser, or real-API evidence.
+- Use the defensive patterns（生命周期/子进程/取消/拆除缺陷类） for lifecycle, subprocess, cancellation, and teardown behavior.
+- Read the active Vitest config and GitHub workflow when their worker or job topology affects the test.
+- For recorded-session scenarios, also follow the snapshot instructions（录制会话场景的 keyless 重放规则）.
+- Use pre-push checks（最小证据集：只跑与改动相关的验证，源自 DeepSeek Harness 的 dsh-pre-push-checks） after the test design is sound to select outgoing validation.
+
+## Model the execution topology
+
+Assume these layers can overlap unless the active configuration proves otherwise:
+
+1. Tests in one Vitest file.
+2. Separate Vitest files or worker processes.
+3. Independent Vitest or repository-gate processes in one job.
+4. Different Actions jobs whose runners share one host.
+
+Process isolation does not isolate host ports, predictable filesystem paths, external services, databases, sockets, or inherited child processes. For every acquired resource, identify its owner, atomic allocation mechanism, observable readiness signal, registered cleanup, and quiescent completion signal.
+
+Do not serialize an entire suite merely because one fixture lacks isolation. Narrow the exclusive scope or change the resource allocation first. A sequential Vitest block cannot protect a host resource from another file, process, job, or runner.
+
+## Allocate resources atomically
+
+Use the resource owner's allocator instead of checking availability and claiming it later.
+
+- Network fixtures bind loopback with `listen(0)` and read the assigned address only after the server reports that it is listening. Never scan for a free port and bind it later.
+- Create private per-test temporary roots with `mkdtemp`; do not acquire predictable shared paths.
+- Give shared databases, sockets, sessions, and output locations unique per-test namespaces.
+- Use exclusive creation where a path must not already exist.
+- Keep stable recorded identifiers separate from ephemeral transport addresses. Translate inside the fixture instead of forcing the live resource to use the recorded value.
+
+Literal paths and URLs used only as parser inputs or expected values are not acquired resources. Do not rewrite them merely because they look fixed.
+
+## Contain process-global state
+
+Treat `process.env`, `cwd`, fake timers, locale and timezone, module mocks, registries, console hooks, `globalThis`, and global `fetch` interception as exclusive mutable resources.
+
+Prefer an injected dependency or instance-local adapter. When mutation is required:
+
+- capture whether the original value was absent or present;
+- restore that exact state;
+- register restoration immediately;
+- use `try/finally` around the smallest mutation scope;
+- keep an `afterEach` fallback when failure before the local `finally` is plausible;
+- intercept the narrowest exact request or call that the fixture owns.
+
+## Respect platform-owned semantics
+
+CI runs the same suite on Windows and on POSIX hosts, and a value the operating system owns does not always come back the way a test wrote it.
+
+- Writing a value back is safe only when the assertion tolerates the write-back failing. Restoring a file's `mtime` to prove that a fingerprint invalidates anyway holds everywhere; restoring it to prove that a record stays valid assumes a lossless round trip, which NTFS's 100-nanosecond ticks do not give a fractional millisecond. When the assertion depends on the restoration, take the expected value from a fresh read rather than from the remembered one.
+- Windows matches environment variable names case-insensitively, so a fixture seeding `http_proxy` and `HTTP_PROXY` as separate keys holds one entry there.
+- Windows releases file handles asynchronously, so a rename or removal that completes at once on a POSIX host needs a bounded retry sized to the observed contention.
+- Windows has no POSIX permission or signal semantics. A case that depends on them takes an explicit platform skip naming the reason, rather than an assertion weakened everywhere.
+
+Prefer an observation that holds on every platform. When a case genuinely cannot, exclude it on that platform explicitly.
+
+## Budget timeouts against the lane
+
+A `describe` or case timeout overrides the runner's `--testTimeout` instead of yielding to it, so a value below the lane's budget lowers what CI already granted — and the same literal reads as a widening on a host whose default is smaller. A suite bound by process creation takes the lane budget; a tighter value carries the reason it is tighter.
+
+Raise the hook budget with the test budget. Setup and teardown pay the same contention, so lifting only the case budget moves a contended failure into `afterEach`.
+
+Where a timeout is the subject, keep the outer wait far larger than the timeout under test. A case proving that a 20 ms deadline fires must not race the harness's own wait, or load decides which deadline reports first.
+
+## Synchronize on state
+
+A fixed sleep is not evidence that setup completed or cleanup settled.
+
+- Wait for an explicit readiness event, handshake, state transition, owned promise, or externally observable condition.
+- Use deferred promises or barriers to place a race at a deterministic point and prove the relevant operations overlap.
+- Use a timeout only to bound a wait, never as the condition that makes the assertion correct.
+- Do not assert scheduler-dependent ordering unless that ordering is the product behavior under test.
+- When time itself is the subject, inject or fake the clock and always restore real timers.
+
+## Dispose to quiescence
+
+Register cleanup immediately after acquisition so assertion failures also release the resource. Cleanup stops new callbacks or requests, detaches listeners, restores global hooks, terminates owned work, and awaits child exit, server close, worker termination, or the equivalent completion signal.
+
+Calling `abort()`, `close()`, or `kill()` without awaiting the owned completion signal is incomplete teardown. When late completion is possible, prove that disposal prevents it from mutating another test.
+
+## Prove the intended regression
+
+- Observe an ordinary regression fail before the fix when practical.
+- For a new static or corpus guard, temporarily introduce the rejected case and observe the intended failure.
+- For a race, use barriers to prove overlap; repeated execution alone is not a race test.
+- For ports, sockets, shared paths, subprocesses, or other host resources, run independent test processes concurrently when cross-process isolation is part of the fix.
+- Where a fixture spawns with its own deadline, assert that no signal or timeout ended the child before asserting its exit status, so a killed child reports as a timeout instead of as a status mismatch.
+- Verify external state, events, files, logs, exits, or disposal instead of trusting the component's self-report.
+
+Stress runs supplement a deterministic regression; they do not replace one.
+
+## Reject flake-masking fixes
+
+Do not present these as root-cause fixes for deterministic local tests:
+
+- increasing a timeout without identifying the awaited state;
+- adding retries;
+- making all files serial;
+- swallowing an error or unhandled rejection;
+- weakening an assertion;
+- normalizing away unstable behavior;
+- adding a sleep before cleanup or assertion.
+
+Retries remain valid for documented transient external-provider tests under the real-API policy. Keep that exception at the external boundary.
+
+Restoring a budget is not masking. Raising a suite to the lane budget it already had, or sizing a bounded retry to the contention actually measured on the runner, names the awaited work and returns what the lane granted; neither invents headroom around an unexamined wait.
+
+## Diagnose existing flakes
+
+For an existing probabilistic CI failure, read [the CI flake diagnosis workflow](references/ci-flake-diagnosis.md). A diagnosis-only request remains read-only: report the cause and evidence unless the user also asks for a fix.
+
+## Validate and report
+
+Run the smallest focused regression for the affected behavior. Add topology-specific evidence only when the change owns that risk:
+
+- global mutation needs restoration evidence;
+- lifecycle or subprocess work needs quiescent teardown evidence;
+- ports, sockets, or shared paths need concurrent independent-process evidence;
+- a new guard needs a negative control.
+
+Before a push, use pre-push checks（最小证据集：只跑与改动相关的验证，源自 DeepSeek Harness 的 dsh-pre-push-checks）. Report exact commands and observed results; do not describe retries, skipped tests, or pending CI as passing.

package/presets/code-vibe/skills/dsh-ci-test-reliability/references/ci-flake-diagnosis.md

@@ -0,0 +1,60 @@
+# CI flake diagnosis
+
+Use this workflow only when the task is to investigate an existing probabilistic test or CI failure. Preserve the requested read/write scope: diagnosis does not authorize a fix, workflow rerun, or CI configuration change.
+
+## Freeze the evidence
+
+Record the repository, workflow, job, commit SHA, runner labels, timestamps, exact failing test or command, and the first stable failure signature. Keep infrastructure messages separate from test output.
+
+Compare multiple failing and passing runs. Prefer runs of the same SHA; when that is impossible, verify that the relevant test and CI configuration are identical across the compared commits. One passing rerun does not prove an infrastructure fault, and one timeout does not prove a product race.
+
+Use Actions logs and metadata to establish whether failures overlap on one host or resource namespace. Preserve links to the supporting runs rather than pasting large logs.
+
+## Classify the failure
+
+Classify from recorded evidence, not from the eventual fix:
+
+- **Host-resource collision:** the same port, socket, database, predictable path, cache, or external namespace is acquired by independent processes or jobs.
+- **Incomplete lifecycle:** teardown returns before children, workers, streams, servers, or callbacks reach quiescence; later output or mutations appear in another test.
+- **Process-global contamination:** outcome depends on test order or leaked `process.env`, `cwd`, fake timers, globals, mocks, locale, or module state.
+- **Load-sensitive synchronization:** a sleep, polling interval, or assumed event-loop turn substitutes for observable readiness or completion.
+- **Platform or entry-path mismatch:** the failure consistently follows an operating system, shell, filesystem rule, source/build mode, or executable entry. Timestamp precision, environment variable name case, handle-release timing, and permission semantics all differ between Windows and POSIX hosts, so a case passing on macOS says nothing about the Windows lane.
+- **Product concurrency defect:** the test controls its resources, reproduces deterministically with explicit overlap, and exposes a race in shipped behavior.
+- **External-provider transience:** the failure is owned by a live API or network boundary and matches its documented retry policy.
+- **Runner infrastructure:** checkout, dependency download, disk, host process, or runner service fails independently of the test command. Require direct runner evidence before assigning this class. Where a self-hosted pool exposes no host metrics, say so and classify from what the logs do carry: one signature repeating across unrelated branches on one pool is evidence of shared-host contention even when the host cannot be inspected.
+
+If evidence supports more than one independent fact, report each one. Do not collapse a timeout, signal, exit code, and assertion into a single inferred outcome.
+
+## Reproduce the smallest relevant topology
+
+Start with the owning test file or focused test name. Increase concurrency only to the first topology that reproduces the signature:
+
+1. one test process;
+2. concurrent tests or files;
+3. multiple independent Vitest processes;
+4. the owning repository gate with its configured worker count;
+5. separate jobs or runner processes sharing the implicated host resource.
+
+Match the active Vitest config, environment knobs, source/build mode, and platform. Do not lower a production timeout or add random load merely to manufacture a different failure.
+
+Where the signature belongs to a platform the available host cannot run, the ladder stops at the last reachable rung. Record that limit rather than substituting a passing run on another platform, then use CI as the reproduction, changing one suspected owner per run so the result stays attributable.
+
+For a suspected race, replace probabilistic timing with a barrier at the contested transition. For a suspected host collision, prove simultaneous acquisition of the same identifier or prove that atomic unique allocation removes the conflict.
+
+## Fix at the owner
+
+When implementation is authorized, fix the component that allocates, publishes readiness, mutates global state, or owns teardown. Do not hide the failure in a snapshot normalizer, retry wrapper, broader timeout, global serialization setting, or weaker assertion.
+
+Keep stable fixture data separate from live resource allocation. A recorded URL can remain stable while the fixture maps its transport to an OS-assigned port; a stable expected path can remain an assertion without becoming a shared writable directory.
+
+## Close the investigation
+
+The evidence is complete when:
+
+- the original signature has a supported classification;
+- the smallest relevant topology reproduces it, or the external evidence is sufficient and the reproduction limit is explicit;
+- an authorized fix fails under a negative control or pre-fix state and passes under the same topology afterward;
+- any concurrent-process, restoration, or quiescent-teardown proof required by the resource owner passes;
+- remaining Actions checks are reported as passing, pending, skipped, or failing from their observed state.
+
+Do not run until a test happens to pass and call that result stable. Stop after the selected evidence establishes the conclusion, or report the missing fact that blocks classification.

package/presets/code-vibe/skills/dsh-find-simplifications/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: dsh-find-simplifications
+description: 简化/减法/防复杂度累积； Find evidence-backed simplifications in DeepSeek Harness code, APIs, configuration, tests, and prose; write or consolidate proposals, identify small inline cleanups, or assess simplifications from another branch. Use for removing dead, duplicated, speculative, or unnecessarily maintained behavior and infrastructure.
+
+<!-- provenance: ported from deepseek-ai/deepseek-harness/.agents/skills/dsh-find-simplifications @ 00102833dfaee1da9f48a3a8eae9d34005a75218 (MIT License, Copyright (c) 2026 DeepSeek). Content adapted for self-contained operation outside the upstream repo. -->
+---
+
+# Finding DeepSeek Harness Simplifications
+
+Find changes that remove maintained obligations: APIs, representations, lifecycle states, configuration paths, dependencies, tests, or documentation. Prefer a few well-supported candidates over a count of deletions. This is guidance, not a checklist; keep the user's scope and distinguish a survey from permission to implement its proposals.
+
+## Establish scope and constraints
+
+Read the repository constitution（AGENTS.md、architecture、defensive patterns、testing policy——均源自 DeepSeek Harness）before judging packages. Consult relevant decision records for intentional decisions; use decision-record rules（proposed/implemented/rejected 骨架，源自 DeepSeek Harness note 体系）for new records. Archived notes are historical examples, not current authority: never inspect, verify, or repair their outbound links.
+
+The two LLM adapters are intentional. JSONL is the sole first-party Session persistence provider, while the backend-neutral Service Definition supports out-of-tree providers. Do not propose deleting an LLM twin or the persistence seam unless the user explicitly overrides that constraint. Unused members within a protected design remain candidates when their removal preserves its purpose.
+
+For broad requests, divide independent domains among subagents: loop and persistence; model/tool assembly; Host, Client, and SDKs; subprocess and execution providers; composition, scripts, tests, and documentation. Give each agent a bounded domain and require consumer evidence and rejected alternatives. Inspect substantial production machinery as well as obvious unused symbols; do not stop after the first promising deletion.
+
+## Search for removable obligations
+
+Use these questions to guide discovery. Read the relevant section of [historical patterns](references/historical-patterns.md) when a candidate needs calibration; the examples illustrate decisions, not a current deletion inventory.
+
+- **Does a declared feature have a complete effect path?** Trace producer, transformations, provider or endpoint support, and observable result. A field copied everywhere may still have no setter, no reader, or only implementations that reject it. Search constructors and discriminant emitters as well as callers.
+- **Which distinctions change a consumer's action?** Several internal states may require one model-facing status or one usable identifier. Keep internal distinctions that control authorization, residency, durability, or ownership; remove public distinctions that only invite an unusable choice.
+- **Could a smaller explicit behavior remove the subsystem?** Fixed intervals, caller-supplied time zones, or reported activation failure can eliminate generalized calendars, persisted defaults, or automatic rollback. Name the capability given up and the machinery deleted. A production caller makes this a behavior decision, not an automatic rejection; implementation must remain within the user's authorization.
+- **Can a consumer read the authoritative value when needed?** Look for copied histories, promotion ledgers, invalidation events followed by reads, and feature caches beside a shared projection stream. Derivation or reuse may delete subscriptions, retained data, stale-response handling, and recovery paths together. Establish the required time of observation first.
+- **Is composition being mistaken for policy?** Optional service presence, a provider method, or a sibling tool can express availability without deciding deployment behavior. Explicit configuration or a caller-intent operation may remove registries and dependency checks. Preserve distinct operations when their ownership or completion timing differs.
+- **What owns the complete maintenance cost?** Trace pass-through configuration, duplicate application trees, demo launchers used by products, resolver-only workspaces, and installation helpers with their own upgrade lifecycle. Compare the entire removed system with the replacement, including residual glue; moving complexity or adding a gate to keep duplicate definitions equal does not remove it.
+
+## Prove reachability and the trade-off
+
+Start with `rg`, then read the matches. Search exact symbols, property reads and writes, discriminants, event and wire strings, config keys, package names, and both `.method(` and `method(` forms. Tests and declarations can show a contract without proving a shipped producer or consumer.
+
+Include `packages/*/*/src`, `apps/`, `python/`, runtime scripts, shipped profiles and overlays, package manifests and exports, loader resolution, generated runtime assets, and installed-package consumers. Classify examples and fixtures by their actual entry point rather than directory name. Follow generated catalogs to their consumers: a catalog used by model-written plugin mounts is a dynamic product API, while a documentation-only listing is not a fixed caller. Public third-party extension paths can be intentional despite zero repository call sites.
+
+For each candidate, record the current owner, effective producer/consumer path, what disappears, what remains, and the strongest reason to retain it. Distinguish:
+
+- removal of unreachable or unread behavior;
+- a narrower public or product behavior with an explicit loss;
+- a protected obligation or insufficient evidence.
+
+Reject a candidate when it breaks a retained obligation, merely relocates the same complexity, or has no meaningful reduction. Read rejection reasons at the level of the proposed change: a stale inventory or a mixed proposal's rejected behavior does not settle every independent item. Refresh the evidence before re-proposing one. Small local improvements belong in actionable `TODO`/`FIXME`/`XXX` comments under the urgency rules（TODO/FIXME/XXX 按紧迫度分级）, not standalone design records.
+
+## Preserve ownership and failure semantics
+
+For copies, freezes, validators, and callback captures, name the value's origin, next owner, and trust boundary. Typed same-process calls ordinarily borrow readonly values; parsers, config loaders, queues, model/tool JSON, durable files, workers, processes, and wire decoders own or validate their inputs. Hostile-getter or callback-replacement tests do not establish a requirement by themselves. A frozen root does not prove its descendants immutable, and equal ids do not prove object identity.
+
+For asynchronous machinery, map each promise, flag, cancellation path, disposer, and reservation to its owner and transition. Collapse mechanisms only when they express the same fact. Preserve synchronous publication and rollback, callback containment, first-terminal-outcome arbitration, worker/process ownership, and dispose-to-quiescence where required. Durable start/end markers can record real facts even when transcript renderers ignore them; dropping interrupted work is a capability loss, not redundant-log cleanup.
+
+An invariant companion is justified by comparing independently produced observations that can diverge. Checks of service presence, plugin metadata, fixed examples, or the same mutation's return value do not qualify. Removing a companion includes its export, build entry, invariant-only compiler references, dependencies, and tests; record the package-specific omission reason in both READMEs. Keep checks comparing independent event producers, durable history, or mutable data.
+
+## Replace infrastructure only for a net reduction
+
+Follow the dependency policy（优先维护良好的依赖或 Node builtins；替换必须删除真实拥有的代码而非假设；评估维护/传递成本与残留语义）. Search existing dependencies and Node builtins at the engine floor before adding a package. Identify the exact implementation and dedicated tests the replacement deletes, its maintenance and transitive cost, and every residual behavior the glue must preserve.
+
+Exercise the mismatches most likely to defeat the replacement: protocol truncation, cancellation and teardown, configured bounds, deterministic test clocks, platform packaging, and source versus built entry points. A library that covers framing but requires rebuilding the same framing to enforce a size limit is not a simplification. An accepted edge-behavior change belongs in the proposal and relevant tests. Do not re-prove a dependency's generic specification while omitting tests for the harness-specific shim.
+
+## Record, consolidate, and validate
+
+Use [dsh-prose-standard](../dsh-prose-standard/SKILL.md) when prose is in scope. Remove code-restating or remotely owned explanations while preserving local behavior, timing, ownership, and failure obligations. Update affected READMEs, JSDoc, model-visible catalogs, configuration, snapshots, and generated files with their owning change.
+
+A substantial proposal belongs in an Issue with `Problem`, `Proposal`, `Alternatives considered`, `Acceptance criteria`, and `Risks`. Include concrete consumer evidence, the removed maintenance cost, the capability given up, and observable acceptance conditions. Record the implemented decision and verification evidence in the pull request and Git history. Update an existing Issue when the decision is the same; do not create duplicates to preserve candidate counts.
+
+Before opening a new Issue, check whether an existing Issue or pull request owns the same decision. Preserve current durable, wire, compatibility, or rejected-alternative obligations in the code or current documentation that owns them.
+
+When folding another branch, compare its independent diff against the target base, port only supported non-overlapping proposals, and consolidate overlapping rationale. Closing another PR requires authorization or clear ownership of that housekeeping.
+
+For docs-only issue or pull request work, run 项目自身的文档/静态检查（如 package.json 的 lint/typecheck 脚本）与 `git diff --check`（本环境无 doc-sync 门禁；文档改动以人工对照 + wish-programming 的 quote/模板一致性检查为准）; for skill or comment edits, include the applicable validator. Select other checks through pre-push minimal-evidence discipline（只跑与改动相关的验证）。 Report the surveyed areas, supported candidates, meaningful rejections or deferrals, notes added/consolidated/retained/removed, and commands actually run. 展开中的调研先把候选登记到 gap-register/工单（本环境无 draft PR 流程）；do not describe an unverified search as exhaustive.

package/presets/code-vibe/skills/dsh-find-simplifications/references/historical-patterns.md

@@ -0,0 +1,45 @@
+# Historical simplification patterns
+
+Use these examples to calibrate a candidate whose value is not established by an unused-symbol search. They describe recorded decisions, not current removal opportunities. Archived sources are frozen snapshots: read the cited note itself, never follow or repair its outbound links. Verify current owners and released-data obligations before applying a pattern.
+
+## Require a complete effect path
+
+A declaration, serializer branch, and test can form convincing-looking support without an effective feature. Trace both ends: something must produce the value, and an implementation must honor it. The producerless-variants decision（上游决策档案） removed reserved union members and cache hints without emitters. The inert-request-knobs decision（上游决策档案） distinguished knobs rejected by every adapter from working request fields available to hooks. Deletion included declarations, forwarding, rejection-only tests, and generated documentation.
+
+Zero fixed callers is weaker evidence than unreachability. The skill-registration rejection（上游决策档案） preserves a deliberate third-party registration path. For catalogued services, inspect generic plugin invocation and returned values before calling them dead. A working extension point and a field no provider can honor require different verdicts.
+
+## Reduce distinctions where consumers decide
+
+Map every public variant to the consumer action it enables. The model agent-availability decision（上游决策档案） gives models one usable Team target and projects multiple residency states to the same availability, while internal routing retains Session identity and residency. The capability-neutral sandbox context（上游决策档案） replaces two approximate capability registries with truthful conditional policy wording; exact tool availability remains in tool schemas. The gain includes registration methods, disposal state, invalidation, and combination tests.
+
+Do not erase distinct durable facts merely because one renderer ignores them. The durable step-boundary rejection（上游决策档案） retains explicit start and completion facts needed for empty failed steps, crash repair, and inspection. Simplify the projection only when the underlying distinction remains necessary.
+
+## Trade general behavior for a smaller explicit promise
+
+A used feature can still be an expensive way to satisfy the required outcome. The fixed-rate Schedule decision（上游决策档案） gives up calendar recurrence and missed-occurrence replay, removing a parser, evaluator, cross-record gate, durable variants, and backlog states. The non-transactional Loader decision（上游决策档案） gives up automatic plugin rollback while keeping failure reporting and consumer-owned activation checks. Moving generic rollback to another package would retain its cost.
+
+State the loss as clearly as the deletion. The interrupted-turn truncation rejection（上游决策档案） rejects a simpler recovery algorithm because an unfinished turn can contain substantial real work. Convenience, smaller unions, or fewer tests alone do not justify losing required data or behavior. A survey can propose the trade-off without implying permission to implement it.
+
+## Make assumptions explicit at their consuming operation
+
+Look for a local default that has acquired shared storage, synchronization, or confirmation machinery. The explicit Schedule time-zone decision（上游决策档案） keeps browser facts on the originating request and requires an explicit zone in the scheduling operation, removing Session defaults and cross-tab conflict state. The injected-content decision（上游决策档案） leaves framing with the caller and removes envelope controls threaded through unrelated layers. Both reduce the number of owners that must interpret one assumption.
+
+Do not move a requirement past the place that must enforce it. The Host-only Remote input-validation decision（上游决策档案） removes duplicate Client schema execution but retains Host validation before lookup and business invocation, plus local arity and Context binding checks. Its documented cost is later malformed-input failure and the loss of Client parsing as accidental redaction.
+
+## Derive at use or reuse an existing delivery owner
+
+For each cache or event subscription, ask when the consumer needs the value and whether an authoritative source already retains it. Feedback telemetry（上游决策档案） reads the canonical Session prefix at feedback time, deleting a continuously copied pre-feedback buffer and its listeners. Workspace recency（上游决策档案） sorts current summaries instead of persisting promotion history; manual ordering remains independent user state. Web subagent projections（上游决策档案） reuse a shared stream and projection store, removing feature notifications, repeated reads, and a second membership cache.
+
+The timing promise determines whether this works. Feedback-time redaction differs from capture-time redaction; manual placement cannot be derived from activity timestamps; an initial historical read may remain necessary when a stream baseline is absent. Name such residual obligations instead of declaring all caches redundant.
+
+## Remove accidental composition owners
+
+Inspect actual launch and resolution paths before trusting names such as demo, support, or example. The shared-base-config decision（上游决策档案） removes duplicate compositions and pass-through settings; actual Loader behavior determines overlay placement. The owner-local profiles and guides decision（上游决策档案） removes a resolver-only workspace by assigning tests, guides, and shipped assets to their owners. The merged subagent service decision（上游决策档案） uses explicit deployment policy instead of inferring it from provider or sibling-tool presence, while preserving optional dependencies internally.
+
+A smaller package count is not sufficient. Separate caller intents may have different ownership and completion timing; a retained Service Definition may serve independent providers. Prove the replacement's real composition and dependency behavior, and account for all remaining configuration and lifecycle glue.
+
+## Use rejected experiments to test parity claims
+
+The SSE parser replacement（上游决策档案） deletes generic framing and its conformance tests while retaining the provider-specific termination shim and documenting stricter truncated-tail behavior. In contrast, the timer-promises rejection（上游决策档案） records that a nominally equivalent builtin defeated deterministic fake-clock tests for a small deletion. The dependency-swap audit（上游决策档案） distinguishes replaceable generic code from configured bounds, security rules, lifecycle ownership, and deployment behavior a library does not implement.
+
+A past rejection is a scoped falsifier, not a permanent package blacklist. Revisit it only with new evidence addressing the failed premise, and measure the implementation, glue, tests, dependencies, and supported behavior together.

package/presets/code-vibe/skills/dsh-merging-stacked-prs/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: dsh-merging-stacked-prs
+description: GitHub 栈式 PR 合并； Use when landing a stack of dependent GitHub PRs (A ← B ← C, where each bases on the one below) onto master, merging a PR whose base is another open PR's branch, or whenever a request mentions "stacked PRs", "PR stack", "dependent PRs", or merging several related PRs in sequence. Requires every same-repository dependency chain to use GitHub's official stacked-PR feature before landing so GitHub owns stack-wide rules, CI, ordering, retargeting, and merge state.
+
+<!-- provenance: ported from deepseek-ai/deepseek-harness/.agents/skills/dsh-merging-stacked-prs @ 00102833dfaee1da9f48a3a8eae9d34005a75218 (MIT License, Copyright (c) 2026 DeepSeek). Content adapted for self-contained operation outside the upstream repo. -->
+---
+
+# Landing an official GitHub PR stack
+
+Land dependent PRs through GitHub's native stack object and `gh stack merge`. Do not reproduce stack semantics by merging and retargeting individual PRs with `gh pr merge` and `gh pr edit`. The root AGENTS.md（仓库宪法）owns the allowed merge-forward and rebase histories; stack review discipline（评审修复在栈层间的传播方式）applies to review-fix propagation.
+
+## Require native stack support
+
+Run `gh stack --version` before changing GitHub state. Hard-stop if the official extension or server-side stack feature is unavailable; do not fall back to manually merging and retargeting PRs one at a time. GitHub stacks require every head branch to live in the same repository, so hard-stop on a cross-fork chain.
+
+Use a clean dedicated worktree. Fetch current PR metadata and exact head OIDs rather than trusting branch names or an earlier report:
+
+```sh
+gh pr view <pr> --json number,author,baseRefName,baseRefOid,headRefName,headRefOid,isCrossRepository,state,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup
+```
+
+Query `PullRequest.stack` and `stackEntry.position` for at least one PR in each apparent chain; this official GitHub object, not base-branch inference alone, is the stack-membership authority. Paginate `entries` when `size` exceeds the returned page:
+
+```sh
+gh api graphql -F owner=<owner> -F name=<repo> -F number=<pr> -f query='
+query($owner: String!, $name: String!, $number: Int!) {
+  repository(owner: $owner, name: $name) {
+    pullRequest(number: $number) {
+      number
+      author { login }
+      baseRefName
+      headRefName
+      stackEntry { position }
+      stack {
+        number
+        baseRefName
+        size
+        entries(first: 100) {
+          nodes {
+            position
+            pullRequest { number author { login } baseRefName headRefName state isDraft }
+          }
+        }
+      }
+    }
+  }
+}'
+```
+
+Establish the expected bottom-to-top order from the live PR bases: the bottom targets the trunk, and each higher PR targets the head branch immediately below it.
+
+## Link missing stack members
+
+First compare any existing stack entries with the expected chain. One existing stack may contain an order-preserving subset of the requested chain; multiple stack numbers, an unexpected entry, or a conflicting order requires user direction before any mutation.
+
+When any dependent PR is not yet in that official stack:
+
+1. Compare every `author.login` exactly.
+2. If all authors match, link the chain automatically in bottom-to-top order:
+
+```sh
+gh stack link --base <trunk> <bottom-pr> <next-pr> ... <top-pr>
+```
+
+3. If authors differ or any author is unavailable, ask the user whether to link before changing GitHub state.
+4. Re-query GraphQL and require one stack number, the expected trunk, the complete PR set, and the expected positions and base chain.
+
+Never dissolve, reorder, or rebuild an existing stack automatically; `gh stack link` is additive and merged or queued entries cannot be unstacked.
+
+## Refresh only when needed
+
+Do not rewrite branches merely because a refresh mechanism exists. When the live merge state or repository rules require an updated trunk, choose either allowed history:
+
+- **Native cascading rebase:** check out the remote stack with `gh stack checkout <pr-or-stack>` when it is not tracked locally, then run `gh stack sync`. The command may rebase and lease-protected force-push every active layer before local validation. Immediately inspect the rewritten scope, run the relevant checks for every affected layer, and do not merge or claim readiness until they pass. If sync detects a rebase conflict, use `gh stack rebase`, resolve and validate it, then publish with `gh stack push`. If checkout or sync reports divergent local and remote stack compositions, cancel and ask rather than deleting or recreating the remote stack automatically.
+- **Incremental merge-forward:** merge the trunk into the bottom affected branch, then propagate each updated parent into its child in bottom-to-top order and push normally. If the base advances during an in-progress merge, preserve that checkpoint before merging the newer tip.
+
+Any history rewrite is allowed after review, but it invalidates commit-OID assumptions. Re-fetch exact heads and re-audit unresolved review threads, approvals, mergeability, and checks after the push. Never use raw `--force` or overwrite a concurrently advanced remote head.
+
+## Preflight the merge range
+
+Re-query the official stack immediately before merging. Require every selected PR to be open, non-draft, in the expected order, and compliant with the repository's review and check requirements. Treat each PR's state independently; a ready top layer does not prove its dependencies are ready.
+
+"Land the stack" selects the whole stack. A partial landing requires an explicit boundary PR and includes every layer from the bottom through that boundary.
+
+## Merge through the stack API
+
+Merge the whole stack by its official stack number:
+
+```sh
+gh stack merge <stack-number> --yes --merge
+```
+
+For an explicitly requested partial landing, merge through the boundary PR:
+
+```sh
+gh stack merge <boundary-pr> --yes --merge
+```
+
+Do not pass `--delete-branch`, manually retarget dependents, or issue per-PR merge commands. GitHub merges the selected range bottom-up and retargets/rebases any remaining upper layers. A direct stack merge is all-or-nothing; when the trunk uses a merge queue, GitHub queues the selected range together but may land it in separate groups.
+
+Do not bypass merge requirements. If the native merge reports a blocker, inspect and resolve that blocker through the owning PR or stop and report it; never fall back to `gh pr merge`.
+
+## Verify the landed state
+
+Wait for every selected PR to report `MERGED`; a queued request is not a completed landing:
+
+```sh
+gh pr view <pr> --json number,state,mergedAt,mergeCommit,baseRefName,headRefName
+```
+
+For a partial landing, re-query the official stack and verify that every remaining PR is still linked in the expected order and targets the stack trunk or the layer below it. Re-check current heads, review state, and CI because GitHub may have rebased the remaining layers.
+
+Delete branches only in a separate final pass after the corresponding PRs report `MERGED`. Before deleting each branch, require GitHub to report no open PR still using it as a base:
+
+```sh
+gh pr list --state open --base <branch> --json number --jq length
+```
+
+Anything other than `0` blocks deletion.
+
+## Checklist
+
+- [ ] Native `gh stack` support is available; every PR branch is in the same repository.
+- [ ] Live PR bases and exact heads establish one bottom-to-top dependency chain.
+- [ ] GraphQL reports one official stack with the expected trunk, entries, and order; an eligible same-author unstacked chain was linked automatically.
+- [ ] Any rewritten layers passed relevant validation, and review threads, approvals, mergeability, and checks were re-audited afterward.
+- [ ] The whole stack, or an explicitly bounded prefix, was submitted through `gh stack merge --yes --merge`.
+- [ ] Every selected PR reports `MERGED`; any remaining upper layers still form the expected official stack.
+- [ ] Branch deletion happened only after merged-state and zero-dependent verification.

package/presets/code-vibe/skills/dsh-prose-standard/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: dsh-prose-standard
+description: 写作/措辞/注释与文档文案标准； Use when writing, reviewing, restoring, trimming, or auditing prose in the deepseek-harness repo, including deciding where documentation or comments are required across Markdown, JSDoc, code and test comments, prompts, descriptions, diagnostics, and CLI or UI strings.
+
+<!-- provenance: ported from deepseek-ai/deepseek-harness/.agents/skills/dsh-prose-standard @ 00102833dfaee1da9f48a3a8eae9d34005a75218 (MIT License, Copyright (c) 2026 DeepSeek). Content adapted for self-contained operation outside the upstream repo. -->
+---
+
+# DeepSeek Harness Prose Standard
+
+Write enough to preserve the contract, then remove reasoning transcripts, repetition, and decoration. A contract is an obligation, invariant, precondition, postcondition, or compatibility promise that a caller, callee, implementer, producer, or consumer relies on. This skill owns editorial judgment and required prose coverage; use 本环境的文档工作流（放置/预算/双语对与文档门禁按 wish-programming 的模板与本包 [`UPSTREAM.md`](../UPSTREAM.md) 执行；上游 dsh-doc 体系本环境按自包含规则承接） for placement, budgets, bilingual pairs, and documentation gates, and [dsh-trim-cot-leakage](../dsh-trim-cot-leakage/SKILL.md) for hunting and fixing reasoning-transcript leakage. It is guidance, not a script.
+
+Treat `contract`, `boundary`, `shape`, `surface`, `seam`, `gate`, and `vocabulary` as terms to check before use, not banned words. First ask whether the exact rule, API, field set, type, validation, timing point, component split, or failure states the fact better. Keep a term when it names the exact technical subject, including caller/callee contracts and security/process boundaries.
+
+Comments describe non-obvious contracts or rationale that code cannot express; they do not restate what code already implies.
+
+## Inputs and exclusions
+
+Require an explicit `scope`. If it is missing, report the required input and stop; do not infer a repository-wide scope or begin an interview.
+
+Accept `mode: automatic | interactive`; default to `automatic`. Enter interactive mode only when the user explicitly requests questions or calibration.
+
+`mode` controls questions, not write authority. Review and audit tasks report findings without editing; explicitly requested write, fix, or trim tasks apply clear changes.
+
+Always exclude `vendor/` from discovery, review, and edits, even when the requested scope is the whole repository. Do not follow a symlink into it. Put exclusions after inclusion globs so a later include cannot re-admit it: for example, end ripgrep commands with `--glob '!vendor/**'`, and give Git commands an explicit `:(exclude)vendor/**` pathspec. If the requested scope contains only `vendor/`, report that no eligible files remain.
+
+Also exclude `archived third-party snapshots/` from prose review and edits. Archived issues and pull requests are frozen snapshots; inspect an exact target only to understand a historical inbound citation, never to modernize its prose or outbound links.
+
+Treat generated catalogs, snapshots, and fixtures as derivative. Trace every consumer before editing: source JSDoc may also feed a generated model-visible catalog. Edit the owning source or scenario first, then regenerate every derivative. When a generator extracts a summary from owner prose, make the extracted sentence complete for that surface. Bilingual pairs have no permanent owner: either language may be the authored side for an update. Follow the lightweight routine path（双语对最小更新并重录哈希，源自 DeepSeek Harness 文档标准）, update the counterpart minimally, and re-record the pair.
+
+## Preserve the complete proposition
+
+Before editing, identify every proposition in the passage. Preserve each relevant:
+
+- actor and action;
+- condition, timing, and ordering;
+- modality such as must, may, or never;
+- negative guarantee and exception;
+- ownership, side effect, failure mode, and consequence.
+
+Remove adjectives, repetition, and narration only when every factual clause survives and the result is clearer. A smaller word count alone is not an improvement.
+
+Keep a complete local contract at the point of use: behavior, failure, ownership, and consequence that a caller or maintainer needs there. Aggressively link to the owning document for architecture, rationale, algorithms, history, or extended examples. One explanation has one home; essential contract facts may repeat locally.
+
+Keep non-obvious rationale when omitting it could plausibly cause misuse or an incorrect simplification. Otherwise state the consequence and link the rationale home.
+
+## Required coverage by prose location
+
+This is not a one-way shortening pass. Add or restore prose when code, types, and structure do not communicate a required contract below. Do not add a comment when those facts are already obvious locally.
+
+- **Public JSDoc:** document caller-visible return distinctions, throws or rejections, side effects, ownership, timing, cancellation, and durability.
+- **Internal comments:** orient non-local structure and obviously complicated local structure, including invariants, race ordering, ownership, security boundaries, and surprising failure behavior. Delete control-flow narration and code restatement.
+- **Module comments:** state the module's role, dependencies, responsibilities, and non-obvious architecture choices; link architecture choices to their owning explanation.
+- **Tests:** explain only non-obvious test design—why a fixture, assertion, platform accommodation, real entry path, or indirect observation is necessary. Delete walkthroughs and inventories.
+- **Cookbooks:** include prerequisites, required actions, the real entry path, observable verification, and concise warnings.
+- **READMEs:** include the consumer contract: configuration, semantics, failures, limitations, extension points, and model-visible effects. Quote stable model-visible text owned by the package; link generated catalogs and cross-package owners. Keep durable gaps and maintainer traps, not ordinary cleanup inventories. Follow the package README requirements（配置/语义/失败/限制/扩展点/模型可见效果——源自 DeepSeek Harness cookbook）.
+- **issues and pull requests:** retain unique rationale, mechanisms, alternatives, consequences, shipped verification evidence, and named coverage gaps. Implemented issues and pull requests state shipped reality in the present tense; remove planning checklists, not evidence of what pins the decision.
+- **Postmortems:** retain the incident sequence, evidence, causal chain, impact, and prevention. Remove repeated persuasion or implementation detail that does not establish causality.
+- **Skills and agent instructions:** state behavioral guardrails and explicit scope limitations such as “guidance, not a script/checklist.” Keep the workflow concise and link its source of truth.
+- **Examples and configuration comments:** explain access limits, non-obvious wiring or load order, security stance, replay behavior, exceptions, and likely misuse. Do not narrate entries that the configuration already shows.
+- **Prompts and visible strings:** treat wording as behavior. Client UI copy belongs in typed locale dictionaries and reaches Cordis-free primitives as explicit localized props; inspect text, accessibility names, tooltips, placeholders, and format templates together, then run 本环境可用的文案/UI 一致性检查（上游的 verify-client-ui-i18n 门禁本环境不存在，以人工逐项对照确认）。Update the owning runnable snapshot for model-visible text and repository-required GUI evidence. If the authorized scope has no owning scenario, leave the wording unchanged and report the deferral; do not silently fold it into a prose-only edit.
+- **Diagnostics:** name the failing subject or path, violated rule, and correction when it is non-obvious. Remove internal execution narration.
+
+Preserve searchable mechanism names and meaningful modal, temporal, or negative emphasis. Normalize decorative emphasis only.
+
+## Workflow
+
+1. Confirm the scope, mode, current branch or PR base, and applicable `AGENTS.md` files. Do not inspect unrelated branches.
+2. Read the documentation standard（文档分层/写作规则/预算，源自 DeepSeek Harness） and the owning code or document before judging a passage. For calibration or unfamiliar cases, read [the distilled examples](references/examples.md).
+3. Inspect the requested scope, not only the largest files. Use searches and word counts to find candidates, then judge passages semantically.
+4. Classify each candidate as keep, add, trim, restore, restructure, or defer. Apply clear changes only when the task authorizes edits; do not manufacture edits to satisfy a deletion target.
+5. Update the owner before derivative artifacts. Re-check analogous passages after learning a new rule.
+6. Run the narrow relevant checks, documentation gates, `git diff --check`, and behavior tests for visible strings. Verify the final diff contains no `vendor/` path and report any accidental vendor match rather than claiming a clean exclusion history.
+7. Report the inspected scope, clear changes, deliberate keeps, deferred cases, and checks actually run.
+
+## Borderline decisions
+
+A case is borderline only when at least two versions satisfy the complete-proposition rule but trade accepted principles, and this skill does not already resolve the tradeoff. A rewrite with one proposition-preserving answer is not borderline.
+
+In automatic mode, apply clear edits when authorized and report genuine borderline cases without asking questions. Do not weaken a proposition to make progress.
+
+In interactive mode, group analogous passages under the governing principle. Present two or three viable versions, recommend one, and state the factual or structural difference. Do not offer inferior distractors. Use the user's requested channel; when calibrating a PR through inline comments, place the recommended provisional version in the diff and attach the alternatives to that exact line.
+
+After the user decides, distill the principle and versions into [the examples](references/examples.md), without PR history or reviewer narration, and apply the learned rule to every analogous passage in scope.