---
description: Sibling-Repos dashback/dashfront — nur lesen, keine Cross-Edits; Docs & Git-Logs
alwaysApply: true
---

# Sibling-Repos (dashdbschema / libdashstore)

Dieses Repo ist **dashdbschema** (MSSQL-Schema + Store-API / `libdashstore`). Geschwister: `../dashback` (HTTP-API), `../dashfront` (UI). Jedes Repo hat ein eigenes Agent/Human-Paar. **Cross-Interference nur durch den Human** — du änderst keine Dateien außerhalb dieses Repos.

## Erlaubt (read-only)

- Git-Logs der Geschwister lesen, wenn HTTP-API oder UI-Bedarf unklar ist:
  - `git -C ../dashback log --oneline -20`
  - `git -C ../dashfront log --oneline -20`
- Doku und Code der Geschwister **lesen** (Kontext, nicht patchen)

## Verboten

- Dateien in `../dashback` oder `../dashfront` schreiben, committen, installieren, Server starten/stoppen
- HTTP-Routen oder Frontend-Code „mitliefern“ — der Human koordiniert
- Migrations-/Upgrade-Pfade (siehe `no-schema-migrations`)
- **Keine Fallbacks** — fehlende/unklare API nicht erraten, nicht mit Defaults oder „irgendwie passenden“ Signaturen kaschieren

## Unklar oder fehlt → absprechen

Wenn ein Vertrag unklar oder fehlt: **nicht weiterwursteln**. Human fragen, Vorschläge machen, Lücken benennen. Absprache läuft über den Human zu den anderen Agents. **Lieber zu oft gefragt als zu wenig.**

## Docs — wo was steht

| Repo | Pfad | Inhalt |
|------|------|--------|
| **dieses** | `README.md` | Store-Methoden, Signaturen, Returns — Vertrag für dashback |
| **dieses** | `src/schema.js`, `src/store/` | Schema + Implementierung |
| dashback | `../dashback/docs/api/README.md` | HTTP-Routen-Index |
| dashback | `../dashback/docs/api/routes/` | eine Markdown-Datei pro Endpoint |
| dashback | `../dashback/docs/api/openapi.json` | maschinenlesbare Spec |
| dashfront | `../dashfront/README.md`, `../dashfront/src/api/index.js` | UI-Client; spricht nur HTTP, nicht direkt Store |

## Was der Human / dashback von dir erwarten

1. **README.md aktuell halten**, wenn Store-Methoden oder Returns sich ändern — dashback baut Services darauf.
2. Schema-Änderungen so, dass `npm run reset-db` den Zielzustand abbildet; Live-DB nur manuell per `sqlcmd` (Human).
3. Bei API-Bedarf aus dem Frontend: dashback-Docs/Logs lesen; fehlende HTTP-Schicht dem Human melden, nicht in dashback implementieren.