Bonfire
Architecture

The Four Claims

Four load-bearing claims that compound into a framework, not a scaffold.

Bonfire's architecture rests on four load-bearing claims. Each one solves a problem that other frameworks leave to the application layer.

#ClaimWhat it solvesWhere it lives
1It learnsThe Knowledge Layer + Prompt CompilationPriority-based context management plus a local-first knowledge graph that accumulates patterns across runs. Fork = empty brain.knowledge/ (10 files) · prompt/compiler.py (516 lines)
2It competes with itselfDual/Triple WorkflowsStructured disagreement, not task-splitting. Sage synthesizes competing solutions.workflow/research.py (89 lines)
3It feeds its own firePipeline Engine + TDD as ArchitectureDAG-validated, gate-enforced, resumable workflows where Knights write RED tests and Warriors write GREEN code. PR lifecycle outcomes drive the ember.engine/pipeline.py (681 lines) · workflow/standard.py (108 lines)
4It gets better the more you use itCost Receipts + the XP systemPer-stage, per-agent, per-token tracking auditable across runs. XP progression rewards consistent use.cost/models.py (58 lines) · xp/

These claims are not independent features. They compound:

  • Priority truncation makes model interpolation mechanical — same prompts degrade gracefully across model tiers.
  • TDD gates make pipeline checkpoints meaningful — a checkpoint after a green gate is a safe resume point.
  • The Knowledge Layer feeds past Scout reports into future Scout context — the knowledge graph accumulates across runs.
  • Cost receipts make pipeline gates auditable — every bounce-back loop has a receipt trail.

The 7-stage pipeline is the reference implementation that wires all four claims together.