azcodr 1.3.0 → 1.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/hooks.json.example +42 -0
- package/.agents/mcp_config.json.example +24 -0
- package/.agents/skills/agentic-architect/SKILL.md +14 -7
- package/.agents/skills/agentic-architect/references/agents_md_template.md +6 -3
- package/.agents/skills/agentic-architect/references/skill_architecture_inquiry.md +1 -1
- package/.agents/skills/agentic-architect/references/skill_template.md +2 -1
- package/.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh +156 -4
- package/.agents/skills/clean-code-refactor/SKILL.md +6 -6
- package/.agents/skills/compliance-audit/SKILL.md +1 -1
- package/.agents/skills/lets-build/SKILL.md +12 -4
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +1 -1
- package/.agents/skills/lets-build/references/project_readme_template.md +4 -4
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +63 -35
- package/.agents/skills/relentless-questioner/SKILL.md +10 -5
- package/AGENTS.md +25 -40
- package/README.md +27 -40
- package/bin/azcodr.js +1 -1
- package/docs/rules/agentic_configuration.md +120 -32
- package/docs/rules/api_architecture.md +179 -0
- package/docs/rules/caching.md +30 -13
- package/docs/rules/cloud_native.md +10 -12
- package/docs/rules/cqrs.md +203 -0
- package/docs/rules/database_design.md +125 -0
- package/docs/rules/database_operations.md +56 -14
- package/docs/rules/design_patterns.md +18 -11
- package/docs/rules/devops_ci_cd.md +76 -0
- package/docs/rules/domain_driven_design.md +17 -13
- package/docs/rules/feature_flags.md +21 -4
- package/docs/rules/frontend_architecture.md +157 -0
- package/docs/rules/multitenancy_architecture.md +98 -0
- package/docs/rules/product_ownership.md +22 -27
- package/docs/rules/requirements_engineering.md +16 -14
- package/docs/rules/security_compliance.md +53 -0
- package/docs/rules/server_driven_ui.md +20 -3
- package/docs/rules/test_driven_development.md +118 -62
- package/docs/rules/type_safety.md +65 -0
- package/docs/rules/ui_ux_architecture.md +33 -30
- package/docs/rules/workflow_state_machines.md +20 -3
- package/lib/scaffold.js +9 -0
- package/memory.md +149 -15
- package/package.json +2 -2
- package/docs/rules/accessibility.md +0 -31
- package/docs/rules/advanced_api_patterns.md +0 -104
- package/docs/rules/api_versioning.md +0 -113
- package/docs/rules/application_security.md +0 -23
- package/docs/rules/architecture_decision_records.md +0 -42
- package/docs/rules/compliance.md +0 -25
- package/docs/rules/container_infrastructure.md +0 -32
- package/docs/rules/continuous_deployment.md +0 -24
- package/docs/rules/continuous_integration.md +0 -20
- package/docs/rules/continuous_learning.md +0 -29
- package/docs/rules/database_integrity.md +0 -80
- package/docs/rules/database_migrations.md +0 -41
- package/docs/rules/database_performance.md +0 -44
- package/docs/rules/database_transactions.md +0 -81
- package/docs/rules/devsecops.md +0 -33
- package/docs/rules/multitenancy_isolation.md +0 -88
- package/docs/rules/react.md +0 -78
- package/docs/rules/rest_api_conventions.md +0 -46
- package/docs/rules/tenant_dynamic_schemas.md +0 -88
- package/docs/rules/tenant_pluggable_logic.md +0 -59
- package/docs/rules/test_isolation.md +0 -26
- package/docs/rules/typescript.md +0 -55
- package/docs/rules/ui_navigation.md +0 -20
- package/docs/rules/workspace_isolation.md +0 -25
package/memory.md
CHANGED
|
@@ -17,23 +17,31 @@
|
|
|
17
17
|
|
|
18
18
|
| ID | Title | Date | Status | Governing Rule / Skill |
|
|
19
19
|
|---|---|---|---|---|
|
|
20
|
-
| **ADR-001** | 100% Open-Source Tooling & Framework Mandate | 2026-09-16 | ACCEPTED | [`
|
|
20
|
+
| **ADR-001** | 100% Open-Source Tooling & Framework Mandate | 2026-09-16 | ACCEPTED | [`security_compliance.md`](./docs/rules/security_compliance.md), [`devops_ci_cd.md`](./docs/rules/devops_ci_cd.md) |
|
|
21
21
|
| **ADR-002** | Progressive Disclosure Architecture for Agentic Context | 2026-09-16 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`agentic-architect`](./.agents/skills/agentic-architect/SKILL.md) |
|
|
22
|
-
| **ADR-003** | Dual-Layer Multi-Tenancy Isolation with PostgreSQL RLS | 2026-09-16 | ACCEPTED | [`
|
|
22
|
+
| **ADR-003** | Dual-Layer Multi-Tenancy Isolation with PostgreSQL RLS | 2026-09-16 | ACCEPTED | [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md) |
|
|
23
23
|
| **ADR-004** | Systemic Atomicity & Pure Single-Responsibility Rule Decomposition | 2026-09-16 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
24
24
|
| **ADR-005** | Universal Technology, Language, and Stack Agnosticism | 2026-09-18 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`lets-build`](./.agents/skills/lets-build/SKILL.md) |
|
|
25
|
-
| **ADR-006** | Mandatory Full Lifecycle CRUD & Relational FK Selector Pattern | 2026-09-18 | ACCEPTED | [`
|
|
25
|
+
| **ADR-006** | Mandatory Full Lifecycle CRUD & Relational FK Selector Pattern | 2026-09-18 | ACCEPTED | [`database_design.md`](./docs/rules/database_design.md), [`api_architecture.md`](./docs/rules/api_architecture.md), [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md) |
|
|
26
26
|
| **ADR-007** | Decoupling Project Bootstrapping from Domain Analysis | 2026-09-18 | ACCEPTED | [`lets-build`](./.agents/skills/lets-build/SKILL.md), [`product-analyst`](./.agents/skills/product-analyst/SKILL.md) |
|
|
27
|
-
| **ADR-008** | Non-Negotiable 5-Phase Agile Domain Lifecycle & Outside-In TDD | 2026-09-18 | ACCEPTED | [`test_driven_development.md`](./docs/rules/test_driven_development.md)
|
|
27
|
+
| **ADR-008** | Non-Negotiable 5-Phase Agile Domain Lifecycle & Outside-In TDD | 2026-09-18 | ACCEPTED | [`test_driven_development.md`](./docs/rules/test_driven_development.md) |
|
|
28
28
|
| **ADR-009** | Many-to-Many Skill Composability & Orthogonal Pipelines | 2026-09-18 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`agentic-architect`](./.agents/skills/agentic-architect/SKILL.md) |
|
|
29
|
-
| **ADR-011** | Canonical 6 Total Audit Fields Architecture & Modern React Stack | 2026-09-19 | ACCEPTED | [`
|
|
29
|
+
| **ADR-011** | Canonical 6 Total Audit Fields Architecture & Modern React Stack | 2026-09-19 | ACCEPTED | [`database_design.md`](./docs/rules/database_design.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md) |
|
|
30
30
|
| **ADR-012** | State Machine Lifecycle Configurability & Ubiquitous Language Contract | 2026-09-19 | ACCEPTED | [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) |
|
|
31
31
|
| **ADR-013** | Design Architecture Triage, Persistent Shell & Dev Persona Isolation | 2026-09-20 | ACCEPTED | [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md), [`authentication.md`](./docs/rules/authentication.md) |
|
|
32
32
|
| **ADR-014** | Product Ownership, Prioritization Models, SMART Tasks & INVEST Slicing | 2026-09-21 | ACCEPTED | [`product_ownership.md`](./docs/rules/product_ownership.md), [`requirements_engineering.md`](./docs/rules/requirements_engineering.md), [`project_management.md`](./docs/rules/project_management.md) |
|
|
33
33
|
| **ADR-015** | Problem-First Architecture, Topology Scaffolding, Tipping Points & Nano-TDD | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md), [`lets-build`](./.agents/skills/lets-build/SKILL.md) |
|
|
34
|
-
| **ADR-016** | Elimination of Static Markdown Knowledge Graph | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`
|
|
34
|
+
| **ADR-016** | Elimination of Static Markdown Knowledge Graph | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
35
35
|
| **ADR-017** | Progressive Rules Consolidation (DDD & GoF Patterns) | 2026-09-25 | ACCEPTED | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`design_patterns.md`](./docs/rules/design_patterns.md) |
|
|
36
|
-
| **ADR-018** | Elimination of Upstream Changes Ledger and Sync Tooling | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`
|
|
36
|
+
| **ADR-018** | Elimination of Upstream Changes Ledger and Sync Tooling | 2026-09-25 | ACCEPTED | [`clean_code.md`](./docs/rules/clean_code.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
37
|
+
| **ADR-019** | Evolutionary CQRS Spectrum & Strict YAGNI Tipping Points | 2026-09-26 | ACCEPTED | [`cqrs.md`](./docs/rules/cqrs.md), [`database_design.md`](./docs/rules/database_design.md) |
|
|
38
|
+
| **ADR-020** | Universal YAGNI Gate Triad Architecture | 2026-09-26 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`.agents/skills/agentic-architect/SKILL.md`](./.agents/skills/agentic-architect/SKILL.md) |
|
|
39
|
+
| **ADR-021** | Language-Agnostic Core Rules Generalization & Toolchain Zero-Rule Policy | 2026-09-26 | ACCEPTED | [`type_safety.md`](./docs/rules/type_safety.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md) |
|
|
40
|
+
| **ADR-022** | Vendor-Agnostic Frontend Architecture & Library-as-a-Skill Anti-Pattern Defense | 2026-09-26 | ACCEPTED | [`frontend_architecture.md`](./docs/rules/frontend_architecture.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
41
|
+
| **ADR-023** | Architectural Cohesion Consolidation (Synthesis of 28 Cohesive Domain Rules) | 2026-09-26 | ACCEPTED | All 28 rules in [`docs/rules/`](./docs/rules/) |
|
|
42
|
+
| **ADR-024** | Outside-In Interaction Discovery vs. Inside-Out Invariants & Headless UI Testing | 2026-09-26 | ACCEPTED | [`frontend_architecture.md`](./docs/rules/frontend_architecture.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md) |
|
|
43
|
+
| **ADR-025** | Automated Markdown Link Integrity, Scaffolding Boundary Decoupling & Prepublish Quality Gates | 2026-09-26 | ACCEPTED | [`.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh`](./.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
44
|
+
| **ADR-026** | Multi-Harness Parity, Agentic Skill Taxonomy & Deterministic Governance Hardening | 2026-09-26 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`agentic-architect`](./.agents/skills/agentic-architect/SKILL.md) |
|
|
37
45
|
|
|
38
46
|
|
|
39
47
|
---
|
|
@@ -44,7 +52,7 @@
|
|
|
44
52
|
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
45
53
|
- **Context:** Proprietary SaaS dependencies introduce vendor lock-in, recurring operational costs, and black-box security risks.
|
|
46
54
|
- **Decision:** Standardize exclusively on open-source solutions across all architectural domains (PostgreSQL, Redis, Trivy, Semgrep, Gitleaks, OpenTelemetry, Vitest, Playwright, Radix UI).
|
|
47
|
-
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`
|
|
55
|
+
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`security_compliance.md`](./docs/rules/security_compliance.md), [`devops_ci_cd.md`](./docs/rules/devops_ci_cd.md).
|
|
48
56
|
|
|
49
57
|
#### ADR-002: Progressive Disclosure Architecture for Agentic Context
|
|
50
58
|
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
@@ -56,7 +64,7 @@
|
|
|
56
64
|
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
57
65
|
- **Context:** Application-level `where: { tenantId }` filtering is prone to human error, risking catastrophic cross-tenant data leaks.
|
|
58
66
|
- **Decision:** Combine application middleware context resolution with database-level PostgreSQL Row-Level Security (RLS) policies as an immutable backstop.
|
|
59
|
-
- **Enforced In:** [`
|
|
67
|
+
- **Enforced In:** [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md).
|
|
60
68
|
|
|
61
69
|
#### ADR-004: Systemic Atomicity & Pure Single-Responsibility Rule Decomposition
|
|
62
70
|
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
@@ -74,7 +82,7 @@
|
|
|
74
82
|
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
75
83
|
- **Context:** Prototypes often provide partial CRUD, leaving entities un-editable or undeletable. Exposing foreign keys as raw text inputs causes severe relational errors.
|
|
76
84
|
- **Decision:** Every feature must implement complete lifecycle CRUD (Create, Read/Detail, Update/Transition, Delete/Archive) with 100.00% test coverage. Foreign keys must never be exposed as raw string inputs; they must be resolved via accessible relational dropdown selectors displaying contextual business metadata.
|
|
77
|
-
- **Enforced In:** [`
|
|
85
|
+
- **Enforced In:** [`database_design.md`](./docs/rules/database_design.md), [`api_architecture.md`](./docs/rules/api_architecture.md), [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md).
|
|
78
86
|
|
|
79
87
|
#### ADR-007: Strict Decoupling of Project Bootstrapping from Domain Analysis
|
|
80
88
|
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
@@ -86,7 +94,7 @@
|
|
|
86
94
|
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
87
95
|
- **Context:** Writing production code before tests or domain understanding leads to brittle code, regressions, and "toy prototypes."
|
|
88
96
|
- **Decision:** Enforce an immutable 5-Phase Agile Domain Lifecycle across all tasks (Requirements ➔ Domain Analysis ➔ Outer Acceptance RED ➔ Inner Unit TDD RED-GREEN-REFACTOR ➔ Outer GREEN & DoD). Writing production code without a failing test is strictly prohibited.
|
|
89
|
-
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md)
|
|
97
|
+
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md).
|
|
90
98
|
|
|
91
99
|
#### ADR-009: Many-to-Many Skill Composability & Orthogonal Pipeline Architecture
|
|
92
100
|
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
@@ -98,7 +106,7 @@
|
|
|
98
106
|
- **Date:** 2026-09-19 | **Status:** ACCEPTED
|
|
99
107
|
- **Context:** Inconsistent audit tracking risks SOC 2 / ISO 27001 non-compliance. Frontend `useEffect` fetch loops cause stale states and race conditions.
|
|
100
108
|
- **Decision:** Every mutable stateful table must implement the Canonical 6 Total Audit Fields (`createdAt`, `createdBy`, `updatedAt`, `updatedBy`, `deletedAt`, `deletedBy`), with append-only ledgers omitting update/delete fields. Standardize frontend on TanStack Query, React Hook Form + Zod, and headless Radix primitives.
|
|
101
|
-
- **Enforced In:** [`
|
|
109
|
+
- **Enforced In:** [`database_design.md`](./docs/rules/database_design.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md).
|
|
102
110
|
|
|
103
111
|
#### ADR-012: State Machine Lifecycle Configurability & Living Ubiquitous Language Contract
|
|
104
112
|
- **Date:** 2026-09-19 | **Status:** ACCEPTED
|
|
@@ -110,7 +118,7 @@
|
|
|
110
118
|
- **Date:** 2026-09-20 | **Status:** ACCEPTED
|
|
111
119
|
- **Context:** Conflating developer demo personas with production auth creates toy-like prototypes. Untriaged UI produces layout shifts and broken navigation.
|
|
112
120
|
- **Decision:** Mandate the 7-Pillar Design Architecture Triage Gate before writing UI code; separate Enterprise Operator Workspace (`/`) from Consumer Portal (`/portal`); standardize on a persistent shell with 64px collapsible icon rail and bidirectional URL state sync; strictly isolate developer demo personas into a dev-only floating toolbar (`import.meta.env.DEV`).
|
|
113
|
-
- **Enforced In:** [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md), [`authentication.md`](./docs/rules/authentication.md), [`
|
|
121
|
+
- **Enforced In:** [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md), [`authentication.md`](./docs/rules/authentication.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md).
|
|
114
122
|
|
|
115
123
|
#### ADR-014: Product Ownership, Backlog Prioritization Models, SMART Developer Tasks & INVEST Slicing
|
|
116
124
|
- **Date:** 2026-09-21 | **Status:** ACCEPTED
|
|
@@ -132,7 +140,7 @@
|
|
|
132
140
|
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
133
141
|
- **Context:** Template repositories often maintain static markdown files containing Mermaid diagrams, ERDs, and component topologies (`docs/knowledge/knowledge_graph.md`). In practice, these static artifacts suffer from rapid maintenance drift, violate the Problem-First mandate by pre-fabricating multi-tenant web backend models before the user defines their project, duplicate existing domain rules and memory records, and become stale tokens consumed on every context load.
|
|
134
142
|
- **Decision:** Permanently delete `docs/knowledge/knowledge_graph.md`. Treat executable code, strict type definitions, and versioned database migrations as the sole source of truth for architectural topologies. Retain `docs/knowledge/ubiquitous_language.md` as the lightweight, living domain vocabulary contract.
|
|
135
|
-
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`
|
|
143
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`memory.md`](./memory.md).
|
|
136
144
|
|
|
137
145
|
#### ADR-017: Progressive Rules Consolidation (DDD & GoF Design Patterns)
|
|
138
146
|
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
@@ -151,5 +159,131 @@
|
|
|
151
159
|
2. Remove `changes.md` from scaffolded `TEMPLATE_ITEMS` and package manifests.
|
|
152
160
|
3. Purge `logChange` functions, types, and CLI subcommands, restoring `azcodr` CLI as a clean, single-purpose project bootstrapper.
|
|
153
161
|
4. Standardize exclusively on Git commits for historical revision logs and `memory.md` for architectural decision records.
|
|
154
|
-
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md),
|
|
162
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), `lib/scaffold.js`, `bin/azcodr.js`, [`memory.md`](./memory.md).
|
|
163
|
+
|
|
164
|
+
#### ADR-019: CQRS (Command Query Responsibility Segregation) & YAGNI Defense
|
|
165
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
166
|
+
- **Context:** Command Query Responsibility Segregation (CQRS) is frequently adopted prematurely across whole applications, violating the YAGNI (You Aren't Gonna Need It) principle and introducing immense accidental complexity: eventual consistency lag, dual schema maintenance, projection drift, loss of ACID transactions, and distributed outbox pipelines. However, segregating read projections from write aggregates is essential for high-contention or high read/write asymmetry bounded contexts.
|
|
167
|
+
- **Decision:**
|
|
168
|
+
1. Mandate the **YAGNI Defense**: Default to a Single Model / Single Database architecture for all applications and generic subdomains. CQRS is strictly forbidden as a global, top-level system architecture.
|
|
169
|
+
2. Define an **Evolutionary 4-Tier CQRS Spectrum**:
|
|
170
|
+
- *Level 0 (Method CQS)*: Commands mutate state; queries return values. Zero overhead; mandatory everywhere.
|
|
171
|
+
- *Level 1 (Segregated Handlers)*: Single database/schema. Command Handlers load Aggregates to enforce business invariants; Query Handlers bypass domain entities and query direct SQL projections into flat DTOs.
|
|
172
|
+
- *Level 2 (Segregated Read Models / Materialized Views)*: Single database. Synchronously updated read tables or materialized views for multi-table join optimization.
|
|
173
|
+
- *Level 3 (Polyglot Multi-Store CQRS)*: Dual databases (PostgreSQL write + Elasticsearch/Redis read) synchronized strictly via the Transactional Outbox Pattern and CDC. Permitted only when explicit empirical tipping points (Read:Write > 50:1, search engine requirement, or read starvation) are proven.
|
|
174
|
+
3. Prohibit common anti-patterns: Conflating CQRS with Event Sourcing, dual-write projections without an outbox, and exposing users to eventual consistency lag on their own mutations (enforce Read-Your-Own-Writes consistency via optimistic UI or version headers).
|
|
175
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), [`docs/rules/cqrs.md`](./docs/rules/cqrs.md), [`docs/rules/clean_code.md`](./docs/rules/clean_code.md), [`docs/rules/database_design.md`](./docs/rules/database_design.md), [`memory.md`](./memory.md).
|
|
176
|
+
|
|
177
|
+
#### ADR-020: Universal YAGNI Gate Architecture, Tipping Points & Foundational Library Leverage
|
|
178
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
179
|
+
- **Context:** LLM coding agents suffer from a known statistical failure mode—"Instruction Creep" and "Eager Pattern Application"—where introducing an advanced architectural rule (e.g. distributed caching, state machines, feature flag servers, server-driven UI) prompts the agent to reflexively implement complex infrastructure across all tasks, even for 50-line CLIs or low-traffic prototypes. Conversely, developers sometimes misinterpret YAGNI as forbidding battle-tested libraries (shadcn/ui, Tailwind CSS, Zod, Lombok), leading to Not-Invented-Here (NIH) syndrome and massive hand-rolled accidental complexity.
|
|
180
|
+
- **Decision:**
|
|
181
|
+
1. Codify the **YAGNI Gate Triad** across all architectural pattern rules and skills:
|
|
182
|
+
- *Part 1: The Simple Baseline (Day 1)*: Zero-overhead default (single DB before CQRS; relational indexes before Redis; simple enums before State Machines; standard React before Server-Driven UI; env vars before Flipt).
|
|
183
|
+
- *Part 2: The Anti-Triggers*: Explicit negative scenarios where the pattern is forbidden as premature over-engineering.
|
|
184
|
+
- *Part 3: The Empirical Tipping Point*: Measurable threshold (latency SLA, state count, asymmetry ratio, external scripts) required to graduate.
|
|
185
|
+
2. Clarify **Foundational Leverage vs. Speculative Over-Engineering**: Adopting standard open-source primitives (`shadcn/ui`, `Tailwind CSS`, `Zod`, `TanStack Query`, `Lombok`) to solve concrete present requirements with minimal code is YAGNI-compliant foundational leverage. YAGNI strictly attacks speculative custom code and premature multi-tier distributed architectures.
|
|
186
|
+
3. Retrofit explicit YAGNI Gates across high-risk rules: [`caching.md`](./docs/rules/caching.md), [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md), [`feature_flags.md`](./docs/rules/feature_flags.md), [`server_driven_ui.md`](./docs/rules/server_driven_ui.md), [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md).
|
|
187
|
+
#### ADR-021: Language-Agnostic Core Rules Generalization (`type_safety.md` & `frontend_architecture.md`) and Deferred Project-Specific Specialization via `/lets-build`
|
|
188
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
189
|
+
- **Context:** Naming rules after specific technologies (`typescript.md`, `react.md`) in a foundational template workspace creates false tool/platform bias, violating Problem-First Architecture and confusing developers initializing Python, Java, Go, Rust, or C# systems. Furthermore, procedural package management rules (e.g. creating rules for `venv` vs `uv` vs `poetry`, or `maven` vs `gradle`) is a severe YAGNI violation and prompt anti-pattern, because LLMs already possess parametric toolchain knowledge and should derive execution commands from native workspace manifests (`pom.xml`, `pyproject.toml`).
|
|
190
|
+
- **Decision:**
|
|
191
|
+
1. Generalize technology-specific rule filenames into polyglot architectural disciplines:
|
|
192
|
+
- Rename `typescript.md` ➔ [`type_safety.md`](./docs/rules/type_safety.md): Codifies sound type systems, branded nominal typing, and fail-fast boundary validation across TypeScript, Python (`mypy`/`pydantic`), Java (records), C# (nullable), Rust (newtype), and Go.
|
|
193
|
+
- Rename `react.md` ➔ [`frontend_architecture.md`](./docs/rules/frontend_architecture.md): Codifies headless accessible primitives, server-state cache synchronization and deduplication, declarative schema form validation, 5-tier state separation hierarchy, and design tokens across modern web clients.
|
|
194
|
+
2. Maintain a strict **Zero Toolchain Rule Policy**: Package managers (`uv`, `maven`, `gradle`, `composer`, `cargo`) shall never have dedicated rule files. Instead, `/lets-build` inquires into preferred toolchains during the interview, scaffolds native manifests, and stamps a concise 4-line execution contract into `AGENTS.md` (`## 2. Runtime & Core Scripts`).
|
|
195
|
+
3. Defer project-specific pruning to `/lets-build`: Projects without a frontend (e.g. headless Python backends or Rust CLIs) prune frontend rules during bootstrapping to ensure minimal token footprint.
|
|
196
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), [`docs/rules/type_safety.md`](./docs/rules/type_safety.md), [`docs/rules/frontend_architecture.md`](./docs/rules/frontend_architecture.md), [`.agents/skills/lets-build/SKILL.md`](./.agents/skills/lets-build/SKILL.md), [`memory.md`](./memory.md).
|
|
197
|
+
|
|
198
|
+
#### ADR-022: Vendor-Agnostic Frontend Architecture & The "Library-as-a-Skill" Anti-Pattern Defense
|
|
199
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
200
|
+
- **Context:** Hardcoding a specific library (e.g. `TanStack Query`) as a mandatory requirement in `frontend_architecture.md` violates Problem-First Topology Alignment when building applications with Vue, SvelteKit, Angular, Solid, or React Server Components. Furthermore, a recurring temptation during domain analysis is to dynamically generate dedicated agent "skills" for every chosen library (e.g. `skills/react`, `skills/tanstack`, `skills/shadcn`, `skills/zustand`, `skills/testing-library`).
|
|
201
|
+
- **Decision:**
|
|
202
|
+
1. **Vendor-Agnostic Architectural Invariants**: Decouple `frontend_architecture.md` from specific libraries. Codify universal architectural patterns (Headless Accessible Primitives, Server-State Cache Synchronization & Invalidation, Declarative Schema Form Validation, 5-Tier State Separation, and Token Symmetry) illustrated across frameworks (React, Vue, Svelte, Angular).
|
|
203
|
+
2. **Defend Against the "Library-as-a-Skill" Anti-Pattern**: Do NOT generate skills for standard commodity open-source libraries:
|
|
204
|
+
- *Prompt Bloat & Re-explanation Tax:* Skill descriptions are injected into every prompt. Adding 15 library skills floods the context window with parametric knowledge the LLM already knows.
|
|
205
|
+
- *Trigger Collision & Agent Paralysis:* A single UI prompt (e.g. "Create a profile form with data fetch") collides across multiple library skills (`react`, `tanstack`, `shadcn`, `testing-library`), causing wasteful subagent hops.
|
|
206
|
+
- *Passive Libraries vs. Active Workflows:* A skill is an active multi-step procedure (e.g. `/lets-build`, `product-analyst`, `compliance-audit`). A library is passive code whose usage is derived from code manifests (`package.json`, `components.json`), local component directories (`components/ui`), and CLI tools (`npx shadcn@latest add`).
|
|
207
|
+
3. **The 4-Layer Resolution Standard for Project Stack Knowledge**:
|
|
208
|
+
- *Layer 1 (Ground Truth Manifests):* `package.json`, `tsconfig.json`, `components.json`.
|
|
209
|
+
- *Layer 2 (Stack Contract in `AGENTS.md`):* 3–5 line declaration in project entrypoint stamped by `/lets-build`.
|
|
210
|
+
- *Layer 3 (Universal Domain Rules):* `frontend_architecture.md`, `test_driven_development.md`, `api_architecture.md`.
|
|
211
|
+
- *Layer 4 (Tool & CLI Execution):* Direct execution of package CLIs (`npx shadcn@latest add`) or MCP servers.
|
|
212
|
+
- **Enforced In:** [`frontend_architecture.md`](./docs/rules/frontend_architecture.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`memory.md`](./memory.md).
|
|
213
|
+
|
|
214
|
+
#### ADR-023: Architectural Cohesion Consolidation (Synthesis of 28 Cohesive Domain Rules)
|
|
215
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
216
|
+
- **Context:** The workspace rules had suffered from micro-rule fragmentation (45 separate files, with 15 files under 35 lines), creating high cognitive discovery overhead, duplicated directives, and split concerns across closely related domains (e.g. 5 UI files, 5 database files, 4 DevOps files, 3 multi-tenancy files, 3 API files).
|
|
217
|
+
- **Decision:**
|
|
218
|
+
Consolidate fragmented micro-rules into 28 cohesive, single-responsibility domain rules:
|
|
219
|
+
1. **Frontend & UI**: Merge `accessibility.md` and `ui_navigation.md` into [`frontend_architecture.md`](./docs/rules/frontend_architecture.md). Retain [`ui_ux_architecture.md`](./docs/rules/ui_ux_architecture.md) for system design/layout and [`server_driven_ui.md`](./docs/rules/server_driven_ui.md) for backend schemas.
|
|
220
|
+
2. **API Architecture**: Merge `rest_api_conventions.md`, `advanced_api_patterns.md`, and `api_versioning.md` into [`api_architecture.md`](./docs/rules/api_architecture.md) (covering HTTP status codes, sync vs async 202 processing, `_actions`, idempotency keys, cursor pagination, OCC, and RFC 8594 lifecycle deprecation).
|
|
221
|
+
3. **Multi-Tenancy**: Merge `multitenancy_isolation.md`, `tenant_dynamic_schemas.md`, and `tenant_pluggable_logic.md` into [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md) (unifying context resolution, 4 isolation models, RLS, dynamic schemas, and pluggable logic with YAGNI gates).
|
|
222
|
+
4. **Database Architecture**: Consolidate into 2 atomic rules: [`database_design.md`](./docs/rules/database_design.md) (relational integrity, FKs, CHECKs, Canonical 6 Audit Fields, ACID transactions, Outbox pattern) and [`database_operations.md`](./docs/rules/database_operations.md) (zero-downtime expand-contract migrations, N+1 elimination, DataLoader, indexing, connection pooling, PITR).
|
|
223
|
+
5. **DevOps & CI/CD**: Merge `continuous_integration.md`, `continuous_deployment.md`, `container_infrastructure.md`, and `devsecops.md` into [`devops_ci_cd.md`](./docs/rules/devops_ci_cd.md).
|
|
224
|
+
6. **Security & Compliance**: Merge `application_security.md` and `compliance.md` into [`security_compliance.md`](./docs/rules/security_compliance.md).
|
|
225
|
+
7. **Testing**: Merge `test_isolation.md` into [`test_driven_development.md`](./docs/rules/test_driven_development.md).
|
|
226
|
+
8. **Agent Governance**: Merge `workspace_isolation.md`, `continuous_learning.md`, and `architecture_decision_records.md` into [`agentic_configuration.md`](./docs/rules/agentic_configuration.md).
|
|
227
|
+
- **Consequences:** Eliminates 22 fragmented micro-files, reduces `AGENTS.md` table from 45 to 28 rows, and aligns every rule with True Single Responsibility.
|
|
228
|
+
#### ADR-024: Outside-In Interaction Discovery vs. Inside-Out Domain Invariants, Headless UI Testing Architecture for AI Agents, and Universal Mermaid Diagram Standards
|
|
229
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
230
|
+
- **Context:**
|
|
231
|
+
1. The classic software dichotomy: "Does UI (CLI, GUI, API) dictate logic or vice versa?" Misunderstanding this relationship causes teams to either tightly couple business rules to UI frameworks (fat UI components) or build ivory-tower domain models detached from real customer journeys.
|
|
232
|
+
2. Autonomous AI agents operate in headless execution environments with zero visual eyesight. Standard engineering workflows frequently neglect UI testing or rely on fragile manual browser inspection that AI agents cannot execute or verify.
|
|
233
|
+
3. Workspace rules previously contained ad-hoc ASCII art diagrams that render inconsistently across markdown viewports, violate the user formatting directive, and cannot be dynamically rendered by modern Git platforms.
|
|
234
|
+
- **Decision:**
|
|
235
|
+
1. **Outside-In Interaction Discovery vs. Inside-Out Domain Invariants Law**:
|
|
236
|
+
- *Phase 1 & 2 (Outside-In Discovery)*: UI, CLI, and client interaction models guide *what capabilities are needed* early. The customer journey discovers input command payloads, output presentation DTOs, and state requirements.
|
|
237
|
+
- *Phase 3 & 4 (Inside-Out Execution & Invariants)*: Domain entities enforce *how business rules operate*. Core business invariants are 100% agnostic to presentation frameworks, decoupled via Driving Ports (Use Cases).
|
|
238
|
+
- *Headless / Zero-UI Topologies*: In systems without a graphical interface (microservices, daemons, developer CLIs), the external API schema (OpenAPI, gRPC) or CLI command pipeline IS the UI. The identical Outside-In discovery law applies.
|
|
239
|
+
2. **The 4-Tier Headless UI Testing Pyramid for Autonomous AI Agents**:
|
|
240
|
+
- *Tier 1 (Accessible Component Tests)*: `@testing-library` + `user-event`. Query elements strictly by accessible ARIA roles (`getByRole`), ensuring semantic accessibility and banning brittle CSS selectors.
|
|
241
|
+
- *Tier 2 (Network Interception & Universal UI States)*: `MSW` (Mock Service Worker). Test all 4 universal UI states (Loading, Success, Error, Empty) deterministically in memory without live backends.
|
|
242
|
+
- *Tier 3 (Zero-Eyesight Automated Accessibility)*: `axe-core` (`vitest-axe` / `@axe-core/playwright`). Execute programmatic WCAG 2.2 AA assertions providing empirical pass/fail proof without visual eyesight.
|
|
243
|
+
- *Tier 4 (Headless E2E Smoke Tests)*: Headless Playwright CLI runs. Validate critical user journeys with traces, screenshots, and video recordings captured automatically upon test failure.
|
|
244
|
+
3. **Universal Mermaid Diagram Standard**:
|
|
245
|
+
- Standardize exclusively on GitHub-Flavored Markdown Mermaid diagrams (`flowchart`, `sequenceDiagram`, `classDiagram`) across all workspace rules, replacing all legacy ASCII box drawings.
|
|
246
|
+
- **Enforced In:** [`docs/rules/frontend_architecture.md`](./docs/rules/frontend_architecture.md), [`docs/rules/test_driven_development.md`](./docs/rules/test_driven_development.md), [`docs/rules/api_architecture.md`](./docs/rules/api_architecture.md), all 28 domain rules in [`docs/rules/`](./docs/rules/), [`memory.md`](./memory.md).
|
|
247
|
+
|
|
248
|
+
#### ADR-025: Automated Markdown Link Integrity, Scaffolding Boundary Decoupling & Prepublish Quality Gates
|
|
249
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
250
|
+
- **Context:**
|
|
251
|
+
1. As rules are refactored or consolidated, internal relative links across markdown documentation (`memory.md`, `README.md`, skills, rules) risk breaking silently without automated CI detection.
|
|
252
|
+
2. Scaffolding templates that reference repository-internal files (`lib/`, `bin/`) fail when evaluated in downstream isolated workspaces, violating Workspace Sovereignty.
|
|
253
|
+
3. Prepublish hooks omitted linting, risking publishing untested syntax.
|
|
254
|
+
- **Decision:**
|
|
255
|
+
1. **Automated Cross-Reference & Link Integrity Enforcement**: Embed a deterministic link validator into `validate_agentic_configs.sh` that scans all markdown files across the workspace and asserts that 100% of internal links resolve to valid files on disk.
|
|
256
|
+
2. **Scaffolding Boundary Decoupling**: Sanitize all documentation and memory records to format internal packaging files (`lib/`, `bin/`) in code font rather than relative markdown links, ensuring scaffolded projects pass validation with zero broken links.
|
|
257
|
+
3. **Prepublish Quality Gate**: Expand `prepublishOnly` in `package.json` to enforce `npm run lint && npm run test:coverage && npm run validate` prior to distribution.
|
|
258
|
+
- **Enforced In:** [`.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh`](./.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh), [`docs/rules/agentic_configuration.md`](./docs/rules/agentic_configuration.md), `package.json`, [`memory.md`](./memory.md).
|
|
259
|
+
|
|
260
|
+
#### ADR-026: Multi-Harness Parity, Agentic Skill Taxonomy & Deterministic Governance Hardening
|
|
261
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
262
|
+
- **Context:**
|
|
263
|
+
1. The repository's harness parity previously only symlinked `CLAUDE.md` and `agents.md`, omitting Google Antigravity & Gemini CLI (`GEMINI.md`), Cursor (`.cursorrules`), and Windsurf (`.windsurfrules`), leading to configuration discovery divergence across different AI coding environments.
|
|
264
|
+
2. Root `AGENTS.md` omitted required top-level Workspace Identity, Mission, and Runtime Environment contracts mandated by `agentic_configuration.md`.
|
|
265
|
+
3. Skill subdirectories used non-standard terminology (`assets/` instead of `resources/` / `examples/`), and skills (`lets-build`, `relentless-questioner`) lacked explicit `## 5. Subdirectories & Progressive Resources` catalogs, leaving reference files orphaned.
|
|
266
|
+
4. The deterministic configuration validator omitted checks for closing frontmatter delimiters, negative boundary trigger phrasing in skill descriptions, and additional harness symlinks.
|
|
267
|
+
- **Decision:**
|
|
268
|
+
1. **Omni-Harness Parity**: Expand harness parity to establish and assert symlinks across all 5 major AI coding harnesses: `CLAUDE.md`, `agents.md`, `GEMINI.md`, `.cursorrules`, and `.windsurfrules` pointing to root `AGENTS.md`. Update `lib/scaffold.js` to automatically stamp all 5 symlinks during scaffolding.
|
|
269
|
+
2. **Standardized Skill Folder Taxonomy**: Align skill subdirectory architecture strictly with standard Agent Skills and Antigravity specifications: `scripts/` (executable tools), `references/` (documentation), `resources/` (schemas/templates), and `examples/` (reference patterns), permanently retiring `assets/`.
|
|
270
|
+
3. **Progressive Resource Discoverability**: Ensure 100% of skills in `.agents/skills/` catalog all sub-resources and scripts under a standardized `## 5. Subdirectories & Progressive Resources` section with active links.
|
|
271
|
+
4. **Rigorous Configuration Validator Gates**: Enhance `validate_agentic_configs.sh` to validate all 5 harness symlinks, assert YAML frontmatter closure, verify negative boundary phrasing in skill descriptions, and handle `file://` URIs without false positives.
|
|
272
|
+
5. **Polyglot Skill Neutrality**: Purge hardcoded language-specific assumptions from `clean-code-refactor` and `compliance-audit`, generalizing to universal code health and type safety contracts.
|
|
273
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`docs/rules/agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`.agents/skills/agentic-architect/SKILL.md`](./.agents/skills/agentic-architect/SKILL.md), [`.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh`](./.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh), `lib/scaffold.js`, `bin/azcodr.js`, [`memory.md`](./memory.md).
|
|
274
|
+
|
|
275
|
+
#### ADR-027: Enterprise Agentic Hardening — Lifecycle Hooks, MCP Blueprints, Topology Tracking & Verification Smokes
|
|
276
|
+
- **Date:** 2026-09-26 | **Status:** ACCEPTED
|
|
277
|
+
- **Context:**
|
|
278
|
+
1. The 5-iteration relentless agentic audit identified missing out-of-the-box working schemas for Antigravity Lifecycle Hooks (`hooks.json`) and vendor-neutral Model Context Protocol servers (`mcp_config.json`), leaving users to manually divine JSON schemas for safety guards and MCP tools.
|
|
279
|
+
2. Scaffolding scripts (`bootstrap_workspace.sh`) created empty directory topologies without `.gitkeep`, causing Git to ignore empty leaf folders upon commit and silently dropping scaffolded architecture trees.
|
|
280
|
+
3. Projects scaffolded via `lets-build` lacked a deterministic starter for the required Phase 5 Boundary Verification Smoke Test (`scripts/smoke_test.sh`).
|
|
281
|
+
4. Configuration validation symlink checks strictly matched `"AGENTS.md"`, failing if a symlink used `./AGENTS.md` or absolute paths.
|
|
282
|
+
- **Decision:**
|
|
283
|
+
1. **Lifecycle Hooks & MCP Schema Blueprints**: Provide `.agents/hooks.json.example` (configuring `PreToolUse`, `PostToolUse`, `Stop` with `"enabled": false`) and `.agents/mcp_config.json.example` (Stdio and SSE server blueprints) out-of-the-box in the template root for zero-guesswork integration.
|
|
284
|
+
2. **Topology Git Preservation**: Update `bootstrap_workspace.sh` with a `create_leaf` helper that automatically places `.gitkeep` inside empty scaffolded leaf directories across all topologies (extension, game engine, CLI, backend).
|
|
285
|
+
3. **Deterministic Boundary Smoke Test Generation**: Update `bootstrap_workspace.sh` to generate an executable starter `scripts/smoke_test.sh` upon workspace bootstrapping, satisfying Phase 5 verification gates out-of-the-box.
|
|
286
|
+
4. **Path-Tolerant Symlink & Fallback Validation**: Enhance `validate_agentic_configs.sh` with `is_valid_agents_target` and `is_valid_text_pointer` helpers accepting relative (`./AGENTS.md`) and absolute paths, while adding non-breaking validation for `.github/copilot-instructions.md`.
|
|
287
|
+
- **Enforced In:** [`.agents/hooks.json.example`](./.agents/hooks.json.example), [`.agents/mcp_config.json.example`](./.agents/mcp_config.json.example), [`.agents/skills/lets-build/scripts/bootstrap_workspace.sh`](./.agents/skills/lets-build/scripts/bootstrap_workspace.sh), [`.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh`](./.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh), [`memory.md`](./memory.md).
|
|
288
|
+
|
|
155
289
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "azcodr",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.4.0",
|
|
4
4
|
"description": "Enterprise Architecture & Agentic Engineering Starter Template",
|
|
5
5
|
"bin": {
|
|
6
6
|
"azcodr": "bin/azcodr.js"
|
|
@@ -54,6 +54,6 @@
|
|
|
54
54
|
"test:coverage": "node scripts/test_coverage.js",
|
|
55
55
|
"lint": "node --check bin/azcodr.js lib/index.js lib/scaffold.js tests/cli.test.js tests/scaffold.test.js scripts/test_coverage.js",
|
|
56
56
|
"validate": "bash .agents/skills/agentic-architect/scripts/validate_agentic_configs.sh",
|
|
57
|
-
"prepublishOnly": "npm run test:coverage && npm run validate"
|
|
57
|
+
"prepublishOnly": "npm run lint && npm run test:coverage && npm run validate"
|
|
58
58
|
}
|
|
59
59
|
}
|
|
@@ -1,31 +0,0 @@
|
|
|
1
|
-
# Accessibility (A11y) & WCAG 2.2 Standards
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Enforce WCAG 2.2 Level AA compliance, accessible Radix UI primitives, keyboard focus management, visible focus rings, and ARIA live regions across all user interfaces.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Accessible UI Primitives & Radix UI
|
|
8
|
-
|
|
9
|
-
- **Prohibited Native Alerts**: Strictly prohibit browser-native `window.confirm()` or `window.alert()`. Use accessible Radix UI dialogs (`@radix-ui/react-dialog`, `@radix-ui/react-alert-dialog`).
|
|
10
|
-
- **Focus Management & Trapping**:
|
|
11
|
-
- Modal dialogs must trap keyboard focus within the dialog container while open.
|
|
12
|
-
- Closing a dialog must return keyboard focus deterministically to the triggering element.
|
|
13
|
-
- **Visible Focus Indicators**: Never remove default outline rings (`outline: none`) without providing an explicit, high-contrast replacement (`focus-visible:ring-2 focus-visible:ring-offset-2`).
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## 2. Form & Feedback Accessibility
|
|
18
|
-
|
|
19
|
-
- **Form Input Wiring**:
|
|
20
|
-
- Every form input must have an associated `<label>` using `htmlFor` or nested wrapping.
|
|
21
|
-
- Validation errors must be programmatically linked to their inputs via `aria-invalid="true"` and `aria-describedby="<error-message-id>"`.
|
|
22
|
-
- **Dynamic Content & Status Feedback (ARIA Live Regions)**:
|
|
23
|
-
- Asynchronous notifications, toast alerts, and status updates must use `role="status"` or `aria-live="polite"` so screen readers announce changes without interrupting the user.
|
|
24
|
-
- Critical error alerts must use `role="alert"` or `aria-live="assertive"`.
|
|
25
|
-
|
|
26
|
-
---
|
|
27
|
-
|
|
28
|
-
## 3. Visual & Contrast Baselines
|
|
29
|
-
|
|
30
|
-
- **Color Contrast**: Maintain a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text / UI controls against their background.
|
|
31
|
-
- **Semantic Landmark Markup**: Use semantic landmark elements (`<main>`, `<nav>`, `<aside>`, `<header>`, `<footer>`, `<section>`) rather than unsemantic `<div>` structures.
|
|
@@ -1,104 +0,0 @@
|
|
|
1
|
-
# Advanced REST API Patterns & Capability Architecture
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Enrich API responses with capability metadata (Allowed Actions), ensure safe mutations via idempotency keys, enforce cursor pagination, and prevent race conditions with optimistic concurrency.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Allowed Actions & Capability Metadata (HATEOAS-Lite)
|
|
8
|
-
|
|
9
|
-
Clients must not duplicate server-side business and authorization rules to decide whether an action (edit, delete, approve, cancel) is permitted. **The server is the authoritative source of truth.**
|
|
10
|
-
|
|
11
|
-
### Pattern: `_actions` and `_links` Envelope
|
|
12
|
-
Every resource response must embed an `_actions` boolean map and optional `_links` hypermedia block indicating what the requesting caller is permitted to do based on their role, tenant boundaries, and the entity's current state:
|
|
13
|
-
|
|
14
|
-
```json
|
|
15
|
-
{
|
|
16
|
-
"id": "ord_9876",
|
|
17
|
-
"status": "SHIPPED",
|
|
18
|
-
"totalAmount": 149.99,
|
|
19
|
-
"currency": "USD",
|
|
20
|
-
"_actions": {
|
|
21
|
-
"canEdit": false,
|
|
22
|
-
"canCancel": false,
|
|
23
|
-
"canTrack": true,
|
|
24
|
-
"canRequestRefund": true
|
|
25
|
-
},
|
|
26
|
-
"_links": {
|
|
27
|
-
"self": { "href": "/api/v1/orders/ord_9876", "method": "GET" },
|
|
28
|
-
"track": { "href": "/api/v1/orders/ord_9876/tracking", "method": "GET" },
|
|
29
|
-
"refund": { "href": "/api/v1/orders/ord_9876/refunds", "method": "POST" }
|
|
30
|
-
}
|
|
31
|
-
}
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
### UI Benefits
|
|
35
|
-
- Frontend buttons and menus simply bind to `resource._actions.canDelete`.
|
|
36
|
-
- When business logic evolves (e.g. orders over $1,000 require manager approval), only the backend logic changes—zero frontend redeployment required.
|
|
37
|
-
|
|
38
|
-
---
|
|
39
|
-
|
|
40
|
-
## 2. Safe Mutations via Idempotency Keys (IETF Draft)
|
|
41
|
-
|
|
42
|
-
To prevent duplicate processing (double charging, duplicate resource creation) caused by network retries:
|
|
43
|
-
|
|
44
|
-
### Protocol
|
|
45
|
-
- Clients generating mutating requests (`POST`, `PATCH`) must supply a unique `Idempotency-Key: <uuid-v4>` header.
|
|
46
|
-
- **Server Lifecycle**:
|
|
47
|
-
1. Check distributed idempotency store for key `idemp:<tenantId>:<idempotencyKey>`.
|
|
48
|
-
2. If found with status `IN_FLIGHT`: return `409 Conflict` (`IDEMPOTENT_OPERATION_IN_PROGRESS`).
|
|
49
|
-
3. If found with status `COMPLETED`: return the cached status code, headers, and response payload without re-executing.
|
|
50
|
-
4. If not found: Acquire distributed lock, process mutation atomically, cache response with a 24-hour TTL, and release lock.
|
|
51
|
-
|
|
52
|
-
---
|
|
53
|
-
|
|
54
|
-
## 3. High-Scale Keyset / Cursor-Based Pagination
|
|
55
|
-
|
|
56
|
-
Never use offset pagination (`OFFSET 10000 LIMIT 20`) on large tables. Offsets degrade linearly (`O(N)`) and suffer from page-drift anomalies.
|
|
57
|
-
|
|
58
|
-
### Specification
|
|
59
|
-
- Query Parameters: `?cursor=<opaque_base64>&limit=20` (default limit 20, max 100).
|
|
60
|
-
- Response Envelope:
|
|
61
|
-
```json
|
|
62
|
-
{
|
|
63
|
-
"data": [...],
|
|
64
|
-
"pagination": {
|
|
65
|
-
"nextCursor": "ZXlKaWRI...==",
|
|
66
|
-
"hasMore": true,
|
|
67
|
-
"limit": 20
|
|
68
|
-
}
|
|
69
|
-
}
|
|
70
|
-
```
|
|
71
|
-
- **Agnostic Keyset Query Pattern**:
|
|
72
|
-
```sql
|
|
73
|
-
SELECT * FROM orders
|
|
74
|
-
WHERE tenant_id = :tenantId
|
|
75
|
-
AND (created_at, id) < (:cursorCreatedAt, :cursorId)
|
|
76
|
-
ORDER BY created_at DESC, id DESC
|
|
77
|
-
LIMIT :limit + 1;
|
|
78
|
-
```
|
|
79
|
-
If `results.length > limit`, slice the extra item and encode its cursor token for `nextCursor`.
|
|
80
|
-
|
|
81
|
-
---
|
|
82
|
-
|
|
83
|
-
## 4. Optimistic Concurrency Control (OCC)
|
|
84
|
-
|
|
85
|
-
Prevent lost-update anomalies during concurrent edits without pessimistic database row locking:
|
|
86
|
-
|
|
87
|
-
### Protocol
|
|
88
|
-
- Every mutable entity contains an incrementing integer `version` column.
|
|
89
|
-
- Server returns the current version in the `ETag` response header: `ETag: W/"v4"`.
|
|
90
|
-
- Clients submitting updates (`PUT`, `PATCH`) must include `If-Match: W/"v4"`.
|
|
91
|
-
- **Conflict Handling**:
|
|
92
|
-
- Atomic update: `UPDATE table SET ..., version = version + 1 WHERE id = :id AND version = :expectedVersion`.
|
|
93
|
-
- If 0 rows updated: Return **`409 Conflict`** with error code `CONCURRENCY_CONFLICT` and the latest entity representation.
|
|
94
|
-
|
|
95
|
-
---
|
|
96
|
-
|
|
97
|
-
## 5. Asynchronous Processing (`202 Accepted`)
|
|
98
|
-
|
|
99
|
-
For tasks taking > 1.5 seconds (video rendering, large PDF export, batch imports):
|
|
100
|
-
- Do NOT block synchronous client requests.
|
|
101
|
-
- Dispatch task to an asynchronous worker queue or workflow engine.
|
|
102
|
-
- Return **`202 Accepted`** immediately with:
|
|
103
|
-
- Header: `Location: /api/v1/tasks/:taskId`
|
|
104
|
-
- Body: `{ "taskId": "tsk_123", "status": "QUEUED", "pollIntervalMs": 2000 }`
|
|
@@ -1,113 +0,0 @@
|
|
|
1
|
-
# API Versioning, SemVer Lifecycle & Swagger Multi-Version Architecture
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Enforce URI path major versioning (`/api/v1/`), SemVer 2.0.0 contract specifications, RFC 8594 Sunset/Deprecation headers, a 90-day retirement window, and multi-version Swagger UI exploration.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Semantic Versioning (SemVer 2.0.0) in Web APIs
|
|
8
|
-
|
|
9
|
-
Semantic Versioning maps to Web APIs according to contract stability and backward compatibility:
|
|
10
|
-
|
|
11
|
-
$$\text{Version Format: } \mathbf{MAJOR.MINOR.PATCH}$$
|
|
12
|
-
|
|
13
|
-
| SemVer Component | Scope & Impact | Exposure Channel | Example |
|
|
14
|
-
|---|---|---|---|
|
|
15
|
-
| **MAJOR** | Breaking, backwards-incompatible contract modifications. Requires client code/URL changes. | URI Path (`/api/v1/`, `/api/v2/`) & OpenAPI `info.version` | `2.0.0` |
|
|
16
|
-
| **MINOR** | Backwards-compatible additive functionality, new endpoints, or optional attributes. | OpenAPI `info.version`, `API-Version` response header | `1.1.0` |
|
|
17
|
-
| **PATCH** | Backwards-compatible bug fixes, performance optimizations, and documentation fixes. | OpenAPI `info.version`, release tags, telemetry metadata | `1.0.1` |
|
|
18
|
-
|
|
19
|
-
> [!IMPORTANT]
|
|
20
|
-
> **Why URI Path Exposes MAJOR Only:**
|
|
21
|
-
> Exposing minor or patch versions in the URL path (e.g. `/api/v1.2.3/`) is a severe anti-pattern. Minor additions and bug fixes must not break client routing. Clients bind to the stable major version (`/api/v1/`) while consuming backward-compatible updates transparently.
|
|
22
|
-
|
|
23
|
-
---
|
|
24
|
-
|
|
25
|
-
## 2. SemVer Trigger Matrix: What Triggers a Version Update?
|
|
26
|
-
|
|
27
|
-
### A. MAJOR Bump (`1.x.x` ➔ `2.0.0`) — Breaking Changes
|
|
28
|
-
A MAJOR version bump and a new URI prefix (`/api/v2/`) are triggered whenever existing clients would fail without code modifications:
|
|
29
|
-
|
|
30
|
-
1. **Endpoint Alterations:**
|
|
31
|
-
- Deleting an existing endpoint or HTTP method.
|
|
32
|
-
- Renaming an existing URL path or subresource route.
|
|
33
|
-
2. **Request Contract Breaking Changes:**
|
|
34
|
-
- Removing an existing request parameter (header, query, or body field).
|
|
35
|
-
- Renaming a request field.
|
|
36
|
-
- Changing the data type or format of a request field (e.g., string integer to number, date format change).
|
|
37
|
-
- Adding a new **mandatory / required** field to an existing request payload without a default value.
|
|
38
|
-
- Tightening input validation constraints (e.g., reducing max string length, narrowing allowed enum values).
|
|
39
|
-
3. **Response Contract Breaking Changes:**
|
|
40
|
-
- Removing an existing field from a response payload.
|
|
41
|
-
- Changing the data type or structure of a response field (e.g., object converted to array, integer cents converted to float string).
|
|
42
|
-
- Changing the semantic business meaning of a field.
|
|
43
|
-
4. **Behavioral & Protocol Breaking Changes:**
|
|
44
|
-
- Altering the standard HTTP status code for successful execution (e.g., changing `200 OK` to `204 No Content` or `201 Created`).
|
|
45
|
-
- Changing the error envelope schema away from RFC 7807 problem details.
|
|
46
|
-
- Changing authentication or authorization requirements (e.g. requiring a new OAuth scope or mTLS).
|
|
47
|
-
|
|
48
|
-
### B. MINOR Bump (`1.0.x` ➔ `1.1.0`) — Additive, Backward-Compatible
|
|
49
|
-
A MINOR version bump preserves the `/api/v1/` URI path and updates the contract specification:
|
|
50
|
-
|
|
51
|
-
1. Adding completely new endpoints or resources (e.g., adding `POST /api/v1/documents/:id/signatures`).
|
|
52
|
-
2. Adding new optional query parameters, headers, or request body fields.
|
|
53
|
-
3. Adding new fields to response payloads (clients must follow Postel's Law / Tolerant Reader pattern).
|
|
54
|
-
4. Adding new enum values to input requests if the service handles them gracefully without breaking old clients.
|
|
55
|
-
5. Relaxing validation constraints (e.g., increasing maximum allowed file upload size or string length).
|
|
56
|
-
6. Introducing deprecation notices on endpoints (via RFC 8594 headers) while maintaining functionality.
|
|
57
|
-
|
|
58
|
-
### C. PATCH Bump (`1.0.0` ➔ `1.0.1`) — Bug Fixes & Non-Contractual Changes
|
|
59
|
-
A PATCH version bump preserves contract schemas and updates release metadata:
|
|
60
|
-
|
|
61
|
-
1. Internal bug fixes in domain logic that do not alter the contractual request/response schema or status codes.
|
|
62
|
-
2. Performance enhancements, caching optimization, and database indexing.
|
|
63
|
-
3. Security patches in dependencies and runtime frameworks.
|
|
64
|
-
4. Clarifications, typo corrections, and formatting updates in OpenAPI descriptions.
|
|
65
|
-
|
|
66
|
-
---
|
|
67
|
-
|
|
68
|
-
## 3. RFC 8594 Sunset & Deprecation Lifecycle
|
|
69
|
-
|
|
70
|
-
When an older major version or endpoint is scheduled for retirement, inject standardized RFC 8594 headers:
|
|
71
|
-
|
|
72
|
-
```http
|
|
73
|
-
Deprecation: @1773619200
|
|
74
|
-
Sunset: Wed, 16 Sep 2026 23:59:59 GMT
|
|
75
|
-
Link: <https://api.domain.com/docs/migration/v2>; rel="sunset"
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
- **Mandatory 90-Day Migration Window:** Retain deprecated API versions for a minimum of 90 days following formal deprecation notification before decommissioning.
|
|
79
|
-
- **Access Telemetry:** Track consumer traffic on deprecated routes via OpenTelemetry attributes (`api.deprecated=true`, `http.route`) to coordinate client migration.
|
|
80
|
-
|
|
81
|
-
---
|
|
82
|
-
|
|
83
|
-
## 4. Swagger UI Multi-Version Selector Architecture
|
|
84
|
-
|
|
85
|
-
Swagger UI must provide an interactive version dropdown selector enabling consumers and developers to inspect both active and upcoming API specifications.
|
|
86
|
-
|
|
87
|
-
### Multi-Spec Configuration in Express / Swagger UI:
|
|
88
|
-
```ts
|
|
89
|
-
app.use(
|
|
90
|
-
'/docs',
|
|
91
|
-
swaggerUi.serve,
|
|
92
|
-
swaggerUi.setup(undefined, {
|
|
93
|
-
swaggerOptions: {
|
|
94
|
-
urls: [
|
|
95
|
-
{ url: '/specs/v1/openapi.yaml', name: 'v1.0.0 (Current Stable)' },
|
|
96
|
-
{ url: '/specs/v2/openapi.yaml', name: 'v2.0.0-draft (Next Major Preview)' }
|
|
97
|
-
],
|
|
98
|
-
'urls.primaryName': 'v1.0.0 (Current Stable)'
|
|
99
|
-
}
|
|
100
|
-
})
|
|
101
|
-
);
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
### Filesystem Specification Hierarchy:
|
|
105
|
-
```
|
|
106
|
-
specs/
|
|
107
|
-
├── openapi/
|
|
108
|
-
│ ├── v1/
|
|
109
|
-
│ │ └── openapi.yaml
|
|
110
|
-
│ └── v2/
|
|
111
|
-
│ └── openapi.yaml
|
|
112
|
-
```
|
|
113
|
-
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# Application Security & OWASP Top 10 Defenses
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Enforce proactive defenses against the OWASP Top 10 vulnerabilities, cryptographic rigor, and token-bucket rate limiting across all layers.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. OWASP Top 10 Defenses
|
|
8
|
-
|
|
9
|
-
- **A01: Broken Access Control**: Verify permissions server-side on every request using Policy Enforcement Points (PEPs). Enforce immutable multi-tenancy data isolation (AST interceptors, database RLS, or schema namespaces).
|
|
10
|
-
- **A02: Cryptographic Failures**: Passwords must be hashed using **Argon2id** with memory-hard parameters. Encrypt sensitive data at rest using authenticated ciphers (**AES-256-GCM** or **ChaCha20-Poly1305**).
|
|
11
|
-
- **A03: Injection (SQL / NoSQL / Command)**: Strictly prohibit raw query string interpolation or dynamic execution. All database interactions must use parameterized prepared statements.
|
|
12
|
-
- **A07: Identification and Authentication Failures**: Enforce rate limiting on auth endpoints, FIDO2/WebAuthn passkeys, and Refresh Token Rotation (RTR) with family invalidation on replay detection.
|
|
13
|
-
- **A10: Server-Side Request Forgery (SSRF)**: Validate and restrict outbound network requests to an explicit allowlist of domains. Block requests targeting RFC 1918 private IP ranges, loopback addresses (`127.0.0.1`), and cloud metadata endpoints (`169.254.169.254`).
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## 2. Distributed API Rate Limiting
|
|
18
|
-
|
|
19
|
-
- Utilize token-bucket or sliding-window rate limiters backed by a distributed in-memory cache port.
|
|
20
|
-
- Enforce tiered rate limits:
|
|
21
|
-
- Authentication routes: Max 5 requests / minute per IP.
|
|
22
|
-
- Standard API routes: Max 100 requests / minute per tenant/user.
|
|
23
|
-
- Return **`429 Too Many Requests`** with standard `Retry-After` and `RateLimit-*` IETF headers when limits are exceeded.
|
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
# Architecture Decision Records (ADR)
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Log all technical, architectural, and operational trade-offs in `memory.md` using the standardized Lightweight ADR format.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. When to Author an ADR
|
|
8
|
-
|
|
9
|
-
An Architectural Decision Record must be authored whenever a team member or agent:
|
|
10
|
-
- Introduces or removes an external dependency or library.
|
|
11
|
-
- Modifies database schema architecture, transaction boundaries, or migration strategies.
|
|
12
|
-
- Selects an architectural pattern (e.g. Server-Driven UI, Event-Driven Outbox, OpenFeature).
|
|
13
|
-
- Defines security boundaries, cryptographic standards, or compliance exceptions.
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## 2. Lightweight ADR Format
|
|
18
|
-
|
|
19
|
-
Log decisions in `memory.md` adhering to this structure:
|
|
20
|
-
|
|
21
|
-
```markdown
|
|
22
|
-
### ADR-[Number]: [Concise Title]
|
|
23
|
-
|
|
24
|
-
- **Date:** [YYYY-MM-DD]
|
|
25
|
-
- **Status:** [PROPOSED | ACCEPTED | SUPERSEDED]
|
|
26
|
-
|
|
27
|
-
#### 1. Context & Problem Statement
|
|
28
|
-
What business requirement, technical bottleneck, or security mandate necessitated this architectural decision?
|
|
29
|
-
|
|
30
|
-
#### 2. Decision Drivers
|
|
31
|
-
- [Driver 1: e.g. Zero-downtime database deployment]
|
|
32
|
-
- [Driver 2: e.g. SOC 2 Type II tamper-evident logging compliance]
|
|
33
|
-
|
|
34
|
-
#### 3. Considered Options
|
|
35
|
-
- **Option A:** [Description and evaluation]
|
|
36
|
-
- **Option B:** [Description and evaluation]
|
|
37
|
-
|
|
38
|
-
#### 4. Decision Outcome & Consequences
|
|
39
|
-
- **Chosen Option:** [Selected approach and core rationale]
|
|
40
|
-
- **Positive Consequences:** [What improves]
|
|
41
|
-
- **Negative Consequences / Trade-offs:** [What operational or code overhead is accepted]
|
|
42
|
-
```
|
package/docs/rules/compliance.md
DELETED
|
@@ -1,25 +0,0 @@
|
|
|
1
|
-
# Regulatory Compliance: SOC 2, ISO 27001 & GDPR
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Enforce SOC 2 Type II Trust Services Criteria, ISO/IEC 27001 ISMS technical controls, and GDPR data subject privacy rights using open-source architectures.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. SOC 2 Type II Trust Services Criteria
|
|
8
|
-
|
|
9
|
-
- **Access Controls (CC6.1)**: Enforce least-privilege RBAC/ABAC on all API endpoints. System-defined roles must be protected from unauthorized mutation.
|
|
10
|
-
- **Tamper-Evident Audit Trails (CC7.2)**:
|
|
11
|
-
- All state mutations must create write-only, immutable audit log records:
|
|
12
|
-
`{ timestamp, actorId, tenantId, action, entityType, entityId, ipAddress, userAgent, changes: { before, after } }`.
|
|
13
|
-
- Audit logs must be retained for at least 365 days in append-only storage.
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## 2. ISO/IEC 27001 ISMS Technical Controls
|
|
18
|
-
|
|
19
|
-
- **Annex A Cryptographic Controls (A.10.1)**: Enforce TLS 1.3 for data in transit and AES-256-GCM for sensitive data at rest. Passwords must be hashed using Argon2id or bcrypt.
|
|
20
|
-
|
|
21
|
-
---
|
|
22
|
-
|
|
23
|
-
## 3. GDPR Data Subject Rights
|
|
24
|
-
|
|
25
|
-
- **Right to Erasure (Article 17)**: Deleting a tenant or user must cascade delete or pseudonymize all associated personal identifiable information (PII) across active databases and backups.
|