A SQLite reference implementation built to validate the specforge extract→build cycle.
Each module is hand-written as a reference implementation, then:
- A YAML spec is extracted from the code using
specforge extract - A cleanroom implementation is built from the spec alone (no access to the reference)
- The original test suite is run against the cleanroom output
- Findings are documented comparing reference vs cleanroom
| Module | Description | Tests | Cleanroom |
|---|---|---|---|
| parser | CREATE TABLE parser (tokenize + parse) | 38/38 | 38/38 |
| storage | In-memory storage engine (type coercion, constraints, rowid) | 56/56 | 56/56 |
| tokenizer | General SQL tokenizer (strings, numbers, operators) | 38/38 | 38/38 |
| insert | INSERT INTO parser + executor | 30/30 | 30/30 |
sqlforge/ # Reference implementation (hand-written)
parser.py # SQL CREATE TABLE parser
storage.py # In-memory storage engine
tokenizer.py # General SQL tokenizer
insert.py # INSERT INTO parser + executor
tests/ # Test suite (shared between reference and cleanroom)
test_parser.py
test_storage.py
test_tokenizer.py
test_insert.py
specs/ # Extracted specforge YAML specs
app.yaml
parser.yaml
storage.yaml
tokenizer.yaml
insert.yaml
output/ # Cleanroom implementations (built from spec only)
parser.py
storage.py
tokenizer.py
insert.py
docs/ # Design specifications
parser-design.md
storage-design.md
tokenizer-design.md
insert-design.md
FINDINGS.md # Detailed comparison of reference vs cleanroom
pip install -e ".[dev]"
pytestBoth modules achieve zero behavior gaps in cleanroom builds. See FINDINGS.md for detailed analysis including:
- What the spec extractor captures well vs misses
- Diff analysis between reference and cleanroom implementations
- Implications for spec-driven development
GPL-3.0-or-later