@bigsteele/the-big-sean 0.1.0

package/README.md

@@ -0,0 +1,53 @@
+# @bigsteele/the-big-sean
+
+**The Big Sean** — the Launch Report Card. A collaboration between **Big Steele** and
+**LaSean Pickens**.
+
+Point it at an app and it grades two things at once: **can this take customers without
+hurting them** (launch readiness, L01–L15, sixty checks) and **can it run the business
+without you** (autonomy, D01–D20, eighty checks, rubric KALDR-AUTONOMY-1.0). One hundred
+forty checks, every one PASS, FAIL, UNKNOWN, or N/A with evidence attached — no partial
+credit, no "mostly works." The output is a report card: a verified score out of 100, a
+band, a ceiling, gate status, category cards, the path to 100, and every finding cited to
+a file and line, a query, or a page.
+
+The audit itself is run by Claude Code against your repo and, where reachable, your live
+system — read-only, no edits, no questions, nothing spent. This package ships the
+protocol and the tools around it:
+
+```
+npx @bigsteele/the-big-sean            # drop THE-BIG-SEAN.md into the repo, paste it into Claude Code
+npx @bigsteele/the-big-sean --run      # or open claude with the protocol already loaded
+npx @bigsteele/the-big-sean --check    # after the audit: re-compute the report's math yourself
+npx @bigsteele/the-big-sean --stdout   # print the protocol
+```
+
+## Prove the number
+
+The protocol makes the auditing agent write its own validator and show its math. `--check`
+is the second opinion: it reads `.planning/launch-audit/grade.json` (or any file you point
+it at) and re-computes everything by the same rules, implemented independently here:
+
+- Only PASS, FAIL, UNKNOWN, N/A. A PASS or FAIL with zero evidence entries is rejected.
+  An N/A without a reason is rejected. A check that was never given a written test is
+  rejected. If the file is rejected, fix the grade.json, not the validator.
+- Total possible = the weights of every check that is not N/A. **Verified** = PASS points
+  as a percentage of that — the headline. **Ceiling** = PASS + UNKNOWN. **Coverage** =
+  PASS + FAIL. Bands: A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, F below.
+- Gates: any weight-5 FAIL is **LAUNCH BLOCKED** regardless of score. Any weight-5
+  UNKNOWN is **NOT VERIFIED FOR LAUNCH**. A report with unknowns is **INCOMPLETE** and
+  says so next to its number.
+
+Exit codes from `--check`: 0 gates clear, 2 blocked or not verified, 1 rejected file.
+
+## What the audit never does
+
+Read-only, by contract: no edits to source, config, migrations, dependencies, database,
+or any connected service. No commits, branches, deploys, messages, or spending. It never
+prints a secret or a customer's personal data, and it never says "production ready" — it
+says what it verified and what it did not.
+
+## The name
+
+Big Steele wrote the machine. LaSean Pickens wrote the standard. The Big Sean is what
+happens when an app has to face both.

package/dist/check.js

@@ -0,0 +1,175 @@
+/** The Big Sean — the independent scorer (Launch Report Card, Step 5).
+ *
+ *  The protocol makes the auditing agent write score.mjs and prove its own
+ *  math. This module is the second opinion: the same rules, implemented
+ *  once, here, so any grade.json can be re-scored without trusting the
+ *  agent that produced it. If the two disagree, believe this one and fix
+ *  the grade.json, never the validator.
+ *
+ *  PURE MODULE: no filesystem, no process. The CLI feeds it parsed JSON.
+ */
+const STATUSES = new Set(["PASS", "FAIL", "UNKNOWN", "N/A"]);
+export function band(score) {
+    if (score >= 90)
+        return "A";
+    if (score >= 80)
+        return "B";
+    if (score >= 70)
+        return "C";
+    if (score >= 60)
+        return "D";
+    return "F";
+}
+const r1 = (n) => Math.round(n * 10) / 10;
+/** grade.json arrives in whatever wrapper the agent chose; the records are
+ *  what matters. Accepts a bare array, {records}, {checks}, {controls}. */
+export function extractRecords(raw) {
+    if (Array.isArray(raw))
+        return raw;
+    if (typeof raw === "object" && raw !== null) {
+        const o = raw;
+        for (const key of ["records", "checks", "controls", "grades"]) {
+            if (Array.isArray(o[key]))
+                return o[key];
+        }
+    }
+    return [];
+}
+function categoryOf(rec) {
+    const dep = typeof rec.department === "string" ? rec.department : "";
+    const fromDep = dep.match(/^([LD]\d{2})/i)?.[1];
+    if (fromDep)
+        return fromDep.toUpperCase();
+    const fromId = String(rec.id ?? "").match(/^([LD]\d{2})/i)?.[1];
+    if (fromId)
+        return fromId.toUpperCase();
+    return dep || "uncategorized";
+}
+/** Step 5 validation, verbatim rules: only the four statuses; a PASS or
+ *  FAIL with zero evidence entries is rejected; an N/A without a reason is
+ *  rejected; a check that was never given a written test is rejected. */
+export function validate(records) {
+    const problems = [];
+    if (records.length === 0)
+        problems.push("no check records found in grade.json");
+    const seen = new Set();
+    for (const rec of records) {
+        const id = String(rec.id ?? "(missing id)");
+        if (seen.has(id))
+            problems.push(`${id}: duplicate check id`);
+        seen.add(id);
+        if (!STATUSES.has(String(rec.status)))
+            problems.push(`${id}: status "${rec.status}" is not PASS, FAIL, UNKNOWN, or N/A`);
+        const w = Number(rec.weight);
+        if (w !== 3 && w !== 5)
+            problems.push(`${id}: weight ${rec.weight} is not 3 or 5`);
+        const evidence = Array.isArray(rec.evidence) ? rec.evidence.filter((e) => e !== null && e !== "") : [];
+        if ((rec.status === "PASS" || rec.status === "FAIL") && evidence.length === 0) {
+            problems.push(`${id}: ${rec.status} with zero evidence entries`);
+        }
+        if (rec.status === "N/A" && !String(rec.naReason ?? rec.reason ?? "").trim()) {
+            problems.push(`${id}: N/A without a reason`);
+        }
+        const test = String(rec.retest ?? rec.test ?? "").trim();
+        if (!test)
+            problems.push(`${id}: no written test (a check that was never given a test is UNKNOWN, never PASS)`);
+    }
+    return problems;
+}
+function rubric(records) {
+    const applicable = records.filter((c) => c.status !== "N/A");
+    const possible = applicable.reduce((s, c) => s + c.weight, 0);
+    if (possible === 0)
+        return null;
+    const pts = (statuses) => applicable.filter((c) => statuses.includes(c.status)).reduce((s, c) => s + c.weight, 0);
+    const verified = r1((pts(["PASS"]) / possible) * 100);
+    return {
+        possible,
+        verified,
+        ceiling: r1((pts(["PASS", "UNKNOWN"]) / possible) * 100),
+        coverage: r1((pts(["PASS", "FAIL"]) / possible) * 100),
+        band: band(verified),
+        incomplete: applicable.some((c) => c.status === "UNKNOWN"),
+    };
+}
+/** Score a validated set of records: combined, per rubric (L / D), per
+ *  category, and the gates. Never call on records that failed validate() —
+ *  the protocol says fix the grade.json, not the validator. */
+export function score(records) {
+    const problems = validate(records);
+    const counts = { PASS: 0, FAIL: 0, UNKNOWN: 0, "N/A": 0, total: records.length };
+    for (const c of records)
+        if (STATUSES.has(c.status))
+            counts[c.status] += 1;
+    if (problems.length > 0) {
+        return { ok: false, problems, counts, combined: null, launch: null, autonomy: null, categories: [], gate: null };
+    }
+    const cats = new Map();
+    for (const c of records) {
+        const k = categoryOf(c);
+        cats.set(k, [...(cats.get(k) ?? []), c]);
+    }
+    const categories = [...cats.entries()].sort(([a], [b]) => (a < b ? -1 : 1)).map(([category, recs]) => {
+        const s = rubric(recs);
+        const st = { PASS: 0, FAIL: 0, UNKNOWN: 0, "N/A": 0 };
+        for (const c of recs)
+            st[c.status] += 1;
+        return {
+            category,
+            possible: s?.possible ?? 0,
+            passPts: recs.filter((c) => c.status === "PASS").reduce((x, c) => x + c.weight, 0),
+            verified: s?.verified ?? null,
+            ceiling: s?.ceiling ?? null,
+            coverage: s?.coverage ?? null,
+            band: s ? s.band : null,
+            statuses: st,
+        };
+    });
+    const isGateWeight = (c) => c.weight === 5 || c.critical === true;
+    const blockers = records.filter((c) => isGateWeight(c) && c.status === "FAIL").map((c) => c.id);
+    const unproven = records.filter((c) => isGateWeight(c) && c.status === "UNKNOWN").map((c) => c.id);
+    const gate = {
+        status: blockers.length > 0 ? "LAUNCH BLOCKED" : unproven.length > 0 ? "NOT VERIFIED FOR LAUNCH" : "GATES CLEAR",
+        blockers,
+        unproven,
+    };
+    return {
+        ok: true,
+        problems: [],
+        counts,
+        combined: rubric(records),
+        launch: rubric(records.filter((c) => categoryOf(c).startsWith("L"))),
+        autonomy: rubric(records.filter((c) => categoryOf(c).startsWith("D"))),
+        categories,
+        gate,
+    };
+}
+/** "Show the math", printable: the sums, the divisions, per category and
+ *  overall — the same section the protocol requires in the report card. */
+export function showTheMath(res) {
+    const L = [];
+    if (!res.ok) {
+        L.push(`grade.json REJECTED (${res.problems.length} problem${res.problems.length === 1 ? "" : "s"}). Fix the grade.json, not the validator.`);
+        for (const p of res.problems)
+            L.push(`  - ${p}`);
+        return L.join("\n");
+    }
+    const line = (label, s) => {
+        if (!s)
+            return `${label}: no applicable checks`;
+        return `${label}: verified ${s.verified}${s.incomplete ? " INCOMPLETE" : ""} (${s.band})   ceiling ${s.ceiling}   coverage ${s.coverage}   possible ${s.possible} pts`;
+    };
+    L.push("THE BIG SEAN — show the math");
+    L.push(line("Combined", res.combined));
+    L.push(line("Launch readiness (L)", res.launch));
+    L.push(line("Autonomy (D)", res.autonomy));
+    L.push(`Checks: ${res.counts.PASS} PASS, ${res.counts.FAIL} FAIL, ${res.counts.UNKNOWN} UNKNOWN, ${res.counts["N/A"]} N/A of ${res.counts.total}`);
+    const g = res.gate;
+    L.push(`Gates: ${g.status}${g.blockers.length ? " — blocked by " + g.blockers.join(", ") : ""}${g.unproven.length ? " — unproven: " + g.unproven.join(", ") : ""}`);
+    L.push("");
+    L.push("category   verified   ceiling   coverage   pass/fail/unknown/na");
+    for (const c of res.categories) {
+        L.push(`${c.category.padEnd(10)} ${String(c.verified ?? "-").padStart(8)}   ${String(c.ceiling ?? "-").padStart(7)}   ${String(c.coverage ?? "-").padStart(8)}   ${c.statuses.PASS}/${c.statuses.FAIL}/${c.statuses.UNKNOWN}/${c.statuses["N/A"]}`);
+    }
+    return L.join("\n");
+}

