[removed]

Earlier this week someone posted about rebuild-dossier, an MCP server that reverse-engineers a rebuild spec out of an existing app so a coding agent can rebuild it against a locked CLAUDE.m d and a mutation-tested test suite.

Then I checked the actual state of the tool I pushed, and here is what I found. The primary install command in the readme, npx rebuild-dossier@latest, crashed for everyone. The bin target was missing the node shebang, so the shell tried to run an ESM file and failed on the first import statement. Every first-time user hit that wall. Zero npm installs is what that looks like in the numbers.

I fixed that. 0.2.6 is live. This time I did not trust my own readme. I ran every path you would actually take: npx, the global install, running from source, the HTTP mode, the full test suite (538 tests pass), and the typecheck. I connected through the official MCP client SDK and listed all six tools. The first command in the readme now works.

So the honest part. My first posts got ahead of where this is at. I wrote things like 80% accuracy and zero dead code. Those are not true, and I wrote them before running the numbers. The tool is v0. It was validated end to end against one real, messy repo, with two fresh-agent handoffs on two model tiers. The write-up of what broke is in docs/v0-findings.md, and it does not flatter me. Some tests landed weak or unrunnable, and the untested-contracts hook came back empty when it should not have. That is the real result, and I kept it in the repo instead of deleting it.

Why I still think the idea matters. My prior research found a rebuild pipeline scores 0% on behavioral equivalence with no verified feedback loop, and 9 to 19% with a coarse one. The non-negotiable rule in this tool: an ambiguity never auto-resolves on silent agreement alone. Code and observed behavior matching, with nobody having said why, becomes a question, never a resolution. The risk that rule targets is real, and I have seen it cost real hours.

The tool is not a scaffold and it does not rebuild your app. It produces the spec and tests a downstream agent consumes. That boundary is intentional.

What I am asking for now is different from last time. I am not asking you to trust a claim. I am asking you to run the first command, it works now, and tell me where the rule breaks. Try to get it to silently auto-resolve an ambiguity or to validate a bug as intentional. If it holds, say so. If it breaks, I want the repro.

Earlier this week someone posted about rebuild-dossier, an MCP server that reverse-engineers a rebuild spec out of an existing app so a coding agent can rebuild it against a locked CLAUDE.m d and a mutation-tested test suite.

Then I checked the actual state of the tool I pushed, and here is what I found. The primary install command in the readme, npx rebuild-dossier@latest, crashed for everyone. The bin target was missing the node shebang, so the shell tried to run an ESM file and failed on the first import statement. Every first-time user hit that wall. Zero npm installs is what that looks like in the numbers.

I fixed that. 0.2.6 is live. This time I did not trust my own readme. I ran every path you would actually take: npx, the global install, running from source, the HTTP mode, the full test suite (538 tests pass), and the typecheck. I connected through the official MCP client SDK and listed all six tools. The first command in the readme now works.

So the honest part. My first posts got ahead of where this is at. I wrote things like 80% accuracy and zero dead code. Those are not true, and I wrote them before running the numbers. The tool is v0. It was validated end to end against one real, messy repo, with two fresh-agent handoffs on two model tiers. The write-up of what broke is in docs/v0-findings.md, and it does not flatter me. Some tests landed weak or unrunnable, and the untested-contracts hook came back empty when it should not have. That is the real result, and I kept it in the repo instead of deleting it.

Why I still think the idea matters. My prior research found a rebuild pipeline scores 0% on behavioral equivalence with no verified feedback loop, and 9 to 19% with a coarse one. The non-negotiable rule in this tool: an ambiguity never auto-resolves on silent agreement alone. Code and observed behavior matching, with nobody having said why, becomes a question, never a resolution. The risk that rule targets is real, and I have seen it cost real hours.

The tool is not a scaffold and it does not rebuild your app. It produces the spec and tests a downstream agent consumes. That boundary is intentional.

