Examples

These examples generate an application's routes, schemas, controllers, pages, seed data, and diagrams from an aontu model. Each application is checked against a reference implementation's tests over HTTP.

The validation script takes a base URL and calls the API. It tests the generated application's responses using the same expectations as the reference implementation.

Every page here is the example's own record, rendered from test/system/ in the engine repository: the model, the generators, what is hand-written, and how development goes on once the scaffold exists.

• rb-solar: a Rails application, generated

  Ruby on Rails 8, SQLite, Hotwire: the Solar System API (Planet, Moon) and a human UI over the same data

  Held to voxgig-sdk/voxgig-solardemo-sdk, which supplies the OpenAPI description, the validation script and the Ruby SDK

  nine checks, including the reference's own twenty tests

What "generated" means here

The generated application is committed, and a byte gate holds it to the model on every run: a generator answers a component tree, a generator runtime writes it, and the result is compared with what is committed. A change to the model or a generator is therefore a reviewable diff to the application, and a hand edit to a generated file is drift the check reports. Nothing is regenerated silently.

What is hand-written is only what the model does not decide (the framework's own boilerplate) and it carries no generated banner.

Running them yourself

Each example is part of the engine repository, not a separate download. Its check.sh runs from any directory, honours $AONTU so either implementation drives it, and skips the legs that need a toolchain it cannot find rather than failing.

$ ./test/system/rb-solar/check.sh    # render, boot, validate
$ AONTU="aontu" ./test/system/rb-solar/check.sh   # the same check, the Go port

An example that stops passing is a defect in the renderer, the model or the generator: never a test to relax.