Rootimagine

rootimagine — Simulation Verification Mode

Writing the fix isn't the end. Mentally (or on paper) run the fix through normal/edge/failure scenarios before commit to expose what you missed. "Compiles OK" absolutely does NOT mean "works."

Activation

Explicit: /rootimagine

Auto-triggers:

• "시뮬레이션 돌려"
• "확실히 해결한거지"
• "진짜 해결됐는지"
• "코드 확인해봐"
• "논리적으로 확인"
• "dry-run"
• "머릿속으로 돌려봐"

Relationship with rootfix

Common pair: rootfix to draft → rootimagine to verify → commit.

6-Step Simulation

1. Build State/Variable Table

List every variable, state, and external resource (cache/DB/event/queue/...) the fix touches:

This table is the mental state model. Miss it and the sim is wrong.

2. Time-Step Trace (T = time)

For each time point of interest (T=0, T=5, T=10, ...), trace what runs and how variables change.

How to pick trace points — any of these is a checkpoint

• await / asyncio.wait_for / condition.wait_for — any yieldable point
• timeout expiry — wait_for timeout value
• loop iterations — while True / for ... boundaries
• event.set() / event.is_set() — completion points of external tasks
• external calls (Bedrock/DB/HTTP) — response arrival (typically ms to tens of seconds)
• user actions — click/leave/refresh/page change
• component mount/unmount (frontend)
• branches (if/else) — trace both arms

At each time point, record

• Code line + one-line description ("line 3040: chunk = await _bg_queue.get() blocked")
• Every cell of the variable table (especially the deciding branch variables)
• What yielded/returned/dispatched (effect on user view)
• What other tasks are doing simultaneously (critical in async)

Forced self-check at every branch / await

• During this await, can another task mutate Z so that the next branch chooses differently?
• Did I trace the other arm of this branch?
• After this timeout, in what state is the next line invoked?
• While this yield reaches the client, what is the backend doing? (and vice versa)

Example trace:

T=0     : line 2944 _gen_share_card_early task started (Bedrock call started)
T=0     : line 2964 _bg_generate task started
T=0.1   : SSE generator entered, line 3027 stat_cards yielded → client view
T=0.1~5 : line 3031 share_card_ready.wait() blocked
         | meanwhile: _gen_share_card_early awaiting Bedrock response
T=5     : line 3031 wait_for TimeoutError → share_card emission skipped → chunks loop
T=5+ε   : line 3041 _bg_queue.get() blocked (no chunk yet)
         | meanwhile: _gen_share_card_early awaiting Bedrock response
T=10    : _gen_share_card_early got Bedrock response → _pg.share_card filled → share_card_ready.set()
         | line 3041 still blocked
T=120   : first chunk arrives → line 3041 unblocks → yield chunk → polling → share_card yielded
         | user: doesn't see share_card until T=120 ← MISSED CASE!

If during a trace you find a "wait this is missed" — fix immediately. That is the entire point of the sim.

3. Case Enumeration — Pull more than you think

Principle: A/B/C/D are the starting line, not the finish. For each variable/timing/external resource the code depends on, pull out dimensions of variation, then multiply cases by sampling extremes/middles along each dimension. "I only ran the happy path" = immediate fail.

Dimension checklist (commonly missed axes)

• Timing: fast / right at timeout / slow / never arrives
• Order: A first / B first / simultaneous
• Resource state: cache hit / miss / stale / reset (after deploy)
• Network / IO: normal / slow / disconnect / partial response
• Concurrency: single / same user twice / different users simultaneously
• Input: normal / empty / malformed / very large
• Auth: valid / expired / forged / anonymous
• Lifecycle: normal exit / user leaves / refresh / page change
• External: external API success / failure / timeout / partial
• State reset: initial / leftover from prior call / cross-instance influence

Minimum cases (starting line)

A. Normal (fast path): all dependencies satisfied within timeout. Happy path. B. Slow path: async dependency is late but eventually completes. ← Most fixes miss here. C. Failure: dependency errors out. Verify fallback behavior. D. Extreme: dependency never completes / external abort / cancel / process kill.

Don't stop here. From the dimension checklist above, pick relevant ones and add cases:

• E. Concurrent invocations (race)
• F. Partial failure (some chunks arrive + cancel)
• G. External resource reset (cache cleared right after deploy)
• H. User input variability (empty form / unicode / emoji / very large)
• ...

Question to ask yourself: "Did I write down every way this fix could break in someone's hands?" — if you have fewer than 5, push harder.

4. State the User-Visible Effect

For each case, what does the user actually see?

• "share_card appears around T=3"
• "1-2 minutes of blank screen, then share_card around T=11"
• "user never sees share_card (fallback kicks in, content batched at the end)"

If you can't write the user-visible effect in plain words, you haven't really traced it.

5. Latent Defect Self-Check

