| # Meta3.0 Overnight Control Plane |
|
|
| Zweck: Dieser Ordner bereitet grosse Qwen/API-Auswertungen vor, ohne sie |
| versehentlich zu starten. |
|
|
| ## Kanonische Linie |
|
|
| - `Meta3.0` ist der neue Kontrollordner fuer Fragen, Anforderungen, Run- |
| Manifeste und Overnight-Planung. |
| - `Meta2.0` bleibt die aktuelle Daten-Pipeline fuer Session-Inventar und |
| Layer-1-Digests. |
| - `META2.0` ist Legacy-Frage-Fanout und nicht die Arbeitslinie. |
|
|
| Wichtig: Fanout nach Daten-Shards, nicht nach Fragen. Erst Session-Digests |
| stabilisieren, dann Fragen beantworten. |
|
|
| Der Unterschied: Meta2.0 erzeugt verwertbare Session-Digests. Meta3.0 prueft, |
| welche Aussagen daraus ueberhaupt belastbar sind. Meta3.0 ist deshalb |
| Experiment-Design, Evidenzvertrag, Gegenbeweis-Suche und Owner-Synthese ueber |
| Meta2.0, nicht nur mehr API-Budget. |
|
|
| Der Meta3-Prozess steht in `docs/META3_PROCESS.md` und |
| `config/process_model.json`. Der erste sinnvolle Loop ist Kalibrierung vor |
| Scale-up, nicht sofort 10 Mio Calls. |
|
|
| ## Aktueller Stand der Vorarbeit |
|
|
| Quelle: `/home/smlflg/Projekte/Meta2.0` |
|
|
| - Inventory: 1,104 Session-Dateien. |
| - Zuletzt beobachteter Layer-1 Stand im lokalen Smoke: 216 / 1,104. |
| - Zuletzt beobachtete Coverage im lokalen Smoke: 19.57%. |
| - Stable setting laut Meta2.0: `--batch-size 3 --concurrency 2`. |
|
|
| ## Ordner |
|
|
| - `config/` - Fragen und Run-Profil. |
| - `docs/evals/` - blockierende Eval-Spezifikationen fuer den Versuchsaufbau. |
| - `requirements/` - Samuels kommende Anforderungen und Intake. |
| - `scripts/` - lokale Prepare-/Plan-/Smoke-Scripts, keine API-Calls. |
| - `runs/` - pro Overnight-Versuch ein eigener Run-Ordner. |
| - `data/` - Meta3-spezifische Zwischenartefakte. |
| - `reports/` - menschliche Reports und Status. |
| - `logs/` - lokale Logs. |
|
|
| ## Schnellstart |
|
|
| ```bash |
| python3 scripts/meta3_smoke.py |
| python3 scripts/meta3_prepare.py |
| python3 scripts/meta3_plan_batches.py |
| python3 scripts/meta3_freeze_sources.py |
| python3 scripts/meta3_build_workpackets.py --mode calibration --sample-size 24 |
| python3 scripts/meta3_validate_run.py |
| python3 scripts/meta3_run_packets.py --mode calibration --limit 1 |
| python3 scripts/meta3_runner_status.py |
| python3 scripts/meta3_preflight.py --mode calibration --accepted-call-budget 10 |
| python3 scripts/meta3_collect_responses.py --mode calibration --allow-empty |
| python3 scripts/meta3_morning_report.py |
| python3 scripts/meta3_orchestrate_local.py --accepted-call-budget 10000000 |
| ``` |
|
|
| Das erstellt einen Run-Ordner unter `runs/` und einen Batchplan. Es ruft keine |
| API auf. Der Workpacket-Schritt erzeugt Prompts und Call-Ledger fuer einen |
| spaeteren Runner, ebenfalls ohne Netzwerk. Der Runner-Befehl ohne |
| `--execute-network` ist nur ein Dry-Run. |
|
|
| Wenn `meta3_build_workpackets.py` mit `Source drift refused` stoppt, ist das ein |
| gewollter Gate: Meta2.0-Audit und rohe Digest-Datei sind nicht synchron. Dann |
| entweder erst `python3 scripts/meta3_freeze_sources.py` ausfuehren und gegen den |
| lokalen Snapshot arbeiten, oder den Meta2-Audit aktualisieren. |
|
|
| ## Start-Gate fuer spaeter |
|
|
| Ein echter Overnight-Lauf darf erst starten, wenn: |
|
|
| 1. `requirements/PENDING.md` durch Samuels konkrete Anforderungen ersetzt oder |
| ergaenzt wurde. |
| 2. `python3 scripts/meta3_smoke.py` ohne ERROR laeuft. |
| 3. `python3 scripts/meta3_prepare.py` ein Run-Manifest erzeugt. |
| 4. `python3 scripts/meta3_plan_batches.py` einen Batchplan erzeugt. |
| 5. Der geplante Call-/Kosten-/Concurrency-Rahmen explizit akzeptiert ist. |
| 6. Der Meta3-Improvement-Vertrag aus `config/experiment_design.json` fuer den |
| konkreten Lauf nicht verletzt wird. |
|
|
