Kairo-Jinkendo/README.md

# Jinkendo Kairo

Operativer Program Director der Jinkendo-Produktfamilie.

Kairo steuert Vorhaben, Programme, Projekte, Meilensteine, Maßnahmen, Backlogs, Reviews, Nachweise und die Zusammenarbeit von Menschen, Arbeitsgruppen und KI-Agenten.

## Leitfrage

> Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?

## Startzustand

Dieses Repository startet mit einem reinen Spezifikations- und Sprint-0-Handover-Paket.

Noch nicht enthalten:

- produktiver Anwendungscode
- endgültiger Technologie-Stack
- vollständige Jinkendo-Foundation
- Mitai- oder Shinkan-Code
- Billing / SSO / zentrale Produktfamilien-Konvergenz

## Verbindliche Dokumente für Sprint 0

1. `docs/product/Jinkendo_Kairo_Product_Spec_v0.2.md`
2. `docs/architecture/Jinkendo_Foundation_Minimum_Viable_Foundation_v0.2.md`
3. `docs/architecture/Kairo_Sprint0_Principle_Gate_v0.1.md`
4. `docs/sprints/Jinkendo_Kairo_04_Sprint0_Foundation_v0.3.md`
5. `docs/sprints/Sprint0_Vibe_Coder_Handover_v0.1.md`
6. `docs/sprints/Sprint0_AP0_1_Project_Setup_Assignment_v0.1.md`
7. `CLAUDE.md`
8. `.cursor/rules/kairo-architecture.mdc`

## Arbeitsmodus

Kairo wird iterativ entwickelt.

Sprint 0 baut nur das Fundament:

- Tenant
- User
- Actor
- TenantContext
- Auth-Gates
- Capability/Rights Registry
- minimale Feature Registry
- minimale Prompt Registry
- Platzhaltermodell
- Audit
- Migration/Deploy-Grundlage

Vorhaben, Projekte, Meilensteine und Maßnahmen kommen erst nach Sprint 0.


## Designprinzipien-Referenzen

Die extrahierten Designprinzipien aus Mitai und Shinkan liegen im Repository unter:

```text
docs/reference/design-principles/
```

Diese Dokumente sind Referenzen, kein direkter Sprint-Scope.

Verbindlich ist nur, was über das Kairo Sprint-0 Principle Gate oder eine Architecture Decision übernommen wurde.

## Deployment & CI

Zwei getrennte Gitea-Workflows (wie Shinkan):

| Workflow | Branch |
|----------|--------|
| **Deploy Development** | `develop` |
| **Deploy Production** | `main` |
| **Test Suite** | nach Deploy + bei Push/PR `develop` |

Details: [docs/DEPLOYMENT.md](docs/DEPLOYMENT.md)

## Local Development

Voraussetzungen: Docker + Docker Compose.

```bash
git clone http://192.168.2.144:3000/Lars/Kairo-Jinkendo.git
cd Kairo-Jinkendo
git checkout develop

# Dev-Stack (PostgreSQL + Backend + Frontend)
docker compose -f docker-compose.dev-env.yml up --build

# Health prüfen
curl http://localhost:8097/api/health
curl http://localhost:3097/api/health

# Tests im Backend-Container
docker compose -f docker-compose.dev-env.yml exec backend pip install -r requirements-dev.txt
docker compose -f docker-compose.dev-env.yml exec backend python -m pytest tests -ra -vv
```

UI: http://localhost:3097 · API: http://localhost:8097

Interaktive API-Doku (Dev): http://localhost:8097/api/docs

### Auth (AP0.2)

**Ersteinrichtung Dev** (automatisch per Seed nach jedem Backend-Start):

| Feld | Wert |
|------|------|
| E-Mail | `lars@stommer.com` |
| Passwort | `12345678` |

Alternativ: UI-Registrierung (nur wenn DB leer und Dev-Seed deaktiviert) oder Bootstrap per `.env`:

```env
KAIRO_BOOTSTRAP_ADMIN_EMAIL=admin@kairo.local
KAIRO_BOOTSTRAP_ADMIN_PASSWORD=…
KAIRO_BOOTSTRAP_TENANT_SLUG=default
```

Migrationen & idempotente Data-Seeds: [docs/MIGRATIONS.md](docs/MIGRATIONS.md)

| Endpoint | Methode | Auth | Beschreibung |
|----------|---------|------|--------------|
| `/api/auth/setup-status` | GET | — | Ob Erstregistrierung offen ist |
| `/api/auth/register` | POST | — | Erster User → Portal-Admin + Tenant (nur wenn noch kein User) |
| `/api/auth/login` | POST | — | E-Mail + Passwort → Session-Token |
| `/api/auth/logout` | POST | `X-Auth-Token` | Session löschen |
| `/api/me` | GET | `X-Auth-Token` | Aktueller User + Tenant-Liste |
| `/api/me/context` | GET | `X-Auth-Token` | TenantContext (Tenant + Human Actor + Capabilities) |
| `/api/me/entitlements` | GET | `X-Auth-Token` | Entitlements-Snapshot (Rollen, Capabilities, Features-Platzhalter) |
| `/api/me/admin/demo` | GET | `X-Auth-Token` + `kairo.admin.access` | Beispiel-Endpoint mit `require_capability` |
| `/api/me/tenant` | POST | `X-Auth-Token` | Aktiven Tenant wechseln (nur Memberships) |

