Article Scope
How To Use This Article
Good articles frame judgment and failure patterns. They should not pretend to replace the live database, calculator, or detail page once the question becomes exact.
Read this when the question is judgment, not raw lookup
Our patch workflow for Slay the Spire 2: find what changed, isolate the assumptions those changes break, update the source data, and only then refresh the editorial layers and tools.
Longform still has a boundary
Once the question becomes exact card text, room totals, or calculator inputs, stop forcing one article to own live data and open the linked page that carries the current surface.
What a verification pass actually looks like
Patch-safe publishing is mostly dependency hygiene done in the right order.
Read how the data station is built
This article should hand you off cleanly. Open Read how the data station is built when the argument needs a live tool, database, or narrower follow-up page.
Maintenance Signals
Who Maintains This Page
This block keeps article ownership and scope visible without forcing the whole page to repeat the same trust speech.
Maintains site-build explainers, methodology notes, and articles about how the project is structured and reviewed.
Final site operator and responsible editor. Final contact for corrections, rights notices, and maintenance triage via [email protected].
The visible post body, related links, and article-level metadata were checked on the article update date shown here.
This verification workflow revision rechecked the page's main argument around "We verify the rule first, then the data row, then every tool or guide derived from it". It also re-read "Patch notes are not enough" so the visible examples still support the same decision line. The linked live pages were verified again so the article still hands the reader off cleanly when the question turns exact.
If a patch breaks a claim in this article, the post should be revised, narrowed, or replaced instead of silently drifting.
Use the linked tools, detail pages, and databases when you need the live underlying numbers behind the argument.
Good judgment pages still carry opinions. When the page links to a calculator or database, that linked page owns the raw reference surface.
Patch Reality
Patch notes are not enough
The first mistake after any update is assuming the official note already tells the whole story. Patch notes are useful, but they are still summaries. They often omit edge conditions, interaction changes, category reassignments, or knock-on effects that matter to tools much more than to casual reading.
So our workflow starts with identifying what class of rule changed. Was it a numeric breakpoint, a timing interaction, a data tag, or a relation between systems. That classification decides which downstream pages need scrutiny.
Workflow
What a verification pass actually looks like
Patch-safe publishing is mostly dependency hygiene done in the right order.
- Classify the kind of rule that moved
Start by deciding whether the patch changed a breakpoint, timing interaction, data tag, or relation between systems, because that tells you where the downstream risk lives.
- Update the source data before the summary copy
The data row changes first so calculators, guides, and detail pages are not asked to narrate stale numbers with fresh prose.
- Audit every consumer that derived meaning from the change
This is the boring middle most sites skip, and it is also where quality actually lives.
- Remove or narrow pages if certainty is not ready
If the rule is still unclear, the honest move is to hide, narrow, or rewrite rather than bluff with a timestamp.
Verification Pass
What gets checked after the source data moves
A row update is not a finished verification pass if downstream pages were deriving strategy from it.
- Patch scan identifies affected systems.
- Source data is updated before editorial summaries.
- Derived tools and guides are checked for broken assumptions.
Confidence Rule
When we would rather remove than bluff
Sometimes the honest answer after a patch is that a page or tool needs to be temporarily narrowed, rewritten, or hidden until the rule is clear again. We would rather do that than leave a polished page live that now rests on stale assumptions.
Users do not benefit from brave-looking uncertainty. They benefit from a site that knows when its own confidence should drop.
Problem Definition
A patch pass is not a timestamp pass
The dishonest version of patch maintenance is trivial: change a date, skim the obvious notes, and hope nobody notices which downstream pages still depend on the old assumption. That workflow produces the worst kind of stale page because everything looks freshly maintained while the actual claim is already detached from the live game state. A serious patch pass has to begin by identifying which rule moved, which pages were depending on that rule, and which user decisions become dangerous if the old interpretation survives one more day.
That is why we treat patch verification as dependency repair instead of text refresh. Enemy HP changes do not only affect enemy pages. They change Doom lethal thresholds, rest-site greed, potion hold-versus-spend logic, boss pacing, and any article that was using the old breakpoint as a hidden premise. The real work is finding those dependency chains early enough that a clean-looking page never gets to tell the wrong story with full confidence.
- A page is not safe because the source row was updated once.
- A page is only safe when the downstream judgment layers were rechecked against the new rule.
- If the team cannot recheck the downstream layer honestly, the page should narrow its claim or temporarily stop making it.
Workflow Compare
What gets patched first and what must wait
The order matters because patch work breaks the moment summary copy gets ahead of verified rules.
Hard Gate
When we should refuse to mark a page as updated
A page should not get a fresh date just because it was opened in an editor. We hold the update label when any of these conditions are still true.
- The page still depends on a derived calculator or threshold that has not been rechecked.
- A key recommendation is still leaning on pre-patch room pacing or route pressure.
- The team understands the raw number change but not the new decision boundary it creates.
- The page still needs a narrowed claim, warning note, or deindex decision to avoid overstating certainty.
Failure Mode
The most dangerous patch error is silent confidence
A page that is obviously stale is annoying, but a page that looks maintained while carrying an invalid assumption is worse. Users stop checking the boundary of the claim because the maintenance signals told them that boundary had already been handled. That is exactly why we tie patch work to dependency checks, visible update dates, and selective deindexing when the human layer cannot be repaired quickly enough.
In practice, this means some pages should temporarily say less after a patch. That is not weakness. It is the difference between a site that admits uncertainty and a site that launders uncertainty through polished timestamps. Google and users both punish the second version more harshly, because it is not merely incomplete. It is misleading.
More From The Blog
Next Articles
How to Use the Event EV Calculator Without Faking Precision
An EV tool is useful when it sharpens a close decision. It becomes dangerous the moment you feed it fake confidence, bad route assumptions, or a run state you have not described honestly.
- The tool helps when the input state is concrete and the next decision is real.
- It lies when the player buries route risk, survivability, or hidden preferences under fake neutral numbers.
How We Built the Slay the Spire 2 Early Access Data Station
A practical look at how STS2 Calculator turns early-access patch churn into usable tools, cleaner reference pages, and original editorial work instead of recycled database sludge.
- We design tools around decisions, not around showing off raw tables.
- Every reference page is tied back to a real route, combat, or deck-building question.
Input Assumptions Behind Every Tool on This Site
Every calculator makes assumptions. This page spells out what ours do, where the models are intentionally strict, and where results can drift from a real run if the input state is incomplete.
- Our tools model the variables that most often change the decision, not every decorative edge case.
- If an input is missing, the result is only as honest as the assumption replacing it.