RepoDoctor runs an unfamiliar repo in a throwaway sandbox, reads the real errors, and asks GPT-6 Astra for the smallest safe fix. A policy gate decides. It retries the command that failed, then ships a Dockerfile only after a fresh image passes.
What became possible in your product with Astra that was not practical before?
Maker
RepoDoctor can reason across repository structure, real execution failures, previous repair attempts, and verification results instead of making a one-shot Dockerfile guess. This enables a closed loop of plan → execute → observe → repair → retry → verify, with Astra reasoning about what to do next while deterministic policy and isolated execution verify that the proposed fix actually works.
Report
Maker
📌
Hi Product Hunt 👋
I built RepoDoctor because of a specific kind of frustration: getting an
unfamiliar repository to actually run.
Ask an LLM for a Dockerfile and you'll get something plausible. It looks
right. It might even build. But "looks right" and "runs" are different
things, and the gap between them is where hours disappear — a missing
package manager, a virtual environment that was never created, a
dependency group nobody installed.
So I built something that refuses to guess. RepoDoctor executes the
repository in a throwaway sandbox, reads the real exit code and stderr,
and only then asks for help. GPT-6 Astra proposes the smallest
environment-level fix. A deterministic policy decides whether that fix is
allowed to run — the model never gets execution authority. Then
RepoDoctor retries the original command that failed. Only a successful
retry counts as a repair.
And it doesn't trust its own output. Once the repository works, it writes
a Dockerfile, builds a completely fresh image, and reruns verification
inside it. If the fresh image fails, there is no verified Dockerfile.
AI proposes. Policy decides. Sandbox executes. Verification proves.
Two things I deliberately did not do:
It will not edit your source code. If the environment reproduces but your
own linter still fails, it says so — environment reproduced, checks
failed — and hands you the Dockerfile that builds. Fixing your code is
your call, not a model's.
It will not claim a repair it can't prove. A repair is verified by
retrying the command that failed, not by the repair command exiting 0.
How the GPT-6 Astra Challenge went: this project was originally framed
around a different model provider, and porting it to Astra turned out to
be the most useful part of the build. Structuring both agents around
strict JSON contracts — and keeping one narrow client boundary — meant
Astra could own the reasoning while the execution layer stayed
deterministic and auditable. The interesting shift wasn't raw capability;
it was how much more I trusted the loop once the model's output had to
survive a policy gate and a real retry.
What I'd love feedback on:
1. Which ecosystem should come next? Python and Node.js work today.
2. Would you rather have the repair trace or the final Dockerfile as the
primary artifact?
3. Where would you not trust this yet?
Try it with the repo that wasted your afternoon. That's the repodoctor
moment I'm chasing.
Thanks for reading 🙏