What it is

dsh-security-assurance is an evidence-backed repository security assessment plugin for DeepSeek Harness. It integrates through public Harness and Cordis seams without modifying Harness Core, and exposes versioned, queryable, recoverable assessment results.

This is an assurance plugin, not a general vulnerability scanner. Built-in capabilities include the Node package.json install-lifecycle check, npm publish surface, pnpm lockfile integrity, GitHub Actions permission and immutable-dependency checks, and pure normalization plus independent validation of frozen npm-audit.json and Gitleaks v8 JSON reports.

A scan finding is not automatically an auditable security conclusion: input may be tampered with, truncated, or detached from the frozen repository. Security Assurance accepts only verified slices from a frozen Subject, then emits a verdict after independent validation and sealed submission.

Assessment at a glance

The Service resolves an authorized Catalog selection and freezes the complete Subject before exposing verified slices to qualified PURE Analyzers or report normalizers. Candidates and Coverage are independently re-derived before the Kernel can compute SATISFIED, FAILED, or INDETERMINATE and emit a digest-bound Submission for a sealed Assessment.

Current release

• Version: 0.1.0-rc.17
• Status: release candidate
• Target Harness: 0.1.2-alpha.1 (primary); 0.1.2-alpha.2 through 0.1.2-rc.1, 0.1.3-alpha.1, 0.1.3-alpha.2, 0.1.5-alpha.1, 0.1.5-alpha.2, 0.1.5-rc.1, 0.1.5-rc.2, 0.1.5-rc.3, 0.1.7-alpha.2, 0.1.7-rc.1, 0.1.7-rc.2, and 0.2.0-rc.1 verified by the compatibility matrix
• Release: v0.1.0-rc.17

Support matrix

The Service resolves authorized repositories and catalog choices first. Models must use the exact returned identifiers; paths and IDs are never guessed.

Current v0.1 Analyzer qualifications prove only the security/standard path. A Repository bound to security/deep or a Host-defined Profile is reported as unsupported by Catalog and Start Preflight; even a direct Service caller that omits preflight can produce only an INDETERMINATE result, never stronger-Profile Coverage from Standard PURE Evidence.

The Security Catalog also exposes bounded capability summaries for the fixed five-role catalog. Each entry is identified by a package-owned version and deterministic digest, and Start Preflight includes that same exact catalog in its proposal digest. Every role is PROPOSAL_ONLY and cannot approve, accept risk, or decide a Verdict. Catalog-entry lineage is not an executable Role Definition: execution remains UNSUPPORTED until complete definitions and a qualified Subagent Provider composition exist, and Deep Preflight reports NO_ELIGIBLE_ROLE_COMPOSITION separately.

The public root also provides an authority-free RoleContextGrantV1 contract kit. A Grant binds only protected Subject Inventory, Source Slice and Evidence artifact references, explicit disclosure categories, peer-output visibility, and byte and token ceilings; it carries no source body, workspace root, parent conversation, credentials, Store, Cordis Context, or execution capability. Creation is deterministic and deeply frozen, while receiver-side parsing recomputes the digest and fails closed on tampering, budget overruns, undisclosed categories, or duplicate references. This contract neither starts a Subagent nor claims that a Provider is qualified.

The same public seam provides deterministic SourceSliceRequestV1 creation, parsing, and static preflight. A request binds the exact Context Grant, Subject, Role Attempt, purpose, Coverage obligation, canonical Subject-relative target, expected raw-byte digest, egress selection, and requested budget; parsing rejects tampering. Preflight reports stale bindings, scope or egress expansion, and budget overruns together, but its only successful state is MATERIAL_REVIEW_REQUIRED: the Service must still re-prove Subject containment, source-digest integrity, sensitivity, secret redaction, Data Egress, actual budget, and Role need before it may issue a new immutable Grant. The tool reads no source, calls no Provider, and issues no capability.

A package-private protected reader can now accept that exact Grant and Request, repeat static admission, and read one in-target file from the content-addressed Subject Snapshot. It reverifies the complete Subject, frozen Target containment, the Request/Manifest/observed raw-byte digest chain, and the actual byte budget; its deeply frozen result is not exported from the package root. This local material has not passed sensitivity, secret-redaction, Data Egress, or Role-need review, so it cannot be sent to a Provider or used to issue another Context Grant.

