83cca68965
Christian: 'If we can give it a higher rating or if we can dispel rumors, then we need to make that part of our first post.' Discipline first: debunking a rumor must not buy score, or the instrument becomes a PR department with a database attached. What the rumors actually did was correct one under-informed dimension. - incident_record 7 -> 8. The 2026 'Signal was hacked' panic is a documented phishing campaign. FBI/CISA PSA260626 says plainly that the app and its encryption were not compromised, Signal published a precise correction within days and shipped linkage confirmations by 2026-05-13. Fast, accurate, independently corroborated. - Total 75.9 -> 76.4. Half a point. That is the correct size. - Everything else was already priced in: the OTF funding was already docked under ownership, the phone number already docked under user control. Evidence rows added for the FBI advisory, Signal's statement, the itemised ,955,000 OTF funding record (2013-2016), and the UK/Sweden exit commitments. The recompute gate verified 76.4 from the weights and scores, not from trust. |
||
|---|---|---|
| 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)