@cronus-ui/ai-kit 0.6.0

package/templates/AGENTS.fintech.md

@@ -0,0 +1,116 @@
+## Fintech / payments preset
+
+Enable this preset when __APP_NAME__ moves money: payments, checkout, marketplaces,
+payouts, wallets, subscriptions, ledgers, or anything that reports balances to a user
+who makes decisions with that number. It appends to and specializes the base rules.
+
+Central rule: **money, trust, and operational continuity outrank apparent speed.**
+The financial layer holds the highest bar in the product: it cannot be approximate,
+obscure, or unverified. Any number a user acts on — to scale ad spend, to pause, to
+withdraw, to reconcile — must be traceable to a real source of record.
+
+### 1. Financial truth before UI
+
+Every financial figure must have a clear origin. If a screen shows revenue, balance,
+reserve, payout, fee, refund, chargeback, or adjustment, there must be an auditable
+path from that pixel to the real source: the internal ledger, the processor/acquirer,
+the bank, or a recorded financial event. A pretty number without backing is a
+liability, not a feature. If you cannot name the source, do not display the number as
+fact.
+
+### 2. Revenue is not withdrawable balance — separate the money layers
+
+Never treat gross sales, net revenue, available balance, reserve, in-transit, and paid
+payouts as the same thing. When you compute, explain, or render money, keep these
+layers distinct and labeled:
+
+- **approved** — the sale/authorization succeeded, but the money is not settled;
+- **settled / captured** — funds confirmed by the processor;
+- **in-processing** — pending settlement, clearing, or review;
+- **net revenue** — settled minus fees, refunds, chargebacks, and disputes;
+- **reserve** — held by rolling-reserve or risk rules, not spendable;
+- **available** — cleared and eligible to be paid out;
+- **payout-created** — a payout/transfer was initiated;
+- **in-transit** — payout sent, not yet confirmed at the destination;
+- **paid** — payout confirmed at the destination account;
+- **adjustment** — manual compensation, correction, or off-ledger movement.
+
+If two amounts look similar, assume they may be different layers until proven
+otherwise. Collapsing layers is how a dashboard lies without a single wrong query.
+
+### 3. Dashboards must not induce wrong scaling decisions
+
+If a screen makes a user believe they are profitable while the real ledger says
+otherwise, that is a P0/P1 defect — not a styling ticket. A financial surface must make
+explicit:
+
+- what is commercial performance vs. what is actual balance;
+- what has already been deducted (fees, refunds, disputes) vs. what has not;
+- what is still in reconciliation or review;
+- what has not yet become spendable money;
+- what depends on a release rule (reserve, hold, settlement window).
+
+Users decide traffic, hiring, and cash moves from these numbers. Financial confusion
+costs real money, support load, and reputation. Optimize the number for correctness
+first, then for clarity, then for looks.
+
+### 4. Downstream data is a business decision
+
+Events emitted to analytics, pixels, webhooks, or partner integrations are treated as
+business decisions, not technical details. A wrong or duplicated purchase/refund event
+can distort a user's ad optimization and cause real loss. Deduplicate, version, and
+document the contract; a change to an emitted financial event is a P1 by default.
+
+### 5. Financial divergence protocol
+
+When there is any doubt about balance, payout, revenue, reserve, or "missing money",
+do not answer on impulse. Run the protocol:
+
+1. Do not assume the customer is wrong.
+2. Do not assume the dashboard is right.
+3. Do not assume the processor/acquirer is right without checking.
+4. Fix the scope first: exact **period**, **account**, **store/project**, and **currency**.
+5. Break the account into blocks and reconcile each: approved, settled,
+   in-processing, refunds, chargebacks/disputes, fees, reserve, adjustments,
+   available, payouts paid, payouts in-transit, and manual/off-ledger payments.
+6. Produce a line-by-line reconciliation when the totals do not agree.
+7. Explain the result in plain terms that do not hide the problem.
+8. If the screen is wrong, fix the screen. If the money is wrong, quantify it, correct
+   it, and document it.
+
+Hard rule: **never call something a "visual bug" before it has been reconciled.** A
+silent explanation protects you today and destroys trust later.
+
+### 6. Money-handling essentials
+
+Get the mechanics right or the money is wrong at the source:
+
+- **Never use floating-point for monetary amounts.** Store and compute in minor units
+  (integer cents) or a fixed-precision decimal type; binary floats silently lose cents.
+- **Put an idempotency key on every money-moving mutation.** A retry, double-click, or
+  webhook redelivery must collapse to exactly one charge, refund, or payout.
+- **Verify every webhook and callback signature, and treat the payload as untrusted.**
+  A processor callback is a public HTTP endpoint until proven authentic; validate before
+  you act on it.
+
+### Evidence and criticality for money
+
+This preset raises the base gates for financial work:
+
+- Anything touching money, balance, payout, checkout, or ledger is **P0/P1** — the
+  full review + QA gate is mandatory, not optional.
+- Financial conclusions must not close below **L3**; anything affecting payout, balance,
+  or production money must reach **L4**, with a closed reconciliation.
+- Prefer a dry-run or a read-only reconciliation before any money-moving mutation.
+- Never invent amounts, rates, or reconciliations. State exactly what was not verified.
+
+### Money-flow anti-patterns
+
+The base "never introduce" list (unbounded retry, infinite polling, unthrottled fan-out,
+messages that requeue forever, crash-on-missing-dependency) applies in full. Two failure
+modes are money-specific and worse:
+
+- a boot or dependency failure that degrades into silent double-charges or dropped
+  transactions instead of failing loudly and cleanly;
+- a **silent fallback that turns a financial error into a trustworthy-looking zero** —
+  show the error state; never fabricate a clean number.

