From efe3215f32b688be38be67a29f6cf30419aba789 Mon Sep 17 00:00:00 2001
From: Jan Svabenik <jan@svabi.ch>
Date: Sun, 22 Mar 2026 15:20:05 +0100
Subject: [PATCH] docs: capture Phase-4 monitor-window status

---
 PLAN.md   | 9 +++++++++
 README.md | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/PLAN.md b/PLAN.md
index 347b2bf..2ed9764 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -144,6 +144,15 @@ Verantwortung:
 ## Spätere Phasen
 
 ### Phase 4
+Phase-4 Status: Monitor-Window-Betriebsmodell gelandet (Wave 4F-C Abschluss).
+
+Gelandete Wellen (4F):
+- Monitor-Windows mit Overlap, Priority/Zone-Bias und Auto-Record/Decode pro Window
+- Candidate-Gating im Capture-Span + Refinement-Plan-Input
+- Window-Statistiken + Outcome-Summaries in Debug/API (`/api/refinement`)
+- Decision/Admission-Reason-Tags mit `window:*` + `window-zone:*`
+
+Nächste Ausbaustufe (später):
 - breitbandige Multi-Span-Profile
 - 20-80 MHz konkrete Betriebsmodi
 - adaptive Quality-of-Service
diff --git a/README.md b/README.md
index e8c6c7e..a2625ec 100644
--- a/README.md
+++ b/README.md
@@ -62,7 +62,7 @@ Edit `config.yaml` (autosave goes to `config.autosave.yaml`).
 - `pipeline.goals.*` -- declarative target/intent layer for future autonomous operation
   - `intent`
   - `monitor_start_hz` / `monitor_end_hz` / `monitor_span_hz`
-  - `monitor_windows` -- optional list of monitor windows (each window uses `start_hz` + `end_hz` or `center_hz` + `span_hz`)
+  - `monitor_windows` -- optional list of monitor windows (each window uses `start_hz` + `end_hz` or `center_hz` + `span_hz`, plus optional `label`, `zone`, `priority`, `auto_record`, `auto_decode`)
   - `signal_priorities`
   - `auto_record_classes`
   - `auto_decode_classes`
@@ -122,7 +122,7 @@ Phase-3 status (Wave 3E):
 
 The long-term target is that you describe *what the system should do* (for example broad-span monitoring intent, preferred signal families, auto-record/decode priorities), while the engine decides *how* to allocate surveillance, refinement and decoding budgets.
 
-Phase-4 groundwork: `monitor_windows` allows multi-span gating within a single capture span; it is used to accept/reject candidates and inform refinement plans without changing the acquisition center/rate.
+Phase-4 status (monitor-window operating model): `monitor_windows` gates candidates inside a capture span, supports overlapping windows with priority/zone bias, and can auto-record/decode per window without retuning. Window stats + summaries now surface in `/api/refinement`, and decision/admission reasons include window tags/zone tags for traceability.
 
 **CFAR modes:** `OFF`, `CA`, `OS`, `GOSCA`, `CASO`