Status Module Viewport Loading Implementation Plan

For Claude: REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.

Goal: Delay status-module network requests until the status components enter the viewport, reducing initial network contention without changing final rendered content.

Architecture: Add an IntersectionObserver-based trigger to the status-related scripts so requests start only when the relevant component is near/inside view. Keep existing rendering and request logic intact; only change request timing.

Tech Stack: MkDocs Material, vanilla JavaScript, IntersectionObserver, requestIdleCallback fallback patterns

Task 1: Gate UptimeRobot requests by viewport visibility

Files: - Modify: docs/javascripts/uptimerobot-status.js - Verify: homepage/status sections using status-root, status-cn, status-wiki, status-hkw, status-www

Step 1: Write the failing test

Manual failing criteria: - UptimeRobot requests begin during page load even when the status block is below the fold. - Network panel shows requests before the user scrolls near the component.

Step 2: Run verification to confirm failure

Open page with status cards, reload, and inspect Network. Expected: FAIL because requests start immediately/idle-before-viewport.

Step 3: Write minimal implementation

Detect the first existing monitored element from configured elementIds.
If IntersectionObserver exists, observe the nearest status element/container.
Trigger existing fetch logic once when the target enters or approaches viewport.
Disconnect observer after first trigger.
Preserve current idle scheduling only after visibility trigger if still useful.
Keep current rendering output unchanged.

Step 4: Run verification to confirm it passes

Expected: - No UptimeRobot requests before the status module is near view. - Requests fire once when user scrolls to the section. - Status cards still render the same content.

Step 5: Commit

git add docs/javascripts/uptimerobot-status.js
git commit -m "perf: defer uptime status requests until visible"

Task 2: Gate TCY multi-node status monitor requests by viewport visibility

Files: - Modify: docs/javascripts/tcy-status-monitor.js - Verify: page containing #tcy-status-monitor

Step 1: Write the failing test

Manual failing criteria: - The multi-node status monitor starts fetching immediately on page init, regardless of whether the component is visible.

Step 2: Run verification to confirm failure

Reload page and inspect Network. Expected: FAIL because API requests start before scrolling to the component.

Step 3: Write minimal implementation

Observe #tcy-status-monitor with IntersectionObserver.
Only start the existing status fetch pipeline once it enters/approaches viewport.
Keep current TTL cache behavior.
Do not change card markup or labels.

Step 4: Run verification to confirm it passes

Expected: - Requests are delayed until the monitor block is visible. - Once visible, content renders exactly as before. - Re-entry does not duplicate startup logic.

Step 5: Commit

git add docs/javascripts/tcy-status-monitor.js
git commit -m "perf: defer node monitor requests until visible"

Task 3: Verify no UX regression in loading states

Files: - Verify only unless regression found

Step 1: Write failing verification checklist

Failure conditions: - User scrolls to status block and sees nothing at all - Requests refire repeatedly while scrolling - Existing loading text disappears or layout collapses

Step 2: Run verification

Check representative pages in browser: - reload page above fold - confirm no early requests - scroll to status area - confirm loading state appears then resolves correctly

Step 3: Minimal implementation if needed

Only fix visibility-trigger or loading-placeholder regressions. No extra feature work.

Step 4: Re-run verification

Expected: visual behavior remains acceptable, requests are delayed, and final UI is unchanged.

Step 5: Commit

git add <only files changed during regression fix>
git commit -m "fix: preserve status loading UX after viewport deferral"

Plan complete and saved to docs/plans/2026-03-07-status-viewport-loading-plan.md. Two execution options:

1. Subagent-Driven (this session) - I dispatch fresh subagent per task, review between tasks, fast iteration

2. Parallel Session (separate) - Open new session with executing-plans, batch execution with checkpoints

Which approach?