Legion · Leading harnesses, one co-evolving team

English | 简体中文

Legion's goal is to bring any leading harness into a team that works for the user, shares tools and capabilities, and improves together through real work.

The user provides a goal. The team researches, organizes itself, uses each other's tools, reviews contributions and continues the same deliverable. A verified improvement made by one member can become usable by others and be improved again in later work. This is not a menu for choosing one assistant or a collection of independent answers.

DSH is an entry point; the co-evolving team is the product. Plugin discovery, GitHub integration and core configuration support that team rather than define the whole vision. The product definition and verified scope remain separate: installation and connection checks do not establish full collective autonomy or co-evolution.

Connector 0.5.0 is public: set up the team once, then start automatically. The public Legion core v0.1.0 is installed separately. Its first-party source is MIT, it remains a technical preview, and third-party licenses are retained.

Choose companions and a collaboration style; improvement defaults to on. Submitting schedules the first round and weekly follow-ups through native DSH, with pause and original-conversation entry points. See the workflow and boundaries. Scheduling, model execution and verified improvement remain separate. Users configure their own models and accounts; no shared credentials are included.

Get started

1. Install through DSH Discover or the fixed Git command, then explicitly enable Legion. Neither route requires publishing this connector to npm.
2. Open Legion, choose a Working session, then follow Companions → Collaboration → Grow together. You may also use Discover directly; tools, Skills and public GitHub search need no Legion core.
3. For delegated work, download and verify core v0.1.0, create a fresh Python 3.12 environment, then follow init → serve → dsh-config → Save connection. Configure your own model before submitting work; the connector does not bundle or start the core.

Try an ordinary DSH request:

Find an existing plugin for the capability I need. Show its sources and limitations before installing anything.

Post-release receipts on GitHub main · Limits, data and license

What you can do

Need	Entry point	Boundary
Find an existing capability	legion_discover	Current Agent-visible tools, user-configured native markets, or public GitHub; not a machine-wide inventory.
Read a project's interfaces and license	legion_source	Pinned source, file hashes and bounded previews; incomplete reads stay explicit.
Package code already adapted by an author	legion_bundle	Writes workspace files and metadata; does not install or execute them.
Install or switch capabilities	Official plugin_manager	Native installation, approvals, bundle selection and individual plugin switches.
See what your Legion service really has	legion_runtime	Current member, capability or catalog observations; registration is not installation, configuration or verified execution.
Delegate work and continue revisions	legion_submit	Real delegation; previous_task_ref reconnects to the original Legion conversation.
Use a local tool for a Legion task	legion_call, then a separate legion_message	Execution and delivery are two decisions; a mailbox receipt is not model consumption.
Follow remote work	legion_status	Task state, events, commander messages and formal exports; no automatic mailbox execution.
Receive actual files	legion_download	Downloads formal artifacts of this task and compares their bytes with the service's SHA-256.

You can also ask DSH to inspect a public repository, adapt its real interfaces, and package independently useful capabilities. This is not an automatic converter for arbitrary applications. The on-demand legion-ecosystem skill supplies the available tools and development references.

The core retains world-reference research, intent context, native collaboration, knowledge reuse, failure feedback, continued revision and formal delivery through existing modules. See the capability map. Retaining a mechanism does not prove every member is installed or that a team generally outperforms the strongest individual harness.

Install a reviewed local copy

Requirements: Node.js >=24.9.0 and official npm DSH 0.2.1-rc.2. The Agent needs the relevant native tools: write for generated files, plugin_manager for installation, and optionally plugin_market for configured indexes. Slash commands additionally need the Host's commands service.

The sidebar needs DSH's browser UI, session and command services. Editable settings, Skills, markets and bundle management use the corresponding native services when available; the workbench does not bypass missing services or permissions.

If you already have a reviewed local copy, use the official plugin_manager. Replace the placeholder below with its absolute bundle directory, preserving any spaces:

{
  "action": "install_bundle",
  "target": "file:<absolute bundle directory>",
  "enabled": false
}

This is a parameter template, not a published package address. For public pinned-Git installation and community catalog submission, see publication routes.

