@bigsteele/the-big-sean 0.2.1 → 0.3.0

package/README.md

@@ -26,6 +26,20 @@ npx @bigsteele/the-big-sean --check    # after the audit: re-compute the report'
 npx @bigsteele/the-big-sean --stdout   # print the protocol
 ```
 
+## What it targets
+
+The audit reads **this repository**, and any live system it reaches must be one this
+repository names: a Supabase project ref in the env or `supabase/config.toml`, an account
+id in CI, a host named in deploy config. A project ref written only in a planning document
+is treated as a claim to confirm, never as the target. Tools do not choose: `list_projects`,
+a linked CLI project, and an MCP server's configured connection are candidates that must
+match a ref the repo names. No match means no query, and the checks that needed it are
+UNKNOWN with the reason recorded in `SOURCES.md`. Read-only access to a database that is
+not yours is still access that is not yours.
+
+The Big Steele AI Audit that runs as Step 0 touches nothing at all: no network, no
+database, no shell. It reads files in the folder you point it at.
+
 ## Before you run it
 
 This is a large scan, not a quick check. The agent reads everything in the repository it
@@ -65,7 +79,8 @@ says what it verified and what it did not.
 
 Every report card ends the same way: send it in at **bigsteele.com/scan** and get a written
 read of the three fixes that come first, in order. No call required to get it, and no pitch
-inside it. If the read turns into a build, it is the first mile of that engagement.
+inside it. If the read turns into a build, it is the first mile of that engagement. The read is
+free; the live Scan Analysis call is $497, booked from the same page.
 
 ## The name
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bigsteele/the-big-sean",
-  "version": "0.2.1",
+  "version": "0.3.0",
   "description": "The Big Sean: the Launch Report Card, by Big Steele and LaSean Pickens. Runs the Big Steele AI Audit, drops a 140-check launch-readiness and autonomy audit protocol into a repo for Claude Code to run, names the deliverable after the app, 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",

package/prompt/THE-BIG-SEAN.md

@@ -13,6 +13,7 @@ Rules you never break:
 	•	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.
+	•	IDENTIFY THE TARGET BEFORE YOU READ IT. Every live system you touch must be proven to belong to THIS repository before you run a single query against it, and the proof goes in SOURCES.md. See Step 1's identity gate. Reading a database that belongs to someone else is not made acceptable by being read-only.
 Step 0. The AI Audit (already run for you, or run it now)
 If .planning/launch-audit/ai-audit-<app>.md and ai-audit-<app>.json exist, big-sean ran the Big Steele AI Audit before handing you this protocol. Read both. They are evidence, cited like any other: use their findings for the checks about surfaces, model calls, tools, loops, reach, and failure visibility in Part B, and cite the file and the criterion. If they are missing, run `npx @bigsteele/ai-audit --repo . --out .planning/launch-audit` yourself (it is read-only, writes only those two files, and never opens an env file), then read them. The AI Audit's score, grade, and level go on the summary card as the AI readiness line. It replaces no check: an agent-runnable architecture still has to pass every gate.
 The AI Audit is deterministic: it reads files and counts patterns, and it can miss an agent surface that lives outside the main app (Deno edge functions, workers, a separate service, a hand-written MCP server with no SDK). Never accept its zeros on faith. If it reports zero or near zero for the MCP server, tool definitions, or memory between runs, go read supabase/functions, workers, api, and any folder named mcp, tools, agents, or intelligence yourself before grading. Where you find a surface the scanner missed, grade the capability as present with your own evidence, and record a separate finding: the surface is not discoverable (no SDK declaration, no server card or mcp.json, no mention in README, AGENTS.md, or llms.txt). Claude, Cursor, and ChatGPT discover software the way the scanner did. An agent surface a scanner cannot find is one an agent cannot find either, and that is the real finding, not the zero.
@@ -25,8 +26,18 @@ Look for what is already on this machine and use it read-only. Do not ask me for
 	•	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 IDENTITY GATE (do this before the access ladder, for every live system).
+A repository names its own infrastructure. Anything else on your account, in your MCP servers, or shared with you belongs to someone else until proven otherwise.
+	•	Derive the target from the REPOSITORY, not from your tools. For Supabase: the project ref in the URL in .env, .env.local, .env.production, or .env.example (the subdomain of SUPABASE_URL / VITE_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_URL), or project_id in supabase/config.toml, or the ref in a deploy script or CI workflow in this repo. For every other provider: the account, project, or resource id named in the repo's env, config, or CI. Write down every candidate ref you found and the file and line that named it.
+	•	A ref written in prose is a claim, not proof. A project ref that appears only in a planning document, a README, a USER-INPUTS.md, a handoff note, or a chat transcript is a CLAIM. Record it as a claim and try to confirm it against an env file, config.toml, or CI. If the claim and the config disagree, that disagreement is a FINDING (the repo does not know which project it deploys to), and you do not resolve it by picking one.
+	•	Never let a tool choose the target. list_projects, a CLI's default project, a linked project on this machine, and an MCP server's configured connection are all candidates, never answers. Match a candidate to a ref the repository named. If a tool exposes exactly one project and the repository names none, that is still not a match.
+	•	No match, no query. If you cannot tie a live system to a ref this repository names, do not read it. Mark every check that needed it UNKNOWN with the reason "target not identified from the repository", list the candidates you saw (refs only, never their contents), and say what would resolve it: a URL in the env, project_id in config.toml, or the owner naming the ref.
+	•	If you query something and then discover it does not match, stop, discard those findings, say so in SOURCES.md and in the report, and mark the checks UNKNOWN. Findings from an unidentified system are not findings about this app; reporting them as such is worse than reporting nothing.
+	•	One target per system. If several refs match, ask which environment the report is for by writing the ambiguity into SOURCES.md and grading only the one the repo's production config names, and treat the others as out of scope.
+	•	Record in SOURCES.md, for every live system: the identifier you targeted, the file and line in this repository that named it, whether it was confirmed or only claimed, and the rung that got you in.
+
 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.
+	•	Database (Supabase or Postgres): 1 Composio Supabase tools, but ONLY against the project ref the identity gate confirmed from this repository: list projects, match the ref, and if no project matches, stop and mark UNKNOWN rather than querying the nearest one; 2 a Supabase MCP server in this session, subject to the same match (an MCP server is often pointed at a different project than this repo deploys to, and it will answer anyway); 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.
@@ -34,7 +45,7 @@ The access ladder. For every system, climb every rung before you write 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.
+Write a table SOURCES.md: every system you found, the identifier you targeted and the file and line in this repository that named it, whether that identifier was confirmed from config or only claimed in prose, 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. A row with a live read and no confirmed identifier is a defect in the audit, not a finding about the app. 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.
@@ -344,6 +355,8 @@ Big Steele and LaSean Pickens wrote this standard because they build what it gra
 **bigsteele.com/scan** Upload this file. You get a written read back. No call required to get it, and no pitch inside it.
 
 If the read turns into a build, it is the first mile of that engagement. The path to 100 above is the plan; the read tells you where to start.
+
+The written read is free. If you want it walked through live, the Scan Analysis call is $497, booked at the same page.
 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