Zum Inhalt

1:1-Spiegel aus dem Repo

Quelle: planning/UEBERSICHT_PROJEKTENTWICKLUNG_W6_2026-08-13.md · Stand der Quelldatei: 14.08.2026 00:32 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

ÜBERSICHT · Die vollständige W6-Projektentwicklung — Repo-Karte, Spinnennetz, Prüfweg

[W6-ODOO · GOV] · Stand 13.08.2026 ~23:45 · jede Zahl heute Abend selbst gemessen (Brücken-Inventur über alle sechs Ordner-Wurzeln, git --no-optional-locks)

0 · M-Wort vom 13.08. abends (bindend, Reihenfolge fest)

  1. Erst wird der Gesamt-Rückstand abgearbeitet — alles muss ins Git.
  2. Dann muss mkdocs (personenlesbare Doku) live sein.
  3. Alle Terminal-Agenten wieder live; alles Gemeldete im Git.
  4. Diese Übersicht ist das eine Blatt über die gesamte Projektentwicklung.
  5. Struktur: ein Core-Git, einzelne Entwicklungen als eigene Git-Projekte, Dokumentation untereinander verlinkt wie ein Spinnennetz; Beispiel: das PPWR-Modul ist ein eigenes Git mit eigener mkdocs.
  6. Keine Mac-Migration, bevor M nicht alles online selbst gesehen und geprüft hat.

Die Abarbeitung läuft über kickoffs/PROMPTS_ABSCHLUSS_ALLE_LANES_2026-08-13.md (P0–P8).


1 · Repo-Karte IST (gemessen 13.08. ~23:30)

Repo / Ordner Ort Branch offen Remote Zustand → Zug
w6-fleet-ops (Betriebs-Nabe) ~/W6_GITHUB main 13 Pfade (= Evening-Push-Einspielung des 13.08.: 36 Dateien) thetha/w6-fleet-ops wartet auf P0
W6-PPWR-2026 (Compliance) ~/W6-PPWR-2026-git sprint/2026-07-27 65 Pfade (9 M, 56 neu) thetha/W6-PPWR-2026 wartet auf P1 — größter Einzelrückstand
w6-odoo-core (Odoo-Nabe, Arbeitskopie) ~/W6_GITHUB/w6-odoo-core agent/git-memory-d048-v1.7.0 4 Pfade, darunter modules/w6-ppwr/ UNGETRACKT thetha/w6-odoo-core wartet auf P2
w6-odoo-core (Deploy-Klon) ~/W6_DEPLOY main 0 dito sauber
w6-agent-runtime (Board) ~/W6_GITHUB/w6-agent-runtime agent/T5-r9-board-v096 0, gepusht thetha/w6-agent-runtime Merge-Entscheid offen → P8/T5
w6-library ~/W6_GITHUB/w6-library main 0 thetha/w6-library sauber
w6-eintausch-automation v0.5.0-a1 ~/W6_GITHUB/… main 0 thetha/w6_eintauschaktion_google_apps_script sauber
dito (Deploy-Klon) ~/W6_DEPLOY main 0 dito sauber
w6-schnaeppchen_v1.5.3 ~/odoo-w6-projekte main 0 thetha/w6-schnaeppchen_v1.5.3 sauber
w6-versand-orchestrator ~/odoo-w6-projekte main 0 KEIN REMOTE — einziger Stand liegt lokal! P6
w6-werkstatt-system (Alt, 20.05.) ~/w6 staging 2 thetha/w6-werkstatt-system P7
Lane-Worktrees T1/T2/T3/T5/T6/T7 ~/W6_LANES Worktrees alle 0 (über fleet-ops) sauber; nach Klon per git worktree add neu erzeugbar
w6-odoo-modul-register (Modul-Nabe) ~/w6-odoo-modul-register/repo main 0, gepusht thetha/w6-odoo-modul-register P3 vollzogen 14.08. — Tag register-1.1.0
w6-ppwr-modul (+ mkdocs) ~/w6-ppwr-modul main 0, gepusht thetha/w6-ppwr-modul P3 vollzogen 14.08. — Tag v1.0.0
7 Odoo-Modul-Repos (config_w6 …) ~/w6-odoo-modul-register/repo/module/<name>/quelle main 0, gepusht thetha/w6-odoo-modul-<name> P3 vollzogen 14.08. — Remotes je Modul in §2

