Mitwirkender Code

Suchen Sie die Implementierung

Beginnen Sie mit dem Verhalten, das Sie ändern. Für eine Desktop-Aktion folgen Sie apps/desktop/src/app/routes.tsx zu seinem Seitenadapter und Funktionsbildschirm. Suchen Sie die Anforderung in ihrem Client oder Feature-Helper, dem Endpunktschema in packages/api, der Handler in apps/sidecar/src/httpund den Dienst oder das Repository darunter.

Beginnen Sie bei einer Geometrie- oder NC-Ausgabeänderung mit packages/core und die dazugehörigen Tests. Überprüfen Sie bei einem Persistenzproblem die Repository-Abfrage und packages/db/src/schema.ts. Überprüfen Sie das native Lebenszyklus-, Dateidialog-, Schlüsselbund- oder Updater-Verhalten apps/desktop/src-tauri/src. Dadurch bleibt eine Änderung nah an ihrer tatsächlichen Verantwortung.

Verantwortlichkeiten am Arbeitsplatz

Verwenden Sie den öffentlichen Einstiegspunkt eines Moduls, sofern verfügbar. Halten Sie den SQLite-Zugriff von der Kerngeometrie und den Clients fern. Funktionsbildschirme sollten die Sidecar-Autorisierung nicht umgehen oder Serveranmeldeinformationen einbetten. Bei übergreifenden Änderungen sollte jede betroffene Grenze explizit aktualisiert werden.

Gemeinsame Verträge bewusst ändern

1. Definieren Sie die Anforderungs-, Antwort- und typisierten Fehlerschemata im Vertragspaket.
2. Implementieren Sie den Handler und sein Dienst-/Repository-Verhalten, einschließlich Eigentumsprüfungen.
3. Generieren Sie Clients neu und prüfen Sie, ob die generierte Ausgabe aktuell ist.
4. Aktualisieren Sie Desktop-, Companion-, Plugin- oder externe Client-Konsumenten, die die geänderte Oberfläche verwenden.
5. Dokumentieren Sie die unterstützten Eingaben, Ausgaben, das Fehlerverhalten und die Betriebsgrenzen.

bun run generate
bun run generate:check
bun run --filter @cadcamfun/api typecheck
bun run --filter @cadcamfun/sidecar typecheck

Generierte Kunden sind Ausgaben des Vertragsgenerators. Korrigieren Sie den Vertrag oder den Generator, wenn deren Formen falsch sind. Eine handschriftliche Korrektur der generierten Ausgabe geht bei der Neugenerierung verloren. Behalten Sie die vorhandene Client-Semantik bei oder identifizieren Sie die Kompatibilitätsauswirkungen einer absichtlichen API-Änderung.

Implementierungskonventionen

Schreiben Sie Code, Kommentare und Dokumentation auf Englisch. Halten Sie exportierte TypeScript-Schnittstellen explizit und verwenden Sie sie unknown plus Schemavalidierung für nicht vertrauenswürdige Werte. Relative TypeScript-Importe verwenden .ts erweiterungen. Für CAD-Abstände werden Millimeter und für Zeichnungswinkel das Bogenmaß verwendet. Berücksichtigen Sie ausdrücklich Gradwert-Feature- und CAM-Dreheingaben. NC-Nummern an der Pfostengrenze formatieren.

Der Effektcode verwendet die Service-/Layer-/Fehler-APIs der angehefteten Version. Dienste besitzen externe Abhängigkeiten; Bereichsebenen verfügen über eigene Ressourcen. Vermeiden Sie das Hinzufügen versteckter Prozesskonfigurationslesevorgänge innerhalb eines Domänenmoduls. Halten Sie Geometrieberechnungen rein und isolieren Sie Dateisystem-, Netzwerk- und Datenbankoperationen hinter ihren Adaptern.

Für eine Schemaänderung ändern Sie schema.ts, generieren Sie eine Migration und führen Sie sowohl die Neuerstellung als auch das Upgrade einer vorhandenen Datenbank durch. Halten Sie bei einer Änderung der Benutzeroberfläche die Routenadapter klein und platzieren Sie die Interaktionslogik in der entsprechenden Funktion. Behalten Sie für native Arbeiten die Geometrie und die Repository-Logik im Sidecar/Kern, anstatt sie nach Rust zu verschieben.

Verifizierung vor Überprüfung

