PowerOn PORTA -- Dokumentation

Produkt

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

Komponente	Repository (Forgejo: git.poweron.swiss/PowerOn)	Technologie	Beschreibung
Frontend Nyla	`ui-nyla`	React/TypeScript, Vite	Zentrales UI für alle Features
Platform Core	`platform-core`	FastAPI, Python, PostgreSQL	Backend REST-API, Services, AI-Core
Private LLM	`service-llm-private`	Python	Internes LLM für Neutralisierung + sensitive Daten
Preprocessing	`service-preprocessing`	Python	Datenvorverarbeitung Power BI → SQLite, SQL-Query-Service
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; ISO 9001/27001 IMS unter `e-compliance/ims/` (Handbuch, Politiken, SoA, Prozesse, Cockpit)	Regulatorische Fragen, Zertifizierung
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.

Nach jedem Change: 1 Zeile in c-work/_CHANGELOG.md (Format dort beschrieben).

b-reference/ Aufbau

b-reference/
├── product.md              Komponentenübersicht, Repo-Map, Tech-Stack
├── platform-core/          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
│   ├── voice-google.md        Google STT/TTS (VoiceObjects, Streaming-WS, Feature-Mapping)
│   └── features/              trustee.md, commcoach.md, ...
├── ui-nyla/                Frontend-Komponente
│   └── architecture.md        Seiten, Komponenten, Hooks, Routing
├── service-llm-private/    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: platform-core@<sha>, ui-nyla@<sha> -->

4.3 KiB Raw Blame History