@ryuenn3123/agentic-senior-core 1.8.0

package/.agent-context/stacks/ruby.md

@@ -0,0 +1,80 @@
+# Ruby on Rails Engineering Standards
+
+> Rails provides "Convention over Configuration," but convention does not mean "put all your business logic in ActiveRecord callbacks."
+
+## Core Tenets
+1. **Skinny Models, Skinny Controllers, Fat Services:** The default Rails MVC is insufficient for complex domains. Extract business logic into Service Objects (Interactors).
+2. **Death to N+1 Queries:** The `bullet` gem is mandatory in development and test environments. Any N+1 query is a blocker.
+3. **No Hidden Magic:** Avoid deeply nested or complex ActiveRecord callbacks (`before_save`, `after_commit`). They obscure the flow of data. If an action has side effects, orchestrate it in a Service Object.
+4. **Strong Parameters Only:** Never trust user input. Always permit explicit parameters in the controller layer before passing data down.
+
+## Architecture & Layering (The Service Object Pattern)
+Default Rails couples the HTTP request cycle tightly to the Database via the Model. We break this.
+
+### 1. Controllers (Transport Layer)
+- **Role:** Handle HTTP requests, parse parameters (Strong Params), authenticate/authorize the user, call the Service Object, and return the HTTP response/JSON.
+- **BANNED:** Calling `Model.create()`, `Model.update()`, or writing any business calculations in the controller.
+- **ALLOWED:** `MyService.call(params)`
+
+### 2. Service Objects (Application Layer)
+- **Role:** The orchestrator. Located in `app/services/`.
+- **Structure:** Usually plain Ruby objects (POROs) with a single public `call` method.
+- **Responsibility:** Executes the business transaction, handling database operations, sending emails, or enqueuing background jobs.
+
+### 3. Models (Domain & Persistence Layer)
+- **Role:** ActiveRecord models should only contain associations (`belongs_to`, `has_many`), scopes, and simple data validations (e.g., `validates :email, presence: true`).
+- **BANNED:** Complex business logic, sending emails, API calls to third parties.
+
+## Ecosystem & Dependencies (March 2026)
+- **API Mode:** Use `rails new my_api --api` for backend-only projects.
+- **Background Jobs:** `sidekiq` is the standard. Default `ActiveJob` should map to a Sidekiq backend (powered by Redis).
+- **Authentication/Authorization:** `devise` (if needed, though often overkill for raw APIs; consider `jwt` + custom auth) and `pundit` (mandatory for authorization). Avoid `cancancan`.
+- **Testing:** `rspec-rails` and `factory_bot_rails`. Default `minitest` and `fixtures` are explicitly banned for Agentic-Senior-Core projects.
+- **Linting:** `rubocop` is mandatory. The build must fail if RuboCop fails.
+
+## Anti-Patterns (Zero Tolerance)
+
+### 1. The Fat Model Callback Hell
+```ruby
+# ❌ BANNED: The model side-effect
+class User < ApplicationRecord
+  after_create :send_welcome_email
+
+  def send_welcome_email
+    UserMailer.welcome(self).deliver_now
+  end
+end
+
+# ✅ REQUIRED: The Service Object Orchestrator
+class Users::CreateService
+  def self.call(params)
+    user = User.new(params)
+    if user.save
+      UserMailer.welcome(user).deliver_later
+    end
+    user
+  end
+end
+```
+
+### 2. N+1 Queries in Responses
+```ruby
+# ❌ BANNED: Will execute 101 queries for 100 posts
+def index
+  @posts = Post.all
+  render json: @posts.map { |p| { title: p.title, author: p.author.name } }
+end
+
+# ✅ REQUIRED: Eager loading
+def index
+  @posts = Post.includes(:author).all
+  # ...
+end
+```
+
+### 3. Logic in Views/Serializers
+If using ActiveModelSerializers, Jbuilder, or Blueprinter, never perform database queries or heavy calculations in the serialization phase.
+
+## Background Jobs (Sidekiq)
+- **Rule:** Any operation taking longer than 300ms (e.g., sending an email, generating a PDF, calling an external API) **MUST** be pushed to a background job (`.deliver_later` or `MyWorker.perform_async`).
+- **Rule:** Background job parameters must be simple types (strings, integers, IDs). **NEVER** pass an ActiveRecord object directly to a Sidekiq worker (it might be stale when the job runs). Pass the `user_id` instead.

