Your First January Re-Entry Wednesday Smoke After Holiday Freeze in One Evening - 2026

January 3, 2027: the repository opens, the CI badge is green, and everyone remembers that the demo worked before the break. The last December defer receipt says holiday_defer_ok: true. But the installed build on the test laptop is three weeks old, the Steam branch has an ambiguous label, one contractor returned with new audio banks, and nobody can say whether the binary currently downloadable by a player is the binary that entered the freeze.

That is why January 2027 re-entry needs its own smoke. February Steam Next Fest preparation resumes immediately after the holiday break, so “it passed in December” is not enough. A safe restart proves that the frozen build label, remote branch, cold install, save state, golden path, and clean quit still agree before any deferred feature or February RC work lands.

This beginner tutorial takes one evening and produces january_reentry_smoke_receipt_v1.json with gates R1–R6. It extends the weekly Wednesday demo smoke ritual, but it is not a duplicate: the weekly ritual asks whether this week’s candidate can be promoted; this re-entry pass asks whether the holiday-frozen baseline can be trusted before development resumes.

Non-repetition note: December defer owns Ship/Freeze/Defer scope. Friday capstone review owns the pre-freeze capstone latch. The regular Wednesday ritual owns recurring binary promotion checks. This page owns the first post-freeze cold-install baseline, frozen-label reconciliation, and re-entry receipt.

Pair it with the February 2027 prep calendar, the Steam Playtest branch isolation resources, BUILD_RECEIPT channel-label troubleshooting, the jq January reentry capstone pointer sketch (re-run November verify before February RC), and Course 276 November close-out capstone forward.

Why this matters now

1. The February clock restarts immediately. January is not a relaxed month for teams targeting February Next Fest. RC labels, store uploads, trailer checks, and creator outreach begin while people are still returning.
2. A freeze preserves intent, not necessarily reality. Steam branches can be relabeled, cloud saves can sync, certificates can expire, CI caches can change, and a “harmless” holiday hotfix can move a depot.
3. Contractors return asynchronously. Art may be back January 3 while audio returns January 8. A baseline smoke separates the trusted frozen build from new work.
4. Local installs lie by omission. A warm developer install can contain loose files, old banks, cached Addressables, or saves that a player never receives.
5. Receipts need a re-entry edge. december_freeze_allowed: true describes the start of the freeze. january_reentry_smoke_ok: true describes the first verified state after it.

Direct answer: do not merge deferred January work first. Record the frozen build_label, download the remote branch into a clean library, test launch → first input → 60-second golden path → save/load if applicable → clean quit, compare the result to BUILD_RECEIPT, and file january_reentry_smoke_receipt_v1.json. Only then open the branch for February RC changes.

What you will finish tonight

Time: 60–90 minutes for the first re-entry; about 20 minutes in future years after the runbook exists.

You need:

• Access to the player-facing Steam or test branch.
• The final December BUILD_RECEIPT.json.
• december_defer_receipt_v1.json or the equivalent freeze note.
• The last GREEN demo_smoke_receipt_v1.json.
• A non-development test account where possible.
• A clean install location with enough space.
• A text editor; PowerShell or bash is optional.

If you do not have BUILD_RECEIPT yet, start with the beginner BUILD_RECEIPT and upload-log pipeline. Do not invent missing December values during re-entry; mark them unknown, then investigate.

The mental model — freeze, re-entry, RC

Re-entry does not mean “unfreeze everything.” It creates a clean, reproducible starting point. If re-entry is RED, freeze remains in force while you diagnose. If it is GREEN, deferred work can resume one numbered change at a time.

Gates R1–R6

R1, R3, R4, and R6 are hard blockers. R2 is only YELLOW if a clean machine is genuinely unavailable and you document exactly what was cleaned. R5 may be not_applicable for demos without persistence, but clean quit is always required.

Step 1 — freeze your evidence before touching code

Create:

release-evidence/
  03-builds/
    january-reentry/
      2027-W01/
        notes.md
        install/
        screenshots/
        logs/
        january_reentry_smoke_receipt_v1.json

Copy references, not mutable guesses, into notes.md:

# January re-entry baseline