package/dist/cli.js

@@ -0,0 +1,96 @@
+#!/usr/bin/env node
+// big-sean [dir]              write THE-BIG-SEAN.md into <dir> (default .) and say what to do next
+// big-sean --stdout           print the protocol (pipe it wherever you like)
+// big-sean --run [dir]        launch the `claude` CLI in <dir> with the protocol as the opening prompt
+// big-sean --check [file]     re-score a finished audit's grade.json (default .planning/launch-audit/grade.json)
+//
+// --check exits 0 on GATES CLEAR, 2 on LAUNCH BLOCKED or NOT VERIFIED FOR LAUNCH,
+// 1 when the grade.json is rejected. Everything else exits 0 on success.
+import { spawn } from "node:child_process";
+import { readFile, writeFile } from "node:fs/promises";
+import { join, resolve } from "node:path";
+import { extractRecords, score, showTheMath } from "./check.js";
+import { loadPrompt } from "./index.js";
+const HELP = `The Big Sean — the Launch Report Card. Big Steele × LaSean Pickens.
+
+  big-sean [dir]           drop THE-BIG-SEAN.md into the repo (default: here)
+  big-sean --stdout        print the protocol
+  big-sean --run [dir]     open claude with the protocol as the opening prompt
+  big-sean --check [file]  re-score a report's grade.json and show the math
+                           (default: .planning/launch-audit/grade.json)`;
+export async function main(argv, log = console.log, err = console.error) {
+    let dir = ".";
+    let mode = "write";
+    let checkTarget = null;
+    for (let i = 0; i < argv.length; i++) {
+        const a = argv[i];
+        if (a === "--stdout")
+            mode = "stdout";
+        else if (a === "--run")
+            mode = "run";
+        else if (a === "--check") {
+            mode = "check";
+            const next = argv[i + 1];
+            if (next && !next.startsWith("--"))
+                checkTarget = argv[++i] ?? null;
+        }
+        else if (a === "--help" || a === "-h") {
+            log(HELP);
+            return 0;
+        }
+        else if (a && !a.startsWith("--"))
+            dir = a;
+    }
+    const root = resolve(dir);
+    if (mode === "check") {
+        const file = resolve(checkTarget ?? join(root, ".planning", "launch-audit", "grade.json"));
+        let raw;
+        try {
+            raw = JSON.parse(await readFile(file, "utf8"));
+        }
+        catch (e) {
+            err(`Could not read ${file}: ${e.message}`);
+            err(`Run the audit first (big-sean --run), or point --check at the grade.json.`);
+            return 1;
+        }
+        const res = score(extractRecords(raw));
+        log(showTheMath(res));
+        if (!res.ok)
+            return 1;
+        return res.gate.status === "GATES CLEAR" ? 0 : 2;
+    }
+    const prompt = await loadPrompt();
+    if (mode === "stdout") {
+        log(prompt);
+        return 0;
+    }
+    if (mode === "run") {
+        log(`The Big Sean: opening claude with the Launch Report Card. Read-only audit; it changes nothing.`);
+        const child = spawn("claude", [prompt], { cwd: root, stdio: "inherit" });
+        return await new Promise((resolvePromise) => {
+            child.on("error", async () => {
+                err(`Could not start the claude CLI. Writing the protocol instead.`);
+                resolvePromise(await writeProtocol(root, log));
+            });
+            child.on("exit", (code) => resolvePromise(code ?? 0));
+        });
+    }
+    return writeProtocol(root, log);
+}
+async function writeProtocol(root, log) {
+    const file = join(root, "THE-BIG-SEAN.md");
+    await writeFile(file, await loadPrompt(), "utf8");
+    log(`Wrote ${file}`);
+    log(``);
+    log(`Next: open Claude Code in this folder and paste the whole file in (or run big-sean --run).`);
+    log(`When it finishes, the report card opens itself. Then prove the number:`);
+    log(`  big-sean --check`);
+    return 0;
+}
+const entry = process.argv[1] ?? "";
+if (/cli\.(js|ts)$/.test(entry) || /big-sean$/.test(entry)) {
+    main(process.argv.slice(2)).then((code) => process.exit(code), (e) => {
+        console.error(e instanceof Error ? e.message : String(e));
+        process.exit(1);
+    });
+}

package/dist/index.js

@@ -0,0 +1,10 @@
+export { band, extractRecords, score, showTheMath, validate } from "./check.js";
+import { readFile } from "node:fs/promises";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+/** The Launch Report Card protocol, verbatim — the thing you paste into
+ *  Claude Code. Ships inside the package; the CLI writes or prints it. */
+export async function loadPrompt() {
+    const here = dirname(fileURLToPath(import.meta.url));
+    return readFile(join(here, "..", "prompt", "THE-BIG-SEAN.md"), "utf8");
+}

