air start claude TUI preselection doesn't reflect current filesystem state

[tadasant]

Problem

When running air start claude and selecting skills, then running air start claude again, the TUI's preselected skills don't reflect what was just selected (and what currently lives in the filesystem). The preselection appears to come from some other source (default manifest?) rather than the actual on-disk state.

Additionally, deselecting an item in the TUI doesn't remove it from disk — selection is treated as additive only.

Repro

1. air start claude — select a non-default set of skills
2. Confirm those skills are written to disk
3. air start claude again
4. Observe: the preselected items in the TUI do not match what's on disk
5. Deselect a manifest-controlled item, complete the flow
6. Observe: the item is still present on disk

Expected

• The TUI should always represent the current state of the filesystem on entry. If the user added skill X last time, X should be preselected this time.
• TUI selection state should be the source of truth on what gets written and removed, scoped to manifest-controlled artifacts. Deselecting a manifest-controlled item should remove it from the filesystem on the next air start claude. Locked/always-on items obviously stay.

Proposal

• Drive preselection from the current filesystem state (what's actually installed/wired up), not from a static default list.
• Apply selection diffs on commit: add newly-selected items, remove newly-deselected manifest-controlled items.
• Keep the existing "locked" affordance for always-on items.
• Add a separate affordance to indicate "default" items (which may or may not currently be selected per the on-disk manifest) — so users can tell which items are recommended defaults vs. which are currently active.

[tadasant]

🚦 Issue gate

Kind: feature (⚪ normal) · Scope: divergent · Facets: none

Verdict: HELD — A3, it expands product scope; A6 fires independently. Three asks are stacked here and they point in different directions. The first — preselection should reflect on-disk state — is a clean convergent bug and would proceed on its own. The second is not: deselection removing files from disk is a destructive capability the TUI was never built to have (the issue says so: "selection is treated as additive only"), and turning an additive picker into a two-way sync is new behaviour, not a corrected one. The third asks outright for a new affordance distinguishing "default" from "currently active" items — a new UI state by definition. A6 fires too: I cannot tell which of the three is the ask, and they imply materially different work and materially different review.

Live pages: none — not alert-shaped, and nothing in pulsemcp/air is deployed (the surface doc: "nothing here is deployed, so nothing pages"), so anchor 2a has no rule to resolve; anchor 2b — quick_search_sessions for pulsemcp/air issue sessions with show_archived: true — returns no alert-genesis session. Normal dispatch.

Re-entry: split it. A human scoping this down to "preselection is driven by current filesystem state" alone gets an immediate proceed from me; the removal semantics and the new affordance are product decisions and want to be their own issues. Hand back either half and I will rate it.

Rating detail

The rating below is recorded for the ledger; the hold tests decided this.

Axis	Rating	Why
Requirement complexity	large	Three asks with one shared repro, and the issue states goals ("the TUI should always represent the current state of the filesystem") rather than a spec for what "manifest-controlled" covers.
Requirement impact	medium	air start claude is the front door for interactive users, but the failure is a mis-preselected list rather than a wrong session.
Solution complexity	medium (est.)	Guessing: reading on-disk state is bounded; a selection diff applied on commit is a new model for the TUI to hold.
Implementation risk	large (est.)	Guessing, and this is the number that matters: ask 2 deletes files from a user's working tree based on a TUI diff, and the "manifest-controlled" boundary that decides what may be deleted is not defined anywhere in the issue. Getting that wrong removes something a user wanted. Under this surface's posture it holds nothing by itself — A3 did — but it is why splitting the issue is the right shape.
Estimated cost	medium (est.)	Guessing: the TUI plus whatever writes the manifest, plus tests for the removal path.

Note: the three solution-side axes are estimates — there is no diff yet.

Staleness check: live. No merged PR since 2026-04-28 touches the air start selection flow (#124 added air clean, #128/#133/#135 are hooks and the Claude adapter, #115/#117/#119 are composition and air resolve). No open issue duplicates it.