No description
Find a file
2026-04-21 08:25:06 +02:00
a-strategy DOcu updated 2026-04-06 00:46:32 +02:00
b-reference google configs 2026-04-21 00:50:21 +02:00
c-work google configs 2026-04-21 00:50:21 +02:00
d-guides added forgejo admin 2026-04-21 08:25:06 +02:00
e-compliance feat db-clean-ui and unified content udm 2026-04-16 23:12:56 +02:00
f-decisions integrated and initial teste unified automation 2026-04-07 22:31:57 +02:00
z-archive feat db-clean-ui and unified content udm 2026-04-16 23:12:56 +02:00
README.md cleanup 2026-04-06 09:59:56 +02:00
TOPICS.md fixed proper splitting sysadmin/platformadmin and proper logic for mandate name(slug) and label(user) 2026-04-19 00:03:58 +02:00

PowerOn PORTA -- Dokumentation

Produkt

PowerOn PORTA ist eine Multi-Tenant SaaS-Plattform mit Feature-Store-Modell, AI-Agent-Workspace und mandantenweiter Datenneutralisierung.

Komponente Repository Technologie Beschreibung
Frontend Nyla frontend_nyla React/TypeScript, Vite Zentrales UI für alle Features
Gateway gateway FastAPI, Python, PostgreSQL Backend REST-API, Services, AI-Core
Private LLM private-llm Python Internes LLM für Neutralisierung + sensitive Daten
Teams Bot service-teams-browser-bot TypeScript/Node.js Bot für Teams-Meeting-Teilnahme
Wiki wiki Markdown Dokumentation (dieses Repo)

Ordnerstruktur

Ordner Zweck Wann nutzen
a-strategy/ Produkt-Vision, Strategie, Roadmap, Markt, Investor Richtung setzen, Business-Kontext
b-reference/ Wie das System funktioniert (code-verifiziert) System verstehen, Architektur-Fragen
c-work/ Laufende Arbeit -- Kanban (plan → build → validate → done) Feature planen, bauen, testen
d-guides/ How-to: Dev-Setup, Deployment, Testing, Coding-Regeln Etwas tun, Prozess nachschlagen
e-compliance/ Sicherheit, Datenschutz, Audit-Dokumente Regulatorische Fragen
f-decisions/ Entscheidungen (ADR-light): Kontext, Entscheidung, Konsequenz Warum wurde X so entschieden?
z-archive/ Veraltete Docs mit Forward-Link zum Nachfolger Historischer Kontext

Lebenszyklus: Feature oder Refactor

1. Neues Arbeits-Dokument in c-work/1-plan/ anlegen (Vorlage: c-work/_TEMPLATE.md)
2. Bei Umsetzungsbeginn → nach c-work/2-build/ verschieben
3. Bei Test-Phase → nach c-work/3-validate/
4. Wenn merged/released → nach c-work/4-done/
5. Einmalig: betroffene b-reference/ Seite aktualisieren, TOPICS.md prüfen
6. Arbeits-Dokument → z-archive/ verschieben

Kernregel: Während Planung, Umsetzung und Testing pflegst du nur das eine Arbeits-Dokument in c-work/. Kanon-Seiten in b-reference/ und TOPICS.md werden erst am Ende aktualisiert.


b-reference/ Aufbau

b-reference/
├── product.md              Komponentenübersicht, Repo-Map, Tech-Stack
├── gateway/                Backend-Komponente
│   ├── architecture.md        Module, Services, Interfaces
│   ├── ai-agent.md            Agent Core, Tools, Knowledge/RAG
│   ├── workflow.md            Workflow-Engine, Methoden, Aktionen
│   ├── automation.md          Automation v1 + v2
│   ├── billing.md             Billing, Subscriptions
│   └── features/              trustee.md, commcoach.md, chatbot.md, ...
├── frontend-nyla/          Frontend-Komponente
│   └── architecture.md        Seiten, Komponenten, Hooks, Routing
├── private-llm/            Internes LLM
│   └── architecture.md        Setup, Modelle, Gateway-Integration
├── teams-bot/              Teams Meeting Bot
│   └── architecture.md        Service, WebSocket, Architektur
└── platform/               Cross-Cutting (repo-übergreifend)
    ├── neutralization.md      Gateway + Private-LLM Zusammenspiel
    ├── rbac.md                Rollensystem (Gateway + Frontend)
    └── navigation.md          Navigation API (Gateway → Frontend)

Cursor Doc-Sync: Installationshinweise und Verhalten der Regel → d-guides/cursor-doc-sync.md


Für AI-Assistenten

Immer zuerst laden: TOPICS.md -- dort steht, welche Datei für welches Thema massgeblich ist.


Status-Block (Kopf jeder Kanon-Seite)

<!-- status: canonical | draft | superseded -->
<!-- lastReviewed: YYYY-MM-DD -->
<!-- verifiedAgainst: gateway@<sha>, frontend_nyla@<sha> -->