Unversioniertes mit Wert (liegt NUR auf diesem Mac + teils im Chat) — „Sondergepäck"

Posten Größe Heimat-Plan
~/W6_GITHUB/module_src/ — Modulquellen + Register-Archiv (tar.gz.part00–02, SHA dfe588e5…) 46 M P3 schafft GitHub-Heimat (8 Repos)
~/W6_GITHUB/pakete/ Binärteile: w6-odoo-agents.skill, w6-agent-brain.zip, Snapshots ~2 M M speichert Skill im KONTO; Brain-Repo = offener Tafel-Posten
Root-ZIPs + eucompliancedossier.skill ~2 M nach P3 prüfen, was obsolet ist (nichts löschen — _to_delete/)
~/w6 (5 Ordner ohne Git + 2 ZIPs) 3,9 M Alt-System: M entscheidet mitnehmen/zurücklassen
~/odoo-w6-projekte: w6 automation/, W6_DHL_OUT_v5.0.2/ (1.802 Dateien, kein Git) 15 M gesamt bei Migration als Ordnerkopie; oder eigene Repos, wenn lebendig

2 · SOLL-Struktur: das Spinnennetz (M-Wort, D-075)

                         ┌─────────────────────────────┐
                         │  w6-fleet-ops  (BETRIEB)    │  ← Diese Übersicht = Startseite
                         │  ROLLING_PLAN · DECISIONS   │     mkdocs LIVE (P5): w6-doku.pages.dev
                         └──────┬──────────────┬───────┘
             verlinkt hinunter  │              │  verlinkt hinunter
                    ┌───────────▼───┐      ┌───▼──────────────────┐
                    │ w6-odoo-core  │      │ W6-PPWR-2026         │
                    │ (ODOO-NABE)   │◄────►│ (COMPLIANCE)         │
                    │ Register v1.5 │      │ eigenes mkdocs (SOLL)│
                    └──┬─┬─┬─┬─┬─┬──┘      └───────▲──────────────┘
        je Modul ein   │ │ │ │ │ │                 │ fachlicher Quer-Link
        eigenes Git:   ▼ ▼ ▼ ▼ ▼ ▼                 │
   w6-ppwr-modul(+mkdocs!) · config_w6 · patches_to_server · printnode_base
   · queue_job(OCA-Spiegel) · report_py3o(OCA) · sale_automatic_workflow(OCA) · sandas_maintenance19
        + daneben: w6-agent-runtime · w6-library · Eintausch-GAS · schnaeppchen · versand-orchestrator

Die vier Verlinkungsregeln:

  1. Jedes Sub-Repo verlinkt hinauf (README: → Core-Register, → fleet-ops-Übersicht) und zu fachlichen Nachbarn (w6-ppwr-modul ↔ W6-PPWR-2026).
  2. Jede Nabe verlinkt hinunter: das Modulregister trägt die 8 Repo-URLs; diese Übersicht trägt ALLE Repos (Tabelle §1 = das Netz in Listenform).
  3. Jede Entwicklung, die lebt, bekommt eigenes Git + personenlesbare mkdocs (Beispiel und Pflichtfall: w6-ppwr-modul). Doku wird generiert, nie von Hand gepflegt (Register-Regel R2; tools/gen_doku.py).
  4. Neue Entwicklung ⇒ neue Zeile in §1 + Registerzeile vor der ersten Änderung (D-075). Ohne Zeile existiert das Projekt nicht.

mkdocs-Ausbau: Stufe 1 (heute, P5): fleet-ops-Site live. Stufe 2: w6-ppwr-modul mit eigener mkdocs (P3 Schritt 4) — vollzogen 14.08., mkdocs build --strict läuft sauber durch; die Site ist noch nicht deployed (eigener Auftrag). Stufe 3: W6-PPWR-2026 und w6-odoo-core je eigene Site, untereinander verlinkt — eigene Aufträge nach Ms Online-Prüfung.

Vollzug P3 (14.08.2026) — die neun neuen Remotes

Alle privat, alle unter thetha. Regel 1 (Verlinkung hinauf + zu Nachbarn) ist in jedem README erfüllt, Regel 2 (Nabe verlinkt hinunter) im Modulregister v2.4, Abschnitt 4.

