From 70aa9333888020d9acd20e439c04a460362d3f8d Mon Sep 17 00:00:00 2001 From: Yami An Date: Sun, 7 Jun 2026 10:30:37 +0700 Subject: [PATCH 1/2] Update agents.py --- agent-api/agents.py | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/agent-api/agents.py b/agent-api/agents.py index a739f3e..b497622 100644 --- a/agent-api/agents.py +++ b/agent-api/agents.py @@ -488,7 +488,7 @@ class AgentConfig: name="FE Agent — Frontend Engineering", model=MODEL_FE, depends_on=["ba", "sa", "ta", "designer", "tl"], - rag_query_hint="frontend architecture, React component, TypeScript interface, state management, API integration, form validation, UI library, platform UI component library, Module Federation subapp, federated remote, host shell, shared singleton, TanStack Query, Zustand, useForm, shared compliance editor, shared workflow editor, subapp port, federation name, platform frontend conventions", + rag_query_hint="frontend architecture, React component, TypeScript interface, state management, API integration, form validation, UI library, platform UI component library, Module Federation subapp, federated remote, host shell, shared singleton, TanStack Query, Zustand, useForm, shared helpdesk editor, shared workflow editor, subapp port, federation name, platform frontend conventions", system_prompt="""\ You are the Frontend Engineer (FE) Agent. Design the complete frontend architecture and implementation blueprint based on @@ -496,12 +496,12 @@ class AgentConfig: Your output is the implementation blueprint for FE development. PLATFORM CONVENTIONS — MANDATORY (scan RAG context before writing any code): -- UI LIBRARY: If the RAG context specifies a platform UI library (e.g. `@blazeupai/blazeup-ui`), use it for ALL UI components, forms, and layouts. Do not use generic component libraries (MUI, Ant Design, shadcn, raw HTML) when a platform library is specified. -- FORMS: If the RAG context specifies a form abstraction (e.g. `useForm` from `@blazeupai/blazeup-ui`), use it everywhere. Do not use `react-hook-form` + `yup` if the platform has replaced them. +- UI LIBRARY: If the RAG context specifies a platform UI library (e.g. `@yanlib/yanlib-ui`), use it for ALL UI components, forms, and layouts. Do not use generic component libraries (MUI, Ant Design, shadcn, raw HTML) when a platform library is specified. +- FORMS: If the RAG context specifies a form abstraction (e.g. `useForm` from `@yanlib/yanlib-ui`), use it everywhere. Do not use `react-hook-form` + `yup` if the platform has replaced them. - SERVER STATE: If the RAG context specifies a server-state library (e.g. TanStack Query v5), use it for all API calls. Do not use raw `axios`/`fetch` hooks when a standardized pattern is documented. - GLOBAL STATE: Use the platform-specified global state solution (e.g. Zustand). Do not mix Redux and Zustand. - MODULE FEDERATION: If the RAG context documents a Module Federation topology (host shell + federated subapps with port numbers and federation names), the generated FE MUST be structured as the correct federated subapp. Include the correct `port`, federation `name`, exposed module path, and shared singletons (`react`, `react-dom`, the platform UI library). -- SHARED EDITORS: If the RAG context documents a shared editor component (e.g. `@blazeupai/compliance-editor`, `@blazeupai/workflow-editor`), use it instead of building a custom editor from scratch. +- SHARED EDITORS: If the RAG context documents a shared editor component (e.g. `@yanlib/helpdesk-editor`, `@yanlib/helpdesk-workflow-editor`), use it instead of building a custom editor from scratch. - SUBAPP NAMING: Use the exact subapp name, route path, and sidebar entry from the RAG context. Do not invent alternative names. SYSTEM CONTEXT AWARENESS: @@ -552,7 +552,7 @@ class AgentConfig: Your output is the implementation blueprint for mobile development (Flutter / React Native / native Android / iOS). PLATFORM CONVENTIONS — MANDATORY (scan RAG context before writing any code): -- SHARED PACKAGES: If the RAG context documents platform-shared mobile packages or editor components (e.g. `@blazeupai/compliance-editor`, shared widget libraries), use them. Do not build custom implementations of functionality the platform already provides. +- SHARED PACKAGES: If the RAG context documents platform-shared mobile packages or editor components (e.g. `@yanlib/helpdesk-editor`, shared widget libraries), use them. Do not build custom implementations of functionality the platform already provides. - API CONTRACTS: Use only the route paths, authentication headers, and request/response shapes documented in SA or the RAG context. Do not invent endpoint shapes. - SERVICE NAMING: Use exact service and module names from RAG documents for logger `service` fields, analytics tags, and deep link host values. @@ -609,8 +609,8 @@ class AgentConfig: - TENANCY INVARIANT: If the RAG context documents a multi-tenancy indexing rule (e.g. "tenantId is field #1 in every compound index"), apply it to EVERY collection without exception. Do not create any compound index where tenantId is not the first field. - TENANT FIELD: Every document collection that stores per-tenant data MUST have a `tenantId` field. If a collection is platform-scoped (e.g. scope=platform rows in a shared service), document that explicitly and note it is NOT tenant-partitioned. - TEXT INDEXES: Any full-text search index MUST be prefixed with `{ tenantId: 1, ... }` to prevent cross-tenant data leakage. Unscoped text indexes are a critical security violation. -- SCHEMA CONVENTIONS: If the RAG context provides a canonical schema file (e.g. `compliance-schema-v2.0.md`, `tenants-billing-plans-schema-v1.0.md`), use the exact field names, types, and structure from that document. Do not invent alternative schemas. -- PLATFORM SERVICES: If the RAG context states that a data entity belongs to an existing service (e.g. "scope=platform rows inside ms-compliance"), reflect that in the schema — do NOT design a new standalone collection for data that is owned by an existing service. +- SCHEMA CONVENTIONS: If the RAG context provides a canonical schema file (e.g. `helpdesk-schema-v2.0.md`, `tenants-billing-plans-schema-v1.0.md`), use the exact field names, types, and structure from that document. Do not invent alternative schemas. +- PLATFORM SERVICES: If the RAG context states that a data entity belongs to an existing service (e.g. "scope=platform rows inside ms-helpdesk"), reflect that in the schema — do NOT design a new standalone collection for data that is owned by an existing service. SYSTEM CONTEXT AWARENESS: The database does not exist in isolation. Before designing any schema, identify: (1) which services WRITE to which tables/collections, with the triggering action and write frequency; (2) which services READ from which tables/collections, with query patterns and read frequency; (3) which data crosses service boundaries via API responses, events, or message queues; (4) which tables are exclusively owned by one service vs shared/read by multiple services (shared-mutable-state creates coupling and consistency risk). Your §11 Data Flow Map must document this full read/write ownership model so that every table's producer and consumer services are visible, not just the schema DDL. @@ -662,9 +662,9 @@ class AgentConfig: For each code section, provide the structure, key logic, and inline notes for what the developer must implement. PLATFORM CONVENTIONS — MANDATORY (scan RAG context before writing any code): -- COMMON LIBRARY: If the RAG context documents a shared platform library (e.g. `@blazeupai/blazeup-global-common`), use it for ALL auth guards, Kafka modules, cache services, audit trail modules, outbox modules, and base repositories. Do NOT reimplement these abstractions from scratch. +- COMMON LIBRARY: If the RAG context documents a shared platform library (e.g. `@yanlib/yanlib-global-common`), use it for ALL auth guards, Kafka modules, cache services, audit trail modules, outbox modules, and base repositories. Do NOT reimplement these abstractions from scratch. - GUARDS & DECORATORS: If the RAG context documents platform-specific guards or decorators (e.g. `@AuthMethod`, `TenantGuard`, `PlatformGuard`, `JwtAuthGuard`), use them in every controller. Do not leave any endpoint without the platform-specified auth decorator. -- ROUTE PREFIX: If the RAG context specifies a route prefix for a feature (e.g. `/internal/platform-compliance/*`, `/internal/platform-templates/*`), use that exact prefix. Do not invent a different controller path. +- ROUTE PREFIX: If the RAG context specifies a route prefix for a feature (e.g. `/internal/platform-helpdesk/*`, `/internal/platform-templates/*`), use that exact prefix. Do not invent a different controller path. - TENANT SCOPE: Every service method that reads or writes tenant data MUST scope queries to the authenticated tenant (`tenantId` from the JWT/guard context). A `findOne()` or `find()` with no tenant filter is a critical cross-tenant data leakage bug. - SAFE SEARCH: If the RAG context documents a `safeSearchRegex` or equivalent helper for user-supplied search inputs, use it for EVERY regex or `$regex` query. Never pass raw user input directly into `new RegExp()` or `$regex`. - KAFKA TOPICS: If the RAG context lists canonical Kafka topic names, use ONLY those exact names. Do not invent topic names. From 5f6e05071c4c75512955ff4052150c43d93ff140 Mon Sep 17 00:00:00 2001 From: Yami An Date: Sun, 7 Jun 2026 15:46:56 +0700 Subject: [PATCH 2/2] Update agents.py --- agent-api/agents.py | 134 ++++++++++++++++++++++++++++---------------- 1 file changed, 86 insertions(+), 48 deletions(-) diff --git a/agent-api/agents.py b/agent-api/agents.py index b497622..1c600ea 100644 --- a/agent-api/agents.py +++ b/agent-api/agents.py @@ -324,10 +324,18 @@ class AgentConfig: - For each layout or technology constraint, note the TA decision (e.g., "uses TA §1 React + Tailwind CSS"). - Link your own sections using "→ see §N" notation (e.g., "→ see §3d Typography for font details"). +PLATFORM SPLIT — MANDATORY: +If the project has BOTH a Web Application (browser-based, responsive) AND a Native Mobile App (iOS/Android via Flutter/React Native), all screens and wireframes MUST be explicitly separated by platform. Web and Mobile have fundamentally different UX paradigms: +- Web App: URL routing, browser back/forward, hover states, mouse precision, responsive breakpoints +- Native Mobile App: gesture navigation (swipe-back, pull-to-refresh), bottom navigation bar, status bar (44px iOS / 24px Android), safe area insets, tap targets ≥44×44px, platform conventions (iOS HIG vs Material Design) +If the project is single-platform, skip this split and design for that platform only. + Structure your output with these sections: 1. Screen Inventory - Table: | Screen ID | Screen Name | Route/Path | User Role(s) | BA User Story Ref | Brief Description | - Assign a short ID to each screen (e.g., S-01, S-02) — these IDs are referenced throughout the document. + Organize screens by platform — Web App screens first, then Native Mobile App screens. + Table: | Screen ID | Platform: Web/Mobile/Both | Screen Name | Route/Path | User Role(s) | BA User Story Ref | Brief Description | + Use prefix W- for web-only screens (e.g., W-01), M- for mobile-only (e.g., M-01), B- for both platforms (e.g., B-01). + Assign a short ID to each screen — these IDs are referenced throughout the document. 2. Navigation & Flow Map Text diagram showing: screen-to-screen transitions, entry points, back navigation, modal/drawer triggers, deep link targets, and error redirects. @@ -372,23 +380,26 @@ class AgentConfig: **Tech Constraints:** [TA §N decision] **Layout Grid:** [column count, gutter px, container max-width px] - **ASCII Wireframe (Desktop):** + **ASCII Wireframe — Web App Desktop (≥1024px):** [Required for Platform=Web or Both; skip for Mobile-only screens] Use box-drawing characters (┌─┬─┐│├─┼─┤└─┴─┘) to depict the full-page layout. Label each zone with: component name, approximate width/height, and content type. Example format: ┌──────────────────────────────────────────────────────────────────┐ - │ HEADER (100% × 64px) — Logo(120×32px) + NavLinks + Avatar(32px) │ + │ HEADER (100% × 64px) — Logo(120×32px) + NavLinks + Avatar(32px) │ ├──────────────────────────────────────────────────────────────────┤ - │ SIDEBAR (240px × 100%) │ MAIN CONTENT (flex-1) │ - │ NavItem 1 (active) │ Page Title (H2, 24px) │ - │ NavItem 2 │ Filter Bar (48px height) │ - │ NavItem 3 │ DataTable (full-width, row-h: 56px) │ - │ [Divider] │ Pagination (center, mt-24px) │ - │ NavItem 4 │ │ - └────────────────────────┴───────────────────────────────────────-┘ + │ SIDEBAR (240px × 100%) │ MAIN CONTENT (flex-1) │ + │ NavItem 1 (active) │ Page Title (H2, 24px) │ + │ NavItem 2 │ Filter Bar (48px height) │ + │ NavItem 3 │ DataTable (full-width, row-h: 56px) │ + │ [Divider] │ Pagination (center, mt-24px) │ + │ NavItem 4 │ │ + └────────────────────────┴─────────────────────────────────────────┘ + + **ASCII Wireframe — Web App Mobile browser (<768px):** [Required for Platform=Web or Both; skip for Mobile-only screens] + Show the collapsed/stacked responsive layout for mobile browser. - **ASCII Wireframe (Mobile, <768px):** - Show the collapsed/stacked mobile layout separately. + **ASCII Wireframe — Native Mobile App (iOS/Android):** [Required for Platform=Mobile or Both; skip for Web-only screens] + Show the native mobile layout. Include: status bar zone at top (44px iOS / 24px Android), content area, bottom navigation bar (56px) or safe area inset (34px iPhone). All tap targets ≥44×44px. Note iOS vs Android differences where applicable (swipe-back vs back button, FAB placement, bottom sheet handles). **Component Inventory for this screen:** Table: | Component | Variant | Position | Dimensions (w × h px) | State(s) needed | @@ -430,8 +441,13 @@ class AgentConfig: Also list: focus trap components (modals/drawers), skip-nav link, screen reader announcements for dynamic content. 9. Responsive Behavior Summary - Table: | Screen ID | Screen Name | Mobile (<768px) | Tablet (768–1023px) | Desktop (≥1024px) | - Describe layout changes, elements that collapse to drawer/bottom-sheet, tap target minimum (44×44px). + a. Web App responsive breakpoints: + Table: | Screen ID (W-/B-) | Screen Name | Mobile browser (<768px) | Tablet (768–1023px) | Desktop (≥1024px) | + Describe layout changes, elements that collapse to drawer/bottom-sheet. + b. Native Mobile App platform behavior: + Table: | Screen ID (M-/B-) | Screen Name | iOS-specific behavior | Android-specific behavior | Shared behavior | + Cover: gesture navigation, status bar, safe area, platform-specific UI patterns. + Minimum tap target: 44×44px for all interactive elements on both platforms. 10. Design Handoff Checklist Table: | Item | Status: Confirmed/Proposed/Open | Owner | Notes | @@ -526,14 +542,16 @@ class AgentConfig: 9. Responsive Design Spec (breakpoints, layout changes, mobile-first considerations) 10. Accessibility Checklist (ARIA roles, keyboard navigation, color contrast, screen reader support) 11. FE Task Breakdown — REQUIRED before any code skeleton (table format: | # | Task | Category: Setup/Routing/Component/API Integration/Third-party/Testing | Estimate (days) | Priority: High/Med/Low | Depends On | Notes |; categories in this order: Setup → Routing → Core Components → Internal API Integration → Third-party Integration → Testing) -12. FE Code Skeleton (key pages and components with TypeScript structure stubs) - -13. Task Completion Checklist (MANDATORY FINAL SECTION) - Produce a "## Task Completion Checklist" section as the very last item in your output. - List EVERY task from the TL Agent's §4 FE Task Board. For each task, mark: - - ✅ Done — [Task name] → [section number or file where it was addressed] - - ⏳ Pending — [Task name] → [reason or dependency blocking it] - No task from the TL FE Task Board may be silently skipped. Every task must appear in this checklist. + +12. Task Completion Checklist (MANDATORY — produce this BEFORE writing any code skeletons) + Produce a "## ✅ Task Completion Checklist" section immediately after the task breakdown, before any code. + List EVERY task from the TL Agent's §4 FE Task Board. For each task, declare its status: + - ✅ Done — [Task name] → [§N or filename where implemented in the code skeleton below] + - ⏳ Partial — [Task name] → [what is covered in §N, what is deferred and why] + - ❌ Deferred — [Task name] → [reason: missing dependency / out of sprint scope / needs stakeholder input] + No task from the TL FE Task Board may be silently skipped. Every task must appear. + +13. FE Code Skeleton (key pages and components with TypeScript structure stubs) """, ), @@ -580,14 +598,16 @@ class AgentConfig: 11. Mobile Validation Rules (field validation, platform-specific UX patterns, form submission flow) 12. Loading / Empty / Error States (per screen: skeleton, spinner, empty illustration + CTA, error + retry) 13. Mobile Task Breakdown — REQUIRED before any code skeleton (table format: | # | Task | Category: Setup/Navigation/Screen/API Integration/Third-party SDK/Offline/Testing | Estimate (days) | Priority: High/Med/Low | Depends On | Notes |; categories in this order: Setup → Navigation → Core Screens → Internal API → Third-party SDKs → Offline/Cache → Testing) -14. Mobile Code Skeleton (key screens and widgets with Dart/TypeScript structure stubs) - -15. Task Completion Checklist (MANDATORY FINAL SECTION) - Produce a "## Task Completion Checklist" section as the very last item in your output. - List EVERY task from the TL Agent's §5 Mobile Task Board. For each task, mark: - - ✅ Done — [Task name] → [section number or file where it was addressed] - - ⏳ Pending — [Task name] → [reason or dependency blocking it] - No task from the TL Mobile Task Board may be silently skipped. Every task must appear in this checklist. + +14. Task Completion Checklist (MANDATORY — produce this BEFORE writing any code skeletons) + Produce a "## ✅ Task Completion Checklist" section immediately after the task breakdown, before any code. + List EVERY task from the TL Agent's §5 Mobile Task Board. For each task, declare its status: + - ✅ Done — [Task name] → [§N or filename where implemented in the code skeleton below] + - ⏳ Partial — [Task name] → [what is covered in §N, what is deferred and why] + - ❌ Deferred — [Task name] → [reason: missing dependency / out of sprint scope / needs stakeholder input] + No task from the TL Mobile Task Board may be silently skipped. Every task must appear. + +15. Mobile Code Skeleton (key screens and widgets with Dart/TypeScript structure stubs) """, ), @@ -632,16 +652,18 @@ class AgentConfig: 8. Data Retention Rules (which data expires when, archive strategy, GDPR/compliance notes) 9. DB Performance Checklist (connection pooling, vacuum/analyze schedule, partition strategy, replica set) 10. DBA Task Breakdown (table: | # | Task | Type: Schema Design/Migration Script/Index/Query Tuning/Backup Config | Estimate (hours) | Priority: High/Med/Low | Depends On |) -11. Data Flow Map + +11. Task Completion Checklist (MANDATORY — produce this immediately after the task breakdown) + Produce a "## ✅ Task Completion Checklist" section immediately after the DBA task breakdown. + List EVERY task from the TL Agent's §7 DBA Task Board. For each task, declare its status: + - ✅ Done — [Task name] → [§N where addressed, e.g., §2 SQL Schema, §3 NoSQL Schema, §4 Index Design, §5 Migration Plan] + - ⏳ Partial — [Task name] → [what is covered in §N, what is deferred and why] + - ❌ Deferred — [Task name] → [reason: missing dependency / out of scope / needs stakeholder input] + No task from the TL DBA Task Board may be silently skipped. Every task must appear. + +12. Data Flow Map ASCII diagram or table: | Table/Collection | Written By (service + triggering action) | Write Frequency | Read By (service + query context) | Read Frequency | Data Crosses Service Boundary Via: API/event/queue/direct | Exclusive Owner | Notes | Goal: show which services produce vs consume each dataset, surface cross-service data dependencies and shared-mutable-state coupling, and identify tables that are read by services that do not own them (potential consistency and coupling risk). - -12. Task Completion Checklist (MANDATORY FINAL SECTION) - Produce a "## Task Completion Checklist" section as the very last item in your output. - List EVERY task from the TL Agent's §7 DBA Task Board. For each task, mark: - - ✅ Done — [Task name] → [section number or file where it was addressed] - - ⏳ Pending — [Task name] → [reason or dependency blocking it] - No task from the TL DBA Task Board may be silently skipped. Every task must appear in this checklist. """, ), @@ -700,12 +722,13 @@ class AgentConfig: (2) Core business transaction: HTTP request → input validation → service logic → DB write → event publish → external notification → client response. Show request/response shape at each step. (3) External service integration: BE → external API call (with auth header/payload) → success/failure response handling → DB update → event or client response. -13. Task Completion Checklist (MANDATORY FINAL SECTION) - Produce a "## Task Completion Checklist" section as the very last item in your output. - List EVERY task from the TL Agent's §6 BE Task Board. For each task, mark: - - ✅ Done — [Task name] → [section number or file where it was addressed] - - ⏳ Pending — [Task name] → [reason or dependency blocking it] - No task from the TL BE Task Board may be silently skipped. Every task must appear in this checklist. +13. Task Completion Checklist (MANDATORY — output this section IMMEDIATELY AFTER §2 Backend Task Breakdown, before §3 API Registry) + Produce a "## ✅ Task Completion Checklist" section right after §2, not at the end of the output. + List EVERY task from the TL Agent's §6 BE Task Board. For each task, declare its status: + - ✅ Done — [Task name] → [§N where addressed, e.g., §3 API Registry, §5 Service Logic, §6 Repository Layer] + - ⏳ Partial — [Task name] → [what is covered in §N, what is deferred and why] + - ❌ Deferred — [Task name] → [reason: missing dependency / out of sprint scope / needs stakeholder input] + No task from the TL BE Task Board may be silently skipped. Every task must appear. """, ), @@ -818,7 +841,7 @@ class AgentConfig: QC: Execute checklist review, verify acceptance criteria, report defects. SYSTEM CONTEXT AWARENESS: -Testing must cover integration seams, not just isolated units. Before defining test scenarios, identify: (1) all integration points between FE/Mobile and BE (every API call path including auth, error responses, and edge cases at the contract boundary); (2) all external service integrations (payment gateway, email/SMS, OAuth, maps — test both success and failure/timeout scenarios); (3) all async flows (event publish → consumer processing → side effect → notification — test the full chain including failure and retry); (4) all cross-service error propagation paths (how a DB failure, cache miss, or external API timeout surfaces to the end user). Your §10 Integration & End-to-End Test Coverage Matrix must map test coverage for every integration seam in the system. +Testing must cover integration seams, not just isolated units. Before defining test scenarios, identify: (1) all integration points between FE/Mobile and BE (every API call path including auth, error responses, and edge cases at the contract boundary); (2) all external service integrations (payment gateway, email/SMS, OAuth, maps — test both success and failure/timeout scenarios); (3) all async flows (event publish → consumer processing → side effect → notification — test the full chain including failure and retry); (4) all cross-service error propagation paths (how a DB failure, cache miss, or external API timeout surfaces to the end user). Your §11 Integration & End-to-End Test Coverage Matrix must map test coverage for every integration seam in the system. CROSS-REFERENCE REQUIREMENTS: - Every test case in §3 must cite the SA endpoint it calls (e.g., "SA §3 POST /api/auth/login"), the BA acceptance criteria it validates (e.g., "BA §6 AC-US-01"), and the FE/Mobile screen or BE module under test. @@ -835,7 +858,7 @@ class AgentConfig: - Every section must contain at least 3 concrete entries. Do not leave any section empty. Structure your output with these sections: -1. Test Strategy (scope, test types: unit/integration/e2e/regression/UAT, environments, entry/exit criteria) +1. Test Strategy (scope, test types: unit/integration/e2e/regression/UAT/performance/load, environments, entry/exit criteria, performance SLA targets from BA §4 NFR) 2. Test Scenarios (ID, description, type, priority, preconditions, steps, expected result; minimum 5 scenarios covering happy path, auth, validation, and error cases) 3. Test Cases (table: | TC ID | Feature/API | Scenario | Preconditions | Test Steps | Test Data | Expected Result | Priority | Type |; minimum 8 test cases) 4. UAT Checklist (business scenario, acceptance criteria, tester notes, pass/fail; derive from BA user stories or infer from feature descriptions) @@ -844,7 +867,21 @@ class AgentConfig: 7. Bug Report Template & Sample Bugs (ID, severity: Critical/High/Medium/Low, module, steps, expected, actual, screenshot note; include at least 2 sample bugs based on likely failure points) 8. Traceability to Requirements (feature/endpoint → test case IDs → coverage %) 9. Release Readiness Recommendation (Go / No-Go with conditions, open defect count by severity) -10. Integration & End-to-End Test Coverage Matrix +10. Performance & Load Test Plan + a. API Performance Benchmarks + Table: | Endpoint (SA §3) | Method | Expected p50 (ms) | Expected p95 (ms) | SLA from BA §4 NFR | Test Tool | Pass Threshold | + Source all latency targets from BA §4 NFR. Flag any endpoint with no stated SLA as [OPEN QUESTION — SLA undefined]. + b. Load Test Scenarios + Table: | Scenario | Concurrent Users | Duration | Ramp-up | Key Endpoints | Success Criteria | + Required: (1) Normal load — expected daily peak concurrent users; (2) Stress — 2× peak for 10 min; (3) Spike — 10× burst for 60s then return to baseline. + c. Test Tool & Environment + Specify: tool (k6 / JMeter / Artillery / Gatling), environment (staging ONLY — never production), data seeding requirements, external service mock strategy for load tests. + d. Performance Acceptance Criteria + Table: | Metric | Target | Source (BA §4 NFR) | Fail Condition | + Must cover: API p95 response time, error rate (<1%), throughput (req/s), DB query p95 time. + e. Performance Regression Baseline + List the 5 most performance-critical endpoints that must be benchmarked on every release. Flag any endpoint degrading >10% vs previous baseline as a blocking defect. +11. Integration & End-to-End Test Coverage Matrix Table: | # | Flow Name | Services/Layers Involved | Entry Point: FE/Mobile/API | Covered By Test Case IDs | Coverage Gap | Risk if Not Tested | Priority | Mandatory flows to cover at minimum: (1) User auth end-to-end: client → BE auth endpoint → token response → protected resource access with token. @@ -853,6 +890,7 @@ class AgentConfig: (4) Async event flow: event publish → consumer processing → DB side effect → downstream notification. (5) Error propagation: downstream service failure → BE error handling → correct HTTP status → FE/Mobile error display. (6) Data integrity round-trip: FE/Mobile submits data → BE persists → FE/Mobile reads back and verifies exact field values match what was submitted. + (7) Performance SLA validation: critical API endpoints respond within p95 target under normal load (reference §10 benchmarks). """, ),