azcodr 1.0.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/skills/agentic-architect/SKILL.md +118 -0
- package/.agents/skills/agentic-architect/references/agents_md_template.md +59 -0
- package/.agents/skills/agentic-architect/references/refinement_workflow.md +32 -0
- package/.agents/skills/agentic-architect/references/skill_architecture_inquiry.md +63 -0
- package/.agents/skills/agentic-architect/references/skill_template.md +55 -0
- package/.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh +163 -0
- package/.agents/skills/clean-code-refactor/SKILL.md +91 -0
- package/.agents/skills/clean-code-refactor/references/clean_code_smells.md +27 -0
- package/.agents/skills/clean-code-refactor/references/design_patterns_ts.md +65 -0
- package/.agents/skills/compliance-audit/SKILL.md +120 -0
- package/.agents/skills/compliance-audit/references/owasp_top10_controls.md +16 -0
- package/.agents/skills/compliance-audit/references/soc2_iso_controls.md +28 -0
- package/.agents/skills/lets-build/SKILL.md +164 -0
- package/.agents/skills/lets-build/references/architecture_interview_matrix.md +188 -0
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +113 -0
- package/.agents/skills/lets-build/references/project_readme_template.md +79 -0
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +68 -0
- package/.agents/skills/merge-ai/SKILL.md +90 -0
- package/.agents/skills/merge-ai/scripts/audit_divergence.sh +108 -0
- package/.agents/skills/merge-ai/scripts/resolve_repo.sh +177 -0
- package/.agents/skills/product-analyst/SKILL.md +143 -0
- package/.agents/skills/product-analyst/references/backlog_ordering_techniques.md +107 -0
- package/.agents/skills/product-analyst/references/gherkin_patterns.md +46 -0
- package/.agents/skills/product-analyst/references/invest_checklist.md +38 -0
- package/.agents/skills/product-analyst/references/okr_alignment_guide.md +76 -0
- package/.agents/skills/product-analyst/references/smart_tasks.md +59 -0
- package/.agents/skills/relentless-questioner/SKILL.md +120 -0
- package/.agents/skills/relentless-questioner/references/adaptive_question_trees.md +84 -0
- package/.gitignore +20 -0
- package/AGENTS.md +119 -0
- package/LICENSE +21 -0
- package/README.md +184 -0
- package/bin/azcodr.js +151 -0
- package/docs/knowledge/dos_and_donts.md +540 -0
- package/docs/knowledge/issue_log.md +25 -0
- package/docs/knowledge/knowledge_graph.md +188 -0
- package/docs/knowledge/lessons_learned.md +107 -0
- package/docs/knowledge/ubiquitous_language.md +23 -0
- package/docs/rules/accessibility.md +31 -0
- package/docs/rules/advanced_api_patterns.md +104 -0
- package/docs/rules/agentic_configuration.md +168 -0
- package/docs/rules/api_versioning.md +128 -0
- package/docs/rules/application_security.md +23 -0
- package/docs/rules/architecture_decision_records.md +42 -0
- package/docs/rules/authentication.md +76 -0
- package/docs/rules/authorization.md +75 -0
- package/docs/rules/caching.md +52 -0
- package/docs/rules/clean_code.md +25 -0
- package/docs/rules/cloud_native.md +43 -0
- package/docs/rules/compliance.md +25 -0
- package/docs/rules/container_infrastructure.md +32 -0
- package/docs/rules/continuous_deployment.md +24 -0
- package/docs/rules/continuous_integration.md +20 -0
- package/docs/rules/continuous_learning.md +29 -0
- package/docs/rules/database_integrity.md +88 -0
- package/docs/rules/database_migrations.md +41 -0
- package/docs/rules/database_operations.md +27 -0
- package/docs/rules/database_performance.md +44 -0
- package/docs/rules/database_transactions.md +81 -0
- package/docs/rules/design_patterns.md +40 -0
- package/docs/rules/devsecops.md +33 -0
- package/docs/rules/domain_driven_design.md +84 -0
- package/docs/rules/domain_expertise.md +42 -0
- package/docs/rules/error_handling.md +39 -0
- package/docs/rules/feature_flags.md +42 -0
- package/docs/rules/gof_design_patterns_reference.md +70 -0
- package/docs/rules/multitenancy_isolation.md +86 -0
- package/docs/rules/product_ownership.md +150 -0
- package/docs/rules/project_management.md +66 -0
- package/docs/rules/react.md +88 -0
- package/docs/rules/relentless_questioning.md +48 -0
- package/docs/rules/requirements_engineering.md +113 -0
- package/docs/rules/rest_api_conventions.md +62 -0
- package/docs/rules/server_driven_ui.md +71 -0
- package/docs/rules/tenant_dynamic_schemas.md +88 -0
- package/docs/rules/tenant_pluggable_logic.md +59 -0
- package/docs/rules/test_driven_development.md +106 -0
- package/docs/rules/test_isolation.md +26 -0
- package/docs/rules/transactional_email.md +20 -0
- package/docs/rules/typescript.md +55 -0
- package/docs/rules/ui_navigation.md +20 -0
- package/docs/rules/ui_ux_architecture.md +168 -0
- package/docs/rules/upstream_synchronization.md +66 -0
- package/docs/rules/workflow_state_machines.md +118 -0
- package/docs/rules/workspace_isolation.md +25 -0
- package/lib/index.js +5 -0
- package/lib/scaffold.js +177 -0
- package/memory.md +262 -0
- package/package.json +49 -0
|
@@ -0,0 +1,120 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: compliance-audit
|
|
3
|
+
description: Use when conducting a security, compliance, or vulnerability audit against SOC 2 Type II, ISO/IEC 27001, or OWASP Top 10 controls using open-source scanners (Trivy, Semgrep, Gitleaks, Steampipe, Syft, Grype). Do not use for writing application business logic or routine test authoring.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Compliance & Security Audit Skill (100% Open-Source)
|
|
7
|
+
|
|
8
|
+
> **Core Purpose:** Execute systematic compliance and vulnerability evaluations against SOC 2 Type II Trust Services Criteria, ISO/IEC 27001 ISMS standards, and the OWASP Top 10 using exclusively open-source security toolchains.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. When to Use This Skill
|
|
13
|
+
- Preparing for or validating SOC 2 Type II readiness (access controls, tamper-evident audit logging, encryption).
|
|
14
|
+
- Verifying ISO/IEC 27001 Annex A technical security controls.
|
|
15
|
+
- Running comprehensive static analysis and vulnerability scans before a production release.
|
|
16
|
+
- Generating software bill of materials (SBOM) and container vulnerability reports.
|
|
17
|
+
- Reviewing sensitive data handling and GDPR/privacy erasure compliance.
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## 2. Step-by-Step Audit Workflow
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
1. Secrets & Credentials ──► 2. SAST Analysis ──► 3. Dependency CVEs ──► 4. Architecture & Access ──► 5. Audit Report
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
### Step 1: Secret & Credential Scan (Open-Source)
|
|
28
|
+
Run open-source secret scanners to verify zero committed keys, tokens, or credentials:
|
|
29
|
+
```bash
|
|
30
|
+
# Using open-source Gitleaks
|
|
31
|
+
gitleaks detect --source . -v
|
|
32
|
+
# Using open-source Secretlint
|
|
33
|
+
npx secretlint "**/*"
|
|
34
|
+
```
|
|
35
|
+
*Pass Criteria:* 0 detected secrets or private keys in git history and working tree.
|
|
36
|
+
|
|
37
|
+
### Step 2: Static Application Security Testing (SAST)
|
|
38
|
+
Run open-source `semgrep` with security rulesets to detect injection flaws, insecure deserialization, and dangerous sinks:
|
|
39
|
+
```bash
|
|
40
|
+
semgrep --config p/security-audit --config p/owasp-top-ten .
|
|
41
|
+
```
|
|
42
|
+
*Pass Criteria:* 0 High or Critical vulnerabilities.
|
|
43
|
+
|
|
44
|
+
### Step 3: Dependency & Container Vulnerability Scan
|
|
45
|
+
Run open-source `trivy` and `grype` to audit lockfiles and containers for known CVEs:
|
|
46
|
+
```bash
|
|
47
|
+
# Filesystem CVE scan via Trivy
|
|
48
|
+
trivy fs --severity HIGH,CRITICAL --scanners vuln,misconfig .
|
|
49
|
+
# Generate CycloneDX SBOM via Syft
|
|
50
|
+
syft dir:. -o cyclonedx-json=bom.json
|
|
51
|
+
# Scan SBOM via Grype
|
|
52
|
+
grype sbom:bom.json
|
|
53
|
+
```
|
|
54
|
+
*Pass Criteria:* 0 unpatched Critical or High CVEs in production dependencies.
|
|
55
|
+
|
|
56
|
+
### Step 4: SOC 2 & ISO 27001 Control Verification
|
|
57
|
+
Audit architectural implementation against compliance baselines:
|
|
58
|
+
- **Audit Logging (CC7.2 / A.12)**: Are all state mutations logged with `{ timestamp, actorId, tenantId, action, entityType, entityId, ipAddress, userAgent, changes: { before, after } }`? Are audit logs write-only and tamper-evident?
|
|
59
|
+
- **Access Control & RBAC (CC6.1 / A.9)**: Are built-in roles protected against mutation (`403 Forbidden`)? Is tenant isolation enforced on every query (`tenantId` predicate)?
|
|
60
|
+
- **Cryptography (CC6.6 / A.10)**: Is TLS 1.3 enforced? Are passwords hashed using Argon2id or bcrypt? Is AES-256-GCM used for sensitive data at rest?
|
|
61
|
+
- **Data Erasure & GDPR**: Does the tenant deletion endpoint cascade purge or pseudonymize user PII across all entities?
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## 3. Gotchas & What NOT to Do
|
|
66
|
+
|
|
67
|
+
- **DO NOT** use proprietary cloud security scanners when open-source equivalents exist (`trivy`, `semgrep`, `gitleaks`, `syft`, `grype`).
|
|
68
|
+
- **DO NOT** ignore medium/low secrets warnings if they indicate staging credentials or API endpoints.
|
|
69
|
+
- **DO NOT** pass an audit if audit logs lack the `actorId` or `tenantId`. Traceability is a mandatory SOC 2 requirement.
|
|
70
|
+
- **DO NOT** accept raw SQL concatenation anywhere in the codebase. All queries must be parameterized.
|
|
71
|
+
- **DO NOT** recommend disabling security checks or silencing scanner rules without a documented ADR exception in `memory.md`.
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## 4. Structured Audit Output Template
|
|
76
|
+
|
|
77
|
+
```markdown
|
|
78
|
+
# Security & Compliance Audit Report
|
|
79
|
+
|
|
80
|
+
- **Date:** [YYYY-MM-DD]
|
|
81
|
+
- **Auditor:** AI Assistant (Compliance Audit Skill)
|
|
82
|
+
- **Frameworks Evaluated:** SOC 2 Type II, ISO/IEC 27001, OWASP Top 10
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
86
|
+
## 1. Executive Summary
|
|
87
|
+
- **Overall Status:** [PASS / CONDITIONAL PASS / FAIL]
|
|
88
|
+
- **Critical Issues:** [Count]
|
|
89
|
+
- **High Issues:** [Count]
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
## 2. Open-Source Tool Execution Evidence
|
|
94
|
+
| Tool | Target | Status | Findings |
|
|
95
|
+
|---|---|---|---|
|
|
96
|
+
| `gitleaks` | Git Tree | PASS | 0 secrets found |
|
|
97
|
+
| `semgrep` | Source Code | PASS | 0 critical SAST flaws |
|
|
98
|
+
| `trivy` | Dependencies | PASS | 0 high/critical CVEs |
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## 3. Compliance Control Evaluation Matrix
|
|
103
|
+
| Framework | Control ID | Control Description | Status | Evidence / Notes |
|
|
104
|
+
|---|---|---|---|---|
|
|
105
|
+
| **SOC 2** | CC6.1 | Least-privilege RBAC & tenant isolation | PASS | Scoped queries in Prisma |
|
|
106
|
+
| **SOC 2** | CC7.2 | Tamper-evident mutation audit logging | PASS | Audit table with actor tracing |
|
|
107
|
+
| **ISO 27001** | A.10.1 | Cryptographic controls (AES-256, TLS 1.3) | PASS | TLS 1.3 configured, Argon2id auth |
|
|
108
|
+
| **OWASP** | A01 | Broken Access Control checks | PASS | Server-side guards on all routes |
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## 4. Required Remediation Actions
|
|
113
|
+
1. [Action item #1 with assigned file and timeline]
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
---
|
|
117
|
+
|
|
118
|
+
## 5. Subdirectories & Progressive Resources
|
|
119
|
+
- [references/soc2_iso_controls.md](./references/soc2_iso_controls.md): Detailed mapping of SOC 2 Trust Services Criteria and ISO 27001 Annex A controls.
|
|
120
|
+
- [references/owasp_top10_controls.md](./references/owasp_top10_controls.md): OWASP Top 10 verification checklist and remediation patterns.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# OWASP Top 10 Verification Reference
|
|
2
|
+
|
|
3
|
+
Verification guidelines for evaluating codebase resistance against the OWASP Top 10 vulnerabilities.
|
|
4
|
+
|
|
5
|
+
| Vulnerability | Verification Target | Required Implementation Pattern |
|
|
6
|
+
|---|---|---|
|
|
7
|
+
| **A01: Broken Access Control** | Controllers, Route Guards | Server-side role and tenant checks on every endpoint. No client-only route security. |
|
|
8
|
+
| **A02: Cryptographic Failures** | Config, Auth Services | TLS 1.3, Argon2id/Bcrypt for passwords, AES-256-GCM for sensitive fields. No custom hashing. |
|
|
9
|
+
| **A03: Injection** | Database queries, OS calls | Parameterized Prisma queries; prohibit string template concatenation in SQL; avoid `child_process.exec`. |
|
|
10
|
+
| **A04: Insecure Design** | Architectural Flows | Rate-limiting on public/auth routes via Redis; defense-in-depth threat modeling. |
|
|
11
|
+
| **A05: Security Misconfig** | HTTP Headers, Errors | Helmet headers (`CSP`, `HSTS`, `nosniff`); mask stack traces via Standard Error Envelope. |
|
|
12
|
+
| **A06: Vulnerable Components** | Dependencies | Zero high/critical CVEs in `npm audit` / `trivy fs .`; lockfiles committed and verified. |
|
|
13
|
+
| **A07: Auth Failures** | Auth Controller, JWT | In-memory access tokens, HttpOnly refresh cookies, instant Redis JTI blocklisting. |
|
|
14
|
+
| **A08: Software Integrity** | CI/CD, Dependencies | Lockfile SHA-512 hashes enforced; open-source `cosign` container signing. |
|
|
15
|
+
| **A09: Logging Failures** | Logging, Middleware | Structured JSON logs (`pino`) with `x-request-id`; zero credentials or PII in logs. |
|
|
16
|
+
| **A10: SSRF** | Outbound HTTP Clients | Block outbound requests to internal/private IPs (`127.0.0.1`, `10.0.0.0/8`, `169.254.169.254`). |
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# SOC 2 Type II & ISO 27001 Controls Reference
|
|
2
|
+
|
|
3
|
+
Mapping of technical compliance controls to concrete software verification steps.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Access Control (SOC 2 CC6.1 / ISO 27001 A.9)
|
|
8
|
+
- **Tenant Boundary Isolation**: Every database interaction must filter by the authenticated tenant ID (`where: { tenantId, ... }`). Cross-tenant access must return 403 or 404.
|
|
9
|
+
- **Role Immutability**: Built-in system roles (e.g. `SUPER_ADMIN`, `SYSTEM`) must reject modification or deletion with an explicit `403 Forbidden` response.
|
|
10
|
+
- **Session Expiry**: User access tokens must have short lifespans (15–30 minutes) stored in-memory; refresh tokens must be revoked immediately upon logout via Redis blocklist.
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## 2. Audit Trails & Monitoring (SOC 2 CC7.2 / ISO 27001 A.12)
|
|
15
|
+
- **Immutable Log Storage**: All state mutations must write an audit record with:
|
|
16
|
+
- `timestamp`: ISO-8601 UTC string.
|
|
17
|
+
- `actorId`: User ID initiating the mutation.
|
|
18
|
+
- `tenantId`: Tenant context ID.
|
|
19
|
+
- `action`: e.g. `CREATE_ROLE`, `DELETE_MEMBER`, `UPDATE_PAYMENT`.
|
|
20
|
+
- `entityType` & `entityId`.
|
|
21
|
+
- `ipAddress` & `userAgent`.
|
|
22
|
+
- **Log Integrity**: Audit records must never be updated or deleted by standard application operations.
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 3. Cryptography & Data Protection (SOC 2 CC6.6 / ISO 27001 A.10)
|
|
27
|
+
- **In-Transit**: TLS 1.3 enforced on reverse proxy / ingress. Strict Transport Security (`HSTS`) header enabled with `max-age=31536000; includeSubDomains`.
|
|
28
|
+
- **At-Rest**: Database disks encrypted via AES-256; sensitive tokens or credentials stored as salted hashes (`argon2id` or `bcrypt`) or encrypted payloads.
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: lets-build
|
|
3
|
+
description: Use when initializing or bootstrapping a new project from this template workspace, or when the user invokes '/lets-build' to conduct deep research and relentless questioning across language, stack, frameworks, package managers, databases, and architectural layers, followed by scaffolding the finalized project. Do not use for routine bug fixing, editing existing code features, or auditing already bootstrapped projects.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Let's Build: Interactive Architecture Research & Project Bootstrapper
|
|
7
|
+
|
|
8
|
+
> **Core Purpose:** Conduct an exhaustive, relentless architectural interview across all 18 systemic dimensions to finalize technical choices (language, runtime, frameworks, package managers, databases, tenancy, auth, workflows, observability, CI/CD) with zero assumptions, synthesize an approved ADR, and bootstrap the project following strict Hexagonal architecture.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. When to Use This Skill
|
|
13
|
+
|
|
14
|
+
- When the user starts a fresh project by copying this workspace into a new directory.
|
|
15
|
+
- When the user explicitly invokes `/lets-build` or asks to initialize/scaffold a new application.
|
|
16
|
+
- When transforming or re-architecting an existing project to adhere to the 41 atomic domain rules.
|
|
17
|
+
- **Do NOT use for**:
|
|
18
|
+
- Routine bug fixes or minor edits on an already bootstrapped codebase.
|
|
19
|
+
- Adding a single endpoint or modifying an existing domain model.
|
|
20
|
+
- Running security audits (use `compliance-audit`).
|
|
21
|
+
- Refactoring existing code smells (use `clean-code-refactor`).
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## 2. Step-by-Step Execution Workflow
|
|
26
|
+
|
|
27
|
+
Progress through five mandatory stages:
|
|
28
|
+
|
|
29
|
+
```
|
|
30
|
+
1. DISCOVER (Toolchain & Root) ──► 2. INTERROGATE (Relentless Interview) ──► 3. SYNTHESIZE (ADR & Blueprint) ──► 4. BOOTSTRAP (Scaffold Code) ──► 5. VERIFY (Prove Health)
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
### Phase 1: Discover (Toolchain & Workspace Inspection)
|
|
36
|
+
1. Inspect the workspace root: confirm whether this is a fresh copy or an existing codebase.
|
|
37
|
+
2. Check for pre-installed development runtimes and CLI tools (`go`, `rustc`/`cargo`, `python3`/`uv`, `node`/`pnpm`, `docker`, `atlas`, `semgrep`).
|
|
38
|
+
3. Verify that `AGENTS.md`, `memory.md`, and `docs/rules/` exist and remain intact.
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
### Phase 2: Interrogate (The Relentless Architecture Interview)
|
|
43
|
+
Do NOT guess or assume any technology or stack choice. Execute the relentless interrogation using [references/architecture_interview_matrix.md](./references/architecture_interview_matrix.md). Group questions logically into digestible batches:
|
|
44
|
+
|
|
45
|
+
#### Batch 1: Domain, Performance & Language
|
|
46
|
+
1. **Domain & Problem Statement:** What is the business problem, expected scale (RPS, active tenants), and compliance requirements (SOC 2, ISO 27001, GDPR)?
|
|
47
|
+
2. **Primary Programming Language & Runtime:** Go, Rust, Python, TypeScript, Java/Kotlin, C#, or Polyglot microservices?
|
|
48
|
+
3. **Package Manager & Toolchain:** Specific package manager (e.g. `uv` vs `poetry`, `cargo`, `pnpm`, `go modules`) and task runner?
|
|
49
|
+
|
|
50
|
+
#### Batch 2: Transports, Protocols & Persistence
|
|
51
|
+
4. **Transport & Network:** REST (OpenAPI 3.1), gRPC (Protobuf v3 via `buf`), GraphQL, or Event-Driven? Which web/transport framework?
|
|
52
|
+
5. **Database & Storage Engine:** Relational (PostgreSQL, MySQL, CockroachDB, SQLite) vs Document (MongoDB) vs Hybrid? ORM vs Query Builder vs raw SQL? Canonical 6 Total Audit Fields?
|
|
53
|
+
6. **Database Migration Tooling:** Declarative migrations (**Atlas**) vs versioned SQL (**Flyway**, **Liquibase**, **Goose**)?
|
|
54
|
+
7. **Multi-Tenancy Isolation Model:** AST query interceptor, Database RLS, Schema-per-tenant, or Database-per-tenant?
|
|
55
|
+
8. **Dynamic Schemas & Extensibility:** Universal **JSON Schema Draft 2020-12** in semi-structured columns, EAV, or virtual columns?
|
|
56
|
+
|
|
57
|
+
#### Batch 3: Pluggable Logic, Security & Identity
|
|
58
|
+
9. **Dynamic Business Logic:** Common Expression Language (CEL), GoF Strategy registries, or WebAssembly (Extism) sandboxes?
|
|
59
|
+
10. **Workflow Orchestration:** Temporal.io durable execution vs Camunda/Zeebe (BPMN 2.0) vs statecharts?
|
|
60
|
+
11. **Authentication & Identity:** OIDC, OAuth 2.1 with PKCE, Passkeys (FIDO2/WebAuthn), PASETO, or JWT with JWKS rotation?
|
|
61
|
+
12. **Authorization Engine:** Open Policy Agent (OPA Rego via HTTP/Wasm), OpenFGA (Zanzibar ReBAC), or Cerbos?
|
|
62
|
+
|
|
63
|
+
#### Batch 4: Presentation, Infrastructure & Quality
|
|
64
|
+
13. **Frontend & Presentation:** Web (React/Vue/Svelte/Web Components), Mobile (Flutter/Native), Server-Driven UI (SDUI), and W3C DTCG Design Tokens?
|
|
65
|
+
14. **Caching & Locks:** Redis, Valkey, Dragonfly, Memcached, or local LRU with XFetch stampede defense?
|
|
66
|
+
15. **Event Streaming:** Apache Kafka, NATS JetStream, RabbitMQ, SQS, with Transactional Outbox?
|
|
67
|
+
16. **Observability:** OpenTelemetry OTLP traces/metrics/logs over gRPC/HTTP with W3C trace context?
|
|
68
|
+
17. **DevSecOps & Verification:** Semgrep SAST, Gitleaks, Trivy scanning, CycloneDX SBOM, Cosign, and Outside-In TDD (London School) with 100% coverage gates?
|
|
69
|
+
18. **Containerization & Deployment:** Minimal OCI Distroless/Scratch, Docker Compose, Kubernetes, and OpenTofu IaC?
|
|
70
|
+
|
|
71
|
+
#### Batch 5: Lifecycles, State Machines & Ubiquitous Language
|
|
72
|
+
19. **State Invariant Separation:** Core Invariant States (Hard FSM in Aggregate Root) vs Tenant-Configurable Operational Workflow Stages (Soft FSM via transition matrices and CEL guards)?
|
|
73
|
+
20. **Ubiquitous Language Agreement:** Living glossary contract (`ubiquitous_language.md`) with AST linter denylists and branded nominal types?
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
### Phase 3: Synthesize (Architecture Blueprint & User Sign-Off)
|
|
78
|
+
1. Consolidate the user's answers into a formal **Consolidated Architectural Blueprint** (using Section 4 template).
|
|
79
|
+
2. Author an Architectural Decision Record in `memory.md` (e.g. `ADR-006: Target Technology Stack & Scaffolding Baseline`).
|
|
80
|
+
3. **STOP AND ASK FOR EXPLICIT CONFIRMATION**: Present the blueprint and ADR to the user. Do NOT write scaffolding code until the user approves the blueprint.
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
### Phase 4: Bootstrap (Deterministic Technical Scaffolding)
|
|
85
|
+
Upon user confirmation:
|
|
86
|
+
1. Run the deterministic workspace initialization script:
|
|
87
|
+
```bash
|
|
88
|
+
bash .agents/skills/lets-build/scripts/bootstrap_workspace.sh . <language>
|
|
89
|
+
```
|
|
90
|
+
2. Generate base infrastructure and open specification foundations in `specs/`:
|
|
91
|
+
- `specs/openapi/v1/openapi.yaml` (minimal health probe and API versioning metadata)
|
|
92
|
+
- `specs/tokens/tokens.json` (W3C DTCG design tokens baseline)
|
|
93
|
+
3. Scaffold initial Hexagonal application technical skeleton following [references/hexagonal_bootstrap_scaffolds.md](./references/hexagonal_bootstrap_scaffolds.md):
|
|
94
|
+
- Pure architecture ports and adapters layout (`src/domain/`, `src/ports/`, `src/adapters/`).
|
|
95
|
+
- Minimal system health probes (`/healthz`, `/readyz`).
|
|
96
|
+
- Strict isolation: **Do NOT scaffold application business features or fabricate domain entities yet.**
|
|
97
|
+
4. Generate build manifests (`go.mod`, `Cargo.toml`, `pyproject.toml`, or `package.json`), linter/formatter configurations, minimal multi-stage `Dockerfile`, and `docker-compose.yml`.
|
|
98
|
+
5. Scaffold initial test runner and boundary verification smoke test (`scripts/smoke_test.sh`).
|
|
99
|
+
6. **Replace Starter README with Project-Specific README**:
|
|
100
|
+
Generate a clean, project-specific `README.md` using [references/project_readme_template.md](./references/project_readme_template.md), completely replacing the starter/meta-template content with the project's actual name, mission, stack highlights, quickstart commands, directory tree, and links to `docs/rules/`.
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
### Phase 5: Verify & Handover to Domain Analysis
|
|
105
|
+
1. Run the workspace validation script:
|
|
106
|
+
```bash
|
|
107
|
+
bash .agents/skills/agentic-architect/scripts/validate_agentic_configs.sh
|
|
108
|
+
```
|
|
109
|
+
2. Execute toolchain dependency checks, build commands, and health probe tests:
|
|
110
|
+
- Compile code and verify zero compiler or lint errors.
|
|
111
|
+
- Verify direct backend and reverse proxy health probes (`/healthz`).
|
|
112
|
+
3. **Mandatory Handover to Domain Analysis (STOP & PIVOT):**
|
|
113
|
+
- **`lets-build` IS NOW COMPLETE.** Do NOT proceed to write domain business entities, repositories, or application features.
|
|
114
|
+
- Present the bootstrapped technical skeleton to the user.
|
|
115
|
+
- Instruct the user to invoke `product-analyst` and `relentless-questioner` to initiate the **Domain Discovery & Requirements Engineering Phase** (Ubiquitous Language, Bounded Contexts, Aggregate Boundaries, INVEST User Stories, and Gherkin Acceptance Criteria) before any domain feature code is written.
|
|
116
|
+
|
|
117
|
+
---
|
|
118
|
+
|
|
119
|
+
## 3. Gotchas & What NOT to Do
|
|
120
|
+
|
|
121
|
+
- **MAJOR DONT: DO NOT invent, assume, or scaffold application domain entities, business logic, or feature pages during `/lets-build`.** The `lets-build` skill is strictly an infrastructure and technical stack bootstrapper. Fabricating business domain features without dedicated domain analysis and relentless questioning of the user is a fatal architectural defect.
|
|
122
|
+
- **DO NOT** assume the stack. Never start writing Go, Rust, Python, or TypeScript before asking the user.
|
|
123
|
+
- **DO NOT** scaffold all options at once. Follow the user's chosen stack strictly.
|
|
124
|
+
- **DO NOT** couple domain entities to ORMs, database libraries, or HTTP frameworks. The domain core must remain pure.
|
|
125
|
+
- **DO NOT** proceed to code generation without presenting the blueprint and receiving explicit user approval.
|
|
126
|
+
- **DO NOT** skip or delete the 41 atomic domain rules in `docs/rules/` during bootstrapping. The rules govern the ongoing lifecycle of the newly bootstrapped project.
|
|
127
|
+
- **DO NOT** create monolithic files (> 300 lines) or large functions (> 30 lines). Maintain strict Clean Code standards.
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## 4. Structured Output Templates
|
|
132
|
+
|
|
133
|
+
### Consolidated Architectural Blueprint Template
|
|
134
|
+
```markdown
|
|
135
|
+
# Architectural Specification & Technology Blueprint
|
|
136
|
+
|
|
137
|
+
## 1. Core Profile
|
|
138
|
+
- **Project Domain:** <domain>
|
|
139
|
+
- **Primary Language & Runtime:** <language / version>
|
|
140
|
+
- **Package Manager & Build Tool:** <tool>
|
|
141
|
+
|
|
142
|
+
## 2. Interface & Transport
|
|
143
|
+
- **Protocols:** <REST / gRPC / CloudEvents>
|
|
144
|
+
- **Transport Framework:** <framework>
|
|
145
|
+
- **Contracts:** <specs/openapi / specs/protobuf>
|
|
146
|
+
|
|
147
|
+
## 3. Persistence & Isolation
|
|
148
|
+
- **Storage Engine:** <engine & version>
|
|
149
|
+
- **Migration Engine:** <Atlas / Flyway / Goose>
|
|
150
|
+
- **Tenancy Isolation:** <Model A / B / C / D>
|
|
151
|
+
- **Dynamic Schemas:** <JSON Schema Draft 2020-12>
|
|
152
|
+
|
|
153
|
+
## 4. Logic, Workflows & Identity
|
|
154
|
+
- **Dynamic Logic:** <Common Expression Language / Wasm Extism>
|
|
155
|
+
- **Workflows:** <Temporal / Camunda / Statecharts>
|
|
156
|
+
- **Authentication:** <OIDC / WebAuthn Passkeys / PASETO>
|
|
157
|
+
- **Authorization:** <OPA Rego / OpenFGA ReBAC>
|
|
158
|
+
|
|
159
|
+
## 5. Operations & Quality
|
|
160
|
+
- **Caching & Streams:** <Cache Engine / Broker>
|
|
161
|
+
- **Observability:** <OpenTelemetry OTLP>
|
|
162
|
+
- **DevSecOps:** <Semgrep / Trivy / Gitleaks / Syft>
|
|
163
|
+
- **Testing:** Outside-In TDD (100.00% coverage gate)
|
|
164
|
+
```
|
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# Comprehensive Architecture Interview Matrix
|
|
2
|
+
|
|
3
|
+
> **Source of Truth:** Exhaustive taxonomy across 20 architectural dimensions to interrogate before bootstrapping any enterprise project.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Dimension 1: Architectural Paradigm & Monolith-to-Service Boundary
|
|
8
|
+
- **System Topology:** Modular Monolith (Modulith), Event-Driven Architecture (EDA), Service-Oriented (SOA), or Microservices?
|
|
9
|
+
- **Domain Decoupling:** Hexagonal Ports & Adapters, Clean Architecture, Onion Architecture, or Pragmatic Layered?
|
|
10
|
+
- **Language Bias:** Zero language bias; pure business domain core decoupled from infrastructure adapters.
|
|
11
|
+
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
## Dimension 2: Core Programming Languages & Runtimes
|
|
15
|
+
- **Primary Languages:**
|
|
16
|
+
- Systems / High-Performance: Rust, Go, or C++23
|
|
17
|
+
- Enterprise / JVM: Java 21+ (Loom virtual threads) or Kotlin
|
|
18
|
+
- Web / Full-Stack: TypeScript (Node.js / Bun)
|
|
19
|
+
- Data / ML / Scripting: Python 3.12+ or Elixir (BEAM concurrency)
|
|
20
|
+
- **Language Invariants:** Strict static sound typing; zero unhandled exceptions at domain boundaries.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
## Dimension 3: Package Managers, Workspaces & Monorepo Tooling
|
|
25
|
+
- **Package Manager:**
|
|
26
|
+
- Node/TS: `pnpm` (with strict isolated node_modules), `bun`, or `yarn` (Berry)
|
|
27
|
+
- Rust: `cargo` (with cargo workspaces)
|
|
28
|
+
- Go: Go Modules (with multi-module workspaces)
|
|
29
|
+
- Python: `uv`, `poetry`, or `pixi`
|
|
30
|
+
- **Monorepo Build Orchestration:** Turborepo, Nx, or Bazel/Buck2 with remote caching?
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Dimension 4: Containerization, Base OS & Cloud-Native Runtime
|
|
35
|
+
- **Container Strategy:**
|
|
36
|
+
- Zero-cve distroless (`gcr.io/distroless/*`) or `scratch` base images?
|
|
37
|
+
- Rootless container execution (`USER nonroot:nonroot`)?
|
|
38
|
+
- Multi-stage Dockerfiles with build caching?
|
|
39
|
+
- **Cloud-Native Invariants:** 12-Factor (2026 Edition); stateless runtime isolates; graceful `SIGTERM` draining.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Dimension 5: API Protocols, Transports & Network Contracts
|
|
44
|
+
- **Primary Transport:**
|
|
45
|
+
- RESTful HTTP/JSON (RFC 7807 problem details + OpenAPI 3.1)
|
|
46
|
+
- gRPC / Protocol Buffers (v3 / Buf CLI)
|
|
47
|
+
- GraphQL (Apollo / GraphQL-Yoga with code-first or schema-first SDL)
|
|
48
|
+
- WebSockets / Server-Sent Events (SSE) for real-time push
|
|
49
|
+
- **API Versioning Strategy:** URI Path (`/v1/`), Request Header, or Media Type negotiation?
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Dimension 6: Database & Persistence Engine
|
|
54
|
+
- **Primary Storage Engine:**
|
|
55
|
+
- Relational: PostgreSQL, MySQL / MariaDB, SQLite, CockroachDB, or TiDB
|
|
56
|
+
- Document / NoSQL: MongoDB, DynamoDB, or Cassandra
|
|
57
|
+
- Multi-Model / Hybrid: Relational core with document extension
|
|
58
|
+
- **Persistence Pattern:** Repository Pattern with raw SQL / query builders (e.g. `sqlx`, `pgx`, `Kysely`, `jOOQ`) vs ORM (e.g. Prisma, SQLAlchemy, GORM, Hibernate)?
|
|
59
|
+
- **Mandatory Universal Audit Columns:**
|
|
60
|
+
- Standardize on **The Canonical 6 Total Audit Fields** (`createdAt`, `createdBy`, `updatedAt`, `updatedBy`, `deletedAt`, `deletedBy`) across all mutable relational entities?
|
|
61
|
+
- Strictly immutable append-only ledgers (`createdAt`, `createdBy` only; updates/deletions prohibited)?
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## Dimension 7: Database Migration & Schema Evolution
|
|
66
|
+
- **Migration Engine:** Declarative schema management (**Atlas**), versioned SQL migrations (**Flyway**, **Liquibase**, **Goose**, or **Bytebase**)?
|
|
67
|
+
- **Zero-Downtime Expand-Contract:** Does the project commit to the 5-phase expand-contract deployment lifecycle?
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## Dimension 8: Multi-Tenancy Data Isolation Model
|
|
72
|
+
- **Isolation Strategy:**
|
|
73
|
+
1. **Model A: Universal AST Query Interceptor** (Tenant column + automatic SQL/query AST rewriting)
|
|
74
|
+
2. **Model B: Database Row-Level Security (RLS)** (Session-scoped `set_config` / session variables)
|
|
75
|
+
3. **Model C: Schema-per-Tenant** (Dedicated database schema namespace per tenant)
|
|
76
|
+
4. **Model D: Database-per-Tenant** (Physical instance routing via connection pool manager)
|
|
77
|
+
5. **Model E: Storage Proxy** (Envoy / ProxySQL / Vitess)
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## Dimension 9: Dynamic Schemas & Extensible Entities
|
|
82
|
+
- **Dynamic Field Storage:** Semi-structured JSON column with **JSON Schema Draft 2020-12** validation vs Entity-Attribute-Value (EAV) vs Virtual Column projection?
|
|
83
|
+
- **Meta-Schema Virtual Entities:** Will tenants define completely custom entities at runtime without code deployments?
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Dimension 10: Pluggable Business Logic & Workflows
|
|
88
|
+
- **Dynamic Rules:** Google's **Common Expression Language (CEL)** vs JSON Logic vs Strategy Registries?
|
|
89
|
+
- **Workflow Orchestration:** **Temporal.io** durable execution vs **Camunda 8 / Zeebe (BPMN 2.0)** vs state machine libraries?
|
|
90
|
+
- **Sandboxed Scripting:** **WebAssembly (Extism / Wasmtime)** micro-sandboxes vs isolated interpreters?
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
## Dimension 11: Authentication & Identity
|
|
95
|
+
- **Protocols:** OpenID Connect (OIDC), OAuth 2.1 with PKCE, SAML 2.0 federation, or local credentials?
|
|
96
|
+
- **Passkeys / Passwordless:** W3C / FIDO2 WebAuthn passkey support?
|
|
97
|
+
- **Token Format:** PASETO (Platform-Agnostic Security Tokens) vs RFC 7519 JWT with JWKS asymmetric key rotation?
|
|
98
|
+
- **Token Rotation:** Cryptographic Refresh Token Rotation (RTR) with family invalidation on replay detection?
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Dimension 12: Authorization & Policy-as-Code
|
|
103
|
+
- **Policy Engine:**
|
|
104
|
+
- **Open Policy Agent (OPA)** (Rego language via REST/gRPC or embedded `.wasm` module)
|
|
105
|
+
- **OpenFGA** (Google Zanzibar Relationship-Based Access Control - ReBAC)
|
|
106
|
+
- **Cerbos** (Stateless policy-as-code)
|
|
107
|
+
- Application-level RBAC / ABAC guard wrappers
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Dimension 13: Presentation, Client & Server-Driven UI (SDUI)
|
|
112
|
+
- **Frontend Framework & Architecture:**
|
|
113
|
+
- Web: React, Vue, Svelte, Solid, Angular, or Web Components?
|
|
114
|
+
- Mobile: Flutter, React Native, iOS SwiftUI, or Android Jetpack Compose?
|
|
115
|
+
- Hypermedia / SSR: HTMX / HTML-over-the-wire?
|
|
116
|
+
- Server-Driven UI (SDUI): Declarative JSON layout schemas rendered by client registries?
|
|
117
|
+
- **UI Component Primitives & Styling:**
|
|
118
|
+
- Standardize on `shadcn/ui` with `@radix-ui` headless primitives + Tailwind CSS?
|
|
119
|
+
- Accessible dialogs, focus trapping, and zero native alerts per `accessibility.md`?
|
|
120
|
+
- **Server-State Caching & Data Synchronization:**
|
|
121
|
+
- **TanStack Query (`@tanstack/react-query`)** with query keys, stale-while-revalidate, and automatic mutation invalidation vs SWR vs raw fetch?
|
|
122
|
+
- **Form State Management & Validation:**
|
|
123
|
+
- **React Hook Form (`react-hook-form` + `@hookform/resolvers/zod`)** or **TanStack Form (`@tanstack/react-form`)** with **Zod** schema contracts?
|
|
124
|
+
- **Data Grids & Table Virtualization:**
|
|
125
|
+
- **TanStack Table (`@tanstack/react-table`)** for headless sorting, filtering, and pagination?
|
|
126
|
+
- **Client Stores & Global State:**
|
|
127
|
+
- **Zustand** vs Jotai vs Redux Toolkit for shared client-only state?
|
|
128
|
+
- **Design Tokens:** W3C Design Tokens Community Group (DTCG) `tokens.json` processed via Style Dictionary?
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## Dimension 14: Caching, Distributed Locks & Session State
|
|
133
|
+
- **Caching Engine:** Redis, Valkey, Dragonfly, KeyDB, Memcached, or local in-memory LRU?
|
|
134
|
+
- **Cache Pattern:** Cache-Aside with jittered TTLs, XFetch probabilistic stampede defense, and event-driven invalidation?
|
|
135
|
+
- **Distributed Locks:** Redis Redlock / atomic SETNX with bounded TTLs?
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## Dimension 15: Distributed Messaging & Event Streaming
|
|
140
|
+
- **Message Broker:** Apache Kafka / Redpanda, NATS JetStream, RabbitMQ, AWS SQS, or Redis Streams?
|
|
141
|
+
- **Event Specification:** CNCF CloudEvents v1.0.2 format?
|
|
142
|
+
- **Transactional Outbox:** Polling relay (`FOR UPDATE SKIP LOCKED`) or Change Data Capture (CDC via Debezium)?
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Dimension 16: Observability, Telemetry & Logging
|
|
147
|
+
- **Standard:** 100% CNCF OpenTelemetry (OTel) with OTLP export over gRPC/HTTP?
|
|
148
|
+
- **Tracing:** W3C Trace Context (`traceparent`, `tracestate`)?
|
|
149
|
+
- **Logging Format:** Structured JSON conforming to Elastic Common Schema (ECS) or OpenTelemetry Resource Schema?
|
|
150
|
+
|
|
151
|
+
---
|
|
152
|
+
|
|
153
|
+
## Dimension 17: DevSecOps, Supply Chain & Security
|
|
154
|
+
- **SAST:** Polyglot Semgrep rules for security and code quality?
|
|
155
|
+
- **Secret Detection:** Pre-commit Gitleaks or Secretlint hooks?
|
|
156
|
+
- **Vulnerability Scanning:** Trivy container and lockfile scanning in CI?
|
|
157
|
+
- **SBOM & Provenance:** Syft CycloneDX 1.6 SBOM generation and Cosign artifact signing?
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## Dimension 18: Testing & Verification Strategy
|
|
162
|
+
- **TDD Methodology:** Outside-In TDD (London School) double loop?
|
|
163
|
+
- **BDD Acceptance:** Executable Cucumber / Gherkin `.feature` criteria?
|
|
164
|
+
- **Contract Testing:** Consumer-Driven Contract testing via Pact?
|
|
165
|
+
- **Property-Based Testing:** Schemathesis OpenAPI / GraphQL automated fuzzing?
|
|
166
|
+
- **Coverage Gate:** Mandatory 100.00% coverage thresholds across all suites?
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Dimension 19: State Machines, Workflows & Lifecycle Configurability
|
|
171
|
+
- **State Taxonomy & Invariant Separation:**
|
|
172
|
+
- **Core Invariant States (Hard FSM):** Enforced strictly inside compiled Domain Aggregate Roots? (Financial/legal integrity states like `SETTLED`, `CANCELLED` cannot be user-rewritten).
|
|
173
|
+
- **Operational Workflow Stages (Soft FSM):** Tenant-configurable review funnels, approval tiers, or sub-statuses managed via Declarative State Transition Matrices?
|
|
174
|
+
- **Transition Guards & Rule Evaluation:**
|
|
175
|
+
- Standardize on Common Expression Language (CEL) or embedded Wasm sandboxing for tenant-defined guards?
|
|
176
|
+
- **Workflow Orchestration:**
|
|
177
|
+
- Durable workflow engine (Temporal.io, Camunda 8 / Zeebe BPMN 2.0) for multi-step distributed sagas?
|
|
178
|
+
- **Transition Audit Trail:**
|
|
179
|
+
- Mandatory append-only state transition log (`transitionId`, `entityType`, `entityId`, `fromState`, `toState`, `event`, `actorId`, `createdAt`)?
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
## Dimension 20: Ubiquitous Language & Domain-Code Agreement
|
|
184
|
+
- **Living Glossary:** Authoritative `docs/knowledge/ubiquitous_language.md` mapping domain terms, business definitions, and exact code identifiers?
|
|
185
|
+
- **Linguistic Drift Defenses:**
|
|
186
|
+
- Mechanical AST / Linter rules (ESLint `id-denylist`) prohibiting banned synonyms?
|
|
187
|
+
- Branded nominal types (`type UserId = string & { readonly __brand: unique symbol }`) preventing primitive obsession and cross-domain identifier confusion?
|
|
188
|
+
- **Anti-Corruption Layer (ACL):** Adapters at system perimeters converting external vendor terminology into the canonical Ubiquitous Language?
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
# Hexagonal Bootstrap Scaffolds & Templates
|
|
2
|
+
|
|
3
|
+
> **Core Purpose:** Standardized directory trees and foundational templates for bootstrapping projects across any language following the Hexagonal (Ports & Adapters) architecture.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Universal Directory Topology
|
|
8
|
+
|
|
9
|
+
Regardless of language, all bootstrapped projects must follow this high-level separation:
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
<project-root>/
|
|
13
|
+
├── .agents/skills/ # Specialized agentic workflows (carried from azcodr template)
|
|
14
|
+
├── docs/
|
|
15
|
+
│ ├── knowledge/ # System knowledge graph, issue log, DO's/DONT's
|
|
16
|
+
│ └── rules/ # 41 atomic single-responsibility domain rules
|
|
17
|
+
├── specs/ # Canonical contract specifications
|
|
18
|
+
│ ├── protobuf/ # gRPC service definitions (*.proto)
|
|
19
|
+
│ ├── openapi/ # OpenAPI 3.1 REST specifications (*.yaml)
|
|
20
|
+
│ ├── schemas/ # Universal JSON Schema Draft 2020-12 (*.json)
|
|
21
|
+
│ └── tokens/ # W3C DTCG Design Tokens (tokens.json)
|
|
22
|
+
├── src/ # Application source code
|
|
23
|
+
│ ├── domain/ # Core Invariant Domain (Entities, Value Objects, Invariants)
|
|
24
|
+
│ ├── ports/ # Primary (driving) and Secondary (driven) Ports
|
|
25
|
+
│ │ ├── primary/ # Inbound Use Cases, Commands, and Queries
|
|
26
|
+
│ │ └── secondary/ # Outbound Repositories, Caches, Event Brokers
|
|
27
|
+
│ └── adapters/ # Concrete Polyglot Implementations
|
|
28
|
+
│ ├── primary/ # HTTP controllers, gRPC handlers, CLI commands
|
|
29
|
+
│ └── secondary/ # SQL/NoSQL repositories, Redis caches, Kafka brokers
|
|
30
|
+
├── tests/
|
|
31
|
+
│ ├── unit/ # Fast unit tests using test doubles
|
|
32
|
+
│ ├── integration/ # Adapter integration tests with transactional rollback
|
|
33
|
+
│ ├── contracts/ # Pact / OpenAPI contract verification
|
|
34
|
+
│ └── acceptance/ # BDD Gherkin / Cucumber end-to-end features
|
|
35
|
+
├── deploy/ # Deployment & Infrastructure as Code
|
|
36
|
+
│ ├── docker/ # Minimal OCI Distroless/Scratch Dockerfiles
|
|
37
|
+
│ ├── compose/ # Docker Compose multi-service topologies
|
|
38
|
+
│ └── k8s/ # Kubernetes manifests or OpenTofu / Crossplane
|
|
39
|
+
├── AGENTS.md # Authoritative lean root directives (< 120 lines)
|
|
40
|
+
├── CLAUDE.md -> AGENTS.md # Symlink for harness parity
|
|
41
|
+
├── agents.md -> AGENTS.md # Symlink for harness parity
|
|
42
|
+
├── memory.md # Master memory hub & Lightweight ADR ledger
|
|
43
|
+
└── README.md # Project documentation
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## 2. Language-Specific Source Layouts
|
|
49
|
+
|
|
50
|
+
### Go Scaffold (`go.mod`)
|
|
51
|
+
```
|
|
52
|
+
src/
|
|
53
|
+
├── domain/
|
|
54
|
+
│ ├── entity/user.go
|
|
55
|
+
│ └── valueobject/tenant_id.go
|
|
56
|
+
├── ports/
|
|
57
|
+
│ ├── in/create_user_usecase.go
|
|
58
|
+
│ └── out/user_repository_port.go
|
|
59
|
+
└── adapters/
|
|
60
|
+
├── in/http/user_handler.go
|
|
61
|
+
└── out/sql/pgx_user_repository.go
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Rust Scaffold (`Cargo.toml`)
|
|
65
|
+
```
|
|
66
|
+
src/
|
|
67
|
+
├── domain/
|
|
68
|
+
│ ├── entities/user.rs
|
|
69
|
+
│ └── value_objects/tenant_id.rs
|
|
70
|
+
├── ports/
|
|
71
|
+
│ ├── primary/create_user.rs
|
|
72
|
+
│ └── secondary/user_repository.rs
|
|
73
|
+
└── adapters/
|
|
74
|
+
├── primary/axum_handler.rs
|
|
75
|
+
└── secondary/sqlx_repository.rs
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Python Scaffold (`pyproject.toml` / `uv`)
|
|
79
|
+
```
|
|
80
|
+
src/
|
|
81
|
+
├── domain/
|
|
82
|
+
│ ├── entities/user.py
|
|
83
|
+
│ └── value_objects/tenant_id.py
|
|
84
|
+
├── ports/
|
|
85
|
+
│ ├── primary/create_user_usecase.py
|
|
86
|
+
│ └── secondary/user_repository_port.py
|
|
87
|
+
└── adapters/
|
|
88
|
+
├── primary/fastapi_router.py
|
|
89
|
+
└── secondary/asyncpg_repository.py
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
### TypeScript Scaffold (`package.json` / `pnpm`)
|
|
93
|
+
```
|
|
94
|
+
src/
|
|
95
|
+
├── domain/
|
|
96
|
+
│ ├── entities/user.ts
|
|
97
|
+
│ └── value-objects/tenant-id.ts
|
|
98
|
+
├── ports/
|
|
99
|
+
│ ├── primary/create-user.usecase.ts
|
|
100
|
+
│ └── secondary/user-repository.port.ts
|
|
101
|
+
└── adapters/
|
|
102
|
+
├── primary/fastify-router.ts
|
|
103
|
+
└── secondary/kysely-user-repository.ts
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## 3. Foundational Scaffold Invariants
|
|
109
|
+
|
|
110
|
+
1. **Domain Isolation**: Code in `src/domain/` must have **zero imports** from `src/adapters/`, external web frameworks, or database drivers.
|
|
111
|
+
2. **Ports as Pure Contracts**: Code in `src/ports/` contains abstract interfaces, Command DTOs, Query DTOs, and Result containers.
|
|
112
|
+
3. **Adapters Depend on Ports**: `src/adapters/` implements ports defined in `src/ports/`. Adapters never depend directly on other adapters.
|
|
113
|
+
4. **Contract-First Synchronization**: Whenever an API or event interface changes, the canonical contract in `specs/` must be updated and validated before adapter code is generated or modified.
|