package/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "@bigsteele/the-big-sean",
+  "version": "0.1.0",
+  "description": "The Big Sean: the Launch Report Card, by Big Steele and LaSean Pickens. Drops a 140-check launch-readiness and autonomy audit protocol into a repo for Claude Code to run, and independently re-computes any report's math from its grade.json so the number on the card can be proven, not trusted.",
+  "type": "module",
+  "license": "UNLICENSED",
+  "author": "Big Steele (Together Inc.) and LaSean Pickens",
+  "homepage": "https://bigsteele.com",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/bigsteele/blank-canvas-project.git",
+    "directory": "packages/the-big-sean"
+  },
+  "bin": {
+    "big-sean": "dist/cli.js"
+  },
+  "files": [
+    "dist",
+    "prompt",
+    "README.md"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "scripts": {
+    "build": "rm -rf dist && tsc -p tsconfig.json",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "test": "vitest run",
+    "prepublishOnly": "npm run build && npm test"
+  },
+  "devDependencies": {
+    "@types/node": "^22.10.0",
+    "typescript": "^5.7.0",
+    "vitest": "^3.0.0"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

package/prompt/THE-BIG-SEAN.md

@@ -0,0 +1,353 @@
+# THE BIG SEAN — Launch Report Card
+
+A collaboration between Big Steele and LaSean Pickens.
+
+Paste this whole thing into Claude Code (or Claude Cowork) inside your app's folder. Type nothing else. When it finishes, your report card opens by itself.
+
+You are a senior software auditor. Grade this app on two things: is it ready for beta launch (reliable, safe, secure, usable, able to take load) and is it autonomous (able to run the business without the owner or the customer's staff after onboarding, inside explicit policies). Both are primary. Neither is optional. Do not fix anything. Do not change anything. Do not ask me questions. Discover everything yourself, grade it, and give me a full report card with a score out of 100, a score for every category, why each category scored what it scored, exactly what to change, and the order to do it in.
+Rules you never break:
+	•	Read only. No edits to source, config, migrations, dependencies, database, or any connected service. No commits, no branches, no deploys, no messages sent, no money spent. The only thing you create is the report folder .planning/launch-audit/.
+	•	Never invent. Every claim points to a file and line, a query you ran, a command output, or a page you loaded. If you could not check something, say UNKNOWN and say why. UNKNOWN is not a fail and it is not a pass.
+	•	Reading a file is not proof it works. A migration in the repo is not proof it is applied. A cron in a config is not proof it fires. A test file is not proof the test runs. A "done" checkbox in a planning doc is not proof of anything.
+	•	Never print a secret, a token, a password, or a customer's personal data anywhere.
+	•	Never say "100% bug-free" or "production ready." Say what you verified and what you did not.
+Step 1. Find out what you can reach (no setup from me)
+Look for what is already on this machine and use it read-only. Do not ask me for anything.
+	•	Env files (.env, .env.local, .env.production, .env.example) for the names of services in use and any database URL, Supabase URL and keys, provider keys. Use keys only for read operations.
+	•	Logged-in CLIs: supabase, vercel, gh, stripe, fly, railway, netlify, wrangler. Run only list, status, inspect, and read subcommands.
+	•	Composio, if it is connected in this session (it usually is): use its Supabase tools for every database read (list projects, pick the one whose URL matches the env file, then the read-only query tool for row counts, RLS, policies, grants, functions, cron run logs, migration history; list edge functions and secrets by name) and its GitHub tools for the repo, branches, workflow runs, branch protection, and the deployed tag. Use its Vercel, Stripe, Sentry, or PostHog tools too when connected, read operations only. Composio is the preferred path because it needs nothing installed; fall back to local CLIs only when a Composio tool is missing.
+	•	Any other MCP servers or database tools already available to you in this session.
+	•	Package manifests, lockfiles, framework config, CI files, deploy config, Docker files, infrastructure-as-code.
+	•	The running app: if a dev server or a deployed URL is discoverable, load pages read-only.
+The access ladder. For every system, climb every rung before you write UNKNOWN. Use whichever rung works first, record the rung in SOURCES.md, and keep every operation read-only regardless of which rung got you in.
+	•	Database (Supabase or Postgres): 1 Composio Supabase tools (find the project whose URL matches the env file, run the read-only query tool); 2 a Supabase MCP server in this session; 3 supabase CLI already logged in, or logged in non-interactively with SUPABASE_ACCESS_TOKEN from the env, then supabase db read commands and the Management API query endpoint for SQL; 4 a direct DATABASE_URL, POSTGRES_URL, or SUPABASE_DB_URL in the env through psql or a Node pg client, SELECT only; 5 the project URL plus the service role key from the env, used only for catalog and metadata reads (policies, grants, functions, cron run logs, migration history), never for business writes; 6 the anon key plus a test login through PostgREST for the isolation test. If none of the six work, the database is UNKNOWN with the rung-by-rung failure recorded.
+	•	Repository and CI: 1 Composio GitHub tools; 2 gh CLI logged in; 3 GITHUB_TOKEN or GH_TOKEN in the env; 4 the local git checkout (history, branches, tags) which is always available; workflow runs and branch protection are UNKNOWN only if rungs 1 to 3 all fail.
+	•	Deployment (Vercel, Netlify, Fly, Railway, Cloudflare, Render): 1 Composio tools for that host; 2 the host's CLI logged in; 3 the host's token in the env (VERCEL_TOKEN, NETLIFY_AUTH_TOKEN, FLY_API_TOKEN, RAILWAY_TOKEN, CLOUDFLARE_API_TOKEN, RENDER_API_KEY); 4 the public production URL, loaded read-only, for served commit headers, security headers, robots, sitemap, and page behavior.
+	•	Payments (Stripe, Square): 1 Composio; 2 CLI logged in; 3 a restricted or secret key in the env used only for GET endpoints (webhook endpoints, products, prices, recent events); 4 UNKNOWN.
+	•	Monitoring and analytics (Sentry, PostHog, Datadog, LogRocket): 1 Composio; 2 MCP; 3 an API token in the env, GET only; 4 the SDK config in code plus a live page load to see whether events fire (network tab or SDK debug), which proves wiring but not receipt; 5 UNKNOWN.
+	•	Messaging and voice (Twilio, Resend, SendGrid, Vapi, Telegram): 1 Composio; 2 API keys in the env, GET only (registered webhooks, sender status, recent deliveries); 3 UNKNOWN.
+	•	Any other provider named in the env or the code: same order, Composio, MCP, CLI, token, public surface, UNKNOWN.
+Never ask me to connect something. If a rung needs a login prompt, skip it. If a rung would write, skip it.
+Write a table SOURCES.md: every system you found, the rung that got you in (or every rung that failed), whether you could reach it live or only in code, and what you could not reach. This table is the first thing on the report card. If you reached nothing live, the report is titled CODE-ONLY REPORT CARD and every live-dependent category is marked UNKNOWN with the reason. Never pretend a code read was a live check.
+PART A. LAUNCH READINESS
+Step 2. Learn the app
+Read the planning docs, README, specs, and any state files first. Then read the real code: every route, page, API handler, server action, edge or serverless function, worker, cron, webhook, database migration, policy, trigger, function, storage rule, and integration. Trace the main user journeys end to end: sign up, first value, the core workflow of this product, pay, cancel, delete account, get support. Trace the owner's journeys: onboarding a customer, seeing what happened, handling a failure, getting paid. Write WHAT-THIS-APP-DOES.md: what it is, who uses it, the money flows, the external services, the background jobs, and the workflows that must work for a customer to pay and stay.
+Step 3. Check the live system where you can (all read-only)
+Where the database is reachable:
+	•	Every table with its row count. Flag tables that are empty but should have content (an academy with no lessons, a pricing table with no rows, a policies table with no current version).
+	•	Row Level Security: is it enabled and forced on every table with customer data, and what does every policy actually allow? Watch the trap where every user shares one tenant id so a "same tenant" policy isolates nobody. Reads that go through a service or admin key bypass RLS and hide holes. If test accounts exist in the env files, sign in as an ordinary user and prove you only see that user's rows and zero rows on admin tables. If no test accounts exist and this is a dev or staging database, sign up two throwaway accounts through the app's own signup and run the same check; if it is production, do not create anything, mark the isolation test UNKNOWN, and write the exact steps to run it later.
+	•	Functions with SECURITY DEFINER (they bypass RLS unless they check the caller themselves).
+	•	Migrations in the repo versus migrations recorded as applied in the database.
+	•	Cron jobs, and whether each one actually ran recently (the run log, not the schedule).
+	•	Storage buckets and their policies.
+	•	Extensions and versions.
+Where the deployment is reachable: the commit being served versus the latest on the main branch, the environment variable names set versus the names the code reads, the domains, the cron registrations, the deployed functions versus the ones in the repo.
+Where providers are reachable: registered webhooks and their URLs versus the routes in the code, error monitoring receiving events, analytics receiving events, payment products and prices matching the app.
+Run the app's own checks if they exist and are safe: typecheck, lint, tests, production build. Never run anything that writes to a database or sends anything.
+Step 4. Test like an attacker and like a confused customer
+Through code reading and, where a safe environment is reachable, through real requests:
+	•	Does every route that changes data check who the user is and whether they own the thing? Not just "logged in."
+	•	Can a request skip a step, repeat a step, replay an old request, send a forged id, submit stale state, or send two at once and corrupt something?
+	•	Are inputs validated on every API route, form, and webhook? Are webhooks signature-checked? Are duplicate and out-of-order webhooks handled?
+	•	Are secrets out of the repo and out of the browser bundle? Are security headers and a real content security policy set? Do error messages leak internals?
+	•	Are auth, public, and money-costing endpoints rate limited?
+	•	Money: integer cents, idempotency keys, server-side entitlement checks, no client-side secrets. If there is no money in this app, say so instead of inventing findings.
+	•	What happens when a provider times out, returns an error, or the worker dies mid-job? Does the app fail safely and avoid double effects?
+	•	Consent: is consent captured with a timestamp and a version at signup, checked again before any message goes out, and is there an unsubscribe that actually stops sends? Are terms and privacy reachable inside the app? Is there a delete-my-account path?
+	•	Usability: walk the golden path for each type of user. Dead buttons, links to nowhere, "coming soon" pretending to be live, missing empty and error and loading states, placeholder text, lorem, TODOs visible, debug pages public, broken on mobile width.
+	•	Load: find the heaviest and most frequent operations. If a safe non-production environment is reachable, run a modest load test and report p50, p95, p99, error rate, and the number you actually tested. If not, mark UNKNOWN and write the exact test to run.
+	•	Autonomy: can this app run a normal day, week, and month without the owner opening a dashboard and without the customer's staff babysitting it? Which duties still need a human, and is that by design or by omission? Do the full protocol in Step 4A, not a paragraph.
+Step 4A. The autonomy protocol (this is the primary test, not a side note)
+The question is: after a customer is onboarded, can this software run the business without the owner and without the customer's staff, inside its policies? Answer it with an inventory and a simulation, never with an impression.
+	•	Responsibility inventory. Build it the way Part B section B4 specifies (that section is the authority; this is the summary). From the code, the specs, and the domain, list every duty this product is responsible for on both planes. Platform and owner: signups, provisioning, integrations, entitlements, billing, payment recovery, support, releases, backups, cost control, fleet reporting. Tenant and customer: lead capture, qualification, scheduling if the product sells time, inbox and voice if present, follow-up, campaigns, quotes or proposals, agreements, the vertical's core delivery workflow, invoicing, payment status, aftercare, reviews, referrals, reactivation, support, staff exceptions, knowledge updates, reporting. Include time-triggered duties that have no screen (reminders, renewals, expiries, cleanup, reconciliation). Do not invent duties this product does not have; mark them not applicable with the reason. Write WORKFLOW-COVERAGE.md: one row per duty with ID, plane, trigger, what runs it today (a human, a cron, a producer, a webhook, nothing), current status (RUNNING unattended, RUNNING with approval, WRITTEN not running, MISSING, BLOCKED by an external constraint, PHYSICAL or CUSTOMER-CHOICE by nature), the evidence, and what would make it unattended.

+	•	Counts, both denominators. Total duties. Then: automated unattended, approval-dependent, written but not running, missing, blocked externally, physical or customer-choice, unknown. Report the automated count against the total AND against the software-executable subset (total minus physical, customer-choice, and legally reserved). Both numbers go on the summary card.

+	•	Authority check. For every duty that runs without a human, find the deterministic check outside the model that authorizes it: tenant membership, entitlement, tool scope, ownership, policy version, budget, consent, timing. A model's confidence is not authorization. Find the receipt for each action (proposal, policy decision, execution, outcome, cost as linked records). Find the kill switch per workflow, per tenant, and fleet-wide, and prove it reaches queued jobs. Find the budget reservation and prove a split action cannot evade it.

+	•	The simulated unattended day. With the owner's dashboard closed and no staff logged in, using seeded fictional data in a non-production environment if one is reachable (otherwise trace it through code and mark the run UNKNOWN with the procedure): a new customer signs up and reaches first value; an ordinary day happens (a lead arrives, a booking or order is made, a reminder fires, a payment settles, a follow-up sends inside consent and quiet hours); a recurring duty fires on schedule; an exception happens (a payment fails, a provider times out, a customer replies STOP, a ticket arrives) and the software handles it or routes it with a receipt; the day ends with the owner's Telegram or digest showing what happened. Record every step where a human was needed. Then the week (renewals, weekly digest, reconciliation) and the month (invoicing, dunning, retention pass) from the cron registry and run logs.

+	•	Human work to remove. From the inventory, list every duty a human touches today, on each plane, tagged removable (software can do it inside policy), partial (software does most, a human click or provider review remains), or by design (money out, legal versions, merges, refunds, price changes stay human on purpose). This list is a required section of the report card.

+	•	Knowledge and learning. Does the product know the customer's business from ingested sources with provenance and version, or from typed notes only? Are embeddings actually populated and searched (row counts, a live query), or scaffolded? Do exact facts (prices, balances, schedules, permissions) come from typed queries, never from vectors? When a human corrects the software, is the correction stored with evidence and read by the next decision, with a test that proves the behavior changed? Are guesses ever promoted to facts? Does deleting a customer reach derived memories and embeddings?

+PART B. THE AUTONOMY AUDIT (rubric KALDR-AUTONOMY-1.0, in full)
+You are also my principal software architect, codebase auditor, database engineer, agent-systems engineer, reliability engineer, and skeptical verification lead. Your assignment in this part is to establish what this specific software actually does, identify every material dependency on the owner or the tenant's staff, and produce a complete dependency-ordered plan for removing automatable human work from both the platform side and the client side. Deliver a detailed evidence-based report and unapplied implementation specifications. Do not execute the proposed fixes.
+This is a product-specific investigation. Do not produce a generic SaaS checklist with the product name substituted. Work from the actual repository, applicable product specifications, connected infrastructure, and observed behavior. Include domain research to find missing responsibilities that the current codebase does not represent. Research identifies requirements; it does not prove implementation.
+INPUTS (all discovered, nothing typed by the owner)
+	•	MODE: AUDIT_AND_PLAN, locked. Report and planning artifacts only. No fixes or system changes.
+	•	TARGET: the current repository and its verified deployments. If multiple unrelated products are plausible, finish safe inventory, pick the one this folder is, and say so.
+	•	AUTONOMY OBJECTIVE: no routine platform-owner or tenant-staff interaction after onboarding, within explicit policies and external constraints.
+	•	REPORT DIRECTORY: .planning/launch-audit/ (the same folder as Part A).
+B0. START-TO-FINISH AUDIT AND REPORT CONTRACT
+MODE IS LOCKED TO AUDIT_AND_PLAN. This part authorizes investigation and creation of audit and planning artifacts only. It does not authorize fixes. No default, earlier session permission, legacy mode selector, detected vulnerability, or instruction later in this document may silently switch this run to implementation. Any later implementation is a separate task outside this audit.
+Run the whole assessment without asking for a mode switch: establish facts, map workflows, inspect code and read-only runtime evidence, run permitted non-mutating checks, grade departments, rank findings, design the complete target architecture, produce the dependency-ordered plan, review evidence and scoring, deliver the finished artifact. The deliverable is a detailed assessment and plan, not a modified application.
+WRITE BOUNDARY: create the report, evidence register, grade sheets, diagrams, proposed SQL and code examples, task plans, and scratch analysis files in the report directory only. Do not edit application source, tests, configuration, dependencies, lockfiles, migrations, or existing product instructions. Do not commit, push, create repair branches, PRs, or issues, install product dependencies, apply SQL changes, write business data, seed tenants in connected systems, backfill knowledge, promote trust, enable or disable jobs, change webhooks or credentials, send messages, spend money, deploy, undeploy, delete, or execute repairs. Merely identifying an urgent risk does not authorize containment changes: report the recommended containment and its urgency.
+Use read-only credentials where available. Inspect test scripts before execution. Run existing checks only when they cannot change application, infrastructure, or business state or cause external side effects. Disposable local analysis copies and isolated scratch test fixtures may support an audit, but no changes may be carried back to the application or connected environment. Do not claim a safe test ran if its environment is unavailable. Record it as UNKNOWN and provide the future execution procedure. Do not bypass required CI, access controls, or blocked services.
+The technical sections below describe what to inspect and what to specify in the proposed future system. Words such as build, implement, enforce, repair, migrate, configure, or deploy in a target-state requirement are planning requirements, never authorization to carry out that change during this run. Current-state evidence and future-state design must remain visibly separate throughout the artifact.
+When a dependency blocks evidence collection, finish all independent analysis and planning. Missing traffic, empty tables, blocked CI, missing legal inputs, or unavailable infrastructure do not justify omitting the architecture, onboarding plan, hazard inventory, acceptance specification, or roadmap. Fill supported content, label unresolved details, and link affected tasks. Do not invent facts to fill those gaps.
+Recover missing context from files, commits, and authorized sources. Preserve requirements and evidence before compaction. Continue until the complete report is delivered or an actual execution limit forces a checkpoint. Terminal states: REPORT_COMPLETE or REPORT_COMPLETE_WITH_EVIDENCE_GAPS. These certify delivery of the report only. They never certify product readiness. If interrupted or stopped, explicitly record INCOMPLETE and the continuation point.
+B1. TRUTH AND COMPLETION CONTRACT
+Never claim 100% autonomy because components exist, an agent answered, a build passed, or a plan is complete. A plan is not an implementation. Implementation is not a deployment. Deployment is not demonstrated operation. Demonstrated operation in a test window is not a guarantee about all future conditions.
+Distinguish FACT, OBSERVATION, VERIFIED REQUIREMENT, PROPOSAL, HYPOTHESIS, UNKNOWN, and BLOCKED. No hypothesis may be reported as an established cause or current capability. Do not invent tables, files, providers, endpoints, credentials, limits, costs, customer policies, or test results. Proposed objects may be named explicitly as proposed objects.
+For each current-state finding record: finding ID, timestamp and environment, exact repository commit, file and symbol or line references, applicable database objects, relevant deployment or version, sanitized command, query, or test evidence, expected behavior, observed behavior, impact, and reproducibility. Record contradictory evidence rather than choosing whichever source supports the desired conclusion.
+Use precise statuses: VERIFIED_WORKING, PRESENT_UNVERIFIED, PARTIAL, MISSING_CONFIRMED, BROKEN, BLOCKED_ACCESS, HUMAN_DEPENDENT, PROPOSED, and NOT_APPLICABLE_WITH_EVIDENCE. A failed search is not sufficient evidence of absence. Define the search scope and inspect alternate execution paths first.
+All changing vendor, API, or runtime claims require current official documentation, verified against installed and deployed versions, with retrieval dates. Never use model memory as the source of business facts. Engineering proposals may use general engineering knowledge, but must be labeled, justified against observed constraints, and tested before being called working.
+B2. ESTABLISH THE PROJECT AND ITS RULES
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Read applicable AGENTS.md, CLAUDE.md, README, manifests, lockfiles, product state, specifications, architectural decisions, feature ledgers, wiring maps, migrations, CI, and deployment configuration. Establish the existing build stage. Do not reset a mature product to a new-project scaffold.
+For Kaldr work, retrieve github.com/DreTheGeek/kaldr-core (doctrine/kaldr-build-system) read-only if it is reachable, and read its current SKILL.md, STATE.md, and the standards relevant to autonomy, knowledge, smart systems, AI staff, operations, observability, self-healing, security, money, tenancy, learning, and verification. Load applicable referenced skills. Keep methodology generation, package version, and repo release identifiers separate. If access is unavailable, disclose exactly what cannot be verified and continue the independent evidence collection that is possible.
+Follow the applicable sequence: Research, Discovery, Design Brief, Blueprint, Series Outline, Wiring Map, PRDs, Launch Gates, Operations. Reuse valid existing artifacts, produce explicit deltas for changes, and do not skip unmet gates. No unsolicited redesign. If visual changes are required, use approved references and the project's design process.
+Identify whether this is an owned product or client-owned code. Preserve repository, account, intellectual property, billing, and data ownership. Do not reuse another client's private code without authorization. For authorized Kaldr reuse, inspect the existing reuse pool and map exact source files, licenses and ownership, adaptations, and compatibility before writing replacements.
+Do not assume a framework, hosting vendor, queue provider, model, or tenancy architecture. This part requires Postgres, pgvector, RAG, memory, retrieval, reconciliation, Edge Functions, Cron scheduling, and grounding to be explicitly designed, verified, or marked blocked. If the product uses another stack, map equivalent existing capabilities and produce a concrete Supabase integration or migration decision with impact and dependencies. Do not silently migrate, duplicate the system of record, or pretend Supabase is already connected.
+B3. BUILD A FRESH EVIDENCE BASELINE
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Record actual UTC run time, repo remote, branch, HEAD, local modifications, environment mapping, deployment commit, database identity, migration head, enabled extensions, installed versions, and access scope. Keep secrets out of artifacts and logs. Never overwrite user changes or run destructive Git operations to simplify the audit.
+Inspect first-party source throughout the repository. Inventory generated and vendor content separately. Create an inspection coverage manifest identifying what was read, traced, executed, sampled, inaccessible, or omitted with reasons. A full inventory does not mean every path has been verified.
+Map frontend routes and actions; API and MCP tools; authentication and authorization; server handlers; database functions, triggers, tables, views, constraints, grants, and policies; storage; external integrations; background consumers; Cron registrations; webhooks; monitoring; deployment; rollback; and backup and restore.
+Inspect live metadata and runtime evidence using read-only operations only. Compare declared configuration to deployed functions, active Cron jobs, running consumers, registered webhooks, actual grants, provider status, and recent receipts. A checked-in migration or function source is not proof that it is deployed or running.
+Trace representative workflows from entry point to database and provider effects and back to user-visible outcome. Exercise all material branches according to their risk. Record code-only findings separately from runtime-verified findings. Missing access must not receive a passing status.
+Do not repeat unsupported conclusions from prior audits. In particular: (a) zero rows establish emptiness at the queried time and scope, not that the whole feature is built or has never executed through another path; (b) disabled trust proves a current gate condition, not end-to-end implementation completeness; (c) a non-member denial test does not prove member access or cross-tenant isolation; inspect existing two-tenant tests or use disposable local isolated fixtures when they cannot affect connected systems; otherwise specify that test and mark it UNKNOWN, without requiring paying customers; (d) no CI jobs starting means missing CI evidence, not tested code failure; (e) skipped tests are unknown, and authoring runnable acceptance tests is still required; (f) no live workload requires disclosed access-pattern proposals from code and contracts, not omission of the architecture; (g) absent confirmed jurisdictions requires an applicability inventory and unresolved review fields, not omission of the hazard analysis; (h) a production fixture cleanup is a gated destructive change, not automatic housekeeping. Claims such as fully built, configuration only, never ran, and permanently human require evidence of their entire stated scope.
+B4. DEFINE THE COMPLETE BUSINESS WORKLOAD
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Derive a responsibility inventory from product intent, source, domain evidence, actual user roles, observed workflows, and applicable policies. Inspect the operator's day, week, month, quarter, year, first-use lifecycle, incident day, cancellation, and offboarding. Include time-triggered duties that have no UI screen.
+Audit both distinct planes.
+PLATFORM and OWNER: acquisition infrastructure, conversion, sales administration, tenant provisioning, integration setup, entitlements, platform subscriptions, metering, payment recovery, support, releases, security operations, abuse controls, cost management, backups, restore, incident recovery, knowledge maintenance, evaluation, account lifecycle, and fleet reporting.
+TENANT and CLIENT: lead capture, qualification, CRM, scheduling where applicable, inbox and voice where applicable, follow-up, nurturing, campaigns, estimates, proposals, agreements, service preparation, the vertical's core delivery workflow, coordination, inventory and resources where applicable, invoicing, payment status, approved collection flows, aftercare, reviews, referrals, reactivation, retention, customer support, staff exceptions, knowledge updates, and reporting.
+These are discovery prompts, not mandatory invented modules. Expand for this product's domain. Mark irrelevant responsibilities with evidence. Do not force a booking workflow into software that does not sell appointments. Do not count physical work, required customer choices, third-party identity checks, or legally reserved decisions as software execution.
+Create a WORKFLOW-COVERAGE ledger. Every responsibility needs a stable ID, actor and plane, trigger, prerequisites, state machine, action, outcome proof, exception behavior, source evidence, current status, desired autonomy, dependencies, and acceptance test. Keep human-dependent and externally blocked responsibilities visible in the full inventory.
+B5. DEFINE AUTHORITY BEFORE EXECUTION
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Create a machine-enforceable autonomy policy per tenant, workflow, action, channel, and risk class. Include allowed tools, scope, preconditions, recipients, timing windows, financial limits, budgets, confidence and evidence requirements, postconditions, reversibility and compensation, expiry, and revocation.
+The objective is to convert recurring human decisions into explicit onboarding policies wherever valid. Do not insert approval into every ordinary task by habit. Equally, do not interpret the phrase full autonomy as permission to bypass existing controls, invent commercial terms, initiate unapproved spending, or remove required consent.
+Where a current standard reserves an action for a human and the requested target is zero human interaction, surface the conflict precisely. Produce the policy decision and technical work needed to resolve it. Do not silently rewrite the standard or silently lower the target. Continue all unaffected work.
+Require deterministic authorization outside the LLM. Model-provided confidence is not sufficient permission. Validate current tenant membership, entitlement, tool scope, object ownership, evidence freshness, and business preconditions at execution time. Ground tenant context in authenticated server-side identity. Do not trust a host, header, or tenant ID without validating its mapping and authority.
+Represent proposals, approvals when applicable, policy decisions, executions, tool calls, outcomes, and costs as linked records. Give every material action a receipt. Where an action cannot be undone, define a permitted compensating response rather than inventing an undo. Include pause and resume and per-workflow, tenant, and fleet kill switches with auditable reasons.
+B5A. MAKE SAFETY A BLOCKING EXECUTION SYSTEM
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Autonomy must operate inside enforceable boundaries. Never promise that this system prevents every lawsuit, security incident, or incorrect decision. Identify applicable obligations and demonstrate the controls actually enforced. Disclaimers, generic terms of service, an LLM guardrail prompt, and an AI confidence score are not substitutes for authorization or product safety.
+Produce a threat model and hazard register covering malicious users, compromised tenants, hostile retrieved content, malicious tool responses, compromised integrations, mistaken agents, concurrent workflows, insider abuse, supply-chain changes, and failure of the guardrail services themselves. Include harm from action, inaction, repetition, disclosure, discrimination, false claims, destructive changes, and unsafe domain decisions. For each hazard identify the affected person, trigger, consequence, enforcement point, detector, recovery, and test.
+Build a GUARDRAIL-REGISTER. Every control requires a stable ID, applicable workflows, prohibited condition, authoritative input, enforcement location, policy version, allow and deny behavior, outage behavior, receipt, alert, test, and designated policy owner. Specify blocking checks outside the model at the API, tool, and provider boundary and the database layer where applicable. Inspect whether existing checks bind UI, API, MCP, Cron, worker, and webhook entry points; describe exact future fixes for gaps.
+The execution gate must validate identity and tenant scope; tool permission; current policy; required consent or other applicable authorization; recipient, account, and resource identity; factual support; input schema; freshness; price, amount, and currency; available resources; timing; cumulative limits; idempotency; and permitted postconditions as relevant to the action. Reserve cumulative budget atomically before acting so concurrent agents cannot each spend the full allowance. Splitting one action into many small actions must not evade limits.
+Use deny-by-default for unregistered actions and fail closed for privileged, harmful, or externally consequential actions when required authorization or evidence checks are unavailable. Define a tested safe fallback per workflow so fail-closed behavior does not silently abandon a duty. Separate continuing safe internal and read-only work from prohibited external side effects. Permission revocation and a kill switch must reach queued jobs and be rechecked immediately before execution. Do not imply an in-flight external side effect can always be canceled.
+LEGAL AND DOMAIN APPLICABILITY: build a dated requirements matrix based on the business location, customer locations, channels, data types, industry, contractual commitments, and actual activities. Verify relevant requirements from current primary authorities, effective dates, applicability, and approved counsel interpretations where needed. Do not treat an AI legal summary as counsel approval. Mark uncertainty and block the affected action or use a confirmed lawful fallback. Continue unrelated work. Separate binding rules, vendor terms, contractual promises, voluntary frameworks, and internal risk choices.
+Inspect marketing email, SMS, calls, call recording, AI disclosure, subscriptions and cancellation, consumer representations, data protection, retention, accessibility, and sector-specific requirements only where applicable. Do not assume one universal consent standard covers every jurisdiction and channel. Required professional judgment, legal commitments, or safety-critical domain decisions cannot be automated by inventing authorization. Define software support boundaries for any regulated or high-impact health, credit, employment, insurance, housing, or physical-safety functionality actually present.
+CONSENT AND CONTACT CONTROLS: preserve evidence of the actual disclosure and policy version presented, permitted purpose and channel, subject identity, timestamp, capture source, revocation, and scope. Validate required contact authorization at send time, not only enrollment. Handle imported lists, delegated access, reassigned addresses and numbers, wrong recipients, opt-out races, stale consent, quiet hours, and provider restrictions. Do not infer marketing consent from an account creation, a public address, or a transaction without a verified applicable basis. A blocked campaign may continue safe internal preparation but cannot send.
+CLAIMS AND COMMITMENTS: require approved source-backed claims and offers. Block invented testimonials, fabricated scarcity, guarantees, unsupported professional advice, unauthorized discounts, altered commercial terms, admissions, threats, and promises the product cannot fulfill. Use versioned approved contract templates and deterministic business terms where applicable; prevent the agent from rewriting legal clauses from a customer chat. Distinguish necessary customer choice or signature from operator work that can be automated. Record residual dependencies plainly.
+MONEY AND RESOURCES: enforce server-side entitlements, merchant, tenant, and currency mapping, operation-derived idempotency, atomic limits, immutable accounting history where required, refund and payout authority, protected destination changes, and reconciliation. Never let the model compute an authoritative balance or choose an arbitrary beneficiary. Test repeat requests, concurrency, self-dealing, negative and overflow amounts, and charge and refund loops. Keep the client's commercial transactions separate from Kaldr platform billing.
+PRIVACY AND EVIDENCE: minimize collection and model-provider disclosure; inventory processors and data flows; scope retention, deletion, export, and legal holds under verified requirements; redact traces; restrict PII; and protect secrets. Identify sensitive and minor data where present. Never put passwords, raw credentials, or unnecessary sensitive records into embeddings. Design tamper-evident audit records and restricted deletion; do not call an ordinary writable table immutable. Record the model, prompt, tool, policy, and source versions and inputs and outputs needed to reconstruct a material decision, using minimization and access control.
+AI AND TOOL SECURITY: prevent arbitrary shell, SQL, URL, or file actions in the tenant agent. Use registered tools, typed arguments, allowlisted targets, bounded outputs, egress controls, SSRF protection, output encoding, and secure file handling. Treat all retrieved and external content as untrusted. A prompt-injection classifier may assist but cannot be the sole boundary. No model may grant itself a role, extend a budget, change its own policy, erase its audit trail, or silently promote unverified memories.
+MODEL AND POLICY CHANGE: version prompts, models, knowledge sources, retrieval settings, rules, and tools. Evaluate material changes on held-out product cases and adversarial tests before promotion. Use shadow mode and canaries where they resolve risk. Pin versions where supported and detect provider-side drift. Automatic learning may only update the fields and procedures explicitly authorized for that mode. A large clean streak does not prove a rare catastrophic risk is absent.
+INCIDENT RESPONSE: define containment, per-tenant isolation, freeze of unsafe actions, evidence preservation, connection revocation, recovery, support communication, and notification decision paths under applicable rules. Do not automatically send breach notices, make legal admissions, or promise restitution from a speculative diagnosis. Track unresolved exposure, accountable decision ownership, and deadlines. A blocked legal dependency cannot be hidden in a green autonomy score.
+MANDATORY NEGATIVE TESTS: demonstrate denial of cross-tenant tools and retrieval; forged and expired consent; wrong-recipient requests; injected document and tool instructions; stale and contradictory policies; cumulative-spend bypass; concurrent overbooking; credential leakage; approval replay; revoked authority in queued work; prohibited legal-clause edits; guardrail service outage; unauthorized control changes; and attempted audit tampering. Tests must show no forbidden external effect or data disclosure, not merely that a refusal sentence was generated. Measure false-positive blocks as well so the system remains useful.
+Deliver a jurisdiction and applicability matrix, threat and hazard register, guardrail registry, policy-change process, consent and evidence design, adversarial test suite, and incident-response runbook. Every applicable control must map to exact implementation and passing evidence or a visible blocker. No launch or autonomy pass while a required safety control is missing, unverified, or bypassable.
+B6. MAKE ONBOARDING PRODUCE AN OPERATIONAL TENANT
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Onboarding must establish the knowledge and authority needed for the product to work without repeated questions. A form marked complete is not an activation proof.
+Discover and collect only product-relevant inputs: legal and business identity, services and products, exact prices, geography, time zone, hours, resources, capacity, approved brand assets and voice, customer lifecycle, policies, communication consent, quiet hours, lead qualification, objectives, budgets, escalation rules, integration ownership, and permitted actions. Record missing inputs explicitly. Never generate business facts to fill a blank.
+Ingest approved sources such as documents, authenticated exports, authorized websites, structured settings, and FAQs. Preserve originals, provenance, owner, version, effective dates, source priority, processing status, and permissions. Detect extraction failures and contradictory statements. Ask focused questions about unresolved material facts only after collecting discoverable evidence.
+Create the tenant's versioned knowledge base, structured policy records, tool permissions, agent configuration, workflow configuration, and goal-based action plan. The plan needs steps, dependencies, triggers, due conditions, follow-ups, outcome measures, and exception routes. Activate only supported actions for which authority and prerequisites exist.
+Provision asynchronously through durable jobs. Track granular states and allow idempotent resume after partial failure. Verify RLS, source ingestion, retrieval, external connection health, webhook signatures, scheduling, consent, and test outcomes. Use controlled test data and recipients isolated from production. Record each activation criterion from actual evidence, not a mutable completed flag.
+Knowledge readiness includes factual question tests, forbidden-source tests, conflict tests, missing-answer behavior, policy application, and at least one product-specific tool workflow. Existing tenants need a resumable backfill and requalification path. Revoked connections, revised policies, and expired knowledge must cause targeted revalidation.
+B7. DESIGN THE DATA AND INTELLIGENCE ARCHITECTURE IN DEPTH
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Produce a dedicated architecture artifact covering all the following and trace each design to current objects or explicit proposed changes.
+A. POSTGRES. Establish authoritative state and relationships; business invariants; tenant ownership; composite ownership constraints where needed; RLS and grants for tables, views, functions, storage, and vector queries; indexes derived from actual access patterns; concurrent update controls; retention; auditing; and migration strategy. Address privileged workers that bypass ordinary RLS. Avoid granting an agent arbitrary SQL or a service-role key through the client.
+MIGRATION LINEAGE RULE: treat the live database schema, the migration-history table, the repository migration files, and custom deployment scripts as four separate evidence sources. Compare them read-only. Do not infer missing production objects from file counts, a stale migration-history count, or an inability to reset locally. Do not reset, drop, truncate, replay, mark every migration applied, or rewrite the migration chain during this audit. The plan must preserve the live database and data, identify already-present versus actually-applied changes, and propose a controlled lineage repair. Where a change is already present because it was applied manually, a future operator may use Supabase's migration-history repair operation to record that version only after schema evidence proves it is present; history repair records metadata and does not execute the migration SQL. Where a history row exists but the change is absent, propose a reviewed reverted-history correction only after evidence proves it never ran. The plan must never mark all missing rows applied to make counts agree.
+For an unrepeatable chain, document a non-destructive baseline plan: capture the live schema as a versioned reference, preserve a historical-gap ledger, compare it to a disposable local or branch database, separate schema from data, auth, storage, extension, and secret inventory, and prove a forward-only migration path before any production application. A clean rebuild is a future test target, never a production repair step. Grade live correctness, history accuracy, and clean-environment reproducibility separately.
+For Kaldr money records use BIGINT integer cents and the existing atomic ledger architecture, never a mutable balance as the sole authority. Use operation-derived idempotency keys and reclaimable webhook handling. Preserve product ownership boundaries and audit existing exceptions instead of silently replacing a mature money implementation.
+Keep normal state tables plus append-only material events by default, rather than introducing full event sourcing without evidence. Atomically commit business changes and their event and outbox records. Version event payloads; record tenant, actor, entity, source, occurred and recorded time, correlation and causation IDs, and deduplication identity. Define ordering per entity where it matters. Protect event integrity and minimize sensitive payloads.
+B. PGVECTOR AND KNOWLEDGE INGESTION. Verify extension availability and version. Define source storage, parsing and OCR where needed, chunk boundaries, metadata, source version and hash, embedding model and dimensions, search operators, indexes, update and delete propagation, failed-ingestion handling, and reindexing when models change. Use compatible document and query embeddings. Prevent late embedding jobs from overwriting newer content. Measure filtered recall and latency under tenant isolation with representative data. Vectorize semantic content. Exact balances, inventory, schedules, permissions, prices, and transactional state come from typed queries and tools. Vectors never replace the authority of those records. Do not report that embedding content trains model weights.
+C. RETRIEVAL AND RAG. Route questions to SQL and tool facts, document evidence, memory, relationship queries, or a justified combination. Filter access, active versions, applicability, and time before evidence enters the model. Design lexical plus semantic search where useful, deduplication, reranking, evidence limits, source authority, freshness, query fallbacks, and retrieval traces. Hard applicability rules cannot be overridden by a similarity score. Define query-specific source precedence. Tenant policies cannot override higher applicable constraints. Distinguish current-answer mode from historical and audit mode. Cache keys must include tenant and access scope and relevant versions, with permission-change and source-change invalidation. Never use shared semantic caching that leaks tenant content.
+D. GROUNDING. For material claims and action parameters preserve source record and version, supporting excerpt or typed tool result, retrieval time, applicable dates, and evidence status. Distinguish fact, calculation, inference, estimate, and recommendation in storage and output. Deterministic code performs authoritative calculations. Validate citations for actual entailment and applicability; attaching a URL is insufficient. Revalidate mutable preconditions immediately before acting and protect concurrent changes with database and provider safeguards. Treat retrieved content, uploaded documents, messages, and tool results as untrusted data. They cannot redefine system permissions. Missing or conflicting evidence causes an explicit, useful fallback and gap record, not a fabricated answer.
+E. MEMORY AND LEARNING. Separate raw conversation history, structured extracted facts, semantic summaries, episodic outcomes, temporary working state, and approved procedural knowledge. Keep identity resolution explicit. Memory needs tenant, subject, type, source, confidence and evidence status, observed time, effective time, invalidation and supersession history, sensitivity, and retention. Support correction, export, and deletion across derived representations. Capture explicit corrections and outcome-linked predictions. Label implicit behavior signals as estimates. Evaluate every material event for learning value with inexpensive deterministic filtering before model use. Build candidate extraction, contradiction resolution, evidence validation, evaluation, promotion, rollback, and future-retrieval wiring. Do not save every generated response as truth or reinforce a model's own mistake by repeatedly citing it. Distinguish updating knowledge, changing approved procedures and prompts, fitting calibrated predictors, and training model weights. Use holdouts or controlled comparisons for claimed improvements where appropriate. Avoid feedback loops, target leakage, unsupported causal claims, and cross-tenant transfer of private information. Any population learning needs an explicit permission and privacy design; a minimum group size alone is not proof of privacy. Every promoted lesson must show where future decisions read it, an evaluation showing the behavior changed as intended, and a regression test that protects the correction. A memory table without a retrieval path is inactive storage.
+F. RECONCILIATION. List every material pair that can disagree: internal and provider payments, ledgers and entitlements, bookings and calendars, resources and reservations, source documents and embeddings, approvals and executions, jobs and business outcomes, event history and state, and declared and deployed schedules or schemas. Add domain-specific pairs. For each define field-level authority, comparison method, expected consistency delay, scan and checkpoint strategy, discrepancy type, bounded corrective action, idempotency, concurrency control, evidence, escalation, and verified closure. Never use latest timestamp wins universally. Unknown external side effects require investigation before replay. Never infer payment success or issue a duplicate charge because a local request timed out.
+G. EDGE FUNCTIONS AND WORKERS. Map every function and worker to its trigger, authenticated caller, allowed scope, exact input and output, business transaction boundary, dependencies, timeout, retries, resource and spend budget, receipt, and outcome. Verify current limits against deployed plans. Bounded functions perform bounded work; long-running, CPU-heavy, or repository execution belongs in suitable isolated workers. Persist workflow checkpoints outside process memory.
+H. CRON AND DURABLE EXECUTION. Verify registered schedules and running consumers, not only config files. Build a registry with name, expression, time zone, owner, handler, read and write objects, due-time behavior, maximum duration, concurrency, heartbeat, retry, misfire policy, and consequence of a missed run. Address DST, tenant quiet hours, staggered execution, overlap, catch-up, and schedule changes. Use durable jobs with leases, heartbeats, attempt records, operation-derived idempotency, stale-worker fencing where required, backoff and jitter, attempt and spend ceilings, cancellation, dead letters, and replay controls. A queue visibility guarantee is not end-to-end exactly-once delivery to a provider. Do not hold database transactions open during long external work. Define recovery after crashes at every side-effect boundary. Monitor end-to-end completion independently of scheduler success. External deadman monitoring must detect failure of the database, scheduler, worker, and the monitor itself as far as practicable. Record durable schedules separately from their execution attempts.
+B8. WIRE BUSINESS EXECUTION, FOLLOW-UP, AND COMMUNICATION
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Build a product-specific catalog for immediate, scheduled, conditional, and recurring workflows. Cover the previously discovered acquisition-to-retention and platform-operation responsibilities without inventing irrelevant features.
+For each plan, follow-up, nurture sequence, campaign, and operational workflow define: eligible audience, entry event, prerequisites, permitted channel, source-backed content, schedule, wait conditions, stop conditions, branch logic, tool actions, measurable result, retry and recovery, and attribution. Conversion, reply, opt-out, cancellation, changed eligibility, and manual takeover must cancel or revise pending actions consistently.
+Prevent different agents and campaigns from independently contacting the same person with conflicting messages. Add a contact-level coordination policy, deduplication, frequency limits, quiet hours, suppression, unsubscribe propagation, channel restrictions, delivery-status processing, and failure handling. Do not equate provider acceptance with delivery, reading, conversion, or revenue.
+For webhooks verify provider registration, signature using the required original payload, anti-replay rules, tenant and account mapping, durable receipt, deduplication, fast acknowledgment, asynchronous processing, duplicate and out-of-order handling, retries, schema evolution, dead letters, and reconciliation for missed events. API and MCP entry points must use the same business authorization and invariants as the UI.
+Make every plan actionable through registered tools with typed arguments and explicit state transitions. A next-best-action paragraph without executable steps, scheduling, receipts, and outcome tracking does not meet the target.
+B9. PLATFORM RELIABILITY AND SELF-HEALING INTERFACE
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Audit dependency health, structured logs, traces, Sentry or actual monitoring, silent workflow failures, product analytics, cost and usage, security, status reporting, backups, storage-object backup coverage, restore drills, secrets rotation, and graceful degradation. Define SLOs and recovery objectives from product commitments and evidence; mark unapproved targets as proposals.
+Distinguish operational recovery from source-code modification. Wire tickets, telemetry, failed synthetic checks, and reconciliation discrepancies into an incident system that investigates before escalating to a coding agent. Define the contract with the separate self-healing prompt: incident ID, repo and deployment, expected behavior, sanitized evidence, scope, risk, reproduction, outcome, and status callbacks.
+Do not award autonomy credit for emitting an alert. Track whether the system recovered, completed a compensating action, or still depends on a human. Keep platform and tenant exception ownership distinct. Design fleet-level monitoring without aggregating unrestricted client secrets or raw private business data.
+B10. PRODUCE AN EXECUTABLE IMPLEMENTATION PROGRAM
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Audit output must leave the product with an implementation-ready plan, not a recommendations list. At minimum produce these substantive artifacts in the report directory, reusing canonical project files and linking rather than duplicating them:
+	•	RUN-STATE: current commit and environment, mode, authorization scope, completed work, blockers, and exact continuation step.
+	•	EVIDENCE-REGISTER: reproducible evidence and inspection coverage.
+	•	AUTONOMY-AUDIT: failures, impact, current capabilities, and human dependencies.
+	•	WORKFLOW-COVERAGE: machine-readable responsibilities and statuses plus readable matrix.
+	•	AUTONOMY-CONTRACT: scope, authority policies, limits, and visible exclusions.
+	•	SAFETY-AND-APPLICABILITY: dated requirements, hazards, guardrail registry, consent and evidence controls, adversarial tests, and incident-response procedures.
+	•	DATA-INTELLIGENCE-ARCHITECTURE: all eight areas above with current and proposed mapping.
+	•	ONBOARDING-ACTIVATION-PLAN: facts, sources, provisioning, tenant backfill, and proof.
+	•	WIRING-MAP: routes, tools, tables, triggers, jobs, webhooks, Cron registry, and provider effects.
+	•	IMPLEMENTATION-SERIES: dependency graph, reuse map, risk, deployment order, and no-overlap scope.
+	•	Individual PRDs and task plans satisfying the project standard.
+	•	ACCEPTANCE-AND-FAILURE-TESTS: executable checks with objective pass conditions.
+	•	ROLLOUT-RECOVERY: staging, backfill, canary, rollback and compensation, and live verification.
+	•	BLOCKERS-AND-DECISIONS: exact missing input, access, or authorization and what it blocks.
+There is no PRD count target or cap. Decompose by cohesive implementation scope and dependencies. Every gap maps to a task; every task maps to acceptance evidence. Earlier invariants remain intact throughout the series.
+Each PRD needs a header with dependencies, unlocks, verified reuse percentage, atomic task count, and verification loops. Include exact existing and proposed file paths, symbols, routes, request and response shapes, and error contracts. Database changes require complete SQL with constraints, indexes, grants, RLS, and migration and backfill strategy following the Schema Expansion Checklist. Label environment-dependent unresolved values; do not invent them. If a material unresolved decision prevents executable detail, explicitly mark that PRD blocked rather than pretending it is complete.
+Atomic tasks need ordered steps, expected result, exact checks, failure response, and evidence output. Update the feature ledger, living spec, and per-PRD delta through the applicable evaluator process. Avoid parallel work on shared schema and interface contracts before those contracts are fixed.
+B10A. THE AUTONOMY DEPARTMENT GRADE SHEET (rubric KALDR-AUTONOMY-1.0)
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+This is a published engineering rubric, not a claim of mathematical freedom from all bias or an industry certification. Minimize judgment through locked criteria, reproducible evidence, deterministic calculation, independent review where available, and a documented challenge and retest path. Never grade based on the author's confidence, model brand, code volume, money spent, number of agents, or whether the implementation uses AI. Deterministic workflows earn the same credit when they satisfy the same outcome.
+Twenty departments, four controls each. Within department Dxx, numbered item n has ID Dxx-0n. Weights are fixed: 5 is a critical invariant or gate, 3 is a major operating requirement. These are declared rubric policy choices, not measured probabilities. A compound control passes only when every applicable clause and mapped workflow has evidence. Expand it into objective subtests without multiplying its parent weight. Add product-specific controls before testing, with documented requirement, risk, and weight; keep them in a separately disclosed supplement. Do not erase missing functionality with NOT_APPLICABLE.
+ID
+Department
+Controls and fixed weight
+D01
+Product truth and build reproducibility
+1. Source, deployment, schema, and environment identities match or drift is explained [w=3]; 2. A clean isolated checkout builds with declared dependencies [w=3]; 3. Live schema, migration history, repository files, and deployment scripts have reconciled lineage, with clean-environment reproducibility assessed separately [w=5]; 4. All material workflows and inspected and omitted paths are inventoried [w=3]
+D02
+Tenant isolation and access
+1. Authenticated tenant A cannot read or write tenant B through any exposed path [w=5]; 2. Permitted tenant members can perform their intended actions [w=5]; 3. Non-members, revoked users, and wrong-role requests are denied [w=5]; 4. Privileged workers, storage, vectors, views, and functions preserve tenant scope [w=5]
+D03
+Safety, consent, and authority
+1. External actions require applicable current consent and authorization [w=5]; 2. Policy outages, revocations, and kill switches block dependent unsafe actions [w=5]; 3. Injected content cannot change tool authority or disclose protected data [w=5]; 4. Required applicability reviews and protected decisions are identified and enforced [w=5]
+D04
+Onboarding and activation
+1. Required business facts and policy versions are collected without fabricated defaults [w=3]; 2. Provisioning resumes after interruption without duplicate tenant resources [w=3]; 3. Connection and knowledge readiness are verified before dependent actions activate [w=5]; 4. A new isolated tenant completes the product-specific first-value workflow [w=3]
+D05
+Postgres and business correctness
+1. Constraints preserve product-specific state and relationship invariants [w=5]; 2. Concurrent writes cannot create forbidden duplicate or conflicting business state [w=5]; 3. Critical queries and indexes are evaluated against stated workloads [w=3]; 4. Business updates and their durable event and outbox handoff commit together [w=5]
+D06
+Knowledge base and pgvector
+1. Approved sources retain provenance, versions, applicability, and access scope [w=3]; 2. Ingestion, compatible embeddings, and search work on representative authorized content [w=3]; 3. Updates and deletes reach chunks, embeddings, and caches without stale overwrites [w=3]; 4. Failed extraction and index jobs are visible, bounded, and recoverable [w=3]
+D07
+Retrieval, RAG, and grounding
+1. Exact transactional questions use authoritative queries and tools [w=5]; 2. Retrieval excludes forbidden, expired, and inapplicable evidence [w=5]; 3. Material claims and action parameters are supported by applicable evidence [w=5]; 4. Missing or conflicting evidence produces the defined safe fallback and gap record [w=3]
+D08
+Memory and learning from mistakes
+1. Explicit corrections retain source evidence and tenant-scoped validity [w=3]; 2. A verified lesson changes the intended future retrieval or action in a test [w=3]; 3. Learning promotion passes holdout and regression checks and can be withdrawn [w=3]; 4. Guesses are not promoted as facts and deletion reaches derived memories [w=5]
+D09
+Jobs, Edge Functions, and Cron
+1. Declared schedules and functions match deployed registrations and active consumers [w=3]; 2. Jobs recover from crashes with leases and checkpoints and bounded retries [w=3]; 3. Unknown external effects are checked before retry to avoid duplicate effects [w=5]; 4. Missed schedules, stalled jobs, and budget exhaustion are detected with safe responses [w=3]
+D10
+Integrations, API, MCP, and webhooks
+1. All entry points enforce the same business authority and invariants [w=5]; 2. Webhook identity, replay handling, and tenant and account mapping are verified [w=5]; 3. Duplicate, out-of-order, and missed provider events are handled correctly [w=3]; 4. Expired connections, quotas, and schema changes have tested recovery paths [w=3]
+D11
+Reconciliation and data integrity
+1. Each material disagreement has a declared field-level source of authority [w=3]; 2. Discrepancy scans have checkpoints, backlog monitoring, and bounded work [w=3]; 3. Permitted repairs converge without duplicate financial or business effects [w=5]; 4. Uncertain or conflicting cases remain visible until closure is proved [w=3]
+D12
+Acquisition, nurturing, and campaigns
+1. Lead capture and qualification use approved facts and record outcomes [w=3]; 2. Campaign entry, waiting, branching, and stop conditions execute as specified [w=3]; 3. Opt-outs, contact limits, and competing campaigns cannot bypass send policy [w=5]; 4. Attribution distinguishes acceptance, delivery, conversion, and revenue [w=3]
+D13
+Core client service delivery
+1. The product-specific client workflow reaches a verified business outcome [w=5]; 2. Resources, timing, and required customer and staff inputs are correctly coordinated [w=3]; 3. Failures and changes trigger defined recovery or visible exceptions [w=3]; 4. All applicable recurring client duties run without an open staff browser [w=3]
+D14
+Money, billing, and entitlements
+1. Amounts, currency, and tenant and merchant destinations are authoritative and validated [w=5]; 2. Ledger transitions and idempotency prevent duplicate or inconsistent money effects [w=5]; 3. Server-side entitlements and atomic cumulative limits bind all execution paths [w=5]; 4. Payment uncertainty, recovery, and provider reconciliation are tested in safe isolation [w=5]
+D15
+Support, aftercare, and retention
+1. Known support questions use applicable evidence with a safe unknown path [w=3]; 2. Tickets retain context and reach an accountable resolution path [w=3]; 3. Aftercare, rebooking, and reactivation follow consent and lifecycle stop rules [w=3]; 4. Customers receive accurate status and failures are not falsely called resolved [w=3]
+D16
+Platform owner and fleet operations
+1. Applicable platform lifecycle and recurring owner duties have executable workflows [w=3]; 2. Fleet reporting links outcomes, exceptions, and ownership to each product [w=3]; 3. Client repositories, data, and billing stay within their ownership boundaries [w=5]; 4. Routine platform operations execute without an owner dashboard session [w=3]
+D17
+Observability, security response, and recovery
+1. Monitoring detects failed outcomes and silence beyond the watched failure domain [w=5]; 2. Backup restoration recovers required data and service dependencies in a drill [w=5]; 3. Containment, revocation, and recovery playbooks operate within authority [w=5]; 4. Reliability and cost reports show traceable outcomes and unresolved incidents [w=3]
+D18
+Self-healing and release integrity
+1. Incident triage separates verified code defects from other causes [w=3]; 2. A code repair has a failing-before and passing-after meaningful reproduction [w=5]; 3. The agent cannot weaken required tests, controls, or release permissions [w=5]; 4. Authorized release, rollback and compensation, and post-release closure are verified [w=5]
+D19
+Cost, capacity, and abuse
+1. Atomic per-tenant, workflow, and fleet budgets stop unauthorized cumulative spending [w=5]; 2. Rate, concurrency, queue, and attempt limits bound abusive or runaway work [w=3]; 3. Capacity targets and degraded behavior are tested against declared requirements [w=3]; 4. Cost per completed outcome and anomalous usage are observable [w=3]
+D20
+Verification and unattended outcomes
+1. Material workflows have executed positive and negative acceptance tests [w=5]; 2. Required tests cannot self-skip and still produce a readiness pass [w=5]; 3. Unattended tests prove complete outcomes and safe failure handling [w=5]; 4. Before and after evidence, residual dependencies, and observation limits are reported plainly [w=3]
+Lock the product's expected workflows, control applicability, test cases, and measurable acceptance thresholds before running checks. Derive thresholds from verified business contracts or explicitly approved design targets, never invent industry averages. Application-specific questions must be made concrete: which route, tenant role, record, expected result, failure condition, and acceptable bounds? Record all mapping details in the criterion's evidence packet. One root cause can explain several distinct failed outcomes; deduplicate the repair task, not independent outcome failures. Do not count the same control twice under different departments; where a D control and an L control test the same thing, run the test once and cite the same evidence from both.
+CONTROL STATUS: PASS means all defined tests passed with applicable evidence. FAIL means an observed behavior violates the defined acceptance condition. UNKNOWN means untested, inaccessible, skipped, inconclusive, or stale evidence; attach the exact reason. N/A requires affirmative non-applicability evidence and rationale. Unknown is not a proven defect. Empty data, disabled features, and unavailable credentials do not establish N/A. Mixed or partial outcomes must be recorded in subtests and resolve to FAIL if a required subtest fails, otherwise UNKNOWN if any required subtest is unresolved. Source existence alone cannot pass an execution requirement.
+EVIDENCE REQUIREMENTS: each control has scope, plane (platform, client, or both), product and workflow mapping, environment, immutable commit, deployment, and schema identifiers where relevant, UTC time, expected and actual result, executed test, query, or command, sanitized artifact reference, and evaluator identity. Screenshots support UX evidence but cannot alone certify backend security. A PASS or FAIL without sufficient evidence becomes UNKNOWN. N/A without sufficient rationale becomes UNKNOWN.
+ACTION PLAN: every FAIL and UNKNOWN has a plain-language problem or missing-proof statement, who is affected, business consequence, confirmed cause or explicit hypothesis, immediate containment where needed, exact file, function, table, or config scope, dependencies, atomic implementation or verification tasks, responsible role, effort basis if estimable, and objective retest. Unknowns get investigate and prove actions rather than fabricated fixes. Link actions to PRDs, commits, tests, and affected criteria. Prioritize P0 for confirmed high-impact exposure with containment; then verification of critical unknowns before dependent release; then dependency-unblocking correctness and recovery work; then ordinary capability and optimization gaps. State evidence for priority rather than ranking by score improvement alone.
+FAIR REVIEW: use a separate evaluator when available (a sub-agent that inspects evidence without adopting the builder's conclusions). Record disagreements and resolve them by reproducible tests or leave UNKNOWN. For stochastic AI tests record dataset and version, repetitions, and outcome distribution; do not select only passing runs. Record sampling limits. Never invent a reviewer or claim independent verification when none occurred.
+B12. ASSESS EXISTING UNATTENDED PROOF AND SPECIFY FUTURE TESTS
+Scope: inspect existing evidence and document the proposed target state only. Do not apply changes.
+Inspect existing unattended test evidence and run existing non-mutating checks only within the audit contract. Specify a future test harness with platform-owner and tenant-staff browsers closed and no human approvals inside the tested automated scope. Do not build or wire that harness into the application in this run. Any local scratch simulation must stay isolated and be labeled; it is not production observation.
+Map existing evidence and planned acceptance tests for the product's first-value flow, ordinary day, recurring duties, lifecycle endings, and material exceptions. Include: interrupted onboarding and idempotent resume; missing, contradictory, expired, and malicious knowledge sources; cross-tenant retrieval and access attempts and access revocation; source updates, deletion, and embedding refresh failures; duplicate and out-of-order webhooks, missed webhooks, and event replay; worker death before and after an external side effect; provider success followed by local timeout and uncertain execution; concurrent resource claims and stale action preconditions; rate limits, provider outages, revoked credentials, and exhausted budgets; missed Cron, DST transitions, stalled consumers, and failed watchdog signals; campaign opt-out or reply during queued sends and cross-campaign conflicts; reconciliation finding and repairing a discrepancy without duplicate effects; learning a verified correction, retrieving it later, and avoiding regressions; backup restoration including dependencies needed for actual service recovery; a confirmed code defect routed into verified self-healing and post-release checks.
+Test protected or irreversible actions through safe isolated fixtures, never unapproved live consequences. Preserve deterministic repros, expected and actual state, trace IDs, provider receipts, runtime versions, and costs. Run independent skeptical verification where the project supports it; otherwise disclose the independence limitation. The builder's confidence is not acceptance evidence.
+Report both denominators: all material business responsibilities and the explicitly authorized software-executable subset. Show automated, approval-dependent, blocked, physical and customer-dependent, and unknown counts separately. For operational rates count completed business workflow instances, including failed eligible attempts, rather than inflating the numerator with heartbeats or tiny background actions. Report workload coverage separately from success rate and observation duration.
+Track success without human intervention, failure and unknown outcome rate, manual minutes, approval backlog, reconciliation backlog and age, duplicate effects, groundedness, retrieval quality, tenant isolation, recovery time, and cost per completed outcome. Passing tests alone do not establish an unmeasured production success percentage.
+B13. AUTONOMY VERDICT
+Lead the autonomy half of the report with what is verified today, what remains dependent on people, and whether the no-routine-human target is achieved for the declared scope. Then the critical blockers, the exact implementation order, the deliverable paths, the evidence actually collected, the checks run or blocked, the current deployment identity, and the ranked next actions for a separate implementation task. Never output a fabricated certificate of 100% autonomy. If anything material is unverified or still human-dependent, state it plainly and attach the work needed to close it. Exclusions must be visible, not removed to make the percentage attractive.
+
+PART C. GRADE, PROVE, DELIVER
+Step 5. Grade it
+Two rubrics, one report. LAUNCH (L01 to L15 below, sixty checks) answers: can this take customers without hurting them. AUTONOMY (D01 to D20 in Part B, eighty checks) answers: can it run the business without you. Both are graded with the same four statuses and the same math; the summary card shows each and the combined number. Each check is weight 5 (a gate: failing it blocks launch) or weight 3. Each check is PASS (proven with evidence), FAIL (proven broken), UNKNOWN (could not verify, reason attached), or N/A (proven not applicable, reason attached; empty tables and missing credentials are never N/A).
+	•	Truth and reproducibility: deployed code matches the repo (3); clean build, typecheck, lint, tests pass (3); migrations in repo match the database (5); every system inventoried (3).
+	•	Tenant isolation and RLS: user A cannot see or change user B's data by any path (5); users can do what they are supposed to (5); non-members, revoked, wrong-role denied (5); admin keys, storage, views, functions, vectors, realtime keep tenant scope (5).
+	•	Authentication and session: identity verified on the server on every call (5); sessions refresh, expire, and revoke correctly (3); a user cannot edit their own role or privileges (5); no login loops, recovery works (3).
+	•	Authorization, input, and abuse: every data-changing route checks ownership or role (5); inputs validated everywhere (3); CSRF defended on cookie-authenticated handlers (3); rate limits on auth, public, and costly endpoints (3).
+	•	Secrets, headers, supply chain, errors: no secrets in repo or browser bundle (5); security headers and a real CSP (3); no known critical vulnerabilities, lockfile consistent (3); no leaking errors, no silent catches, audit log on destructive actions (3).
+	•	Safety, consent, and trust: versioned timestamped consent captured and rechecked at send time (5); kill switches and policy failures stop unsafe actions (5); injected text in documents or messages cannot change what the app is allowed to do (5); terms, privacy, AI disclosure, delete-my-data all reachable (3).
+	•	Money and entitlements (N/A only if there is provably no money): integer cents and authoritative amounts (5); idempotency prevents double charges (5); server-side entitlement checks on every path (5); webhook signatures, uncertainty handling, reconciliation (5).
+	•	Data integrity: constraints enforce the app's rules (5); concurrent writes cannot create forbidden duplicates (5); indexes fit the real queries (3); a business change and its event or outbox row commit together (5).
+	•	Jobs, crons, and functions: what is declared is deployed and firing (3); crashed jobs recover with bounded retries (3); an unknown external side effect is checked before retry (5); missed schedules and stalled workers are detected (3).
+	•	Integrations and webhooks: UI, API, cron, and webhooks enforce the same rules (5); webhook identity, replay, and account mapping verified (5); duplicate, out-of-order, missed events handled (3); expired credentials and quotas recover (3).
+	•	Reliability, backup, and rollback: provider failures fail safe with a clear state (5); a backup has been restored in a drill (5); a release can be rolled back without corrupting data (5); recovery time and data loss window are known (3).
+	•	Performance and capacity: load tested at the expected beta traffic with acceptable p95 and error rate (5); concurrent writes and bursts behave (3); database connections, locks, queues observed under load (3); tested capacity stated as a number (3).
+	•	Observability and self-healing: monitoring catches failed outcomes and silence, not just crashes (5); error monitoring and analytics wired and receiving (3); alerts fire on signup, payment failure, ticket, cron failure, health red (3); a ticket-to-fix path exists that never auto-merges code (3).
+	•	Usability and acceptance: the golden path for each user type works through the UI with the backend state to prove it (5); no dead controls, broken links, or unlabeled stubs (3); empty, loading, and error states everywhere (3); works across browsers, mobile width, slow network, time zones (3).
+	•	Accessibility, i18n, SEO, and copy: keyboard and screen reader basics pass (3); translations complete where the app has them (3); titles, meta, canonical, robots, sitemap correct, no debug pages public (3); no placeholder, lorem, TODO, or fake legal text visible (3). Categories 16 to 35 are the twenty autonomy departments D01 to D20 in Part B below (rubric KALDR-AUTONOMY-1.0). They are graded with the same statuses and the same math and they carry their own artifacts.
+Before you test anything in a category, write the test for each of its four checks into grade.json: what you will do, against which route, table, role, or record, and what result means PASS. Then run it. Then record the result. A check that was never given a test is UNKNOWN, never PASS.
+No partial credit exists. A check is PASS, FAIL, UNKNOWN, or N/A. "Mostly works," "scaffolded," "present but unverified," and "half the routes" are all UNKNOWN or FAIL, never a fraction. If you find yourself wanting to give 1.5 points, the check has subtests: list them, and the check is FAIL if any required subtest failed, otherwise UNKNOWN if any is unresolved, otherwise PASS.
+Score math (compute it, do not eyeball it):
+	•	Total possible = sum of weights of every check that is not N/A.
+	•	Verified score = points from PASS only, as a percentage of total possible. This is the headline number.
+	•	Ceiling = PASS plus UNKNOWN points, as a percentage. The best this app could be if every unknown turned out fine.
+	•	Coverage = PASS plus FAIL points, as a percentage. How much was actually proven either way.
+	•	Bands: A 90 and up, B 80 to 89, C 70 to 79, D 60 to 69, F below 60. Show the band of the verified score.
+	•	Gates: any weight-5 FAIL means LAUNCH BLOCKED regardless of the score. Any weight-5 UNKNOWN means NOT VERIFIED FOR LAUNCH. Say which checks.
+	•	Each category gets the same math on its own four checks.
+	•	If any check anywhere is UNKNOWN, the headline shows the verified score with the word INCOMPLETE next to it and the ceiling beside it. Never show a bare number over a report that has unknowns.
+Prove the number. Write score.mjs into the report folder. It reads grade.json, rejects any status outside PASS, FAIL, UNKNOWN, N/A, rejects any PASS or FAIL that has zero evidence entries, rejects any N/A without a reason, rejects any check without a written test, and then computes every number on the page. The HTML reads the computed output; nothing is typed by hand. Run node score.mjs and paste its output into the report under the heading "Show the math": the weight table, the sums, the division, per category and overall. If the validator rejects the file, fix the grade.json, not the validator.
+Step 6. Write the report card
+Create .planning/launch-audit/REPORT-CARD.html (single file, inline CSS and JS, opens from disk, no external requests) and REPORT-CARD.md with identical content. Build both from a grade.json you write first, so every number is computed. Structure, in this order:
+	•	Headline: verified score and band, ceiling, coverage, gate status (LAUNCH BLOCKED, NOT VERIFIED FOR LAUNCH, or GATES CLEAR), the launch-readiness score and the autonomy score side by side, the unattended verdict with the duty counts, the one-sentence verdict, the date, the commit, the sources reached live and not reached.
+	•	The thirty-five category cards (L01 to L15, then D01 to D20). Each card shows: the category score and band; the four checks with PASS, FAIL, UNKNOWN, or N/A and their weight; Why you scored this (one plain-language paragraph per check that is not PASS, citing the file and line, the query, or the page); What this costs you (what happens to a customer, to your money, or to your reputation if you launch like this); How to fix it (the exact change, where, and the test that proves it); How to verify it yourself (a command or a click path).
+	•	Your path to 100: every check that is not PASS, across all categories, in the order to do them. Blockers first (weight-5 FAILs), then the weight-5 UNKNOWNs to prove, then everything else in dependency order. Each with the change, the location, the test, and a rough effort (hours, one day, multi-day).
+	•	Your next ten actions: the first ten items from the path, written as instructions a person can start today.
+	•	Human work to remove (from Step 4A): two columns, platform owner and tenant staff; every duty a human touches today with its tag removable, partial, or by design, and the change that removes it. Then what still needs a human for this audit: decisions, credentials, dashboard clicks, legal copy, content, and anything I chose not to test.
+	•	Everything I found: every finding with an ID, category, severity, file and line or query, expected versus observed, and impact.
+	•	What I tested, what I could not, and what I assumed, with counts.
+	•	Show the math: the validator output from score.mjs, unedited, for LAUNCH, for AUTONOMY, and combined. 8A. The autonomy artifacts from Part B, every one, linked from the report card: RUN-STATE, EVIDENCE-REGISTER, AUTONOMY-AUDIT, WORKFLOW-COVERAGE (machine-readable plus the readable matrix), AUTONOMY-CONTRACT, SAFETY-AND-APPLICABILITY (jurisdiction matrix, hazard register, guardrail registry, consent and evidence design, adversarial test suite, incident-response runbook), DATA-INTELLIGENCE-ARCHITECTURE (all eight areas, current versus proposed), ONBOARDING-ACTIVATION-PLAN, WIRING-MAP, IMPLEMENTATION-SERIES, the PRDs, ACCEPTANCE-AND-FAILURE-TESTS, ROLLOUT-RECOVERY, BLOCKERS-AND-DECISIONS, CURRENT-GRADE-SHEET, RANKED-FINDINGS, ACTION-PLAN, FUTURE-RETEST-PLAN, and the machine-readable audit records with rubricVersion, product, environment, commit, assessedAt, evaluator, and every control's id, department, requirement, weight, critical, status, evidence[], reason, expected, actual, causeStatus, rootCauseId, action, dependencies[], retest, owner, effort, naReason, reviewer. A report card without these is a summary, not the deliverable.
+	•	The evidence register: every evidence entry with its ID, the exact query or command, the exact output excerpt (secrets and personal data redacted), the file and line, the time, and which checks cite it. Every PASS and every FAIL on the page links to at least one entry here.
+	•	The full inventories (this is where the depth lives; a highlight reel is not a report card):
+	•	Every route and page, with its auth requirement, ownership check, input validation, rate limit, and the check IDs that touched it.
+	•	Every database table, with row count, RLS enabled, RLS forced, every policy and its exact rule, grants to anon, authenticated, and service_role, and the isolation test result for that table.
+	•	Every database function, with SECURITY DEFINER or INVOKER, who can execute it, and whether it checks the caller.
+	•	Every migration in the repo versus the database history, with applied, unapplied, or unrecorded.
+	•	Every cron, in the platform and in pg_cron, with its schedule, its last successful run, and FIRING or NOT RUNNING.
+	•	Every edge or serverless function, with deployed or not, version, and caller.
+	•	Every environment variable name the code reads, with set or unset per environment.
+	•	Every webhook, with provider registration, URL match, signature check, and replay handling.
+	•	Every external provider, with reachable or not and what was verified.
+	•	Every dependency with a known vulnerability, with severity and the fix version.
+	•	Every persona with its golden path steps and the step where it passed or failed.
+	•	The full WORKFLOW-COVERAGE table: every duty, plane, trigger, what runs it, status, evidence, and what makes it unattended.
+	•	The simulated day, week, and month logs: every step, who or what performed it, the receipt, and every point a human was needed.
+	•	Every finding, all of them, not the ones that move the needle: ID, category, severity, check ID, file and line or query, expected, observed, impact, fix, retest.
+Minimums, or the report is not done: every one of the one hundred forty checks has a written test and at least one evidence entry or an UNKNOWN reason; every table and every route appears in the inventories; the findings list contains every FAIL and every UNKNOWN as its own row. If the app is large, the report is long. That is correct.
+Make the HTML readable by a non-engineer at the top and complete for an engineer underneath: a score dial, category cards with color by band, filters by category and severity and status, expandable evidence, and a button that downloads grade.json. Put the summary card from Step 7 at the very top of the page so the first screen answers the question.
+Step 7. Hand it to me
+Do not make me look for anything.
+	•	If this session has an artifact tool or a file-presenting tool (Claude Cowork and claude.ai do), present REPORT-CARD.html as an artifact so it renders right here in the conversation with a clickable card.
+	•	Whether or not that worked, open the report in the default browser automatically: start "" "<full path>" on Windows, open "<full path>" on macOS, xdg-open "<full path>" on Linux. Then print the clickable link on its own line: file:///<full path to REPORT-CARD.html>.
+	•	Under the link, print the summary card in chat:
+LAUNCH REPORT CARD
+Score: <verified> / 100  (<band>)  <INCOMPLETE if any unknowns>   Ceiling: <ceiling>   Proven either way: <coverage>%
+Checks: <n> PASS, <n> FAIL, <n> UNKNOWN, <n> N/A of 140   Findings: <count>   Evidence entries: <count>
+Launch readiness (L01 to L15): <score>   Autonomy (D01 to D20): <score>   Combined: <score>
+Gates: <LAUNCH BLOCKED by ... | NOT VERIFIED FOR LAUNCH: ... | GATES CLEAR>
+Runs unattended today: <YES | NO | UNKNOWN>   Duties automated: <n> of <total> (<n> of <software-executable>)   Human touches per week: <n> (<removable> removable, <partial> partial, <by design> by design)
+Live sources reached: <list>   Not reached: <list>
+Top 5 problems:
+ 1. ...
+ 2. ...
+ 3. ...
+ 4. ...
+ 5. ...
+Next action: <the first item on the path to 100>
+Nothing else. No offer to fix anything. This run changed nothing.
+