Reference tooling

OPFiles names a standard command vocabulary; the reference implementation ships it incrementally as part of the AIQT Guardrails reference suite. A verb that has not landed fails closed with a clear message rather than pretending to run, so a stub can never read as a completed operation. A base adopter can use their own tooling instead, or adopt by hand.

Status

The standard is a draft, and so is the tooling roster below. The verbs that have landed are usable now; the rest are recognized names that refuse with a nonzero exit until their unit ships. The turnkey walkthrough, a start-to-finish sequence with real command output, is a future section of this page: it will be written only once the verbs it shows can be run and their behaviour observed, never transcribed from design intent.

The command vocabulary

Verb	What it does	Status
`opf init`	Scaffolds validated store sources and the committed pointer; surfaces, never absorbs, anything already at the store location.	Available now
`opf render`	Regenerates the declared views; `--check` reports drift read-only, `--write` writes only on a full store validation before and after.	Available now
`opf doctor`	Runs the whole-store integrity layer read-only and returns a valid, invalid, or cannot-evaluate verdict.	Available now
`opf upgrade`	Applies the in-place, additive, idempotent base-schema upgrade, staged for your own review and merge; it never commits.	Available now
`opf import`	Scans, plans, captures attributed reviews of legacy content, and promotes a reviewed import with `--apply`; scan, plan, review, and apply have all landed.	Available now
`opf migrate`	Relocates the whole store, git history and worklog preserved, to any location a target can name.	Fails closed until it lands
`opf sync`	The surfaced pull and push step of the store consistency contract.	Fails closed until it lands

What the tooling checks

When it runs, opf doctor covers the integrity layer: schema validity, ID uniqueness and counter monotonicity, bidirectional index reconciliation, transition legality, the all-or-none resolution bundle, byte drift for every deterministic view, worklog span tiling and frozen digests, changelog coverage and freeze, archive integrity, the tracked-store requirement, pointer and sync-target agreement, and path containment. At the strictest posture, an unreadable, unparseable, or unresolvable declared input is a failure, never an empty or clean result.

Trust and integrity

The release digests are published now, independently of artefact delivery, at posluns.dev/hashes.txt, so you can confirm that the tooling you downloaded matches the one we intended to publish. The planned adoption flow will run that digest check before applying anything to your project; today the comparison is yours to run.

Publishing a verifiable signature alongside releases is a roadmap item.

How an assistant finds the standard

The site is intended to expose a machine-readable entry point for AI assistants: an /llms.txt index, a generated /adopt.md, and a plain link on the root page an assistant can follow, so that pointing an assistant at the site is enough for it to find and follow the adoption steps. This is the planned entry point; none of these files is published yet.

Relationship to the reference suite

This tooling is part of the AIQT Guardrails reference enforcement suite. It is a consumer of the standard, not its definition: a base adopter can use their own tooling, or adopt by hand (see adopt by hand), and still conform. The standard defines the store and the command vocabulary; the reference implementation is one way to work them.