Tier-Strategie & Qualitätssicherung
BACON-AI Workshop: Architecture & Design Document — Port-Konvention v2.0 (Service-Projekt-Tier), Multi-Tenant-Architektur, BACON-AI Test-Framework und TAXD Dokumenten-Architektur.
1. Einführung: Warum eine Tier-Strategie?
In der professionellen Softwareentwicklung sind Produktivsysteme heilig. Kein Entwickler, kein Agent und kein Prozess darf direkte Änderungen an einem laufenden Produktivsystem vornehmen. Alle Änderungen durchlaufen eine kontrollierte Pipeline, in der sie Schritt für Schritt getestet und freigegeben werden.
SAP-Erbe: BACON-AI adaptiert das SAP-Instanznummernmodell —
bewährt seit über 40 Jahren bei Tausenden von Unternehmen. Kombiniert mit
modernem Docker, Odoo Multi-Datenbank und Cloud-nativen Architekturen.
Das Ergebnis: Jeder Port, jede URL, jede Datenbank erzählt ihre eigene Geschichte — keine Rätsel, keine Verwechslungen.
Die Lösung vs. Das Problem
flowchart LR
subgraph solution ["Die Loesung: Konvention"]
direction TB
S1["Port 8901\nOdoo / Sandbox / Orch"]
S2["Port 8401\nOdoo / Dev / Orch"]
S3["Port 5004\nWeb / Prod / Launcher"]
S1 --> S2 --> S3
end
subgraph problem ["Das Problem: Port-Chaos"]
direction TB
P1["Port 8069\nWas laeuft hier?"]
P2["Port 3000\nProduktion? Dev?"]
P3["Port 5173\nWelches Projekt?"]
P1 --> P2 --> P3
end
style S1 fill:#0d3320,stroke:#00e676,color:#e0e6f0
style S2 fill:#0d3320,stroke:#00e676,color:#e0e6f0
style S3 fill:#0d3320,stroke:#00e676,color:#e0e6f0
style P1 fill:#3d1010,stroke:#ff5252,color:#e0e6f0
style P2 fill:#3d1010,stroke:#ff5252,color:#e0e6f0
style P3 fill:#3d1010,stroke:#ff5252,color:#e0e6f0
style solution fill:#0a1f15,stroke:#00e676,color:#80ffbb
style problem fill:#1f0a0a,stroke:#ff5252,color:#ff8a8a
Links: Jeder Port hat eine klare Bedeutung. Rechts: Ohne Konvention herrscht Chaos.
2. Die Port-Formel: Jede Ziffer hat Bedeutung
Port = [Service][Projekt##][Tier] — eine 4-stellige Zahl, die sich selbst erklärt.
Lesregel: „Dies ist ein [Service] für [Projekt], laufend in [Tier]“
⚠ v2.0 — Tier ist jetzt die letzte Stelle (nicht mehr die zweite). Alle alten Port-Nummern wurden nach diesem Schema aktualisiert.
| Position | Name | Werte | Bedeutung |
|---|---|---|---|
| 1. Ziffer | Service-Typ | 3–9 | Welche Art von Dienst? |
| 2.–3. Ziffer | Projekt | 01–99 | Welches Projekt? |
| 4. Ziffer | Tier | 0–9 | Welche Umgebung? (0=Prod, 9=Sandbox) |
2.1 Typ-Codes (1. Ziffer)
| Code | Dienst-Kategorie | Beispiele |
|---|---|---|
| 3 | MCP-Server, KI-Agent-Endpunkte | Governance-Nudge-Channel |
| 4 | API-Backends, REST-Dienste | Session-API, Run-API |
| 5 | Web-Frontends, SPAs, Dokumentation | BPMN-Editor, Docs-Seite |
| 6 | Monitoring, Observability, Analytics | Grafana, Health-Checks |
| 7 | WebSocket, Channels, Echtzeit | SSE-Endpunkte, Event-Streams |
| 8 | Odoo-Instanzen (ERP/Workflow) | Orchestrator, Rental |
| 9 | Overflow, temporär, experimentell | Schnelle Prototypen |
2.2 Tier-Codes (4. Ziffer — letzte Stelle)
| Code | Umgebung | Schutzlevel | Pflicht-Tests |
|---|---|---|---|
| 0 | PRODUKTION | Heilig — niemals direkt ändern | TUT + FUT + SIT + UAT + Regression + Perf |
| 1 | Hotfix / Notfall | Geschützt — Audit erforderlich | TUT + FUT + SIT (Minimum) |
| 2 | Staging / UAT | Kontrolliert — Benutzerabnahme | Vollständige Regression |
| 3 | QA / SIT | Verifiziert — Integrationstest | SIT (System-Integrationstest) |
| 4–8 | Entwicklung A–E | Offen — hier wird Code geschrieben | TUT während der Entwicklung |
| 9 | Sandbox | Frei — hier darf man alles kaputt machen | Keine Tests erforderlich |
2.3 Projekt-Nummern (2.–3. Ziffer)
| Nr. | Kategorie | Projektname | Primärer Dienst |
|---|---|---|---|
| 01 | ORCH | Workflow Orchestrator | Odoo (8xxx) |
| 02 | RENT | Odoo Rental Management | Odoo (8xxx) |
| 03 | MESH | Bacon Mesh | Web (5xxx) |
| 04 | LNCH | Bacon Launcher | Web (5xxx) |
| 05 | VOIC | Bacon Voice / TTS | API (4xxx) |
| 06 | WALL | Bacon Wallpaper | Web (5xxx) |
| 07 | DATV | Mouse-Click Datev | Web (5xxx) |
| 08 | KOFL | Kofali Contract Review | Web (5xxx) |
| 09 | BPMN | BPMN-AI AgenticFlow | Web (5xxx), API (4xxx) |
| 10 | BRST | Brainstorm Companion | Web (5xxx), WS (7xxx) |
| 11 | DASH | Server Dashboard | Web (5xxx), API (4xxx) |
| 12 | FLWS | Flowise (TNAS) | Web (5xxx) |
| 13 | MEMO | Memos | Web (5xxx) |
| 14 | N8N | n8n Automation | Web (5xxx) |
| 15 | TAXD | Tax Document Registry | API (4xxx), Web (5xxx) |
| 16–99 | — | (verfügbar) | — |
Konflikte vermeiden — diese Kombinationen NICHT verwenden
| Service | Projekt überspringen | Würde erzeugen | Konflikt mit |
|---|---|---|---|
| 5 (Web) | 17 | 5173 | Vite Dev-Server |
| 5 (Web) | 43 | 5432 | PostgreSQL |
| 5 (Web) | 90 | 5900 | VNC |
| 6 (Monitor) | 37 | 6379 | Redis |
| 3 (MCP) | 30 | 3306 | MySQL |
| 8 (Odoo) | 08 | 8080 | HTTP-Alt |
| 8 (Odoo) | 44 | 8443 | HTTPS-Alt |
Port-Beispiele auf einen Blick
8010
8=Odoo, 01=Orch, 0=Produktion
8019
8=Odoo, 01=Orch, 9=Sandbox
8024
8=Odoo, 02=Rental, 4=Dev A
5040
5=Web, 04=Launcher, 0=Produktion
3010
3=MCP, 01=Orch, 0=Produktion
8023
8=Odoo, 02=Rental, 3=QA/SIT
3. Die Promotions-Pipeline: Code fließt nur in eine Richtung
Das Herzstück der Tier-Strategie ist die Promotions-Pipeline. Code bewegt sich immer von unten nach oben — niemals rückwärts. An jeder Grenze steht ein Test-Gate, das bestanden werden muss.
flowchart BT
SAND["SANDBOX\nPort xx9x\nFrei experimentieren"]
DEV["DEVELOPMENT\nPort xx4x - xx8x\nTUT + FUT waehrend der Arbeit"]
QA["QA / SIT\nPort xx3x\nIntegrationstest"]
STAG["STAGING / UAT\nPort xx2x\nBenutzerabnahme"]
HOT["HOTFIX\nPort xx1x\nNotfall-Bypass"]
PROD["PRODUKTION\nPort xx0x\nHEILIG"]
SAND -->|"keine Huerde"| DEV
DEV -->|"TUT + FUT + PR"| QA
QA -->|"SIT + Regression"| STAG
STAG -->|"UAT + Perf + Security"| PROD
HOT -->|"TUT + FUT + SIT"| PROD
style SAND fill:#3d2e00,stroke:#ffab40,color:#ffe080
style DEV fill:#0d3320,stroke:#00e676,color:#80ffbb
style QA fill:#0d1a3d,stroke:#448aff,color:#80b0ff
style STAG fill:#3d2e00,stroke:#ffab40,color:#ffe080
style HOT fill:#3d2200,stroke:#ff8a40,color:#ffc080
style PROD fill:#3d1010,stroke:#ff5252,color:#ff8a8a
Die Promotions-Pipeline: Code fließt immer bottom-up. Jede Stufe hat ein Test-Gate.
3.1 Warum nur in eine Richtung?
- Sandbox → Dev: Ideen fließen frei
- Dev → QA: Nur getesteter Code wird weitergegeben
- QA → Staging: Nur integrierte Features erreichen die Benutzerabnahme
- Staging → Produktion: Nur vom Benutzer abgenommener Code geht live
Niemals rückwärts. Ein Hotfix ist der einzige Bypass —
und selbst der erfordert Tests (TUT + FUT + SIT als Minimum).
4. Multi-Tenant-Architektur: Ein Container, viele Projekte
4.1 Das SAP-Mandanten-Modell
In SAP läuft eine Instanz auf einem Applikationsserver (Port) mit mehreren Mandanten (Clients). Jeder hat eigene Daten, teilt aber die Software. BACON-AI übernimmt dieses Modell für Odoo.
flowchart TB
DC["Docker Container\nOdoo 19.0 Server\nPort 8069 intern"]
DB1["orch-0001-sand"]
DB2["rent-0001-sand"]
DB3["kofl-0001-sand"]
PG["PostgreSQL 16"]
DC --> DB1
DC --> DB2
DC --> DB3
DB1 --> PG
DB2 --> PG
DB3 --> PG
style DC fill:#141a2e,stroke:#00e5ff,color:#e0e6f0
style DB1 fill:#0d3320,stroke:#00e676,color:#80ffbb
style DB2 fill:#3d2e00,stroke:#ffab40,color:#ffe080
style DB3 fill:#1a0d3d,stroke:#8855ff,color:#b0a0ff
style PG fill:#1e2a4a,stroke:#448aff,color:#80b0ff
Ein Odoo-Container bedient mehrere Datenbanken (Mandanten) — genau wie SAP.
SAP-Begriffe → Odoo/BACON-AI
| SAP-Begriff | Odoo-Begriff | Unsere Konvention |
|---|---|---|
| Instanz (NN) | Odoo Server-Prozess | Port (z.B. 8901) |
| Mandant/Client (000–999) | Datenbank | z.B. orch-0001-sand |
| SAP-Router | Caddy Reverse Proxy | *.engine.bacon-ai.cloud |
4.2 URL-Routing
flowchart LR
BR["Browser"]
DNS["DNS Wildcard\n*.engine.bacon-ai.cloud\n--> 31.97.216.95"]
CAD["Caddy\nReverse Proxy\n--> localhost:8901"]
ODOO["Odoo dbfilter\nwaehlt Datenbank"]
PG["PostgreSQL\norch-0001-sand"]
BR --> DNS --> CAD --> ODOO --> PG
style BR fill:#141a2e,stroke:#8892a8,color:#e0e6f0
style DNS fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style CAD fill:#0d3320,stroke:#00e676,color:#80ffbb
style ODOO fill:#1e2a4a,stroke:#ffab40,color:#ffe080
style PG fill:#0d1a3d,stroke:#448aff,color:#80b0ff
Vom Browser zur Datenbank: DNS Wildcard → Caddy → Odoo dbfilter → PostgreSQL.
4.3 Datenbank-Namenskonvention
Format: {projekt}-{nummer}-{tier}
| Datenbank | Projekt | Tier | URL |
|---|---|---|---|
| orch-0001-sand | Orchestrator | Sandbox | orch-0001-sand.engine.bacon-ai.cloud |
| rent-0001-sand | Rental | Sandbox | rent-0001-sand.engine.bacon-ai.cloud |
| orch-0001-dev | Orchestrator | Development | orch-0001-dev.engine.bacon-ai.cloud |
| rent-0001-dev | Rental | Development | rent-0001-dev.engine.bacon-ai.cloud |
| rent-0001-qa | Rental | QA/SIT | rent-0001-qa.engine.bacon-ai.cloud |
| rent-0001-stag | Rental | Staging/UAT | rent-0001-stag.engine.bacon-ai.cloud |
4.4 Warum Option B (ein Container pro Tier)?
| Kriterium | Option A: Ein Container pro Projekt | Option B: Ein Container pro Tier |
|---|---|---|
| Container-Anzahl | 10 Tiers x N Projekte = viele | 10 Tiers = maximal 10 |
| RAM-Verbrauch | ~300MB pro Container x N | ~300MB pro Tier = ~3GB gesamt |
| Port-Konflikte | 8902 = Rental-Sandbox oder Orch-Websocket? | Keine — Port = Tier |
| SAP-Bewährt | Nein | Ja — Mandanten-Modell seit 40 Jahren |
| Neue Projekte | Neuer Container + Port + Config | Nur neue Datenbank erstellen |
Entscheidung (08.04.2026): Option B — SAP-Mandanten-Modell.
Ein Container pro Tier, viele Datenbanken (Mandanten) pro Container.
5. Das BACON-AI Test-Framework
5.1 Die vier Test-Stufen
Basierend auf der V-Modell-Methodik: Jede Planungsebene hat eine korrespondierende Teststufe.
| Test | Vollständiger Name | Was wird getestet? | Wann? | Wo? |
|---|---|---|---|---|
| TUT | Technical Unit Test | Einzelne Funktionen und Methoden | Bei jedem Speichern | Dev (Port 8401) |
| FUT | Functional Unit Test | Geschäftslogik liefert korrekte Ergebnisse | Vor PR-Erstellung | Dev (Port 8401) |
| SIT | System Integration Test | Mehrere Komponenten arbeiten zusammen | Nach Feature-Merge | QA (Port 8301) |
| UAT | User Acceptance Test | Ein Mensch bestätigt: Es funktioniert | Vor Produktion | Staging (Port 8201) |
flowchart LR
subgraph planung ["Planung"]
direction TB
A1["Anforderungen\ndefinieren"]
A2["System-Design"]
A3["Detail-Entwurf"]
A4["Implementierung"]
A1 --> A2 --> A3 --> A4
end
subgraph testing ["Testing"]
direction BT
T1["TUT\nTechnischer Test"]
T2["FUT\nFachlicher Test"]
T3["SIT\nIntegrationstest"]
T4["UAT\nBenutzerabnahme"]
T1 --> T2 --> T3 --> T4
end
A1 -.-|"validiert durch"| T4
A2 -.-|"validiert durch"| T3
A3 -.-|"validiert durch"| T2
A4 -.-|"validiert durch"| T1
style A1 fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style A2 fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style A3 fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style A4 fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style T1 fill:#0d3320,stroke:#00e676,color:#80ffbb
style T2 fill:#0d3320,stroke:#00e676,color:#80ffbb
style T3 fill:#0d1a3d,stroke:#448aff,color:#80b0ff
style T4 fill:#3d2e00,stroke:#ffab40,color:#ffe080
style planung fill:#0a0e1a,stroke:#00e5ff,color:#80f0ff
style testing fill:#0a0e1a,stroke:#00e676,color:#80ffbb
Das klassische V-Modell: Jede Planungsebene wird durch eine korrespondierende Teststufe validiert.
5.2 Test-Stufen und Tier-Zuordnung
Jede Teststufe läuft in ihrer eigenen Tier-Umgebung.
flowchart LR
DEV["Tier 4-8\nDevelopment\nTUT --> FUT"]
QA["Tier 3\nQA\nSIT --> Regression"]
STAG["Tier 2\nStaging\nUAT --> Performance"]
PROD["Tier 0\nProduktion\nLIVE System"]
DEV -->|"bestanden"| QA -->|"bestanden"| STAG -->|"bestanden"| PROD
style DEV fill:#0d3320,stroke:#00e676,color:#80ffbb
style QA fill:#0d1a3d,stroke:#448aff,color:#80b0ff
style STAG fill:#3d2e00,stroke:#ffab40,color:#ffe080
style PROD fill:#3d1010,stroke:#ff5252,color:#ff8a8a
Von der Entwicklung bis zur Produktion: Jede Stufe muss bestanden werden.
5.3 Anti-Dodge-Governance: KI-Agenten können nicht schummeln
7 Validatoren prüfen jede Schritt-Abschlussmeldung:
| Nr. | Validator | Prüfung | Blockiert bei… |
|---|---|---|---|
| 1 | Reflexions-Gate | Menschliche Schritte → Genehmigung | Genehmigung fehlt |
| 2 | Evidenz-Prüfung | Nachweise vorhanden | Leere Nachweise |
| 3 | Schema-Prüfung | output_schema validiert | Schema-Verletzung |
| 4 | Nachbedingungen | Pflichtfelder in Ergebnissen | Fehlende Pflichtfelder |
| 5 | Tier-Anforderungen | Control-Point spezifische Anforderungen | Fehlende Artefakte |
| 6 | Policy-Prüfung | Self-Annealing-Regeln (SA-001 bis SA-008) | Policy blockiert |
| 7 | Challenge-Tabelle | Spezifische Evidenz-Keywords pro Schritttyp | TUT ohne test_results |
Ein KI-Agent kann einen TUT-Schritt nicht als abgeschlossen markieren, ohne Test-Evidenz vorzulegen. Die Engine ist deterministischer Python-Code — sie kann nicht überredet oder ausgetrickst werden.
6. Alles zusammen: Die komplette Umgebungslandschaft
6.1 Workshop-Umgebungen (Stand: April 2026)
Alle Umgebungen auf dem Hostinger-Server (srv906866.hstgr.cloud):
| Tier | Port | Rental-Projekt | Orchestrator-Projekt |
|---|---|---|---|
| Sandbox | 8901 | rent-0001-sand.engine.bacon-ai.cloud | orch-0001-sand.engine.bacon-ai.cloud |
| Dev A | 8401 | rent-0001-dev.engine.bacon-ai.cloud | orch-0001-dev.engine.bacon-ai.cloud |
| QA/SIT | 8301 | rent-0001-qa.engine.bacon-ai.cloud | orch-0001-qa.engine.bacon-ai.cloud |
| Staging | 8201 | rent-0001-stag.engine.bacon-ai.cloud | orch-0001-stag.engine.bacon-ai.cloud |
Zugangsdaten: admin / admin (alle Umgebungen).
flowchart TB
INET["Internet\n*.engine.bacon-ai.cloud"]
HOST["Hostinger Cloud Server"]
CADDY["Caddy Reverse Proxy\n+ Auto-TLS"]
subgraph docker ["Docker Compose"]
direction TB
SAND["odoo-sandbox\nPort 8901"]
ODEV["odoo-dev\nPort 8401"]
OQA["odoo-qa\nPort 8301"]
OSTAG["odoo-staging\nPort 8201"]
OLEG["odoo-legacy\nPort 8069"]
end
PG["PostgreSQL 16"]
INET --> HOST --> CADDY
CADDY --> SAND
CADDY --> ODEV
CADDY --> OQA
CADDY --> OSTAG
CADDY --> OLEG
SAND --> PG
ODEV --> PG
OQA --> PG
OSTAG --> PG
OLEG --> PG
style INET fill:#141a2e,stroke:#8892a8,color:#e0e6f0
style HOST fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0
style CADDY fill:#0d3320,stroke:#00e676,color:#80ffbb
style SAND fill:#1a2e1a,stroke:#00e676,color:#80ffbb
style ODEV fill:#0d3320,stroke:#00e676,color:#80ffbb
style OQA fill:#0d1a3d,stroke:#448aff,color:#80b0ff
style OSTAG fill:#3d2e00,stroke:#ffab40,color:#ffe080
style OLEG fill:#3d1010,stroke:#ff5252,color:#ff8a8a
style PG fill:#1e2a4a,stroke:#448aff,color:#80b0ff
style docker fill:#0a0e1a,stroke:#2a3358,color:#8892a8
Infrastruktur-Übersicht: Vom Internet über Caddy bis zu den Docker-Containern und PostgreSQL.
7. Kapazität und Skalierung
| Dimension | Kapazität | Bei 100K Flows |
|---|---|---|
| Projekte pro Tier | Unbegrenzt (PostgreSQL-Limit) | ~50 Projekte |
| Container pro Server | ~10 (einer pro Tier, ~300MB je) | ~3GB RAM gesamt |
| Datenbanken pro Container | Unbegrenzt | Hunderte |
| URLs pro Tier | Eine pro Projekt (Wildcard-DNS) | Automatisch |
| Port-Nummern | 99 Projekte x 10 Tiers = 990 | 0,5% genutzt |
8. Zusammenfassung: Die drei Säulen
mindmap
root("BACON-AI\nTier-Strategie")
Port-Konvention
SAP-inspiriert
Typ = Dienst-Art
Projekt = Anwendung
Tier = Umgebung
Multi-Tenant
SAP-Mandanten-Modell
Ein Container pro Tier
Viele Datenbanken
URL-basiertes Routing
Test-Framework
TUT = Technisch
FUT = Fachlich
SIT = Integration
UAT = Benutzer
Anti-Dodge Governance
Die drei Säulen der BACON-AI Tier-Strategie: Port-Konvention, Multi-Tenant und Test-Framework.
Port-Konvention
- SAP-inspiriert
- Typ = Dienst-Art
- Projekt = Anwendung
- Tier = Umgebung
Multi-Tenant
- SAP-Mandanten-Modell
- Ein Container pro Tier
- Viele Datenbanken
- URL-basiertes Routing
Test-Framework
- TUT = Technisch
- FUT = Fachlich
- SIT = Integration
- UAT = Benutzer
- Anti-Dodge Governance
Kernprinzipien
- Produktion ist heilig — keine direkten Änderungen, nur getestete Transporte.
- Jede Umgebung hat eine feste Identität — Port-Nummer ändert sich nie.
- Eine Nummer sagt alles — Port 8301 = Odoo / QA / Orchestrator, immer.
- Die Pipeline wird von der Infrastruktur erzwungen — nicht von der Disziplin der Entwickler.
- KI-Agenten können nicht schummeln — deterministische Validatoren in der Engine.
- Das Mandanten-Modell skaliert — bewährt bei SAP über 40 Jahre weltweit.
Quelle: Dieses Dokument wurde im Rahmen des BACON-AI Workshops erstellt.
Stand: April 2026 • Projekt: ORCH-0001 • Framework: BACON-AI v2
6. Anwendungsbeispiel: TAXD (Tax Document Registry)
Erste vollständige Implementierung der Port-Konvention v2.0 als Referenz-Architektur. TAXD (Projekt 15) verwaltet Steuerdokumente für Colin Bacon (DE ESt 2023/2024, UK SA) in einer strukturierten Datenbank mit graphähnlicher Dokumenten-Relationstabelle und Google-Sites-Frontend.
6.1 Port-Zuordnung (Konvention v2.0)
| Port | Formel | Dienst | Status |
|---|---|---|---|
| 4159 | API(4) + TAXD(15) + Sandbox(9) | Flask REST API — 127.0.0.1:4159, Hostinger | ✅ Aktiv |
| 4154 | API(4) + TAXD(15) + Dev(4) | API, Dev-Tier | Geplant |
| 4150 | API(4) + TAXD(15) + Prod(0) | API, Produktions-Tier (alle Gates) | Geplant |
| 5159 | Web(5) + TAXD(15) + Sandbox(9) | Web-Dashboard / Google Sites | Geplant |
6.2 Systemarchitektur
flowchart TB
GS["Google Sites
Frontend + Auth
Seiten-spezifischer Zugang"]
AS["Apps Script
Middleware
Daten-Abruf"]
API["Flask API Port 4159
127.0.0.1 only"]
DB[("PostgreSQL
bacon_tax DB
Hostinger")]
ODOO["Odoo 19 Port 8069
res.partner, Kontakte"]
DRIVE["Google Drive
Dokumenten-PDFs"]
GS --> AS --> API --> DB
DB -.->|"gleicher PG-Server"| ODOO
GS --> DRIVE
style GS fill:#0d2040,stroke:#448aff,color:#80b0ff
style API fill:#0d3320,stroke:#00e676,color:#80ffbb
style DB fill:#1a0d3d,stroke:#7c4dff,color:#b39ddb
style ODOO fill:#3d2200,stroke:#ff8a40,color:#ffc080
6.3 Datenmodell — 5 Tabellen
erDiagram
BACON_TAX_DOCUMENT {
text doc_id PK
text name
text status
bool needed_for_boehm
}
BACON_DOC_YEAR {
text doc_id FK
text tax_year
text section
}
BACON_DOC_RELATION {
text doc_from FK
text doc_to FK
text relation
}
BACON_TAX_DOCUMENT ||--o{ BACON_DOC_YEAR : "Jahr+Abschnitt"
BACON_TAX_DOCUMENT ||--o{ BACON_DOC_RELATION : "Graph-Relation"
6.4 Dokumenten-Graph (rekursives CTE)
flowchart LR
A001["A001 Kaufvertrag"]
A002["A002 Grundschuld"]
A003["A003 Notarkosten"]
A004["A004 Zinsbescheinigung 2023"]
A005["A005 Zinsbescheinigung 2024"]
A001 -->|same_event| A002
A001 -->|same_event| A003
A001 -->|required_by| A004
A001 -->|required_by| A005
A002 -->|required_by| A004
style A001 fill:#0d2040,stroke:#448aff,color:#80b0ff
style A004 fill:#3d2e00,stroke:#ffab40,color:#ffe080
6.5 Sicherheitsmodell
| Schicht | Mechanismus | Zugang |
|---|---|---|
PostgreSQL bacon_tax | Lokaler Socket, kein externer Port | Nur localhost |
| Flask API Port 4159 | host=127.0.0.1 — niemals 0.0.0.0 | Tailscale via Caddy |
| Google Sites | Seiten-spezifische Google-Berechtigungen | Böhm sieht nur seine Sektion |
| Odoo Port 8069 | PoC — separat, kein gemeinsamer Code | Zu härten (nächste Phase) |
📄 Wissensdatenbank: docs/DE-TAX-KNOWLEDGE-BASE.md —
Registry: docs/DE-TAX-DOCUMENT-REGISTRY.json