Código contribuyente

Localizar la implementación

Comience con el comportamiento que está cambiando. Para una acción de escritorio, siga apps/desktop/src/app/routes.tsx a su adaptador de página y pantalla de funciones. Ubique la solicitud en su cliente o asistente de funciones, el esquema de punto final en packages/api, el manejador en apps/sidecar/src/httpy el servicio o repositorio debajo de él.

Para un cambio de geometría o salida NC, comience en packages/core y sus pruebas adyacentes. Para un problema de persistencia, inspeccione la consulta del repositorio y packages/db/src/schema.ts. Para conocer el ciclo de vida nativo, el cuadro de diálogo de archivos, el llavero o el comportamiento del actualizador, inspeccione apps/desktop/src-tauri/src. Esto mantiene un cambio cercano a su responsabilidad real.

Responsabilidades del espacio de trabajo

Utilice el punto de entrada público de un módulo cuando esté disponible. Mantenga el acceso a SQLite fuera de la geometría central y los clientes. Las pantallas de funciones no deben omitir la autorización adicional ni incorporar las credenciales del servidor. Los cambios transversales deben actualizar explícitamente cada límite afectado.

Cambiar los contratos compartidos deliberadamente

1. Defina los esquemas de solicitud, respuesta y error escrito en el paquete de contrato.
2. Implemente el controlador y su comportamiento de servicio/repositorio, incluidas las comprobaciones de propiedad.
3. Regenere los clientes y verifique que la salida generada sea actual.
4. Actualice los consumidores de escritorio, complementarios, de complementos o de clientes externos que utilizan la superficie modificada.
5. Documente las entradas y salidas admitidas, el comportamiento de falla y los límites operativos.

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

Los clientes generados son salidas del generador de contratos. Arreglar el contrato o generador cuando sus formas estén equivocadas; una corrección escrita a mano de la salida generada se perderá durante la regeneración. Preserve la semántica del cliente existente o identifique el impacto en la compatibilidad de un cambio deliberado de API.

Convenciones de implementación

Escribir código, comentarios y documentación en inglés. Mantenga explícitas las interfaces TypeScript exportadas y utilícelas unknown además de validación de esquema para valores que no son de confianza. Uso relativo de importaciones de TypeScript .ts extensiones. Las distancias CAD utilizan milímetros y los ángulos de dibujo utilizan radianes; Respete las características explícitamente valoradas en grados y las entradas rotativas CAM. Formatee los números NC en el límite del poste.

El código del efecto utiliza las API de servicio/capa/error de la versión fijada. Servicios propios de dependencias externas; recursos propios de las capas con alcance. Evite agregar lecturas de configuración de procesos ocultos dentro de un módulo de dominio. Mantenga los cálculos de geometría puros y aísle las operaciones del sistema de archivos, la red y la base de datos detrás de sus adaptadores.

Para un cambio de esquema, modifique schema.ts, generar una migración y ejercer tanto la creación nueva como la actualización de una base de datos existente. Para un cambio de interfaz de usuario, mantenga los adaptadores de ruta pequeños y coloque la lógica de interacción en la característica relevante. Para el trabajo nativo, mantenga la geometría y la lógica del repositorio en el sidecar/núcleo en lugar de moverlos a Rust.

Verificación antes de la revisión

• Ejecute la verificación de tipos del paquete afectado y pruebas significativas para el comportamiento modificado.
• Para corregir un error, demuestre la condición fallida y su resultado corregido.
• Para contratos compartidos, verifique los clientes generados y los consumidores afectados.
• Para lograr persistencia, verifique el comportamiento de la migración y la integridad de los datos utilizando bases de datos aisladas.
• Para interacciones nativas o renderizadas, ejerza el tiempo de ejecución de destino real además de las pruebas lógicas.
• Actualice la documentación del usuario/desarrollador y explique las limitaciones operativas que persisten.

Las comprobaciones de raíz son bun run typecheck y bun run test. CI también tiene Rust y trabajos específicos complementarios. Informar lo que se ejecutó y cualquier falla o cobertura de tiempo de ejecución no disponible; distinguir un flujo de trabajo configurado de una ejecución exitosa.

Mantener los cambios revisables

Mantenga los artefactos generados, las actualizaciones de dependencias, los cambios de comportamiento y los cambios de documentación rastreables con el mismo propósito concreto. Evite reformatear módulos no relacionados. Conserve el trabajo de los usuarios existentes y utilice directorios de datos desechables para experimentos.

No incluya tokens de inicio, enlaces de emparejamiento de dispositivos, claves de modelo, contenidos de bases de datos ni credenciales de firma en parches o capturas de pantalla. Los ejemplos deben utilizar marcadores de posición. Un elemento local o un proveedor burlado puede validar un flujo determinista; documento donde sigue siendo necesaria una integración nativa o de proveedor real.

Comprobaciones útiles

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

Usos de embalaje nativo scripts/build.ts; usar --help o --dry-run para inspeccionar sus etapas. Las pruebas unitarias están separadas de la etapa de verificación de tipo del canal de compilación. Consulte la guía de lanzamiento para la firma, la arquitectura de destino y la validación del actualizador.