package/templates/AGENTS.oss.md

@@ -0,0 +1,78 @@
+## Open-source preset
+
+Enable this preset when __APP_NAME__ is published for others to depend on and
+contribute to: a library, SDK, CLI, or public API released under an open-source
+license. It appends to and specializes the base rules.
+
+Central rule: **the public surface is a contract with strangers you will never meet.**
+People build on what you export, on a schedule you do not control. Breaking them
+silently, or shipping a secret to a public repo, is a P0 — not a follow-up.
+
+### 1. Guard the public surface, version it honestly
+
+Anything exported — functions, types, CLI flags, config keys, HTTP routes, event
+shapes — is API the moment it ships. Treat the boundary between public and internal
+as deliberate.
+
+- Keep the public surface small and intentional; mark internals clearly and do not
+  let them leak into the published entry points.
+- Follow **semver** literally: a breaking change to public behavior is a **major**
+  bump, new backward-compatible capability is minor, fixes are patch.
+- **Deprecate before you remove.** Ship the deprecation with a warning, a migration
+  note, and a replacement, keep it working for at least one minor cycle, then remove
+  only on a major. Never delete public API in a patch.
+- When a change would break consumers, stop and say so plainly — do not disguise a
+  breaking change as a "fix."
+
+### 2. Never commit a secret
+
+A public repository has no private corners, and git history is forever.
+
+- No tokens, keys, passwords, private endpoints, or customer data in source, tests,
+  fixtures, examples, or commit history.
+- Use placeholders and documented env vars; keep real secrets out of the tree with
+  ignore rules and pre-commit hygiene.
+- If a secret is ever committed, treat it as compromised: rotate it, do not merely
+  delete the line.
+
+### 3. Make contribution and review easy and consistent
+
+Contributors are guests; lower the cost of a good PR and keep the bar visible.
+
+- Keep contributor docs current: how to set up, build, test, and lint, plus the
+  commit and branching conventions this project uses.
+- PR hygiene: one focused change per PR, a clear title and description, linked issue,
+  green CI, and tests for new behavior and fixed bugs.
+- Review with the same adversarial posture whether the author is a maintainer or a
+  first-time contributor; be direct and kind, and explain the *why* behind a request.
+
+### 4. Keep docs, README, and CHANGELOG true
+
+Out-of-date docs are a bug reported by every new user.
+
+- Update the README, examples, and API docs **in the same change** as the code they
+  describe. A feature without docs is not done.
+- Maintain a human-readable CHANGELOG with every release: what changed, what broke,
+  and how to migrate. Users decide whether to upgrade from it.
+- Examples must actually run against the released version.
+
+### 5. Respect license and attribution
+
+The license is a legal promise; honor it and keep it consistent.
+
+- Where the project uses per-file license headers, add them to new files; match the
+  existing style and year convention.
+- Keep the LICENSE, third-party notices, and dependency licenses accurate; do not
+  introduce a dependency whose license conflicts with the project's.
+- Preserve existing copyright and attribution; never strip it.
+
+### Security disclosure
+
+Vulnerabilities in a public project put every downstream user at risk.
+
+- Provide and follow a responsible-disclosure path (a `SECURITY.md` / private
+  contact); **never** discuss an unpatched vulnerability in a public issue or PR.
+- Fix privately, prepare the patched release and advisory, then disclose with credit
+  and an upgrade path. Coordinate the release so users can update before details are
+  public.
+- A security fix is P0: it jumps the queue and ships with a clear advisory and version.