A package-private secret inspection layer can run a versioned set of high-confidence patterns over that local material while retaining only the type, UTF-16 location, and an HMAC-SHA-256 fingerprint made with a Host-supplied key. Raw matches and the fingerprint key never enter the returned record; weak keys, text-digest drift, and non-canonical paths fail closed. The detector is intentionally bounded: even an empty result remains ADDITIONAL_REVIEW_REQUIRED, never a claim that the text is secret-free or an authorization for egress.

The same package-private layer can replace every detected value with a fixed typed placeholder and separately digest-bind the redacted UTF-8 text and the complete redaction record. A receiver rechecks the source bindings, detected locations, replacement coverage, and both digests against the protected material; raw matches are not retained. REDACTED_MATCHES_REVIEW_REQUIRED means only that known high-confidence matches were replaced, not that secret clearance is complete or Data Egress is authorized.

A versioned package-private sensitivity method then classifies the exact material and redaction conservatively: every source is at least PROTECTED_SOURCE, sensitive paths such as .env, credential files, and private-key containers become RESTRICTED_SOURCE, and high-confidence secret matches become SECRET_BEARING_SOURCE. Receivers recompute the classification and digest and reject even a digest-valid downgrade. The method classifies only; it neither permits disclosure nor pretends to be the not-yet-implemented Policy Compiler or a compiled Security Policy.

A package-private Data Egress review then repeats Grant/Request static admission, verifies the complete material-to-redaction digest chain, and meters the actual redacted UTF-8 bytes. It also binds a qualified secret-review summary for the same exact Slice into its own digest chain: complete CLEAR Evidence removes the secret-review gap, SECRET_FOUND rejects egress, and missing or indeterminate review remains fail closed. egress/deny-by-default always yields REJECTED; every other policy remains BROKER_REVIEW_REQUIRED while Broker qualification or destination authorization is missing. Only a Host-attested Broker Qualification and Host Destination Authorization that remain valid at the explicit evaluation instant and exactly bind the Provider, non-secret credential reference, policy, destination, category, Slice digests, single-request quota, timeout, and audit policy remove those two gaps and advance to BROKER_INVOCATION_REQUIRED. This step still has no approved state, resolves no credential, accesses no network, and calls no Provider.

On that foundation, a package-private issuer can re-admit the same Broker and destination Evidence at issuance time and create one non-serializable, one-use Source Slice Egress Capability. It binds the fixed redacted text and non-secret credential reference to the exact Role Attempt, generation, fence digest, Data Egress policy, request/token quotas, and effective deadline, and can invoke only an injected Broker Adapter with the exact qualified identity. Attempt settlement, caller cancellation, or timeout aborts the in-flight adapter; a Broker response with drifted Provider/destination, schema, or usage fails closed. Both success and failure produce a digest-bound audit receipt containing no request or response text. The capability remains package-private: no production Broker Adapter is registered, no receipt is yet persisted, and no Material Review, Context Grant, or Verdict is approved by this operation.

