116 lines
3.4 KiB
Markdown
116 lines
3.4 KiB
Markdown
# Patterns
|
|
|
|
## Entry Template
|
|
|
|
```
|
|
date: YYYY-MM-DD
|
|
author: <agent|name>
|
|
scope: <files/routes/features>
|
|
type: pattern
|
|
rationale: <why>
|
|
impact: <user/system/security/i18n/a11y>
|
|
status: accepted|superseded
|
|
|
|
Pattern:
|
|
When to use:
|
|
Example paths:
|
|
```
|
|
|
|
---
|
|
|
|
### P-001: Thin Pages, Reusable Logic Elsewhere
|
|
|
|
date: 2026-03-11
|
|
author: Cline
|
|
scope: `pages/`, `components/`, `lib/`, `actions/`
|
|
type: pattern
|
|
rationale: Improve maintainability and reduce route-level complexity.
|
|
impact: Better testability and safer incremental changes.
|
|
status: accepted
|
|
|
|
Pattern:
|
|
Keep route pages focused on composition and orchestration; place reusable behavior in `lib/`, `components/`, or `actions/`.
|
|
|
|
When to use:
|
|
|
|
- New features in existing routes
|
|
- Refactors reducing duplication across pages/components
|
|
|
|
Example paths:
|
|
|
|
- `pages/newappeal/**`
|
|
- `components/newappeal/**`
|
|
- `actions/index.js`
|
|
|
|
### P-002: EN/CY Parity for User-Facing Changes
|
|
|
|
date: 2026-03-11
|
|
author: Cline
|
|
scope: `locales/`, `i18n.js`, `next.config.js`, user-facing pages
|
|
type: pattern
|
|
rationale: Service requires bilingual consistency and reliable route behavior.
|
|
impact: Prevents locale divergence and citizen confusion.
|
|
status: accepted
|
|
|
|
Pattern:
|
|
Any user-facing change should include EN and CY text/route validation as part of done checks.
|
|
|
|
When to use:
|
|
|
|
- New/changed labels, messages, headings
|
|
- New/changed route aliases or rewrites
|
|
|
|
Example paths:
|
|
|
|
- `locales/en/**`, `locales/cy/**`
|
|
- `next.config.js`, `i18n.js`
|
|
|
|
### P-003: Shared Relay Policy via Middleware (No Endpoint Drift)
|
|
|
|
date: 2026-03-24
|
|
author: Cline
|
|
scope: `pages/api/middleware/relayForwarding.js`, `pages/api/endpoint/*_api.js` relay GET handlers
|
|
type: pattern
|
|
rationale: Keep reliability and logging policy centralized so endpoint handlers remain thin and behavior stays consistent as relay surface evolves.
|
|
impact: Reduces duplication/drift in timeout/retry/error behavior and supports safer incremental endpoint migration/hardening.
|
|
status: accepted
|
|
|
|
Pattern:
|
|
Implement retry/timeout/redacted structured logging in shared relay middleware and keep endpoint handlers focused on validation, transform, and route-level response contracts.
|
|
|
|
When to use:
|
|
|
|
- Any new or migrated relay-backed endpoint
|
|
- Any relay reliability/logging policy update
|
|
|
|
Example paths:
|
|
|
|
- `pages/api/middleware/relayForwarding.js`
|
|
- `pages/api/endpoint/getadvancedsearch_api.js`
|
|
- `pages/api/endpoint/getdnscoords_api.js`
|
|
- `tests/phase21/relay-forwarding-hardening.test.cjs`
|
|
|
|
### P-004: Relay Policy Change Bundle (Governance + Smoke + Rollback)
|
|
|
|
date: 2026-03-24
|
|
author: Cline
|
|
scope: relay policy changes + rollout documentation
|
|
type: pattern
|
|
rationale: Relay reliability changes can alter runtime behavior without changing endpoint contracts; bundle process controls and operational checks together to reduce regression risk.
|
|
impact: Improves release confidence and standardizes operational readiness for relay policy updates.
|
|
status: accepted
|
|
|
|
Pattern:
|
|
For relay timeout/retry/logging policy updates, ship one documentation bundle that includes governance checklist, non-prod smoke matrix, monitoring checks, and rollback instructions.
|
|
|
|
When to use:
|
|
|
|
- Any change to retry classification, timeout defaults/bounds, or relay logging behavior
|
|
- Any change to relay environment tuning guidance
|
|
|
|
Example paths:
|
|
|
|
- `context/runbook.md`
|
|
- `memory-bank/change-log.md`
|
|
- `memory-bank/decisions.md`
|