dsh-code-reuse-firewall

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.