Clarify planning activation edge cases

Author: pt9912

docs/plan/planning/open/plan-domain-migration-optimization-run-can-execute.md

@@ -215,6 +215,11 @@ Migration der Ausführungsentscheidung auf `CanExecute`.
      percent-encodiertem ISO-Zeitstempelwert wird persistiert, geparst,
      innerhalb des `kv1`-Parsers decodiert und bytegleich zum ursprünglichen
      fachlichen Wert verglichen.
+   - Source-Guard-Vorsorgetest ergänzen: eine timestamp-basierte
+     `series_version` mit Doppelpunkt (z. B. `2026-05-24T12:00:00Z-v3`) wird
+     als hypothetischer `kv1`-Wert percent-encoded, roundtrippt und decodiert
+     bytegleich. Das bleibt auch dann Pflicht, wenn aktuelle Preis-/Forecast-
+     Slices `series_version` noch nicht im `TerminationDetail` persistieren.
    - API-Kompatibilität:
      - Producer-Vertrag: `can_execute` ist nach der Migration ein required Feld in
        Optimierungs-Run-Responses.

docs/plan/planning/open/plan-ler-fcr-reserve-robustness.md

@@ -320,7 +320,8 @@ Deterministische Berechnung (verbindlich):
   - optionale Pflichtanteile je Produkt und Richtung:
   - `alpha_afrr_up_t`, `alpha_afrr_down_t`
   - `alpha_mfrr_up_t`, `alpha_mfrr_down_t`
-  - Default: `1.0`, wenn das Produkt gebucht ist, sonst `0.0` bei nicht gebuchtem Produkt.
+  - Default: `1.0`, wenn das Produkt nach den obigen Produkt-Aktivitätsregeln
+    produktiv aktiv ist, sonst `0.0`.
   - Vor der Rechnung ist hart zu validieren:
     - Alle Reserve- und Alphafelder pro Zeitschritt sind endlich und nicht negativ.
     - `fcr_*`, `afrr_*`, `mfrr_*` und die optionalen `required_*`-Felder sind `>= 0`.
@@ -370,6 +371,14 @@ Deterministische Berechnung (verbindlich):
     - Für die Worst-Case-Hülle ist die zu reservierende FCR-Energie auf
       `min(Δt, fcr_remaining_envelope_t/60)` h zu skalieren.
     - Mit der Tracking-Logik wird bei kleinen `Δt` die volle Mindestdauer konservativ über Folgeintervalle berücksichtigt.
+    - Beispiel: Bei `Δt=1/60 h`, `t_min_fcr=30 min` und `fcr_up_kw_t=1 MW`
+      ist `fcr_remaining_envelope_t` zwar pro Schritt statisch `30 min`, der
+      FCR-Term aber `min(1/60, 30/60) * 1000 kW = 16,67 kWh` je Schritt.
+      Über 30 fortgeschriebene SOC-Schritte akkumuliert dies zu `500 kWh`,
+      also genau 30 Minuten FCR-Energie. Es wird nicht pro Schritt erneut
+      30-Minuten-Energie abgezogen; die statische Größe erzwingt nur, dass
+      jeder Entscheidungszeitpunkt als neuer Worst-Case-Startpunkt bewertet
+      wird.
 - Hilfsgröße:
   - `self_discharge_loss_kwh_t` ist deterministisch zu berechnen:
     - bei `self_discharge_mode=absolute_kwh_per_hour`:
@@ -445,10 +454,17 @@ Restore- und Gate-Entscheidungslogik (verbindlich):
   Die folgenden `restore_shortfall_*`-Größen gehören zur unabhängigen
   Worst-Case-Hülle je Richtung; sie sind keine konkrete Fahrplanaktion und
   dürfen nicht als gleichzeitiges Laden/Entladen interpretiert werden.
+  - Effektiver Restore-Bedarf:
+    - `required_restore_up_kwh_t = coalesce(required_up_kwh_t, worst_up_kwh_t)`
+    - `required_restore_down_kwh_t = coalesce(required_down_kwh_t, worst_down_kwh_t)`
+    - Operatorseitig gesetzte `required_*`-Werte dürfen größer sein als die
+      Worst-Case-Hülle; wenn gesetzt, sind sie bewusst der größere
+      Restore-Planungs- und Gate-Bedarf. So entstehen keine divergierenden
+      Gate- und Plan-Energien.
   - Up-Verstoß-Defizit:
