One team worked it out.
Nobody else can reach it.

A team writes a security review that knows your ORM. Another works out how a model should handle your migrations. Today that work stays in the repository where somebody wrote it.

A pack is that work, installable. Installing one does not switch it on.

Check one before you trust it Read the design note
$ in-lockstep pack lswith the worked example installed
installed packs  (offered, not in force — bind one in
                 .lockstep/lockstep.py)
  acme-review-prompts        prompt    1.0.0      imports: none
                 A security lens that knows about our ORM, and a
                 guardrail about migrations

The pack that ships in this repository, installed into a throwaway environment. imports: none was derived by walking the AST of every file the distribution ships, without importing one of them.

Two ways a thing arrives.

Organization standards and extension packs use two different entry point groups, and they behave in opposite ways on arrival, for a reason worth stating out loud.

A standards package applies itself on install; an extension pack stops at offered Two rows with the same geometry. The upper row is labeled standards package: a box named in underscore lockstep dot standards sends an arrow, marked on install, into a box that reads applies itself, and a second arrow from there into a box marked in force. A note underneath says it may only tighten, so the risk is the repository that never installed it. The lower row is labeled extension pack: a box named in underscore lockstep dot extensions sends the same arrow, marked on install, into a box that reads offered. From there a dashed line stops short of the in force box and ends in a small circle. Below it a separate box reads you write it, dot lockstep slash lockstep dot py, and an arrow curves up from that box into the in force box. A note underneath says it hands a model write and execute tools, and it spends money. standards package in_lockstep.standards on install applies itself in force it may only tighten, so the risk is the repository that never installed it extension pack in_lockstep.extensions on install offered in force you write it .lockstep/lockstep.py it hands a model write and execute tools, and it spends money
Installing offers it. A line you wrote puts it in force.

The asymmetry is the point. A standards package may only tighten: lower a turn limit, deny a tool, force input scanning on. The worst it can do is refuse something, so applying it on arrival is safe and the real risk is the repository that never installed it.

An extension pack is the opposite risk. It hands a model write and execute tools, and it spends money. So detect() does not query the extensions group at all, and a test asserts that directly rather than inferring it from an empty container.

Installed, accepted, and still not running.

Drawn: how a pack is resolved. The pack from the panel above is installed here, and the record accepting it is written. This is the container that would actually run.

$ in-lockstep lsexcerpt
bindings
  Fix                    -> DiagnoseThenFix (singleton, explicit)
  Implement              -> TDD             (singleton, explicit)
  Test                   -> PytestTest      (singleton, explicit)
  Validate               -> RuffValidate    (singleton, explicit)

prompts  (what each AI binding composes;
          * = not the shipped prompt)
  TDD                implement/oneshot implement/tdd
                     guardrails: baseline, implement/implementing

