dsh-cordis-sub-agent

English | 中文

Unofficial community plugin, independently maintained and not affiliated with DeepSeek.

dsh-cordis-sub-agent manages plugin development inside the DeepSeek Harness
monorepo. Each task owns one generated workspace package at
packages/generated/<plugin-name>/.

Installation

Install the Bundle from GitHub into a DSH Profile:

dsh plugin --profile web add github:ganfabo123-cmyk/dsh-cordis-sub-agent

Run that Profile from the DeepSeek Harness checkout you want to modify. The plugin's repoRoot defaults to the launch working directory; set it explicitly in a Profile patch when DSH is launched elsewhere.

Git installation runs the package's self-contained prepare build. If pnpm requests build-script approval, approve only this repository when you trust its source, then repeat the installation command. Use dsh --profile web --dump-config and confirm the cordis-sub-agent row before starting the Profile.

Recommended composition with Experience Memory and Explorer

The effective plugin-development stack has three capabilities:

Experience Memory recalls validated lessons
  -> Explorer investigates the current DSH checkout
  -> Cordis Sub-Agent scaffolds, documents, verifies, and accepts the plugin
  -> Experience Memory records the reusable result

Cordis Sub-Agent 0.1.0 already embeds the Explorer workflow and registers explorer, explore_paths, and explore_semantics. The standalone dsh-explorer-agent registers the same three names. DeepSeek Harness rejects duplicate Tool names, so do not load the standalone Explorer package in the same Profile as this Cordis version.

For normal Cordis plugin development, install Experience Memory and Cordis Sub-Agent:

dsh plugin --profile web add github:ganfabo123-cmyk/dsh-experience-memory
dsh plugin --profile web add github:ganfabo123-cmyk/dsh-cordis-sub-agent

If that Profile already contains dsh-explorer-agent, remove it before loading Cordis:

dsh plugin --profile web remove dsh-explorer-agent

Start the Profile from the DeepSeek Harness repository root. Use this operating sequence:

1. Call memory_search with concrete requirement, package, API, and failure keywords. Use memory_get only for candidates worth reading; memories are past evidence and may be stale.
2. Call Cordis's built-in explorer for facts that must be verified in the current checkout. Pass the relevant directories and one precise repository question.
3. Use the Cordis lifecycle below to create the generated plugin, complete documentation, run deterministic checks, and perform fresh-runtime acceptance.
4. After the result is verified, call memory_record only for reusable successes, failures, compatibility constraints, or recovery procedures. Do not store routine logs or the complete session.

This gives Cordis development all three capabilities while loading two packages: the Explorer capability is embedded in Cordis. The standalone Explorer package is intended for Profiles that need reusable repository exploration without the Cordis development lifecycle. A future Cordis option could delegate to the external Explorer package; 0.1.0 does not provide that mode.

Development flow

submit_plugin_metadata
-> task_id
-> prepare_plugin_reading(task_id)
-> Read Agent returns a JSON reading plan
-> Main Agent reads according to the plan, writes, builds/tests, and fixes the same pluginRoot
-> document_development (Documentation Agent: README files only)
-> verify_development (foreground engineering commands)
-> start_acceptance (fresh DSH runtime with temporary acceptance config)
-> send_acceptance_message
-> stop_acceptance
-> permanent integration

packages/generated/<plugin-name>/ matches the repository's existing
packages/*/* workspace glob. The generated package can therefore use
workspace:* dependencies after the workspace install is refreshed. Normal
development never edits the root pnpm-workspace.yaml.

The canonical ordinary-plugin reference is
packages/examples/plugin-reference/. Read it for the standard plugin entry,
config, Tool, service, persistence, lifecycle, test, and documentation shape.
The other packages under packages/examples/ are architecture references for
agent-spine, ACP, and JSON-RPC composition.

Tools

• submit_plugin_metadata: submits requirement-stage plugin input/output schemas, block-and-arrow execution flow, and detailed plugin document; creates packages/generated/<plugin-name>/ and returns its in-memory task_id and plugin_root.
• prepare_plugin_reading: accepts only that task_id, sends the stored metadata to the read-only Read Agent, and returns its reading plan.
• get_development_task: returns the in-process V3 metadata task, reading plan, documentation, verification, acceptance, evidence, and errors.
• document_development: invokes the Documentation Agent after Main Agent coding and local checks.
• verify_development: runs deterministic foreground typecheck/build/test/documentation checks and returns complete command output.
• start_acceptance, send_acceptance_message, stop_acceptance: run and control the fresh DSH acceptance runtime.
• discard_development: stops the acceptance runtime and removes the task-owned pluginRoot. A new task may only claim a plugin directory that did not already exist.

Ownership and write boundaries

Before acceptance passes, ordinary task writes are limited to the pluginRoot and
Harness-managed temporary acceptance YAML. The Read Agent only investigates and
returns a JSON reading plan. The Main Agent uses that plan to inspect the repository and owns business source
and local build/test repair. The Documentation Agent may modify only
README.md, README.zh.md, and README.i18n.yaml inside the pluginRoot; it
must not modify business source, tests, package configuration, or root files.

Acceptance uses a temporary composition file. A failed acceptance leaves the
same pluginRoot available for Main Agent repair and another verification cycle.
Discard removes the pluginRoot and temporary acceptance resources. A passed
acceptance removes the temporary YAML and moves the task to permanent
integration, where root-level changes are allowed only when the actual DSH
integration requires them.

Completion requirements

Engineering verification is evidence, not behavioral proof. Completion also
requires successful fresh-runtime acceptance and the required user acceptance
interactions. User acceptance input is forwarded unchanged.

Model Experience

The Main Agent sees the submitted metadata, Read Agent JSON plan, task facts,
evidence, and tool catalog. It uses the plan to inspect the repository, then
performs implementation, local commands, and repairs directly. The Documentation Agent receives the implementation context
as a one-shot documentation subtask and is restricted to the README triad.

Known Limitations and Deferred Work

Documentation checks validate structure and command results; they do not judge
translation quality. V3 task facts are process-local, so a DSH restart invalidates
the task id while leaving its generated directory in place.

The plugin deliberately targets a real DeepSeek Harness source checkout. Repository reading, generated packages, engineering commands, and the package-owned acceptance runner depend on that checkout's layout and built runtime artifacts. It is not a general-purpose plugin generator for arbitrary repositories.

The acceptance lifecycle can consume model credentials and requires the selected provider, model, and patch dependencies. Package and Profile smoke verification therefore does not by itself prove a real model acceptance session.

Cordis 0.1.0 cannot be composed with the standalone Explorer package because both register the same Tool names. Use the embedded Explorer as described above.

Development

pnpm install
pnpm run check
pnpm pack

See VERIFICATION.md for standalone package and fresh Profile evidence.

License

MIT. See LICENSE and NOTICE.