Parked sketch — swipe-cards for multi-workload nesting on status.gf.cx

DARE.CO.UK · PARKED SKETCH · 2026-06-03

Mirrored from ~/.claude/.../memory/parked_sketch_swipe_cards_multi_workload_2026-06-03.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

When multiple GCP (or other) workloads run in parallel, nest them as swipeable cards within one container instead of rendering N separate cards on the status page; surfaces “what’s running on each cloud” without sprawl

The idea

When several workloads of the same kind run simultaneously (e.g. 2-3 GCP VMs against different audreyinc trial workloads, or 4 parallel rclone jobs against gvr-* user remotes), the current rendering creates one card per workload — the active grid sprawls.

Sketch: one container card per category (GCP, Cloud Run, multi-account rclone, etc.) with swipeable sub-cards inside for each workload. Dots/indicators show how many sub-cards exist; left/right swipe (or keyboard arrows on desktop) moves between them. Aggregate metrics on the parent (total cost, total throughput, fastest ETA) summarise the swarm.

Why this matters

• Visual: 3 GCP cards next to a dare Mac card next to 4 Cloud Run cards = noise. One “GCP · 3 active” card with swipe gives the same info at 1/3 the width.
• Cost surfacing: the existing header bar already separates Claude API vs GCP egress (2026-06-03 update). The swipe-card pattern extends that “category-aware” framing one level down — each category gets its container, header-bar shows the category total, swipe gives the per-workload split.
• Composes with: feedback_default_to_tables_for_sequential_work.md (table-like grid of sub-cards in the swipe), feedback_graceful_degradation_pending_state_pattern.md (sub-cards that haven’t started yet hold position with neutral placeholders).

How to apply (when picked up)

1. Detect category at render time — same interface field used for the GCP egress filter (gcp substring) defines a swipe-group.
2. Aggregate parent stats: total bytes_done / bytes_total / cost / fastest ETA across the group.
3. Sub-card markup: keep the existing per-transfer card shape, wrap N of them in <div class="swipe-track"> with CSS scroll-snap (scroll-snap-type: x mandatory on parent, scroll-snap-align: start on each child). Pure CSS, no JS for the swipe itself.
4. Indicator dots: small bottom-of-card row showing N dots; current dot filled. Optional JS to highlight the currently-visible one via IntersectionObserver.
5. Keyboard / touch: native scroll-snap handles touch swipe + arrow keys via container focus. No custom event handlers needed for v1.

Trigger condition

Build when there’s actual demand — i.e. when two or more workloads of the same category run concurrently in production. Premature otherwise. Park until then.

Likely first trigger: the multi-account Mac rclone pattern (project_multi_thread_streams_test_smart_sellars_2026-06-03.md) when it ships — 4 parallel rclones to gvr-* user remotes = the first real “multi-workload of one category” case.