• Prefer file: for package installation with declared dependencies. A bare directory can become a development link: whose target dependencies are not installed recursively. A local directory is mutable, not a content hash.
• With enabled:false, new bundles are not automatically selected for activation; updates preserve existing switches. If you do not want updated code to run, disable that bundle before updating. Disabled does not mean dependency build scripts cannot run: inspect native warnings and any pendingBuilds; build permission is separate.
• After reviewing the installation result, manage the bundle with set_bundle. Read actual entryId values from list_plugins before using set_plugin; declared rowId/module names are not runtime IDs. A disabled bundle may have no runtime entries.
• Bundle selection may load all default-enabled rows. Installation, selection, activation and actual calls are different facts. Preserve application, changed, warnings and restart requirements; do not assume a failed load rolled back selection.

Host plugins run outside the agent sandbox. Review code and dependencies before trusting them; see Security.

Fixed-version Git installation — v0.5.0

Requires Node.js >=24.9.0 and DSH 0.2.1-rc.2. Replace the example web profile if needed and retain -w:

dsh plugin --profile web -w add 'github:seanliii/dsh-plugin-legion#v0.5.0'

Pinned source: 090c82e273dcbf4912ab48906bf28f9f086ae53d. The release retains the reviewed 32-file package and its checksum. Explicitly enable Legion in DSH Plugins after installation. Post-release documentation on main does not move the tag or replace release bytes; “development” wording in the frozen archive records its pre-publication state. See 0.5.0 installation and verification.

Fixed-version Git installation — v0.4.2 (historical)

This edition uses Git, not npm publication. Replace the example web profile as needed and retain -w:

dsh plugin --profile web -w add 'github:seanliii/dsh-plugin-legion#v0.4.2'

v0.4.2 is pinned to 7ca96434ee077102d2e2459173fffa91747898b5. The public package, native Discover installation, saved connection and restart recovery are recorded in 0.4.2 acceptance. Installation retained a pnpm peer-dependency warning. No model was configured in this fresh instance; a working connection does not certify member execution.

Fixed-version Git installation — v0.4.1

The following is the existing 0.4.1 release, not a 0.4.2 installation or acceptance record.

Use the published fixed tag; replace the example web profile as needed and retain -w:

dsh plugin --profile web -w add 'github:seanliii/dsh-plugin-legion#v0.4.1'

v0.4.1 is fixed to 87a2f4dae1c61e2764b7748ecb10ea7b367fcf2f. Anonymous installation of that full commit and the scoped core-free native UI checks are verified; the fresh installation started disabled and retained a pnpm peer-dependency warning. The v0.4.1 Release provides the original reviewed TGZ and SHA256SUMS, both checked by anonymous re-download. The 0.4.1 catalog update is open for maintainer review; Git/tag installation does not depend on that review. Later documentation does not move this or older tags; the installation guide also provides the exact-commit command.

Historical 0.4.0 commands, commit, tag and scoped acceptance remain in the 0.4.0 records, not as evidence for 0.4.1.

Open the native workbench

After installing and enabling the connector in DSH Plugins, open Legion in DSH's sidebar. This is a native DSH page, not another website or service. Choose the Working session at the top right; a single existing session is selected automatically. If none exist, create a DSH conversation, then click Refresh sessions. No core yet? Go straight to Discover; an unconnected members page does not block discovery.

Page	What to do	What it means
My Legion (0.5.0)	Companions → Collaboration → Grow together → Form team and start automatically. Inspect schedules, open results, run again or pause.	Saves native candidateHarnesses and teamProfile, schedules the first round and defaults to weekly follow-ups. Selection is not installation; scheduling and delivery do not prove completed improvement.
Discover	Search Session tools / Skills, GitHub, or DSH plugin market.	Tools are those visible to the selected session's Agent; Skills are guidance. Only configured market indexes are searched. No core is required, and discovery executes no tools.
Add capabilities	Inspect and explicitly install an existing DSH bundle, or edit a goal and Delegate integration.	Native package management and model-led adaptation are different operations; reading a repository does neither automatically.
Integration tasks	Refresh tasks, then Read live progress; inspect export records and use Download file where available.	The list is this session and identity's local recovery index, not a live feed. Runtime, artifacts, refusal reasons and pagination are shown separately; incomplete data is not zero artifacts. done is not a usable-result guarantee.
Connection	Enter Core URL, Token environment variable name, or private token file path, then Save connection.	Never enter the token value. Saving native configuration reloads the connector; it does not install a core or configure models.

