Library note. Hub page for card, verification, and audit-log operating patterns.

OpsLab — operations primitives for Claude Code teams

OpsLab is the library half of Leefan Reports that documents how we actually run things. Five pages today, all under one cluster (“Cards as an Ops Primitive”), all written from a live operation and not from a workshop slide deck. If you have ever run the same long Claude Code prompt three times and gotten three quietly different answers, OpsLab is for you.

This page is the hub. It exists to (a) tell you the shape of the cluster in 60 seconds, (b) point you at the right entry page for your situation, and (c) be honest about what is not in OpsLab yet.

1. What the cluster covers (and what it deliberately doesn’t)

OpsLab cluster A is about the card primitive — what a card is, how it lives across a run, why we prefer it to ad-hoc prompts, how we verify its output, and how the cards-as-files become an audit log a team can actually read.

Cluster A does not cover:

2. The five pages, in the order a new reader should take them

#PageWhat it gives youTrust tier
1 A1 — What a Claude Code card actually is (library page not rendered in preview) The 10-property comparison table that distinguishes a card from a prompt and from a script. Single load-bearing artifact of the cluster. Operator-grade — treat the runtime’s self-report skeptically.
2 A2 — The card lifecycle The state machine (draft → queued → running → done / blocked / rolled-back) plus sidecar JSON. Operator-grade — the rolling-back state is the part most write-ups skip.
3 A3 — Why cards beat prompts (most of the time) Two reproducible examples — one where the card wins, one where a prompt is the right tool — with diffs. Operator-grade — honest about the counter-case.
4 A4 — Reading output without trusting self-report 11-item verify checklist for the moment your runtime says it is done. Operator-grade — flags its own false-positive failure mode.
5 A5 — Cards as an audit log Directory layout + decision-log line shape that turns a folder of cards into an audit trail a teammate can read six months later. Working artifact — explicitly not compliance-grade.

Reading order is the order above. A1 is the conceptual ground; the rest extend it.

A reader short on time should read A1 + A4. A1 tells you what a card is; A4 tells you what to do the moment one finishes.

3. The trust contract for this cluster

Every page in OpsLab has a “what this does NOT cover” section, a counter-case for when the page’s recommendation is the wrong tool, and a last_verified date in the header. If you find a claim on any of these pages that you cannot reproduce from the artifacts in the Leefan Reports evidence pack, email contact@leefan.co.jp with the correction label. We respond within two business days, including with “won’t address — here is why” when that is the right answer.

4. Where these pages plug into the rest of the site

5. What’s not here yet

A serious hub page tells you what is missing. As of 2026-05:

The pages above are not on a “coming soon” countdown. The honest signal is the dated changelog and evidence pack available by request at contact@leefan.co.jp.

6. How to read OpsLab if you are…

7. Where the cluster comes from (provenance, briefly)

OpsLab cluster A was written from a live programmatic-content operation the operator runs in a different vertical and under a different brand. The artifacts here — the card schema, the lifecycle state machine, the verify checklist, the audit-log layout — are the ones that earned their keep in that operation. We acknowledge the prior vertical in the abstract on /about and do not name it further on the public site. (The prior vertical and this practice serve different audiences.)

8. What a reader can do from here in one minute