Files

T

Lucas Berger 13d27fd2d1 docs(09): capture phase context

Phase 09: Batch Operations
- Implementation decisions documented
- Phase boundary established

2026-02-03 20:44:58 -05:00

2.9 KiB

Raw Blame History

Phase 9: Batch Operations - Context

Gathered: 2026-02-03 Status: Ready for planning

## Phase Boundary

Execute actions on multiple containers in a single command with individual progress and consolidated results. Supports text commands and inline keyboard batch selection. "Update all" targets containers with available updates only.

## Implementation Decisions

Command syntax

Space-separated container names: "update plex sonarr radarr"
"Update all" = all containers with updates available (not all containers)
No "start all", "stop all", or "restart all" commands — user cannot picture needing these
Multiple named containers supported for start, stop, restart (e.g., "stop plex sonarr")
Fuzzy name matching means disambiguation may be needed (see Confirmation rules)

Inline keyboard batch

Support batch operations via UI buttons (Phase 8 keyboard infrastructure)
Claude's discretion on selection UX — pick approach that fits existing keyboard flow (multi-select toggle or checkbox-style)

Progress display

Claude's discretion on message strategy (single editing message vs stacked)
Summary emphasizes failures over successes — user cares about what broke and why
No retry button after completion — user manually re-runs if needed
Claude's discretion on cancel button during batch

Failure handling

Continue attempting remaining containers after a failure (don't abort batch)
Show container name + failure reason (actionable error info)
Distinguish warnings vs errors:
- Warning: "already stopped", "no update available" — non-critical
- Error: "image pull failed", "timeout" — actual failures
Claude's discretion on whether warnings appear in final summary

Confirmation rules

"Update all" requires confirmation showing count only: "Update 5 containers?"
Named batches run immediately without confirmation (user was explicit)
Exception: Batch stop confirms due to fuzzy matching risk
- If "stop plex" matches multiple containers (plex, jellyplex), show disambiguation
Claude's discretion on handling exact-match vs fuzzy-match (when user wants JUST plex, not jellyplex)

Claude's Discretion

Inline keyboard selection UX
Single editing message vs stacked messages for progress
Cancel button during batch (complexity vs usefulness)
Warning visibility in final summary
Exact-match priority vs fuzzy-match disambiguation behavior

## Specific Ideas

Fuzzy name matching should allow disambiguation: if "plex" matches both "plex" and "jellyplex", the user should be able to specify they want only "plex"
Failures need to be identifiable with reason — "why did it fail?" is the key question

## Deferred Ideas

None — discussion stayed within phase scope

Phase: 09-batch-operations Context gathered: 2026-02-03

2.9 KiB Raw Blame History