rebuild-dossier

Why passing tests isn't enough

A deliberately trivial HTTP-200 stub passed all 20 visible and 12 held-out test files, but matched 0 of 77 checks in a separate behavioral fidelity battery. Passing those test files did not mean the implementation reproduced the application.

The archived suites accepted a handler that returned 200 with an empty JSON object; their tests did not enforce the application's authentication, validation, or response-body behavior. A separate author-written fidelity oracle compared the original application's status codes and top-level response keys: the stub failed all 77 full-match checks. This is a deliberately constructed control on one application, not a coding-agent rebuild or a claim about how often agents fail.

• Constant-200 baseline: reproduction steps, test logs, and results
• Fidelity oracle: frozen protocol, scoring rule, and limitations
• Research preprint (broader tool and earlier evaluation; the specific constant-200 control is documented in the linked baseline)

Rebuild Dossier addresses parts of this assurance gap by extracting interface contracts, surfacing ambiguities for explicit decisions, and generating mutation-tested checks before a coding agent rebuilds the application.

An MCP server that reverse-engineers a trustworthy rebuild spec — a locked CLAUDE.md, .claude/ config, and a mutation-tested test suite — out of an existing app, so any coding agent can rebuild it cleanly against that spec instead of guessing.

It does not rebuild the app. It produces the spec, contracts, and tests a coding agent consumes to do that separately. This boundary is deliberate — see Why below.

Validated against a real app. The core loop (ingest, resolve cases, generate spec) has been tested end-to-end against a real, messy repo with two independent fresh-agent handoffs on two model tiers, plus a mutation-tested test suite. docs/v0-findings.md covers what worked, what broke, and what's still open.

Quick start

Available on npm:

npx rebuild-dossier@latest --help    # pulls and verifies the package, or:
npm install -g rebuild-dossier        # install the CLI globally

Requires Node 20.12+ (set in package.json engines). To run from source instead, clone the repo, npm install, and use npm start.

Then add it as an MCP server. In Claude Code, from the project you want to rebuild:

claude mcp add rebuild-dossier -- npx -y rebuild-dossier@latest

(or add this to your ~/.claude.json / project .mcp.json):

{
  "mcpServers": {
    "rebuild-dossier": {
      "command": "npx",
      "args": ["-y", "rebuild-dossier@latest"]
    }
  }
}

Then in a session. The first call, ingest_repo, runs instantly with zero setup: static analysis only, no browser, no Chromium, no LLM call. Run it on any app to confirm the server is alive before committing to the full workflow:

ingest_repo({ path: "/path/to/some-app" })
get_case_queue({ repoPath: "/path/to/some-app", interactive: true })
# ...resolve whatever the queue surfaces...
generate_spec({ repoPath: "/path/to/some-app" })

This writes a clean some-app-rebuild/ sibling directory. cd into it, start a fresh Claude Code session (nothing else should be in scope), and paste the contents of its kickoff-prompt.txt.

If this looks useful, a star helps other developers find it.

Why

Prior research (AgentModernize, arXiv:2605.17535) found that a rebuild pipeline scores 0% behavioral equivalence with no verified feedback loop, and only 9–19% with a coarse one. The bet behind this tool: locking interface contracts before running tests, plus a strict one-test-at-a-time retry loop instead of batch regeneration, does meaningfully better.

The riskiest part of any such pipeline is silently validating a bug as intentional — four sources of evidence can quietly agree on the same mistake with nobody ever having said why. So the single non-negotiable rule in this tool: auto-resolving an ambiguity requires both signal agreement and an affirmative signal that someone actually decided (a stated comment, a TODO admitting a bug, or a direct human answer). Silent agreement alone — code and observed behavior simply matching, with no one ever having said why — always becomes a question, never an auto-resolution, no matter how high the apparent confidence.

How it works

Six MCP tools, run from inside a normal Claude Code (or any MCP-compatible) session:

| Tool | What it does | |---|---| | ingest_repo(path) | Static analysis only, no LLM call: routes, package.json, build config (via AST, never executed), existing tests, and structural-smell detectors (e.g. a client-side-only credential check with no server-side verification) that surface real ambiguity even when nobody ever commented on it. | | crawl_site(url) | Headless Playwright crawl of reachable routes, with progress notifications so long crawls don't get killed as unresponsive. | | flag_known_bug(description) | Free text, stored verbatim. Always overrides auto-resolve for anything it matches — the cheapest, most authoritative signal in the system. | | get_case_queue() / resolve_case(id, decision) | The ambiguity queue. Surfaces open questions via MCP elicitation when the client supports it; resolve_case is always available as a scripted fallback. | | generate_spec() | Only callable once the case queue is empty. Writes CLAUDE.md, .claude/rules/, .claude/settings.json (hooks that mechanically enforce the discipline — see below), spec/contracts/*.md, tests/visible/ + tests/held-out/, and kickoff-prompt.txt to a clean sibling <repo>-rebuild/ directory — never into the original repo. Runs a real mutation check before finalizing tests: deliberately breaks the original code and confirms each generated test actually catches it, downgrading any that don't. |