package/.agent-context/stacks/rust.md

@@ -0,0 +1,86 @@
+# Rust Engineering Standards
+
+> Rust guarantees memory safety, but not logic safety. Write code that is as predictable as the compiler.
+
+## Core Tenets
+1. **Never Panic:** The use of `unwrap()`, `expect()`, or `panic!()` in production business logic is strictly banned.
+2. **Make Invalid States Unrepresentable:** Use Rust's powerful type system (enums, newtypes) to enforce business rules at compile time.
+3. **Explicit Errors:** Use `Result` for all fallible operations.
+4. **Fearless Concurrency:** Leverage `Send` and `Sync`. Avoid shared mutable state; prefer message passing or structured concurrency.
+
+## Ecosystem & Dependencies (March 2026)
+Adhere to the `efficiency-vs-hype` rule. The Rust ecosystem is robust; use community standards:
+
+### Backend / API
+- **Web Framework:** `axum` (Standard for new projects, built on `tokio` and `tower`). Avoid `actix-web` and `rocket` for new microservices unless migrating legacy code.
+- **Async Runtime:** `tokio` (Standard).
+- **Serialization:** `serde` + `serde_json`.
+
+### Data / Persistence
+- **Database:** `sqlx` (preferred for compile-time checked SQL) or `sea-orm` (if an ORM is strictly required). Avoid `diesel` (unless explicitly requested).
+- **Connection Pooling:** Built into `sqlx` (use `PgPool`, etc.).
+
+### Validation / Error Handling / Observability
+- **Error Handling:** `thiserror` (for libraries and domain boundaries) and `anyhow` (for application/binaries and controllers).
+- **Validation:** `validator` crate.
+- **Telemetry/Logging:** `tracing` + `tracing-subscriber`. `log` and `env_logger` are legacy.
+
+## Architecture & Layering
+Strict Clean Architecture / Hexagonal Architecture.
+
+1. **Transport (`/api` or `/transport`)**
+   - Axum routers and handlers.
+   - Responsible for extracting JSON/Path data, verifying auth claims, and calling the Domain/Service layer.
+   - **MUST:** Return standard HTTP status codes mapping to domain errors.
+
+2. **Application / Service (`/services` or `/app`)**
+   - Orchestrates business logic, database transactions, and external API calls.
+   - **NO** HTTP knowledge (Axum types do not cross this boundary).
+
+3. **Domain (`/domain`)**
+   - Pure Rust logic. Structs, Enums, Traits.
+   - **Must not** know about the database (SQL) or HTTP. Use traits (interfaces) to define repository contracts.
+
+4. **Infrastructure / Repository (`/repo` or `/infra`)**
+   - `sqlx` queries go here. Implements the traits defined in Domain.
+
+## Anti-Patterns (Zero Tolerance)
+
+### 1. The `unwrap()` Fallacy
+```rust
+// ❌ BANNED: Will crash the server if parsing fails
+let user_id = id_string.parse::<i32>().unwrap();
+
+// ✅ REQUIRED: Explicit error mapping
+let user_id = id_string.parse::<i32>().map_err(AppError::InvalidId)?;
+```
+
+### 2. Stringly-Typed Domain
+```rust
+// ❌ BANNED: Passing raw strings everywhere
+fn update_email(user_id: String, email: String) {}
+
+// ✅ REQUIRED: Newtypes and validated types
+struct UserId(uuid::Uuid);
+struct Email(String); // Should be validated on creation
+
+fn update_email(user_id: UserId, email: Email) {}
+```
+
+### 3. Cloning to Appease the Borrow Checker
+```rust
+// ❌ POOR PRACTICE: Cloning just to make it compile instead of designing lifetimes/ownership
+let name = user.name.clone();
+process_name(name);
+
+// ✅ REQUIRED: Pass by reference (borrowing)
+process_name(&user.name);
+```
+
+### 4. Catch-all `anyhow::Error` in Traits
+Traits defining contracts between layers (like Repositories) should return explicit errors (`thiserror`), not `anyhow::Error`, so the caller can systematically handle specific failures (e.g., `NotFound`, `ConstraintViolation`).
+
+## Testing Standards
+- **Unit Tests:** Inside the same file as the code (`#[cfg(test)] mod tests { ... }`).
+- **Integration Tests:** In the `tests/` directory at the root level.
+- **Mocking:** Use `mockall` or manually implement traits for test doubles. Avoid testing against a real database in unit tests; use them in integration tests using `sqlx::test`.

