Decompose render: modal views with snapshot-based project_store reads

[MasonRhodesDev]

Context

Render architecture audit from #203. The four modal factories (new task, add agent, create branch, custom action) are currently stored as Option<ModalState> fields on AnotherOneApp and rendered inline. They read project_store for branch lists, agent lists, and issue discovery caches.

What to do

For each modal:

1. Define an immutable FooModalSnapshot capturing the project_store data it needs (branch list, agent list, issue cache, etc.).
2. Lift the Option<FooModalState> fields into a struct FooModal implementing Render, holding the snapshot plus local draft state (text inputs, selections, validation errors).
3. Store as Entity<FooModal> on app (present when open, replaced when closed, or kept and shown/hidden via a flag).
4. Compute and push a fresh snapshot only when the modal is open and its backing data changes.

Why

Modals are shown infrequently but have complex render trees (branch dropdowns, agent lists, issue pickers). As inline helpers they re-render on every tick while open. As isolated View<T> entities they only re-render when their own state (user input, snapshot update) changes.

The Option<State> pattern already exists — this migration adds the Entity<T> wrapper and snapshot boundary without changing modal logic.

[MasonRhodesDev]

Implementation plan

Modal inventory

File	State struct	Render lines
app/src/new_task_modal.rs	NewTaskModalState	~800
app/src/create_branch_modal.rs	CreateBranchModalState	~260
app/src/add_agent_modal.rs	AddAgentModalState	~650
app/src/custom_actions_modal.rs	CustomActionModalState	~1500

All four are stored as Option<T> on AnotherOneApp (lines 2083–2089) and rendered inline at the bottom of render as layered children.

project_store reads per modal at render time

Modal	Reads at render	Reads at open/submit
NewTaskModal	branch_names, current_branch, is_git_backed, project_name, issue cache, enabled_agents()	root project lookup, issue discovery trigger
CreateBranchModal	None — slugify_branch_name is a pure fn	active_project_context at submit only
AddAgentModal	enabled_agents(), default_agent_id()	resolves enabled agents on open
CustomActionsModal	None at render	active_open_in_project_id at submit only

CreateBranchModal and CustomActionsModal need no snapshot — they're self-contained at render time.

Snapshot struct designs

// new_task_modal.rs
pub(crate) struct NewTaskModalSnapshot {
    pub is_git_backed: bool,
    pub project_name: String,
    pub available_branches: Vec<String>,
    pub current_branch: String,
    pub issue_row_visible: bool,
    pub issue_options_loading: bool,
    pub issue_options: Option<Vec<GitHubIssueRecord>>,
    pub issue_options_error: Option<String>,
    pub enabled_agents: Vec<&'static AgentDef>,
}

// add_agent_modal.rs
pub(crate) struct AddAgentModalSnapshot {
    pub enabled_agents: Vec<&'static AgentDef>,
    pub default_agent_id: Option<&'static str>,
}

Entity lifecycle: ephemeral (create on open, drop on close)

Persistent show/hide entities accumulate stale snapshot risk and require explicit is_visible guards. Ephemeral entities (or the current Option<State> pattern promoted to Option<Entity<T>>) always start from a fresh snapshot. The snapshot extraction and the Entity<T> migration are independent steps — the snapshot can land first with no entity changes.

Snapshot refresh points (while modal is open)

• drain_new_task_branch_refresh → patch snapshot.available_branches + snapshot.current_branch
• drain_project_issue_discovery → patch snapshot.issue_options* fields
• Both drains already guard on if let Some(modal) = self.new_task_modal.as_mut() — extend those guards to also update the snapshot field

Step-by-step plan (ordered simplest first)

Step 1 — AddAgentModal: introduce AddAgentModalSnapshot

• Capture enabled_agents and default_agent_id in open_add_agent_modal; store alongside draft state
• Remove self.enabled_agents() and self.default_agent_id() calls from add_agent_modal_overlay
• sanitize_add_agent_modal_selection still calls self.enabled_agents() (it's a handler, not render)
• Estimated: +30 / −5 lines

Step 2 — NewTaskModal: introduce NewTaskModalSnapshot (main effort)

• Add the snapshot struct; populate in open_new_task_modal_with_branch
• Change field to new_task_modal: Option<(NewTaskModalState, NewTaskModalSnapshot)> or a wrapper struct
• new_task_modal_overlay reads branch list, issue data, git-backed flag, agent list from snapshot
• Patch snapshot in drain_new_task_branch_refresh and drain_project_issue_discovery
• Estimated: +140 / −50 lines

Step 3 — Entity<T> migration (optional — prerequisite for test-harness)

• Create Entity<NewTaskModalView> on open, drop on close via Option<Entity<T>> on app
• Implement Render for NewTaskModalView; wire handlers back to parent via cx.listener
• Repeat for AddAgentModalView
• Estimated: +320 / −120 lines, high complexity — do last

Risks

Snapshot staleness during async refresh
drain_new_task_branch_refresh fires ~50 ms after the user opens the modal. If the user closes the modal before the drain fires, the existing if let Some(modal) guard already prevents the stale write. Extend the same guard to cover the snapshot field.

text_input_target() routing
app.rs has a text_input_target() method that inspects self.new_task_modal, etc. to route IME text input. Must be updated in Step 2 to read from the new wrapper struct. Do not change the field name mid-migration or this breaks text input.

Entity close lifecycle (Step 3)
Handlers that close the modal (ESC, Cancel, submit) must go through AnotherOneApp and set the Option<Entity<T>> to None synchronously. Closing via entity-emitted events adds one-tick ghost renders. Always close from the parent.

Acceptance criteria

• new_task_modal_overlay contains zero direct reads of self.project_store, self.project_issue_discovery_cache, or self.enabled_agents()
• add_agent_modal_overlay contains zero calls to self.enabled_agents() or self.default_agent_id()
• Branch list in the new-task modal updates when drain_new_task_branch_refresh fires
• Issue list updates when drain_project_issue_discovery fires
• Open / dismiss / submit / ESC / backdrop-click all behave identically
• submitting guard still blocks dismiss during in-flight creates
• cargo build -p another-one clean

Estimated scope

Steps 1–2 (snapshot extraction only): ~+260 lines net. Step 3 (entity migration): +200 lines on top. Steps 1–2 are the right first PR.