Architecture

You want to extend the runtime, wire per-request values into Graphitron.newExecutionInput(…​), register custom scalars, hook in jOOQ listeners. → Runtime Extension Points.

You’re integrating with Apollo Federation, the @link opt-in, the <schemaInput tag> flag, providing a custom entity fetcher. → How-to: Apollo Federation transport; the contributor-facing wiring rationale lives in Dev loop internals → Federation.

You want to understand rejections, what AUTHOR_ERROR / INVALID_SCHEMA / DEFERRED actually mean in the builder, why rejection is a typed variant rather than a string, how Levenshtein candidate hints get attached. → Typed rejection.

You’re integrating an editor or agent with the dev loop, what the dev Mojo wires up, what the LSP / schema watcher / classpath watcher each watch, why idempotent writes matter. → Dev loop internals.

You want to know how the architecture got here, why the model is keyed by coordinate, what the sealed-leaf hierarchy was right about, and what measurement redirected the work onto a relational core. → The road to the relational core.

You want to know what graphitron does with a schema pattern, which facts capture writes down, how a coordinate’s verdict is derived from them, and what gets generated where. → start at Pipeline overview for the chain the architecture runs, then The fact model for the discipline that shapes it. Code Generation Triggers carries the per-pattern detail; its leaf taxonomy describes the transitional classification walk rather than the architecture the walk drains into, and each section there says so.

You want to know where a change goes. → The generator’s destination packages are facts (what capture writes), plan (what produces command rows from those facts), command (the rows themselves, pure data) and render (what folds a row into emitted output). Pipeline overview names the boundaries between them; rewrite is the transitional tree being drained and is not where new work belongs.

You’re looking for a deeper reference, the architectural principles that govern both classifier and emitter, the test-tier rubric, the unified argument-resolution lift, the dispatch-axis model behind DataLoader-backed source-side fields. → see Graphitron Development Principles, Test-tier guide, Argument Resolution, Dispatch axes. The module map is at Modules; the pipeline overview at Pipeline overview.

Trunk runs at 10-SNAPSHOT; releases are cut from tag-driven GitHub Releases. The .github/workflows/maven-publish.yml workflow accepts v<MAJOR>.<MINOR>.<PATCH> and v<MAJOR>.<MINOR>.<PATCH>-RC<n>, sets the version across the reactor, signs (sources + javadoc + GPG), and pushes to Maven Central via the central-publishing-maven-plugin with autoPublish=true. Maven version ordering treats 10.0.0-RC1 as strictly less than 10.0.0, so consumers asking for [10.0.0,) won’t pick up RCs by accident. Snapshots aren’t published; the parent declares no <snapshotRepository>, so an accidental mvn deploy on 10-SNAPSHOT fails fast.

Publishable surface: graphitron-javapoet, graphitron, graphitron-lsp, graphitron-mcp, graphitron-maven-plugin, graphitron-jakarta-rest. graphitron-jakarta-rest is a real artifact consumers pull onto their runtime classpath, so it joins the deploy set (no maven.deploy.skip), unlike graphitron-sakila-example, which only consumes the library and stays deploy-skipped. graphitron-mcp is published like graphitron-lsp because the plugin declares a compile-scope dependency on it and a Maven plugin resolves its declared dependencies from the consumer’s repositories at execution time; it must not join the maven.deploy.skip list. Test fixtures and example consumers (graphitron-fixtures-codegen, graphitron-sakila-db, graphitron-sakila-service, graphitron-sakila-example, roadmap-tool, docs) carry <maven.deploy.skip>true</maven.deploy.skip>.