package/.agent-context/stacks/typescript.md

@@ -0,0 +1,317 @@
+# TypeScript Stack Profile — The "Galak" Standard
+
+> TypeScript is not JavaScript with optional types.
+> It is a contract system. Use it like one.
+
+## Compiler Configuration (Non-Negotiable)
+
+### tsconfig.json Strict Settings
+```json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true,
+    "noUnusedLocals": true,
+    "noUnusedParameters": true,
+    "exactOptionalPropertyTypes": true,
+    "forceConsistentCasingInFileNames": true,
+    "isolatedModules": true,
+    "esModuleInterop": true,
+    "resolveJsonModule": true,
+    "moduleResolution": "bundler",
+    "module": "ESNext",
+    "target": "ES2022",
+    "skipLibCheck": true,
+    "paths": {
+      "@/*": ["./src/*"]
+    }
+  }
+}
+```
+
+**Rule:** `"strict": true` is mandatory. If a project has `"strict": false`, fix it before writing any new code.
+
+---
+
+## The `any` Ban (Zero Tolerance)
+
+### Rule: `any` is BANNED. No exceptions.
+
+```typescript
+// ❌ INSTANT REJECTION
+function processData(data: any) { ... }
+const result = response.json() as any;
+// @ts-ignore
+// @ts-expect-error — only allowed with a comment explaining WHY and a linked issue
+
+// ✅ REQUIRED: Use `unknown` with type narrowing
+function processData(data: unknown) {
+  const parsed = DataSchema.parse(data);  // Zod validates and narrows
+  // `parsed` is now fully typed
+}
+
+// ✅ REQUIRED: Use generics when the type varies
+function getFirstItem<T>(items: T[]): T | undefined {
+  return items[0];
+}
+```
+
+### What to Use Instead of `any`
+| Situation | Instead of `any`, Use |
+|-----------|----------------------|
+| Unknown external data | `unknown` + Zod parsing |
+| Generic container | `T` (generic type parameter) |
+| Object with unknown keys | `Record<string, unknown>` |
+| Function argument you'll refine | `unknown` + type guard |
+| Library with bad types | Write a `.d.ts` override or `unknown` wrapper |
+| Event handlers | The specific event type (`MouseEvent`, `ChangeEvent<HTMLInputElement>`) |
+
+---
+
+## Zod at Boundaries (Mandatory)
+
+### Rule: ALL External Data MUST Pass Through Zod
+
+```typescript
+// ❌ BANNED: Trusting external data
+app.post('/users', async (req, res) => {
+  const { name, email, age } = req.body;  // Could be anything!
+  await userService.create({ name, email, age });
+});
+
+// ✅ REQUIRED: Validate with Zod at the boundary
+import { z } from 'zod';
+
+const CreateUserSchema = z.object({
+  name: z.string().min(1).max(100).trim(),
+  email: z.string().email().toLowerCase(),
+  age: z.number().int().min(13).max(150),
+});
+
+type CreateUserDto = z.infer<typeof CreateUserSchema>;
+
+app.post('/users', async (req, res) => {
+  const parsed = CreateUserSchema.safeParse(req.body);
+  if (!parsed.success) {
+    return res.status(400).json({ errors: parsed.error.flatten() });
+  }
+  // `parsed.data` is fully typed and validated
+  await userService.create(parsed.data);
+});
+```
+
+### Where Zod is MANDATORY
+- API request bodies (POST, PUT, PATCH)
+- Query parameters and path parameters
+- WebSocket incoming messages
+- Queue/event payloads from external systems
+- Environment variables at startup
+- Third-party API responses (trust but verify)
+- File upload metadata
+
+### Zod Best Practices
+```typescript
+// ✅ Reuse schemas — define once, use everywhere
+// src/modules/user/user.schema.ts
+export const UserSchema = z.object({
+  id: z.string().uuid(),
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+  role: z.enum(['user', 'admin', 'moderator']),
+  createdAt: z.coerce.date(),
+});
+
+export const CreateUserSchema = UserSchema.omit({ id: true, createdAt: true });
+export const UpdateUserSchema = CreateUserSchema.partial();
+
+// Types derived from schemas — single source of truth
+export type User = z.infer<typeof UserSchema>;
+export type CreateUserDto = z.infer<typeof CreateUserSchema>;
+export type UpdateUserDto = z.infer<typeof UpdateUserSchema>;
+```
+
+---
+
+## API Documentation (Mandatory)
+
+### Rule: No API Endpoint Exists Without Documentation
+
+Every API endpoint MUST have corresponding documentation. When creating or modifying an endpoint, you MUST simultaneously update the API documentation.
+
+### Preferred Approach: OpenAPI (Swagger)
+
+```typescript
+// Option 1: Code-first with decorators (NestJS)
+@ApiOperation({ summary: 'Create a new user' })
+@ApiBody({ type: CreateUserDto })
+@ApiResponse({ status: 201, description: 'User created', type: UserResponseDto })
+@ApiResponse({ status: 400, description: 'Validation error' })
+@ApiResponse({ status: 409, description: 'Email already exists' })
+@Post()
+async createUser(@Body() dto: CreateUserDto): Promise<UserResponseDto> { ... }
+
+// Option 2: Schema-first with Zod + zod-to-openapi
+import { extendZodWithOpenApi } from '@asteasolutions/zod-to-openapi';
+extendZodWithOpenApi(z);
+
+const CreateUserSchema = z.object({
+  name: z.string().min(1).openapi({ example: 'John Doe' }),
+  email: z.string().email().openapi({ example: 'john@example.com' }),
+}).openapi('CreateUserRequest');
+```
+
+### Documentation Checklist (Per Endpoint)
+- [ ] HTTP method and path
+- [ ] Request body schema (with examples)
+- [ ] Query/path parameter descriptions
+- [ ] All possible response codes with schemas
+- [ ] Authentication requirements
+- [ ] Rate limiting information (if applicable)
+
+### Documentation Must Stay in Sync
+```
+❌ BANNED:
+// Endpoint accepts `role` field but docs don't mention it
+// Endpoint returns 422 but docs only show 400
+
+✅ REQUIRED:
+// When you change an endpoint → update the schema/docs in the SAME commit
+// Use code-first tools so docs are generated from the actual types
+```
+
+---
+
+## Import Style
+
+### Path Aliases (Required)
+```typescript
+// ❌ BANNED: Deep relative imports
+import { UserService } from '../../../modules/user/user.service';
+import { AppError } from '../../../../shared/errors/app-error';
+
+// ✅ REQUIRED: Path aliases
+import { UserService } from '@/modules/user/user.service';
+import { AppError } from '@/shared/errors/app-error';
+```
+
+### Import Order (Enforced by ESLint)
+```typescript
+// 1. Node built-ins
+import { readFile } from 'node:fs/promises';
+import { join } from 'node:path';
+
+// 2. External packages
+import { z } from 'zod';
+import { PrismaClient } from '@prisma/client';
+
+// 3. Internal modules (path aliases)
+import { UserService } from '@/modules/user/user.service';
+import { AppError } from '@/shared/errors/app-error';
+
+// 4. Relative imports (same module only)
+import { CreateUserDto } from './user.dto';
+import { UserRepository } from './user.repository';
+```
+
+---
+
+## Async Patterns
+
+### Rule: Prefer async/await Over Raw Promises
+```typescript
+// ❌ BANNED: Promise chain hell
+function getUser(id: string) {
+  return userRepo.findById(id)
+    .then(user => {
+      if (!user) throw new NotFoundError('User', id);
+      return orderRepo.findByUserId(user.id);
+    })
+    .then(orders => ({ ...user, orders }))
+    .catch(err => { throw err; });
+}
+
+// ✅ REQUIRED: Clean async/await
+async function getUser(id: string): Promise<UserWithOrders> {
+  const user = await userRepo.findById(id);
+  if (!user) throw new NotFoundError('User', id);
+
+  const orders = await orderRepo.findByUserId(user.id);
+  return { ...user, orders };
+}
+```
+
+### Parallel Execution
+```typescript
+// ❌ SLOW: Sequential when operations are independent
+const user = await getUser(id);
+const orders = await getOrders(id);
+const preferences = await getPreferences(id);
+
+// ✅ FAST: Parallel independent operations
+const [user, orders, preferences] = await Promise.all([
+  getUser(id),
+  getOrders(id),
+  getPreferences(id),
+]);
+```
+
+---
+
+## Enum and Union Types
+
+### Prefer `as const` Unions Over Enums
+```typescript
+// ⚠️ ACCEPTABLE but verbose:
+enum OrderStatus {
+  PENDING = 'pending',
+  CONFIRMED = 'confirmed',
+  SHIPPED = 'shipped',
+  DELIVERED = 'delivered',
+}
+
+// ✅ PREFERRED: const assertion + union type
+const ORDER_STATUSES = ['pending', 'confirmed', 'shipped', 'delivered'] as const;
+type OrderStatus = (typeof ORDER_STATUSES)[number];
+// OrderStatus = 'pending' | 'confirmed' | 'shipped' | 'delivered'
+
+// Works perfectly with Zod:
+const OrderStatusSchema = z.enum(ORDER_STATUSES);
+```
+
+---
+
+## Preferred Libraries (V1.0 — 2025)
+
+| Need | Library | Why |
+|------|---------|-----|
+| Runtime | Bun / Node 20+ | ESM native, fast, batteries-included |
+| Validation | `zod` | 0 deps, type inference, composable |
+| ORM | `prisma` or `drizzle-orm` | Type-safe queries, migration support |
+| HTTP framework | `hono` / `fastify` / Next.js | Lightweight, modern, tree-shakeable |
+| Testing | `vitest` | Vite-native, Jest-compatible API, fast |
+| Linting | `eslint` + `@typescript-eslint` | Community standard |
+| Formatting | `prettier` | Community standard |
+| Date | `date-fns` or `Temporal` (when stable) | Tree-shakeable, immutable |
+| HTTP client | `ky` / `ofetch` / built-in `fetch` | Lightweight, modern |
+| Password | `bcrypt` / `argon2` | Proven, secure |
+| Logger | `pino` | Fastest JSON logger for Node.js |
+| Env | `@t3-oss/env-core` + Zod | Type-safe env validation |
+
+---
+
+## Banned Patterns
+
+| Pattern | Why | Alternative |
+|---------|-----|-------------|
+| `any` type | Defeats TypeScript's purpose | `unknown` + narrowing |
+| `// @ts-ignore` | Hides real type errors | Fix the type or `@ts-expect-error` with comment |
+| `var` keyword | Function scoping bugs | `const` (default) or `let` |
+| `==` loose equality | Type coercion surprises | `===` always |
+| `console.log` in production | Not structured, not configurable | Use `pino` or structured logger |
+| `new Date()` without timezone | Timezone bugs | Explicit UTC or use date-fns |
+| Default exports | Naming inconsistency across imports | Named exports only |
+| Barrel re-exports (`index.ts`) | Circular dependency magnets | Direct imports or module public API only |
+| `moment.js` | Deprecated, massive bundle | `date-fns` or `dayjs` |
+| `class` with inheritance (deep chains) | Fragile hierarchies | Composition + interfaces |