• Führen Sie die Typprüfung des betroffenen Pakets und aussagekräftige Tests für das geänderte Verhalten durch.
• Für eine Fehlerbehebung demonstrieren Sie die fehlerhafte Bedingung und das korrigierte Ergebnis.
• Überprüfen Sie bei gemeinsamen Verträgen die generierten Kunden und betroffenen Verbraucher.
• Um die Persistenz zu gewährleisten, überprüfen Sie das Migrationsverhalten und die Datenintegrität mithilfe isolierter Datenbanken.
• Führen Sie bei nativen oder gerenderten Interaktionen zusätzlich zu den Logiktests auch die eigentliche Ziellaufzeit durch.
• Aktualisieren Sie die Benutzer-/Entwicklerdokumentation und erläutern Sie die verbleibenden betrieblichen Einschränkungen.

Die Root-Checks sind bun run typecheck und bun run test. CI hat auch Rust- und Companion-spezifische Jobs. Melden Sie, was ausgeführt wurde und welche Fehler oder nicht verfügbare Laufzeitabdeckung vorliegen. einen konfigurierten Workflow von einem erfolgreichen Lauf unterscheiden.

Halten Sie Änderungen überprüfbar

Sorgen Sie dafür, dass generierte Artefakte, Abhängigkeitsaktualisierungen, Verhaltensänderungen und Dokumentationsänderungen auf denselben konkreten Zweck zurückzuführen sind. Vermeiden Sie die Neuformatierung nicht verwandter Module. Behalten Sie die Arbeit vorhandener Benutzer bei und nutzen Sie verfügbare Datenverzeichnisse für Experimente.

Fügen Sie in Patches oder Screenshots keine Starttokens, Gerätekopplungslinks, Modellschlüssel, Datenbankinhalte oder Signaturanmeldeinformationen ein. Beispiele sollten Platzhalter verwenden. Ein lokaler Fixture- oder Mock-Provider kann einen deterministischen Fluss validieren; Dokument, bei dem ein echter Anbieter oder eine native Integration weiterhin erforderlich ist.

Nützliche Schecks

bun run --filter @cadcamfun/core typecheck
bun test packages/core
bun test apps/sidecar/test
bun test apps/desktop/src
bun run --cwd apps/mobile typecheck
bun run --cwd apps/mobile test
bun run --cwd packages/web check
bun run --cwd packages/web build

Verwendung nativer Verpackungen scripts/build.ts; verwenden --help oder --dry-run seine Stadien zu inspizieren. Unit-Tests sind von der Typprüfungsphase der Build-Pipeline getrennt. Informationen zum Signieren, zur Zielarchitektur und zur Updater-Validierung finden Sie im Release-Leitfaden.

Beispiel: Projektvalidierung ändern

Angenommen, die Regel zum Erstellen/Aktualisieren eines Projekts ändert sich. Das Anforderungsschema ist packages/api/src/projects.ts, der HTTP-Adapter ist apps/sidecar/src/http/projects.ts, und Persistenz wird implementiert durch ProjectRepo. Das Schema macht derzeit name optional, während Handler es für die Erstellung und Aktualisierung benötigen. Überprüfen Sie beide Ebenen, bevor Sie versprechen, dass eine schemagültige Anfrage erfolgreich sein wird.

1. Definieren Sie die vorgesehenen Eingabefälle: fehlender Name, ungültiger Typ, leerer Text, zugängliche Organisation und nicht zugängliche Organisation.
2. Entscheiden Sie, welche Bedingung ein Decodierungsfehler und welche eine Geschäftsvalidierung darstellt. Behalten Sie die dokumentierte Status-/Fehlerform des Endpunkts bei.
3. Fügen Sie Assertionen an der relevanten Handler-/Dienstgrenze hinzu und stellen Sie sicher, dass nicht autorisierte Anrufer oder Anrufer, die keine Mitglieder sind, die Regel nicht umgehen können.
4. Wenn sich das öffentliche Schema geändert hat, generieren Sie beide Clientfamilien neu und überprüfen Sie die Verbraucher.
5. Nutzen Sie das Desktop-Formular und dokumentieren Sie alle geänderten Anforderungsanforderungen.

Die Erstellung gibt derzeit eine leere Projektzeile mit HTTP 201 zurück. Mit Beziehungen angereicherte Zeilen auflisten/erhalten und zurückgeben. Setzen Sie dieser Familie keinen allgemeinen Erfolgsrahmen auf, ohne ihren Vertrag und ihre Verbraucher zu aktualisieren. Andere Endpunktfamilien verwenden absichtlich andere Umschläge.

Der Generator-Einstiegspunkt ist packages/api/scripts/generate-clients.ts. Seine Ausgänge leben unter src/client/generated und src/sdk/generated. Änderungen an der Vertragsoberfläche gehören in den Quellvertrag; Die erzeugte Ausgabe sollte reproduzierbar sein.

