At some point in any design project, you have to stop building and start reading. Not skimming — reading. Every sentence. Every number. Every room entry against every table that references it. We'd reached that point, and it was overdue.
The full rules document is approximately 136,000 characters. The room glossary covers all 80 rooms across a dynamic sortable table. There are nine separate card decks, a design deviations tracker, a difficulty curve comparison, a shopping list, a setup reference, five blog posts, a rank track reference card, and an inventory checklist. These documents were built across many sessions, over weeks, with decisions that changed — sometimes reversed — between sessions. The errors weren't random. They had specific causes, and those causes are worth documenting, because anyone building a complex rules package will run into the same traps.
The gem cost problem — why 20 rooms were wrong
The most pervasive class of error was gem costs. We'd populated the room glossary early in the project with estimated gem costs — reasonable guesses based on what we knew about the VG at the time. Many were correct. Many weren't. The glossary was the authoritative source for the tile-back print sheets and the rules, so whatever was wrong there propagated outward.
When we finally did a proper research pass — pulling directly from the fandom wiki category pages for Cost 1 Gem, Cost 2 Gems, Cost 3 Gems — we found 20 incorrect entries. The biggest surprises: Cloister was listed at 1 gem (it's 3), Vault at 0 gems (it's 3), Veranda at 1 gem (it's 2), and all three base-game shops — Kitchen, Commissary, Locksmith — at 0 gems when they're each 1. The shop discovery in particular changed the feel of the game. Accessing a shop costs a gem. That's meaningful economy tension that the early doc had simply erased.
The fix required sweeping the glossary, the rules, the room setup reference, the shopping list, and the table layout diagram. Five documents, 20 corrections. After applying them, the glossary was reverified by running a Python script against the corrected data. Then the user asked to confirm specific counts — "1 gem, 19 of 80 rooms" — and the script returned 18. Two more sessions of diagnosis revealed the cause: the regex used to count rooms was failing to match entries with escaped apostrophes. Her Ladyship's Chamber, Maid's Chamber, and Servant's Quarters — all with a backslash-escaped apostrophe in the JavaScript data — were invisible to the naive pattern. The data was always correct. The counter was wrong. That distinction matters: a broken tool is less alarming than corrupt data, but it still breaks your confidence in everything the tool tells you.
Never trust a count. Always verify by listing. A count of 18 and a count of 19 look almost identical in a terminal output. The list either contains Servant's Quarters or it doesn't. Lists don't lie the way numbers do.
The rarity ghost
The single most embarrassing class of error was the rarity system — a system we'd explicitly removed from the design in Post 03. The decision was clear, well-reasoned, and documented: all core room tiles go into one Active Bag, no tier separation, no random exclusion of Standard tiles per run. That decision was made. And then, over the following sessions, we kept building on top of the old architecture as if we'd never made it.
The rank track reference card — the card players hold in their hands at the table — still read: "Active Deck Each Day: 43 Tier 1 + 20 of 36 Tier 2 = 63+ tiles. Tier 3 — separate stack beside board, never shuffled in unless triggered." The setup SVG diagram in the rules still showed an "Unusual Deck" box with "26 tiles · locked · unlocked by triggers." The draft step-by-step still told players to "return the other 2 to the bottom of their respective tier piles." The inventory sheet still showed the Active Bag count as "~79" — the tilde alone an admission that we didn't actually know the number.
None of this reflected how the game actually works. It was a fossil — the preserved skeleton of a design decision that had been superseded months earlier. It survived because each subsequent session started by adding new content rather than auditing old content. The rarity decision lived in Post 03 and in the design deviations tracker. It did not live in the rank track card, because nobody went back to update the rank track card.
The fix was surgical but extensive. Seven files needed changes. The Active Bag count was corrected to exactly 57 tiles — no tilde, no approximation. The rank track card was rebuilt to show the single-bag draw procedure. The setup sequence steps were rewritten. The tier terminology was purged.
The Terrace inversion
This one required a moment of genuine disbelief when I found it. The Terrace room entry contained this sentence:
"Drafting it before a Greenhouse (saves 3 gems), a Cloister (saves 1), and a Solarium (saves 1) effectively nets a 4-gem profit on a 1-gem spend."
Greenhouse costs 1 gem. Cloister costs 3 gems. The note had them exactly backwards — the savings figures for both rooms were swapped. The math was also wrong: even correcting the reversal, 1 + 3 + 1 = 5 gems saved, not 4. The net profit was also understated.
How does something like this happen? The note was written during a session when the gem costs for Greenhouse and Cloister hadn't been verified yet. They were placeholders. When the gem costs were later corrected in the glossary and the components table, the note in the Terrace room entry was not. It sat there, plausible-sounding, wrong in every detail, for several sessions.
This is the most dangerous kind of error in a rules document: not a missing rule, not an obvious contradiction, but a confident-sounding sentence that leads a player to a completely incorrect understanding of how resources work. A player reading this would draft the Greenhouse expecting a 3-gem savings and be confused when they only got 1 back.
The Greenhouse mechanic that wasn't
In the win condition section — a passage describing how to unlock the south Antechamber door via the Greenhouse lever — there was a bonus mechanics description that I don't know the origin of:
"While the Greenhouse is in your house, once per draft you may draw 1 additional tile blind from the Active Bag and swap it for any one of your current 3 drawn tiles. The swapped-out tile returns to the Active Bag."
This mechanic does not exist in the video game. The Greenhouse's actual effect is that Green Room tiles appear more often in draws while it's on the board — a probability weighting, not an additional draw action. What we'd written was essentially the Library's mechanic, attributed to the wrong room. It had been sitting in the document, unquestioned, through multiple reviews. Possibly written during a session where we were trying to translate the "Green Rooms surface more often" effect into something physical and concrete, and went too far.
The honest fix was to replace it with an accurate description: the Greenhouse creates a natural probability effect from the bag composition. No additional mechanical step. Flag for playtesting if Green Rooms feel underrepresented. We don't yet have a clean board game translation for weighted probability, and pretending we do is worse than admitting the gap.
The meal card phantom
The meal card deck was documented as having 6 cards in the inventory sheet, 6 in the card table of contents, and "5 cards, used in order" in the Dining Room rules section. All three numbers referenced the same physical deck. The actual meal_cards.html file showed 5 named meals on sheet 1 and a single named meal on sheet 2 — with the second slot on sheet 2 marked card-blank. An empty div. A layout artifact from making the sheet come out even.
There was never a 6th meal. The count of 6 had been entered at some point — possibly when we were considering adding a sixth meal to balance the deck — and then the card was never designed, but the count was never corrected. The inventory said 6. The rules said 5. Players using both references simultaneously would have caught the contradiction immediately. We caught it during the audit instead.
The apostrophe problem
Three rooms — Her Ladyship's Chamber, Maid's Chamber, Servant's Quarters — were intermittently invisible to scripts that analyzed the glossary data. The rooms were in the file. The data was correct. But the JavaScript object used a backslash-escaped apostrophe in the name field (name:'Servant\'s Quarters'), and the naive Python regex used to count and verify rooms didn't account for the escape character. It matched name:'([^']+)', which terminates at the first unescaped single quote — cutting off before the apostrophe in the room name.
The consequence was a persistent phantom error. Scripts would report 77 rooms when there were 80. Servant's Quarters would be missing from 1-gem lists. The gem cost correction pass initially missed it. Every time we ran a count, it was silently wrong. The fix was a corrected regex that handled escaped characters: name:'((?:[^'\\]|\\.)+)'. Three rooms immediately reappeared.
There's a small irony here. Servant's Quarters is specifically the room where you collect a key for every Bedroom currently on the board — the late-game key-generator that rewards patience and careful building. It was itself invisible to our tools until we built the right instrument to find it.
When a count is wrong but the data looks right, suspect the tool. Run the list instead. The regex [^'] is seductive because it's compact and usually correct. But "usually correct" is exactly the failure mode you can't afford in a data-verification script.
The full error inventory
| Error | Type | Root cause |
|---|---|---|
| Veranda gem cost: 1 gem in room entry, 2 gems in glossary | Critical | Gem cost research pass updated the glossary but not the room entry paragraph |
| Terrace savings note: Greenhouse and Cloister gem values swapped | Critical | Written before gem costs were verified; never updated after verification |
| Cloister dirt spot count: 2 in table, 1 in room entry | Critical | Table and entry written in different sessions; one was never updated to match the other |
| Observatory star trigger: "drafted and entered" instead of "drafted" | Critical | Inaccurate translation; a player following this literally would withhold the star if they didn't enter |
| Meal card count: 6 in inventory, 5 in rules | Critical | Layout artifact (blank card for even sheet count) was miscounted as a real card |
| 20 gem costs wrong across the glossary | Critical | Early estimated values never verified against source; propagated into multiple documents |
| Rarity system language throughout: Tier 1/2/3, 63+ tiles, Minor Key, return to tier piles | Critical | Post-03 rarity removal decision not propagated to rank track card, setup SVG, or step-by-step procedure |
| Greenhouse mechanic: invented Library-style swap mechanic attributed to wrong room | Critical | Placeholder translation of "Green Rooms more common" that went too far and was never caught |
| Pantry: two sections contradicted each other on whether coins respawn | Clarity | Entry written at different times; one said "gives 4 coins on subsequent entries," the other said "no reward" |
| Veranda passive: "dig yields" in bullet, "Common Items draw" in rule text | Clarity | Bullet written loosely; never reconciled against the specific mechanic in the paragraph above it |
| Commissary runs 20–21 pricing: appeared without explanation of how runs are tracked | Clarity | Copied from VG lore context without establishing the tracking mechanism for board game |
| Apostrophe rooms invisible to count scripts: 77 reported, 80 actual | Tooling | Regex [^'] breaks on escaped apostrophes in JS object literal syntax |
Why none of this is surprising
None of these errors are inexplicable. They're all consequences of the same underlying condition: a document built across many sessions with many decisions, where the cost of going back to verify previous work was always competing with the pull of making forward progress. That's the normal state of a design project. The errors accumulate quietly.
What helps is having a specific triggering event — a reason to stop and audit rather than continue adding. Ours was the tile-marking task: the user was physically about to write gem costs on 29 tiles with a marker. Getting those wrong would mean correcting physical artifacts. The cost of error had become tactile and immediate. That's what prompted the research pass, which found the 20 wrong gem costs, which triggered the full document sweep, which found everything else.
The lesson isn't "do more audits" — that's obvious and unhelpful. The lesson is to identify the moments in your production process where the cost of error becomes physical. Printing. Cutting. Writing. Those are the checkpoints. They don't happen often enough to catch everything, but when they do, they're worth treating as an audit trigger rather than just a production step.
The rules document is now the most internally consistent it's ever been. That consistency won't survive the first real playtest unchanged — some rule will interact with another rule in a way nobody anticipated, and something will need to change. But at least we'll know the errors that surface at the table are new ones, not old ones we missed.
Photo card — design using in-game Apple Orchard screenshot. Special key tokens — 4 custom tokens still needed. Kitchen menu card — Silver Spoon and Showroom references need cleanup. Difficulty curve decision — held for playtesting.