package/.agent-context/state/architecture-map.md

@@ -0,0 +1,25 @@
+# Architecture Map (State Awareness)
+
+> This file defines protected architectural boundaries for AI-assisted changes.
+
+## Boundary Classification
+
+| Module/Path Pattern | Criticality | Change Policy | Required Checks |
+|---------------------|-------------|---------------|-----------------|
+| `src/modules/payment/**` | critical | Must preserve transactional behavior and idempotency | Unit + integration + rollback test |
+| `src/modules/authentication/**` | critical | Never bypass auth guards or token validation | Security audit + integration tests |
+| `src/modules/**/repository/**` | high | Preserve query contracts and avoid N+1 regressions | Query plan review + performance audit |
+| `src/features/**` | medium | Keep UI contracts stable and avoid API drift | Component tests + contract checks |
+| `src/shared/**` | high | Backward compatibility required for public utilities | Cross-module usage validation |
+
+## Required Agent Behavior
+
+1. Before editing a `critical` area, load `.agent-context/review-checklists/security-audit.md` and `.agent-context/review-checklists/performance-audit.md`.
+2. For boundary-crossing changes, verify no circular dependencies are introduced (see `dependency-map.md`).
+3. Every critical-path change must include explicit risk notes in PR description.
+
+## Project-Specific Notes
+
+- Replace placeholder path patterns with your actual module map.
+- Mark payment, identity, and financial reconciliation flows as `critical`.
+- Keep this file updated whenever module ownership changes.