A completed Broker receipt can now be combined with a Kernel-owned budget reservation and frozen invocation lineage in a package-private pure settlement module to form a protected Model Invocation Record containing no Prompt, source, or response body. Before settlement, the reservation fixes the Context Grant, Role Attempt generation and fence, egress authorization, Broker request, single-request/token ceilings, and deadline. Settlement revalidates the complete receipt and binds Provider/backend/deployment/model plus Moving Provider status, Role and Prompt versions, Prompt and Tool Schema digests, parameters and randomness strategy, start/finish times, actual request and token usage, the raw response-byte digest, finish reason, Broker diagnostics, and the parent Attempt. Actual input/output tokens are charged and only the unused reservation is released; potentially over-budget parameters, completion at the deadline, and digest or request substitution fail closed. A package-private publication layer can also revalidate the complete Context Grant, derive its trusted assessment and Subject, verify the exact Attempt bindings, and atomically publish the record as a canonical content-addressed Evidence object. Its digest-bound receipt jointly fixes the invocation, parent Attempt generation and fence, record digest, and Evidence digest; identical publication is idempotent, and readback rechecks the entire binding. Neither the receipt nor the package root exposes a path or body. Package-private persistence can atomically create an immutable RUNNING Role Attempt before an isolated session starts. Published Model Invocation Evidence may be linked only while that exact Role Attempt remains RUNNING, its Grant and fence agree, and the protected invocation record's Role, Provider/model, Prompt, and Tool Schema lineage matches the Attempt. A successful return can then complete only by citing one durably admitted Role Contribution for the same generation and fence; disposition, request/token usage, Evidence count, and Candidate count are derived from that immutable Contribution instead of accepted from the completion caller. Admission closes over every and only the Attempt's linked Model Invocation Evidence and rechecks the exact record and response digests, Role, Provider/model, Prompt, Context Grant, Subject, and budget. The full protected Contribution remains in its own relational row while the Assessment carries only a compact digest-bound projection. Exact admission and completion replay is idempotent, while missing or extra invocations, conflicting contributions, stale revisions/fences, non-running state, cancellation, Subject drift, or budget drift rolls back and fails closed. On first open, a released schema-v1 Store advances through separately backed-up, fully verified, exclusively leased, digest-journaled v2, v3, and v4 migrations. A v2 Store with existing logical Evidence links but no provable Attempt rows is rejected, as are unknown versions. Required Role Attempts can also settle explicitly as FAILED: the failure code, usage, and retained counts are committed atomically with the Role Card, Revision Journal, and BLOCKED Assessment state. The public recovery projection identifies the exact ROLE_EXECUTION Attempt and requires authorized Resume. An Assessment cancellation request first prevents late-result admission; only after the caller proves cleanup and quiescence does the terminal commit change every remaining RUNNING Role Attempt and Role Card to CANCELED in the same revision. Recovery neither reuses nor erases the old Attempt: a new Attempt for the same Role needs a new identity and must cite a FAILED/CANCELED parent in the same Assessment; absent, non-terminal, or definition-drifted parent lineage fails closed. Automatic execution-graph scheduling, production session spawning, per-Role cleanup proof, and Broker registration remain absent. This slice also does not create the ADR 0197 Evidence Link or admit a canonical Assessment Bundle. Failed or unverifiable-usage Broker receipts are not fabricated into complete Model Invocation Records, and Material Review's ACTUAL_BUDGET does not yet become satisfied automatically.

A terminal model proposal can now enter a package-private pure RoleContributionV1 contract. Its canonical digest binds the Assessment, Subject, Context Grant, exact Attempt generation and fence, Role Definition, every Model Invocation record and response digest, structured hypotheses, Candidate Findings, Coverage observations, Evidence context and requests, challenges, Follow-up Requests, limitations, uncertainty, completion disposition, and exact aggregate usage. Strict parsing rejects unknown authority-bearing fields, duplicate or dangling references, non-canonical or unsafe Source Anchors, usage drift, oversized records, and digest tampering. The pure contract grants no authority; the durable admission described above only freezes lineage and completion accounting. Neither layer creates a Finding or Coverage Resolution, calls a Provider, or grants a Verdict, Risk Acceptance, or public capability.

Candidates from an admitted Role Contribution can now pass through a separate package-private pure admission boundary. It revalidates the exact Context Grant, Contribution, and durable Admission Link across their Assessment, Subject, Role, Attempt generation and fence, invocation, usage, count, revision, and digest lineage. Every Source Anchor must match a caller-supplied frozen-Subject slice whose raw bytes are reverified and its byte span must remain in bounds; every Candidate Evidence ID must be present in the caller-confirmed durable object set. The Candidate batch is all-or-nothing, and each success receives independent deeply frozen Candidate and admission digests; failures expose only fixed-code protected diagnostics. Schema v6 further commits one caller-identified admission attempt as a single Assessment transaction: success writes the digest-bound batch and per-Candidate rows, while failure writes only the fixed code, a safely parsed Candidate ID when available, and a request digest, never source or failure text. Exact success and rejection replay remains revision-neutral after Store reopen; conflicting attempts, stale revisions, cancellation, and non-running Attempts fail closed, while a new attempt can retry an earlier rejection after missing durable input becomes available. Admission itself still creates no Finding, Coverage Resolution, cluster, Evidence merge, or ADR 0197 Evidence Link.

