Version: 1.10
Date: March 20, 2026
Status: Draft
Related Document: Vision Document
Table of Contents
1. Introduction
1.1 Purpose
This document defines the functional and non-functional requirements for Forma3D.Connect, the integration services platform that connects Forma 3D's Shopify e-commerce system with SimplyPrint print farm management.
1.2 Scope
This requirements specification covers:
- Integration between Shopify and SimplyPrint
- Automated order processing workflows
- Administrative dashboard and monitoring
- Error handling and recovery mechanisms
1.3 Definitions and Acronyms
| Term |
Definition |
| API |
Application Programming Interface |
| DTO |
Data Transfer Object |
| POD |
Print-on-Demand |
| SKU |
Stock Keeping Unit |
| UUID |
Universally Unique Identifier |
| Webhook |
HTTP callback for real-time event notification |
2. System Overview
2.1 System Context

2.2 User Classes
| User Class |
Description |
Access Level |
| Administrator |
Full system access, configuration management |
Full |
| Operator |
Day-to-day monitoring, manual overrides |
Limited |
| System |
Automated processes, API integrations |
Programmatic |
3. Functional Requirements
3.1 Shopify Integration
FR-SH-001: Webhook Registration
| Attribute |
Value |
| ID |
FR-SH-001 |
| Title |
Shopify Webhook Registration |
| Description |
The system shall register webhooks with Shopify to receive real-time order notifications |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1, 2026-01-09) |
| Acceptance Criteria |
- System registers
orders/create webhook on startup/configuration - System registers
orders/updated webhook - System registers
orders/cancelled webhook - Webhook endpoints are secured with HMAC verification
|
FR-SH-002: Order Reception
| Attribute |
Value |
| ID |
FR-SH-002 |
| Title |
Receive and Process New Orders |
| Description |
The system shall receive new order notifications from Shopify and parse order details |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1, 2026-01-09) |
| Acceptance Criteria |
- Webhook payload is validated using HMAC-SHA256
- Order data is parsed and stored in local database
- Duplicate orders are detected and handled idempotently
- Order contains: ID, line items, customer info, shipping address
|
FR-SH-003: Product-to-Print Mapping
| Attribute |
Value |
| ID |
FR-SH-003 |
| Title |
Map Shopify Products to Print Files |
| Description |
The system shall maintain configuration mapping Shopify product variants to SimplyPrint print files/profiles |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1, 2026-01-09) |
| Acceptance Criteria |
- Admin can create/edit/delete product mappings
- Mapping includes: Shopify product/variant ID → SimplyPrint file ID + print profile (SKU optional)
- Multiple variants can map to different print files
- Unmapped products are flagged for manual review
|
FR-SH-004: Order Fulfillment
| Attribute |
Value |
| ID |
FR-SH-004 |
| Title |
Create Shopify Fulfillment |
| Description |
The system shall create fulfillment records in Shopify when prints are completed |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Acceptance Criteria |
- Fulfillment is created via Shopify Admin API
- Fulfillment includes all line items from completed print job
- Tracking information from Sendcloud is attached if available
- Order status updates to "fulfilled" in Shopify
|
FR-SH-005: Order Cancellation Handling
| Attribute |
Value |
| ID |
FR-SH-005 |
| Title |
Handle Order Cancellations |
| Description |
The system shall handle cancelled Shopify orders and cancel associated print jobs |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Acceptance Criteria |
- Cancelled order webhook triggers cancellation workflow
- If print job exists and not started, cancel in SimplyPrint
- If print job in progress, flag for operator review
- Local order status updated to "cancelled"
|
3.2 SimplyPrint Integration
FR-SP-001: Authentication
| Attribute |
Value |
| ID |
FR-SP-001 |
| Title |
SimplyPrint API Authentication |
| Description |
The system shall authenticate with SimplyPrint API using secure credentials |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 2, 2026-01-13) |
| Acceptance Criteria |
- API key/token stored securely (environment variables, not in code)
- Authentication tested on system startup
- Authentication failures trigger alerts
- Token refresh handled if applicable
|
Implementation Details:
- HTTP Basic Authentication with company ID and API key
- Credentials stored in environment variables (SIMPLYPRINT_API_KEY, SIMPLYPRINT_COMPANY_ID)
- Connection verification on module initialization
- Sentry alerts on authentication failures
FR-SP-002: Print Job Creation
| Attribute |
Value |
| ID |
FR-SP-002 |
| Title |
Create Print Jobs from Orders |
| Description |
The system shall create print jobs in SimplyPrint for each eligible order line item |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 2, 2026-01-13) |
| Acceptance Criteria |
- Print job created within 60 seconds of order reception
- Job includes: file reference, quantity, print profile settings
- Job is assigned to appropriate print queue
- Job creation confirmation stored in local database
- Multiple line items create multiple jobs (or batched as appropriate)
|
Implementation Details:
- Automatic print job creation via OrchestrationService when orders are created
- Supports assembly products (multiple parts per product)
- Product mapping lookup for file references
- Idempotent job creation (prevents duplicates)
FR-SP-003: Print Job Status Monitoring
| Attribute |
Value |
| ID |
FR-SP-003 |
| Title |
Monitor Print Job Status |
| Description |
The system shall track print job status changes in SimplyPrint |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 2, 2026-01-13) |
| Acceptance Criteria |
- Status updates received via webhook or polling (based on API capability)
- Statuses tracked: queued, printing, completed, failed, cancelled
- Status changes logged with timestamps
- Status changes trigger appropriate downstream actions
|
Implementation Details:
- Webhook endpoint at POST /webhooks/simplyprint with X-SP-Token verification
- Polling fallback (configurable via SIMPLYPRINT_POLLING_ENABLED)
- Status mapping: queued → assigned → printing → completed/failed/cancelled
- EventLog entries for all status changes
FR-SP-004: Print Job Completion Handling
| Attribute |
Value |
| ID |
FR-SP-004 |
| Title |
Handle Print Job Completion |
| Description |
The system shall detect print job completion and trigger fulfillment workflow |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 2, 2026-01-13) |
| Acceptance Criteria |
- Completion event triggers within 60 seconds of actual completion
- All line items for an order checked for completion
- When all items complete, order marked ready for fulfillment
- Partial fulfillment supported (configurable)
|
Implementation Details:
- OrchestrationService tracks job completion per order
- Emits order.ready-for-fulfillment event when all jobs complete
- Supports partial completion (PARTIALLY_COMPLETED status)
FR-SP-005: Print Job Failure Handling
| Attribute |
Value |
| ID |
FR-SP-005 |
| Title |
Handle Print Job Failures |
| Description |
The system shall handle failed print jobs and notify operators |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 2, 2026-01-13) |
| Acceptance Criteria |
- Failed job triggers notification to operator
- Failure reason captured if available from API
- Automatic retry option (configurable)
- Manual retry/cancel option in dashboard
|
Implementation Details:
- Error message captured from SimplyPrint API
- Sentry alerts for failures (5xx errors)
- EventLog entries with requiresAttention: true for operator review
- Retry endpoint: POST /api/v1/print-jobs/:id/retry
- Cancel endpoint: POST /api/v1/print-jobs/:id/cancel
- Maximum retry count configurable (default: 3)
FR-SP-006: Printer Status Visibility
| Attribute |
Value |
| ID |
FR-SP-006 |
| Title |
Display Printer Status |
| Description |
The system shall display current status of all connected printers |
| Priority |
Should Have |
| Status |
— |
| Acceptance Criteria |
- Dashboard shows all printers with current status
- Status includes: online/offline, idle/printing, current job
- Real-time updates via Socket.IO
|
3.3 Shipping Integration
FR-SC-001: Shipping Label Generation
| Attribute |
Value |
| ID |
FR-SC-001 |
| Title |
Generate Shipping Labels via Sendcloud |
| Description |
The system shall generate shipping labels when orders are ready to ship |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 5, 2026-01-16) |
| Acceptance Criteria |
- Label generated via Sendcloud API upon order completion
- Shipping method selected based on order/destination
- Tracking number retrieved and stored
- Label PDF available for download/printing
|
Implementation Notes: Sendcloud API client at apps/api/src/sendcloud/sendcloud-api.client.ts. Shipment model stores parcel ID, tracking info, label URL. Labels generated on order.ready-for-fulfillment event.
| Attribute |
Value |
| ID |
FR-SC-002 |
| Title |
Sync Tracking Information to Shopify |
| Description |
The system shall sync tracking information to Shopify fulfillment |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 5, 2026-01-16) |
| Acceptance Criteria |
- Tracking number added to Shopify fulfillment
- Carrier name identified correctly
- Customer receives automated shipping notification from Shopify
|
Implementation Notes: Tracking number and URL from Sendcloud stored in Order model. Fulfillment service uses tracking info when creating Shopify fulfillment. Shipment status (from SendCloud webhooks) is surfaced on every order API response via shipmentStatus field, enabling the dashboard to show real-time shipping progress (Label Created → In Transit → Delivered).
3.4 Administrative Dashboard
FR-AD-001: Order Queue View
| Attribute |
Value |
| ID |
FR-AD-001 |
| Title |
View Order Processing Queue |
| Description |
The dashboard shall display all orders in the processing pipeline |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- List view of all orders with status
- Filter by order status: pending, processing, partially completed, completed, failed, cancelled
- Filter by shipping status: ready to ship, in transit, delivered, shipping issues
- Shipping status badge displayed alongside order status when a shipment exists
- Search by order number or customer
- Real-time updates without page refresh
|
Implementation: apps/web/src/pages/orders/index.tsx — Order list with order status filtering, shipping status filtering (Ready to Ship, In Transit, Delivered, Shipping Issues), shipping status badges, pagination, and real-time updates via Socket.IO. API returns shipmentStatus field on every order response. Backend supports shipmentStatus and readyToShip query parameters.
FR-AD-002: Order Detail View
| Attribute |
Value |
| ID |
FR-AD-002 |
| Title |
View Order Details |
| Description |
The dashboard shall display detailed information for individual orders |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- Order information from Shopify displayed
- Associated print jobs with status
- Event timeline/audit log
- Manual action buttons (retry, cancel, force fulfill)
|
Implementation: apps/web/src/pages/orders/[id].tsx — Order detail page with customer info, line items, print jobs, and action buttons.
FR-AD-003: Product Mapping Management
| Attribute |
Value |
| ID |
FR-AD-003 |
| Title |
Manage Product-to-Print Mappings |
| Description |
The dashboard shall allow configuration of product-to-print-file mappings |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- List all Shopify products/variants
- Associate each with SimplyPrint file and profile
- Bulk import/export of mappings
- Validation of mapping completeness
|
Implementation: apps/web/src/pages/mappings/ — Mapping list and create/edit form with assembly parts editor.
FR-AD-004: System Configuration
| Attribute |
Value |
| ID |
FR-AD-004 |
| Title |
System Configuration Interface |
| Description |
The dashboard shall provide configuration options for system behavior |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- API credentials management (Shopify, SimplyPrint, Sendcloud)
- Webhook URL display and regeneration
- Notification settings (email, webhook)
- Retry policy configuration
- Partial fulfillment toggle
|
Implementation: apps/web/src/pages/settings/index.tsx — Settings page with connection status and system info.
FR-AD-005: Activity Logs
| Attribute |
Value |
| ID |
FR-AD-005 |
| Title |
View Activity Logs |
| Description |
The dashboard shall display system activity and error logs |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- Chronological log of all system events
- Filter by event type, severity, date
- Log retention configurable (default 30 days)
- Export capability for troubleshooting
|
Implementation: apps/web/src/pages/logs/index.tsx — Activity logs with severity/event type filtering and CSV export.
FR-AD-006: Manual Order Processing
| Attribute |
Value |
| ID |
FR-AD-006 |
| Title |
Manual Order Processing Actions |
| Description |
The dashboard shall allow manual intervention in the order processing workflow |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 4, 2026-01-14) |
| Acceptance Criteria |
- Retry failed print job
- Cancel pending print job
- Force mark order as fulfilled
- Re-sync order from Shopify
- All manual actions logged with operator ID
|
Implementation: apps/web/src/pages/orders/[id].tsx — Retry, cancel, and manual action buttons with API key authentication.
3.5 Notifications
FR-NO-001: Error Notifications
| Attribute |
Value |
| ID |
FR-NO-001 |
| Title |
Send Error Notifications |
| Description |
The system shall send notifications when errors occur |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Acceptance Criteria |
- Email notification for critical errors
- Dashboard notification for all errors
- Notification includes: error type, affected order, timestamp
- Configurable notification recipients
|
FR-NO-002: Daily Summary
| Attribute |
Value |
| ID |
FR-NO-002 |
| Title |
Daily Summary Report |
| Description |
The system shall generate daily summary of processing activity |
| Priority |
Could Have |
| Status |
— |
| Acceptance Criteria |
- Orders processed count
- Success/failure rates
- Average processing time
- Sent via email at configurable time
|
4. Non-Functional Requirements
NFR-PE-001: Order Processing Latency
| Attribute |
Value |
| ID |
NFR-PE-001 |
| Description |
Time from Shopify webhook to SimplyPrint job creation |
| Priority |
Must Have |
| Status |
— |
| Target |
< 60 seconds for 95% of orders |
| Maximum |
< 5 minutes for 99.9% of orders |
| Measurement |
Automated monitoring, timestamp comparison |
NFR-PE-002: Fulfillment Latency
| Attribute |
Value |
| ID |
NFR-PE-002 |
| Description |
Time from SimplyPrint job completion to Shopify fulfillment |
| Priority |
Must Have |
| Status |
— |
| Target |
< 60 seconds for 95% of orders |
| Maximum |
< 5 minutes for 99.9% of orders |
| Measurement |
Automated monitoring, timestamp comparison |
NFR-PE-003: Dashboard Response Time
| Attribute |
Value |
| ID |
NFR-PE-003 |
| Description |
Page load and API response times for dashboard |
| Priority |
Must Have |
| Status |
— |
| Target |
< 500ms for 95% of requests |
| Maximum |
< 2 seconds for 99% of requests |
| Measurement |
Frontend performance monitoring |
NFR-PE-004: Concurrent Order Processing
| Attribute |
Value |
| ID |
NFR-PE-004 |
| Description |
Number of orders that can be processed simultaneously |
| Priority |
Must Have |
| Status |
— |
| Target |
100 concurrent orders |
| Measurement |
Load testing |
4.2 Scalability Requirements
NFR-SC-001: Daily Order Volume
| Attribute |
Value |
| ID |
NFR-SC-001 |
| Description |
Maximum orders processed per day |
| Priority |
Must Have |
| Status |
— |
| Target |
1,000 orders/day |
| Growth |
Design to scale to 10,000 orders/day |
| Measurement |
Production metrics |
NFR-SC-002: Database Growth
| Attribute |
Value |
| ID |
NFR-SC-002 |
| Description |
Database can handle growing historical data |
| Priority |
Should Have |
| Status |
— |
| Target |
5 years of data without performance impact |
| Strategy |
Data archival, indexing, partitioning |
4.3 Availability Requirements
NFR-AV-001: System Uptime
| Attribute |
Value |
| ID |
NFR-AV-001 |
| Description |
Overall system availability |
| Priority |
Must Have |
| Status |
— |
| Target |
99.9% uptime (8.76 hours downtime/year) |
| Measurement |
Statping-ng monitoring |
NFR-AV-002: Planned Maintenance Window
| Attribute |
Value |
| ID |
NFR-AV-002 |
| Description |
Scheduled maintenance periods |
| Priority |
Should Have |
| Status |
— |
| Target |
< 4 hours/month, off-peak hours |
| Notification |
24 hours advance notice |
NFR-AV-003: Recovery Time Objective (RTO)
| Attribute |
Value |
| ID |
NFR-AV-003 |
| Description |
Time to restore service after failure |
| Priority |
Must Have |
| Status |
— |
| Target |
< 1 hour |
| Strategy |
Automated restart, redundancy |
NFR-AV-004: Recovery Point Objective (RPO)
| Attribute |
Value |
| ID |
NFR-AV-004 |
| Description |
Maximum data loss acceptable |
| Priority |
Must Have |
| Status |
— |
| Target |
< 5 minutes |
| Strategy |
Real-time database replication |
4.4 Security Requirements
NFR-SE-001: API Authentication
| Attribute |
Value |
| ID |
NFR-SE-001 |
| Description |
All API communications must be authenticated |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1: 2026-01-09, Phase 2: 2026-01-13, Phase 3: 2026-01-14) |
| Implementation |
HMAC webhook verification (Shopify), Token verification (SimplyPrint), API keys (Admin) |
| Storage |
Credentials in environment variables, never in code |
Authentication Methods:
| Endpoint Type |
Method |
Header |
Status |
| Shopify Webhooks |
HMAC-SHA256 Signature |
X-Shopify-Hmac-Sha256 |
✅ Phase 1 (2026-01-09) |
| SimplyPrint Webhooks |
Token Verification |
X-SP-Token |
✅ Phase 2 (2026-01-13) |
| Admin Endpoints |
API Key |
X-API-Key |
✅ Phase 3 (2026-01-14) |
| Public Endpoints |
None (health, docs) |
- |
By design |
NFR-SE-002: Data Encryption in Transit
| Attribute |
Value |
| ID |
NFR-SE-002 |
| Description |
All data in transit must be encrypted |
| Priority |
Must Have |
| Status |
✅ Implemented (Let's Encrypt via Traefik in Docker Compose; 2026-01-10 phase-1c deployment, 2026-01-16 phase-5) |
| Implementation |
TLS 1.2+ via Traefik; certificates from Let's Encrypt (certresolver=letsencrypt in deployment/staging/docker-compose.yml, traefik.yml) |
| Verification |
Security audit |
Traceability: .specstory/history/2026-01-10_19-58Z-phase-1c-deployment-prompt-execution.md, 2026-01-16_11-19Z-phase-5-prompt-documentation.md, docs/_internal/prompts/done/prompt-phase6.md
NFR-SE-003: Data Encryption at Rest
| Attribute |
Value |
| ID |
NFR-SE-003 |
| Description |
Sensitive data at rest must be encrypted |
| Priority |
Must Have |
| Status |
— |
| Implementation |
Database encryption, encrypted backups |
| Scope |
API keys, customer PII |
NFR-SE-004: Access Control
| Attribute |
Value |
| ID |
NFR-SE-004 |
| Description |
Dashboard access must be controlled |
| Priority |
Should Have |
| Status |
✅ Implemented (Keycloak/RBAC; 2026-01-25) |
| Implementation |
Keycloak authentication, RBAC, user management |
| Future |
SSO integration option |
Traceability: .specstory/history/2026-01-21_20-12Z-user-accounts-and-permissions-with-keycloak.md, 2026-01-24_16-51Z-rbac-multitenancy-prompt.md, 2026-01-25_16-23Z-rbac-user-management-functionality.md
NFR-SE-005: Audit Logging
| Attribute |
Value |
| ID |
NFR-SE-005 |
| Description |
All administrative actions must be logged |
| Priority |
Must Have |
| Status |
✅ Implemented (EventLog entity, audit service; Phase 1–2, 2026-01-09 / 2026-01-13) |
| Implementation |
EventLog/audit service; immutable audit log with user, action, timestamp |
| Retention |
1 year minimum |
Traceability: .specstory/history/2026-01-09_20-04Z-phase-1-prompt-execution.md, 2026-01-13_15-49Z-prompt-phase-2-execution.md; code: libs/service-common/src/lib/audit/, libs/domain/src/entities/event-log.ts
NFR-SE-006: Continuous Security Monitoring (Syft + Grype)
| Attribute |
Value |
| ID |
NFR-SE-006 |
| Description |
Continuous container security via Syft (SBOM) + Grype (CVE scanning) in CI/CD pipeline |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1, updated March 2026) |
| Implementation |
Syft generates CycloneDX SBOMs; Grype scans SBOMs for CVEs — both run in CI/CD |
| Scope |
Container image CVE scanning, SBOM generation for supply chain transparency |
Security Pipeline:
| Check |
Tool |
Description |
| SBOM Generation |
Syft |
CycloneDX SBOM generated for each container image |
| CVE Scanning |
Grype |
Scans SBOMs for known vulnerabilities, fails on High/Critical CVEs |
| Image Signing |
Cosign |
Cryptographic image signing with SBOM attestation |
Note: Aikido was previously used as a SaaS security platform. It was replaced by Syft + Grype (open-source tools by Anchore) to eliminate external SaaS dependency and run scanning directly in the CI/CD pipeline.
NFR-SE-007: Software Bill of Materials (SBOM)
| Attribute |
Value |
| ID |
NFR-SE-007 |
| Description |
Generate SBOM for software supply chain transparency |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1, 2026-01-09) |
| Implementation |
Automated CycloneDX SBOM generation via Syft in CI/CD pipeline |
| Format |
Standard SBOM format for dependency tracking |
NFR-SE-008: Admin Endpoint Authorization
| Attribute |
Value |
| ID |
NFR-SE-008 |
| Description |
Admin endpoints must require authentication to prevent unauthorized access |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Implementation |
API Key authentication via X-API-Key header with timing-safe comparison |
| Scope |
Fulfillment endpoints, Cancellation endpoints |
Protected Endpoints:
| Endpoint |
Protection |
POST /api/v1/fulfillments/order/:orderId |
API Key |
POST /api/v1/fulfillments/order/:orderId/force |
API Key |
GET /api/v1/fulfillments/order/:orderId/status |
API Key |
POST /api/v1/cancellations/order/:orderId |
API Key |
POST /api/v1/cancellations/print-job/:jobId |
API Key |
Security Features:
- Timing-safe comparison prevents timing attacks
- Generic error messages prevent information leakage
- Audit logging for access attempts
- Development mode allows bypass when key not configured
4.5 Acceptance Testing Requirements
The project requires automated acceptance testing to verify deployments:
NFR-AT-001: Acceptance Testing
| Attribute |
Value |
| ID |
NFR-AT-001 |
| Description |
Automated acceptance tests must verify deployment success |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1d, 2026-01-12) |
| Implementation |
Playwright + Gherkin in Nx monorepo |
| Scope |
Health checks, API docs, Web dashboard smoke tests |
| Trigger |
Runs automatically after staging deployment |
NFR-AT-002: Gherkin Syntax
| Attribute |
Value |
| ID |
NFR-AT-002 |
| Description |
Test scenarios must use Given/When/Then format |
| Priority |
Should Have |
| Status |
✅ Implemented (Phase 1d, 2026-01-12) |
| Implementation |
Gherkin feature files with Cucumber |
| Purpose |
Readable by non-developers, documentation of acceptance criteria |
NFR-AT-003: CI/CD Integration
| Attribute |
Value |
| ID |
NFR-AT-003 |
| Description |
Acceptance tests integrated into Azure DevOps pipeline |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1d, 2026-01-12) |
| Implementation |
Pipeline stage after staging deployment |
| Reporting |
JUnit results, HTML report as artifact |
| Failure |
Pipeline fails if acceptance tests fail |
NFR-AT-004: Test Isolation
| Attribute |
Value |
| ID |
NFR-AT-004 |
| Description |
Tests must be idempotent and isolated |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1d, 2026-01-12) |
| Requirements |
No inter-test dependencies, CI-safe, no production data modification |
| Environment |
Target staging only, URLs via environment variables |
4.6 Observability Requirements (Sentry)
The project integrates Sentry for comprehensive observability with an OpenTelemetry-first architecture:
NFR-OB-001: Error Tracking
| Attribute |
Value |
| ID |
NFR-OB-001 |
| Description |
All application errors must be captured and reported |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10) |
| Implementation |
Sentry SDK integrated in backend (NestJS) and frontend (React) |
| Scope |
Unhandled exceptions, handled errors, React component failures |
| Context |
Stack traces, request context, user context, breadcrumbs |
| Attribute |
Value |
| ID |
NFR-OB-002 |
| Description |
Application performance must be continuously monitored |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10) |
| Implementation |
Sentry Performance Monitoring with OpenTelemetry instrumentation |
| Metrics |
HTTP request latency, database query duration, custom spans |
| Target |
P95 latency < 500ms for API endpoints |
NFR-OB-003: Distributed Tracing
| Attribute |
Value |
| ID |
NFR-OB-003 |
| Description |
End-to-end request tracing across all system components |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10) |
| Implementation |
OpenTelemetry SDK with OTLP export to Sentry |
| Propagation |
Trace context propagated via HTTP headers (W3C Trace Context) |
| Correlation |
Request ID / Trace ID included in all logs |
NFR-OB-004: Structured Logging
| Attribute |
Value |
| ID |
NFR-OB-004 |
| Description |
All logs must be structured JSON with consistent format |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10) |
| Implementation |
Pino logger with nestjs-pino integration |
| Fields |
timestamp, level, message, traceId, requestId, context |
| Redaction |
Sensitive fields (password, token, apiKey) automatically redacted |
NFR-OB-005: Sampling Configuration
| Attribute |
Value |
| ID |
NFR-OB-005 |
| Description |
Sampling configuration for Sentry event limits |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10) |
| Configuration |
100% sampling (adjustable when traffic increases) |
| Limits |
10,000 errors/month, 10,000 performance events/month (Free Tier) |
4.6 Data Privacy Requirements
NFR-DP-001: GDPR Compliance
| Attribute |
Value |
| ID |
NFR-DP-001 |
| Description |
System must comply with GDPR |
| Priority |
Must Have |
| Status |
— |
| Implementation |
Data minimization, purpose limitation, retention policies |
| Documentation |
Data processing records |
NFR-DP-002: Data Minimization
| Attribute |
Value |
| ID |
NFR-DP-002 |
| Description |
Only store necessary customer data |
| Priority |
Must Have |
| Status |
— |
| Scope |
Name, address (shipping), order details |
| Excluded |
Payment information (stays in Shopify) |
NFR-DP-003: Data Retention
| Attribute |
Value |
| ID |
NFR-DP-003 |
| Description |
Customer data retained only as long as necessary |
| Priority |
Must Have |
| Status |
— |
| Active Orders |
Until fulfillment + 90 days |
| Historical |
Anonymized after 2 years |
4.6 Reliability Requirements
NFR-RE-001: Idempotency
| Attribute |
Value |
| ID |
NFR-RE-001 |
| Description |
Operations must be idempotent to handle retries |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1: duplicate order detection; webhook idempotency; 2026-01-09) |
| Implementation |
Duplicate order detection (FR-SH-002); webhook-idempotency repositories (SimplyPrint, Sendcloud); idempotent job creation |
| Scope |
Webhook processing, API calls |
Traceability: .specstory/history/2026-01-09_20-04Z-phase-1-prompt-execution.md; code: libs/service-common/src/lib/sendcloud/sendcloud-webhook.service.ts (database-backed idempotency), apps/*/src/webhook-idempotency/, order creation with duplicate handling
NFR-RE-002: Graceful Degradation
| Attribute |
Value |
| ID |
NFR-RE-002 |
| Description |
System continues operating during partial failures |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Example |
If SimplyPrint unavailable, queue orders for retry |
| Implementation |
Retry queue with exponential backoff |
NFR-RE-003: Error Recovery
| Attribute |
Value |
| ID |
NFR-RE-003 |
| Description |
Automatic retry for transient failures |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 3, 2026-01-14) |
| Strategy |
Exponential backoff with jitter |
| Implementation |
RetryQueue service with configurable max attempts (5) |
| Maximum Retries |
5 attempts over 24 hours |
4.7 Maintainability Requirements
NFR-MA-001: Code Quality
| Attribute |
Value |
| ID |
NFR-MA-001 |
| Description |
Code must meet quality standards |
| Priority |
Must Have |
| Status |
✅ Implemented (ESLint from Phase 1, 2026-01-09; SonarCloud 2026-03-12) |
| Standards |
TypeScript strict mode, no any, ESLint passing |
| Verification |
CI/CD pipeline checks, SonarCloud quality gate |
Traceability: .specstory/history/2026-01-09_20-04Z-phase-1-prompt-execution.md, 2026-03-12_17-18Z-sonarcloud-integration-prompt.md, 2026-03-13_*sonarcloud*.md
NFR-MA-002: Test Coverage
| Attribute |
Value |
| ID |
NFR-MA-002 |
| Description |
Automated test coverage requirements |
| Priority |
Must Have |
| Status |
✅ Implemented (coverage threshold in CI 2026-01-10; SonarCloud 2026-03) |
| Unit Tests |
> 80% coverage |
| Integration Tests |
All API integrations covered |
| E2E Tests |
Critical paths covered |
Traceability: .specstory/history/2026-01-10_16-00Z-pipeline-code-coverage-threshold-not-met.md, 2026-03-12_17-18Z-sonarcloud-integration-prompt.md, 2026-03-13_*coverage*.md
NFR-MA-003: Documentation
| Attribute |
Value |
| ID |
NFR-MA-003 |
| Description |
System must be documented |
| Priority |
Should Have |
| Status |
Partially implemented (API docs, architecture) |
| API Docs |
✅ OpenAPI/Swagger specification — Implemented |
| Architecture |
✅ Decision records (13 ADRs), C4 diagrams — Implemented (docs/03-architecture/) |
| Operations |
Runbook, troubleshooting guide |
OpenAPI/Swagger Implementation Details:
- Interactive Swagger UI:
/api/docs (non-production only)
- OpenAPI 3.0 JSON:
/api/docs-json
- All endpoints documented with
@ApiTags, @ApiOperation, @ApiResponse
- All DTOs documented with
@ApiProperty decorators
- Request/response schemas auto-generated
- Grouped by feature: Health, Orders, Product Mappings, Shopify Webhooks
NFR-MA-004: Logging
| Attribute |
Value |
| ID |
NFR-MA-004 |
| Description |
Comprehensive logging for debugging |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 1b, 2026-01-10 — Pino, structured JSON) |
| Format |
Structured JSON logs |
| Levels |
Error, Warn, Info, Debug |
| Correlation |
Request/order correlation IDs |
Traceability: .specstory/history/2026-01-10_15-01Z-observability-phase-implementation.md (NFR-OB-004 same phase); code: Pino/nestjs-pino
4.8 Compatibility Requirements
NFR-CO-001: Browser Support
| Attribute |
Value |
| ID |
NFR-CO-001 |
| Description |
Dashboard browser compatibility |
| Priority |
Must Have |
| Status |
✅ Implemented (Phase 4 dashboard 2026-01-14; React 19, Tailwind, modern browsers) |
| Supported |
Chrome (latest 2), Firefox (latest 2), Safari (latest 2), Edge (latest 2) |
Traceability: .specstory/history/2026-01-14_19-31Z-phase-4-prompt-document.md
NFR-CO-002: API Version Compatibility
| Attribute |
Value |
| ID |
NFR-CO-002 |
| Description |
Handle API version changes gracefully |
| Priority |
Should Have |
| Status |
— |
| Strategy |
Version pinning, changelog monitoring |
| Shopify |
Support at least 2 recent API versions |
5. API Specifications
5.1 Shopify API Requirements
5.1.1 Required Shopify Scopes
read_orders
write_orders
read_products
read_fulfillments
write_fulfillments
read_inventory
read_merchant_managed_fulfillment_orders
write_merchant_managed_fulfillment_orders
5.1.2 Webhook Topics Required
| Topic |
Purpose |
orders/create |
Trigger new order processing |
orders/updated |
Handle order modifications |
orders/cancelled |
Cancel associated print jobs |
orders/fulfilled |
Detect external fulfillments |
5.1.3 REST/GraphQL Endpoints Used
| Endpoint |
Method |
Purpose |
/admin/api/2024-01/orders.json |
GET |
Retrieve order details |
/admin/api/2024-01/orders/{id}.json |
GET |
Get specific order |
/admin/api/2024-01/fulfillments.json |
POST |
Create fulfillment |
/admin/api/2024-01/products.json |
GET |
List products for mapping |
5.2 SimplyPrint API Requirements
5.2.1 Expected Capabilities
| Capability |
Description |
| Authentication |
API key or OAuth token |
| List Files |
Retrieve available print files |
| Create Job |
Queue a print job for a specific file |
| Job Status |
Get current status of a job |
| Cancel Job |
Cancel a pending/queued job |
| Printer List |
Get list of available printers |
| Printer Status |
Get current status of printers |
5.2.2 Webhook/Polling Requirements
| Event |
Mechanism |
Purpose |
| Job Queued |
Webhook/Poll |
Confirm job created |
| Job Started |
Webhook/Poll |
Track print progress |
| Job Completed |
Webhook/Poll |
Trigger fulfillment |
| Job Failed |
Webhook/Poll |
Alert operators |
5.3 Sendcloud API Requirements
5.3.1 Required Capabilities
| Capability |
Description |
| Create Parcel |
Generate shipping label |
| Get Label |
Download label PDF |
| Get Tracking |
Retrieve tracking information |
6. Data Requirements
6.1 Data Entities
6.1.1 Order
| Field |
Type |
Description |
| id |
UUID |
Internal identifier |
| shopifyOrderId |
String |
Shopify order ID |
| shopifyOrderNumber |
String |
Human-readable order number |
| status |
Enum |
pending, processing, completed, failed, cancelled |
| customerName |
String |
Customer full name |
| shippingAddress |
JSON |
Shipping address object |
| lineItems |
Relation |
Associated line items |
| createdAt |
DateTime |
Order creation timestamp |
| updatedAt |
DateTime |
Last update timestamp |
| completedAt |
DateTime |
Fulfillment timestamp |
6.1.2 LineItem
| Field |
Type |
Description |
| id |
UUID |
Internal identifier |
| orderId |
UUID |
Parent order reference |
| shopifyLineItemId |
String |
Shopify line item ID |
| shopifyProductId |
String? |
Shopify product ID (for matching) |
| shopifyVariantId |
String? |
Shopify variant ID (for matching) |
| productSku |
String |
Product SKU |
| productName |
String |
Product name |
| quantity |
Integer |
Quantity ordered |
| printJobId |
UUID |
Associated print job |
| status |
Enum |
pending, printing, completed, failed |
6.1.3 PrintJob
| Field |
Type |
Description |
| id |
UUID |
Internal identifier |
| simplyPrintJobId |
String |
SimplyPrint job ID (mutable; updated from queue-item ID to job UID) |
| simplyPrintQueueItemId |
String |
Persistent SimplyPrint queue-item ID (never overwritten) |
| lineItemId |
UUID |
Associated line item |
| status |
Enum |
queued, printing, completed, failed, cancelled |
| printerId |
String |
Assigned printer ID |
| startedAt |
DateTime |
Print start timestamp |
| completedAt |
DateTime |
Print completion timestamp |
| errorMessage |
String |
Error details if failed |
6.1.4 ProductMapping
| Field |
Type |
Description |
| id |
UUID |
Internal identifier |
| shopifyProductId |
String |
Shopify product ID |
| shopifyVariantId |
String |
Shopify variant ID |
| sku |
String? |
Product SKU (optional) |
| simplyPrintFileId |
String |
SimplyPrint file reference |
| printProfile |
JSON |
Print settings/profile |
| isActive |
Boolean |
Mapping enabled |
6.1.5 EventLog
| Field |
Type |
Description |
| id |
UUID |
Internal identifier |
| orderId |
UUID |
Related order (nullable) |
| eventType |
String |
Event type identifier |
| severity |
Enum |
info, warning, error |
| message |
String |
Event description |
| metadata |
JSON |
Additional event data |
| createdAt |
DateTime |
Event timestamp |
6.2 Data Flow

7. Interface Requirements
7.1 User Interface Requirements
UI-001: Dashboard Layout
- Clean, modern design using Tailwind CSS
- Responsive layout (desktop-first, mobile-compatible)
- Left sidebar navigation
- Main content area with contextual actions
UI-002: Order List View
- Table with sortable columns
- Status indicators with color coding
- Quick action buttons per row
- Pagination (50 items per page default)
UI-003: Order Detail View
- Two-column layout: order info + timeline
- Line item status indicators
- Action buttons: Retry, Cancel, Force Fulfill
- Print job details expandable
UI-004: Configuration Pages
- Form-based input with validation
- Clear success/error feedback
- Connection test buttons for API credentials
7.2 API Interface Requirements
API-001: Internal REST API
- Versioned endpoints (
/api/v1/...)
- JSON request/response format
- Consistent error response structure
- ✅ OpenAPI documentation — Implemented at
/api/docs
API-002: Webhook Endpoints
/api/v1/webhooks/shopify - Shopify webhook receiver
/webhooks/simplyprint - SimplyPrint webhook receiver
- HMAC signature verification
- Idempotent processing
API-003: OpenAPI/Swagger Documentation
| Attribute |
Value |
| ID |
API-003 |
| Title |
Interactive API Documentation |
| Description |
Swagger UI for exploring and testing API endpoints |
| Priority |
Must Have |
| Status |
✅ Implemented |
| Endpoints |
/api/docs — Swagger UI interface/api/docs-json — OpenAPI 3.0 JSON spec
|
| Features |
- Interactive endpoint testing
- Request/response schema documentation
- Grouped by feature tags
- Available in non-production environments only
|
8. Constraints
8.1 Technical Constraints
| ID |
Constraint |
Rationale |
| TC-001 |
Must use Nx monorepo structure |
Project standard |
| TC-002 |
TypeScript strict mode required |
Code quality |
| TC-003 |
NestJS for backend |
Project standard |
| TC-004 |
React 19 for frontend |
Project standard |
| TC-005 |
PostgreSQL for database |
Project standard |
| TC-006 |
Prisma ORM only |
Database abstraction standard |
8.2 Business Constraints
| ID |
Constraint |
Rationale |
| BC-001 |
Single tenant design |
Single printfarm operation |
| BC-002 |
Must integrate with existing Shopify store |
Business continuity |
| BC-003 |
Must integrate with existing SimplyPrint setup |
Business continuity |
8.3 External Constraints
| ID |
Constraint |
Impact |
| EC-001 |
Shopify API rate limits |
Request throttling required |
| EC-002 |
SimplyPrint API limitations |
Design within API capabilities |
| EC-003 |
Sendcloud API requirements |
Follow integration guidelines |
9. Traceability Matrix
| Requirement |
Vision Objective |
Priority |
| FR-SH-001 |
O1 |
Must Have |
| FR-SH-002 |
O1 |
Must Have |
| FR-SH-003 |
O1 |
Must Have |
| FR-SH-004 |
O2 |
Must Have |
| FR-SP-002 |
O1 |
Must Have |
| FR-SP-003 |
O3 |
Must Have |
| FR-SP-004 |
O2 |
Must Have |
| FR-AD-001 |
O5 |
Must Have |
| NFR-AV-001 |
O6 |
Must Have |
| NFR-SC-001 |
O7 |
Must Have |
| NFR-SE-005 |
O8 |
Must Have |
| NFR-SE-006 |
O9 |
Must Have |
| NFR-SE-007 |
O9 |
Must Have |
| NFR-OB-001 |
O10 |
Must Have |
| NFR-OB-002 |
O10 |
Must Have |
| NFR-OB-003 |
O10 |
Must Have |
| NFR-OB-004 |
O10 |
Must Have |
| NFR-OB-005 |
O10 |
Must Have |
| NFR-AT-001 |
O11 |
Must Have |
| NFR-AT-002 |
O11 |
Should Have |
| NFR-AT-003 |
O11 |
Must Have |
| NFR-AT-004 |
O11 |
Must Have |
10. Acceptance Criteria Summary
10.1 MVP Acceptance
The MVP is considered complete when:
- ✓ New Shopify orders automatically create SimplyPrint print jobs
- ✓ Completed print jobs automatically trigger Shopify fulfillment
- ✓ Admin dashboard shows order pipeline with status
- ✓ Manual override capabilities available
- ✓ Error notifications sent to operators
- ✓ System achieves 95% automation success rate
- ✓ System achieves 99% uptime over 2-week test period
- ✅ API documentation available via Swagger UI — Implemented
10.2 Production Release Criteria
- All MVP criteria met
- Load testing passes for 500 orders/day
- Security review completed
- Documentation complete
- Runbook validated
- Backup/recovery tested
11. Document Approval
| Role |
Name |
Signature |
Date |
| Project Sponsor |
|
|
|
| Technical Lead |
|
|
|
| Operations |
|
|
|
12. Revision History
| Version |
Date |
Author |
Changes |
| 1.0 |
2026-01-09 |
AI Assistant |
Initial draft |
| 1.1 |
2026-01-10 |
AI Assistant |
Marked Phase 1 requirements as implemented, added Swagger |
| 1.2 |
2026-01-10 |
AI Assistant |
Added NFR-SE-006, NFR-SE-007 for Aikido security platform |
| 1.3 |
2026-01-10 |
AI Assistant |
Added NFR-OB-001 through NFR-OB-005 for Sentry observability |
| 1.4 |
2026-01-10 |
AI Assistant |
Marked Phase 1b requirements as implemented, 100% sampling |
| 1.5 |
2026-01-12 |
AI Assistant |
Added NFR-AT-001 through NFR-AT-004 for acceptance testing |
| 1.6 |
2026-01-13 |
AI Assistant |
Marked FR-SP-001 through FR-SP-005 as implemented (Phase 2) |
| 1.7 |
2026-01-14 |
AI Assistant |
Added NFR-SE-008 for Admin Endpoint Authorization, updated NFR-SE-001 |
| 1.8 |
2026-03-20 |
AI Assistant |
Completion indications updated from .specstory/history (phase dates: Phase 1 2026-01-09, 1b 2026-01-10, 1d 2026-01-12, 2 2026-01-13, 3–4 2026-01-14, 5 2026-01-16); NFR-AT headers ⏳→✅ |
| 1.9 |
2026-03-20 |
AI Assistant |
Normalized requirement tables: status only in Status row; removed from titles; added Status (and Priority where missing); order ID, Title?, Description, Priority, Status, rest |
| 1.10 |
2026-03-20 |
AI Assistant |
Marked NFR-SE-002 (TLS/Let's Encrypt), NFR-SE-004 (Access Control/Keycloak), NFR-SE-005 (Audit Logging), NFR-RE-001 (Idempotency), NFR-MA-001 (Code Quality/ESLint+SonarCloud), NFR-MA-002 (Test Coverage), NFR-MA-004 (Logging), NFR-CO-001 (Browser Support) as implemented; added .specstory/history traceability for each |