-    `restore_shortfall_up_kwh = max(0, worst_up_kwh_t - (soc_plan_up_t - soc_min_eff_kwh) * eta_discharge)`
+    `restore_shortfall_up_kwh = max(0, required_restore_up_kwh_t - (soc_plan_up_t - soc_min_eff_kwh) * eta_discharge)`
   - Down-Verstoß-Defizit:
-    `restore_shortfall_down_kwh = max(0, worst_down_kwh_t - (soc_max_eff_kwh - soc_plan_down_t) / eta_charge)`
+    `restore_shortfall_down_kwh = max(0, required_restore_down_kwh_t - (soc_max_eff_kwh - soc_plan_down_t) / eta_charge)`
 - Verfügbare Wiederherstellungsleistung je Schritt:
   - Effektive Restore-Kapazität je Richtung berechnet sich per Coalesce:
     per-step Envelope-Override > Policy-Skalar > technischer Default.
@@ -581,8 +597,9 @@ Pflichtregeln:
  vorschlagen:
 
  - Zuerst wird je Zeitfenster berechnet, ob eine Wiederherstellung je Richtung nötig ist:
-   - `required_restore_up_kwh_t = coalesce(required_up_kwh_t, worst_up_kwh_t)`
-   - `required_restore_down_kwh_t = coalesce(required_down_kwh_t, worst_down_kwh_t)`
+   - `required_restore_up_kwh_t` und `required_restore_down_kwh_t` sind die
+     bereits in der Gate-Entscheidungslogik verwendeten effektiven
+     Restore-Bedarfe.
    - `scheduled_restore_up_kwh_t = max(0, required_restore_up_kwh_t - available_up_kwh_t)`
    - `scheduled_restore_down_kwh_t = max(0, required_restore_down_kwh_t - available_down_kwh_t)`
   - Vor der Berechnung gilt hart:

docs/plan/planning/open/plan-market-colocation-model.md

@@ -286,13 +286,23 @@ Mögliche Domain-/Application-Erweiterungen:
 
 - `LocalOriginState`
   - virtuelle Zwischenbilanz für herkunftsgebundene Energie (kWh)
+  - `e_local_0` als Initialzustand der Herkunftsbilanz; Default `0`.
+    Erforderlich, sobald `OriginConstraint` aktiv ist.
   - `e_local_t` je Zeitschritt
   - `eta_charge` (optional, default `1.0`)
   - `eta_discharge` (optional, default `1.0`)
   - Begrenzung via `local_origin_capacity_kwh`
   - Für `GreenStorageRestricted` muss `local_origin_capacity_kwh > 0` gelten.
     `local_origin_capacity_kwh=0` ist keine nutzbare Herkunftsbilanz und führt zu
     `CONFIG_INCONSISTENT` mit `format=kv1;reason=GREEN_STORAGE_ORIGIN_CAPACITY_ZERO`.
+  - Für `ClassicalCoLocation`/`HybridWithGridImport` mit aktivem
+    `OriginConstraint` gilt ebenfalls `local_origin_capacity_kwh > 0`; sonst
+    ist die aktivierte Herkunftsbilanz inkonsistent
+    (`CONFIG_INCONSISTENT`, `format=kv1;reason=ORIGIN_CAPACITY_ZERO`).
+    Ohne aktiven `OriginConstraint` darf das Feld fehlen; `0` bedeutet nicht
+    "unbounded", sondern "keine nutzbare Herkunftsbilanz".
+  - Validierung: `0 <= e_local_0 <= local_origin_capacity_kwh`, wenn
+    `OriginConstraint` aktiv ist.
   - Validierung (nur wenn von `1.0` abweichend): `eta_min <= eta_charge <= 1`
     und `eta_min <= eta_discharge <= 1`; `eta_min` ist die gemeinsame
     Assetmodell-Invariante aus dem Robustheitspfad
@@ -468,10 +478,12 @@ Rollback-/Backout-Verhalten:
   `unclear`/`incompatible` nicht freizuschalten.
 - Für Ausnahmeszenarien kann ein Release-Block oder eine kontrollierte Suspendierung gelten:
   - Release-Block: Freigabe bis Daten bereinigt sind.