package/.agent-context/state/dependency-map.md

@@ -0,0 +1,32 @@
+# Dependency Map (State Awareness)
+
+> This map documents allowed dependency direction to prevent circular references during refactors.
+
+## Layer Dependency Rules
+
+1. Transport layer may depend on Service layer.
+2. Service layer may depend on Domain contracts and Repository interfaces.
+3. Infrastructure layer may implement Repository interfaces.
+4. Domain layer must not depend on Transport or Infrastructure.
+
+## Module-Level Constraints
+
+| Source Module | Allowed Dependencies | Forbidden Dependencies |
+|---------------|----------------------|------------------------|
+| `authentication` | `shared`, `user` | `payment` internals |
+| `payment` | `shared`, `billing`, `notification` contracts | `authentication` internals |
+| `reporting` | `shared`, read-only repository ports | write-side service internals |
+| `frontend` | public API clients only | direct repository access |
+
+## Circular Dependency Guardrail
+
+When refactoring:
+
+1. Detect import graph changes before applying bulk edits.
+2. Reject any change introducing `A -> B -> A` cycles.
+3. Move shared contracts to `shared` module when two-way dependencies appear.
+
+## Project-Specific Notes
+
+- Replace sample modules with your real domain modules.
+- Keep this map synchronized with architecture decisions and ADRs.

