From cab7975a2b13a0c65df48d993f60d1e12bf4a5d1 Mon Sep 17 00:00:00 2001
From: sudacode <suda@sudacode.com>
Date: Fri, 10 Jul 2026 01:09:52 -0700
Subject: [PATCH] chore(docs): remove implemented plan docs

- Drop early-managed-overlay-startup and macos-notification-hover design docs (both implemented, no longer needed)
---
 ...06-early-managed-overlay-startup-design.md | 29 -------------------
 ...6-06-09-macos-notification-hover-design.md | 27 -----------------
 2 files changed, 56 deletions(-)
 delete mode 100644 docs/plans/2026-06-06-early-managed-overlay-startup-design.md
 delete mode 100644 docs/plans/2026-06-09-macos-notification-hover-design.md

diff --git a/docs/plans/2026-06-06-early-managed-overlay-startup-design.md b/docs/plans/2026-06-06-early-managed-overlay-startup-design.md
deleted file mode 100644
index ce940042..00000000
--- a/docs/plans/2026-06-06-early-managed-overlay-startup-design.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!-- read_when: changing managed mpv startup, pause-until-ready, or visible overlay boot ordering -->
-
-# Early Managed Overlay Startup Design
-
-Status: approved
-Date: 2026-06-06
-
-## Problem
-
-Managed mpv startup can pause playback immediately, then leave SubMiner's tray and visible overlay
-unavailable until Yomitan/tokenization warmups finish. Startup notifications therefore miss the
-overlay surface and fall back to non-overlay status paths.
-
-## Chosen Approach
-
-For cold `--start --background --managed-playback` launches, handle initial args before waiting for
-the deferred overlay warmup. That lets the tray and visible overlay shell initialize immediately
-while the existing tokenization warmups continue in the background.
-
-The mpv plugin pause gate stays armed. Playback release still waits for SubMiner's autoplay-ready
-signal, which is emitted only after tokenization warmup and visible-overlay readiness. Existing
-second-instance attach behavior remains unchanged: when the launcher finds an already-running
-background app, it sends the same control command to that process and reuses its warmups/tokenizer.
-
-## Checks
-
-- Add a startup ordering regression test for managed background playback.
-- Keep the existing deferred startup ordering for non-managed launches.
-- Run the startup/runtime test slice plus SubMiner verification lane.
diff --git a/docs/plans/2026-06-09-macos-notification-hover-design.md b/docs/plans/2026-06-09-macos-notification-hover-design.md
deleted file mode 100644
index 31303e71..00000000
--- a/docs/plans/2026-06-09-macos-notification-hover-design.md
+++ /dev/null
@@ -1,27 +0,0 @@
-<!-- read_when: changing overlay notification hover, macOS mouse passthrough, or notification actions -->
-
-# macOS Notification Hover Stability Design
-
-Status: approved
-Date: 2026-06-09
-
-## Problem
-
-On macOS, hovering a character dictionary build notification can make the card flicker and slide as
-if it is hiding, then snap back. The likely trigger is the notification stack changing the overlay
-window's mouse-passthrough state for a progress card that has no user action.
-
-## Chosen Approach
-
-Keep non-action overlay notifications visually stable and click-through on hover. Only notifications
-with explicit actions should request interactive overlay input. The notification history panel keeps
-its existing interactive behavior.
-
-This avoids a macOS mouseenter/mouseleave passthrough loop for passive progress cards while
-preserving clickable notification actions.
-
-## Checks
-
-- Add a renderer regression test for passive notification hover.
-- Keep action-bearing notification cards interactive.
-- Run the targeted overlay notification and mouse-ignore tests.