-  - Notfallmodus: optionaler Operator-Override nur für nicht-aktive Sites im Rahmen einer
-    dokumentierten Wartungsfreigabe.
-  - Nicht-aktive Sites sind im Notfallmodus mit `can_dispatch=false` explizit zu markieren;
-    aktive Sites bleiben weiterhin hart blockiert.
+  - Notfallmodus: optionaler Operator-Override nur für Sites, deren
+    Aktivitätsbewertung aus dem aktuellen Request-Kontext nicht aktiv ist, im
+    Rahmen einer dokumentierten Wartungsfreigabe.
+  - Im Notfallmodus dürfen Sites, deren Aktivitätsbewertung nicht aktiv ist, mit
+    `can_dispatch=false` modelliert werden; die Aktivitätsbewertung bleibt
+    request-basiert. Aktive Sites bleiben weiterhin hart blockiert.
 - Keine stillschweigende „Best-Effort“-Auto-Ableitung in produktivem Requestbetrieb.
 
 ### GreenStorageRestricted-Regeln (MVP)
@@ -486,7 +498,8 @@ Rollback-/Backout-Verhalten:
   - `0 <= e_local_t <= local_origin_capacity_kwh`
   - `local_origin_capacity_kwh > 0`; `0` ist `CONFIG_INCONSISTENT` mit
     `format=kv1;reason=GREEN_STORAGE_ORIGIN_CAPACITY_ZERO`.
-  - `e_local_0` ist konfigurierbar (meist 0).
+  - `e_local_0` kommt aus `LocalOriginState` und muss in der konfigurierten
+    Kapazität liegen.
 - Harte Koppelregeln:
   - `p_grid_import_t == 0` (für beide Site-Konventionen) – vollständiges Netzbezugsverbot.
   - `-b_t <= (g_t - c_t)` (Laden nur solange lokaler Überschuss vorliegt)
@@ -502,6 +515,7 @@ Fehlerklassifikation für `GreenStorageRestricted`:
 | Produktiv-Precheck | Produktiver Routine-Run ohne `green_storage_validation_mode=true` | `CONFIG_INVALID` | `GREEN_STORAGE_RESTRICTED_PRODUCTIVE_BLOCKED` |
 | Dispatch-Gate | `green_storage_validation_mode=true` ohne produktive Compliance-/Förderfreigabe | `CONFIG_INCONSISTENT` | `GREEN_STORAGE_RESTRICTED_VALIDATION_ONLY` |
 | Input-/Pre-Solver-Validierung | Fehlender oder nicht auditierbarer Herkunftsnachweis | `CONFIG_INCONSISTENT` | `GREEN_STORAGE_ORIGIN_PROOF_MISSING` |
+| Input-/Pre-Solver-Validierung | Aktivierter weicher Herkunftsnachweis ohne nutzbare Herkunftskapazität | `CONFIG_INCONSISTENT` | `ORIGIN_CAPACITY_ZERO` |
 | Input-/Pre-Solver-Validierung | Request fordert Netzladung oder modelliert Netzbezug als zulässige Ladequelle | `CONFIG_INCONSISTENT` | `GREEN_STORAGE_GRID_CHARGE_BLOCKED` |
 | Solver-Ergebnis | Harte Constraints (`p_grid_import_t == 0`, lokale Quelle, `e_local_t`) machen den angefragten Fahrplan mathematisch unerfüllbar | `MODEL_INFEASIBLE` | `GREEN_STORAGE_MODEL_INFEASIBLE` |
 
@@ -603,6 +617,9 @@ Bestandsrouten nicht brechen:
      `local_origin_capacity_kwh`-Randfall (`0`, Minimalreserve) werden explizit geprüft;
      `local_origin_capacity_kwh=0` blockiert mit `CONFIG_INCONSISTENT` und
      `format=kv1;reason=GREEN_STORAGE_ORIGIN_CAPACITY_ZERO`.
+   - Weicher `OriginConstraint` in `ClassicalCoLocation`/`HybridWithGridImport`
+     mit `local_origin_capacity_kwh=0` blockiert mit `CONFIG_INCONSISTENT` und
+     `format=kv1;reason=ORIGIN_CAPACITY_ZERO`.
    - `GreenStorageRestricted`: Lauf wird mit `CONFIG_INCONSISTENT` und
      `GREEN_STORAGE_GRID_CHARGE_BLOCKED` geblockt, wenn eine Netzladung
      (`p_grid_import_t > 0`) versucht wird.

