@deveonc/spec-to-code 1.0.0-beta.2

package/templates/.ai/rules/react.rules.md

@@ -0,0 +1,36 @@
+# React Rules
+
+## Versioning
+- Target the latest stable React version used by the project.
+- If the version is unclear, inspect `package.json` and ask the user.
+- Avoid experimental/pre-release APIs unless explicitly requested.
+
+## Architecture
+- Prefer functional components with hooks; avoid class components.
+- Keep components small and focused (single responsibility).
+- Extract reusable UI into shared components and hooks.
+- Use composition over inheritance (children, render props when needed).
+
+## State & data
+- Keep state local when possible; lift only when necessary.
+- Use `useReducer` for complex local state.
+- Avoid prop drilling for deep trees; consider context for shared state.
+- Keep side effects in `useEffect` and make dependencies explicit.
+
+## Performance
+- Avoid premature optimization; use `memo`, `useMemo`, `useCallback` when needed.
+- Prefer stable keys for lists (no array index unless static).
+- Avoid unnecessary re-renders by keeping props stable.
+
+## Styling
+- Follow existing styling conventions (CSS Modules, styled-components, etc.).
+- Keep styles colocated with components when possible.
+
+## Testing
+- Add tests for critical user flows.
+- Prefer React Testing Library with user-centric assertions if available.
+
+## Quality
+- Use strict TypeScript typing when available.
+- Validate inputs and handle empty/error states explicitly.
+- Maintain accessibility (semantic HTML, labels, ARIA as needed).

package/templates/.ai/rules/springboot.rules.md

@@ -0,0 +1,134 @@
+# Spring Boot Rules (2.7, 3.x, 4.x)
+
+You are an AI assistant working in a Spring Boot codebase. Support
+Spring Boot 2.7, 3.x, and 4.x based on the project version.
+
+## 0. Version detection
+
+If the version is not explicit, check `pom.xml`, `build.gradle`, or
+Gradle version catalogs. Ask the user when it is unclear.
+
+### Spring Boot 2.7 assumptions
+
+- Spring Boot **2.7** built on **Spring Framework 5.3** and **Jakarta EE 8**.
+- Default namespace is `javax.*` (Servlet 4+, JPA 2.2, Bean Validation 2.0).
+- Runtime: Java 8/11/17 (prefer Java 11 unless the project states otherwise).
+
+### Spring Boot 3.x assumptions
+
+- Spring Boot **3.x** built on **Spring Framework 6** and **Jakarta EE 10**.
+- Namespace is `jakarta.*` (Servlet 6, JPA 3.1, Bean Validation 3.0).
+- Runtime: Java 17+ (prefer Java 17).
+
+### Spring Boot 4.x assumptions
+
+- Spring Boot **4.x** built on **Spring Framework 7** and **Jakarta EE 11**.
+- Namespace is `jakarta.*` (Servlet 6.1, JPA 3.2, Bean Validation 3.1).
+- Runtime: Java 21+ (prefer Java 21).
+
+## Version-specific guidance
+
+- Boot 2.7: `WebSecurityConfigurerAdapter` may exist; keep it unless migrating.
+- Boot 3.x/4.x: Use `SecurityFilterChain` + component-based security config.
+- Boot 3.x/4.x: Prefer `jakarta.*` validation, JPA, and servlet APIs.
+- Boot 2.7: Prefer `javax.*` and avoid Jakarta-only dependencies.
+- Boot 4.x: Favor Java 21 features (records, sealed types, virtual threads) when appropriate.
+
+Your goal is to:
+
+1. Generate **idiomatic Spring Boot code** for the detected version.
+2. Prefer **modern patterns** over legacy ones.
+3. Propose **incremental refactors** that move existing code toward the
+   target version’s best practices without unnecessary rewrites.
+
+
+---
+
+## 1. Project & Architecture Context
+
+- Use the Spring Boot version detected in Section 0.
+- Use `javax.*` only for Boot 2.7 projects; use `jakarta.*` for Boot 3.x/4.x.
+- Target runtime: match the detected Boot version (11 for 2.7, 17 for 3.x, 21 for 4.x).
+- The default architecture is **layered, domain-oriented**:
+
+    - API layer: REST controllers.
+    - Application / service layer: use cases and business logic.
+    - Domain layer: entities, value objects, domain services.
+    - Infrastructure layer: repositories, integration adapters, messaging, external services.
+
+When generating or modifying code:
+
+- Prefer **feature-/domain-based packages**, not purely technical (i.e. `customer`, `order`, etc., not only `controller`, `service`, `repository`).
+- Stick to **Spring Boot conventions over configuration**: use starters and auto-configuration rather than custom boilerplate wherever reasonable.
+
+---
+
+## 2. Package & File Structure
+
+When suggesting or creating new packages, follow this style:
+
+- `com.example.app` (root)
+    - `config` – application configuration classes.
+    - `domain1` - domain feature package
+        - `api` – REST controllers, DTOs, request/response.
+        - `services` – use cases, services.
+        - `repositories` – repositories and entities (Spring Data).
+        - `exceptions` – custom exceptions.
+        - `mappers` – mappers (e.g. for DTOs).
+    - `domain2` - domain2 feature package
+        - ...
+          Rules:
+
+- Use **lowercase package names**.
+- Name classes clearly:
+    - `CustomerController`, `CustomerService`, `CustomerRepository`, `CustomerEntity`, `Customer`, `CustomerMapper`.
+- Prefer **one public top-level class per file**.
+- Use **record** classes for immutable DTOs when Java 17+ is available.
+
+
+---
+
+## 3. Dependencies, Build & Configuration
+
+- Assume **Maven or Gradle** versions compatible with the detected Boot version.
+- Use official **Spring Boot starters** matching the project version.
+- Use `application.yml` (or `application-*.yml`) as the default for configuration examples.
+- For Boot configuration:
+    - Prefer **type-safe configuration properties** (`@ConfigurationProperties`) over `@Value`.
+    - Group related config into dedicated properties classes.
+
+When generating `pom.xml`/`build.gradle` snippets:
+
+- Do **not** pin versions for Spring Boot and Spring dependencies manually; rely on the Boot BOM and plugin where possible.
+- Use compiler settings that match the detected version:
+    - Boot 2.7: Java 11 (`<release>11</release>` / `VERSION_11`).
+    - Boot 3.x: Java 17 (`<release>17</release>` / `VERSION_17`).
+    - Boot 4.x: Java 21 (`<release>21</release>` / `VERSION_21`).
+
+
+---
+
+## 4. Web Layer & REST APIs
+
+- Use **annotated controllers** (`@RestController`) for HTTP APIs.
+- Map APIs with `@RequestMapping` / `@GetMapping` / `@PostMapping` etc.
+- Always return **typed responses** (`ResponseEntity<T>` or directly `T`).
+- Use **DTOs / records** for input and output instead of exposing JPA entities directly.
+
+Rules:
+
+- Use `javax.validation` annotations for Boot 2.7, `jakarta.validation` for Boot 3.x/4.x.
+
+- Annotate controller methods’ arguments with:
+    - `@RequestBody` for JSON bodies.
+    - `@PathVariable` / `@RequestParam` / `@RequestHeader` as needed.
+- Validate inputs using `@Valid` / `@Validated`.
+
+Example DTO as record:
+
+```java
+public record CreateCustomerRequest(
+    @NotBlank String name,
+    @Email String email
+) {}
+```