Switching the working session changes tool visibility and task context, not the scope of settings: bundle switches and connector configuration affect the same DSH profile. Only members the service marks as selectable can be checked. Saving needs writable native configuration; on a revision conflict, reload it before editing again.

Install a bundle, or delegate an adaptation

• Already a DSH bundle: on Add capabilities, enter a package name, Git source or local bundle → Inspect source → review it → Install / update. New bundles are not automatically selected for activation; updates preserve existing switches, so enabled code may keep running. To prevent updated code from running, disable the bundle below before installing the update. These buttons keep DSH's official pluginManager and enabled:false, not a second installer or a forced-disable operation. Inspection accepts a source format/metadata, not its safety. Handle pendingBuilds in DSH Plugins; disabled bundles can still have dependency build steps.
• Then choose what to enable: under Installed DSH capability bundles, use Enable bundle / Disable bundle and expand Individual plugins and loading state for Enable plugin / Disable plugin. Respect read-only or restart-required results. This workbench cannot disable its own Legion connector; use DSH Plugins for that. Search session tools again, then actually use the capability in DSH; installation, visibility and execution are separate checks.
• Still a source project: a GitHub result's Inspect & delegate opens the add page, inspects the source and fills an editable task; it does not submit or install. You can also enter owner/repository and an optional branch, tag or commit, then Inspect project & license. Only Delegate integration submits the goal to your configured core/models and may incur costs. The pinned commit and short source/license facts accompany it; Legion decides how to adapt it. You can omit the repository and ask Legion to research options.

If an install reply is uncertain, keep its request ID and use Recover install result, not another installation. Request cancellation is a request, not confirmation of cancellation. An uncertain delegation offers Retry with the original key while that operation is retained; do not change keys to repeat an unknown side effect.

The task page does not auto-poll or execute incoming messages. It can page through artifact records and events, and Download file reuses the existing /legion download command in the selected original conversation. The file is saved on the DSH Host, not automatically in the browser's Downloads folder; the receipt shows its path, byte count and hash check. Same-name/history records remain distinct, and clipped details or refusal reasons stay marked incomplete. Continuation, feedback and cancellation still use /legion in the original conversation, not new task-page actions. Projection and download limits · Detailed workflows.

Connect your independently installed Legion core

Download the public v0.1.0 archive and SHA-256, then follow Core installation: a fresh Python 3.12 environment → init → serve → dsh-config → Save connection. Model configuration is needed before real delegation, not to obtain the source. Existing authorized instances can continue to use their own connection settings.

Keep serve running. On the same machine, open another terminal in the core source directory and run:

.venv/bin/python -I meyo.py dsh-config --state-dir "/absolute/path/to/your/private-instance"

Use its config object to fill Connection → Core URL / private token file path → Save connection, or the equivalent native plugin settings. The output contains a service address and credential-file path, never the credential:

{
  "baseUrl": "http://127.0.0.1:8015",
  "tokenFile": "/absolute/path/to/your/private-instance/login-token.txt"
}

tokenFile is operator configuration, not a model-chosen path. It must be an owner-only regular file on the DSH Host (use mode 0600), containing one token and no more than 4096 bytes. The page neither reads nor displays its contents. A configured but invalid file fails explicitly; there is no environment fallback.

Rotation is detected, not silently hot-swapped. Each credential read rereads the file and checks for an identity change. Once a connector has bound an identity, a changed token stops that old connector and requires a plugin reload before using the new identity. Changing the service address or actual token selects a separate recovery index: old task references are not inherited, migrated or deleted.

Saving configuration or reloading ends local pending requests; it does not cancel remote tasks. Rotating the file also does not cancel them or prove that the core accepts the new token. The page's Reload configuration button only rereads settings; use native plugin management to reload the connector. After saving/reloading, refresh members to check connectivity. Configuration accepted/read back is not model verification; submit a real task separately.