crawl_site needs Chromium (npx playwright install chromium, step 2 below) — it isn't bundled with the server, including when installed via Smithery, so run it once first or the tool will fail.

Rails that are mechanically enforced, not just written down

A comparison run across two model tiers found that a weaker model will happily read CLAUDE.md, understand "only build what's currently failing, don't batch-regenerate," and then quietly violate it anyway — because nothing checked it. Two rules in this tool are now enforced by real hooks, not prose, for exactly that reason:

• spec/ is locked. Writes under spec/ are blocked.
• Contracts without tests don't get built ahead of schedule. generate_spec writes spec/untested-contracts.json (every route/contract with no covering test), and writes to anything on that list are blocked.

Both rules live in one generated guard script, .claude/hooks/rebuild-guard.mjs, run as a PreToolUse hook on Edit, Write, MultiEdit, NotebookEdit, and Bash. It resolves symlinks, .. segments and (on macOS/Windows) letter case before matching, parses write-shaped shell commands (redirects, heredocs, tee, sed -i, rm/mv/cp, git write subcommands, interpreter one-liners that write), locks its own script and settings.json, and fails closed if its input, the blocklist, or the script itself is missing or unreadable. Known limit: shell parsing is heuristic, so a write routed through a script the agent wrote earlier is not seen. (Releases before 0.2.10 shipped an untested-contracts hook that crashed under the shell and never blocked anything; upgrade.)

A PostToolUse hook runs the visible test suite after every edit and records a heartbeat in .claude/.hook-heartbeat.json, so you can check afterward that the hooks were actually live.

Operating guide

The full lifecycle, in order — each step's actual behavior, not just the call signature.

1. Ingest the repo

ingest_repo({ path: "/absolute/path/to/some-app" })

Static analysis only — no LLM call, nothing executed. Parses package.json, route files (Express and Next.js App Router today — see scope), build config (Tailwind/Vite/Next, via AST, never executed), existing tests, and scans for comment/TODO signals plus structural smells (e.g. a hardcoded client-side credential check with no server-side verification — the kind of thing nobody ever comments on, which is exactly why it needs its own detector rather than relying on comments existing). Everything lands in <repo>/.dossier/ — this tool's own scratch state, inside the original repo, never shared or uploaded anywhere. You'll get back a summary:

{
  "routes": 8,
  "existingTests": 0,
  "signals": 3,
  "buildConfig": ["tailwind", "next"],
  "openCases": 3,
  "savedTo": "/absolute/path/to/some-app/.dossier/evidence.json"
}

openCases here already reflects reconciliation — comment/TODO signals and structural smells that didn't auto-resolve become case-queue entries automatically.

If routes comes back 0, check for a monorepoHint field before assuming the app has none — ingest_repo needs to be pointed at the actual app directory, not a monorepo's root wrapper (a package.json with apps/*/packages/* next to it, common with Turborepo/Nx/workspace layouts, including ones that never actually declare a workspaces field). The hint lists real candidate directories found under apps//packages/ so you don't have to hunt for the real app yourself — re-run ingest_repo pointed at one of those instead.

If your client supports MCP elicitation, you can skip the manual re-run entirely: pass interactive: true and, when a monorepo root with candidates is detected, ingest_repo asks which one is the real app and ingests it directly — it never silently guesses on its own, the same way get_case_queue's interactive mode always asks rather than resolving anything without you. Declining, an unsupported client, or an answer that isn't one of the real candidates all fall back to the plain hint above, unchanged.

2. (Optional) Crawl the live site

crawl_site({ url: "http://localhost:3000", repoPath: "/absolute/path/to/some-app" })

Only useful if the app is actually running somewhere. Headless Playwright crawl of reachable routes, emitting progress notifications periodically — long crawls get auto-backgrounded by most MCP clients, and a silent multi-minute call risks being killed as unresponsive without them.

This step is the only one that needs a browser. crawl_site drives headless Chromium, which isn't bundled with the server (including via Smithery), so run npx playwright install chromium once first or the tool will fail. Skip it and the rest of the workflow still works. ingest_repo, resolve_case, and generate_spec need no browser at all.

3. (Optional, but do this before step 4) Flag anything you already know is broken

flag_known_bug({
  repoPath: "/absolute/path/to/some-app",
  description: "The login gate secret check runs entirely client-side and is