package/templates/AGENTS.saas.md

@@ -0,0 +1,88 @@
+## SaaS preset
+
+Enable this preset when __APP_NAME__ serves multiple customers from one shared
+deployment: a multi-tenant web app, an API product, or any system where one
+account's data, billing, and limits must never bleed into another's. It appends to
+and specializes the base rules.
+
+Central rule: **the tenant boundary is a security boundary, and billing state is a
+promise.** Leaking one tenant's data into another's view is a P0 breach, not a bug.
+Charging, entitling, or cutting off a customer incorrectly is a P0/P1 that costs
+money and trust. Neither is ever a styling ticket.
+
+### 1. Tenant isolation is not optional
+
+Every query, cache entry, background job, file path, and object key must be scoped
+to a tenant. There is no "just this once" global read.
+
+- Derive the tenant from the authenticated principal, **never** from a client-supplied
+  id, header, or body field that the request could forge.
+- Namespace every cache key, queue message, storage prefix, and search index by
+  tenant id; a shared key that omits the tenant is a cross-tenant leak waiting to fire.
+- A missing or ambiguous tenant scope is a hard stop — fail closed, do not fall back
+  to "all rows."
+- Cross-tenant work (admin tools, aggregate reports) is a separate, explicitly-audited
+  path with its own authorization — never a side effect of a normal handler.
+
+### 2. Authorize every handler — deny by default
+
+Authentication answers *who*; authorization answers *what they may touch*. Both run
+on every entry point.
+
+- Default to deny. A new route, RPC, job, or webhook is unauthorized until you add
+  the check — never authorized because you forgot one.
+- Enforce **object-level** access: confirm this principal may act on *this specific*
+  resource, not merely that they hold the role in general.
+- Check on the server, on every request. Client-side gating is UX, not security.
+- Least privilege for machine principals too: scope API keys, service tokens, and
+  internal callers to exactly what they need.
+
+### 3. Billing and entitlements must be correct
+
+Subscription state drives what a customer can do and what they pay. Get it exactly
+right.
+
+- Entitlements (plan, seats, feature flags, quotas) are enforced server-side from the
+  current subscription — never trusted from the client or a stale cache.
+- Make billing operations **idempotent**: no double-charge on a retry, a webhook
+  replay, or a double-click. Key money-moving actions by a stable idempotency token.
+- Handle the full lifecycle honestly: proration on plan change, trials, downgrades,
+  cancellations, failed payments, dunning, and grace periods. Treat the billing
+  provider's webhook as the source of truth and reconcile against it.
+- A wrong invoice, a missed cancellation, or an over-provisioned plan is P0/P1.
+
+### 4. Treat PII and data lifecycle as a contract
+
+Customer data carries legal and reputational weight.
+
+- Collect the minimum, encrypt in transit and at rest, and never log raw PII,
+  credentials, tokens, or full payloads.
+- Honor retention and deletion commitments: know where every copy of a tenant's data
+  lives (DB, cache, backups, search, logs, exports) so export and hard-delete are
+  actually complete. Secrets and per-tenant keys stay managed, rotatable, and uncommitted.
+
+### 5. Rate-limit per principal, not just globally
+
+Apply quotas and rate limits per tenant / per API key / per user, so one noisy account
+cannot starve the rest. Bound the cost of expensive operations (exports, reports,
+fan-out); push back with a clear `429`, never silent failure or unbounded work.
+
+### 6. Migrations stay safe and reversible
+
+Shared tables are shared risk; a bad migration can take down every tenant at once.
+
+- Prefer additive, backward-compatible changes; use expand/contract for column and
+  type changes so old and new code run together during rollout.
+- Every migration ships with a tested rollback and, for large tables, a plan that does
+  not lock out live tenants. No destructive change without an explicit, approved window.
+
+### Observability without leaking
+
+Instrument logs, metrics, and traces so incidents are debuggable — and so they never
+become the leak.
+
+- Tag telemetry with tenant id (or a stable pseudonym) to isolate one customer's
+  problem, but **redact secrets and PII** from every log line, span, and error report.
+- Error messages returned to a client must not disclose another tenant's existence,
+  ids, or data. Log the detail server-side; return the minimum.
+- A log or trace that exposes a token, password, or personal data is itself a P0.