Existing remote services: environment configuration remains supported

Configure these privately in the DSH Host environment. The JSON Environment editor needs JSON string values, including quotes; ordinary process environment variables use plain strings.

Variable	Example JSON value
LEGION_BASE_URL	"https://legion.example.invalid"
LEGION_PERSONAL_TOKEN	"<your-personal-token>"

Keep the token value out of chat, commands, plugin configuration and Git. tokenFile accepts only a local absolute path and takes precedence over tokenEnv without fallback. Remote URLs require HTTPS; HTTP is allowed only on loopback. Installing this connector does not start a service. Optional candidates, project bindings and private state settings are in Protocol.

/legion help
/legion runtime members
/legion runtime capabilities
/legion start page-1 Create a small HTML page with status text and a button.
/legion status <task_ref>
/legion download <task_ref> <artifact_id>

Use references and artifact IDs returned by the tools, not the placeholders. list, continue, message, resume and cancel are also available. legion_submit.tool_names can share selected visible tool schemas; it grants no remote execution access.

Share a local result in two steps

1. Use legion_call with the original task reference, recipient, stable operation key and selected native tool. Its first receipt is pending, not outer-call success. The bridge sends no HTTP or messages; the selected tool may have its own network behavior.
2. Wait for the enclosing Host call to finish. DSH then decides whether to use legion_message, with its own stable key, to share only the final content actually visible and appropriate to send. Do not combine execution and a success message inside the same run_code or another unfinished parent call.

The official result observer records ancestor status metadata only. Same-key, same-input recovery never reruns the tool or replays old result bodies, including after the target capability is disabled, provided this connector and the original session/state remain available. Unknown execution is not permission to change keys and repeat a side effect.

Message acknowledgement is separate from execution and does not prove remote-model consumption or wake a finished task. The bridge's text projection omits binary media; local DSH image forwarding is not full-media transfer to Legion. See the two-step protocol.

How DSH and Legion work together

Express what you want once. DSH can discover existing capabilities, read actual source, adapt useful interfaces into native plugins, and delegate work to your Legion core for research, collaboration, revisions and file delivery. The aim is one useful entry point into an ecosystem, not a larger control panel.

DSH: conversation, native tools, permissions and UI
  ↕ Legion plugin: discovery, source, packaging, tasks and files
Independent Legion core: research, orchestration, recovery and delivery
  ↕ Existing member/capability interfaces, installed and authorized as needed
Native harnesses · CLI / MCP / skills · Media · Devices

The connector provides a five-page workbench in DSH's native sidebar. The actual Legion core is installed separately; native harnesses, media models and devices are added as needed.

No Legion core or token is needed to search current DSH tools, Skills or public GitHub. Source reading, packaging and available native bundle-management services also work independently of the core. Skills provide guidance, not new executable tools. Collaboration requires a compatible service and a personal identity you are authorized to use. DSH keeps its own loop; Legion owns delegated work, and this connector does not add another commander.

Core capabilities and installation · Ecosystem and principles · Versioned evidence · Protocol · Security

Limits, data and license

Repository text, catalog descriptions and task messages are untrusted material, not instructions or permission grants. Source hashes identify bytes; packaging is not runtime verification; download integrity is not file safety. Redaction is bounded, not a universal secret detector.

Keep recovery state private. New v2 native-call records retain metadata, not result bodies; old records and both systems' sessions may still contain content. Uninstalling does not delete user files or cancel remote work.

MIT covers this connector; the owner has separately confirmed MIT publication of the first-party core, selected auto-tools, packager and documentation. The public core format and retained third-party licenses keep rights_verified=false and member_execution_verified=false, without a public_license_granted field. Old private-local-only packages and their metadata are unchanged. Publication and source verification are not runtime or all-member acceptance.

The core is installed separately, not bundled here. The Marked acceptance bundle is also a separate local artifact. User or instance data, credentials, private evidence and logs, unrelated company business code, company monorepos or their private history, complete third-party upstream repositories and model weights are not shipped here. Neither the capability map nor one successful task proves all members are installed, work unattended or generally outperform the strongest individual harness. This is independent community code, not an official DeepSeek product.