Lucas Berger
13d27fd2d1
Phase 09: Batch Operations - Implementation decisions documented - Phase boundary established
76 lines
2.9 KiB
Markdown
76 lines
2.9 KiB
Markdown
# Phase 9: Batch Operations - Context
|
|
|
|
**Gathered:** 2026-02-03
|
|
**Status:** Ready for planning
|
|
|
|
<domain>
|
|
## 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.
|
|
|
|
</domain>
|
|
|
|
<decisions>
|
|
## 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
|
|
|
|
</decisions>
|
|
|
|
<specifics>
|
|
## 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
|
|
|
|
</specifics>
|
|
|
|
<deferred>
|
|
## Deferred Ideas
|
|
|
|
None — discussion stayed within phase scope
|
|
|
|
</deferred>
|
|
|
|
---
|
|
|
|
*Phase: 09-batch-operations*
|
|
*Context gathered: 2026-02-03*
|