Wählen Sie eine Regression mit der richtigen Tiefe

Eine Geometrieregression sollte die Geometrie bestätigen und nicht nur die geänderte Berechnung wiederholen. Bestehende Kollisionstests liefern nützliche Muster: Eine stationäre Überlappung ist eine Kollision zum Zeitpunkt Null; ein Zwischenrotationsdurchlauf kann selbst dann kollidieren, wenn ein Endpunkt klar ist; eine unzureichende Grenze ist ungelöst; und eine zertifizierte Freigabe wird mit einer dichten unabhängigen Referenz verglichen.

bun test packages/core/src/cam/kernel/collision.test.ts
bun run --filter @cadcamfun/core typecheck
bun test packages/core

Wählen Sie die analoge Grenze für andere Arbeiten. Für eine Datenbankmigration sind Neu-/Upgrade-Fälle und Backup-Fehlerverhalten erforderlich. Ein Stream-Parser benötigt geteilte Frames und Löschung. Eine UI-Speicheränderung erfordert eine Zielauswahl, einen Anforderungsfehler, einen erneuten Versuch und das erneute Öffnen des gespeicherten Zustands. Ein nativer Befehl benötigt zusätzlich zu einer Frontend-Typprüfung eine Validierung und ein Lebenszyklusverhalten.

Halten Sie die Schecks proportional zur Änderung. Inhaltsänderungen erfordern eine Navigations-/Vorlagenüberprüfung; Sie erfordern nicht die Erfindung neuer Domänentests. Ein bestandener enger Test unterstützt nur sein behauptetes Verhalten. Schließen Sie daher die Paket- oder Integrationsprüfungen ein, die für die geänderte öffentliche Oberfläche erforderlich sind.

Dokumentation beisteuern

Die Website ist da packages/web. Verwendung von Dokumentationsseiten DocsLayout, ein Inhaltsverzeichnis, Abschnittskennungen und gemeinsam genutzte Code-/Callout-/verwandte Linkkomponenten. Behalten Sie diese Seitenkonventionen und das vorhandene visuelle Design bei und verbessern Sie gleichzeitig den Inhalt.

1. Lesen Sie die Implementierung, das Manifest und die Konfiguration für jedes Verhalten, das Sie dokumentieren.
2. Verwenden Sie eine unterstützte Befehls- oder Anforderungsform und geben Sie das erforderliche Arbeitsverzeichnis, die Anmeldeinformationen, den Datenpfad und die nativen Voraussetzungen an.
3. Beschreiben Sie das Ergebnis und seine Fehlermodi. Beschriften Sie Beispiele als Beispiele; Rufen Sie eine Antwort nur dann als erfasst auf, wenn sie tatsächlich erfasst wurde.
4. Aktualisieren Sie die Navigations- und Abrufmetadaten, wenn Sie eine Route hinzufügen oder umbenennen, und korrigieren Sie jeden lokalen Link zum alten Standort.
5. Führen Sie Indexprüfungen und den Astro-Build durch und überprüfen Sie dann die gerenderte Seite und ihre Anker.

bun run --cwd packages/web check
bun run --cwd packages/web typecheck
bun run --cwd packages/web build

Behauptungen über konfigurierte CI sollten angeben, was der Workflow bewirkt. Behauptungen über eine erfolgreiche Veröffentlichung oder Laufzeitakzeptanz erfordern den jeweiligen Lauf/Artefakt als Beweis. Die Dokumentation sollte implementiertes Verhalten, Standardwerte und Grenzwerte unterscheiden, ohne interne Planungsnotizen in Produktanweisungen umzuwandeln.

Pull-Request-Checkliste

• bun run typecheck geht an der Wurzel vorbei.
• bun run test pässe; Für neues Verhalten gibt es neben dem Code einen Test.
• Vertragsänderungen werden neu generiert: bun run generate:check und bun run --filter @cadcamfun/web check sind sauber.
• Schemaänderungen umfassen den generierten Migrationsordner und sind niemals Bearbeitungen einer angewendeten Migration.
• Rustveränderungen gehen vorüber cargo clippy und cargo test (CI führt beides aus).
• Für den Benutzer sichtbares Verhalten wird auf der Dokumentationsseite widergespiegelt, auf der es beschrieben wird.

CI führt bei jedem Push die gleichen Befehle aus, daher ist eine grüne lokale Ausführung der beste Prädiktor für eine grüne Pull-Anfrage.

In 3D