21208d50ab
Christian: 'I want them to put the BigTech.Sucks rating badge on their site. It should be marketing for them.' A sticker anyone can copy is worthless, so it is not a sticker. - badge/<product>.svg is generated from the assessment row on every build. Score, grade and date are never typed by a human. - Served from bigtech.sucks. A copy pasted onto a vendor's own server is not a badge and its link will not resolve. The domain is the signature. - Regenerated every build, so improving earns a better badge without asking and regressing loses it without warning. - The SVG carries the record id, version and method in a comment, so a real badge can be traced back to one assessment. badges.html publishes the rules: free forever, only rated products, no badge as a favour, and misuse called out publicly. Free matters, because charging for it would make it worthless to both sides: marketing for the vendor, receipts for their customer. Also rewrote the write pass to emit report + badge per assessment in one loop, so they can never drift apart. |
||
|---|---|---|
| deploy | ||
| packages | ||
| .gitignore | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
bigtech.sucks — Draw the Line
V0.1 scaffold per master spec. A retro frontier game that scopes Big Tech exposure and sequences the off-ramp.
Structure
packages/
core/ Render-agnostic game logic, seed data, scoring
core/db/ The living database: schema, seeds, build + verify
web/ React + Vite SPA (V1 funnel)
server/ Minimal waitlist API (email + channel only)
The living database
The database is the source of truth. The site is a view over it. Nothing in the UI may
hardcode a number that lives in bigtech.db.
npm run db:build # rebuild the db, apply seeds, verify, regenerate the catalog
npm run db:verify # run the instrument's own checks against the existing db
packages/core/db/bigtech.db is built, not committed. What is committed is the part that
matters: db/schema.sql, db/seed/*.sql, and db/build.mjs.
The build refuses to pass if a score breaks the instrument's own rules:
- dimension weights must sum to 100
- every stored
weighted_totalmust recompute from its scores - every grade must match its band
- every score must carry a written rationale
- no tier-4 claim may attach to a scored dimension
- the reproducible-build caps are enforced, not documented: no reproducible build caps verifiability at 3, an experimental one at 6
A product with no assessment surfaces as unassessed. It is never given a guessed number.
That is why the 43 legacy roster entries sit in the database as placeholders and exactly one
product carries a real score.
Adding an assessment
- Write
packages/core/db/seed/000N-<slug>.sqlusing the shape in0001-signal.sql. - Every score needs a
rationaleand at least three tier-1 or tier-2evidencerows. npm run db:build. If it fails, the report is not ready to publish.
What the numbers mean
See the instrument spec. Scores are 0 to 100, and a weighted average is not the headline: the weakest dimension is, because a 90 with a 5 on local data exposure is a 90 that will leak.
Quick start
npm install
npm run build -w @bigtech-sucks/core
npm run dev # web on :5173
npm run dev:server # waitlist API on :3001
V1 flow
Welcome → Meet Red → Draw the Line → Overworld → Showdown → Homestead → Reveal (Binary Ranch) → Waitlist
Governance
- Creative assets are candidates — director approval required before ship
- Company name revealed only at homestead/reveal phase
- §13 open decisions are not silently resolved (see
packages/core/src/data/config.ts) - Client-side sovereignty report; server stores waitlist fields only
Roadmap
- V1.5: Terminal/SSH render (Go + Charm)
- V2: Concierge migration, journey chronicle, physical fulfillment (stubs in
v2-stubs.ts)