dsh-code-reuse-firewall
Pre-write reuse firewall for DeepSeek Harness — for PYTHON repositories.
Before the agent writes a new helper / service / manager, reuse_check
deterministically surfaces the existing Python implementations that already
cover that intent, so the agent reuses or extracts instead of duplicating.
Why
Static checkers only catch what looks wrong. The expensive failure mode in
AI-maintained codebases is the opposite: two implementations of the same
capability drift apart silently, because nothing looked broken when the second
copy was written. The fix is to intervene before the second copy exists —
surface the overlap while the new code is still a plan, not a file.
The retrieval is deterministic and LLM-free (callable-name, docstring
lexical, and string-literal channels with IDF-weighted query coverage, stdlib
Python only), backed by the
Auto_code_audit capability
channel. It was validated on an unfamiliar mid-size project (arrow-py): a 1s
scan surfaced nine near-identical locale _format_timeframe methods, four
describe twins, and api.get vs ArrowFactory.get near-duplicates with zero
noise in the dead-code / hardcoded / style categories.
Requirements
- A checkout of Auto_code_audit
(its
capability_retrieval.py is the retrieval engine).
- A Python 3.10+ interpreter (default
python).
Install
dsh plugin add github:keyiadiannao/dsh-code-reuse-firewall#master
Then configure the audit checkout and interpreter in your profile:
- id: dsh-code-reuse-firewall
config:
auditRoot: 'D:/path/to/Auto_code_audit' # required
pythonPath: 'python' # default
maxK: 5 # top-K candidates
minScore: 0.1 # score floor
timeoutMs: 30000 # child-process cap
Usage
The agent calls reuse_check before writing new code:
调用 reuse_check：我要实现「从 JSON 配置读取并支持环境变量覆盖」，根目录是
D:/project/src。看看有没有现成的实现可以复用。
(call reuse_check: I'm about to implement "load a JSON config with
environment-variable overrides", root D:/project/src. Is there an existing
implementation to reuse?)
The tool returns top candidates with paths, scores, and per-channel evidence:
Existing implementations overlapping "load a JSON config with env overrides":
[0.72] config.py:load_config (src/config.py) (name=0.72 doc=0.10 literal=0.00)
[0.51] util.py:ConfigLoader.load (src/util.py) (name=0.51 doc=0.00 literal=0.00)
Hash-locked candidates are flagged. When an existing implementation lives
in a file pinned by a frozen-JSON provenance manifest (e.g.
current_dependency_files / files_sha256 in frozen_results/ or configs/),
the tool marks it 🔒 LOCKED with the locking manifests. Editing such a file
invalidates the frozen results that reference it — the correct reuse is to
import it, never to copy-and-modify its implementation. Derived run-output
trees (outputs/, reports/, logs/, runs/, cache/) are treated as
snapshots, not edit constraints, so scripts that merely appear in run metadata
are not falsely flagged.
[0.32] lib/protocol.py:_split_hash_payload (lib/protocol.py) (name=0.32) 🔒 LOCKED by configs/generation_b_training_compatibility.json
⚠ 1 candidate(s) are in hash-locked files: REUSE by import, do not copy-and-modify their implementation (editing invalidates frozen results).
Advisory evidence, not a verdict. The agent decides whether to reuse,
extract a shared component, or write new code — and must never delete or
rewrite anything based on retrieval alone (the same ground rule as
Auto_code_audit: deterministic output is evidence, not a defect verdict).
Signal-strength caveat (honest limits)
A natural-language --describe query has NO code yet, so the retrieval engine's
strongest signals — normalized AST structure, call-name overlap, string-literal
overlap — cannot fire. The pre-write channel relies on the weaker
name/docstring-lexical/string-literal channels. In practice:
- A well-named existing function whose docstring matches your description WILL
be surfaced (verified:
load_config for "load a JSON config with env
overrides").
- Describe in English keywords a function name/docstring would use
(
load json config settings environment env override). Chinese-only
descriptions match poorly against English code — the engine tokenizes CJK
into bigrams with no Chinese↔English mapping.
- Structurally-similar-but-differently-named code (the strongest reuse signal)
is only found AFTER code exists, via the engine's
--file / --base modes —
which are not yet exposed through this plugin.
- Each candidate carries per-channel evidence (name / docstring / string-literal
scores) in the tool result, so the agent can judge WHY something matched
instead of trusting one blended score.
So treat reuse_check as a low-signal pre-write hint, not a full reuse
audit. The high-signal modes are roadmap items below.
Configuration
| Key | Default | Description |
|---|
auditRoot | — (required) | Auto_code_audit checkout containing capability_retrieval.py |
pythonPath | python | Python interpreter for the retrieval script |
maxK | 5 | Top-K candidates per query |
minScore | 0.3 | Score floor (aligned with the engine's default; measured hits sit at 0.33+, lower scores are mostly noise) |
timeoutMs | 30000 | Child-process timeout — retrieval never hangs a turn |
The plugin parses the retrieval JSON with a schema_version === 1 contract
check: if Auto_code_audit ever changes its output schema, reuse_check fails
loudly with "out of contract" instead of silently mis-parsing.
Development
pnpm run build # tsdown: host + client bundle
pnpm run typecheck # tsc --noEmit
pnpm test # vitest
Roadmap
tools/pre-execute guard: run a reuse check automatically before write-tool
calls when a reuse_check was not already performed (dsh-tool-git style).--file / --base modes (check a new/changed file or diff against a git ref)
exposed through the tool.
License
MIT
