Product
A learning loop for repository guardrails.
Project Spine records a reviewed failure and a maintainer-authored literal rule, then reads Git history to verify that the rule catches the recorded break without rejecting its correction. Verified rules can then run in CI and reach coding agents through relevant context.
From review to enforcement
review evidence
↓
candidate require-text / forbid-text rule
↓
read-only Git replay: broken fails · corrected passes
↓
verified rule → CI guard → file-relevant context → MCPThe evidence trail remains local and reviewable. A replay validates a specific literal rule against specific commits; it does not rerun an agent or prove that an entire defect class is impossible.
v0.10 beta commands
spine learn --case failure.jsonImport explicit evidence and create a candidate scoped rule.spine learn --from-pr <url>Import GitHub review metadata when network access is intentionally requested.spine replay <case-id>Check the candidate against recorded broken and corrected Git commits.spine guard --diff HEAD~1Evaluate verified rules against changed files; add --json for CI.spine context --files 'src/a.ts'Return only the verified rules relevant to a set of files.spine report --format html --out report.htmlWrite a local, inspectable evidence and verification report.spine evaluate <case-id> --adapter adapter.json --allow-execution --runs 1 --jsonOptionally execute a configured agent or evaluator in temporary clones.
Rule model
The beta intentionally supports deterministic forbid-text and require-text rules scoped by file globs. Each case can connect review evidence, a broken commit, a corrected commit, and replay results. This narrow model is easy to inspect, explain, and reproduce.
Executable corrections are the next pilot
Literal rules catch a precise class of regressions without executing repository code. Some corrections need behavior, not text. The source-available correction pilot captures a maintainer-reviewed, dependency-free node:test file from an explicit fixed commit, then pairs it with each revision’s own source files.
Verification applies those recorded bytes to both the broken and fixed revisions, then runs them in a digest-pinned Docker image with no network, a read-only root filesystem, a non-root user, and bounded resources. Execution requires an explicit --allow-execution acknowledgement. Current-tree checks revalidate those controls before reporting a result.
A captured correction is a candidate. It becomes verified only after the controlled run fails on the broken revision and passes on the fixed revision. Spine does not infer tests, repair failing tests, or label candidate context as verified.
spine correction demo --image <image@sha256:digest> --allow-executionRun the synthetic behavioral fixture after pre-pulling the reviewed image.spine correction capture … --out correction.jsonCapture reviewed test bytes, source closure, explicit revisions, lesson, and image digest without execution.spine correction verify --case correction.json --repo . --allow-executionRequire the captured test to fail on the broken revision and pass on the fixed revision under the declared controls.spine correction check --case correction.json --repo . --allow-executionRecheck the current tree and execution controls before returning verified guidance.spine correction context --case correction.jsonRead the captured lesson without execution; output remains labelled candidate.
The operator pre-pulls an explicitly reviewed, digest-pinned image. The pilot will not select or fetch a floating image on its own. See the correction workflow contract.
Why not just write a test?
You should write the test. Spine preserves the reviewed test bytes, their source closure, their broken/fixed evidence, and the execution controls as one auditable correction. It complements the normal suite by retaining why this test exists and proving it distinguishes the recorded failure before using it as agent context.
Replay and evaluation are different operations
spine replayis historical and read-only.It reads Git objects and evaluates literal rules. It does not check out commits, execute repository code, call a model, or require network access.spine evaluateruns configured programs.It requires--allow-execution, creates temporary clones, and invokes the adapter you provide. That adapter may call an agent, a model, or the network and may incur usage costs.
Evaluation does not provide an OS sandbox. Review the adapter and repository before enabling execution. See the evaluation contract for the adapter schema, recorded outputs, and cleanup behavior.
What remains
- Compile and drift.The existing brief-to-agent-context compiler and drift checks remain available as secondary workflows.
- Local MCP.MCP clients can ask for relevant rule context without a hosted account or repository upload.
- Human review.Maintainers author and review candidate rules. Spine verifies their historical evidence before enforcement.
Boundaries
- Replay does not rerun an agent.The separate opt-in evaluation command can execute a configured agent or evaluator with explicit consent.
- No universal prevention claim.A passing literal replay or correction verification is evidence for the recorded case, not a guarantee against every future variation.
- No inferred executable tests.The correction pilot accepts user-reviewed test bytes and an explicit source closure. It does not synthesize tests or claim agent-performance results.
- No hosted fleet dependency.The v0.10 beta is a local CLI, local report, CI guard, and local MCP surface.