Lokal entwickeln

Bu içerik henüz dilinizde mevcut değil.

Wer am Stack mitbaut, arbeitet im Monorepo: Pakete unter packages/, Apps unter apps/, Beispiele unter examples/, die Spec unter docs/spec/. Alles läuft lokal mit Node und pnpm; ein Server, ein Konto oder Android-Werkzeuge sind für den Web-Einstieg nicht nötig.

Voraussetzungen

Node 22 oder neuer und pnpm in der Version, die package.json festlegt; Corepack holt sie.

git clone https://github.com/real-life-org/real-life-stack.git
cd real-life-stack
corepack enable
pnpm install --frozen-lockfile

Vier Dev-Server

Was	Befehl	Adresse	Wofür
Referenz-App	`pnpm dev:reference`	im Terminal	die App mit allen Modulen; über `?connector=mock` oder `local`
Netzwerk-App	`pnpm dev:network`	im Terminal	eine App mit eigenem Modul (Marktplatz) auf dem Rahmen
Storybook	`pnpm storybook`	http://localhost:6006/	jedes Modul, die App-Komposition, alle Hooks — der Ort für Toolkit-Arbeit
Site	`pnpm dev:site`	http://localhost:4321/	Landing und dieses Handbuch

Die Dev-Server lesen die Pakete aus dem Quelltext (development-Condition in den package.json); ein Build vorher ist nicht nötig, jede Änderung im Toolkit erscheint sofort in App und Storybook. Die Ausnahme ist das Handbuch-Beispiel: pnpm dev:first-app nimmt die veröffentlichten Pakete von npm, so wie eine App außerhalb des Repos (Eine eigene App bauen); eine Toolkit-Änderung erreicht es erst mit dem nächsten Release.

Im Storybook beginnst du bei RLS → Start → Read me first: der Lesepfad durch Start, App, App shell, Spaces, Modules, Items, Foundations. Alle Texte dort sind Englisch, die Beispieldaten Deutsch.

Die erste Änderung

Öffne packages/toolkit/src/handbook/garden-data.ts und ändere den Titel des Erntefests. Storybook zeigt die Änderung in RLS → App → 00 Community garden, in der Site auf der Seite Eine eigene App bauen. Diese Daten sind fiktiv und Teil der Dokumentation.

Für eine Änderung am Verhalten gilt die Reihenfolge aus AGENTS.md: erst die Spec-Stelle lesen (docs/spec/), dann Code, Story und Test im selben Schritt ändern. Wiederverwendbare Oberfläche gehört ins Toolkit, nie in eine App; ein Modul lädt nichts selbst, was der Host aus seinem Registereintrag herstellt (Spec 01). Die Regeln im Einzelnen stehen in docs/agent-workspace.md; sie gelten für Menschen und Agenten gleich.

Prüfen

Was CI prüft, läuft auch lokal. Vor einem Pull Request mindestens:

pnpm test              # alle Pakete und Apps mit Tests; CI fährt sie in zwei Zeitzonen
pnpm -r typecheck      # jedes Paket, jede App, das Beispiel
git diff --check

Je nach Bereich dazu: pnpm build:storybook (Toolkit, Stories), pnpm build:site && pnpm check:site && pnpm test:site (Handbuch), pnpm check:hooks (ein Hook wurde exportiert oder geändert), pnpm check:agents (Pakete, Spec-Index, Beispiel), python3 scripts/check-normative-words.py (Spec-Text), python3 scripts/check-shared-derivations.py (ein Modul). Die vollständige Liste mit dem, was jede Prüfung fängt, steht unter Mit Agenten arbeiten → Die Prüfungen.

Welcher Beitrag gehört wohin?

Ziel	Ort
Eine eigene Community-App	ein eigenes Repo auf den veröffentlichten Paketen, Eine eigene App bauen
Eine Fläche, die alle Apps brauchen	`packages/toolkit`, mit Story; Karten aus `ItemPreview`, Dialoge aus der gemeinsamen Familie
Ein neues Modul	eine Datei in `packages/toolkit/src/modules/`, ein Registereintrag, eine Story mit `HostWorld`
Eine Datenquelle	ein Connector gegen `@real-life/data-interface`; Connectoren importieren nicht voneinander
Verbindliches Verhalten	Spec, Code, Test und Story im selben PR; bei Widerspruch gewinnt die Spec
Ein Hook	mit Dokumentationsblock (`@answers`, `@without`, `@group`), dann `pnpm docs:hooks`

Bevor du etwas am Verhalten änderst, lohnen die vier Konzeptseiten, beginnend mit Vom Space zum Item: Sie erklären, warum die Regeln in der Tabelle so sind. Weiter: Zusammen am Stack arbeiten.