SBX — AI-Augmented Framework

01 Problem

AI coding agents move fast but lose context across sessions and skip architectural discipline. Governance usually arrives as PR comments, not as a process the agent must walk through to produce code.

02 Approach

Bottom-up modeling first: each package starts as a YAML model, then Go code is generated against it. The framework is the single source of truth — `.engine` (legacy) is read-only; new work is rebuilt from first principles via `/decision`. The CLI is intentionally a thin ergonomic shell around governed primitives, not a kitchen sink.

03 Solution

Built `sbx`, a Go CLI that wraps every platform tool (build, test, infra, vault, migrations, deploys) and a `.framework/core/` protocol layer of YAML schemas that encode SDLC state, knowledge artifacts, decisions, and traceability rules. The CLI reads the framework, drives a state-machine SDLC, and refuses to advance until each step has the required artifacts. SBX governs its own development — every change to SBX is shipped through SBX.

04 Outcomes

05 Trade-offs

Self-hosting means every framework change must survive its own gates, which slows raw output but produces an immutable audit trail. Chose Go + YAML over a higher-level scripting layer to keep the CLI a single static binary that runs identically on macOS dev and Linux CI.

06 Constraints

• Self-hosting: framework must govern its own development
• Knowledge-before-implementing — no code without loaded artifacts
• Model-before-code — package.yml before Go implementation
• .framework MUST NOT depend on legacy .engine

07 Innovation

Self-hosting AI governance framework. The CLI enforces a state-machine SDLC (story → model → code → test → conformance) with knowledge gates that block agents from skipping architectural discipline. Anchored by decisions like #0061 (model-before-code), #0113 (SDLC state machine), #0148 (client registry), #0193 (PR workflow required), and #0207 (rapid pipeline as default).