dsh-code-reuse-firewall

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