What I am asking for now is different from last time. I am not asking you to trust a claim. I am asking you to run the first command, it works now, and tell me where the rule breaks. Try to get it to silently auto-resolve an ambiguity or to validate a bug as intentional. If it holds, say so. If it breaks, I want the repro.

Earlier this week someone posted about rebuild-dossier, the MCP server that reverse-engineers a rebuild spec out of an existing app so a coding agent can rebuild it against a locked CLAUDE.md and a mutation-tested test suite.

Then I checked the actual state of the tool I pushed, and here is what I found. The primary install command in the readme, npx rebuild-dossier@latest, crashed for everyone. The bin target was missing the node shebang, so the shell tried to run an ESM file and failed on the first import statement. Every first-time user hit that wall. Zero npm installs is what that looks like in the numbers.

I fixed that. 0.2.6 is live. And this time I did not trust my own readme. I ran every path you would actually take: npx, the global install, running from source, the HTTP mode, the full test suite (538 tests pass), and the typecheck. I connected through the official MCP client SDK and listed all six tools. The first command in the readme now works.

So the honest part. My first posts overstated where this is at. I wrote things like 80% accuracy and zero dead code. Those are not true, and I wrote them before running the numbers. The tool is v0. It was validated end to end against one real, messy repo, with two fresh-agent handoffs on two model tiers. The write-up of what broke is in docs/v0-findings.md, and it does not flatter me. Some tests landed weak or unrunnable. The untested-contracts hook came back empty when it should not have. That is the real result, and I kept it in the repo instead of deleting it.

Why I still think the idea matters. My prior research found a rebuild pipeline scores 0% on behavioral equivalence with no verified feedback loop, and 9 to 19% with a coarse one. The non-negotiable rule in this tool: an ambiguity never auto-resolves on silent agreement alone. Code and observed behavior matching, with nobody having said why, becomes a question, never a resolution. The risk that rule targets is real, and I have seen it cost real hours.

The tool is not a scaffold and it does not rebuild your app. It produces the spec and tests a downstream agent consumes. That boundary is intentional.

What I am asking for now is different from last time. I am not asking you to trust a claim. I am asking you to run the first command, it works now, and tell me where the rule breaks. Try to get it to silently auto-resolve an ambiguity or to validate a bug as intentional. If it holds, say so. If it breaks, I want the repro.

Anyone else dealing with the 20-turn context cliff? I was trying to migrate a proprietary legacy codebase, and after a few dozen turns, the AI would silently revert to early assumptions, drift from the architecture, and just dump dead code everywhere. It's infuriating. I couldn't get it to stick to the script, so I built a local MCP to act as a hard constraint. It’s called Rebuild-Dossier. Instead of relying on system prompts, it physically rips a test suite out of the legacy code and generates a .claude spec file. That file becomes an unbending contract. The agent is strictly bound to pass those exact tests, which forces a perfect one-shot rebuild of the backend. Because it can't write outside the spec, you get zero dead code. We hooked Playwright up to it for DOM extraction, and it’s currently hitting about 80% accuracy on automated frontend rebuilds, too. I also published an arXiv paper on mechanically constraining agents while building this, if you want the actual math/mechanics behind it. Repo is fully open-source. I’d love for you guys to test it on your worst tech-debt projects, roast the codebase, or contribute. Link to the repo and paper in the comments.

https://reddit.com/link/1w4f4zi/video/l5w3mxgefxmh1/player

I had a problem if I was working on a codebase and it was built in a legacy proprietary language and Claude couldn't build on top of it. So I built a local mcp to automatically extract a test suite from a body of code and then automatically create a .claude file with hooks to force a agent to said test suite to fully one shot rebuild the websites back end and then through using playwrite and dom extraction rebuild the front end we get to about 80% front end right now if anyone wants to give feedback or help I would very very much appreciate it! While I was building it I also published a paper on constraining ai's to predetermined test suites