cold-reopen — the check that happens later, cold

cold-reopen — the check that happens later, cold

In the world of build systems, "cold-reopen" is an essential skill. It isn't about verifying something immediately after it's built; it's about returning to a feature, task, or claim after it's been marked complete and left alone for at least a week. The idea is simple: check whether it still holds up unassisted by the fresh context you had during its creation. This need was minted on 2026-09-25, and it fills a gap that existing checks like section-pass and seam-check, which handle boundaries and parts, don't cover.

Why cold-reopen matters

Cold-reopen emerged from recurring failures in our ecosystem. For example, the "week two" test mentioned in OWNER-EXPERIENCE-SPINE.md and the case from OWNER-SETUP-STEP-PATTERN.md where abandoned steps were only identified by client feedback, highlight the need for such a check. The 2026-09-16 keepbooth incident, where a green test suite coexisted with a broken production route for two days, underscored the importance of revisiting assumptions after time has passed.

How to perform a cold-reopen

When conducting a cold-reopen, approach it as if you were a stranger to the project:

1. Erase prior knowledge. Do not rely on your own commit history or previous reasoning. Use only the public documentation, live URLs, task state, and the screen itself as your guides.

2. Reconstruct and test the claim. Determine what "done" meant when the item was shipped by referring to specifications, task acceptance criteria, or a certification's effectiveState. These are the artifacts that should define completion, not memory or prior discussions.

3. Evaluate current truth. Compare the original claim against the current state of the world. Changes in dependencies, world context, or even the stagnation of the feature might reveal different outcomes now compared to when it was first verified.

Identifying candidates for cold-reopen

Look for anything marked complete that hasn't been re-verified since its initial completion. Ideal candidates include:

• Features marked live in owner-feature-certifications.json that haven't been revisited post-release.
• Owner tasks with an approved or submitted status based solely on self-reports, especially the kind flagged in OWNER-SETUP-STEP-PATTERN.md §4.
• Documentation claims marked as "proven" or "WORKS" without a recent re-run date.

Cold-reopen isn't a first-time check or a boundary test. It is uniquely about the passage of time, and its value lies in revealing whether something once true still holds in the present. The goal is to ensure that what was built stands the test of time, even after the immediate context has faded.