date_utc: 2027-01-06
tester: release-owner
surface: steam_playtest
branch: fest-demo-private
expected_build_label: fest-demo-2026-12-rc3
december_freeze_allowed: true
holiday_defer_ok: true
last_smoke_receipt: ../2026-W51/demo_smoke_receipt_v1.json

No feature merge is allowed until R1–R6 resolve.

This prevents a common mistake: opening the project, accepting package updates, rebuilding, and then trying to reconstruct what the frozen player build was.

Working-dev evidence snapshot

Before downloading, capture repository state:

git status --short
git rev-parse HEAD
git log -1 --format="%H %cI %s"
git lfs status

Put the output in logs/repo-before-reentry.txt. These commands do not prove the remote depot, but they prove what your local checkout looked like before you resumed work. If Git LFS reports pending pointers, stop: backlog #5 owns the deeper recovery case study, but R1 cannot pass on an uncertain source baseline.

Step 2 — reconcile the frozen label (R1)

Open three records side by side:

1. December BUILD_RECEIPT build_label.
2. The last GREEN smoke receipt build_label.
3. The currently assigned remote branch/depot label.

Use a tiny table:

Do not silently rename the remote branch to make the table green. A mismatch needs one of two outcomes:

• Restore the documented frozen depot, then rerun R1.
• File a numbered holiday SHIP exception showing why the label moved, what changed, who approved it, and which smoke covered it.

The player-visible build-label opinion explains why a label visible in screenshots and bug reports is more useful than a portal-only build number.

Step 3 — perform a clean install (R2)

For Steam:

1. Sign into the test account.
2. Uninstall the demo.
3. Remove remaining files in the install directory after saving only evidence logs.
4. Confirm the intended branch is selected.
5. Install from the network; do not copy your developer build.
6. Record install start/end time and approximate size.
7. Capture the branch/library-label screen without exposing credentials.

For itch or another side channel, use its clean download path and record the channel explicitly. The goal is not “delete everything on the computer.” The goal is to approximate what a returning or first-time player receives.

Why verify files is not enough

Platform verification can confirm bytes against the currently assigned depot. It cannot tell you whether that depot is the correct frozen depot. That is why R1 comes before R2.

R2 cleanup checklist

[ ] Uninstalled prior player build
[ ] Remaining install folder inspected and removed
[ ] Persistent save location documented
[ ] Correct branch selected
[ ] Network download used
[ ] Install size plausible against December upload log
[ ] No local DLL, loose bank, mod, or debug config copied in

If saves could mask onboarding defects, rename the save directory before launch. Do not delete the only copy; store its original path and backup location in notes.md.

Step 4 — run the cold-launch golden path (R3–R4)

Disconnect the editor from your thinking. Launch from the same library button a player uses.

R3 cold launch

Record:

• Click-to-first-window time.
• Splash-to-interactive-menu time.
• Whether mouse, keyboard, and primary controller input work.
• Whether a firewall, redistributable, login, or crash dialog appears.
• The visible build label.

The pass condition is not a synthetic performance target. It is a repeatable, usable launch without a blocker. Use the December smoke threshold if one exists; do not invent a stricter January number solely to create work.

R4 sixty-second golden path

Follow the same golden path that passed before freeze:

1. Start a new run or continue the intended demo path.
2. Reach the first meaningful interaction.
3. Complete one combat, puzzle, placement, or dialogue action.
4. Open pause/settings once.
5. Listen for required menu and gameplay audio.
6. Continue for 60 seconds without soft-lock.

If the game relies on downloadable content, online auth, or remote configuration, record network state. A remote service change over the holidays can make unchanged binaries fail; that is still a valid RED re-entry result.

Capture only useful proof

You do not need a cinematic video. Capture:

• One launch screenshot with visible label.
• One screenshot or short clip at the golden-path checkpoint.
• The player log and crash folder after quit.
• A note for every warning that affects the player.

Avoid collecting personal account details. Redact Steam IDs and local usernames before partner sharing.

Step 5 — test state and clean quit (R5)

If the demo supports saves:

1. Create a new January test save.
2. Quit normally.
3. Relaunch.
4. Load the new save.
5. Confirm the same label and expected scene.
6. Quit again and check that the process exits.

Do not use only a December save. Old saves are valuable compatibility probes, but they can bypass first-run initialization. Test a new save first, then test one copied December save if compatibility is part of your promise.