Ejemplo: cambiar la validación del proyecto

Supongamos que la regla de creación/actualización de un proyecto cambia. El esquema de solicitud es packages/api/src/projects.ts, el adaptador HTTP es apps/sidecar/src/http/projects.ts, y la persistencia se implementa mediante ProjectRepo. El esquema actualmente hace name opcional, mientras que los controladores lo requieren para su creación y actualización. Inspeccione ambos niveles antes de prometer que una solicitud válida para el esquema se realizará correctamente.

1. Defina los casos de entrada previstos: nombre faltante, tipo no válido, texto vacío, organización accesible y organización inaccesible.
2. Decida qué condición es un error de decodificación y cuál es una validación empresarial. Conserve la forma de error/estado documentado del terminal.
3. Agregue aserciones en el límite de servicio/controlador relevante y verifique que las personas que llaman no autorizadas o que no son miembros no puedan eludir la regla.
4. Si el esquema público cambió, regenere tanto las familias de clientes como los consumidores de verificación de tipo.
5. Utilice el formulario de escritorio y documente cualquier cambio en los requisitos de la solicitud.

La creación actualmente devuelve una fila de proyecto simple con HTTP 201. Listar/obtener filas enriquecidas con relaciones de retorno. No imponer una dotación genérica de éxito a esta familia sin actualizar su contrato y sus consumidores. Otras familias de puntos finales utilizan intencionalmente sobres diferentes.

El punto de entrada del generador es packages/api/scripts/generate-clients.ts. Sus salidas viven bajo src/client/generated y src/sdk/generated. Los cambios en la superficie del contrato pertenecen al contrato fuente; La salida generada debe ser reproducible.

Elija una regresión en la profundidad adecuada

Una regresión geométrica debe afirmar la geometría, no solo repetir el cálculo que se está cambiando. Las pruebas de colisión existentes proporcionan patrones útiles: una superposición estacionaria es una colisión en el tiempo cero; un barrido rotacional intermedio puede colisionar incluso cuando un punto final está despejado; un límite insuficiente no está resuelto; y una autorización certificada se compara con una densa referencia independiente.

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

Elija el límite análogo para otro trabajo. Una migración de base de datos necesita casos nuevos/actualizados y un comportamiento de falla en la copia de seguridad. Un analizador de flujo necesita cuadros divididos y cancelación. Un cambio guardado en la UI necesita selección de destino, solicitud fallida, reintento y reapertura del estado guardado. Un comando nativo necesita validación y comportamiento del ciclo de vida además de una verificación de tipo en la interfaz.

Mantenga los cheques proporcionales al cambio. Las ediciones de contenido necesitan verificación de navegación/plantilla; no requieren inventar nuevas pruebas de dominio. Una prueba limitada que pasa solo respalda su comportamiento afirmado, por lo tanto, incluya las comprobaciones de paquete o integración requeridas por la superficie pública modificada.

Contribuir con documentación

El sitio web está en packages/web. Uso de páginas de documentación. DocsLayout, una tabla de contenido, identificadores de sección y componentes de código/llamada/enlace relacionado compartido. Conserve esas convenciones de página y el diseño visual existente mientras mejora el contenido.

1. Lea la implementación, el manifiesto y la configuración de cada comportamiento que documente.
2. Utilice un comando compatible o una forma de solicitud e indique el directorio de trabajo, las credenciales, la ruta de datos y los requisitos previos nativos necesarios.
3. Describir el resultado y sus modos de falla. Etiquetar ejemplos como ejemplos; llamar a una respuesta capturada solo cuando realmente fue capturada.
4. Actualice los metadatos de navegación y recuperación al agregar o cambiar el nombre de una ruta, y corrija cada enlace local a la ubicación anterior.
5. Ejecute comprobaciones de índice y la compilación de Astro, luego inspeccione la página renderizada y sus anclajes.

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

Las afirmaciones sobre la CI configurada deben decir qué hace el flujo de trabajo. Las afirmaciones sobre una publicación exitosa o la aceptación del tiempo de ejecución necesitan la ejecución/artefacto particular como evidencia. La documentación debe distinguir el comportamiento implementado, los valores predeterminados y los límites sin convertir las notas de planificación interna en instrucciones del producto.

Lista de verificación de solicitud de extracción

• bun run typecheck pasa por la raíz.
• bun run test pases; El nuevo comportamiento tiene una prueba al lado del código.
• Los cambios de contrato se regeneran: bun run generate:check y bun run --filter @cadcamfun/web check están limpios.
• Los cambios de esquema incluyen la carpeta de migración generada y nunca son ediciones de una migración aplicada.
• Pasan los cambios de Rust cargo clippy y cargo test (CI ejecuta ambos).
• El comportamiento visible para el usuario se refleja en la página de documentos que lo describe.

CI ejecuta los mismos comandos en cada inserción, por lo que una ejecución local verde es el mejor predictor de una solicitud de extracción verde.

En 3D