After durable admission, a new package-private pure validation boundary first freezes the one exact versioned Validation Contract Resolution from the Candidate weakness and affected control, exact Assessment Policy digest and Mode, ecosystem, execution boundary, and qualification validity across the complete supplied catalog. No applicable Contract or multiple equally applicable Contracts remain explicitly unresolved, and observed proof cannot influence selection. The three-state Validation Outcome is then derived only from exact caller-confirmed durable Evidence identities, purpose-specific Evidence Eligibility Decisions, Contract conditions, required negative controls, and independence decisions bound to the complete provenance graph: only proof of the claim can produce VALIDATED; only eligible Counter-Evidence satisfying an explicit rejection condition can produce REJECTED; missing proof, shared provenance, missing controls, or any qualifying claim proof facing qualifying Counter-Evidence stays UNRESOLVED, however many lineages either side has. Schema v7 first appends the validation attempt's Contract Resolution in its own Assessment revision; only a later transaction can append the Outcome in the next revision, preventing post-result Contract selection. Exact replay of either stage is revision-neutral, current reads choose the latest Outcome for the exact Contribution and Candidate identity, and reopen re-derives and verifies the complete Candidate Admission, Contract, Outcome, and Revision Journal lineage. This boundary still calls no Provider, creates no Finding or Coverage Resolution, merges no Evidence, emits no ADR 0197 Evidence Link, and widens no public API.

If the original Role output fails strict JSON and schema validation, a package-private format-repair boundary now accepts only one separately predeclared, digest-bound invocation. Its plan fixes the Context Grant, Role Definition, Attempt generation and fence, original and repair invocation identities, Provider/model, deterministic parameters, one-request/token budget, and package-owned authority-free semantic payload schema and syntax instruction. Schema v5 commits that plan in the same transaction that starts the Role Attempt, so a running or recovered Attempt cannot gain or replace repair authority. The protected request body sent to the repair Provider may contain only the original response, target schema, and syntax instruction, and its exact digest must match the repair Model Invocation Record. Repair Evidence can be linked only after the exact original invocation Evidence; the text-free repair result is admitted at most once only after both links are durable, and any later Contribution must match its exact digest. A repaired result may be composed only when it passes the strict payload schema and its ordered JSON scalar sequence exactly matches the original; the Service supplies Contribution identity, both invocation lineage entries, and exact usage rather than accepting those fields from the model. Exact replay survives Store reopen, while already-valid output, Markdown fences or heuristic extraction, scalar addition/removal/change/reordering, a second repair identity, authority fields, and raw-byte, Prompt, Provider, time, budget, or replay drift all fail closed. No protected response body is stored in the plan or repair-result rows. This package-private boundary does not yet call a Provider, retry automatically, or change a public contract.

Schema v5 extends the separately backed-up, exclusively leased, digest-journaled migration chain with the durable Format Repair plan and result tables. Existing Role Attempts migrate as having no repair plan, so migration cannot infer or add repair authority.

Schema v6 extends the same fail-closed migration chain with Candidate Admission batches, individually readable Candidate records, and protected rejection diagnostics. Every migration step retains its own verified pre-migration backup and digest-bound history; existing Contributions migrate with no inferred Candidate admission or rejection.

Schema v7 extends that chain with append-only Role Candidate Validation Contract Resolution and three-state Outcome records. The v6-to-v7 step owns its own verified backup and digest-bound migration history; existing Candidate Admissions migrate with no inferred Contract, Evidence eligibility, independence, or Outcome.

A package-private vertical material-review operation re-reads the exact Request from the content-addressed Subject, performs the inspection, redaction, sensitivity classification, and egress review itself, and returns only an immutable, text-free record. In fixed order, the record covers all seven material checks and binds the complete digest chain for the Grant, Request, Subject, raw source, inspection, redacted text, redaction record, sensitivity classification, secret review, Broker/Destination authorization, and egress review. Containment, raw-source integrity, and conservative sensitivity classification can be marked SATISFIED locally. SECRET_REDACTION may additionally advance through a Kernel-eligible Analyzer Portfolio and Contribution dedicated to this scope, but only complete CLEAR Evidence that exactly binds the redacted Slice, remains within qualification validity, and references Host-attested independence Evidence can satisfy it and remove the corresponding egress gap. A residual secret rejects both the secret and egress checks; missing, indeterminate, expired, scope-mismatched, or digest-drifted Evidence fails closed. The existing Gitleaks qualification covers frozen-report normalization only and cannot impersonate this clearance. Even complete Broker and destination Evidence only requires a later Broker invocation; measured tokens and Role need remain REVIEW_REQUIRED, so the operation still has no aggregate approved state, issues no Grant, and calls no Provider.

