--- name: fo3-karma-rebuild description: "The INVENTED-DATA INCIDENT that produced the citation-guard rule, plus the standing correct-then-cite doctrine for all game data, the owner's UX ruling on the karma action buttons, and the version-stamp footgun. The rebuild itself has shipped." metadata: node_type: memory type: project originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- **Raised 2026-07-13 by the owner:** *"karma should be native, it shouldn't have to rely on AI."* The deterministic karma engine was built and has since shipped. **The cited dataset is the repo's source-of-record under `planning/`, and the engine data lives in the per-game definitions with a per-value source field — read the data from there, never from this file.** *Correction 2026-07-20: this file used to carry the whole karma dataset (values, titles, companion gates, thresholds), plus commit hashes, cache revisions, test counts and in-progress markers. All of it is either fallout.wiki-derivable or in the repo, and the shipped state has moved on. Removed. What remains is the incident and the doctrine, which exist nowhere else.* --- ## ⭐⭐ THE INCIDENT — THE APP'S KARMA DATA WAS PARTLY INVENTED The shipped app warned of an **"ENCLAVE HIT SQUAD RISK"** at very low karma. **There is no Enclave hit squad in Fallout 3.** The real mechanic is two *opposed* factions: one hunts you at evil karma, the other hunts you at **good** karma. ⇒ The app named **the wrong faction**, at **the wrong threshold**, and **completely missed that being GOOD gets you hunted too.** Nobody sourced it. **Somebody made it up.** ⚠ **That was a LIVE violation of the sourcing rule sitting in shipped code** (*"Fallout game data: source from fallout.wiki only. The AI acts as typist, not authority"*) — **and nothing caught it, because that rule was honour-system.** ⇒ **This incident is the evidence for the CITATION GUARD:** every game-data constant must carry a `fallout.wiki` source citation. The pattern already existed in the code voluntarily; it simply wasn't *required*. **It's greppable ⇒ it can be an axiom, not a guideline** ([[reframing-review-2026-07-13]]). ## ⭐⭐ IT WAS NOT ISOLATED — the FO3 data-provenance sweep (2026-07-14) The karma finding triggered a sweep of **all** FO3 data against the wiki. **Verdict: NOT a one-off.** Quests, skill books, companions and item names were clean; the karma engine itself came out the gold standard (cited and correct). **Two areas were broken:** a handful of **fabricated or misattributed perks** (including one lifted from a different game), a large share of **wrong perk unlock levels** and some wrong bobblehead locations, and a **weapon-stats table with values inflated by roughly an order of magnitude.** ⭐⭐ **THE LOAD-BEARING LESSON — a citation guard checks that a LABEL EXISTS, not that the NUMBER IS RIGHT.** The weapon table proves it: it already carried `// Source: fallout.wiki` comments and was still wrong. ⇒ **STANDING RULE FOR ALL GAME-DATA WORK: generalizing the citation guard stops FUTURE invention but cannot clean EXISTING wrong data. You need a real re-checking pass, and you must CORRECT-THEN-CITE — never stamp "verified" on a number you did not check.** ## ⚠ WHAT WAS *NOT* BROKEN — Dispatch's own error, recorded The five karma bands in the code were **exactly right.** ChatGPT claimed the boundary inclusivity was wrong — **it was wrong about that, because Dispatch fed it a sloppy *paraphrase* of the code instead of the code itself.** The real source matched the wiki byte-for-byte. ⭐ **LESSON: never audit a paraphrase. Audit the code.** ## STANDING RULES THAT CAME OUT OF THE BUILD - ⚠ **UNVERIFIED FIELDS SHIP AS `null` WITH A VERIFICATION STATUS — never as a guessed number.** Where the wiki is silent (e.g. hit-squad spawn frequency: it says "repeatable" and gives no timer or probability), **do not encode an invented interval or percentage.** Where two wiki pages conflict, record the conflict; do not pick one silently. - ⚠ **KILL PENALTIES ARE NOT DERIVABLE FROM AN NPC'S DISPLAYED ALIGNMENT.** The wiki warns the penalty depends on the target's *programmed faction data*, not its shown morality. ⇒ **Do NOT write `if (npc.karma >= 250) player.karma -= 100`.** Give NPC records an explicit per-record delta field. - **Two separate layers, do not collapse them:** the numeric karma status has **five** bands, but the title table has only **three** alignment columns. **Do not use the five-tier label as the title-table key.** - **All of it is per-game DATA in the game definitions, never a literal in feature code.** Every constant carries its citation. - **Zero AI at runtime.** Deterministic, offline, native — this is *deterministic-by-default* doing real work ([[player-control-principle]]). ## ⭐ THE OWNER'S UX RULING ON THE ACTION BUTTONS (2026-07-14) — verbatim > *"tapping one of those new buttons should do a pop-up in the top right like changing location does. also they should actually look clickable instead of how they look now. it's messy and confusing and not organized or clickable looking."* Two fixes: (1) applying a karma action fires **the existing top-right toast** — the same transient toast a location change uses. **Reuse it, don't invent one.** (2) The action buttons must **READ as buttons** — bordered/filled, organized, obviously tappable, meeting the minimum tap-target size. Consider Fable for the visual if a plain CSS pass isn't enough. **Everything else about the engine stays.** *(Whether this has since been implemented: check `QUEUE.md` and git log.)* Also from the owner: the slider should **not** be the primary interface. The event-log picker is the main input — the player taps what they did and the app computes karma, title, tier and companion availability. **The slider survives as a manual override.** He also spotted that the panel printed the same alignment label twice; one board should read slider → title → number → what it unlocks. ## ⚠ THE VERSION-STAMP FOOTGUN — RECORDED A build session reasoned "new feature → MINOR bump" and stamped a new `APP_VERSION` on the development branch. **Wrong:** on `dev` the version does **not** bump per unit — it stays put, work accrues under `[Unreleased]`, and it bumps only at the dev→main release. Worse, it **committed and pushed before Dispatch's mid-run corrections were read** — *a long uninterrupted run does not process queued messages.* ⇒ **LESSON (see also [[dispatch-autonomy-preference]]): for any version- or release-sensitive unit, put the version instruction IN THE BRIEF. Mid-run correction is unreliable.** Related: [[fo3-pipboy-program]], [[player-control-principle]], [[reframing-review-2026-07-13]] (deterministic-by-default; axioms vs guidelines), [[deep-systems-review-2026-07-13]], [[data-provenance-program-complete]].