ideal-agentic-workflow 1.0.0

package/resources/stacks/database-mongo-redis.md

@@ -0,0 +1,56 @@
+# Stack Pack: MongoDB + Redis
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for MongoDB and Redis (Upstash) applications. An auditor MUST verify that the infrastructure matches these requirements to ensure compatibility with modern driver features. Failing to meet these requirements can lead to connection issues in serverless environments.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| MongoDB | 6.0 | `mongodb` or `mongoose` driver | MongoDB < 5.0 |
+| Redis (Upstash) | 6.2 | `ioredis` or `@upstash/redis` | Local-only Redis configs in serverless |
+| Node.js | 18.17.0 | None | Node.js < 18 |
+
+## 2. Architecture Rules
+These rules define the structural boundaries and hygiene of a NoSQL and Key-Value store architecture. The codebase MUST adhere strictly to these constraints to ensure data consistency and prevent memory exhaustion. Violating these rules commonly results in unstructured data blobs and out-of-memory errors in caching layers.
+
+- **Schema Validation**: MongoDB collections MUST enforce schema validation either at the database level (using JSON Schema validation) or at the application layer (using Mongoose schemas or Pydantic/Zod). Arbitrary document structures without validation are prohibited.
+- **Index Creation**: The application MUST NOT rely on automatic index creation in production. Indexes MUST be defined explicitly and created via a deployment script or migration tool, not during application startup.
+- **Redis TTL Requirement**: Every key written to Redis (including Upstash) MUST have a Time-To-Live (TTL) configured. Keys MUST NOT be allowed to persist indefinitely unless they are part of a bounded, explicitly managed state machine.
+- **Keyspace Namespacing**: Redis keys MUST be prefixed with a clear namespace to prevent keyspace collisions (e.g., `session:user_123`, `rate_limit:ip_456`).
+- **Connection Management**: MongoDB connections MUST be cached across serverless invocations (e.g., storing the client in a global variable) to prevent connection exhaustion. Upstash Redis MUST use REST-based clients (`@upstash/redis`) in serverless environments rather than TCP connections.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in MongoDB and Redis applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent NoSQL injection vulnerabilities and out-of-memory incidents.
+
+#### AP-MONGO-01: NoSQL Injection Vulnerability
+**What it is**: Passing user input directly into MongoDB query objects without sanitization.
+**Detection signal**: Querying the database with an object that directly spreads `req.body` or `req.query`, such as `db.users.find(req.query)`.
+**Consequence**: Attackers can inject query operators like `$gt` or `$ne` in the payload (e.g., `?password[$ne]=`) to bypass authentication or extract sensitive data.
+**Correct alternative**: Explicitly map and sanitize input fields: `db.users.find({ username: req.body.username })`.
+
+#### AP-REDIS-01: Missing TTL on Cache Keys
+**What it is**: Writing data to Redis without setting an expiration time (TTL).
+**Detection signal**: Using `redis.set("key", "value")` without passing the `EX` or `PX` arguments.
+**Consequence**: The Redis instance eventually runs out of memory, causing evictions of important data or crashing the cache entirely.
+**Correct alternative**: Always specify a TTL: `redis.set("key", "value", "EX", 3600)`.
+
+#### AP-MONGO-02: Unbounded Array Growth
+**What it is**: Continuously pushing items into an array field within a single MongoDB document.
+**Detection signal**: Frequent use of the `$push` operator without `$slice` or `$sort` to cap the array size.
+**Consequence**: The document exceeds the 16MB BSON limit, causing the application to crash on updates, and degrades read performance.
+**Correct alternative**: Move unbounded one-to-many relationships to a separate collection and reference the parent document ID.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a MongoDB and Redis codebase. Failure to check these items may result in critical security vulnerabilities, unbounded memory usage, and exhausted connection limits.
+- [ ] All MongoDB queries strictly sanitize user input and map fields explicitly to prevent NoSQL injection.
+- [ ] Unbounded array growth is prevented via separate collections or the `$slice` operator.
+- [ ] Every Redis `set` operation includes a TTL parameter.
+- [ ] Redis keys use a structured prefix naming convention (e.g., `entity:id`).
+- [ ] Serverless environments use global connection caching for MongoDB.
+- [ ] Serverless environments use HTTP/REST clients for Upstash Redis instead of TCP connections.
+
+## 5. Useful References
+The following resources provide authoritative guidance on building secure and performant applications with MongoDB and Redis. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding schema design, index management, or caching strategies. Utilizing these resources prevents the adoption of brittle NoSQL data models.
+- [MongoDB Schema Design Anti-Patterns](https://www.mongodb.com/developer/products/mongodb/schema-design-anti-pattern-summary/): Explains common pitfalls like unbounded arrays and monolithic documents.
+- [Upstash Redis Best Practices](https://docs.upstash.com/redis): Guide on utilizing Redis over REST APIs in serverless architectures.
+- [Preventing NoSQL Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.6-Testing_for_NoSQL_Injection): Comprehensive OWASP documentation on sanitizing input before querying a NoSQL database.
+- [Redis TTL Documentation](https://redis.io/commands/expire/): Information on key expiration and eviction policies.

package/resources/stacks/database-postgres-prisma.md

@@ -0,0 +1,55 @@
+# Stack Pack: PostgreSQL + Prisma
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for PostgreSQL and Prisma ORM. An auditor MUST verify that `package.json` files comply with these ranges to prevent runtime failures and schema sync issues. Ensuring these versions are met is critical for utilizing modern Prisma features like full-text search and JSONB filtering.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| PostgreSQL | 14.0 | None | Postgres < 14 |
+| Prisma | 5.0.0 | `@prisma/client` | Prisma 4.x or earlier |
+| Node.js | 18.17.0 | None | Node.js < 18 |
+
+## 2. Architecture Rules
+These rules define the structural boundaries and data access patterns of a Prisma-backed application. The codebase MUST adhere strictly to these constraints to ensure data integrity, atomicity, and performance. Note: For Upstash Redis constraints (TTL, Keyspace Namespacing) that are often paired with Prisma, refer to the `database-mongo-redis.md` stack pack.
+
+- **Prisma Migration Discipline**: The application MUST NOT alter existing migration files (`.sql` files in `prisma/migrations`) after they have been applied to the database. All schema changes MUST be made in `schema.prisma` and applied via a new migration using `prisma migrate dev`.
+- **Index Placement Rules**: The `schema.prisma` file MUST declare indexes (`@@index`) for fields frequently used in `where`, `orderBy`, or `join` operations. When creating composite indexes, the fields MUST be ordered starting with the most selective field first.
+- **Atomicity Requirement**: The application MUST use `prisma.$transaction` for any operation that involves multi-table writes or sequential operations that must succeed or fail together. 
+- **Connection Pool Limits**: When deploying to serverless environments, the application MUST use an external connection pooler (e.g., PgBouncer) or Prisma Accelerate. Directly connecting serverless functions to PostgreSQL without a pooler exhausts database connections and crashes the application.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in Prisma-backed applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent catastrophic database load and connection exhaustion.
+
+#### AP-PRISMA-01: Prisma N+1 Query Problem
+**What it is**: Fetching a list of records and iterating over them to query related records individually, causing an explosion of database queries.
+**Detection signal**: A `prisma.model.findUnique()` or `findMany()` call located inside a `for` loop, `map()`, or `Promise.all()`.
+**Consequence**: Extremely slow response times as $N$ queries are sent sequentially to the database, exhausting connection pools.
+**Correct alternative**: Use Prisma's `include` or `select` parameters to fetch nested relations in a single query, or use `in` operator to fetch multiple records in one go.
+
+#### AP-PRISMA-02: Over-fetching with `include`
+**What it is**: Using `include` without limits to fetch deeply nested relational data when only a few fields are needed.
+**Detection signal**: A `prisma.model.findMany({ include: { relations: true } })` call that returns massive payloads.
+**Consequence**: Excessive memory consumption in the Node.js process and slow database deserialization times.
+**Correct alternative**: Use `select` instead of `include` to specify the exact fields needed, or apply pagination (`take`, `skip`) to nested includes.
+
+#### AP-PRISMA-03: Direct Mutation of Migration Files
+**What it is**: Modifying a generated `migration.sql` file after it has already been committed and applied to staging or production.
+**Detection signal**: A git diff showing changes to an older `.sql` file inside the `prisma/migrations/` directory.
+**Consequence**: The migration history drifts between environments, causing `prisma migrate deploy` to fail with checksum errors.
+**Correct alternative**: Make changes in `schema.prisma` and run `npx prisma migrate dev --name <description>` to generate a new migration.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Prisma codebase. Failure to check these items may result in corrupted migration histories, connection pool exhaustion, or severe performance degradation.
+- [ ] No `prisma.*` queries exist inside loops or `Promise.all()` maps.
+- [ ] Multi-table writes are wrapped in a `prisma.$transaction` block.
+- [ ] Foreign keys and heavily queried fields have `@@index` defined in `schema.prisma`.
+- [ ] Old migration files have not been modified.
+- [ ] Serverless deployments use PgBouncer or Prisma Accelerate for connection pooling.
+- [ ] Queries use `select` to limit payload size instead of over-fetching with blind `include`.
+
+## 5. Useful References
+The following resources provide authoritative guidance on optimizing database access with Prisma and PostgreSQL. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding database transactions, connection pooling, or migration workflows. Ensuring the application adheres to these best practices is essential for database scalability.
+- [Prisma Optimization and N+1](https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance): Guide on resolving N+1 queries and optimizing data fetching strategies.
+- [Prisma Transactions](https://www.prisma.io/docs/concepts/components/prisma-client/transactions): Best practices for ensuring data atomicity with interactive and nested transactions.
+- [Prisma Schema Reference](https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference): Official reference for all valid schema.prisma properties, types, and attributes.
+- [PostgreSQL Documentation on Indexes](https://www.postgresql.org/docs/current/indexes.html): Guide on B-Tree index structure and multi-column index optimization.

package/resources/stacks/mc-fabric.md

@@ -0,0 +1,60 @@
+# Stack Pack: Minecraft Mod (Fabric)
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for Fabric mods. An auditor MUST verify that `gradle.properties` and `build.gradle` files comply with these strict matrices. Strict adherence to these versions ensures the mod compiles against the correct mappings and game APIs.
+**Note**: The ecosystem splits severely between 1.21.x and 26.x.
+
+| Target MC Version | Fabric Loom | Gradle | Java | Allowed Mappings |
+|---|---|---|---|---|
+| MC 1.21.8 – 1.21.11 | ≤ 1.16 | 8.x | 21 | Yarn OR Mojang |
+| MC 26.x | ≥ 1.17 | ≥ 9.5.1 | 25 | Mojang ONLY |
+
+**Additional 26.x Constraints**:
+- MC 26.2+ requires the Blaze3D API. Raw OpenGL calls are prohibited due to the experimental Vulkan backend.
+- Yarn mappings are officially unsupported for 26.x and MUST NOT be used.
+
+## 2. Architecture Rules
+These rules define the structural boundaries of a Fabric mod. The codebase MUST adhere strictly to these constraints to ensure server/client stability and registry timing. Failing to respect these boundaries will cause dedicated servers to crash upon initialization.
+
+- **Initializer Split Rules**: The mod MUST separate its entry points. `ModInitializer` is for common code (registries, common events). `ClientModInitializer` is exclusively for client-side code (rendering, screens, keybinds). `DedicatedServerModInitializer` is exclusively for server-side behavior.
+- **Client Code Isolation**: Server and common code MUST NEVER reference client-only classes (e.g., `MinecraftClient`, `Screen`, rendering classes). The `@Environment(EnvType.CLIENT)` annotation MUST be respected, and violating this boundary will cause dedicated servers to crash on startup.
+- **Registry Entry Timing**: All registry entries (Blocks, Items, Entities) MUST be registered synchronously within the `onInitialize()` method of the `ModInitializer`. Lazy registration or registering items during gameplay events is strictly prohibited.
+- **Dependency Declarations**: The `fabric.mod.json` file MUST accurately declare dependencies in the `depends`, `recommends`, and `breaks` fields. This includes declaring a dependency on `fabric-api` if its modules are used.
+- **Event Handler Patterns**: The application MUST use the Fabric API Event system (e.g., `ServerTickEvents.END_SERVER_TICK.register(...)`) for callbacks rather than resorting to mixins for standard hooks.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in Fabric mod development. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent mod incompatibility and dedicated server crashes.
+
+#### AP-FABRIC-01: Client Code Bleed in Common Setup
+**What it is**: Referencing client-only classes from within the main `ModInitializer` or common event handlers.
+**Detection signal**: Importing `net.minecraft.client.MinecraftClient` or setting up a `KeyBinding` inside the class that implements `ModInitializer`.
+**Consequence**: The mod works perfectly in the single-player development environment but crashes instantly with a `ClassNotFoundException` when deployed to a dedicated server.
+**Correct alternative**: Move all client-side logic to a separate class that implements `ClientModInitializer`.
+
+#### AP-FABRIC-02: Overwriting Core Methods via Mixin
+**What it is**: Using the `@Overwrite` annotation in a Mixin to completely replace a vanilla method.
+**Detection signal**: The presence of `@Overwrite` in any Mixin class.
+**Consequence**: Absolute incompatibility with any other mod that attempts to modify the same method, breaking the mod ecosystem.
+**Correct alternative**: Use `@Inject` (with `cancellable = true` if necessary), `@ModifyVariable`, or `@ModifyReturnValue` to alter behavior cooperatively.
+
+#### AP-FABRIC-03: Raw OpenGL in 26.2+
+**What it is**: Using raw `GL11` or `RenderSystem` calls that bypass the abstraction layer in modern Minecraft.
+**Detection signal**: Direct calls to `GL11.glEnable()` or similar low-level GL commands.
+**Consequence**: The mod will crash or render incorrectly when the Vulkan backend is enabled in MC 26.2+.
+**Correct alternative**: Use the Blaze3D API and the `MatrixStack` / `VertexConsumer` systems provided by Minecraft.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Fabric mod. Failure to check these items may result in catastrophic compatibility issues, unstable mixins, or a broken build process.
+- [ ] Version constraints (Loom, Gradle, Java, Mappings) strictly match the target MC version.
+- [ ] No client-only classes are referenced in `ModInitializer` or common code.
+- [ ] All registries are initialized synchronously in `onInitialize()`.
+- [ ] Mixins do not use the `@Overwrite` annotation.
+- [ ] `fabric.mod.json` correctly declares all dependencies and incompatibilities.
+- [ ] For MC 26.2+ targets, no raw OpenGL calls exist.
+
+## 5. Useful References
+The following resources provide authoritative guidance on developing resilient Minecraft mods using the Fabric toolchain. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding networking, mixins, or the registry system. Referencing these guides ensures the mod remains compatible with the wider ecosystem.
+- [Fabric Wiki: Environment isolation](https://fabricmc.net/wiki/tutorial:side): Deep dive on the distinction between the logical and physical server/client.
+- [Fabric Wiki: Mixin Introduction](https://fabricmc.net/wiki/tutorial:mixin): Guidelines for writing safe, compatible mixins.
+- [Fabric Registry Guidelines](https://fabricmc.net/wiki/tutorial:registry): Details on how and when to register new items and blocks.
+- [SpongePowered Mixin Documentation](https://github.com/SpongePowered/Mixin/wiki): The official, comprehensive reference for all mixin annotations.

package/resources/stacks/mc-neoforge.md

@@ -0,0 +1,64 @@
+# Stack Pack: Minecraft Mod (NeoForge)
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for NeoForge mods. An auditor MUST verify that `gradle.properties`, `build.gradle`, and `neoforge.mods.toml` files comply with these matrices. Correctly specifying version bounds prevents game crashes on launch and ensures compatibility with the latest API breaking changes.
+
+| Target MC Version | NeoForge | Gradle | Java | Allowed Mappings |
+|---|---|---|---|---|
+| MC 1.21.8 – 1.21.11 | 21.x | 8.x | 21 | Mojang (Parchment optional) |
+| MC 26.x | 26.x | ≥ 9.5.1 | 25 | Mojang ONLY (No obfuscation!) |
+
+**Additional Requirements**:
+- `neoforge.mods.toml` MUST declare dependency ranges accurately using syntax like `[21.0,22)` for MC 1.21.x targets.
+- MC 26.x environments run natively without obfuscation. Deobfuscation assumptions in build scripts MUST be removed for 26.x.
+
+## 2. Architecture Rules
+These rules define the structural boundaries of a NeoForge mod. The codebase MUST adhere strictly to these constraints to ensure compatibility, correct event bus targeting, and safe registration. Bypassing these abstractions leads to race conditions and broken registries.
+
+- **@Mod Annotation**: The main class MUST be annotated with `@Mod("modid")`. The Mod ID must precisely match the ID declared in `neoforge.mods.toml` and MUST be entirely lowercase with no special characters.
+- **Event Registration Distinction**: The `@EventBusSubscriber` annotation MUST be used on classes to automatically register static event handlers (`@SubscribeEvent`) without manual bus registration. However, if instance-level state is required, the class MUST NOT use `@EventBusSubscriber` and instead manually register the instance using `NeoForge.EVENT_BUS.register(this)` and use `@SubscribeEvent` on non-static methods.
+- **DeferredRegister Mandate**: All registry objects (Blocks, Items, Entities, MenuTypes) MUST be registered using the `DeferredRegister` pattern. Direct registration during mod initialization is prohibited as it causes race conditions with NeoForge's internal registry phases.
+- **Event Bus Targeting**: Modders MUST explicitly target the correct event bus. Lifecycle events (setup, registry) belong on the Mod bus (`@EventBusSubscriber(bus = Bus.MOD)`). Gameplay events (tick, interaction) belong on the Forge bus (`@EventBusSubscriber(bus = Bus.FORGE)`).
+- **Client Code Isolation**: Server code MUST NEVER reference client-only classes. Client-specific event handlers MUST specify `value = Dist.CLIENT` in the `@EventBusSubscriber` annotation to ensure they are not loaded on dedicated servers.
+- **Capability System**: The application MUST use the `ICapabilityProvider` registration patterns and NeoForge's attachment system to attach custom data to entities or chunks, rather than relying on mixins or hash maps.
+- **Mixin Configuration**: Mixins are allowed but MUST be explicitly declared via the `@MixinConfig` property in the `neoforge.mods.toml` file.
+- **No Fabric API**: The mod MUST NOT use Fabric API. If cross-loader support is required, the mod MUST use FFAPI or the Sinytra Connector pattern.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in NeoForge mod development. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent silent event failures and registry crashes.
+
+#### AP-NEOFORGE-01: Incorrect Event Bus Target
+**What it is**: Registering an event handler to the wrong bus, causing the event to never fire.
+**Detection signal**: Annotating a `PlayerTickEvent` handler with `@EventBusSubscriber(bus = Bus.MOD)`.
+**Consequence**: The event handler is completely ignored by the game engine, resulting in silent feature failure.
+**Correct alternative**: Use `bus = Bus.FORGE` for runtime/gameplay events, and `bus = Bus.MOD` for initialization/registry events.
+
+#### AP-NEOFORGE-02: Eager Registry Instantiation
+**What it is**: Instantiating a Block or Item as a static final field outside of the `DeferredRegister` framework.
+**Detection signal**: `public static final Block MY_BLOCK = new Block(...)` declared at the class level without a `DeferredRegister` wrapper.
+**Consequence**: The item is instantiated before the game's registry is ready, leading to crashes or missing items in-game.
+**Correct alternative**: Wrap the instantiation in a `DeferredRegister.create()` call and register it via `register(name, () -> new Block(...))`.
+
+#### AP-NEOFORGE-03: Missing Mixin Declaration
+**What it is**: Adding a Mixin to the project but failing to declare it in the mod's configuration file.
+**Detection signal**: A `mixins.json` file exists and is populated, but `neoforge.mods.toml` lacks the necessary configuration linking to it.
+**Consequence**: The mixins silently fail to apply at runtime.
+**Correct alternative**: Add `[[mixins]]` and `config="modid.mixins.json"` to the `neoforge.mods.toml` file.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a NeoForge mod. Failure to check these items may result in catastrophic compatibility issues, registry deadlocks, or broken event loops.
+- [ ] Version constraints (NeoForge, Gradle, Java) strictly match the target MC version.
+- [ ] Dependency version ranges in `neoforge.mods.toml` are correctly formatted (e.g., `[21.0,22)`).
+- [ ] All Blocks, Items, and Entities use the `DeferredRegister` pattern.
+- [ ] Event handlers explicitly define the correct bus (`MOD` vs `FORGE`).
+- [ ] Client-only event subscribers use `value = Dist.CLIENT`.
+- [ ] Mixin configs are properly declared in `neoforge.mods.toml`.
+- [ ] No Fabric API classes are imported.
+- [ ] `@Mod` annotation exactly matches the ID in `neoforge.mods.toml`.
+
+## 5. Useful References
+The following resources provide authoritative guidance on developing resilient Minecraft mods using the NeoForge toolchain. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding event buses, data attachments, or registries. Referencing these guides ensures the mod correctly utilizes modern NeoForge capabilities.
+- [NeoForge Documentation: Concepts](https://docs.neoforged.net/docs/concepts/): Fundamental concepts outlining the mod initialization lifecycle.
+- [NeoForge DeferredRegister](https://docs.neoforged.net/docs/concepts/registries/): Standard patterns for declaring blocks, items, and block entities.
+- [NeoForge Event System](https://docs.neoforged.net/docs/concepts/events/): Detailed documentation on the differences between the Mod bus and Forge bus.
+- [SpongePowered Mixin Documentation](https://github.com/SpongePowered/Mixin/wiki): The official reference for mixin configurations and annotations.

package/resources/stacks/web-backend-java-spring.md

@@ -0,0 +1,58 @@
+# Stack Pack: Java Spring Boot Backend
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for Spring Boot and Java backend applications. An auditor MUST verify that `pom.xml` or `build.gradle` files comply with these ranges to prevent runtime failures and dependency conflicts. Enforcing these versions ensures the application benefits from modern Jakarta EE namespaces and security features.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| Java | 17 (21 recommended) | None | Java < 17 |
+| Spring Boot | 3.0.0 | Jakarta EE 10+ | javax.* namespaces |
+| Spring Security | 6.0.0 | Spring Boot 3+ | WebSecurityConfigurerAdapter (deprecated) |
+
+## 2. Architecture Rules
+These rules define the structural boundaries of a Spring Boot backend. The codebase MUST adhere strictly to these constraints to ensure proper transaction management, security, and separation of concerns. Violations of these rules directly lead to security vulnerabilities and unstable transaction lifecycles.
+
+- **Transactional Boundaries**: The `@Transactional` annotation MUST only be applied at the Service layer. It MUST NOT be applied at the Controller layer (which handles HTTP) or the Repository layer (which handles individual queries), ensuring transactions wrap entire business operations.
+- **DTO ↔ Entity Mapping**: Entities MUST NOT leak into the Controller layer. The Service layer MUST map Entities to Data Transfer Objects (DTOs) before returning data to the Controller, preventing over-posting attacks and accidental data exposure.
+- **Spring Security Filter Chain**: The `SecurityFilterChain` bean MUST be ordered correctly. Public endpoints MUST be explicitly permitted (`permitAll()`), and all other endpoints MUST require authentication (`anyRequest().authenticated()`).
+- **Authorization Annotations**: Prefer `@PreAuthorize` over `@Secured` for method-level security, as `@PreAuthorize` supports Spring Expression Language (SpEL) for complex rules (e.g., `@PreAuthorize("hasRole('ADMIN') or #userId == authentication.principal.id")`).
+- **Exception Handling**: The application MUST use a `@ControllerAdvice` or `@RestControllerAdvice` class to handle exceptions globally. Controllers MUST NOT contain excessive `try-catch` blocks returning raw `ResponseEntity` objects.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in Spring Boot applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent database performance collapse and runtime null pointer exceptions.
+
+#### AP-SPRING-01: JPA N+1 Query Problem
+**What it is**: Fetching a list of entities and then lazily loading a related entity for each item in the list, resulting in $N+1$ database queries instead of 1.
+**Detection signal**: A `@OneToMany` or `@ManyToMany` relationship without a `fetch = FetchType.LAZY` default, combined with accessing the collection in a loop, or omitting `@BatchSize` or `JOIN FETCH` in the JPQL query.
+**Consequence**: Severe database performance degradation under load as one API call triggers hundreds of queries.
+**Correct alternative**: Use `JOIN FETCH` in JPQL queries, configure `@BatchSize` on collections, or use EntityGraphs to fetch related data in a single query.
+
+#### AP-SPRING-02: Returning Null from Repositories
+**What it is**: A repository method or service returning a raw `null` value when an entity is not found, forcing the caller to perform null checks.
+**Detection signal**: A method signature like `User findByEmail(String email)` returning `null` if the user does not exist.
+**Consequence**: High risk of `NullPointerException` (NPE) in downstream logic if a null check is missed.
+**Correct alternative**: Return `Optional<User>` from the repository and use functional methods like `.orElseThrow()` in the service layer.
+
+#### AP-SPRING-03: Singleton Bean Scope Misuse
+**What it is**: Injecting stateful, request-scoped data into a default Singleton-scoped Spring bean.
+**Detection signal**: A `@Service` or `@Component` class containing mutable instance variables (e.g., `private User currentUser;`) that are modified during a request.
+**Consequence**: Severe race conditions and cross-user data leakage, as the same bean instance is shared across all concurrent HTTP threads.
+**Correct alternative**: Keep singleton beans stateless. If state is required, inject the state via method parameters or use `@RequestScope` for the bean.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Spring Boot codebase. Failure to check these items may result in broken transaction boundaries, security vulnerabilities, or severe database performance degradation.
+- [ ] `@Transactional` is used exclusively on Service layer classes or methods.
+- [ ] Controllers accept and return DTOs, not database Entities.
+- [ ] `SecurityFilterChain` explicitly configures `permitAll()` for public routes and requires authentication for everything else.
+- [ ] `@PreAuthorize` is used for method-level security instead of `@Secured`.
+- [ ] `@OneToMany` and `@ManyToMany` relationships are audited for N+1 vulnerabilities (using `JOIN FETCH` or `@BatchSize`).
+- [ ] Repositories return `Optional<T>` for single-entity queries.
+- [ ] Global exception handling is implemented via `@RestControllerAdvice`.
+- [ ] Singleton beans (`@Service`, `@Component`) have no mutable instance variables.
+
+## 5. Useful References
+The following resources provide authoritative guidance on building scalable and secure applications with Java and Spring Boot. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions, particularly involving JPA performance or Spring Security filter chains. Reviewing these links regularly ensures that the application remains aligned with modern Spring ecosystem practices.
+- [Spring Boot Reference Documentation](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/): The primary source of truth for configuration and auto-configuration details.
+- [Spring Security Architecture](https://spring.io/guides/topicals/spring-security-architecture): In-depth guide on the security filter chain and authentication providers.
+- [Hibernate N+1 Problem](https://vladmihalcea.com/n-plus-1-query-problem/): Detailed explanation of how to detect and resolve N+1 queries using `JOIN FETCH` and `@BatchSize`.
+- [Spring Data JPA Documentation](https://docs.spring.io/spring-data/jpa/reference/): Authoritative guide on repository patterns, projections, and entity lifecycle.

package/resources/stacks/web-backend-python-ai.md

@@ -0,0 +1,62 @@
+# Stack Pack: Python AI & RAG Backend
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for Python backend applications focused on AI and RAG (Retrieval-Augmented Generation). An auditor MUST verify that `requirements.txt` or `pyproject.toml` files comply with these dependencies to prevent runtime errors and integration failures. Pinning these framework versions is critical because AI libraries frequently introduce breaking changes without major version bumps.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| Python | 3.10 | None | Python < 3.10 |
+| FastAPI | 0.100.0 | `pydantic >= 2.0`, `uvicorn` | Pydantic v1 |
+| LangChain | Pinned exact | Dependent on specific integrations | Unpinned versions |
+| LlamaIndex | Pinned exact | Dependent on specific integrations | Unpinned versions |
+
+## 2. Architecture Rules
+These rules define the structural boundaries and hygiene of an AI-powered Python backend. The codebase MUST adhere strictly to these constraints to ensure API stability, correct embeddings, and reliable execution. Failure to follow these rules will result in blocked event loops, mismatched vector dimensions, and leaked API keys.
+
+- **Dependency Pinning**: AI framework libraries (LangChain, LlamaIndex, OpenAI SDK) evolve rapidly with breaking changes. The application MUST pin these dependencies to exact versions (e.g., `langchain==0.1.0`) rather than using loose bounds (`>=`).
+- **Environment Variable Management**: The application MUST NOT hardcode API keys or secrets in source code. The application MUST use `pydantic-settings` to load, validate, and type-check environment variables at startup.
+- **Type Annotation Completeness**: All functions and methods MUST have complete type hints for arguments and return types. The use of a bare `Any` type in production code is prohibited unless dealing with strictly unstructured external JSON.
+- **Pydantic v2 Constraints**: The application MUST use `model_validator` or `field_validator` for complex validation logic, utilizing Pydantic v2 paradigms.
+- **RAG Pipeline Hygiene**: 
+  - The embedding model version MUST be pinned (e.g., `text-embedding-3-small`), as changing the model breaks compatibility with existing vector stores.
+  - The chunking strategy (e.g., chunk size and overlap) MUST be documented in the code near the initialization of the text splitter.
+  - The application MUST enforce a maximum token budget per chunk to prevent exceeding the LLM's context window during retrieval.
+  - Vector store index consistency MUST be maintained: the dimension size of the embedding model MUST exactly match the index dimension in the vector database.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in Python AI applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent blocked web servers and corrupt vector databases.
+
+#### AP-PYAI-01: Blocking the Async Event Loop
+**What it is**: Executing synchronous, long-running CPU or I/O operations directly within an `async def` FastAPI route.
+**Detection signal**: Use of `requests.get()`, `time.sleep()`, or synchronous database calls inside a route defined with `async def`.
+**Consequence**: The ASGI server (e.g., Uvicorn) event loop is blocked, causing the server to hang and fail to process concurrent requests.
+**Correct alternative**: Run blocking operations in a thread pool using `asyncio.get_running_loop().run_in_executor()`, or define the FastAPI route as a standard synchronous `def`.
+
+#### AP-PYAI-02: Missing Embedding Dimension Checks
+**What it is**: Initializing a vector database client without verifying that the configured embedding dimensions match the model being used.
+**Detection signal**: A Pinecone or Qdrant index is initialized using a hardcoded dimension size that is completely detached from the embedding model's configuration.
+**Consequence**: Upserting vectors will silently fail or crash at runtime because the vector size generated by the model (e.g., 1536) does not match the database index size (e.g., 384).
+**Correct alternative**: Abstract the embedding configuration into a single source of truth that configures both the model and the index initialization.
+
+#### AP-PYAI-03: Hardcoded API Keys
+**What it is**: Instantiating AI clients with string literals containing actual API keys.
+**Detection signal**: `client = OpenAI(api_key="sk-...")` found in source code.
+**Consequence**: Critical security vulnerability if the code is committed to version control.
+**Correct alternative**: Rely on environment variables and validate them at startup using a `pydantic_settings.BaseSettings` class.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Python AI codebase. Failure to check these items may result in unresponsive endpoints, security vulnerabilities, or silent data corruption in vector stores.
+- [ ] No synchronous blocking calls exist inside `async def` routes without thread pool execution.
+- [ ] AI framework dependencies (LangChain, LlamaIndex) are pinned to exact versions.
+- [ ] No API keys are hardcoded in the codebase.
+- [ ] Environment variables are managed using `pydantic-settings`.
+- [ ] Pydantic v2 `model_validator` and `field_validator` are used instead of legacy v1 validators.
+- [ ] Embedding model versions are explicitly declared and pinned.
+- [ ] All functions and methods contain complete type annotations without bare `Any`.
+
+## 5. Useful References
+The following resources provide authoritative guidance on building robust and asynchronous AI applications in Python. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding FastAPI event loops or Pydantic validation. Ensuring the application adheres to these best practices prevents subtle bugs in high-traffic endpoints.
+- [FastAPI: Concurrency and async / await](https://fastapi.tiangolo.com/async/): Detailed explanation of when to use `def` vs `async def` for route handlers.
+- [Pydantic V2 Migration Guide](https://docs.pydantic.dev/latest/migration/): Documentation on the syntax and performance improvements of Pydantic V2 over V1.
+- [LangChain Documentation](https://python.langchain.com/docs/get_started/introduction): The official guide for LangChain concepts and integrations.
+- [OpenAI API Reference](https://platform.openai.com/docs/api-reference): Official documentation for the OpenAI SDK, including error handling and retry mechanisms.

package/resources/stacks/web-backend-rust.md

@@ -0,0 +1,57 @@
+# Stack Pack: Rust Backend
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for Rust backend applications. An auditor MUST verify that `Cargo.toml` files comply with these versions to prevent compilation failures and dependency conflicts. Keeping the Rust toolchain updated is essential for benefiting from the latest safety features and borrow checker improvements.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| Rust (Edition) | 2021 | None | Pre-2018 editions |
+| Tokio | 1.0.0 | `features = ["full"]` for servers | Sync-only runtimes |
+| Axum (or Actix) | 0.7.0 | `tokio` | Synchronous blocking code |
+
+## 2. Architecture Rules
+These rules define the structural boundaries and memory patterns of a Rust backend. The codebase MUST adhere strictly to these constraints to ensure memory safety, concurrency, and maximum performance. Violating these constraints often results in deadlocks, memory churn, or blocked executors.
+
+- **Error Type Discipline**: The application MUST differentiate between library errors and application errors. Use the `thiserror` crate for defining domain/library-level error enums, and use the `anyhow` crate for application-level error handling (e.g., in `main()` or generic request handlers where the exact error type is opaque).
+- **No Panics in Production**: The application MUST NOT use `.unwrap()` or `.expect()` in request handling paths or business logic. All `Result` and `Option` types MUST be propagated using the `?` operator or handled explicitly via `match`.
+- **Concurrent State Management**: For shared mutable state, the application MUST prefer `DashMap` (from the `dashmap` crate) over `Arc<Mutex<HashMap>>` for high-concurrency maps, as `DashMap` shards the locks and prevents global bottlenecks. For simple values, `Arc<RwLock<T>>` is preferred over `Mutex` if reads vastly outnumber writes.
+- **Connection Pool Sizing**: Database connections (e.g., using `sqlx`) MUST use a connection pool (like `PgPool`). The pool's `max_connections` MUST be explicitly configured based on the expected worker thread count and database limits.
+- **WASM Compilation Constraints**: If the Rust application is intended to be compiled to WebAssembly (e.g., using `wasm-bindgen`), the codebase MUST NOT rely on standard library features that are unavailable in the `wasm32-unknown-unknown` target, such as `std::fs`, `std::thread`, or blocking network sockets. All async operations must be compatible with the WASM event loop.
+
+## 3. Common Anti-Patterns
+The following anti-patterns highlight the most common architectural mistakes made in asynchronous Rust applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent thread starvation and memory leaks.
+
+#### AP-RUST-01: Blocking the Async Runtime
+**What it is**: Executing long-running, CPU-bound, or synchronous I/O operations directly inside an `async fn` running on the Tokio runtime.
+**Detection signal**: Use of `std::fs`, `std::thread::sleep`, heavy cryptographic hashing, or synchronous database clients (like `diesel` without `async` features) inside an `async` function.
+**Consequence**: The async executor thread is blocked, preventing other async tasks from running. Under load, this causes the entire web server to stall and drop requests.
+**Correct alternative**: Wrap blocking operations in `tokio::task::spawn_blocking(move || { ... })`.
+
+#### AP-RUST-02: Unnecessary Memory Allocations
+**What it is**: Repeatedly allocating heap memory (e.g., cloning `String` or `Vec`) in hot request paths when a reference or a zero-copy type could be used.
+**Detection signal**: Extensive use of `.clone()`, `.to_string()`, or passing large structs by value in request handlers instead of borrowing (`&T`).
+**Consequence**: High memory churn and CPU overhead from the allocator, severely reducing the maximum requests-per-second (RPS) the server can handle.
+**Correct alternative**: Pass by reference where possible, use `Arc<T>` for shared read-only data to make cloning cheap, and use `Cow<'a, str>` for copy-on-write strings.
+
+#### AP-RUST-03: Blindly Using Mutexes
+**What it is**: Wrapping large, frequently accessed data structures in `std::sync::Mutex` or `tokio::sync::Mutex` without analyzing the contention.
+**Detection signal**: `Arc<Mutex<AppState>>` where `AppState` is read by every request but modified rarely.
+**Consequence**: Lock contention becomes the primary performance bottleneck, essentially forcing concurrent requests to execute sequentially.
+**Correct alternative**: Use `tokio::sync::RwLock` for read-heavy workloads, or channel-based actor models for complex state mutations.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Rust backend codebase. Failure to check these items may result in thread starvation, panics at runtime, or severe performance bottlenecks under load.
+- [ ] No `std::fs` or heavy CPU-bound tasks execute directly in an `async fn` without `spawn_blocking`.
+- [ ] No `.unwrap()` or `.expect()` calls exist outside of tests or application startup code.
+- [ ] `thiserror` is used for domain error enums, and `anyhow` is used for generic propagation.
+- [ ] High-concurrency hash maps use `DashMap` rather than `Arc<Mutex<HashMap>>`.
+- [ ] Database interactions use a properly configured connection pool.
+- [ ] Large structs are passed by reference or wrapped in `Arc` rather than cloned in hot paths.
+- [ ] Any WASM targets do not use `std::thread` or `std::fs` modules.
+
+## 5. Useful References
+The following resources provide authoritative guidance on building highly concurrent, safe backend systems in Rust. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions regarding the Tokio runtime, error handling, or memory management. Staying updated with these resources is critical to avoiding subtle deadlocks and concurrency bugs.
+- [Tokio: CPU-bound tasks and blocking code](https://tokio.rs/tokio/tutorial/spawning#cpu-bound-tasks-and-blocking-code): Explains how to properly bridge synchronous and asynchronous code.
+- [Rust API Guidelines: Error Handling](https://rust-lang.github.io/api-guidelines/interoperability.html): Best practices for designing error enums and using the `?` operator.
+- [Axum Documentation](https://docs.rs/axum/latest/axum/): Comprehensive guide to routing, middleware, and request extraction in the Axum framework.
+- [Rust Atomics and Locks](https://marabos.nl/atomics/): In-depth exploration of concurrency primitives and lock contention mitigation in Rust.

package/resources/stacks/web-nextjs-turborepo.md

@@ -0,0 +1,65 @@
+# Stack Pack: Next.js + Turborepo
+
+## 1. Version Constraint Matrix
+This section defines the supported versions and compatibility requirements for Next.js, React, and Turborepo. An auditor MUST verify that all `package.json` files within the monorepo strictly comply with these ranges to prevent build failures and hydration mismatches. Ensuring that all workspaces share the same React version is critical for monorepo stability.
+
+| Technology | Minimum Version | Required Dependencies | Incompatible With |
+|---|---|---|---|
+| Next.js | 14.0.0 | React 18+, Node.js 18.17+ | React < 18 |
+| Turborepo | 1.11.0 | `turbo.json` config | Workspaces without explicit boundaries |
+| TypeScript | 5.0.0 | `@types/react`, `@types/node` | `strict: false` in `tsconfig.json` |
+
+## 2. Architecture Rules
+These rules define the structural boundaries of a Next.js App Router application within a Turborepo monorepo. The codebase MUST adhere strictly to these constraints to ensure correct hydration, rendering, and package isolation. Adhering to these rules prevents silent failures during static site generation and edge deployments.
+
+- **App Router Exclusivity**: The application MUST exclusively use the App Router (`app/` directory). The Pages Router (`pages/`) MUST NOT be used alongside the App Router to prevent duplicate rendering paths and context confusion.
+- **Turborepo Boundaries**: Code inside the `packages/` directory MUST NOT import anything from the `apps/` directory. Packages are independent libraries; apps consume packages, never the reverse.
+- **Server and Client Directives**: Server components MUST NOT import browser-only APIs (`window`) or React hooks (`useState`). Client components MUST include the `'use client'` directive at the top. The `'use server'` directive MUST only be used at the top of a file containing server actions or inside an async function intended to be a server action; it MUST NOT be used as a general marker for server-side components.
+- **TypeScript Strictness**: All `tsconfig.json` files MUST have `"strict": true` enabled. Use of `any` types in production code is prohibited.
+- **Image Optimization**: The application MUST use `next/image` (`<Image />`) for all static and external images. Raw HTML `<img>` tags MUST NOT be used unless explicitly required for SVG svgr rendering or external embeds where `next/image` is unsupported.
+
+## 3. Common Anti-Patterns
+The following anti-patterns represent the most frequent sources of performance degradation and architectural debt in Next.js applications. Auditors MUST actively scan the codebase for these specific scenarios during the S2 and S8 phases to prevent them from reaching production.
+
+#### AP-NEXT-01: Improper Mixing of Server and Client Code
+**What it is**: Passing a Server Component as a direct import into a Client Component instead of passing it as a `children` prop.
+**Detection signal**: A file with `'use client'` at the top imports a component that performs server-side data fetching or uses Node.js APIs (like `fs`).
+**Consequence**: The server component is forced to render on the client, exposing server-side code to the browser and increasing bundle size, or causing a runtime crash.
+**Correct alternative**: Pass the server component as a React child: `<ClientWrapper><ServerComponent /></ClientWrapper>`.
+
+#### AP-NEXT-02: Dynamic Routes Without Static Params
+**What it is**: Creating dynamic routes (e.g., `[id]/page.tsx`) in a statically exported or highly cached site without providing `generateStaticParams`.
+**Detection signal**: A dynamic route file `app/[slug]/page.tsx` exists, but there is no exported `generateStaticParams` function in that file.
+**Consequence**: Next.js must render these pages on-demand at runtime, causing slow TTFB (Time to First Byte) and missing out on edge CDN caching.
+**Correct alternative**: Export an async `generateStaticParams` function that returns an array of route parameters.
+
+#### AP-NEXT-03: Heavy Third-Party Imports
+**What it is**: Importing large, monolithic libraries (like `lodash` or `moment`) entirely into client bundles instead of using lighter alternatives or modular imports.
+**Detection signal**: `import _ from 'lodash'` instead of `import get from 'lodash/get'`, or importing `moment` instead of `date-fns`.
+**Consequence**: The client bundle size swells unnecessarily, leading to slow page loads and poor Core Web Vitals.
+**Correct alternative**: Use modular imports (`lodash/get`), switch to modern lighter libraries (`date-fns`), or rely on native JavaScript APIs.
+
+#### AP-NEXT-04: Broad Middleware Matchers
+**What it is**: Configuring the Next.js middleware `matcher` array too broadly (e.g., matching all routes) without excluding static files or images.
+**Detection signal**: A `middleware.ts` file contains a `matcher` config like `matcher: ['/:path*']` without negative lookaheads for `_next/static`, `_next/image`, and `favicon.ico`.
+**Consequence**: The middleware executes on every static asset request, heavily degrading performance and increasing server costs.
+**Correct alternative**: Use negative lookaheads in the matcher regex: `matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)']`.
+
+## 4. Audit Checklist
+An auditor MUST verify the following items when reviewing a Next.js + Turborepo codebase. Failure to check these items may result in severe performance issues, architectural violations, or broken builds.
+- [ ] No files exist in a `pages/` directory if `app/` is being used for routing.
+- [ ] No `packages/` workspace imports anything from an `apps/` workspace.
+- [ ] `'use client'` is only used at the leaves of the component tree, not at the root layout.
+- [ ] `'use server'` is only used for server actions, not as a component marker.
+- [ ] `generateStaticParams` is implemented for dynamic routes where applicable.
+- [ ] Middleware `matcher` configuration explicitly excludes static assets.
+- [ ] All images use `next/image` rather than `<img>`.
+- [ ] `tsconfig.json` has `"strict": true`.
+
+## 5. Useful References
+The following resources provide authoritative guidance on building scalable applications with Next.js and Turborepo. Agents and developers MUST consult these documents when encountering ambiguous architectural decisions or when configuring advanced build caching features. Keeping up to date with these official resources ensures that the codebase does not adopt deprecated patterns or community-driven workarounds that are no longer necessary.
+- [Next.js App Router Documentation](https://nextjs.org/docs/app): The primary source of truth for App Router paradigms, routing, and data fetching.
+- [Turborepo Documentation](https://turbo.build/repo/docs): Guidelines for monorepo boundary configuration, caching, and task orchestration.
+- [Next.js Middleware Constraints](https://nextjs.org/docs/app/building-your-application/routing/middleware): Details on Edge Runtime limitations and matcher configurations.
+- [React Server Components](https://react.dev/reference/rsc/server-components): Understanding the mental model of RSCs and the serialization boundaries between server and client.
+- [Next.js Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations): Best practices for securing and executing mutations on the server.

package/resources/submit-template.md

@@ -0,0 +1,24 @@
+# Submission for Review
+### Task: [Task Description]
+
+## Context
+
+[Provide context about the changes being submitted. Why were they made? What do they affect?]
+
+## Git Diff / Plan Content
+
+[Embed the raw Git diff or the content of the plan being submitted.]
+```diff
+- Old code
++ New code
+```
+[The diff above represents the complete scope of changes for this task. The reviewer MUST check these lines for anti-patterns.]
+
+## Self-Review Checklist
+
+[The submitting agent MUST complete this checklist before requesting review.]
+[Every box MUST be checked; otherwise, the submission is invalid.]
+- [ ] I have verified this change does not violate the architecture.
+- [ ] I have run the test suite and all tests pass.
+- [ ] I have checked for any banned anti-patterns.
+- [ ] I have verified there are no TODO/FIXME or simulation/mock implementations in this code.

package/resources/task-template.md

@@ -0,0 +1,8 @@
+# Task Tracker
+
+This file tracks the execution progress of the tasks defined in the implementation plan.
+The agent MUST update this file incrementally as each step is completed.
+
+- `[ ]` [Uncompleted task]
+- `[/]` [In-progress task]
+- `[x]` [Completed task]