Stop the running DSH instance, run these commands in order, then start DSH again:

dsh plugin --profile web remove @specdev/dsh-archify-manage
dsh plugin --profile web add https://github.com/pioneer666-user/dsh-archify-manage/releases/download/v0.1.11/specdev-dsh-archify-manage-0.1.11.tgz

Removing and reinstalling ensures the old plugin files are replaced. Your diagrams and Git snapshots stay in your project repository.

In a DSH conversation for the target project, describe the business you want to work on. For example:

Use archify-maker to create the business specification, workflow diagram, and node explanations for this project's event registration flow, and register them under docs/archify. Confirm the business rules with me first. Mark unimplemented behavior as design, and leave source evidence empty until verified.

The skill separates design, implementation facts, and unverified information. You still review and accept the resulting diagrams. See archify-maker for the guide.

To explore a fictional sample instead, clone this repository and run the following from its root. Node.js and Git are required, and the destination must not already exist:

node sample/generate.mjs ./local-artifacts/demo-project

Open the generated local-artifacts/demo-project as a DSH workspace. It includes both valid and invalid examples; see the sample project.

All reading data lives in your business repository:

docs/archify/
  project.json                           # project name and introduction
  <business-id>/business.json             # business introduction and document links
  <business-id>/<chart-id>/chart.json     # diagram name and summary
  <business-id>/<chart-id>/workflow.json  # Archify workflow source
  <business-id>/<chart-id>/details.md     # explanations grouped by node
  <business-id>/<chart-id>/evidence.json  # source references pinned to commits

Business IDs and diagram IDs match their directory names. Diagram IDs must be unique across the entire project. You can read diagrams without node explanations or source evidence; missing or invalid material is reported explicitly.

See the file contract for fields and examples.

In details.md, use a level-two heading for the node ID and explicitly name the evidence reference in the body:

## check_eligibility
### Check registration eligibility
[Implemented] Unverified accounts and duplicate registrations are rejected.（证据 eligibility-core）

Keep the literal 证据 marker shown above; it is the reference syntax the reader recognizes. eligibility-core must exactly match a refs[].id in the same version's evidence.json. Each source reference records a repository-relative file path, a full 40-character commit hash, and a line range. The reader fetches code from that pinned commit.

• Level-three headings define groups; without them, paragraphs define the groups. The explanation controls the order.
• A group can name multiple evidence IDs, separated by 、. Examples inside code fences are not used for pairing.
• Paragraphs without explicit references are not assigned guessed code. Missing, duplicate, or invalid references show an explanation.
• The detail reader is not a full Markdown renderer; it supports common headings, paragraphs, lists, emphasis, and code display.

The dialog displays declared relationships. Having a source reference does not by itself prove that a business rule is correct.

Saving creates an annotated Git tag named archify/<chart-id>/<version-id>. Versioned reading covers workflow.json, details.md, and evidence.json. Source excerpts always come from the commit pinned by each evidence reference.

Before saving, the plugin checks that these three diagram files match the current commit. Uncommitted diagram changes, stale page content, or a changed commit block the save with an explanation. Saving the same content at the same stage returns the existing version.

Diagram names and summaries, business introductions, document links, and business-document content still come from the current working tree. To inspect historical business documents, use Git at the snapshot's actual commit.

Invalid snapshot tags are counted and ignored. Deleting or renaming versions, cross-repository evidence, and pushing to a remote are not currently supported.

Log in through the address DSH prints at startup, then use its sidebar entry. Pages and APIs share DSH's login session and origin checks. Requests are rejected when authentication is unavailable.

Workspace mode requires a Git repository root. Subdirectories, invalid workspace IDs, and an unavailable workspace service produce explicit errors.

If the host has no workspace registry, or you need to pin the plugin to one repository, override the entry by ID in the web profile's cordis.patch.yml:

- id: specdev-archify-manage
  config:
    repoRoot: 'D:/your/business-project-repo'

Do not use - insert:, which creates a duplicate entry. Restart DSH and open /archify-manage/ on the same DSH address without a workspace parameter. When the workspace list is unavailable or empty, the sidebar also offers a direct link. Configuration precedence is bundle → profile → home → --patch overlay, with later layers overriding earlier ones.

If you install a manually downloaded .tgz, its local path must not contain spaces due to a DSH limitation. The Release URL command above avoids handling a local package path.

Requires Node.js ≥ 22. Run from the plugin repository root:

npm install
npm run typecheck
npm run build
npm pack --pack-destination .

This produces specdev-dsh-archify-manage-0.1.11.tgz. The renderer and validation tools are included in the source tree; a separate Archify checkout is not needed.

For behavioral checks, run node scripts/smoke.mjs and node scripts/check-save.mjs sequentially as needed. They create temporary sample repositories and do not operate on your business project.

All paths below are prefixed with /archify-manage. Workspace links automatically carry ?workspace=<id>. Both pages and APIs require an authenticated DSH session.