standards  (in_lockstep.standards entry points; applied before
            this module's own lines)
  (none installed)

Every binding, every prompt composed, the merged policy floor, the model routed to each verb. The full listing also prints, under each deterministic binding, which tool it resolved and where. There is no line for the pack, and no section it would appear in.

A pack writes into the same band of the resolution order your own lockstep.py writes into, and nowhere else. Nothing lets a third party land there on its own, and listing one runs no code it ships: everything printed comes from distribution metadata rather than from importing the package to ask.

It is also the good failure mode. A pack installed and never bound does nothing at all, and its absence from this listing is how you find that out, which beats a binding nobody noticed arriving.

Publishing one is publishing a package.

A pack is an ordinary Python distribution holding prompts, a strategy or a verb. One entry point makes it discoverable. There is nothing else to sign up for.

pyproject.tomlexcerpt
[project]
name = "acme-review-prompts"
version = "1.0.0"
dependencies = ["in-lockstep"]

[project.entry-points."in_lockstep.extensions"]
acme-review-prompts = "acme_review_prompts"

Discovery is all the entry point does. Publish the distribution wherever you already publish packages, your company's index or the public one.

acme_review_prompts/pack.tomlthe whole file, less comments
[pack]
kind = "prompt"
summary = "A security lens that knows about our ORM, and a guardrail about migrations"

An unknown key is refused rather than ignored. The moment this file can carry a binding, a policy or a model route, it has become the second configuration surface this framework does not have. The kind is cross-checked against what the receipt derives, so a pack calling itself prose while shipping a strategy says so.

Check it before you trust it.

Three commands. None needs a key, none touches the network, none spends anything. Each reads the code you downloaded rather than the description its author wrote.

$ in-lockstep pack describe acme-review-prompts
pack          acme-review-prompts  1.0.0
distribution  acme-review-prompts  module acme_review_prompts
kind          prompt
summary       A security lens that knows about our ORM, and a
              guardrail about migrations

imports       none  (nothing importable — every module is a
              docstring, so installing it runs nothing)

offers
  (nothing importable to offer — resources only)

evidence
  corpus      2 case(s) in corpus — 2 with checks a machine
              settles, 2 needing a judge
  cassettes   0  — nothing replays offline

digest        sha256:03208834909cadc0bbdde0dcebfb4fb7eac04d0bcbd3a0f4e19c4725c67dfb45

Capabilities off the bound object, the projection off the composed prompt, imports off an AST walk. Nothing here is a claim the author typed. The module is imported afterwards, and only once the tool has said there is something to import.

$ in-lockstep pack try acme-review-promptsexit 1
config    local working tree
acme-review-prompts ships no cassette, so there is nothing to
replay and nothing to measure.

That is a fact about the pack rather than a fault in it:
somebody has to spend real money once, recording what a model
actually said, before everyone after them can measure it for
nothing.
`in-lockstep pack try acme-review-prompts --record`

Everything else can be checked and none of it says whether the pack is any good. That answer is a rate on your own cases, so --corpus ./our-cases counts yours apart from the pack's own. When nothing was decided there is no rate, and the output names the absence rather than printing a zero.

$ in-lockstep add acme-review-promptsexcerpt
NOT PINNED    acme-review-prompts is not fixed to a version
              here, so this receipt describes code that may not
              be the code installed next time.
              `uv add acme-review-prompts`.

recorded      .lockstep/packs/acme-review-prompts.json
              commit it: the record IS the acknowledgement, and
              doctor reads it.

paste into .lockstep/lockstep.py:

    from in_lockstep.packs import pack

    acme_review_prompts = pack('acme-review-prompts')

until you do, nothing changes: `in-lockstep ls` will not mention
acme-review-prompts.

The last line is the whole safety model in one sentence, printed by the tool. Installing offered it. Pasting is what accepts it.

add writes no bytes to .lockstep/lockstep.py under any combination of flags, and there is no flag that turns that off. That file can rebind any adapter, remove any middleware and grant any tool, and it loads from a trusted ref precisely because every line in it was typed by a person.

It does not install anything either. A framework that ran the installer would be deciding what you trust rather than telling you what you are trusting. What it writes is the receipt, and that file is what the next section compares against.

What an upgrade has to say out loud.

A pack you accepted a year ago can be widened by a dependency bump nobody read closely. Three checks re-derive the receipt from the code that is installed now and compare it with the record you committed.

The three doctor checks that read a pack's accepted record
CheckWhat it saysVerdict
DOC170this pack may now do more than the repository acceptedfails
DOC171a bound prompt no longer opens with the shipped guardrail baselinewarns
DOC172a pack is installed but not pinnedwarns

Only DOC170 is an error, and the line it draws is agency. A capability the pack did not hold before is refused until --accept says otherwise, and a refusal records nothing, so a repository cannot end up having accepted what it declined. A version or a new prompt is recorded without a flag: refusing over those would teach people to pass --accept by reflex.

$ in-lockstep doctorthe pack finding
WARNING DOC172  pack 'acme-review-prompts' is
                installed but not pinned
                 A receipt describes the code installed
                 now; a pin is what makes that the code
                 installed next time. Without one,
                 capabilities were accepted for a range.

Run here with the worked example accepted. DOC171 reads the bound adapters rather than the installed packs, because what matters is the prompt a run would really send.

The registry is a file in a git repository.

A catalog is a static index.toml listing packs and pointing at receipts committed beside them. No service, no accounts, no ranking anyone has to defend.

Registering one writes .lockstep/market.toml, and you commit it, because a catalog decides where this repository looks for code.

An entry points at a receipt derived by pack describe, so a listing records what the author's code did rather than what the author wrote. add re-derives it locally and refuses a pack holding more than the catalog published, outright rather than behind a flag: that is a listing that does not describe the code.

A listing you can check beats a listing you have to trust.

Nothing reads it during a run. A repository that installed a pack runs identically to one that copied the same class in by hand, which is what keeps a strategy from ever becoming a name untrusted input could reach.

Where this actually is

  • No pack has been installed from a real index. The worked example is exercised by tests, and no catalog has been published at a real URL. The first person to publish one will find things these tests cannot.
  • The worked example cannot be measured. It ships prose and two corpus cases and no recording. Fabricating a model exchange to turn that lint green would invent the one kind of evidence this project exists to refuse to invent.
  • pack try drives one verb. review only: a single model turn with the diff in the prompt, which is exactly what a cassette replays.
$ in-lockstep market lint examples/lockstep-index/index.tomlexit 1
  acme-review-prompts          prompt    FAILS
                               missing: at least one cassette, so
                               measuring costs nothing

1 entr(y/ies), 1 failing the criteria this catalog states

This project's catalog fails its own criteria, on purpose. Four checks run off the receipt: a receipt at all, imports: none for a prompt pack, a corpus so it can be measured, a cassette so measuring costs nothing. Meeting them says nothing about whether the code is good.

$ in-lockstep market add acme http://raw.example/acme/index.tomlexit 1
config    local working tree
Error: 'http://raw.example/acme/index.toml' is not an https
URL. A catalog says what code to install, so it is fetched over
a channel that cannot be rewritten in transit.

Refused before anything is written. Over plain http, a catalog's description of a pack is whatever the network says it is, and the receipt comparison would be checking an attacker's document.

Read a real one before you write yours.

Both ship in this repository, and every command on this page was run against them. With no name, pack describe turns the same receipt on your own project: what it binds, what that may do, and what proves it.

$ in-lockstep pack describe

The worked pack

Markdown, two corpus cases, and one module holding a docstring. The cheapest kind of pack there is.

The worked catalog

An index.toml, the receipts it points at, and a README saying why it fails its own criteria today.

Rules that only tighten

The other entry point group: standards that apply themselves on install, because all they can do is constrain.