@bigsteele/the-big-sean 0.5.0 → 0.5.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bigsteele/the-big-sean",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "The Big Sean: the Launch Report Card, by Big Steele and LaSean Pickens. Runs the Big Steele AI Audit and Wiremap, 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

@@ -61,6 +61,7 @@ Write NORTH-STAR.md, and keep every line traceable:
 	•	Confidence. High where a pricing page and a schema agree; low where you are inferring from code shape alone. Say which.
 	•	Anything you could not determine. Write UNKNOWN and say what would settle it. Never invent a mission.
 If the evidence contradicts itself, that is a finding, not a puzzle to resolve quietly: a README promising one thing while the code and the money path serve another means the team does not agree on what it is building, and it goes in the report as its own finding with both citations.
+A PRIOR NORTH STAR OR REPORT CARD IS A CLAIM WITH A DATE. If a NORTH-STAR.md or an earlier "The Big Sean - <App>.md" already exists in this repository, it was true at the commit it names, and the code has moved since: note its date and commit, run `git rev-list --count <commit>..HEAD`, re-derive the North Star from the evidence as it is NOW, and record every difference as a finding with both citations. Never inherit the critical few, a score, or an evidence entry from a prior run; a check proven at an old commit is UNKNOWN at this one until it is proven again. NORTH-STAR.md carries a Provenance line: prior file and its commit, HEAD, commits since, what moved.
 THE DRIFT RULE, which governs the rest of this audit. Every FAIL, every UNKNOWN, and every recommendation must connect to the North Star. In the action plan and the path to 100, each item carries one line, "why this matters here", that names the workflow, the money path, or the critical few it protects. An item that cannot make that connection is not dropped and not silently downgraded: it is grouped under "Rubric items that do not serve your North Star" with a one-line reason, so the owner sees you considered it and why it waits. Ordering follows the North Star, not the rubric's numbering: two weight-5 failures are not equal when one breaks the money path and the other breaks a surface nobody has shipped yet. Never recommend building a capability the North Star does not need just because a check exists for it. If the audit's honest conclusion is that the app should do less, say that.
 Now learn the app. Start from the block map (the repository's own, or Wiremap's draft): it tells you what the product does and which files implement it, so you can read the blocks that matter instead of walking the tree. Then read the planning docs, README, specs, and any state files. 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. Where it disagrees with NORTH-STAR.md, the code wins for what the app DOES and the North Star governs what it is FOR; note the gap.
 Step 3. Check the live system where you can (all read-only)