• Any time point where code line Y doesn't execute when it should?
• Variable Z could hold a stale value due to a race?
• External resource (cache/DB/event) might be in a reset state?
• On async cleanup / cancel, is finally guaranteed to run?
• Could the generator hang in a "no chunks/events ever" case?
• What if two instances run the same code path concurrently?

6. Confidence Declaration

• HIGH: all 4+ cases traced end-to-end, no latent defects
• MEDIUM: only some cases simulated, operational verification still required
• LOW: simulation is hard, or external factors dominate → real validation environment needed

No fake confidence. If "HIGH" but you skipped cases, it's actually MEDIUM.

7. Concerns

Surface things that "won't break right now but need attention." Not just bugs — anything that could become a problem. The purpose is to expose risks before they become incidents.

Scope (full coverage)

How to write concerns

• Each concern: what + why it's concerning + when it could break
• Severity tag: 🔴 HIGH / 🟡 MEDIUM / 🟢 LOW
• If you feel "this might be a problem someday..." — write it down. Don't ignore your instinct.
• Overlap with latent defects is OK — here you take a wider lens.

Example:

🟡 MEDIUM: No backoff in retry logic → could exceed rate limits under external API failure (breaks at 10x traffic)
🔴 HIGH: Errors silently swallowed in this function → impossible to trace root cause during incidents (no monitoring alerts either)
🟢 LOW: Magic numbers in 3 places → not broken now but invites mistakes on next change

8. Next Actions

After simulation, state clearly "so what now?" If the agent doesn't know what to do next, the simulation was just self-satisfaction.

3-tier classification

How to write actions

• Each action is one executable sentence (vague "needs improvement" forbidden)
• Link to which mode (rootfix/rootclean/rootbuild) when possible
• If any NOW items exist → commit forbidden, apply fix first then re-simulate
• NOW items must be zero before commit is allowed

Example:

🚨 NOW (Immediate):
1. Case B: share_card missed when first chunk delayed → add polling outside chunks loop [rootfix]
2. Resource not released in finally after timeout → memory leak possible [rootfix]

📋 NEXT (Follow-up):
1. Add share_card generation latency monitoring alert [rootbuild]
2. Write E2E test for Case D (process kill) scenario [rootbuild]

💡 LATER (Optional):
1. Extract _bg_generate function → currently 87 lines, readability improvement [rootclean]
2. Move magic number timeout 5s to config [rootclean]

Output Format

[Simulation — <fix one-liner>]

State table:
| Name | Initial | Updated At | Updated By |
|---|---|---|---|
| ... |

Case A (Normal): T=0 → T=N trace
Case B (Slow):   T=0 → T=N trace
Case C (Failure): T=0 → T=N trace
Case D (Extreme): T=0 → T=N trace

User-visible effect per case:
- A: ...
- B: ...
- C: ...
- D: ...

Latent defects:
- (list if any)

Confidence: HIGH | MEDIUM | LOW
Reason: ...

Concerns:
- 🔴/🟡/🟢 <what> — <why concerning> (<when it breaks>)
- ...

Next Actions:
🚨 NOW (Immediate):
1. <executable instruction> [linked mode]

📋 NEXT (Follow-up):
1. <executable instruction> [linked mode]

💡 LATER (Optional):
1. <executable instruction> [linked mode]

Termination Conditions

Simulation ends → commit/deploy allowed only when ALL of:

• State/variable table built (every variable the fix touches + external resources)
• Dimension checklist reviewed (cover every dimension that applies)
• At least 5 cases traced — A/B/C/D + at least one from dimensions
• User-visible effect declared per case
• Each await/timeout/branch self-check passed
• For any miss discovered, an extra fix is applied → that fix is re-simulated (recursive)
• Latent defects: zero (or explicitly "accepted — reason: ...")
• Confidence assigned (HIGH/MEDIUM/LOW + reason)
• If MEDIUM/LOW, operational verification plan specified (which environment, which flow)
• Concerns documented (code quality / operational / business impact — full scope review)
• Next Actions classified (NOW / NEXT / LATER tiers)
• NOW items = zero — any remaining NOW items block commit, fix first

Any unchecked item → simulation incomplete. Commit forbidden. No self-deception.

Anti-Patterns (forbidden in this mode)

1. "It compiles, so OK" — skipping simulation and declaring success
2. Happy-path-only trace — skipping B/C/D cases
3. Self-inflated confidence — calling it "HIGH" without operational verification
4. Implicit assumptions — "chunks will probably arrive early" without stating it
5. Missing user-visible effect — wrote what code does, but not what the user sees
6. Ignoring races — only one ordering of two tasks considered

Notes

• Derived from real-world async debugging sessions where fixes were repeatedly applied yet all of them missed the actual operating environment — e.g. adding polling inside a chunks loop while the first chunk takes 1-2 minutes to arrive in production (so the polling never runs).
• Pairs with rootfix: fix → simulate → discover missing case → fix again → simulate again → confidence.
• Works in any project. Global skill.