Repo Remote Tag Rolle im Netz
w6-odoo-modul-register thetha/w6-odoo-modul-register register-1.1.0 Nabe über den 7 Modulen: Doku je Modul, register.json, Prüfliste, Werkzeuge
w6-ppwr-modul thetha/w6-ppwr-modul v1.0.0 das M-Beispiel — eigenes Git + eigene mkdocs; Quer-Link ↔ W6-PPWR-2026
w6-odoo-modul-config_w6 thetha/w6-odoo-modul-config_w6 v19.0.0.1 W6-Hausmodul (Sandas) — greift am breitesten in den Standard ein
w6-odoo-modul-patches_to_server thetha/w6-odoo-modul-patches_to_server v19.0.1.0.0 Server-Patches (Sandas)
w6-odoo-modul-printnode_base thetha/w6-odoo-modul-printnode_base v19.0.2.8.0 VentorTech, OPL-1 kostenpflichtig — bleibt dauerhaft privat
w6-odoo-modul-queue_job thetha/w6-odoo-modul-queue_job v19.0.2.0.1 OCA-Spiegel (Upstream OCA/queue)
w6-odoo-modul-report_py3o thetha/w6-odoo-modul-report_py3o v19.0.1.0.0 OCA-Spiegel (Upstream OCA/reporting-engine)
w6-odoo-modul-sale_automatic_workflow thetha/w6-odoo-modul-sale_automatic_workflow v19.0.1.0.0 OCA-Spiegel (Upstream OCA/sale-workflow)
w6-odoo-modul-sandas_maintenance19 thetha/w6-odoo-modul-sandas_maintenance19 v19.0.1.0.0 Wartungsmodul des Hosters

Offen aus P3: der Quer-Link W6-PPWR-2026 → w6-ppwr-modul (Gegenrichtung von Regel 1) — fremde Zone, gehört in die PPWR-Lane, nicht zur GIT-Lane.


3 · Prüfweg für M — „online selbst sehen und prüfen"

Nach dem Durchlauf P0–P8 prüfst Du im Browser, ohne Terminal:

# Wo Was Du sehen musst
1 github.com/thetha/w6-fleet-ops jüngster Commit = Referenz-SHA aus P0; Ordner comms/odoo/ mit 20 Dateien; dieses Blatt unter planning/
2 github.com/thetha/W6-PPWR-2026 (Branch sprint/2026-07-27) Evening-Commit von P1 (≈65 Dateien), LEITSTAND_AKTUELL mit Vermerk
3 github.com/thetha/w6-odoo-core (Branch agent/git-memory-…) Commit mit modules/w6-ppwr/ — das Modul liegt damit erstmals auf GitHub
4 GitHub-Profil thetha 8–9 neue private Repos: w6-odoo-modul-register, w6-ppwr-modul, config_w6, patches_to_server, … (P3-Meldung nennt die URLs)
5 https://w6-doku.pages.dev die Doku-Site, Build-Zeitstempel von heute — danach Access-Schutz setzen (bis dahin öffentlich erreichbar)
6 github.com/thetha/w6-versand-orchestrator existiert, 1 Commit-Historie bis 14.07.
7 dieses Blatt §1 Spalte „Zustand": alle Zeilen ohne offenen Zug

Erst wenn 1–7 grün sind, fällt Ms Wort zur Mac-Migration. Dann gilt docs/SETUP_NEUER_MAC.md (D-064) plus die Sondergepäck-Liste aus §1 dieses Blatts (was Git nicht trägt, wandert als Ordnerkopie/AirDrop — oder hat bis dahin durch P3 eine GitHub-Heimat). Die Thread-Übergabe ist bereits vorbereitet: Block „UEBERGABE AN NEUEN THREAD (13.08.2026)" in comms/G_AKTUELL.md, Bootstrap-Erstnachricht inklusive.


4 · Offene Entscheide, die dieses Blatt berühren

Entscheid Wer
Access-Schutz vor oder direkt nach dem ersten Pages-Deploy M (P5 Schritt 4)
~/w6-Altsystem mitnehmen oder bewusst zurücklassen M (bei Migration)
OCA-Module als Spiegel-Repos oder nur Registerverweis Werkbank nach SUBMODULE_PLAN, STOPP wenn unklar
w6-agent-brain.zip → eigenes Repo M-Wort steht aus (Tafel-Posten seit 12.08.)