package/.agent-override.md

@@ -0,0 +1,36 @@
+# Rule Overrides
+
+> Exception file for enterprise needs.
+> Default policy: all rules remain strict unless explicitly overridden below.
+
+## Override Template
+
+Use this exact structure for every exception:
+
+```markdown
+[Rule: <rule-name>]
+Scope: <module/path>
+Reason: <business or technical constraint>
+Permitted Deviation: <what is allowed>
+Risk Mitigation: <how risk is controlled>
+Expiry: <YYYY-MM-DD>
+Owner: <team/person>
+```
+
+## Example Override
+
+```markdown
+[Rule: Naming]
+Scope: legacy-erp-sync module
+Reason: External DB schema uses snake_case columns and strict mapping contracts.
+Permitted Deviation: snake_case variable names are allowed only in mapper files.
+Risk Mitigation: enforce mapper-only scope with codeowners and lint ignore pattern.
+Expiry: 2026-12-31
+Owner: platform-integration-team
+```
+
+## Enforcement Notes
+
+1. Overrides must be narrow and time-bound.
+2. Expired overrides are invalid and must be removed.
+3. Broad overrides such as "allow any everywhere" are prohibited.

package/.agents/workflows/init-project.md

@@ -0,0 +1,29 @@
+---
+description: Initialize a new project using Agentic-Senior-Core blueprints and engineering standards
+---
+
+// turbo-all
+
+## Workflow: Initialize Project
+
+1. Read all rule files from `.agent-context/rules/` to understand engineering standards.
+
+2. Read the language-specific profile from `.agent-context/stacks/` based on the project's tech stack.
+
+3. Read the chosen blueprint from `.agent-context/blueprints/` (e.g., `api-nextjs.md` or `nestjs-logic.md`).
+
+4. Scaffold the complete project structure following the blueprint exactly:
+   - Create all directories and files
+   - Set up strict `tsconfig.json` (all flags from `stacks/typescript.md`)
+   - Create `.env.example` with placeholder values
+   - Set up Zod-validated environment config
+   - Set up error handling foundation (base error class + global handler)
+   - Set up structured logger (pino)
+   - Create a `/health` endpoint
+   - Initialize the ORM with initial schema
+
+5. Verify every file follows `rules/naming-conv.md` naming conventions.
+
+6. Verify the architecture follows `rules/architecture.md` layer separation.
+
+7. Run the PR checklist from `.agent-context/review-checklists/pr-checklist.md` as a final quality gate.