package/templates/CLAUDE.md

@@ -0,0 +1,52 @@
+# __APP_NAME__ — Claude Code
+
+@AGENTS.md
+
+## Claude Code specifics
+
+The shared operating doctrine is imported above from `AGENTS.md` and applies to
+every session. This file adds only what is specific to Claude Code.
+
+- **Plan before risky changes.** Use plan mode for anything that touches shared
+  contracts, data, migrations, auth, build/release config, or work classified
+  P0/P1. Present the plan, get agreement, then execute. Don't plan trivial edits.
+- **Prefer the project skills and subagents.** Reusable workflows live in
+  `.claude/skills/` and subagents in `.claude/agents/`. Reach for them before
+  improvising. For a pre-merge review, run the `code-review` skill for an inline
+  review in the current session, or delegate to the `code-reviewer` subagent for
+  a review in a fresh, isolated context — both apply the Code-Review and QA
+  rubrics from `AGENTS.md`.
+- **Keep commits AI-attribution-free.** No assistant or tool attribution in
+  commit messages, PR descriptions, or code comments. Follow the git and PR
+  rules in `AGENTS.md`.
+- **Read before you write.** Open the file and map the blast radius before
+  editing. Never edit a file you have not read in the current session.
+- **Leave no debug residue.** Strip scratch logging and instrumentation from the
+  final diff.
+- **Report evidence honestly.** State the evidence level (L0–L4) behind claims,
+  and say plainly what you did not verify. Don't call something "done" without
+  the objective evidence the QA rubric requires.
+
+## Cronus UI product loop
+
+If this project uses Cronus UI (`cronus-ui.json`, or compose / ui-add / theme skills
+under `.claude/skills/`), follow this loop — do not hand-roll screens or reach
+for another component kit:
+
+- New app: `npx create-cronus-app <name> --template saas`. Never omit `--template`
+  (CLI default is an empty starter). Other composed templates: `store`, `landing`.
+- New route: `npx cronus-ui add-page` or MCP `add_page`. Pages are installed
+  blocks stacked in `<main>` — do not hand-write a page of Cards.
+- One primitive: `npx cronus-ui add <slug>` (MCP `install_component`). Prefer the
+  `compose`, `ui-add`, and `theme` skills when they exist.
+- Theme: `npx cronus-ui theme set` / `useTheme`. Never `bg-zinc-*` or palette
+  utilities.
+- Upgrade: `npx cronus-ui upgrade --all --dry-run`, then `--all`. Refreshes
+  installed items and composed pages. MCP `upgrade_components`.
+- Never run shadcn init or write a shadcn `components.json`.
+
+## Tools
+
+- If `.mcp.json` registers the `cronus-ui` MCP server, use it to look up component
+  and block metadata instead of guessing (`add_page`, `install_component`,
+  `set_theme`, `upgrade_components`).

package/templates/claude/agents/code-reviewer.md

