Lamina consistency guarantees

Skill aryaniyaps/lamina/skills/lamina-consistency-guarantees

Product-facing consistency — what users and actors may see when, stale vs fresh data, and acceptable lag. Use when multiple views must agree without prescribing storage technology.From its SKILL.md

Install

npx -y skills add aryaniyaps/lamina --skill lamina-consistency-guarantees

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

2.8 KB, 469 tokens by cl100k_base, as published. Nobody here has run it

Consistency Guarantees

Define what "correct enough" means for users and actors — in product language, not database jargon. Match guarantees to user expectations and risk.

Decision frameworks

Strong consistency (product): After an action, every view immediately reflects the outcome (payment confirmed → ticket shows downloadable now).
- When to use: Money, legal eligibility, safety-critical status.
- How: Block success UI until authoritative state is confirmed; scenarios for lag failures.
Eventual consistency (product): Views converge after a short delay (roster updates after bulk venue change).
- When to use: Non-critical aggregates, notifications, search indexes.
- How: Show "updating" state; set user expectation on delay; scenarios for stale reads.
Read-your-writes: Actor always sees their own recent changes (admin assigns venue → admin view shows assignment immediately).
- When to use: Any mutating workflow.
- How: Verify actor walk sees own action reflected.
Monotonic reads: Once shown as true, status should not flip backward without explicit transition (paid → unpaid without refund flow).

Checklists

Per operation, state the consistency guarantee users expect.
Identify views that can temporarily disagree (student app vs admin console).
Design feedback for lag (skeleton, "processing", refresh).
Write scenarios for stale read and recovery.
Do not prescribe storage — document product behavior only.

Anti-patterns

False instant: Success toast before state is durable — user acts on stale truth.
Silent staleness: Old venue on ticket after admin changed it — no refresh or notification.
Over-strong everywhere: Unnecessary blocking UX for low-risk data.

Examples

Venue change: Admin changes exam venue. Guarantee — students see updated venue within one session refresh; until then show banner "venue updated — refresh ticket." Invariant — ticket never shows old venue after download post-update without void/regenerate.