Bauen, testen und beitragen
Ein praktischer Weg von einem Quellcode-Checkout zu einer gezielten Änderung, samt den Prüfungen, die belegen, dass jede Grenze weiterhin funktioniert.
Gegen den Quellcode geprüft am 17. September 2026
Auf dieser Seite
Mit einer fokussierten Entwicklungsoberfläche beginnen
Verwenden Sie einen Quell-Checkout mit seinen Lockfiles und lesen Sie AGENTS.md für den aktuellen Repository-Vertrag. Der Paketmanager im Stammverzeichnis ist pnpm 10.34.5, und die package.json im Stammverzeichnis pinnt verwundbare transitive Versionen über pnpm-Overrides und gepatchte Abhängigkeiten, weshalb --frozen-lockfile nach einer Abhängigkeitsänderung scheitert, bis das Lockfile neu erzeugt ist. Installieren Sie eine kompatible Node-Laufzeit, stabiles Rust für native Arbeit und die nativen Compiler-Werkzeuge der Zielplattform. iOS-Arbeit erfordert macOS und Xcode. Es gibt keinen Stammbefehl, der alle Komponenten zusammen startet; starten Sie nur die Oberflächen, die Ihre Änderung braucht.
pnpm install --frozen-lockfile| Aufgabe | Startbefehl oder Projekt | Was es nachweist |
|---|---|---|
| Website | pnpm dev:website | Dokumentations- und Marketing-UI in einem Browser. |
| Desktop-Frontend | pnpm -C desktop dev | React-Layout und Frontend-Verhalten; native Aufrufe erfordern eine Tauri-Laufzeitumgebung. |
| Nativer Desktop | pnpm -C desktop tauri:dev | Die eigentliche WebView, Rust-Befehle, Sidecar und lokale Dateien. |
| Server | pnpm dev:server nach lokalem Setup | Konfiguriertes HTTP- und Relay-Dienstverhalten. |
| iOS | mobile/ios/PlanToCode.xcodeproj, PlanToCode-Scheme | Native Companion-UI und, mit einem konfigurierten Desktop, Fernsteuerung. |
| Android | mobile/android in Android Studio | Die Compose-Begleit-App und, mit einem konfigurierten Desktop, Fernsteuerung. |
Die nativen Begleit-Apps bauen
- iPhone: Öffnen Sie mobile/ios/PlanToCode.xcodeproj, wählen Sie das Schema PlanToCode, lösen Sie die lokalen Pakete Core, VibeUI und VibeUIFormatting auf und konfigurieren Sie die Auth0-Werte aus mobile/ios/README.md. Starten Sie auf einem iOS-18-Simulator oder einem Gerät mit Ihrem Signing-Team.
- Android: Öffnen Sie mobile/android in Android Studio, lassen Sie Gradle synchronisieren und konfigurieren Sie die Auth0- und Firebase-Werte aus mobile/android/README.md. Die App zielt auf Android 8.0 und neuer.
- Für einen Live-Steuerungstest auf einer der Plattformen verbinden Sie sich mit einem konfigurierten Desktop mit demselben Konto und derselben Region und lesen eine bekannte Datei, bevor Sie eine Mutation versuchen.
xcodebuild -showdestinations \
-project mobile/ios/PlanToCode.xcodeproj \
-scheme PlanToCodeSimulatoren und Emulatoren decken Layout, Dekodierung und Zustandsübergänge ab. Sie beweisen nichts über physische Push-Zustellung, Store-Käufe oder die Anbieteranmeldung eines signierten Releases, testen Sie das also mit echten Diensten und einem echten Gerät, bevor Sie ein Release für fertig erklären.
Einer Operation durch den Code folgen
rg -n "codexChatOutboxSubmit" rpc-contract.v1.json desktop/src-tauri/src/remote_api server/src mobile/ios
rg -n "submit_outbox_request" desktop/src-tauri/src/commands
rg -n "save_workspace_chat_outbox_with_operation_identity" desktop/src-tauri/src- Beschreiben Sie die Benutzeraktion, das erwartete Ergebnis und einen Fehlerfall vor der Bearbeitung.
- Finden Sie das Transport-DTO und den Domain-Service, der für die Operation zuständig ist. Lesen Sie beides; ein Adapter allein definiert kein Verhalten.
- Ändern Sie die kleinste zuständige Schicht. Bewahren Sie stabile Identitäten für Operationen, Sessions und Timelines.
- Ändern Sie einen gemeinsamen RPC, aktualisieren Sie Manifest, Desktop, Server, iOS und Android zusammen. Das Manifest pinnt, was sie teilen: Seitengrößen 12 und 100, Timeouts von 15, 60, 115, 60 und 20 Sekunden, die Wiederholungsrichtlinie der ersten Timeline und die Mutationen, die einen Idempotenzschlüssel verlangen.
- Fügen Sie einen gezielten Regressionstest an der Fehlergrenze hinzu. Untersuchen Sie bei visuellem oder Lebenszyklus-Verhalten auch die laufende Oberfläche.
- Aktualisieren Sie das relevante technische Kapitel und seine Quellcode-Referenzen zusammen mit der Codeänderung.
Wählen Sie Prüfungen aus, die zur Änderung passen
| Geänderte Oberfläche | Repository-Befehle |
|---|---|
| Desktop TypeScript | pnpm -C desktop typecheck; pnpm -C desktop lint; pnpm -C desktop test |
| Desktop Rust | pnpm desktop:check, danach gezielte Rust-Tests für den geänderten Service. |
| Server Rust | pnpm server:check, danach gezielte cargo-Tests und konfigurierte Service-Tests nach Bedarf. |
| Shared RPC | pnpm check:rpc-contract, plus die betroffenen Client- und Server-Tests. |
| Codex storage boundary | pnpm check:codex-storage-boundary |
| Website | pnpm -C website typecheck; pnpm -C website lint; pnpm -C website test; pnpm -C website build |
| Grenzübergreifendes Review | pnpm check:quality-boundaries kettet neun Prüfungen, darunter die Tauri-Befehlsoberfläche und einen ast-grep-Duplikatscan geänderter Rust-, Kotlin-, Swift- und Python-Dateien mit mindestens 18 Zeilen; pnpm check:all führt die breitere Suite aus. |
Eine Typprüfung beweist Typkonsistenz, nicht Zustellkorrektheit, und ein Relay-Unit-Test beweist keine native Anmeldung. Nennen Sie, welche Prüfungen gelaufen sind, welche externe Dienste brauchen und was Sie im laufenden Produkt geprüft haben.
Machen Sie die Änderung leicht überprüfbar
Behalten Sie einen kanonischen Laufzeitpfad. Entfernen Sie veraltete Zweige, statt stilles Kompatibilitätsverhalten hinzuzufügen. Halten Sie Komponenten modular, verwenden Sie die bereits vorhandenen Abhängigkeiten und bewahren Sie unverwandte Arbeit in einem geänderten Checkout. Das Repository begrenzt Dateien auf 550 Zeilen und Funktionen auf 100, mit Baseline-Dateien, die bestehende Schulden festhalten und nur schrumpfen dürfen, und es zielt auf fünf verfasste Quell- oder Testdateien pro Ordner mit einer harten Obergrenze von sieben; teilen Sie wachsende Ordner nach Feature oder Leseaufgabe.
Ein Beitrag sollte den Auslöser, das resultierende Verhalten, den betroffenen Vertrag und die Validierungsnachweise erklären, mit einem Screenshot für eine sichtbare Änderung und einer begrenzten Ablaufspur für einen Zustellfehler. Nehmen Sie nie private Session-Transkripte, Auth-Dateien oder maschinenspezifische Pfade auf.