@@ -0,0 +1,80 @@
+---
+name: code-reviewer
+description: >-
+  Reviews a diff or proposed change in a fresh, isolated context before it
+  ships. Delegate here for any P0/P1 change, or whenever the user asks for a
+  code review, a second pair of eyes, or a pre-merge check and wants it done
+  outside the current session's context. Applies the full Code-Review and QA
+  rubric from AGENTS.md with explicit evidence levels and a criticality rating.
+  Read-only — it reports findings and a verdict; it does not modify code. For an
+  inline review within the current session, use the code-review skill instead.
+tools: Read, Grep, Glob, Bash
+model: sonnet
+---
+
+You are a senior code reviewer running in a **fresh, isolated context** — you carry no
+session bias, which is the point of delegating here. You wear four hats at once —
+Architect, QA, Security Reviewer, and Release Manager — and you review critically, not
+confirmatorily. Your job is not to approve; it is to find what is wrong before it reaches
+production. (For an inline review inside the caller's session, the `code-review` skill
+does the same work; this subagent is for a clean-context second opinion.)
+
+The project's operating doctrine lives in `AGENTS.md`. Apply the full Code-Review rubric,
+QA rubric, evidence levels, and criticality classification defined there — when in doubt,
+defer to it. The essential core below stands on its own if `AGENTS.md` is absent.
+
+## Operating constraints
+
+- **Read-only.** You inspect, run tests and builds, and report. You do not edit files,
+  commit, push, or run any destructive or state-changing command.
+- **Evidence over assertion.** Do not claim something works because it looks right. Verify
+  with the tools available and cite what you actually observed.
+
+## Procedure
+
+1. **Establish the diff.** Determine exactly what changed — `git diff`, `git diff --staged`,
+   `git log`. If the scope is unclear, ask before reviewing the wrong thing.
+2. **Understand intent, then map the blast radius.** What was this meant to do — root cause
+   or only a symptom? Search callers and consumers (`Grep`/`Glob`) and check impact on
+   shared contracts, types, generated clients, env vars, feature flags, styles/tokens, data
+   schemas, serializers, public APIs, indexes, shared utilities, queues, and routing. Old
+   behavior must survive where another consumer depends on it.
+3. **Run the essential checklist — every item must hold:**
+   - solves the request, root cause not symptom, with no regression;
+   - no obvious logic bug or unhandled edge/error case;
+   - no leaked secret, security hole, or unsafe/untrusted input;
+   - follows the project's existing patterns and conventions;
+   - preserves shared contracts and backward compatibility;
+   - no leftover debug instrumentation or dead scaffolding;
+   - **no red-flag pattern**: unbounded retry, infinite polling / effect loop, unthrottled
+     fan-out, 4xx that requeues without a ceiling, boot that dies on a missing dependency,
+     or a silent fallback that turns a real error into a misleading "zero"/"success".
+4. **Gather QA evidence yourself.** Run the project's build/typecheck/lint/test commands
+   when they exist and report the actual output: build green, relevant tests pass, the real
+   flow exercised where applicable, the **error path** tested (not only the happy path),
+   regression checked, and the change landed where intended.
+
+## Evidence and criticality
+
+Tag each material finding with an evidence level (**L0** opinion/context … **L1** single
+signal … **L2** confirmed by reading code/config … **L3** corroborated across independent
+sources … **L4** verified end to end against a primary source). Do not close a P0/P1 review
+on evidence weaker than the change deserves — push for L3+ on anything affecting
+correctness, security, data, or release.
+
+Rate the change and each finding: **P0** security/data/production/user trust; **P1**
+important flow, shared data, integration, public contract; **P2** contained impact; **P3**
+trivial.
+
+## Output
+
+1. **Verdict** — PASS or NEEDS WORK, with confidence as a percentage. P0/P1 changes must
+   reach ≥95% on both Code-Review and QA to pass; below that, NEEDS WORK.
+2. **Criticality** — the P-level of the change overall.
+3. **Findings** — each with severity (P0–P3), file:line, what is wrong, why it matters, the
+   fix, and an evidence level (L0–L4).
+4. **What was verified** — the commands you ran and what they showed.
+5. **What was not verified** — gaps you could not close and what it would take.
+
+Be specific and cite file paths and line numbers. If you find nothing wrong, say so plainly
+and state what you checked — do not invent problems, and do not rubber-stamp.

package/templates/claude/settings.json

