Core Concepts

Strata19's free-tier tools all read and write a small set of durable, local artifacts. None of them is a copy of a chat transcript — they exist so a later conversation, possibly with a different model or a different agent entirely, can pick up where the last one left off from evidence instead of memory.

Project state

Local project state connects code relationships, findings, work, checkpoints, specifications, and evidence for one repository. It lives in a local SQLite store, resolved per project the same way the plugin resolves which repository to inspect (see Install). strata19.initialize_project binds a session to it; most other tools accept the binding implicitly once that call has run.

Findings and evidence

A finding is a bounded observation with supporting evidence — the file, the line, and the detector that produced it — not a narrative claim. Strata19 reports when evidence is incomplete or a check was not run, rather than converting that gap into a pass. strata19.get_finding_detail returns the expected-vs-observed evidence behind any one finding. See Limits for exactly which four deterministic checks exist and what each one does and does not cover.

Work and checkpoints

A work item retains the request, the touched files and symbols it was drafted against, dependencies, and acceptance criteria — captured the moment a change, bug, decision, or spec delta is mentioned in conversation, and refined one question at a time rather than rejected for being incomplete (strata19.manage_work_item). A checkpoint preserves a point-in-time graph state, stored in a local SQLite file shared across worktrees (.praetor/strata19-checkpoints.db by default), so a later conversation can resume from a saved state instead of reconstructing it from a transcript (strata19.create_or_get_checkpoint).

Specbook

The Specbook separates what the code demonstrably does from what a human has accepted as intent. strata19.spec_generate builds it from the code itself using your own model key (BYOK) and writes it as reviewable markdown into your repository — every section is labelled origin: generated, a proposal about what the code intends, never a claim that it works. strata19.spec_sync keeps it in step with the code as it changes, and never overwrites a section you have edited by hand. strata19.spec_view renders the same underlying sections through five different audience views — product, engineering, quality, security, and code — as projections over one store, so an edit made through one view is an edit in all of them. strata19.get_spec_context parses a repository's own markdown specs (including a hand-authored one, not only a generated Specbook) into chunks with acceptance criteria and a citation, rather than guessing at "what's the spec for X."

Verification

Verification records what checks ran, what they found, and the scope they covered — strata19.verify_implementation. Comparing two verification runs can show findings that are new, gone, or still present; a finding being gone from the later set means it is absent from that comparison, not that a fix was proven. Reopen the underlying work if a result does not actually support calling something done.