Kit System

A Kit is the fundamental unit of code generation in Praetor. Each Kit is responsible for one type of spec node — one layer of the stack — and produces a KitOutput containing generated files and an InterfaceContract that downstream Kits consume.

The Kit system is how Praetor generates a complete, runnable application from a specification: not through a single monolithic generator, but through a pipeline of composable, verifiable generation units.

What a Kit Does

A Kit receives a KitInput describing:

• The spec node to implement (specNodeId, implNodeType)
• Upstream InterfaceContract objects from nodes this node depends on
• An optional patternSeed — the best-matching pattern from the pattern flywheel
• A StructuralDiff on retry attempts — explicit feedback on what the previous attempt got wrong

It returns a KitOutput containing:

• files — the generated source files
• testFiles — associated test files
• exportedInterface — the InterfaceContract this module exposes for downstream Kits

Every Kit follows the same 7-phase execution lifecycle. See Kit Execution for the full phase breakdown.

Kit Catalog

The generation pipeline includes two categories of Kits:

LLM Kits use the AI Gateway to generate code within grammar constraints. They handle logic-bearing layers where the implementation varies by business rules.

Deterministic Steps use templates and project conventions with no LLM involvement. They handle structural scaffolding that can be derived directly from the spec.

For the full list of Kits with their inputs, outputs, and batch positions, see:

• Code Kits — EntityKit, ServiceKit, OperationKit, EndpointKit, SchemaKit, GuardKit, AuthKit, APIClientKit, WorkflowKit, WorkflowStepKit, NotificationKit
• Config Kits — ScaffoldStep, SharedTypesStep, DesignSystemStep, MigrationStep, TestInfraStep, CICDStep

Kit Registry

Kits register themselves via the KitRegistry:

class KitRegistry {
  static register(entry: KitCatalogEntry): void
  static get(type: KitType): KitCatalogEntry | undefined
  static list(): KitCatalogEntry[]
}

Registration is declarative — Kits use a @registerKit decorator at the class level. When the generation pipeline initializes, it calls KitRegistry.list() to discover all available Kits and builds the execution plan from their declared kitType and topological position.

Composition: How Kits Work Together

Kits are composed through Interface Contracts. When Kit A generates a service module, it writes an InterfaceContract to the impl node's metadata in the graph. When Kit B generates an API endpoint that calls that service, it reads Kit A's contract as an upstream dependency.

This means Kits never need to parse each other's generated files. Contracts are typed, structured, and stored in the graph — they are the only communication channel between Kits.

EntityKit → writes InterfaceContract (entity shape, table name, exported types)
    ↓
SchemaKit reads EntityKit's contract → generates Drizzle schema with correct table name
    ↓
ServiceKit reads SchemaKit's contract → generates repository with correct schema import
    ↓
EndpointKit reads ServiceKit's contract → generates route handler with correct service call

Each arrow in this chain is a typed InterfaceContract handoff. No Kit guesses about the structure of neighboring modules.

Topological Ordering

Kits execute in dependency order enforced by Kahn's algorithm over the spec graph. The full batch order is:

See Topological Sort for how Kahn's algorithm builds this order from the spec graph.

CEGIS Integration

Every Kit participates in the CEGIS (Counterexample-Guided Inductive Synthesis) verification loop. After Kit execution, the output is verified against the spec node's requirements. If verification fails, the Kit is retried with a StructuralDiff describing the exact mismatch.

LLM Kits use the diff to refine their generation prompt. Deterministic steps should not fail CEGIS — a failure there indicates a bug in the step, not a generation quality issue.

See Convergence Model for how the scoring and retry logic works.