name: tui-state-validation description: Use this skill when the task is to reproduce or analyze a concrete AutoLabOS TUI/web symptom, especially when stale state, fresh-vs-existing divergence, resume mismatch, or persisted-artifact-vs-UI disagreement may be involved.

TUI State Validation

Produce a structured live-validation result for one concrete target before proposing or evaluating a code change.

Treat actual user-visible behavior as the source of truth and compare, when relevant:

This skill is for narrowing the problem to the most likely minimal failing boundary before patching.

Use this skill when the user asks to:

run TUI live validation
reproduce an interactive bug
compare fresh vs existing or resumed sessions
check whether persisted outputs match what the UI shows
verify whether a fix actually solved the live symptom
triage stale summaries, stale panels, stale progress, or stale session-local state
validate a specific execution mode or a specific end-to-end flow

Typical trigger phrases:

Always produce these sections:

Restate the validation target in one sentence.
Identify the relevant execution mode, commands, flows, sessions, and screens.
Check /doctor output and current runtime context first when applicable.
When possible, compare all of:
- fresh session
- existing or resumed session
- persisted artifact
- top-level summary or projection
Record reproduction steps and observations clearly enough that another agent could follow them exactly.
Choose one dominant problem category:
- persisted_state_bug
- in_memory_projection_bug
- refresh_render_bug
- resume_reload_bug
- race_timing_bug
Also identify the most likely failing boundary:
- persisted artifact layer
- loader / read layer
- projection / aggregation layer
- refresh / subscription / invalidation layer
- session resume / restore layer
- renderer presentation layer
- mode-specific policy divergence boundary
- timing / race boundary
Recommend the next action:
- boundary investigation
- instrumentation
- minimal patch
- rerun with a narrower hypothesis

Do not jump straight into editing before writing down the validation record.
Do not assume persisted state is correct just because the file exists.
Do not assume one working mode implies all modes work.
If the user explicitly asks you to test the behavior yourself, do not substitute deterministic smoke fixtures, fake providers, or replay-only evidence for that request. Use a real live flow when possible, or state the environment limitation plainly.
If a fresh reopen fixes the symptom, explicitly suspect in-memory projection, refresh wiring, resume handling, or session-local cache before blaming persistence.
Separate observations from hypotheses.
Prefer precise reproduction notes over broad conclusions.