Skip to Content
ConceptsThe Loop

The loop

Lamina separates the product contract, the code that implements it, and the evidence that proves it works. Use the loop whenever you introduce or change a user-facing flow.

Persona walks expand intent before implementation; runtime evidence stays separate. Scroll horizontally to inspect the full flow. Initialize the product, run independent Persona design walks until the graph converges, implement the checked WorkMap, verify the live product, apply findings, and re-verify. Verification can return a contract gap to design.

From intent to evidence

  1. Ground the repository. Run /lamina-init once. It records business evidence and publishes inferred Product, Actor, and Persona proposals grounded in explicit user input.
  2. Walk every Persona before building. For new or changed behavior, the provider prepares one coverage-bound design task per active Persona. Isolated walks traverse every proposed node and expand missing permissions, states, branches, Scenarios, Invariants, recovery, and edge cases into the graph until a current round returns an empty discovery matrix. No implementation is required.
  3. Prepare context. The provider rule runs lamina work prepare over the expanded graph to compile Persona-bound cases, direct provenance, ranked source candidates, and stable obligations.
  4. Map and implement. Lamina mechanically scaffolds every obligation and Experience Case row, then the agent resolves each row to immutable file entries. action: modify names an existing file; action: create names a planned file. Roles distinguish implementation from tests before the agent edits source in your existing stack.
  5. Exercise the live product. The agent creates an isolated Mission and Run for every active Persona. UI work requires functional, visual, responsive, and accessibility artifacts, not merely a screenshot or passing unit test.
  6. Decide from evidence. Published Mission events are the sole case proof; the WorkMap remains unchanged. Inspect the findings and semantic diff, then accept the evidence, fix the implementation, or change the contract.

Verification findings have two different destinations:

  • An implementation defect returns to ordinary coding. Fix the product and run the same verification mission again.
  • A contract gap is published transactionally before implementing and verifying it.

This distinction keeps a failing implementation from silently redefining the product contract.

What Lamina changes

The Lamina CLI publishes graph state, packets, receipts, and evidence. It does not edit application source, choose a framework, or replace your coding agent. The provider rule gives that coding agent the graph context automatically. Human-readable implementation, report, and fix documents are optional projections from the resolved graph; the GraphVersion is canonical.

Use lamina graph status to inspect the active version and lamina graph diff --base <view> --head <view> to review the semantic change.

Last updated on