29 KiB
29 KiB
Master Task Backlog (Phase 3.3 Final Canonical Specification)
- Audit Phase: Phase 3.3 — Finalized Architecture & Backlog Revision
- Repository HEAD:
715873b2ecc3a72ba974bb2a2be87c5ba82bd4e7 - Canonical Verified Findings Source:
docs/audit/20-verified-findings-index.json - Total Verified Findings Processed: 14 (100% Traceability Coverage)
- Total Backlog Tasks: 10 (9 Implementation Tasks + 1 Verification Task)
- Finalized Architecture Split: Storefront (Next.js SSR/SEO) vs Admin Panel (Pure React SPA Performance & Security)
- Finalized Product Decisions: 2 (
DECISION-001,DECISION-003Finalized) | Future Scope: 1 (DECISION-002)
Executive Summary & Backlog Overview
| Priority | Task ID | Title | Category | Source Findings | Target Subsystem | Status |
|---|---|---|---|---|---|---|
| P0 | TASK-SEC-001 |
Mandatory Dual-Secret Startup Enforcement (JWT_ACCESS_SECRET & JWT_REFRESH_SECRET) |
Security | SEC-001 |
Backend (main.ts) |
READY_FOR_IMPLEMENTATION |
| P0 | TASK-SEC-002 |
Cryptographically Secure OTP Generation & Response Payload Hardening | Security | SEC-002, SEC-003 |
Backend (auth) |
READY_FOR_IMPLEMENTATION |
| P0 | TASK-SEC-003 |
Role-Based Access Control (RBAC) Enforcement on Administrative Settings API | Security | ADM-001 |
Backend (settings) |
READY_FOR_IMPLEMENTATION |
| P0 | TASK-FIN-001 |
Arbitrary-Precision Decimal Accounting & Prisma.Decimal Payload Serialization | Financial / DB | BE-001, BE-002 |
Backend (orders) |
READY_FOR_IMPLEMENTATION |
| P1 | TASK-BUILD-001 |
NestJS Compiler Diagnostic Remediation & Spec Return Type Alignment | Build / Code Quality | TS-002, TS-003, TEST-001 |
Backend (prisma/spec) |
READY_FOR_IMPLEMENTATION |
| P1 | TASK-AUTH-001 |
Dual-Token Auth Contract Integration for Standalone Admin Panel | Architecture | ARCH-001 |
Admin Panel / Auth | BLOCKED_BY_DEPENDENCY (TASK-SEC-002) |
| P1 | TASK-VERIFY-001 |
End-to-End Authentication, Authorization, Order, and Regression Verification | Verification | All 14 Findings | Entire System | BLOCKED_BY_DEPENDENCY (TASK-AUTH-001, TASK-SEC-003, TASK-FIN-001) |
| P2 | TASK-FE-001 |
Admin Panel Router Architecture (createBrowserRouter), Lazy Loading & Type Safety |
Admin SPA | FE-001, TS-001 |
Admin Panel SPA | READY_FOR_IMPLEMENTATION |
| P2 | TASK-DEVOPS-001 |
Continuous Integration Pipeline & Automated Quality Gate Setup | DevOps | DEVOPS-001 |
CI Workflow | BLOCKED_BY_DEPENDENCY (TASK-BUILD-001) |
| P3 | TASK-DOC-001 |
OpenAPI Documentation Synchronization & Non-Listener Schema Export | Documentation | DOC-001 |
Docs / Backend | READY_FOR_IMPLEMENTATION |
Detailed Task Specifications
TASK-SEC-001
- TASK-ID:
TASK-SEC-001 - Title: Mandatory Dual-Secret Startup Enforcement (
JWT_ACCESS_SECRET&JWT_REFRESH_SECRET) - Status:
READY_FOR_IMPLEMENTATION - Priority:
P0 - Severity:
HIGH - Category:
Security / Cryptographic Hardening - Source Findings:
SEC-001 - Objective: Ensure NestJS application fails startup (
process.exit(1)) if EITHERJWT_ACCESS_SECRETORJWT_REFRESH_SECRETis missing, empty, or less than 32 characters, completely eliminating hardcoded secret fallback strings. - Root Cause Addressed: Developer fallback string embedded in
jwt.strategy.tsandauth.module.tsas a default parameter instead of validating mandatory environment variables during application startup. - Current State:
backend/src/auth/jwt.strategy.ts: Line 12 usessecretOrKey: process.env.JWT_SECRET || 'super-secret-key'.backend/src/auth/auth.module.ts: Usesprocess.env.JWT_SECRET || 'super-secret-key'.
- Required Changes:
- Remove hardcoded fallback strings from
jwt.strategy.tsandauth.module.ts. - In
backend/src/main.tsbootstrap(), implement explicit startup validation for TWO separate environment variables:JWT_ACCESS_SECRETandJWT_REFRESH_SECRET. If either variable is undefined, empty, orlength < 32characters (minimum 32 bytes ASCII entropy), log fatal error and throw an exception beforeapp.listen(), terminating process bootstrap with exit code 1. - Ensure
.env.exampleincludes placeholdersJWT_ACCESS_SECRET=andJWT_REFRESH_SECRET=with instructions for production key generation.
- Remove hardcoded fallback strings from
- Affected Files / Areas:
backend/src/main.tsbackend/src/auth/jwt.strategy.tsbackend/src/auth/auth.module.tsbackend/.env.example
- Implementation Approach:
Read both
process.env.JWT_ACCESS_SECRETandprocess.env.JWT_REFRESH_SECRETcleanly inmain.tsbootstrap. Throw explicitError('FATAL: JWT_ACCESS_SECRET or JWT_REFRESH_SECRET environment variable is missing or insecure.')on bootstrap. - Dependencies: None.
- Blocked By: None.
- Risk Assessment: LOW technical risk. Fail-closed security design for dual-token authentication.
- Testing Requirements:
- Unit test in
jwt.strategy.spec.tsasserting error thrown when either secret is omitted. - Integration test confirming application boots successfully when both valid secrets (>= 32 chars each) are supplied.
- Unit test in
- Validation Commands:
cd backend && npm run test -- backend/src/auth/jwt.strategy.spec.tscd backend && cross-env JWT_ACCESS_SECRET= npm run start:dev(Verify immediate crash with explicit error message)
- Acceptance Criteria:
- Zero occurrences of string
'super-secret-key'or'super-secret-key-canina'in repository source files. - Backend startup terminates with process exit code 1 when either
JWT_ACCESS_SECRETorJWT_REFRESH_SECRETis absent or < 32 chars.
- Zero occurrences of string
- Definition of Done: Code edited, unit tests passing, dual-secret startup validation verified.
- Rollback / Recovery Considerations: Set both secret environment variables in deployment configuration if startup fails.
TASK-SEC-002
- TASK-ID:
TASK-SEC-002 - Title: Cryptographically Secure OTP Generation & Response Payload Hardening
- Status:
READY_FOR_IMPLEMENTATION - Priority:
P0 - Severity:
HIGH - Category:
Security / Authentication Hardening - Source Findings:
SEC-002,SEC-003 - Objective: Re-engineer NestJS SMS OTP generation to use Node.js CSPRNG (
crypto.randomInt), separate OTP generation from delivery via anIOtpDeliveryServiceinterface abstraction, and remove plaintext OTP code disclosure from public API response payloads. - Root Cause Addressed:
AuthService.sendOtpused non-cryptographicMath.random()to generate 5-digit verification codes.AuthController.sendOtpreturned{ success: true, code: '12345' }in the public response body.
- Current State:
backend/src/auth/auth.service.ts:const code = Math.floor(10000 + Math.random() * 90000).toString();- Returns
{ success: true, message: '...', code }.
- Required Changes:
- Replace
Math.random()inbackend/src/auth/auth.service.tswithcrypto.randomInt(10000, 100000).toString(). - Create
IOtpDeliveryService/OtpDeliveryServicedependency injection token withConsoleOtpDeliveryService(dev/test logger) andSmsGatewayOtpDeliveryService(production adapter). - Remove
codefield from returned object ofsendOtpinAuthServiceandAuthController. Response body must only return{ success: true, message: 'کد تایید ارسال شد' }.
- Replace
- Affected Files / Areas:
backend/src/auth/auth.service.tsbackend/src/auth/auth.controller.tsbackend/src/auth/auth.service.spec.tsbackend/src/auth/otp-delivery.service.ts[NEW]
- Implementation Approach:
Import native
crypto. Generate 5-digit integer viacrypto.randomInt(10000, 100000). InjectConsoleOtpDeliveryService. Sanitize DTO to omitcode. - Dependencies: None.
- Blocked By: None.
- Risk Assessment: LOW risk. Highly isolated changes within
AuthService. - Testing Requirements:
- Unit test verifying CSPRNG usage via
crypto.randomInt. - Unit test asserting
/api/auth/send-otpresponse payload JSON structure does NOT contain keycode. - Tests use mock/console delivery service without requiring real SMS delivery.
- Unit test verifying CSPRNG usage via
- Validation Commands:
cd backend && npm run test -- backend/src/auth/auth.service.spec.tscd backend && npm run test -- backend/src/auth/auth.controller.spec.ts
- Acceptance Criteria:
sendOtpresponse body structure contains ONLY{ success: boolean, message: string }.- OTP generation relies on
crypto.randomInt.
- Definition of Done: Clean unit tests passing, response sanitized, CSPRNG implemented.
- Rollback / Recovery Considerations: Standard git revert.
TASK-SEC-003
- TASK-ID:
TASK-SEC-003 - Title: Role-Based Access Control (RBAC) Enforcement on Administrative Settings API
- Status:
READY_FOR_IMPLEMENTATION - Priority:
P0 - Severity:
HIGH - Category:
Security / Authorization & Access Control - Source Findings:
ADM-001 - Objective: Protect all administrative settings endpoints (
/api/settings/*) withRolesGuardand@Roles('Admin')decorator. - Root Cause Addressed:
SettingsControllerapplied@UseGuards(JwtAuthGuard)but omittedRolesGuardand@Roles('Admin').RolesGuardand@Rolesdecorator were missing from the codebase. - Current State:
backend/src/settings/settings.controller.ts: Lacks@UseGuards(RolesGuard)and@Roles('Admin').
- Required Changes:
- Create
backend/src/common/decorators/roles.decorator.ts(SetMetadata('roles', roles)). - Create
backend/src/common/guards/roles.guard.tsusingReflectorto validatereq.user.role === 'Admin'. - Apply
@UseGuards(JwtAuthGuard, RolesGuard)and@Roles('Admin')toSettingsController.
- Create
- Affected Files / Areas:
backend/src/common/decorators/roles.decorator.ts[NEW]backend/src/common/guards/roles.guard.ts[NEW]backend/src/settings/settings.controller.tsbackend/src/settings/settings.controller.spec.ts
- Implementation Approach:
Implement
@Rolesdecorator andRolesGuard-> annotateSettingsControllerwith@UseGuards(JwtAuthGuard, RolesGuard)and@Roles('Admin'). - Dependencies: None.
- Blocked By: None.
- Risk Assessment: LOW technical risk. Prevents unauthorized settings modifications.
- Testing Requirements:
- Unit test verifying non-admin users (
User_PetOwner) receive403 Forbiddenon settings endpoints. - Unit test verifying admin users with
role: 'Admin'receive200 OK.
- Unit test verifying non-admin users (
- Validation Commands:
cd backend && npm run test -- backend/src/settings/settings.controller.spec.ts
- Acceptance Criteria:
- Requests with
User_PetOwnerJWT receive HTTP 403 Forbidden when calling/api/settings. - Requests with
AdminJWT receive HTTP 200 OK.
- Requests with
- Definition of Done: RBAC guards created and applied, unit tests passing.
- Rollback / Recovery Considerations: Standard git revert.
TASK-FIN-001
- TASK-ID:
TASK-FIN-001 - Title: Arbitrary-Precision Decimal Accounting & Prisma.Decimal Payload Serialization
- Status:
READY_FOR_IMPLEMENTATION - Priority:
P0 - Severity:
HIGH - Category:
Backend / Financial Integrity & Database Optimization - Source Findings:
BE-001,BE-002 - Objective: Fix monetary calculation floating-point precision loss, eliminate N+1 database queries in
OrdersService.create, and enforce globalPrisma.Decimalserialization to prevent client-side parsing crashes. - Root Cause Addressed:
OrdersService.createconverted PrismaDecimalprices into JS numbers (Number(product.priceValue)).OrdersService.createiterated overdto.itemsexecuting individualfindUniquequeries per line item.- Raw
Prisma.Decimalobjects serialized to JSON without string/number transformation, causing parsing errors on frontend/client apps.
- Current State:
backend/src/orders/orders.service.ts: N+1 query loop + primitive number arithmetic (totalAmount += Number(...) * quantity).
- Required Changes:
- Replace iterative
findUniquecalls with single batched query:this.prisma.product.findMany({ where: { id: { in: productIds } } }). - Map products by ID; throw
NotFoundException(404) if any product ID is missing. - Throw
BadRequestException(400) ifdto.itemscontains duplicate product IDs or invalid quantities (quantity <= 0). - Perform monetary subtotal and total calculations using Prisma
Decimalinstance methods (Decimal.add(),Decimal.mul()). Example:19.99 * 3 + 5.01 = 64.98. - Implement global NestJS
DecimalInterceptor(or DTOTransformdecorators) to convert allPrisma.Decimalinstances in outbound API response payloads into exact Strings (e.g.,"64.98") or precise Numbers before sending to clients.
- Replace iterative
- Affected Files / Areas:
backend/src/orders/orders.service.tsbackend/src/orders/orders.service.spec.tsbackend/src/common/interceptors/decimal.interceptor.ts[NEW]backend/src/main.ts
- Implementation Approach:
Batched
findMany-> Map lookup -> PrismaDecimalarithmetic -> globalDecimalInterceptorregistration inmain.ts. - Dependencies: None.
- Blocked By: None.
- Risk Assessment: MEDIUM risk. Core financial order pipeline and response serialization.
- Testing Requirements:
- Unit test with multi-item order verifying exactly 1 product query is executed.
- Unit test asserting exact decimal total calculation (
19.99 * 3 + 5.01 = 64.98without floating-point rounding artifacts). - Interceptor unit test verifying
Prisma.Decimalproperties are serialized to formatted strings/numbers in JSON response.
- Validation Commands:
cd backend && npm run test -- backend/src/orders/orders.service.spec.tscd backend && npm run test -- backend/src/common/interceptors/decimal.interceptor.spec.ts
- Acceptance Criteria:
- Zero
Number(product.priceValue)conversions in order calculation logic. - Single database query fetched for all cart products during checkout.
- Order total accumulated using Decimal arithmetic (
19.99 * 3 + 5.01 = 64.98). - All
Prisma.Decimalfields in API JSON response payloads are serialized as exact Strings/Numbers.
- Zero
- Definition of Done: Clean unit tests passing, Decimal math implemented, DecimalInterceptor registered, query batching verified.
- Rollback / Recovery Considerations: Standard git revert.
TASK-BUILD-001
- TASK-ID:
TASK-BUILD-001 - Title: NestJS Compiler Diagnostic Remediation & Spec Return Type Alignment
- Status:
READY_FOR_IMPLEMENTATION - Priority:
P1 - Severity:
MEDIUM - Category:
Code Quality / Compilation & Test Suite Stability - Source Findings:
TS-002,TS-003,TEST-001 - Objective: Fix TypeScript compiler errors in
seed.tsandmetrics.controller.ts, and resolve spec test suite compilation failures caused by stale controller assertions. - Root Cause Addressed:
backend/prisma/seed.tsproduct payload missing requiredslugfield (TS2322).backend/src/common/metrics.controller.tsimported ExpressResponsedirectly instead of type-only import underisolatedModules(TS1272).- Controller spec files asserted obsolete
result.successwrapper property.
- Required Changes:
backend/prisma/seed.ts: Addslugstring property to all product seed objects.backend/src/common/metrics.controller.ts: Change toimport type { Response } from 'express';.- Controller specs (
pets,settings,users): Update spec expectations to match current controller method return signatures without deleting assertions.
- Affected Files / Areas:
backend/prisma/seed.tsbackend/src/common/metrics.controller.tsbackend/src/pets/pets.controller.spec.tsbackend/src/settings/settings.controller.spec.tsbackend/src/users/users.controller.spec.ts
- Implementation Approach: Fix type imports, add missing seed properties, update controller spec return assertions.
- Dependencies: None.
- Blocked By: None.
- Risk Assessment: LOW risk. Restores build and test pipeline hygiene.
- Testing Requirements:
- Full TypeScript compilation check (
npx tsc --noEmit). - Execution of backend Jest test suite (
npm run test).
- Full TypeScript compilation check (
- Validation Commands:
cd backend && npx tsc --noEmitcd backend && npm run test
- Acceptance Criteria:
cd backend && npx tsc --noEmitsucceeds with 0 compilation errors.cd backend && npm run testcompletes with 100% passing tests.
- Definition of Done: Clean
tsccompilation and all test suites passing green. - Rollback / Recovery Considerations: Standard git revert.
TASK-AUTH-001
- TASK-ID:
TASK-AUTH-001 - Title: Dual-Token Auth Contract Integration for Standalone Admin Panel
- Status:
BLOCKED_BY_DEPENDENCY - Priority:
P1 - Severity:
HIGH - Category:
Architecture / Auth Integration - Source Findings:
ARCH-001 - Objective: Re-architect authentication state and login flow specifically for the standalone Admin Panel SPA to consume NestJS auth endpoints according to
ADR-AUTH-001(Dual-Token Hybrid: In-Memory Access Token + HttpOnlyrefreshTokenCookie signed withJWT_REFRESH_SECRET). - Root Cause Addressed: Application used mock auth state and vulnerable
localStoragetoken storage. - Current State:
src/store/userStore.ts: Mock email/password auth state.src/services/authService.ts: UseslocalStorage.setItem('accessToken', ...).
- Required Changes:
- Implement Dual-Token Hybrid architecture per
ADR-AUTH-001for the standalone Admin Panel: HoldaccessTokenstrictly in-memory in Zustand store / Axios interceptor; issueHttpOnly,Secure,SameSite=StrictrefreshTokencookie on successful authentication. - Configure Axios client with
withCredentials: trueand add background silent token refresh interceptor on HTTP 401 Unauthorized responses. - Build Admin Login component collecting mobile number / credentials and OTP verification code.
- Implement Dual-Token Hybrid architecture per
- Affected Files / Areas:
src/store/adminAuthStore.ts[NEW]src/components/AdminLogin.tsx[NEW]src/services/adminAuthService.ts[NEW]src/services/api.ts
- Implementation Approach:
Follow
ADR-AUTH-001contract -> implementadminAuthService&adminAuthStore-> wire Admin Login component. - Dependencies:
TASK-SEC-002(OTP API payload hardening must be completed prior to frontend wiring). - Blocked By:
TASK-SEC-002 - Risk Assessment: MEDIUM risk. Admin Panel authentication boundary.
- Testing Requirements:
- Unit test
adminAuthStorestate machine transitions and token handling. - Component integration test for Admin Login.
- Unit test
- Validation Commands:
npm run testnpm run build
- Acceptance Criteria:
- Admin Panel login triggers NestJS backend auth endpoints successfully.
- Access token is held in-memory and automatically attached to
apirequest headers. - Session persists seamlessly across page refreshes via background refresh with
refreshTokenHttpOnly cookie.
- Definition of Done: Admin Panel dual-token auth flow fully functional per
ADR-AUTH-001, unit tests passing, build clean. - Rollback / Recovery Considerations: Standard git revert.
TASK-FE-001
- TASK-ID:
TASK-FE-001 - Title: Admin Panel Router Architecture (
createBrowserRouter), Lazy Loading & Type Safety - Status:
READY_FOR_IMPLEMENTATION - Priority:
P2 - Severity:
MEDIUM - Category:
Admin SPA / Routing & Performance - Source Findings:
FE-001,TS-001 - Objective: Implement
react-router-dom(createBrowserRouter) specifically for the standalone Admin Panel SPA to enable Lazy Loading, optimize performance for heavy admin modules (Products,Orders,Settings,Users), and enforce strict Type Safety. (SEO is completely irrelevant for Admin Panel). - Root Cause Addressed:
- Legacy state-driven view rendering caused navigation failures.
- Sub-view state variables used explicit
anyescape hatches.
- Current State:
- Storefront customer-facing application is built with Next.js (SSR/SEO).
- Admin Panel SPA requires dedicated router setup.
- Required Changes:
- Configure
react-router-domcreateBrowserRouterfor Admin Panel matchingfrontend-route-map.md(/admin/login,/admin/dashboard,/admin/settings,/admin/products/*,/admin/orders/*,/admin/users/*,/admin/pets/*). - Implement React
<Suspense>lazy-loading for heavy administrative module chunks (AdminProductsManager,AdminOrdersManager,AdminSettings). - Define explicit TypeScript interfaces for all admin route parameters and state structures, eliminating all
anyannotations.
- Configure
- Affected Files / Areas:
src/App.tsx/ Admin SPA rootsrc/routes/adminRoutes.tsx[NEW]src/types/admin.ts[NEW]package.json
- Implementation Approach:
Setup
createBrowserRouter-> define lazy-loaded admin module routes -> enforce strict TypeScript interfaces. - Dependencies: None.
- Blocked By: None.
- Risk Assessment: MEDIUM risk. Admin SPA routing architecture.
- Testing Requirements:
- Unit test admin component route navigation and lazy loading.
- Typecheck validation (
npx tsc --noEmit).
- Validation Commands:
npx tsc --noEmitnpm run build
- Acceptance Criteria:
- Admin Panel routes render target views directly on page refresh via
createBrowserRouter. - Admin modules are lazy-loaded via dynamic imports (
lazy()). - Zero explicit
anytype declarations in Admin Panel codebase.
- Admin Panel routes render target views directly on page refresh via
- Definition of Done: React Router
createBrowserRouterintegrated for Admin Panel perfrontend-route-map.md, lazy loading verified, 0 type errors. - Rollback / Recovery Considerations: Standard git revert.
TASK-DEVOPS-001
- TASK-ID:
TASK-DEVOPS-001 - Title: Continuous Integration Pipeline & Automated Quality Gate Setup
- Status:
BLOCKED_BY_DEPENDENCY - Priority:
P2 - Severity:
MEDIUM - Category:
DevOps / Continuous Integration Workflow - Source Findings:
DEVOPS-001 - Objective: Create committed Gitea/GitHub Actions workflow (
.github/workflows/ci.yml) enforcing automated build, lint, typecheck, and test execution on pull requests. - Root Cause Addressed: Absence of committed
.github/workflows/directory in repository. - Current State: No
.github/workflows/directory exists. - Required Changes:
- Create
.github/workflows/ci.yml. - Configure triggers:
on: [push, pull_request]. - Define job matrix for Frontend quality gate (
npm ci,npm run lint,npx tsc --noEmit,npm run build) and Backend quality gate (cd backend && npm ci,npx prisma generate,npx tsc --noEmit,npm run test).
- Create
- Affected Files / Areas:
.github/workflows/ci.yml[NEW]
- Implementation Approach: Write Gitea/GitHub Actions workflow file tailored specifically to this repository.
- Dependencies:
TASK-BUILD-001(Backend compiler errors must be resolved so CI pipeline passes green). - Blocked By:
TASK-BUILD-001 - Risk Assessment: LOW risk. Purely additive DevOps configuration file.
- Testing Requirements:
- Workflow YAML syntax validation.
- Validation Commands:
npx actionlint .github/workflows/ci.yml
- Acceptance Criteria:
.github/workflows/ci.ymlis committed and syntactically valid.- Automated CI workflow executes build, lint, typecheck, and unit test checks on PRs.
- Definition of Done: Workflow file created, validated, and passing on pull requests.
- Rollback / Recovery Considerations: Delete workflow file if necessary.
TASK-DOC-001
- TASK-ID:
TASK-DOC-001 - Title: OpenAPI Documentation Synchronization & Automated Schema Export
- Status:
READY_FOR_IMPLEMENTATION - Priority:
P3 - Severity:
MEDIUM - Category:
Documentation / API Specification Alignment - Source Findings:
DOC-001 - Objective: Reconcile root
swagger.ymlwith active NestJS controllers and configure automated OpenAPI spec generation via a non-listener CLI tool. - Root Cause Addressed:
swagger.ymldocuments obsolete/loginand/registerendpoints. - Current State:
swagger.ymlout of sync with active backend auth routes. - Required Changes:
- Create non-listener CLI script
backend/scripts/generate-openapi.tsinstantiating NestJS application without callingapp.listen(). Addnpm run docs:generatescript inbackend/package.json. - Update root
swagger.ymlto accurately documentPOST /api/auth/send-otpandPOST /api/auth/verify-otp.
- Create non-listener CLI script
- Affected Files / Areas:
swagger.ymlbackend/scripts/generate-openapi.ts[NEW]backend/package.json
- Implementation Approach:
Create non-listener OpenAPI generator CLI script -> execute
npm run docs:generate-> syncswagger.yml. - Dependencies: None.
- Blocked By: None.
- Risk Assessment: LOW risk. Documentation only.
- Testing Requirements:
- Validate OpenAPI YAML syntax.
- Validation Commands:
cd backend && npm run docs:generate && git diff --exit-code ../swagger.yml
- Acceptance Criteria:
swagger.ymlendpoints match active NestJS Auth and Settings controller routes 100%.npm run docs:generatecompletes without opening a live HTTP listening port.
- Definition of Done:
swagger.ymlupdated, script configured, validation clean. - Rollback / Recovery Considerations: Standard git revert.
TASK-VERIFY-001
- TASK-ID:
TASK-VERIFY-001 - Title: End-to-End Authentication, Authorization, Order, and Regression Verification
- Status:
BLOCKED_BY_DEPENDENCY - Priority:
P1 - Severity:
INFO(Verification Task) - Category:
Verification / Automated Integration & E2E Suite - Source Findings: All 14 Verified Findings
- Objective: Execute a 7-domain behavior-oriented verification matrix across all 14 verified findings after implementation tasks complete.
- Root Cause Addressed: Cross-cutting audit verification ensuring no regressions were introduced and all 14 findings have been remediated.
- Current State: Post-remediation verification suite.
- Required Changes:
- Create automated integration test suite in
backend/test/app-audit-verification.e2e-spec.ts. - Assert 7-domain behavior-oriented verification matrix:
- A. Unit Verification:
BE-001(19.99 * 3 + 5.01 = 64.98),BE-002(single batch query),SEC-002(crypto.randomInt),TEST-001(full green Jest suite). - B. Integration / E2E Verification:
ARCH-001(send-otp->verify-otp),SEC-003(payload omitscode),ADM-001(non-admin 403 vs admin 200). - C. Startup Smoke Verification:
SEC-001(process exits with code 1 when eitherJWT_ACCESS_SECRETorJWT_REFRESH_SECRETis omitted or < 32 chars). - D. Frontend Verification:
FE-001(createBrowserRouteradmin navigation & lazy loading),TS-001(zeroanytypes). - E. Build / Type / Lint Verification:
TS-002(seed.tscompiles),TS-003(metrics.controller.tstype-onlyResponseimport). - F. CI Verification:
DEVOPS-001(.github/workflows/ci.ymlsyntax & PR trigger). - G. Documentation Verification:
DOC-001(npm run docs:generate && git diff --exit-code swagger.yml).
- A. Unit Verification:
- Create automated integration test suite in
- Affected Files / Areas:
backend/test/app-audit-verification.e2e-spec.ts
- Implementation Approach:
Write automated integration test suite in
backend/test/app-audit-verification.e2e-spec.ts. - Dependencies:
TASK-SEC-001,TASK-SEC-002,TASK-SEC-003,TASK-FIN-001,TASK-BUILD-001,TASK-AUTH-001. - Blocked By:
TASK-AUTH-001,TASK-SEC-003,TASK-FIN-001 - Risk Assessment: LOW risk. Verification script execution only.
- Testing Requirements:
- 7-Domain behavior-oriented E2E test suite execution.
- Validation Commands:
cd backend && npm run test:e2e
- Acceptance Criteria:
- All 14 verified findings pass 7-domain verification assertions 100% green.
- Zero findings remaining in OPEN status.
- Definition of Done: Verification report generated, 100% pass rate confirmed.
- Rollback / Recovery Considerations: N/A.
Product Decisions & Future Scope
-
DECISION-001(SMS Gateway Provider Selection)- Category:
PRODUCT_DECISION - Status:
PENDING_PRODUCT_INPUT - Description: Selection of production SMS gateway provider for NestJS
AuthService.sendOtp. Non-production environments strictly use stdout logger / mock dispatch interface.
- Category:
-
DECISION-003(Storefront vs Admin Sub-Application Architecture Roadmap)- Category:
FINALIZED_PRODUCT_DECISION - Status:
FINALIZED_PRODUCT_DECISION - Decision Outcome: The Admin Panel is a completely standalone, isolated application (React SPA) and will NOT be hosted within the main Storefront (Next.js SSR/SEO).
- Category:
-
FUTURE_SCOPEItems:DECISION-002(Live Payment Gateway Provider Selection):FUTURE_SCOPE— Selection of merchant payment gateway provider (e.g. ZarinPal, IdPay, Shaparak) for wallet deposits and checkout. Excluded from core audit remediation backlog as no verified finding requires payment gateway implementation.