From d81f59de05d43d671761bd80a431b8ac11a37aaa Mon Sep 17 00:00:00 2001 From: mkelvers Date: Sat, 27 Jun 2026 19:05:05 +0200 Subject: [PATCH] chore: remove plans folder --- ...pose-episode-availability-refresh-state.md | 45 ------------------- 1 file changed, 45 deletions(-) delete mode 100644 plans/012-expose-episode-availability-refresh-state.md diff --git a/plans/012-expose-episode-availability-refresh-state.md b/plans/012-expose-episode-availability-refresh-state.md deleted file mode 100644 index d29ca4f0..00000000 --- a/plans/012-expose-episode-availability-refresh-state.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -finding: "Expose episode availability freshness / retry state" -catalog: "Direction" -impact: - "Users cannot see stale, retrying, or failed episode availability state even though the app tracks - it." -base_commit: "0d31d46" ---- - -## Effort - -M/L - scope depends on whether this is a small per-title detail or a broader maintenance page. - -## Risk - -MED - exposing provider/cache internals can clutter UI or confuse users if wording is too technical. - -## Confidence - -MED - the data exists, but product shape needs maintainer judgment. - -## Evidence - -- `internal/episodes/worker.go:12-31` refreshes due episode availability in the background. -- `internal/episodes/service/cache_store.go:50-65` stores next refresh, retry window, last - attempt/success, failure count, and last error metadata through query parameters. -- `templates/components/anime_episode_count.gohtml` currently collapses availability to a compact - episode/audio label. - -## Resolution Approach - -Start with the smallest useful user-facing surface: a per-title availability status detail near the -existing episode-count/audio label. Show human-readable freshness such as last refreshed, next -refresh, retrying soon, or temporarily unavailable. Avoid exposing raw provider errors unless they -are sanitized and clearly useful. - -Consider adding an authenticated manual refresh action only after the read-only status is useful. -Manual refresh should be rate-limited or guarded to avoid hammering providers. - -Add service/view-model tests that map cache metadata to user-facing states. Add template tests for -fresh, stale, retrying, and failed states. If this becomes a maintenance page instead, split that -into a separate design plan before implementation. - -Verify with `go test ./internal/episodes/... ./templates ./...` and relevant lint/typecheck commands -if UI scripts are added.