### Registries (AP0.4)

Feature-, Prompt-, Placeholder- und Config-Registry analog zur Rights Registry: Code-Registrierung → Startup-Sync → DB.

| Endpoint | Methode | Capability | Beschreibung |
|----------|---------|------------|--------------|
| `/api/features` | GET | `kairo.feature.registry.read` | Feature-Katalog |
| `/api/prompts` | GET | `kairo.prompt.registry.read` | Prompt-Definitionen |
| `/api/prompts/{key}` | GET | `kairo.prompt.registry.read` | Definition + aktive Version |
| `/api/prompts/{key}/render` | POST | `kairo.prompt.render` | Single-Mode Rendering (ohne LLM) |
| `/api/config` | GET | `kairo.config.registry.read` | Konfiguration (global/tenant) |
| `/api/config` | POST | `kairo.config.registry.manage` | Konfiguration setzen |

Startup: `sync_prompt_feature_config.py` nach Rights-Sync (`SKIP_REGISTRY_SYNC=1` zum Überspringen).

**Prompt-Modell:** `PromptDefinition` → `PromptVersion` → optional `PromptStep` (workflow-/pipeline-fähig; AP0.4 führt nur `execution_mode=single` aus).

**Beispiel-Prompts:** `kairo.system.health_summary`, `kairo.context.debug_summary`

**Features im Entitlements-Snapshot:** `kairo.prompt.registry`, `kairo.config.registry`, `kairo.feature.registry`

| Capability | Modul | Kurzbeschreibung |
|------------|-------|------------------|
| `kairo.feature.registry.read` | feature | Feature-Katalog lesen |
| `kairo.feature.registry.manage` | feature | Feature-Metadaten verwalten |
| `kairo.prompt.registry.read` | prompt | Prompt Registry lesen |
| `kairo.prompt.registry.manage` | prompt | Prompt Registry verwalten |
| `kairo.config.registry.read` | config | Config lesen |
| `kairo.config.registry.manage` | config | Config schreiben |
| `kairo.prompt.render` | prompt | Prompt rendern (Test/Preview) |

Zusätzlich AP0.3-Capabilities (siehe oben).

Enforcement: `CAPABILITY_ENFORCE=probe` (Default) oder `enforce`.

```bash
curl -s http://localhost:8097/api/me/entitlements -H "X-Auth-Token: TOKEN"
curl -s -X POST http://localhost:8097/api/prompts/kairo.system.health_summary/render \
  -H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
  -d '{"values":{"debug_message":"OK","debug_level":"info"},"use_context":false}'
```

### Capabilities (AP0.3)

Registry-first: Capabilities werden in `backend/rights_registrations/` registriert und beim Start via `sync_rights_registry.py` in die DB synchronisiert.

| Capability | Modul | Kurzbeschreibung |
|------------|-------|------------------|
| `kairo.admin.access` | platform | Portal-Administration |
| `kairo.tenant.manage` | tenant | Tenant-Verwaltung |
| `kairo.actor.manage` | tenant | Actor-Verwaltung |
| `kairo.context.read` | platform | TenantContext lesen |
| `kairo.entitlements.read` | platform | Entitlements lesen |

Enforcement: `CAPABILITY_ENFORCE=probe` (Default, loggt Verweigerungen) oder `enforce` (HTTP 403).

```bash
curl -s http://localhost:8097/api/me/entitlements -H "X-Auth-Token: TOKEN"
```

```bash
# Login
curl -s -X POST http://localhost:8097/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@kairo.local","password":"…"}'

# Geschützter Endpoint
curl -s http://localhost:8097/api/me -H "X-Auth-Token: TOKEN"
```

Regeln: `user_id` kommt aus der Session, nicht aus Client-Headern. Portalrolle (`portal_role`) und Tenantrolle (`tenant_role`) sind getrennt.

## AP0.1 – Stand Projektgrundlage

| Bereich | Status |
|---------|--------|
| Git + Gitea (`develop` / `main`) | erledigt |
| Docker Compose (Prod + Dev) | erledigt |
| Backend (FastAPI, Migrationen, `/api/health`) | erledigt |
| Frontend minimal (React + nginx Proxy) | erledigt |
| pytest (Health + Migrationen + Auth/Tenant/Actor) | erledigt (AP0.2) |
| Gitea Actions (Deploy + Test) | erledigt |