docs: align market spec activation contracts

Author: pt9912

docs/plan/planning/open/note-market-and-colocation-followups.md

@@ -173,8 +173,9 @@ sowie Forecast-Serien.
 - [ ] F-MKT-01-Abnahmebedingungen sind als Slice-Startkriterien dokumentiert und
   für mindestens diese drei produktiven Betriebsformen (`StandaloneBess`,
   `ClassicalCoLocation`, `HybridWithGridImport`) definiert.
-- [ ] `GreenStorageRestricted` ist als separater Sondermodus für einen späteren
-  Validierungsslice dokumentiert.
+- [ ] `GreenStorageRestricted` läuft im ersten Slice als Validierungsmodus mit
+  harten Constraints; produktive Förderautomatik bleibt einem späteren Slice
+  vorbehalten.
 - [ ] F-MKT-02-Abnahmebedingungen sind als Slice-Startkriterien dokumentiert
   (Preis: 1 Primär + 1 Fallback; Forecast: je 2 Adapter für `load` und
   `weather-temp`; jeweils Fallback-/Degradation-Modell, Aktualisierung +

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

@@ -73,6 +73,7 @@ Nicht vorhanden:
      - Sammelbeiträge wie `source_ok` sind all-or-nothing: mehrere Slices oder
        mehrere Serien dürfen denselben Slot bedienen, und jeder einzelne
        `source_ok=false`-Beitrag zieht das aggregierte `source_ok` auf `false`;
+     - nicht aktivierte Beiträge gelten im jeweiligen Lauf als neutral `true`;
      - der Combiner berechnet monoton `CanExecute = HasUsableSolution && all(_ok)`.
 
 ### Gemeinsame Run-Mapping-Matrix
@@ -134,7 +135,8 @@ duplizieren diese Matrix nicht.
        Domain-Wireform `TerminationCode:TerminationDetail` am ersten `:` trennt.
        Werte mit natürlichem Doppelpunkt (z. B. ISO-Zeitstempel oder URLs) müssen
        vor Persistierung percent-encoded werden; neue Parser dekodieren nur
-       innerhalb von `format=kv1`.
+       innerhalb von `format=kv1`. Das gilt auch für `series_version`-Werte aus
+       Forecast-/Preisreihen, falls sie in `TerminationDetail` aufgenommen werden.
 
 3. Persistenz und Wire
    - `can_execute` in allen produktiven Stores hinzufügen:

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

@@ -10,7 +10,7 @@ Baltputnis et al. (2024), Journal of Energy Storage 102, 114082
 [`../../../../spec/architecture.md`](../../../../spec/architecture.md),
 [`../done/plan-RM-M4.md`](../done/plan-RM-M4.md),
 [`../done/plan-RM-M5.md`](../done/plan-RM-M5.md),
-[`../open/plan-price-forecast-adapters.md`](../open/plan-price-forecast-adapters.md)
+[`plan-price-forecast-adapters.md`](plan-price-forecast-adapters.md)
 
 ---
 
@@ -318,7 +318,10 @@ Deterministische Berechnung (verbindlich):
       symmetrisch abgedeckt.
     - Diese Kopplung ist bewusst konservativ und vollständig deterministisch.
   - Wenn simultanes Gegensignal laut Produktdefinition aktiv ist, aber `simultaneous_reserve_direction_allowed=false`,
-    gilt hart `ROBUST_POLICY_UNSUPPORTED` mit `POLICY_MISMATCH`.
+    gilt hart `ROBUST_POLICY_UNSUPPORTED` mit `POLICY_MISMATCH`. Diese Sperre
+    gilt nur für separat gebuchte Up-/Down-Produkte (aFRR/mFRR); FCR wird als
+    symmetrisches Produkt unabhängig vom Flag mit getrennten Up-/Down-Hüllen
+    ausgewertet.
 - FCR-Worst-Case-Konsistenz bei Mindestzeit:
   - Für FCR wird die Mindestaktivierungszeit mit zwei getrennten Zustandsgrößen geführt:
     - `fcr_remaining_envelope_t` ist die konservative Worst-Case-Hülle in Minuten.
@@ -585,12 +588,10 @@ Order-Routing oder Börsenanbindung bleibt außerhalb.
 
 ### Phase 3: Optimierungsintegration
 
-- Dieser Abschnitt ist der gemeinsame Referenzvertrag für Ausführungs- und
-  Guard-Verhalten (`OptimizationSolverStatus`, `TerminationCode`, `CanExecute`,
-  `CanExecute=false`-Interpretation).  
-  Das Gegenstück im Co-Location-Slice ist
-  [`plan-market-colocation-model.md`](plan-market-colocation-model.md);
-  beide Abschnitte müssen semantisch identisch bleiben.
+- Die gemeinsame Run-Mapping-Matrix lebt im Pre-Slice
+  [`Domain-Migration OptimizationRun.CanExecute`](plan-domain-migration-optimization-run-can-execute.md).
+  Dieser Abschnitt liefert nur robustheitsbezogene Guard-Beiträge und Codes; er
+  muss mit der Pre-Slice-Matrix konsistent bleiben.
 
 - Precheck für Schedule-Optimierung:
   - Reserveband darf nicht nur leistungsmässig passen, sondern muss
@@ -708,7 +709,7 @@ Order-Routing oder Börsenanbindung bleibt außerhalb.
 - Kein Ersatz für BMS-/PCS-Schutzfunktionen.
 - Keine Änderung der bestehenden Vorzeichenkonvention.
 - Kein Forecast-Adapter; Quellenbeschaffung bleibt
-  [`plan-price-forecast-adapters.md`](../open/plan-price-forecast-adapters.md).
+  [`plan-price-forecast-adapters.md`](plan-price-forecast-adapters.md).
 
 ---
 

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

@@ -199,11 +199,11 @@ Mögliche Domain-/Application-Erweiterungen:
   - Weitere Pflichtfelder:
     - `value_kw`
     - `value_type` (`forecast` | `actual`)
-    - `source`
-    - `product`
+    - `source_metadata.provider_id`
+    - `series_product`
     - `unit` (z. B. `kW`)
-    - `updated_at_utc`
-    - `value_version`
+    - `source_metadata.retrieved_at_utc`
+    - `series_version`
   - Validierung:
     - gleiche Zeitachse wie `PriceSeries` (UTC, step-genau, gleiche Horizon-Länge) bei produktiver Nutzung.
       Abweichende Quellauflösungen sind im produktiven Co-Location-Pfad nur
@@ -212,21 +212,10 @@ Mögliche Domain-/Application-Erweiterungen:
       `alignment_mode=resample`-Pfad mit deterministischer Aggregations-/
       Interpolationsregel freigibt. Dieser Plan definiert noch keinen
       produktiven Resampling-Pfad.
-    - Ist `alignment_mode=reject` (Default im produktiven ADR): die Zeitachse muss hart identisch sein (gleiches Horizon, gleiche Schrittweite, gleiche Startzeit).
-    - Ist `alignment_mode=trim-to-common` gesetzt:
-      - `alignment_prepared` darf nur zusammen mit `alignment_mode=trim-to-common` verwendet werden;
-        `alignment_prepared=true` bei anderem `alignment_mode` ist `SCHEMA_INCONSISTENT`.
-      - produktive Optimierung darf `trim-to-common` nur mit explizit abgeschlossenem Vorverarbeitungs-Pfad und nachweislicher Versionierung in den zugehörigen Vorverarbeitungsfeldern starten; ohne diese Voraussetzungen führt der Lauf zu `SCHEMA_INCONSISTENT`.
-      - Schnittmenge auf den gemeinsamen Zeithorizont.
-      - `alignment_prepared_by` und die vorbereiteten Horizon-Grenzen (`alignment_prepared_horizon_start_utc`, `alignment_prepared_horizon_end_utc`) müssen gesetzt sein.
-      - deterministische Konvention bei Zeitachsen-Verschiebung.
-      - lückenbehaftete Schritte müssen im Anschluss vollständig abgearbeitet werden.
-      - nur im Forecast-/Preprocessing-Pfad, danach muss der Standardpfad (`reject`) mit lückenloser Zeitachse erhalten bleiben.
-      - keine offenen Zeitlücken; zulässig: kontrollierte Backfill-Regel
-        (max. 2 aufeinanderfolgende Intervalle pro Lücke).
-      - Backfill ist nur in diesem vorbereiteten `trim-to-common`-Vorverarbeitungspfad
-        zulässig. Bei `alignment_mode=reject` gibt es kein Backfill; jede
-        Zeitachsenabweichung bleibt `SCHEMA_INCONSISTENT`.
+    - Für Alignment gilt ausschließlich der Vertrag aus
+      [`plan-price-forecast-adapters.md`](plan-price-forecast-adapters.md):
+      produktiver Default ist `alignment_mode=reject`; `trim-to-common` ist nur
+      über den dort spezifizierten versionierten Vorverarbeitungspfad zulässig.
       - Wenn die Vorverarbeitung Werte auffüllt oder schätzt, muss das
         resultierende `SeriesEnvelope` das Flag `SOURCE_BACKFILL` behalten. Solche
         Serien sind im produktiven `quality_mode=strict` nicht zulässig und dürfen
@@ -237,7 +226,8 @@ Mögliche Domain-/Application-Erweiterungen:
     - Negative Werte sind nur über einen separaten signierten Netzausgangs-Datensatz zulässig.
     - Last-Forecasts sind keine `LocalGenerationSeries`; sie laufen als
       `ForecastSeries` mit `series_product=load` über den Forecast-Adaptervertrag.
-    - Metadatenpflicht für `source`, `product`, `updated_at_utc`, `value_version`.
+    - Metadatenpflicht gemäß `SeriesEnvelope`: `source_metadata.provider_id`,
+      `series_product`, `source_metadata.retrieved_at_utc`, `series_version`.
 
 - `LocalOriginState`
   - virtuelle Zwischenbilanz für herkunftsgebundene Energie (kWh)
@@ -530,10 +520,15 @@ Bestandsrouten nicht brechen:
    - `site_grid_power_sign=import_pos`: Vorzeichen-/Grenzlogik bleibt konsistent
      zur Export-Variante bei identischem physischem Leistungsfluss.
    - Netzexportlimit begrenzt Batterieentladung plus lokale Erzeugung.
-   - `GreenStorageRestricted`: `e_local_0`-Randfall (`0` und >0) und `local_origin_capacity_kwh`-Randfall (`0`, Minimalreserve) werden explizit geprüft.
+   - `GreenStorageRestricted`: `e_local_0`-Randfall (`0` und >0) und
+     `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`.
    - `GreenStorageRestricted`: Lauf wird mit `CONFIG_INCONSISTENT` und
      `GREEN_STORAGE_GRID_CHARGE_BLOCKED` geblockt, wenn eine Netzladung
      (`p_grid_import_t > 0`) versucht wird.
+   - Co-Location-Konfigurations- und Schemafehler setzen `CanExecute=false`
+     gemäß Pre-Slice-Matrix.
    - Reservebänder reduzieren weiterhin verfügbare Lade-/Entladeleistung.
    - `migration_strict=false` erlaubt nicht-aktive `can_dispatch=false`-Sites mit
      `unclear`/`incompatible` im Migrationsfenster, blockiert aber aktive Sites

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

@@ -200,7 +200,9 @@ Hinweis zur Semantik:
 - `status_detail` (optional): strukturierte Zusatzinfo (z. B. `{ "source_code": "SOURCE_STALE", "backfill_intervals_closed": 2, "effective_source_id": "opsd-..." }`)
 - `value_hash`: optional für reine Einmalimporte ohne Idempotenz-/Cutover-Vertrag;
   verpflichtend, sobald Versions-Idempotenz, Re-Load-Vergleich, Family-Cutover oder
-  Rollback aktiviert ist. Der Hash stabilisiert den Payload-Vergleich.
+  Rollback aktiviert ist. In der Erstaktivierung von Phase 1/2 ist `value_hash`
+  Pflicht, außer der Adapter ist explizit als Einmalimport ohne Re-Load-Vertrag
+  deklariert. Der Hash stabilisiert den Payload-Vergleich.
 - Validierungspflicht:
   - strikte UTC-Zeitachse
   - Schrittweite exakt `resolution_minutes`
@@ -686,6 +688,8 @@ arbeitet mit deterministischen Preiswerten.
   - `SOURCE_EMPTY` ohne expliziten degraded-Zulassungsweg bleibt hart abweisend.
 - [ ] Versions- und Idempotenzregeln umgesetzt:
   - eindeutiger Revisionsvergleich pro `(series_id, series_version, source.provider_id)`,
+  - `value_hash` ist für produktive Phase-1/2-Adapter vorhanden, außer bei
+    explizit deklarierten Einmalimporten ohne Re-Load-Vertrag,
   - payload-identisches Re-Load ist idempotent,
   - Provider-Kontexte trennscharf unabhängig von identischem `series_id`/`series_version`.
   - kontrollierter Cutover/Rollback für `series_version_family` ist dokumentiert und mit den obigen Family-Tests verifiziert.