docs/plan/planning/open/plan-price-forecast-adapters.md

@@ -227,7 +227,12 @@ Einheitliche Adaptervertraege für Preis- und Forecastdaten:
          eigenen Flag-Wert, falls dieser später explizit eingeführt wird.
       3. **Cutover freigeben**: Neue Family wird produktiv als `primary` markiert und auf mindestens `SOURCE_OK` oder ausdrücklich zugelassene `SOURCE_DEGRADED` gesetzt.
       4. **Produktiver Umschaltpunkt**: Alte Family in produktiven Runs auf `SOURCE_REJECTED`/`CanExecute=false` halten; alte Werte sind nur noch Replay/Diagnose sichtbar.
-      5. **Rollback-Fenster**: Rückkehr auf alte Family nur mit explizitem Release-Block möglich; Rollback ist nur dann erlaubt, wenn die neue Family in einem vollständigen Beobachtungsfenster keine vollständige akzeptierbare Lastserie (ohne harte Fallback) geliefert hat. Die Runbook-Marker `release_block` und `controlled_switchover` werden im Aktivierungs-Runbook definiert, inklusive Ablageort, Berechtigung und Löschregel.
+      5. **Rollback-Fenster**: Rückkehr auf alte Family nur mit explizitem
+         Release-Block möglich. Rollback ist nur zulässig, wenn die neue Family
+         im Beobachtungsfenster die Lastserie nicht ohne harten Fallback
+         akzeptierbar liefern konnte. Die Runbook-Marker `release_block` und
+         `controlled_switchover` werden im Aktivierungs-Runbook definiert,
+         inklusive Ablageort, Berechtigung und Löschregel.
       6. **Abschluss**: Alter Family-Schlüssel wird auf `ARCHIVED` gesetzt; neue Family läuft ohne Alias-Wechsel weiter.
   - Für einen stabilen Tie-Break werden bei gleicher Klasse numerisch zuerst
     `series_version` (wie definiert), danach nur bei unterschiedlichen, gültigen
@@ -333,6 +338,11 @@ Kanonische Ableitungsregeln (deterministisch):
   - Bei vorhandenem kompatiblem Fallback folgt die Fallback-Evaluierung.
   - Bei erfolgreichem Fallback: `series_status=SOURCE_FALLBACK_USED` oder
     `SOURCE_DEGRADED` je nach Backfill/Qualitätsminderung.
+    Präzedenz bei kombinierten Ereignissen ist verbindlich:
+    Qualitätsminderung schlägt Fallback. Wenn Fallback und Backfill bzw. andere
+    Degradation zugleich auftreten, ist `series_status=SOURCE_DEGRADED` und
+    `status_flags` enthält mindestens `SOURCE_FALLBACK_USED` und den
+    Degradationsflag, z. B. `SOURCE_BACKFILL`.
   - Bei fehlendem kompatiblen Fallback: harte Abweisung außer im `degraded_ok`-Modus
     für `SOURCE_STALE` (-> `SOURCE_DEGRADED`).
 - `source_eval_status=SOURCE_TRANSITIONAL_INPUT`:
@@ -430,9 +440,12 @@ Empfohlene Integrationskonvention (API/Operator):
     genau 1. Diese Rundungsregel ist bewusst konservativ und ersetzt
     horizon-spezifische Magic Numbers.
     Operative Folge: Bei typischen 24-h-/15-min-Horizonten greift Backfill wegen
-    dieser Mindestabdeckung praktisch nicht; Backfill ist erst bei längeren
-    Horizonten oder explizit konfigurierter niedrigerer Mindestabdeckung im
-    `quality_mode=degraded_ok` wirksam.
+    dieser Mindestabdeckung praktisch nicht. Das ist im Default gewollt:
+    Backfill ist nur bei längeren Horizonten oder explizit konfigurierter
+    niedrigerer Mindestabdeckung im `quality_mode=degraded_ok` aktiv. Tests für
+    `SOURCE_BACKFILL` müssen deshalb entweder einen längeren Horizon oder eine
+    explizit abgesenkte `min_coverage_ratio` verwenden; ein typischer
+    24-h-/15-min-Defaulttest erwartet keinen Backfill.
   - Die konsolidierte konsumierbare Serie muss nach Backfill keine offenen Lücken mehr enthalten.
 - Lückenregime:
   - Rohdaten mit Lücken vor Backfill sind nur zulässig, solange