nurosys-agents 2.0.0

package/.agent/monolith/workflows/add-new-api-feature-module.md

@@ -0,0 +1,63 @@
+# Workflow: Add a new API feature module
+
+When you need a new set of endpoints — e.g. a new resource or integration — add a feature module under `src/apis/` and wire it in ApisModule.
+
+## Prerequisites
+
+- Feature is clearly scoped (routes, DTOs, one or more services).
+- You know whether it needs auth (Guardian), RBAC (CanPermissionsGuard + permission), and which Core/Common services it will use.
+- Read `project-memory/repo-map.md` for the full module inventory and reusable components registry.
+
+## Module placement rules
+
+- **New API feature**: Create a folder under `src/apis/` and register in `apis.module.ts`.
+- **New shared service used by APIs**: Prefer `src/common/` (app-level) or a new lib under `libs/` if reusable across projects.
+- **New core capability** (guard, auth, config, datasource): Under `src/core/`. Export from CoreModule.
+
+### Do / Don't
+
+- **Do**: Add new feature modules under `src/apis/` and register in ApisModule.
+- **Do**: Use existing CoreModule exports for auth, config, logger.
+- **Do**: Use `@can/common`, `@can/aws`, `@can/notification`, `@can/state-machine` path aliases for lib imports.
+- **Don't**: Create circular dependencies between CoreModule and ApisModule.
+- **Don't**: Put API controllers in CoreModule; keep Core for auth, config, datasource, user, logger.
+- **Don't**: Duplicate services that already exist in the Reusable Components Registry (`project-memory/repo-map.md`).
+
+## Steps
+
+1. **Create feature folder under src/apis/**
+   - Example: `src/apis/my-feature/`.
+   - Add: `my-feature.module.ts`, `my-feature.controller.ts`, `my-feature.service.ts`, and as needed: DTOs (`*.dto.ts`), model, repository (if DB), or types.
+
+2. **Implement module**
+   - In `my-feature.module.ts`: Import only what you need (e.g. SharedModule, or specific modules for Redis/Cache/Guardian). Declare controller and providers (service, etc.). Export service if other API modules need it.
+   - Controller: Define routes, apply guards (`CanAuthGuard`, `CanPermissionsGuard`), `@CanPermissions` if needed, and use `@CurrentUser()` for UserContext when required.
+   - Service: Put business logic here; call Core or Common services via dependency injection. Do not put SQL or auth logic in the controller.
+
+3. **Register in ApisModule**
+   - Open `src/apis/apis.module.ts`.
+   - Add `import { MyFeatureModule } from './my-feature/my-feature.module';` and add `MyFeatureModule` to the `imports` array.
+
+4. **Register DB model (if applicable)**
+   - Add the model to `src/include.models.ts`.
+
+5. **Routes and prefix**
+   - Global prefix is `/v1` (set in main.ts). Controller path (e.g. `@Controller('my-feature')`) gives `/v1/my-feature/...`. Document in Swagger via existing Swagger setup if desired.
+
+6. **Tests**
+   - Add unit tests for service (and controller if complex) in `*.spec.ts` next to the implementation. Use existing Jest config (roots: src, libs; moduleNameMapper for @can/*).
+   - Optionally add e2e in `test/` with `*.e2e-spec.ts` and jest-e2e.json.
+
+7. **Documentation**
+   - Update `project-memory/repo-map.md` under `src/apis/` table with the new feature path and role.
+   - Add or link API usage docs (e.g. in api-documentation/ or README) for the new routes.
+
+## References
+
+- `.agent/skills/auth-and-permissions/SKILL.md` — when the module touches auth-sensitive surfaces
+- `project-memory/constitution.md` — non-negotiables and project structure rules
+- `project-memory/repo-map.md` — module inventory and reusable components
+
+## Out of scope
+
+- Changing CoreModule or auth contract; consume them as-is unless there's a clear requirement to extend.

package/.agent/monolith/workflows/backend-quality-review.md

@@ -0,0 +1,27 @@
+---
+name: backend-quality-review
+description: Post-implementation backend quality gate. Runs after implementation is complete, before merge/PR, or when the user asks for a backend quality review. Delegates to the code-reviewer skill for the full structured review.
+---
+
+You are running a post-implementation backend quality gate for this Node/NestJS codebase.
+
+## When invoked
+
+Use this workflow when:
+- Implementation of a feature module or milestone is complete.
+- User asks for a backend quality review, quality gate, or pre-merge check.
+- End of a feature-module-runner workflow cycle.
+
+## What to do
+
+Execute the full review defined in `.agent/skills/code-reviewer/SKILL.md`.
+
+Follow all six phases in that skill exactly:
+1. Understand the change surface (git diff, graph tools, infer feature/milestone).
+2. Load all project-memory context docs.
+3. Review changed code against all checklist categories.
+4. Determine the output location for the report.
+5. Write the structured review report.
+6. Report findings inline to the user.
+
+No steps in this workflow supersede or replace the skill — run it in full.

package/.agent/monolith/workflows/build-feature-backend.workflow.md

@@ -0,0 +1,91 @@
+# Workflow: Build Backend Feature (Gated)
+
+Orchestrates backend feature delivery with mandatory plan approval, implementation, quality review, and tests.
+
+## Hard rule
+
+- **No code changes before plan approval.**
+- In Phase 1, produce the plan file and **stop**.
+- Do not edit `src/`, `libs/`, configs, or tests until explicit approval is received.
+
+## Prerequisites
+
+- Feature request/scope is available.
+- Repository has `project-memory/quality-playbook.md`.
+
+## Phase 1 — Plan Only (Approval Gate)
+
+1. **Read context (mandatory)**
+   - Read `project-memory/constitution.md`.
+   - Read `project-memory/repo-map.md`.
+   - Identify touched modules, auth/validation impact, and risk areas.
+
+2. **Prepare plan template source**
+   - Use `.agent/templates/FEATURE_PLAN.md`.
+
+3. **Generate plan**
+   - Create `documentation/plans/FEATURE_PLAN_BACKEND.md` using the template above.
+   - Include: scope, touched modules/files, auth/validation impacts, risks, rollout notes, and verification outline.
+
+4. **Stop and wait**
+   - Return for approval with the plan path.
+   - **Do not implement anything** before approval.
+
+## Phase 2 — Implement (Post-Approval Only)
+
+1. Implement exactly the approved plan.
+2. Keep changes minimal and scoped to planned files.
+3. Apply backend guardrails from:
+   - `project-memory/quality-playbook.md`
+   - `project-memory/auth-model.md` for auth-sensitive paths.
+
+## Phase 3 — Backend Quality Review
+
+1. **Identify changed files** — Run `git diff` or list files touched in this feature/module.
+2. **Read the playbook** — Open `project-memory/quality-playbook.md` and build a checklist from its categories for the changed files.
+3. **Apply checks** — For each changed file, validate against all applicable playbook categories:
+   - Async & errors: no unhandled promise rejections, no swallowed async failures, consistent error envelopes.
+   - Input validation at controller boundaries (DTOs/pipes).
+   - Auth/authz: ownership/tenant checks beyond guard-level auth.
+   - Timeouts/retries for outbound calls (HTTP/DB/cache/external APIs).
+   - No blocking sync on hot paths; pagination/limits on list endpoints.
+   - No secrets/PII in logs; no hardcoded secrets or raw `process.env` in feature logic.
+   - DI/module boundaries, controller/service layering, response contracts, test adequacy.
+   - Record only concrete findings tied to actual code paths.
+4. **Write review report** — Create `documentation/reports/REVIEW_REPORT_BACKEND.md` using `.agent/templates/REVIEW_REPORT.md`. Include: findings table (severity, impact, proposed fix, files), required fixes, optional refactors, pass/fail by category.
+5. **Propose minimal refactors** — For each finding, provide the smallest safe fix with rationale, diff scope, exact file paths, and verification notes.
+6. Apply agreed fixes before proceeding.
+
+## Phase 4 — Test Plan + Tests
+
+1. **Create test plan**
+   - Create `documentation/plans/TEST_PLAN_BACKEND.md`.
+   - Use `.agent/templates/TEST_PLAN.md`.
+2. **Implement tests**
+   - Add/update unit and/or e2e tests per plan.
+3. **Run test commands (if present)**
+   - `npm run test`
+   - `npm run test:e2e`
+   - `npm run test:cov` (optional when needed)
+4. Capture pass/fail outcomes and unresolved gaps in the review report.
+
+## Phase 5 — Documentation Update
+
+1. **Create or update `MODULE.md`**
+   - In the feature module directory (e.g. `src/apis/{feature-name}/MODULE.md`).
+   - Use `.agent/templates/MODULE.md` as the template.
+   - Document: purpose, files, exports, DI dependencies, DB models, reusable patterns.
+2. **Update `project-memory/repo-map.md`**
+   - Add a one-line entry in the `src/apis/` table with `MODULE.md` column marked ✅.
+   - If the module introduced any reusable service/pattern, add it to the **Reusable Components Registry**.
+
+## Deliverables
+
+- `documentation/plans/FEATURE_PLAN_BACKEND.md` (approval-gated)
+- Implementation changes (post-approval)
+- `documentation/reports/REVIEW_REPORT_BACKEND.md`
+- `documentation/plans/TEST_PLAN_BACKEND.md`
+- Test updates + command results
+- `src/apis/{feature-name}/MODULE.md`
+- Updated `project-memory/repo-map.md`
+

package/.agent/monolith/workflows/build-feature-react.workflow.md

@@ -0,0 +1,82 @@
+---
+name: build-feature
+description: Strict end-to-end feature workflow with mandatory plan approval, implementation, quality review, and testing.
+strict_mode: true
+owner: agent
+references:
+  - project-memory/constitution.md
+  - project-memory/repo-map.md
+  - project-memory/auth-model.md
+  - project-memory/quality-playbook.md
+  - project-memory/core-memory.md
+  - .agent/skills/feature-workflow/SKILL.md
+  - .agent/skills/auth-and-permissions/SKILL.md
+  - .agent/skills/react-quality-review/SKILL.md
+  - .agent/templates/FEATURE_PLAN.md
+  - .agent/templates/REVIEW_REPORT.md
+  - .agent/templates/TEST_PLAN.md
+outputs:
+  - Documentation/plans/FEATURE_PLAN.md (or Documentation/features/<feature_name>/ when running a named feature)
+  - Documentation/reports/REVIEW_REPORT.md
+  - Documentation/plans/TEST_PLAN.md (or Documentation/features/<feature_name>/ when running a named feature)
+---
+
+# Build Feature Workflow (Strict)
+
+## Non-negotiable gate
+
+- Always load and follow `project-memory/constitution.md`.
+- Always read `project-memory/quality-playbook.md`.
+- Always read and maintain `project-memory/core-memory.md`.
+- **No coding before plan approval.**
+- Required artifacts:
+  - Feature plan: `Documentation/features/<feature_name>/FEATURE_PLAN.md` or `Documentation/plans/FEATURE_PLAN.md`
+  - Review report: `Documentation/reports/REVIEW_REPORT.md`
+  - Test plan: `Documentation/features/<feature_name>/TEST_PLAN.md` or `Documentation/plans/TEST_PLAN.md`
+
+## Steps
+
+1. **Load foundation docs**
+   - Read `project-memory/constitution.md`, `project-memory/repo-map.md`, and `project-memory/auth-model.md`.
+   - Confirm constraints relevant to the request.
+
+2. **Run feature workflow skill and create plan**
+   - Use `.agent/skills/feature-workflow/SKILL.md`.
+   - Generate the feature plan in `Documentation/features/<feature_name>/FEATURE_PLAN.md` or `Documentation/plans/FEATURE_PLAN.md` from `.agent/templates/FEATURE_PLAN.md`.
+
+3. **Approval checkpoint (hard stop)**
+   - Present plan and stop for explicit approval.
+   - Do not modify implementation files before approval.
+
+4. **Implement after approval**
+   - Execute the approved file touch list in order.
+   - Keep pages thin and move logic into `src/views/**`, hooks, and services.
+
+5. **Conditional auth-and-permissions pass**
+   - Run `.agent/skills/auth-and-permissions/SKILL.md` when touching:
+     - `src/contexts/authContext.tsx`
+     - `src/utils/auth.ts`
+     - `src/configs/authConfig.ts`
+     - `src/types/auth.ts`
+     - protected pages under `src/app/[lang]/(dashboard)/(private)/**`
+     - auth-sensitive API routes under `src/app/api/**`
+
+6. **Run quality review and produce report**
+   - Run `.agent/skills/react-quality-review/SKILL.md`.
+   - Create `Documentation/reports/REVIEW_REPORT.md` from `.agent/templates/REVIEW_REPORT.md`.
+   - Apply required refactors from findings.
+
+7. **Generate and execute test plan**
+   - Create the test plan in `Documentation/features/<feature_name>/TEST_PLAN.md` or `Documentation/plans/TEST_PLAN.md` from `.agent/templates/TEST_PLAN.md`.
+   - Add/update relevant tests (unit/integration/manual).
+
+8. **Run test commands**
+   - Run available scripts (`npm run test`, `npm run lint`, feature-specific tests).
+   - Record command outcomes in the test plan file (Documentation/plans or Documentation/features/<feature_name>/).
+
+9. **Update core memory**
+   - Append the completed module or feature summary to `project-memory/core-memory.md`.
+   - Include files changed, decisions made, tests run, and follow-up notes for future work.
+
+10. **Final output**
+   - Return summary of files changed, verification steps, and test results.

package/.agent/monolith/workflows/feature-module-runner.md

@@ -0,0 +1,97 @@
+---
+description: Executes a SINGLE module from a feature folder. Implements, tests, reviews, fixes, and updates docs for that one module only. Invoked per-module by the orchestrator script (scripts/run-feature-modules.sh).
+---
+
+You are a single-module runner. You execute **exactly one module** of a multi-module feature. The orchestrator script (`scripts/run-feature-modules.sh`) handles sequencing — your job is the full lifecycle for the module number you are given.
+
+**Orchestrator gate:** After each module’s Cursor agent session completes successfully, the script runs `npm run build` and `npm run test` before launching the next module. If that gate fails, fix the tree and resume from the same module number. Each agent invocation uses `--model auto` (do not change the script to a fixed model for those sessions).
+
+## Input (provided in prompt)
+
+- **Feature folder** — e.g. `documentation/features/categories_and_amazon_catalog`
+- **Feature name** — derived from folder, e.g. `categories_and_amazon_catalog`
+- **Module number** — e.g. `1`
+- **Module file** — path to the module prompt, e.g. `documentation/features/.../..._MODULE_1_MODEL_LAYER.md`
+
+---
+
+## Setup — Read foundational docs
+
+Read these files first. They provide the rules and patterns you must follow.
+
+| File | Why |
+|------|-----|
+| `project-memory/constitution.md` | Non-negotiable safety rules |
+| `project-memory/quality-playbook.md` | Review checklist categories |
+| `project-memory/core-memory.md` | Feature history and prior decisions |
+| `.agent/workflows/build-feature-backend.workflow.md` | Implementation lifecycle phases |
+| `.agent/workflows/add-new-api-feature-module.md` | Module placement rules |
+
+---
+
+## Step A — Implement
+
+1. **Read the module prompt file** (the path is given in your input).
+2. The prompt contains curated repo-map context and the full module specification. Follow it.
+3. **Generate the feature plan** per `build-feature-backend.workflow.md` Phase 1, saving to `documentation/plans/FEATURE_PLAN_BACKEND_<feature_name>_M<N>.md`.
+4. **Self-approve the plan and implement.** The master plan was already user-approved. Do not stop for human approval. Proceed directly to Phase 2.
+5. Follow `add-new-api-feature-module.md` for module placement and Do/Don't rules.
+
+## Step B — Verify
+
+Run these checks after implementation. Fix issues before finishing.
+
+1. **Run tests**
+   - Scope to the feature area if possible (e.g. `npm run test -- --testPathPattern=<feature-name>`).
+   - Otherwise run `npm run test`.
+   - Note any failures.
+
+2. **Quality review**
+   - Identify changed files (`git diff --name-only`).
+   - Apply `quality-playbook.md` checks to changed files.
+   - Write review report to `documentation/reports/REVIEW_REPORT_BACKEND_<feature_name>_M<N>.md` using `.agent/templates/REVIEW_REPORT.md`.
+   - Save a copy as `documentation/features/<feature_name>/REVIEW_MODULE_<N>.md`.
+
+3. **Fix and re-verify**
+   - If the review has **required fixes** or tests failed, implement fixes.
+   - Re-run tests. If fixes touched reviewed code, re-check against the playbook.
+   - Repeat until tests pass and no required findings remain.
+   - If a fix cannot be resolved after two attempts, report the issue clearly and **exit with failure** so the orchestrator knows to stop.
+
+## Step C — Record
+
+1. **Save test documentation**
+   - Ensure `documentation/features/<feature_name>/tests/` exists.
+   - Create or update `MODULE_<N>_tests.md` with: test file paths, run commands, coverage summary.
+
+2. **Create or update MODULE.md**
+   - In the feature module directory (`src/apis/<feature-name>/MODULE.md`), using `.agent/templates/MODULE.md`.
+
+3. **Update repo-map**
+   - Add/update the module entry in `project-memory/repo-map.md` → `src/apis/` table (set MODULE.md column to ✅).
+   - If a new reusable service or pattern was introduced, add it to the Reusable Components Registry.
+
+4. **Update core-memory**
+   - Update `project-memory/core-memory.md` feature progress table:
+     - `<feature_name>: Module <N> completed (<brief description>); next: Module <N+1>.`
+   - If this is the last module, mark the feature as complete.
+
+---
+
+## Output
+
+When done, print a summary with:
+
+- What was implemented (key files created/modified)
+- Test results (pass/fail, coverage)
+- Review outcomes (findings, fixes applied)
+- Any remaining issues or deferred work
+
+---
+
+## Do not
+
+- Implement more than one module. You handle exactly the module number given.
+- Skip Step B (verify). Always test, review, fix, and update docs.
+- Stop for human confirmation. Self-approve and proceed autonomously.
+- Create unnecessary files outside the scope of this module.

package/.agent/templates/FEATURE_PLAN.md

@@ -0,0 +1,42 @@
+# FEATURE_PLAN (Backend)
+
+## 1) Overview
+- **Feature name**:
+- **Goal / user impact**:
+- **Relevant paths**: [e.g. src/apis/sample/, src/core/auth/, src/apis/apis.module.ts]
+- **Out of scope**:
+
+## 2) API Contract
+- **Endpoint(s)**:
+- **Method(s)**:
+- **Request schema / DTO**:
+- **Response schema**:
+- **Backward compatibility notes**:
+
+## 3) Validation & Authorization
+- **Input validation (body/query/params)**:
+- **Auth guard(s)**:
+- **Permission check(s)**:
+- **Resource ownership / tenant scoping**:
+
+## 4) Data Access & Side Effects
+- **Read/write path**:
+- **Models/repositories/services touched**:
+- **External dependencies (DB/Redis/API)**:
+- **Migration/config changes**:
+
+## 5) Performance & Reliability
+- **Expected query/load impact**:
+- **Caching strategy**:
+- **Timeout/retry strategy**:
+- **Failure handling**:
+
+## 6) Rollout & Rollback
+- **Rollout plan**:
+- **Rollback trigger**:
+- **Rollback steps**:
+
+## 7) Verification
+- **Review checklist refs**: `project-memory/quality-playbook.md`
+- **Auth model refs**: `project-memory/auth-model.md`
+- **Test plan file**: `documentation/plans/TEST_PLAN_BACKEND.md`

package/.agent/templates/MODULE.md

@@ -0,0 +1,45 @@
+# MODULE.md Template
+
+> Place this file in the root of each feature module: `src/apis/{feature-name}/MODULE.md`
+
+## {Feature Name}
+
+**Purpose**: One-sentence description of what this module does.
+
+**Module file**: `{feature-name}.module.ts`
+
+### Files
+
+| File | Role |
+|------|------|
+| `{feature-name}.controller.ts` | HTTP endpoints |
+| `{feature-name}.service.ts` | Business logic |
+| `{feature-name}.repository.ts` | Data access (Sequelize model injection) |
+| `{feature-name}.model.ts` | DB model definition |
+| `{feature-name}.dto.ts` | Request/response validation |
+
+### Exports (injectable by other modules)
+
+| Service | Used by |
+|---------|---------|
+| `{FeatureName}Service` | (list consuming modules, or "internal only") |
+
+### DI Dependencies
+
+| Injected | From |
+|----------|------|
+| (list injected services) | (source module) |
+
+### DB Models
+
+| Model | Table | Registered in `include.models.ts` |
+|-------|-------|-----------------------------------|
+| (model name) | (table name) | ✅ / ❌ |
+
+### Reusable Patterns
+
+> If this module introduced a pattern or service that other modules should reuse, describe it here and ensure it's listed in `project-memory/repo-map.md` → Reusable Components Registry.
+
+### Notes
+
+- Any gotchas, edge cases, or design decisions worth calling out.

package/.agent/templates/REVIEW_REPORT.md

@@ -0,0 +1,44 @@
+# REVIEW_REPORT (Backend)
+
+## 1) Change Summary
+- **Scope reviewed**:
+- **Files reviewed**:
+- **Overall status**: Pass / Pass with fixes / Blocked
+
+## 2) Findings
+
+| Severity | Finding | Why it matters | Proposed fix | Files |
+|---|---|---|---|---|
+| High/Med/Low |  |  |  |  |
+| High/Med/Low |  |  |  |  |
+
+## 3) Required Fixes Before Merge
+- [ ] Fix 1:
+- [ ] Fix 2:
+
+## 4) Optional Refactors
+- [ ] Refactor 1:
+- [ ] Refactor 2:
+
+## 5) Validation of Core Areas
+- [ ] API contract unchanged or versioned
+- [ ] Input validation present
+- [ ] Authz/tenant/resource checks present
+- [ ] Error handling consistent
+- [ ] No secret leakage / unsafe logs
+- [ ] Performance risks reviewed
+- [ ] Changes stay within the right module (see `project-memory/repo-map.md`). No circular imports.
+- [ ] If a new API feature: new module under `src/apis/` and registered in `ApisModule`.
+- [ ] `project-memory/repo-map.md` updated if new modules or notable paths were added.
+
+## 6) Tests
+- **Tests added/updated**:
+- **Commands run**:
+  - `npm run test`
+  - `npm run test:e2e`
+- **Result**: Pass / Fail / Partial
+- **Known gaps**:
+
+## 7) Final Recommendation
+- **Decision**: Approve / Request changes / Block
+- **Notes**:

package/.agent/templates/SECURITY_REPORT.md

@@ -0,0 +1,70 @@
+# SECURITY_ASSESSMENT_<YYYY-MM-DD>
+
+## 1) Scope
+- **Audit target**: Full codebase / Changed files (branch <name>) / Path <path>
+- **Files audited**:
+- **Auth model reference**: `project-memory/auth-model.md` (read at <timestamp>)
+- **Overall verdict**: Clean / Findings — fix before merge / Blocked
+
+## 2) Findings
+
+| Severity | Category | Finding | Why it matters | Proposed fix | Files |
+|---|---|---|---|---|---|
+| CRITICAL / HIGH / MEDIUM / LOW | Auth / Input / Injection / Deps / Data Exposure / Crypto / Secrets / Other |  |  |  |  |
+
+**Severity definitions:**
+- **CRITICAL** — Exploitable now in production; data loss, auth bypass, RCE, or unauthorized cross-tenant access.
+- **HIGH** — Real risk that requires specific conditions to exploit; missing guard on a sensitive endpoint, injection vector behind auth, vulnerable dep with known exploit in current usage.
+- **MEDIUM** — Defense-in-depth gap; weakens posture but no immediate exploit path. Missing rate limit on auth endpoint, verbose error responses, weak validation.
+- **LOW** — Hygiene issue; would not be exploitable on its own but flagged for cleanup.
+
+## 3) Auth Audit
+- [ ] Every protected endpoint has the correct guard/middleware (per `auth-model.md`)
+- [ ] Current-user / tenant context correctly threaded through call stack
+- [ ] Ownership scoping enforced in queries (filtered by user/tenant where required)
+- [ ] No auth logic in service/repository layer (controllers only)
+- [ ] Session/JWT handling matches `auth-model.md` (issuance, expiry, refresh, revocation)
+
+## 4) Input Surface Audit
+- [ ] All controllers/routes validate input at the boundary (DTO + validation pipe, or equivalent)
+- [ ] No raw `req.body` flowing into queries or services
+- [ ] User-supplied IDs are not trusted — auth context drives ownership filters
+- [ ] No unsafe deserialization (raw JSON.parse on external input → typed object without validation)
+- [ ] File uploads (if any): MIME type, size, and content validated server-side
+
+## 5) Injection Audit
+- [ ] SQL: All queries parameterized; no string concatenation of user input
+- [ ] ORM: No `Sequelize.literal` / `raw()` / `$queryRaw` carrying unescaped input
+- [ ] Shell: No `exec` / `spawn` with user-controlled arguments
+- [ ] Template injection: No user input passed to template engines without escape
+
+## 6) Dependency Audit
+- [ ] Ran `npm audit` (or equivalent) — record output summary
+- [ ] No dependencies pinned to known-vulnerable versions
+- [ ] No deprecated/abandoned dependencies in security-critical paths (auth, crypto, parsing)
+- [ ] Dependency added in this change: justified and from a reputable source
+
+## 7) Data Exposure Audit
+- [ ] No PII in application logs (per constitution rules)
+- [ ] No secrets in logs or error responses
+- [ ] API responses do not over-fetch (sensitive fields explicitly excluded)
+- [ ] Sensitive fields masked when surfaced to admin UIs (e.g. last-4 of card, partial email)
+- [ ] No stack traces returned to clients in production
+
+## 8) Crypto & Secrets
+- [ ] Passwords hashed with a current algorithm (bcrypt/argon2 with appropriate cost)
+- [ ] JWTs signed with strong algorithm (HS256+ with rotated secret, or RS256/ES256)
+- [ ] Secrets loaded from environment / secret manager; never committed
+- [ ] TLS enforced on all external HTTP calls (no plain `http://` to internal services that handle auth)
+
+## 9) Required Fixes Before Merge
+- [ ] Fix 1: (CRITICAL/HIGH only)
+- [ ] Fix 2:
+
+## 10) Recommended Hardening (Non-blocking)
+- [ ] Item 1: (MEDIUM/LOW)
+- [ ] Item 2:
+
+## 11) Final Recommendation
+- **Decision**: Approve / Request changes / Block merge
+- **Notes**:

package/.agent/templates/TEST_PLAN.md

@@ -0,0 +1,49 @@
+# TEST_PLAN (Backend)
+
+## 1) Scope
+- **Feature / PR**:
+- **Risks to cover**:
+
+## 2) Unit Tests
+- **Jest config**: Roots `src/` and `libs/`; `*.spec.ts`; moduleNameMapper for `@can/aws`, `@can/common`, `@can/notification`, `@can/state-machine`.
+- **Targets (services/utils/pipes/guards)**:
+- **Cases**:
+  - [ ] Happy path
+  - [ ] Validation failure
+  - [ ] Authz failure
+  - [ ] Error path
+
+## 3) Integration Tests
+- **Targets (module + DB/cache/external boundary)**:
+- **Cases**:
+  - [ ] Contract wiring (controller -> service -> data)
+  - [ ] Permission/tenant filters applied
+  - [ ] Cache behavior (hit/miss/skip)
+
+## 4) E2E Tests
+- **Config**: `test/jest-e2e.json`; `testRegex`: `.e2e-spec.ts$`; same moduleNameMapper.
+- **Endpoints covered**:
+- **Cases**:
+  - [ ] Success response contract
+  - [ ] 4xx/5xx behavior
+  - [ ] Unauthorized/forbidden access
+
+## 5) Mocks & Test Data
+- **What is mocked**:
+- **What is real**:
+- **Fixture strategy**:
+
+## 6) Failure Paths
+- [ ] Upstream timeout/error
+- [ ] Invalid payload/type mismatch
+- [ ] Dependency unavailable (DB/Redis/API)
+
+## 7) Commands & Exit Criteria
+- **Commands**:
+  - `npm run test`
+  - `npm run test:e2e`
+  - `npm run test:cov` (optional)
+- **Exit criteria**:
+  - [ ] Critical paths passing
+  - [ ] Failure paths covered
+  - [ ] No regression in existing tests