|
|
|
|
@@ -40,13 +40,13 @@
|
|
|
|
|
|
|
|
|
|
## High-Level Overview
|
|
|
|
|
|
|
|
|
|
{ Describe the main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven). Explain the primary user interaction or data flow at a conceptual level. }
|
|
|
|
|
{ Describe the main architectural style (e.g., Monolith, Microservices, Serverless, Event-Driven), reflecting the decision made in the PRD. Explain the repository structure (Monorepo/Polyrepo). Explain the primary user interaction or data flow at a conceptual level. }
|
|
|
|
|
|
|
|
|
|
{ Insert high-level mermaid system context or interaction diagram here - e.g., Mermaid Class C4 Models Layer 1 and 2 }
|
|
|
|
|
|
|
|
|
|
## Component View
|
|
|
|
|
|
|
|
|
|
{ Describe the major logical components or services of the system and their responsibilities. Explain how they collaborate. }
|
|
|
|
|
{ Describe the major logical components or services of the system and their responsibilities, reflecting the decided overall architecture (e.g., distinct microservices, modules within a monolith, packages within a monorepo). Explain how they collaborate. }
|
|
|
|
|
|
|
|
|
|
- Component A: {Description of responsibility}
|
|
|
|
|
|
|
|
|
|
@@ -264,148 +264,4 @@ Must be definitive selections; do not list open-ended choices (e.g., for web scr
|
|
|
|
|
- Levels: {e.g., DEBUG, INFO, WARN, ERROR}
|
|
|
|
|
- Context: {What contextual information should be included?}
|
|
|
|
|
- **Specific Handling Patterns:**
|
|
|
|
|
- External API Calls: {e.g., Use `try/catch`, check response codes, implement retries with backoff for transient errors?}
|
|
|
|
|
- Input Validation: {Where and how is input validated?}
|
|
|
|
|
- Graceful Degradation vs. Critical Failure: {Define criteria for when to continue vs. halt.}
|
|
|
|
|
|
|
|
|
|
## Environment Vars Templates
|
|
|
|
|
|
|
|
|
|
### Configuration Loading Mechanism
|
|
|
|
|
|
|
|
|
|
{Describe how environment variables are loaded into the application.}
|
|
|
|
|
|
|
|
|
|
- **Local Development:** {e.g., Using `.env` file with `dotenv` library.}
|
|
|
|
|
- **Deployment (e.g., AWS Lambda, Kubernetes):** {e.g., Set via Lambda function configuration, Kubernetes Secrets/ConfigMaps.}
|
|
|
|
|
|
|
|
|
|
### Required Variables
|
|
|
|
|
|
|
|
|
|
{List all environment variables used by the application.}
|
|
|
|
|
|
|
|
|
|
| Variable Name | Description | Example / Default Value | Required? (Yes/No) | Sensitive? (Yes/No) |
|
|
|
|
|
| :------------------- | :---------------------------------------------- | :------------------------------------ | :----------------- | :------------------ |
|
|
|
|
|
| `NODE_ENV` | Runtime environment | `development` / `production` | Yes | No |
|
|
|
|
|
| `PORT` | Port the application listens on (if applicable) | `8080` | No | No |
|
|
|
|
|
| `DATABASE_URL` | Connection string for the primary database | `postgresql://user:pass@host:port/db` | Yes | Yes |
|
|
|
|
|
| `EXTERNAL_API_KEY` | API Key for {External Service Name} | `sk_...` | Yes | Yes |
|
|
|
|
|
| `S3_BUCKET_NAME` | Name of the S3 bucket for {Purpose} | `my-app-data-bucket-...` | Yes | No |
|
|
|
|
|
| `FEATURE_FLAG_X` | Enables/disables experimental feature X | `false` | No | No |
|
|
|
|
|
| `{ANOTHER_VARIABLE}` | {Description} | {Example} | {Yes/No} | {Yes/No} |
|
|
|
|
|
| ... | ... | ... | ... | ... |
|
|
|
|
|
|
|
|
|
|
### Env Var Notes
|
|
|
|
|
|
|
|
|
|
- **Secrets Management:** {Explain how sensitive variables (API Keys, passwords) should be handled, especially in production (e.g., "Use AWS Secrets Manager", "Inject via CI/CD pipeline").}
|
|
|
|
|
- **`.env.example`:** {Mention that an `.env.example` file should be maintained in the repository with placeholder values for developers.}
|
|
|
|
|
- **Validation:** {Is there code that validates the presence or format of these variables at startup?}
|
|
|
|
|
|
|
|
|
|
## Security Best Practices
|
|
|
|
|
|
|
|
|
|
{Outline key security considerations relevant to the codebase.}
|
|
|
|
|
|
|
|
|
|
- Input Sanitization/Validation: {...}
|
|
|
|
|
- Secrets Management: {How are secrets handled in code? Reference `docs/environment-vars.md` regarding storage.}
|
|
|
|
|
- Dependency Security: {Policy on checking for vulnerable dependencies.}
|
|
|
|
|
- Authentication/Authorization Checks: {Where should these be enforced?}
|
|
|
|
|
- {Other relevant practices...}
|
|
|
|
|
|
|
|
|
|
## Testing Strategy
|
|
|
|
|
|
|
|
|
|
## Overall Philosophy & Goals
|
|
|
|
|
|
|
|
|
|
{Describe the high-level approach. e.g., "Follow the Testing Pyramid/Trophy principle.", "Automate extensively.", "Focus on testing business logic and key integrations.", "Ensure tests run efficiently in CI/CD."}
|
|
|
|
|
|
|
|
|
|
- Goal 1: {e.g., Achieve X% code coverage for critical modules.}
|
|
|
|
|
- Goal 2: {e.g., Prevent regressions in core functionality.}
|
|
|
|
|
- Goal 3: {e.g., Enable confident refactoring.}
|
|
|
|
|
|
|
|
|
|
## Testing Levels
|
|
|
|
|
|
|
|
|
|
### Unit Tests
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope:** Test individual functions, methods, or components in isolation. Focus on business logic, calculations, and conditional paths within a single module.
|
|
|
|
|
- **Tools:** {e.g., Jest, Pytest, Go testing package, JUnit, NUnit}
|
|
|
|
|
- **Mocking/Stubbing:** {How are dependencies mocked? e.g., Jest mocks, Mockito, Go interfaces}
|
|
|
|
|
- **Location:** {e.g., `test/unit/`, adhering to the structure in `docs/project-structure.md` or alongside source files (`*.test.ts`)}
|
|
|
|
|
- **Expectations:** {e.g., Should cover all significant logic paths. Fast execution.}
|
|
|
|
|
|
|
|
|
|
### Integration Tests
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope:** Verify the interaction and collaboration between multiple internal components or modules. Test the flow of data and control within a specific feature or workflow slice. May involve mocking external APIs or databases, or using test containers.
|
|
|
|
|
- **Tools:** {e.g., Jest, Pytest, Go testing package, Testcontainers, Supertest (for APIs)}
|
|
|
|
|
- **Location:** {e.g., `test/integration/`, adhering to the structure in `docs/project-structure.md`}
|
|
|
|
|
- **Expectations:** {e.g., Focus on module boundaries and contracts. Slower than unit tests.}
|
|
|
|
|
|
|
|
|
|
### End-to-End (E2E) / Acceptance Tests
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope:** Test the entire system flow from an end-user perspective. Interact with the application through its external interfaces (UI or API). Validate complete user journeys or business processes against real or near-real dependencies.
|
|
|
|
|
- **Tools:** {e.g., Playwright, Cypress, Selenium (for UI); Postman/Newman, K6 (for API)}
|
|
|
|
|
- **Environment:** {Run against deployed environments (e.g., Staging) or a locally composed setup (Docker Compose).}
|
|
|
|
|
- **Location:** {e.g., `test/e2e/`, adhering to the structure in `docs/project-structure.md`}
|
|
|
|
|
- **Expectations:** {Cover critical user paths. Slower, potentially flaky, run less frequently (e.g., pre-release, nightly).}
|
|
|
|
|
|
|
|
|
|
### Manual / Exploratory Testing (Optional)
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope:** {Where is manual testing still required? e.g., Exploratory testing for usability, testing complex edge cases.}
|
|
|
|
|
- **Process:** {How is it performed and tracked?}
|
|
|
|
|
|
|
|
|
|
### Specialized Testing Types (Add section as needed)
|
|
|
|
|
|
|
|
|
|
### Performance Testing
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope & Goals:** {What needs performance testing? What are the targets (latency, throughput)?}
|
|
|
|
|
- **Tools:** {e.g., K6, JMeter, Locust}
|
|
|
|
|
|
|
|
|
|
### Security Testing
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope & Goals:** {e.g., Dependency scanning, SAST, DAST, penetration testing requirements.}
|
|
|
|
|
- **Tools:** {e.g., Snyk, OWASP ZAP, Dependabot}
|
|
|
|
|
|
|
|
|
|
### Accessibility Testing (UI)
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope & Goals:** {Target WCAG level, key areas.}
|
|
|
|
|
- **Tools:** {e.g., Axe, Lighthouse, manual checks}
|
|
|
|
|
|
|
|
|
|
### Visual Regression Testing (UI)
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
- **Scope & Goals:** {Prevent unintended visual changes.}
|
|
|
|
|
- **Tools:** {e.g., Percy, Applitools Eyes, Playwright visual comparisons}
|
|
|
|
|
|
|
|
|
|
### Test Data Management
|
|
|
|
|
|
|
|
|
|
#### EXAMPLE:
|
|
|
|
|
|
|
|
|
|
{How is test data generated, managed, and reset for different testing levels?}
|
|
|
|
|
|
|
|
|
|
## Key Reference Documents
|
|
|
|
|
|
|
|
|
|
See docs/index.md
|
|
|
|
|
- docs/front-end-architecture.md {If applicable, for detailed frontend technical design}
|
|
|
|
|
|
|
|
|
|
## Change Log
|
|
|
|
|
|
|
|
|
|
| Change | Date | Version | Description | Author |
|
|
|
|
|
| ------ | ---- | ------- | ----------- | ------ |
|
|
|
|
|
|
|
|
|
|
## Epic Story updates
|
|
|
|
|
|
|
|
|
|
{ Upon completion of all sections, any changes needed for epics or stories will be listed here (if there are any)}
|
|
|
|
|
|
|
|
|
|
## Prompt for the Design Architect
|
|
|
|
|
|
|
|
|
|
{ Optional section }
|
|
|
|
|
- External API Calls: {e.g., Use `
|
Brian Madison