Honest About What It Cannot Express
- DGG Conversion
This was a pure DGG week, and nearly every bug I found came from an assumption I didn't know I was making.
Agentic DGG conversion
The transpiler service returns HTTP 200 even when it fails, with the error as the message text, so my pipeline was handing error messages to users as if they were FoxFlow code. I now detect failure explicitly.
Retrieval had a silent bug too: ingestion stored vectors from one embedding model while queries used another with a different dimension, so retrieval returned nothing or errored. Both sides now use the same bundled embedding model, mixing is refused, and ingestion no longer needs any API key. The corpus indexed cleanly at 1,322 chunks.
I extended the emitter to handle multi-node patterns and edges, using syntax I recovered from FoxFlow's own lexer, parser and tests. Previously every rule collapsed into a single-node rewrite and every edge in the corpus was dropped; now all seven edges come through. The first real compiler error from the live service then exposed a bug the whole test suite had missed: the word I used to name a section is a reserved token in FoxFlow, so that section could never parse.
I also wrote an integration status document that is explicit about the limits. The emitted code hadn't been compiled yet, and passing my local validator is not the same as compiling. Edge direction, branching, cycles and rule bodies can't be expressed yet. And as of that week, every end-to-end run had completed through the local fallback; no cross-agent conversion had succeeded.
Reflection
'The pipeline produced FoxFlow' and 'the agents successfully converted a model' sound similar but are completely different claims. Being clear about which one I can actually make has become a habit.