Artefact gating is evaluated when wizardState.updateGating() runs (after setTarget and some transitions). If the user deletes or renames .ti1 / .ti2 / .ti3 / profile files outside the app, the stepper can remain unlocked and later stages can fail in confusing ways.
Re-validate on every stage entry and on app startup so the UI always reflects the real disk state.
Scope & Technical Requirements
Call verify_stage_artefacts (already implemented in Rust):
On application startup (after restoring last basename/cwd if any).
When the user clicks a stepper step (before showing that stage).
When returning to the main window from a file dialog or settings (optional but useful).
If a previously unlocked stage is no longer valid:
Mark the step disabled again.
If the user is currently on that stage, navigate back to the highest still-valid stage and show a short notice (“Target files changed on disk — returned to Stage N”).
Do not force a full wizard reset unless the basename/cwd themselves are gone.
Avoid spamming dialogs; prefer a single status banner or toast.
Acceptance Criteria
Deleting .ti2 while the app is open causes Stage 3+ to lock on next gating refresh.
App start with a missing intermediate artefact does not leave later steps clickable.
No regression to normal forward progress when files are intact.
Performance: verification remains fast enough not to stutter stage switches.
Dependencies
Uses existing commands::verify_stage_artefacts.
Complements Ticket 3 (resume from .ti2); resume should also trigger a full re-validate.
### Description
Artefact gating is evaluated when `wizardState.updateGating()` runs (after `setTarget` and some transitions). If the user deletes or renames `.ti1` / `.ti2` / `.ti3` / profile files **outside** the app, the stepper can remain unlocked and later stages can fail in confusing ways.
Re-validate on every stage entry and on app startup so the UI always reflects the real disk state.
### Scope & Technical Requirements
1. Call `verify_stage_artefacts` (already implemented in Rust):
- On application startup (after restoring last basename/cwd if any).
- When the user clicks a stepper step (before showing that stage).
- When returning to the main window from a file dialog or settings (optional but useful).
2. If a previously unlocked stage is no longer valid:
- Mark the step disabled again.
- If the user is currently on that stage, navigate back to the highest still-valid stage and show a short notice (“Target files changed on disk — returned to Stage N”).
3. Do not force a full wizard reset unless the basename/cwd themselves are gone.
4. Avoid spamming dialogs; prefer a single status banner or toast.
### Acceptance Criteria
- [ ] Deleting `.ti2` while the app is open causes Stage 3+ to lock on next gating refresh.
- [ ] App start with a missing intermediate artefact does not leave later steps clickable.
- [ ] No regression to normal forward progress when files are intact.
- [ ] Performance: verification remains fast enough not to stutter stage switches.
### Dependencies
- Uses existing `commands::verify_stage_artefacts`.
- Complements Ticket 3 (resume from `.ti2`); resume should also trigger a full re-validate.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
Artefact gating is evaluated when
wizardState.updateGating()runs (aftersetTargetand some transitions). If the user deletes or renames.ti1/.ti2/.ti3/ profile files outside the app, the stepper can remain unlocked and later stages can fail in confusing ways.Re-validate on every stage entry and on app startup so the UI always reflects the real disk state.
Scope & Technical Requirements
verify_stage_artefacts(already implemented in Rust):Acceptance Criteria
.ti2while the app is open causes Stage 3+ to lock on next gating refresh.Dependencies
commands::verify_stage_artefacts..ti2); resume should also trigger a full re-validate.