If Steam Cloud overwrites the new local save, use the Steam Cloud overwrite troubleshooting guide before declaring the binary stable.

Step 6 — write the receipt (R6)

Use this starter:

{
  "schema": "january_reentry_smoke_receipt_v1",
  "tested_at_utc": "2027-01-06T19:30:00Z",
  "surface": "steam_playtest",
  "branch": "fest-demo-private",
  "expected_build_label": "fest-demo-2026-12-rc3",
  "observed_build_label": "fest-demo-2026-12-rc3",
  "december_freeze_allowed": true,
  "holiday_defer_ok": true,
  "clean_install": true,
  "cold_launch_ok": true,
  "first_input_ok": true,
  "golden_path_60s_ok": true,
  "new_save_load_ok": true,
  "clean_quit_ok": true,
  "gates": {
    "R1": "GREEN",
    "R2": "GREEN",
    "R3": "GREEN",
    "R4": "GREEN",
    "R5": "GREEN",
    "R6": "GREEN"
  },
  "evidence": {
    "notes": "release-evidence/03-builds/january-reentry/2027-W01/notes.md",
    "player_log": "release-evidence/03-builds/january-reentry/2027-W01/logs/player.log",
    "launch_screenshot": "release-evidence/03-builds/january-reentry/2027-W01/screenshots/launch-label.png"
  },
  "january_reentry_smoke_ok": true,
  "resume_deferred_work": true,
  "notes": []
}

Use null, not invented true, when a check did not run. A receipt with honest YELLOW is more useful than a perfect-looking JSON file that cannot be reproduced.

Add the root BUILD_RECEIPT row

{
  "january_reentry_smoke_ok": true,
  "january_reentry_smoke_receipt": "release-evidence/03-builds/january-reentry/2027-W01/january_reentry_smoke_receipt_v1.json",
  "reentry_baseline_build_label": "fest-demo-2026-12-rc3",
  "deferred_work_resume_allowed": true
}

Commit the receipt and BUILD_RECEIPT row together. That makes the state change reviewable: the team did not simply “come back”; it moved from december_freeze_allowed to a tested re-entry baseline.

Optional JSON validation

Working developers can run a small jq gate:

jq -e '
  .schema == "january_reentry_smoke_receipt_v1"
  and .expected_build_label == .observed_build_label
  and .clean_install == true
  and .cold_launch_ok == true
  and .first_input_ok == true
  and .golden_path_60s_ok == true
  and .clean_quit_ok == true
  and .january_reentry_smoke_ok == true
' january_reentry_smoke_receipt_v1.json

PowerShell can still invoke jq:

