Magister Fable Forge — proof-carrying code generation

The flow. ① You describe a program. ② The engine compiles your goal into a plan: concrete acceptance criteria and the files it may create — you review and approve that plan (edit it if it doesn't say what you mean). ③ A test is authored blind from the criteria — it never sees the implementation — and is proved non-hollow by mutation testing. ④ The implementation is written and must pass that frozen test plus an independent judge. ⑤ You download the code together with the proof: the approved plan, the attested test, the gate verdicts, the full run log.

What it builds well: programs whose correctness you can state as input→output rules — command-line tools, converters, parsers, text/file processors, small libraries. "Given 15, prints 1 2 Fizz 4 Buzz…; given 'abc', exits 1 with an error" is the ideal shape.

What it honestly can't: anything whose quality lives in look, feel, or interaction — GUIs, games, styled websites — or anything needing the network, a display, or libraries not on the menu. The build sandbox has no internet by design; the profile menu below is the full list of admitted toolchains (new libraries are vetted and added by the operator, never typed here).

Writing a good goal: say what goes in and what must come out, with examples; name the error behavior (bad input → what message, what exit code). Avoid vague adjectives ("nice", "user-friendly") — anything untestable is either dropped from the plan or fails honestly.

Failure is a real answer. If the engine can't produce a trustworthy test or a passing implementation, the job fails loudly and you still get the log and artifacts. That transparency is the point. Runs are token-capped (per-run + daily budget) and execute one at a time.