dongsheng123132/dsh-lineage
Content-addressed artifact, fact, action and report lineage for DeepSeek Harness
Content-addressed data and action lineage evidence for DSH: builds a local, verifiable object graph (artifact / fact / action / report nodes; derived-from / observed-by / produced-by / supersedes edges). Every node reference is dereferenced inside workspaceRoot and hashed; the verifier distinguishes verified / missing / stale and rejects dangling references, invalid relations, and cycles. Append-only JSONL ledger with idempotency keys, atomic hard-link publication, and read-back SHA-256 verification. Tools: dsh_lineage_* for DAG validation, upstream/downstream closure, and missing/stale disclosure. Writes only inside explicit ledgerDir/artifactDir; traversal and symlink components rejected; keys for claims/chat/prompts/credentials rejected.
Install
dsh plugin --profile lineage add github:dongsheng123132/dsh-lineageGitHub install per README: dsh plugin --profile lineage add github:dongsheng123132/dsh-lineage. No npm package published. Node.js 22+. v0.2.0 is a formal Codex plugin and standalone proof-only MCP server using the namespace export shape required by the stock DSH Web Loader (with a real Cordis boot regression test). MIT.
Compatibility
DeepSeek Harness (stock DSH Web Loader contract). Node.js 22+. Never stores chat transcripts or factual prose — nodes are typed IDs + workspace-relative references + expected SHA-256.
Details
- Repo: dongsheng123132/dsh-lineage
- Category: Other
- Stars: 4
- Version: GitHub source v0.2.0 (no npm package)
- Last push: 2026-09-07
- First seen: 2026-08-13
Recent updates
v0.2.0: typed content-addressed graph; append-only ledger; verified/missing/stale verifier; MCP proof server; DSH Web Loader contract test.
FAQ
- What does it store?
- Only structural data: node types (artifact/fact/action/report), causal edges, workspace-relative object references, and expected SHA-256 hashes. No transcripts, prompts, or prose.
- How is the ledger append-only?
- Each event with an idempotencyKey maps to one immutable event file: validate → write temp → read back → atomic hard-link → read back and verify. Reusing a key with different content fails closed.
- How is stale data handled?
- Objects that exist but changed hash are marked stale, missing references are marked missing, and nothing missing or stale is silently promoted into a fact.
Alternatives
030611/dsh-verification-receipt · omdsh-dev/dsh-security-audit · jkrandom-sudo/dsh-plugin-audit