jq -e '.january_reentry_smoke_ok == true and .gates.R6 == "GREEN"' `
  .\january_reentry_smoke_receipt_v1.json
if ($LASTEXITCODE -ne 0) { throw "January re-entry gate failed" }

Automation should verify a human-run smoke, not pretend that JSON booleans launch the game.

RED, YELLOW, GREEN decisions

If the result is RED

1. Do not rebuild immediately.
2. Preserve the failed install and logs.
3. Compare branch assignment and label first.
4. Compare upload log and December receipt.
5. Identify whether failure is depot, local environment, remote service, or binary.
6. File one numbered fix.
7. Re-run the full R1–R6 sequence after the fix.

A quick local rebuild may hide the exact state players can download. Diagnose the frozen artifact before replacing it.

Worked example — one evening

The discovered debug config is exactly why a clean install matters. It was not evidence of a broken depot, but leaving it in place could have hidden one.

Scenarios A–H

Proof table

Common mistakes

Merging the first January task before baseline

Then you cannot distinguish a holiday drift failure from the new change. Smoke the frozen baseline first.

Testing a developer build

Re-entry concerns the downloadable player artifact. Editor Play mode is useful later, not as R2–R4 evidence.

Reusing only an old save

Old saves may skip initialization. Create a new save first, then probe compatibility.

Treating “same commit” as “same depot”

Packaging settings, generated banks, remote config, and branch assignment can differ while git commit remains unchanged.

Marking missing evidence GREEN

Use YELLOW or null. Do not turn uncertainty into a boolean pass.

Opening every deferred lane at once

GREEN re-entry establishes a baseline; it does not create unlimited capacity. Continue using the December engineering-floor ramp and resume one lane at a time.

Team handoff template

Post this in the release channel after the receipt is committed:

JANUARY RE-ENTRY — 2027-W01
Baseline: fest-demo-2026-12-rc3
Surface: Steam Playtest / fest-demo-private
R1–R6: GREEN
Receipt: release-evidence/03-builds/january-reentry/2027-W01/january_reentry_smoke_receipt_v1.json
Deferred work resume: YES
First resumed item: DEFER-014
Next gate: February RC branch-label receipt

The message is an index, not the evidence itself.

Honest limits

• A 60-second path does not replace full regression QA.
• A GREEN Windows smoke does not prove macOS, Linux, or Steam Deck.
• A cold install does not test every cloud-save conflict.
• A receipt can document a bad process as easily as a good one if nobody verifies paths.
• Steam branch behavior and festival requirements can change; confirm current details in Steamworks documentation.

For a small studio, the goal is not exhaustive certainty. It is a clear, low-cost baseline that prevents January changes from being blamed on an unverified December artifact.

Related reading across the site

• Blog: Wednesday demo build smoke
• Blog: Friday close-out capstone row review
• Resource: Steam Playtest branch isolation runbooks
• Resource: Build validation and release checklists
• Help: BUILD_RECEIPT channel-label mismatch fix
• Help: Steam Cloud overwrites local demo save fix
• Course: Lesson 265 October ops truth capstone
• Course: Lesson 276 November close-out truth capstone forward

Key takeaways

1. Run the January re-entry smoke before merging deferred work.
2. Reconcile BUILD_RECEIPT, last smoke, remote branch, and player-visible label at R1.
3. Use a clean network install; do not test only an editor or developer folder.
4. R3 proves cold launch and first input; R4 proves a 60-second meaningful path.
5. New-save testing catches initialization defects that old saves can hide.
6. january_reentry_smoke_receipt_v1.json records R1–R6 and the resume decision.
7. Add january_reentry_smoke_ok to root BUILD_RECEIPT in the same commit.
8. RED means freeze remains in force while you diagnose the downloadable artifact.
9. GREEN creates a baseline—it does not approve every deferred feature.
10. Pair re-entry with February calendar, branch isolation resources, weekly Wednesday smoke, and January unfreeze audit tools before defer merges.
11. Keep screenshots and logs useful, minimal, and free of account secrets.
12. Follow with February 2027 RC branch-label receipt before first RC upload.

FAQ

Is January re-entry smoke the same as weekly Wednesday smoke?

No. Weekly smoke decides whether a current candidate can be promoted. Re-entry verifies that the holiday-frozen baseline is still downloadable, runnable, and consistent before work resumes.

Must I run it on Wednesday?

No. Wednesday keeps the established ritual cadence. Run it on the first staffed re-entry day if that is Monday or Thursday; record the actual date and ISO week.

Can CI replace the cold-install test?

No. CI can validate files and receipts, but it does not click the player-facing library button, accept first input, hear missing audio, or experience a cloud-save prompt.

What if the build label changed during the holiday?

R1 is RED until you locate a numbered SHIP exception and its smoke evidence or restore the documented frozen build.

Do I need a new receipt for each storefront?

Yes when binaries, labels, or packaging differ. Use one receipt per surface and summarize them in BUILD_RECEIPT.

Can I skip save testing?

Only if persistence is genuinely outside demo scope. Mark it not_applicable; still prove clean quit.

What happens after GREEN?

Resume deferred work in numbered order, keep the re-entry label as your comparison baseline, and run weekly smoke on each February RC candidate.

Closing

A holiday freeze is only useful if January can identify what was frozen. The first re-entry evening should therefore be deliberately boring: preserve evidence, reconcile the label, install what a player receives, complete one golden path, quit cleanly, and file the receipt.

When R1–R6 are GREEN, you have a trustworthy line between December and February. When they are RED, you have a bounded investigation instead of a week of speculative rebuilds. Either result is better than merging the first shiny January task and discovering later that nobody ever tested the baseline.

Next: February 2027 RC branch-label receipt — align fest-demo-2027-02-rc* across BUILD_RECEIPT, branch, and player-visible UI before store upload.