Skip to Content
ConceptsPersonas

Personas

Lamina verification does not use one generic “user.” It dispatches parallel subagents that walk your application as real actors with distinct goals and permissions.

Quick path

  1. /lamina-init writes .lamina/personas.json — the actor cast
  2. /lamina-design references personas in run.json actors
  3. /lamina-verify dispatches one subagent per primary actor at base_url

Why personas matter

A single test user misses:

  • Permission gaps — admin actions available to guests
  • Role-specific flows — hotel onboarding vs traveler checkout
  • Cross-actor conflicts — two users booking the same held inventory
  • Recovery paths — what happens when payment fails mid-checkout

Persona walks surface these by simulating how each actor actually uses the product.

personas.json

The global actor cast lives at .lamina/personas.json, written by /lamina-init:

personas:
  - id: leisure_traveler
    primary: true
    surface: traveler_web
    summary: Plans leisure stays; wants clear search and fast booking.
    goals:
      end:
        - find a suitable hotel for trip dates
        - complete a paid booking and receive confirmation
    permissions:
      - register_and_authenticate
      - search_and_filter_hotels
      - create_booking
      - pay_for_booking

See Global artifacts for the full field reference.

Example actors (HavenStay)

PersonaSurfaceKey flows
leisure_travelerTraveler webSearch → book → pay → manage reservation
hotel_operatorHotel dashboardOnboard → manage property → handle reservations
platform_adminAdmin consoleApprove properties → handle trust reports → manage payouts

Each persona walks independently. Lamina checks that the permission matrix and state transitions hold for every actor.

Advanced: Negative personas (negative: true) document who the product explicitly does not serve — vacation rental hosts, enterprise chain admins, etc. They prevent scope creep during design.

How verification works

  1. /lamina-verify reads the contract and personas.json
  2. One subagent is assigned per primary: true actor
  3. Each subagent navigates your live application at base_url
  4. Visual evidence captures to walkthrough/
  5. Invariant and reachability probes run against the contract
  6. Product and contract findings aggregate into findings[] and fix.md; fix_target: ops observations stay in report.md only

Probe types during verify

ProbeChecks
Actor walksEach persona completes their workflows
Invariant probesBusiness rules from invariants[]
Reachability probesUnmet dependencies[]
AccessibilityCritical flow steps against a11y standards

base_url requirement

Persona walks require a running product. Start your dev server before verify:

/lamina-verify guest checkout at http://localhost:3000

Without a live app, walks cannot capture real behavior.

What personas catch

From the HavenStay demo:

  • Guest checkout allows booking while another guest holds the same room
  • Cancellation policy not snapshotted at booking time
  • Property goes live on submit without admin approval
  • Cancel path missing required reason field

These are product behavior gaps — not UI bugs.

Tips

  • Define actors clearly in /lamina-init — vague roles produce vague verification
  • Run verify against a running dev server, not static mocks
  • Provide demo accounts for each actor type on brownfield projects
  • Re-verify after every fix cycle until zero open product or contract findings
  • Inspect walkthrough/ for visual evidence per actor

Next steps

Last updated on
Contracts & RunsBrownfield & Greenfield