TARGETED still freezes and digest-binds the complete Subject, then exposes only verified relevant slices inside the explicit Target: package.json for the Node lifecycle policy and .github/workflows/*.yml|yaml for the GitHub Actions policy. Every Target path must name an existing entry or directory prefix. A nonexistent path is rejected before Assessment creation. The npm publish surface, npm audit, Gitleaks, and pnpm lockfile policies do not yet claim TARGETED support because their root or external inputs cannot independently prove an exact Target scan scope.

The Harness support window is an explicit, verified set: a daily Harness Compatibility workflow discovers official repository tags, then runs the dual-plugin joint E2E (Mission → Developer workspace change → CHANGE Assessment → sealed submission → Quality Gate) and a packed fresh-profile installation with a live Web probe — on Ubuntu, macOS, and Windows for the primary target, and on Ubuntu for the remaining versions. New tags enter verification automatically but are not claimed as supported until the matrix passes (ADR 0310).

Exact-commit CHANGE mode freezes the resolved base and head identities, raw diff digest, and complete head tree. The bundled policies evaluate their complete relevant input sets in that tree, which is a conservative superset of the Policy impact cone.

The standalone tool and Workbench catalog remains backward compatible and exposes only exact-commit change to models. After a Control Plane Developer run publishes Implementation Evidence, its Provider receives a Host-only workspace_change from the unforgeable execution context. Security Assurance independently matches branch, baseline HEAD, Git-status fingerprint, byte-exact produced-change fingerprint, and the complete resulting tree before creating an Assessment; any drift fails closed.

Three-minute install in Harness Web

Compatible with DeepSeek Harness 0.1.2-alpha.1 through 0.1.2-rc.1, 0.1.3-alpha.1, 0.1.3-alpha.2, 0.1.5-alpha.1, 0.1.5-alpha.2, 0.1.5-rc.1, 0.1.5-rc.2, 0.1.5-rc.3, 0.1.7-alpha.2, 0.1.7-rc.1, 0.1.7-rc.2, and 0.2.0-rc.1 (an explicit, verified set; see the support matrix above). Requires Node.js ^22.19.0 || >=24.0.0 and the Harness CLI. Install the prebuilt GitHub Release package directly:

1. Download the tarball from the matching Release.
2. Install it from the repository you want to assess and inspect the composed profile.
3. Start Harness Web and run an explicit /security assessment.

dsh plugin --profile web add https://github.com/bailong-Hakuryu/dsh-security-assurance/releases/download/v0.1.0-rc.17/dsh-security-assurance-0.1.0-rc.17.tgz
dsh --profile web --dump-config
dsh web

Alternatively, download dsh-security-assurance-0.1.0-rc.17.tgz from the Release page and pass its absolute local path to the same command.

When both plugins are installed, install Engineering Control Plane first because it supplies the shared invariant registry. The launcher working directory is registered as current-workspace.

Invocation

Natural-language requests are routed through the catalog-first workflow. Users can also run:

/security Assess the current repository and report the final verdict and findings.
/security Assess only packages/api and packages/web for package installation lifecycle risks.

The eight tools are security_repositories, security_catalog, security_assessment_start, security_assessment_status, security_assessment_findings, security_assessment_resume, security_assessment_cancel, and security_assessment_export. The normal order is repositories, catalog, start, status, and findings. Mutations require the exact Service revision and a fresh idempotency key.

In Harness Web, calls to these eight tools render as purpose-built Security cards instead of generic tool rows: one line of title and summary with state, verdict, and severity chips, expandable into details and the raw input and output. The cards read only the tool-call records already in the conversation; they call no Service and hold no authority (ADR 0322). A card that concerns an Assessment offers 「在工作台中打开」 (Open in Workbench) at the end of its row, which opens that Assessment in the Workbench in one step (ADR 0323).

Security Assurance Workbench: select 「安全保障」 (Security Assurance) at the foot of the Harness Web sidebar to browse visible Assessments, follow their progress, and inspect Findings, Evidence metadata, and Bundles, or to start a new Assessment on a registered Repository after a Catalog preflight. The Workbench has exactly the reach of the model tools: read, start, resume, and cancel Assessments, and request and read exports. Risk Decisions, break-glass, sensitive Evidence disclosure, and export download remain grants only a deployment's authenticated resolver can make (ADR 0321).

npm audit report adapter

The Host, CI job, or operator runs npm audit outside the Assessment. The plugin never starts npm, contacts the Registry, or reads live network state from its PURE Analyzer boundary. Generate a UTF-8 report and make sure it is part of the selected Subject before the Assessment starts:

npm audit --json | Set-Content -Encoding utf8 npm-audit.json

Bind the Repository to security/npm-dependency-audit. The adapter reads the exact frozen report bytes and digest. A complete clean report yields SATISFIED; independently validated vulnerabilities yield blocking Findings and FAILED; a missing or unsupported report, incomplete Coverage, or tampered Evidence yields INDETERMINATE. Report freshness remains the responsibility of the Host or CI job that produced it.

Gitleaks report adapter

The Host, CI job, or operator also runs Gitleaks outside the Assessment. Enable full redaction and freeze the UTF-8 JSON report into the selected Subject:

gitleaks dir . --redact=100 --report-format=json --report-path=gitleaks-report.json

Bind the Repository to security/secret-leak-audit. The PURE adapter retains only the rule ID, affected relative path, and location. It never projects Secret, Match, source lines, secret hashes, author email, or commit messages into Candidates, Findings, Evidence, Seals, or exports. A complete empty report yields SATISFIED; any independently re-derived report entry yields a HIGH blocking Finding and FAILED; missing, malformed, tampered, or incomplete input yields INDETERMINATE. The Host or CI owns scan configuration, report freshness, Git history breadth, and allowlist correctness.

GitHub Actions supply-chain policy

Bind the Repository to security/github-actions-supply-chain to evaluate only .github/workflows/.yml and .yaml files selected from the frozen Subject and current Target. The PURE Analyzer does not execute workflows or contact GitHub. It requires an explicit read-only or empty top-level permissions boundary, rejects job-level write permissions, requires a full 40-hex commit SHA for external Actions and reusable workflows, and requires a sha256 image digest for container Actions. Local ./ Actions are accepted.

The complete parse is repeated by an independent Validation Contract. A safe or empty selected workflow set yields SATISFIED; verified violations yield blocking Findings and FAILED; duplicate keys, aliases, malformed or unsupported YAML, and tampered Contributions yield INDETERMINATE. This strict Policy does not decide whether write authority is operationally justified. A release workflow that needs write permission requires another reviewed Policy rather than a silent exception in this one.

npm publish surface policy

Bind the Repository to security/npm-publish-surface to verify the frozen root package.json publish declaration entirely offline: public package identity, public access, an explicit files allowlist, and exports, main, types, and bin targets contained by that allowlist. It never runs npm pack, enumerates the filesystem, contacts the Registry, or claims that files exist, provenance is trusted, or dependencies are safe.

A consistent manifest yields SATISFIED. Private packages, restricted access, missing or broad allowlists, and uncontained entry points yield independently re-derived blocking Findings and FAILED; malformed, duplicate-key, invalid-target, or tampered input yields INDETERMINATE. Version 1 supports only REPOSITORY and CHANGE and proves manifest consistency rather than the contents of a real packed artifact.

pnpm lockfile integrity policy

Bind the Repository to security/pnpm-lockfile-integrity to compare the root package.json and pnpm-lock.yaml from the frozen Subject entirely offline. The PURE Analyzer requires packageManager to pin one exact pnpm semantic version, requires the pnpm v9 root importer to match all three dependency sections exactly, and requires valid SRI on every external package resolution. It never runs pnpm, installs dependencies, contacts the Registry, or claims that dependencies are vulnerability-free.

Consistent input yields SATISFIED. A missing lockfile, importer drift, unpinned package manager, or missing SRI yields independently re-derived blocking Findings and FAILED. Duplicate JSON keys, YAML aliases, malformed input, an unknown lockfile version, a non-pnpm manager, or a tampered Contribution yields INDETERMINATE. Version 1 covers only the root importer and supports REPOSITORY and CHANGE; it does not misrepresent workspace child packages as covered.

Results and safety

All public operations return a typed SecurityResult<T> envelope. Commands return immutable versioned Receipts; queries return identity- and revision-bound Snapshots. Host authority resolves identity and permissions; model arguments never carry credentials, paths, database handles, or executable objects. Missing authorization, conflicts, timeouts, cancellation, and external failures fail closed.

Run workspace_snapshot only for repositories the user explicitly authorizes. Ancestor links are rejected, Subject symlinks are inventoried without dereference, and Git runs through the Harness-managed subprocess boundary. See SECURITY-REVIEW.md.

Control Plane integration

Engineering Control Plane owns the Mission, engineering Evidence, and final Quality Gate. Security Assurance owns the external security obligation and its evidence. An unavailable, failed, or indeterminate security result blocks the Gate; it is never converted into approval. The two plugins do not share SQLite files, writable Evidence paths, transactions, or Kernel objects.

Development

pnpm install
pnpm lint
pnpm build
pnpm typecheck
pnpm test
pnpm pack:dry-run
pnpm pack:profile-smoke
pnpm pack:browser-e2e
pnpm release:check

Stable candidates must first derive deterministic bindings from the real tarball, clean source revision, and lock files, then verify the complete release-evidence request against those bindings:

pnpm release:bind -- --input .\release-files.json --output .\release-file-bindings.json
pnpm release:collect -- --input .\release-proof-input.json --output .\release-proof-index.json
pnpm release:assemble -- --input .\release-qualification-draft.json --output .\release-qualification-input.json
pnpm release:qualify -- --input .\release-qualification-input.json --output .\release-qualification
pnpm release:handoff -- --input .\release-handoff-input.json --output .\release-promotion-handoff.json

The first command records verified file facts but manufactures no test or security proof. Packed smoke commands can emit strict records for that same tarball through DSH_RELEASE_PROOF_OUTPUT; the second command validates and raw-byte hashes those records into a deterministically ordered proof index. The third re-verifies the index, binding, and referenced record bytes, then copies their unchanged statuses into the strict qualification input. The fourth rereads the bound files and exits 0 only when the Release Constitution says PROMOTE and the assembled Manifest is VERIFIED, atomically emitting the Manifest, public Scorecard, and qualification verdict. The fifth binds those three files and the retained RC tarball, compares every entry in the proposed stable tarball, permits only the same-base stable version transition plus README/CHANGELOG release metadata, and emits a receipt whose authorization is explicitly NOT_GRANTED. The release-grade real-browser E2E drives the candidate's own local Workbench through real controls in a freshly installed Harness (ADR 0324). It records WORKBENCH only when the tarball itself enables the local authority and otherwise honestly reports INCONCLUSIVE; a generic Web shell is never relabelled as Workbench proof. Valid blocked or incomplete evidence exits 2 with auditable output; byte, Git HEAD, tracked-source, portfolio, or package-behavior mismatches exit 1 without output. None of the CLIs or proof emitters tag, sign, upload, or publish a package. See the v0.1 release checklist for the input contracts.

The manually triggered Release Candidate Evidence workflow requires an exact 40-character Control Plane commit SHA, packs and binds one candidate, and reuses those tarballs for Linux, macOS, and Windows proof runs. Its final job installs the public collector from the candidate and uploads a deterministic release-evidence-index; it does not qualify, tag, release, or publish.

The current development tree contains 89 test files and 480 tests; the release gate runs those tests together with linting, typecheck, build, packaging, and Harness profile smoke. Public CI rebuilds a fresh Profile from both tarballs and probes Web on Ubuntu, macOS, and Windows; the daily compatibility matrix additionally runs the dual-plugin joint E2E and the packed-installation probe across every declared Harness version.