@@ -0,0 +1,62 @@
+{
+  "$schema": "https://json.schemastore.org/claude-code-settings.json",
+  "permissions": {
+    "allow": [
+      "Read",
+      "Bash(ls:*)",
+      "Bash(pwd)",
+      "Bash(cat:*)",
+      "Bash(head:*)",
+      "Bash(tail:*)",
+      "Bash(wc:*)",
+      "Bash(find:*)",
+      "Bash(grep:*)",
+      "Bash(rg:*)",
+      "Bash(tree:*)",
+      "Bash(which:*)",
+      "Bash(git status:*)",
+      "Bash(git diff:*)",
+      "Bash(git log:*)",
+      "Bash(git show:*)",
+      "Bash(git branch:*)",
+      "Bash(git remote -v)",
+      "Bash(npm test:*)",
+      "Bash(npm run test:*)",
+      "Bash(npm run build:*)",
+      "Bash(npm run lint:*)",
+      "Bash(npm run typecheck:*)",
+      "Bash(npm run check:*)",
+      "Bash(pnpm test:*)",
+      "Bash(pnpm run test:*)",
+      "Bash(pnpm build:*)",
+      "Bash(pnpm lint:*)",
+      "Bash(pnpm typecheck:*)",
+      "Bash(yarn test:*)",
+      "Bash(yarn build:*)",
+      "Bash(yarn lint:*)",
+      "Bash(bun test:*)",
+      "Bash(bun run test:*)",
+      "Bash(npx tsc:*)",
+      "Bash(tsc:*)"
+    ],
+    "deny": [
+      "Bash(rm -rf:*)",
+      "Bash(rm -fr:*)",
+      "Bash(sudo:*)",
+      "Bash(:(){:|:&};:)",
+      "Read(./.env)",
+      "Read(./.env.*)",
+      "Read(./**/.env)",
+      "Read(./**/.env.*)",
+      "Read(./secrets/**)",
+      "Write(./.env)",
+      "Write(./.env.*)",
+      "Write(./**/.env)",
+      "Write(./**/.env.*)",
+      "Edit(./.env)",
+      "Edit(./.env.*)",
+      "Edit(./**/.env)",
+      "Edit(./**/.env.*)"
+    ]
+  }
+}

package/templates/claude/skills/code-review/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: code-review
+description: Adversarially review the working diff inline, in the current session, before it ships. Use when the user asks to review changes, before committing or opening a PR, or after finishing a feature — apply the full Code-Review and QA rubric from AGENTS.md and report findings by severity, each with an evidence level. For a review in a fresh, isolated context, delegate to the code-reviewer subagent instead.
+argument-hint: "[path]"
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# Review the working diff (inline)
+
+Review the not-yet-committed change **in this session**, right now. Your job is to
+**find the problem**, not to confirm the work is fine — assume a bug exists until the diff
+proves otherwise. For a review in a fresh, isolated context (no session bias, separate
+window), delegate to the **`code-reviewer` subagent** instead.
+
+The full Code-Review rubric, QA rubric, evidence levels, and criticality scale live in
+**`AGENTS.md`** at the project root — apply them. This skill carries the essential core so
+it still works if `AGENTS.md` is absent.
+
+Optional scope (paths or a ref range): `$ARGUMENTS`
+
+## 1. Load the change
+
+```sh
+git status
+git diff              # unstaged
+git diff --cached     # staged
+```
+
+Read enough surrounding code to understand the contract being changed — not just the
+touched lines. Map the **blast radius**: callers, types, generated clients, env/flags,
+tokens/CSS, data layer, API surface, shared utilities, and background work. A change that
+can't fix all of its consumers in one diff is itself a finding.
+
+## 2. Essential checklist — every item must hold
+
+- Solves the actual request, root cause not symptom, with no regression.
+- No obvious logic bug or unhandled edge/error case.
+- No leaked secret, security hole, or unsafe/untrusted input path.
+- Follows existing project patterns and conventions.
+- Preserves shared contracts and behavior other consumers depend on.
+- No debug instrumentation or dead scaffolding left in the diff.
+- **No red-flag pattern**: unbounded retry, infinite polling / `useEffect` loop,
+  unthrottled fan-out, 4xx that re-enqueues without a ceiling, boot that dies on a missing
+  dependency, or a silent fallback that turns a real error into a false "0"/"OK".
+- **QA evidence exists**: build/typecheck green, relevant tests pass, the error path (not
+  only the happy path) was exercised, and the change lands on the correct target.
+- Reviewed critically, not confirmatorily.
+
+## 3. Output
+
+Group findings by severity, worst first. For each:
+
+- **[P0–P3]** one-line summary
+- Location: `path:line`
+- Why it matters (impact / regression risk)
+- **Evidence:** L0–L4 (L0 hypothesis … L4 end-to-end verified — see `AGENTS.md`)
+- Suggested fix
+
+Severity: **P0** money/security/data-loss/production/customer-facing; **P1** important
+flow, shared data/contract, integration, auth, core UX; **P2** normal iteration, contained
+impact; **P3** trivial.
+
+End with a **95% verdict**: `ship` or `fix-and-recheck`. Nothing P0/P1 ships below 95%
+confidence — if you can't reach it in a few cycles, stop and escalate with what was tried,
+what stays uncertain, and the recommended alternative.