Per-feature spec-driven experiments for Layer 4 behavioral validation. Each subdirectory is one feature; each feature has a behavior-matrix spec and bash scenarios that the kb-spike harness runs against an isolated brain instance.
Methodology:
docs/experimentation-METHODOLOGY.md— read this before adding or modifying experiments.Manifesto integration:
docs/development-MANIFESTO.mdLayer 4 — when an experiment is required.Harness:
scripts/spike/kb-spike— the operator commands.
experiments/
├── README.md ← you are here
└── <feature>/
├── EXPERIMENT.md ← spec: intent + behavior matrix + scenarios index
├── scenarios/
│ ├── <scenario>.sh ← prepare / stimulate / observe
│ └── ...
└── runs/ ← gitignored — local run history
- In experiments/: the spec (
EXPERIMENT.md) and the scenarios. Both are durable artifacts that ship with the feature in mykb's git. - Not in experiments/: the kb-spike harness (lives at
scripts/spike/), the brain instances themselves (live at~/.mykb-experiments/<exp-id>/, gitignored), the run records produced when scenarios execute (underruns/, gitignored).
When the feature touches Layer 4 — i.e., when it can only be validated by a real Pi running against a real brain. Hooks, context injection, scorer changes, signal capture, side-effect counters. See development-MANIFESTO.md §3 and the methodology doc for the full rule.
If a feature is purely internal (pure logic, CLI mechanics) and Layers 1–2 cover it, no experiment is needed.
- Create
experiments/<feature>/and writeEXPERIMENT.mdwith intent + behavior matrix. - For each row of the matrix, create a
scenarios/<row-id>.sh. Pair positive/negative for behavior-counting features. - Run
bash scripts/spike/kb-spike new --experiment <feature>to spawn an instance, thenrun-scenariofor each scenario. Iterate until they pass. - Commit. The experiment becomes part of the regression suite for the feature.
A successful interactive spike can be promoted to a scripted scenario via kb-spike promote <exp-id> --as <scenario-name>.