package/.agents/workflows/refactor.md

@@ -0,0 +1,29 @@
+---
+description: Refactor code or extract a module following architecture and naming rules
+---
+
+## Workflow: Refactor Code
+
+1. Read `.agent-context/rules/architecture.md` to understand the required layer separation.
+
+2. Read `.agent-context/rules/naming-conv.md` to understand naming standards.
+
+3. Read `.agent-context/rules/error-handling.md` to understand error handling patterns.
+
+4. Read the active language profile from `.agent-context/stacks/` (e.g., `typescript.md`).
+
+5. Analyze the target code for violations:
+   - Layer leaks (business logic in controllers, SQL in services)
+   - Naming violations (generic names, missing verb prefixes, missing boolean prefixes)
+   - Error handling issues (swallowed errors, generic Error types)
+   - Type safety issues (any types, unvalidated input)
+
+6. Apply refactoring while maintaining ALL existing functionality:
+   - Separate into proper layers if needed (controller/service/repository)
+   - Fix all naming violations
+   - Add Zod validation at boundaries if missing
+   - Replace generic errors with typed error classes
+
+7. For every change, provide a Reasoning Chain explaining what was wrong and why the new approach is better.
+
+8. Run `.agent-context/review-checklists/pr-checklist.md` as a final quality gate.

package/.agents/workflows/review-code.md

@@ -0,0 +1,29 @@
+---
+description: Run a comprehensive code review using PR checklist and security audit
+---
+
+## Workflow: Review Code
+
+1. Read `.agent-context/review-checklists/pr-checklist.md` and apply every item against the current codebase.
+
+2. Read `.agent-context/review-checklists/security-audit.md` and apply every item against the current codebase.
+
+3. For every violation found, provide a Reasoning Chain:
+   - State the exact file and line
+   - Reference the specific rule (file + section from `.agent-context/rules/`)
+   - Explain WHY it's a problem
+   - Provide the corrected code
+
+4. Output results in this format:
+
+```
+## PR REVIEW RESULTS
+- PASS or FAIL for each item
+- Reasoning Chain for each failure
+
+## SECURITY AUDIT RESULTS
+- Severity rating (CRITICAL / HIGH / MEDIUM / LOW) for each finding
+- Specific remediation for each finding
+
+## VERDICT: PASS or FAIL
+```