azcodr 1.4.0 → 1.5.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 +2 -2
- package/.agents/scripts/safety_guard.sh +16 -0
- package/.agents/scripts/verify_completion.sh +13 -0
- package/.agents/skills/agentic-architect/SKILL.md +1 -1
- package/.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh +33 -2
- package/.agents/skills/lets-build/SKILL.md +11 -4
- package/.agents/skills/lets-build/references/architecture_interview_matrix.md +8 -2
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +52 -5
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +118 -1
- package/.agents/skills/product-analyst/SKILL.md +13 -2
- package/.agents/skills/relentless-questioner/SKILL.md +3 -0
- package/.agents/skills/relentless-questioner/references/adaptive_question_trees.md +18 -0
- package/.gitignore +2 -0
- package/AGENTS.md +1 -1
- package/bin/azcodr.js +9 -4
- package/docs/rules/agentic_configuration.md +3 -0
- package/docs/rules/relentless_questioning.md +4 -0
- package/docs/rules/test_driven_development.md +1 -0
- package/lib/scaffold.js +108 -5
- package/memory.md +12 -265
- package/package.json +1 -1
|
@@ -7,7 +7,7 @@
|
|
|
7
7
|
"hooks": [
|
|
8
8
|
{
|
|
9
9
|
"type": "command",
|
|
10
|
-
"command": "
|
|
10
|
+
"command": "./.agents/scripts/safety_guard.sh",
|
|
11
11
|
"timeout": 15
|
|
12
12
|
}
|
|
13
13
|
]
|
|
@@ -34,7 +34,7 @@
|
|
|
34
34
|
"Stop": [
|
|
35
35
|
{
|
|
36
36
|
"type": "command",
|
|
37
|
-
"command": "
|
|
37
|
+
"command": "./.agents/scripts/verify_completion.sh",
|
|
38
38
|
"timeout": 15
|
|
39
39
|
}
|
|
40
40
|
]
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# ==============================================================================
|
|
3
|
+
# safety_guard.sh
|
|
4
|
+
# Example PreToolUse hook for agent commands
|
|
5
|
+
# ==============================================================================
|
|
6
|
+
set -euo pipefail
|
|
7
|
+
|
|
8
|
+
COMMAND="${1:-}"
|
|
9
|
+
|
|
10
|
+
# Reject destructive system commands targeting root or home
|
|
11
|
+
if [[ "${COMMAND}" =~ (rm[[:space:]]+-[rf]{1,2}[[:space:]]+(/|\$HOME|~)) ]]; then
|
|
12
|
+
echo "🚨 Safety Guard: Destructive command rejected: ${COMMAND}" >&2
|
|
13
|
+
exit 1
|
|
14
|
+
fi
|
|
15
|
+
|
|
16
|
+
exit 0
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# ==============================================================================
|
|
3
|
+
# verify_completion.sh
|
|
4
|
+
# Example Stop hook ensuring tests and validation pass before agent exit
|
|
5
|
+
# ==============================================================================
|
|
6
|
+
set -euo pipefail
|
|
7
|
+
|
|
8
|
+
# Run project validation script if configured in package.json
|
|
9
|
+
if [[ -f "package.json" ]] && grep -q '"validate"' "package.json"; then
|
|
10
|
+
npm run validate
|
|
11
|
+
fi
|
|
12
|
+
|
|
13
|
+
exit 0
|
|
@@ -27,7 +27,7 @@ Before writing a single line of a skill or rule, execute the **7 Core Inquiry Br
|
|
|
27
27
|
3. **Domain Ground Truth:** Have all generic textbook tutorials been purged? Is this grounded in verified codebase evidence?
|
|
28
28
|
4. **Gotchas & Anti-Patterns:** What exact mistakes has the AI repeatedly made in this domain that must be forbidden?
|
|
29
29
|
5. **Determinism vs. LLM:** Can brittle tasks be converted into deterministic scripts under `scripts/`?
|
|
30
|
-
6. **Progressive Bloat:** Is `SKILL.md` strictly under 500 lines, offloading deep manuals to `references/` and templates to `
|
|
30
|
+
6. **Progressive Bloat:** Is `SKILL.md` strictly under 500 lines, offloading deep manuals to `references/` and templates to `resources/`?
|
|
31
31
|
7. **Verification & Proof:** What structured response template and self-validation checklist will prove success?
|
|
32
32
|
*Rule:* If any branch is unanswered or ambiguous, **STOP and ask the user** (or inspect workspace files). Never fill gaps with assumptions.
|
|
33
33
|
|
|
@@ -6,7 +6,21 @@
|
|
|
6
6
|
|
|
7
7
|
set -euo pipefail
|
|
8
8
|
|
|
9
|
-
WORKSPACE_ROOT="
|
|
9
|
+
WORKSPACE_ROOT=""
|
|
10
|
+
FIX_MODE=false
|
|
11
|
+
|
|
12
|
+
for arg in "$@"; do
|
|
13
|
+
if [[ "${arg}" == "--fix" ]]; then
|
|
14
|
+
FIX_MODE=true
|
|
15
|
+
elif [[ -z "${WORKSPACE_ROOT}" ]]; then
|
|
16
|
+
WORKSPACE_ROOT="${arg}"
|
|
17
|
+
fi
|
|
18
|
+
done
|
|
19
|
+
|
|
20
|
+
if [[ -z "${WORKSPACE_ROOT}" ]]; then
|
|
21
|
+
WORKSPACE_ROOT="$(pwd)"
|
|
22
|
+
fi
|
|
23
|
+
|
|
10
24
|
ERRORS=0
|
|
11
25
|
WARNINGS=0
|
|
12
26
|
|
|
@@ -77,7 +91,12 @@ if [[ "${IS_CASE_INSENSITIVE}" == "true" ]]; then
|
|
|
77
91
|
log_pass "agents.md is satisfied natively by AGENTS.md (case-insensitive filesystem)."
|
|
78
92
|
else
|
|
79
93
|
if [[ ! -L "${AGENTS_LOWER}" ]] && [[ ! -e "${AGENTS_LOWER}" ]] && [[ -f "${AGENTS_FILE}" ]]; then
|
|
80
|
-
|
|
94
|
+
if [[ "${FIX_MODE}" == "true" ]]; then
|
|
95
|
+
ln -sf "AGENTS.md" "${AGENTS_LOWER}"
|
|
96
|
+
log_pass "Created agents.md symlink to AGENTS.md (--fix mode)."
|
|
97
|
+
else
|
|
98
|
+
log_fail "agents.md is missing. Run with --fix to automatically repair symlinks."
|
|
99
|
+
fi
|
|
81
100
|
fi
|
|
82
101
|
if [[ -L "${AGENTS_LOWER}" ]]; then
|
|
83
102
|
TARGET=$(readlink "${AGENTS_LOWER}")
|
|
@@ -86,6 +105,10 @@ else
|
|
|
86
105
|
else
|
|
87
106
|
log_fail "agents.md points to '${TARGET}' instead of 'AGENTS.md'."
|
|
88
107
|
fi
|
|
108
|
+
elif [[ -f "${AGENTS_LOWER}" ]] && is_valid_text_pointer "${AGENTS_LOWER}"; then
|
|
109
|
+
log_pass "agents.md is a text pointer to AGENTS.md (symlink fallback)."
|
|
110
|
+
elif [[ ! -e "${AGENTS_LOWER}" ]] && [[ "${FIX_MODE}" == "true" ]]; then
|
|
111
|
+
: # Handled above
|
|
89
112
|
else
|
|
90
113
|
log_fail "agents.md is not a symbolic link."
|
|
91
114
|
fi
|
|
@@ -153,6 +176,14 @@ if [[ -d "${WORKSPACE_ROOT}/.github" ]]; then
|
|
|
153
176
|
fi
|
|
154
177
|
fi
|
|
155
178
|
|
|
179
|
+
# Check .gitignore exists
|
|
180
|
+
GITIGNORE_FILE="${WORKSPACE_ROOT}/.gitignore"
|
|
181
|
+
if [[ -f "${GITIGNORE_FILE}" ]]; then
|
|
182
|
+
log_pass ".gitignore exists."
|
|
183
|
+
else
|
|
184
|
+
log_fail "Missing .gitignore at ${GITIGNORE_FILE}"
|
|
185
|
+
fi
|
|
186
|
+
|
|
156
187
|
# 2. Checking Progressive Disclosure Rules (docs/rules)
|
|
157
188
|
echo ""
|
|
158
189
|
echo "2. Checking Progressive Disclosure Rules..."
|
|
@@ -45,7 +45,7 @@ Do NOT guess or assume any technology or stack choice. Execute the relentless in
|
|
|
45
45
|
#### Batch 1: Problem Space & System Topology
|
|
46
46
|
1. **Domain & Problem Statement:** What real-world problem or capability does this system solve? What data moves, and what transformations occur?
|
|
47
47
|
2. **System Topology Classification:** Which topology best matches the execution target?
|
|
48
|
-
- Topology A: Web SaaS / Cloud
|
|
48
|
+
- Topology A: Web SaaS / Cloud Applications (Fullstack Web App vs Headless API)
|
|
49
49
|
- Topology B: Browser Extension (Manifest V3)
|
|
50
50
|
- Topology C: Game Engine / High-Performance Simulator (Bare metal, GPU)
|
|
51
51
|
- Topology D: Browser / Canvas Game (HTML5 Canvas / WebGL / WebGPU)
|
|
@@ -70,7 +70,10 @@ Do NOT guess or assume any technology or stack choice. Execute the relentless in
|
|
|
70
70
|
|
|
71
71
|
#### Batch 4: Targeted Invariants (Topology-Scoped, 100% YAGNI)
|
|
72
72
|
Inquire *only* into the dimensions relevant to the selected topology:
|
|
73
|
-
- *If Web SaaS /
|
|
73
|
+
- *If Web SaaS / Cloud Application:*
|
|
74
|
+
- **Interface Scope:** Headless API service only vs Fullstack Web Application (API + Web Frontend).
|
|
75
|
+
- **If Fullstack Web Application:** Frontend framework & build tool (React + Vite, Vue 3, Svelte 5), styling & accessible headless component primitives (Tailwind CSS, Radix UI / shadcn/ui per [`frontend_architecture.md`](../../../docs/rules/frontend_architecture.md)), client directory structure (`client/` + `src/` backend), and persistent app shell layout per [`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md).
|
|
76
|
+
- **Backend & Data:** API protocol (REST/OpenAPI 3.1 vs gRPC), DB migration engine (Atlas/Flyway), tenancy isolation model, authentication, and OCI distroless containers.
|
|
74
77
|
- *If Browser Extension:* MV3 content script isolation (IIFE bundle), `chrome.storage.sync` flow, permissions. (Zero Docker/K8s/OpenAPI!).
|
|
75
78
|
- *If Game Engine:* Graphics backend (Vulkan/DirectX/wgpu), memory allocators (arena/frame), ECS archetype model. (Zero Docker/SQL!).
|
|
76
79
|
- *If CLI:* Arg parsing library, POSIX exit codes, streaming I/O, `--json` formatting. (Zero Docker/SQL!).
|
|
@@ -79,7 +82,7 @@ Inquire *only* into the dimensions relevant to the selected topology:
|
|
|
79
82
|
|
|
80
83
|
### Phase 3: Synthesize (Architecture Blueprint & User Sign-Off)
|
|
81
84
|
1. Consolidate the user's answers into a formal **Consolidated Architectural Blueprint** (using Section 4 template).
|
|
82
|
-
2. Author
|
|
85
|
+
2. Author the project's foundational Architectural Decision Record in `memory.md`, strictly starting with **`ADR-001: Target Technology Stack & Scaffolding Baseline`**. For a freshly initialized or bootstrapped project, `memory.md` must be a clean slate (zero prior decisions). If `memory.md` contains any legacy template ADRs from `azcodr`, sanitize and reset them so the new project starts from `ADR-001`.
|
|
83
86
|
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.
|
|
84
87
|
|
|
85
88
|
---
|
|
@@ -91,7 +94,8 @@ Upon user confirmation:
|
|
|
91
94
|
bash .agents/skills/lets-build/scripts/bootstrap_workspace.sh . <topology> <language>
|
|
92
95
|
```
|
|
93
96
|
2. Generate base infrastructure strictly for the selected topology (zero speculative bloat) using layouts from [references/hexagonal_bootstrap_scaffolds.md](./references/hexagonal_bootstrap_scaffolds.md):
|
|
94
|
-
- *
|
|
97
|
+
- *Fullstack Web SaaS:* Backend in `src/`, Web Client in `client/` (`client/src/components/layout`, `client/src/components/ui`, `client/src/pages`, `client/src/hooks`, `client/src/services`), `specs/openapi/v1/openapi.yaml`, `specs/tokens/tokens.json`, `deploy/docker`, `deploy/compose`.
|
|
98
|
+
- *Headless Backend:* `src/domain/`, `src/ports/`, `src/adapters/`, `specs/openapi/v1/openapi.yaml`, `specs/tokens/tokens.json`, `deploy/docker`, `deploy/compose`.
|
|
95
99
|
- *Extension:* `manifest.json`, `src/background/index.ts`, `src/content/index.ts`, `src/popup/index.html`.
|
|
96
100
|
- *Game / Engine:* `src/core/`, `src/ecs/`, asset manifest, frame loop entrypoint.
|
|
97
101
|
- *CLI:* `src/cmd/`, `src/core/`, CLI entrypoint with exit code handling.
|
|
@@ -113,11 +117,14 @@ Upon user confirmation:
|
|
|
113
117
|
- **`lets-build` IS NOW COMPLETE.** Do NOT proceed to write domain business entities, repositories, or application features.
|
|
114
118
|
- Present the bootstrapped technical skeleton to the user.
|
|
115
119
|
- 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.
|
|
120
|
+
- For applications with a user interface (Fullstack Web SaaS, Extensions, Desktop), the handover must explicitly instruct the user and agent to execute the **7-Pillar Design Architecture Triage Gate** ([`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md)) to define user personas, persistent app shell navigation, and user journeys.
|
|
116
121
|
|
|
117
122
|
---
|
|
118
123
|
|
|
119
124
|
## 3. Gotchas & What NOT to Do
|
|
120
125
|
|
|
126
|
+
- **MAJOR DONT: NEVER carry over template-internal ADRs from azcodr into a new project.** When scaffolding or bootstrapping a new project, `memory.md` must be a clean slate and start at `ADR-001`. Do NOT number the first architecture decision as ADR-025 or ADR-028 based on azcodr's template development history.
|
|
127
|
+
- **MAJOR DONT: NEVER silently drop the frontend or treat Fullstack Web SaaS as a headless backend API!** If the user selects a Fullstack Web application with a UI, you MUST scaffold both the client (`client/`) and backend (`src/`) baselines, configure build manifests for both, execute the 7-Pillar Design Architecture Triage Gate, and ensure user stories slice vertically across both UI and API layers.
|
|
121
128
|
- **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
129
|
- **DO NOT** assume the stack. Never start writing Go, Rust, Python, or TypeScript before asking the user.
|
|
123
130
|
- **DO NOT** scaffold universal web boilerplate (Docker, Kubernetes, OpenAPI, Postgres migrations) for non-backend projects (Browser Extensions, CLIs, Game Engines, Desktop apps).
|
|
@@ -16,7 +16,7 @@
|
|
|
16
16
|
|
|
17
17
|
### Dimension 2: System Topology Classification
|
|
18
18
|
Classify the system into its primary operational topology:
|
|
19
|
-
1. **Topology A — Web SaaS / Cloud
|
|
19
|
+
1. **Topology A — Web SaaS / Cloud Applications:** Network-facing systems with multi-tenant data persistence, ranging from Fullstack Web Applications (API Backend + Web Frontend) to Headless Microservices (API-only).
|
|
20
20
|
2. **Topology B — Browser Extension:** Client-side sandboxed extension (Chrome/Firefox MV3) orchestrating content scripts, background service workers, and popup UI.
|
|
21
21
|
3. **Topology C — Game Engine / High-Performance Simulator:** Low-level, frame-budgeted application directly interfacing with GPU APIs (Vulkan, DirectX, Metal) and system memory.
|
|
22
22
|
4. **Topology D — Browser / Canvas Game:** Sandboxed web game running inside the browser DOM/Canvas via Canvas2D, WebGL, or WebGPU.
|
|
@@ -86,7 +86,13 @@ Derive the programming language, runtime, and package manager strictly from the
|
|
|
86
86
|
|
|
87
87
|
Inquire *only* into the dimensions relevant to the selected topology. **Never ask non-backend projects about databases, containers, or API versioning!**
|
|
88
88
|
|
|
89
|
-
### For Web SaaS & Enterprise
|
|
89
|
+
### For Web SaaS & Enterprise Cloud Applications ONLY:
|
|
90
|
+
- **Application Interface Scope:** Headless API service (no UI) vs Fullstack Web Application (API Backend + Web Frontend Client).
|
|
91
|
+
- **Frontend UI Stack (If Fullstack Web Application):**
|
|
92
|
+
- **Framework & Runtime:** React + Vite, Vue 3, Svelte 5, Next.js.
|
|
93
|
+
- **Component Primitives & Styling:** Tailwind CSS + Accessible Headless Primitives (Radix UI / shadcn/ui) per [docs/rules/frontend_architecture.md](../../../../docs/rules/frontend_architecture.md).
|
|
94
|
+
- **Client Structure:** Paired Client (`client/` + `src/` backend) vs Monorepo (`apps/web` + `apps/api`).
|
|
95
|
+
- **Design Triage & App Shell:** Persistent App Shell (collapsible sidebar, global header) vs Dynamic Canvas per [docs/rules/ui_ux_architecture.md](../../../../docs/rules/ui_ux_architecture.md).
|
|
90
96
|
- **API Protocols:** REST (OpenAPI 3.1) vs gRPC (Protobuf v3 via Buf) vs GraphQL.
|
|
91
97
|
- **Database Migrations:** Declarative (Atlas) vs Versioned SQL (Flyway, Goose).
|
|
92
98
|
- **Multi-Tenancy Isolation:** AST Query Interceptor vs Database RLS vs Schema-per-tenant.
|
|
@@ -6,8 +6,9 @@
|
|
|
6
6
|
|
|
7
7
|
## 1. Universal Directory Topology
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Depending on whether the project target is a **Fullstack Web SaaS** (Frontend + Backend) or a **Headless Service** (API only), projects follow these standard layouts:
|
|
10
10
|
|
|
11
|
+
### Fullstack Web SaaS Topology (Web Frontend + Hexagonal Backend)
|
|
11
12
|
```
|
|
12
13
|
<project-root>/
|
|
13
14
|
├── .agents/skills/ # Specialized agentic workflows (carried from azcodr template)
|
|
@@ -15,11 +16,19 @@ Regardless of language, all bootstrapped projects must follow this high-level se
|
|
|
15
16
|
│ ├── knowledge/ # Domain knowledge & living ubiquitous language glossary
|
|
16
17
|
│ └── rules/ # 28 cohesive single-responsibility domain rules
|
|
17
18
|
├── specs/ # Canonical contract specifications
|
|
18
|
-
│ ├── protobuf/ # gRPC service definitions (*.proto)
|
|
19
19
|
│ ├── openapi/ # OpenAPI 3.1 REST specifications (*.yaml)
|
|
20
20
|
│ ├── schemas/ # Universal JSON Schema Draft 2020-12 (*.json)
|
|
21
21
|
│ └── tokens/ # W3C DTCG Design Tokens (tokens.json)
|
|
22
|
-
├──
|
|
22
|
+
├── client/ # Web Frontend Application (Vite + React / SPA)
|
|
23
|
+
│ ├── src/
|
|
24
|
+
│ │ ├── components/
|
|
25
|
+
│ │ │ ├── layout/ # Persistent Shell (Sidebar, Header, Breadcrumbs)
|
|
26
|
+
│ │ │ └── ui/ # Accessible Headless Primitives (Radix / shadcn)
|
|
27
|
+
│ │ ├── pages/ # Dynamic Canvas Route Views
|
|
28
|
+
│ │ ├── hooks/ # Server-State Cache & URL State Synchronization
|
|
29
|
+
│ │ └── services/ # Inbound API Client Adapters
|
|
30
|
+
│ └── public/ # Static web assets
|
|
31
|
+
├── src/ # Backend Application (Hexagonal Architecture)
|
|
23
32
|
│ ├── domain/ # Core Invariant Domain (Entities, Value Objects, Invariants)
|
|
24
33
|
│ ├── ports/ # Primary (driving) and Secondary (driven) Ports
|
|
25
34
|
│ │ ├── primary/ # Inbound Use Cases, Commands, and Queries
|
|
@@ -31,6 +40,7 @@ Regardless of language, all bootstrapped projects must follow this high-level se
|
|
|
31
40
|
│ ├── unit/ # Fast unit tests using test doubles
|
|
32
41
|
│ ├── integration/ # Adapter integration tests with transactional rollback
|
|
33
42
|
│ ├── contracts/ # Pact / OpenAPI contract verification
|
|
43
|
+
│ ├── client/ # Frontend component and interaction tests
|
|
34
44
|
│ └── acceptance/ # BDD Gherkin / Cucumber end-to-end features
|
|
35
45
|
├── deploy/ # Deployment & Infrastructure as Code
|
|
36
46
|
│ ├── docker/ # Minimal OCI Distroless/Scratch Dockerfiles
|
|
@@ -43,10 +53,46 @@ Regardless of language, all bootstrapped projects must follow this high-level se
|
|
|
43
53
|
└── README.md # Project documentation
|
|
44
54
|
```
|
|
45
55
|
|
|
56
|
+
### Headless Service Topology (Backend API Only)
|
|
57
|
+
```
|
|
58
|
+
<project-root>/
|
|
59
|
+
├── .agents/skills/ # Specialized agentic workflows
|
|
60
|
+
├── docs/ # Domain knowledge & 28 domain rules
|
|
61
|
+
├── specs/ # OpenAPI 3.1 & Schema contracts
|
|
62
|
+
├── src/ # Domain, Ports, Adapters
|
|
63
|
+
├── tests/ # Unit, Integration, Contracts, Acceptance
|
|
64
|
+
├── deploy/ # Docker, Compose
|
|
65
|
+
├── AGENTS.md
|
|
66
|
+
└── memory.md
|
|
67
|
+
```
|
|
68
|
+
|
|
46
69
|
---
|
|
47
70
|
|
|
48
71
|
## 2. Language-Specific Source Layouts
|
|
49
72
|
|
|
73
|
+
### TypeScript Fullstack Scaffold (`client/` + `src/` via `package.json` / `pnpm`)
|
|
74
|
+
```
|
|
75
|
+
client/ # Web Frontend (Vite + React / Vue / Svelte)
|
|
76
|
+
├── src/
|
|
77
|
+
│ ├── components/
|
|
78
|
+
│ │ ├── layout/ # Persistent App Shell (Header, Collapsible Sidebar)
|
|
79
|
+
│ │ └── ui/ # Accessible Headless Primitives (Radix / shadcn)
|
|
80
|
+
│ ├── pages/ # Dynamic Canvas Route Views
|
|
81
|
+
│ ├── hooks/ # Server-State Cache & URL State Synchronization
|
|
82
|
+
│ └── services/ # Inbound API Client Adapters
|
|
83
|
+
└── public/
|
|
84
|
+
src/ # Core Backend (Hexagonal Ports & Adapters)
|
|
85
|
+
├── domain/
|
|
86
|
+
│ ├── entities/user.ts
|
|
87
|
+
│ └── value-objects/tenant-id.ts
|
|
88
|
+
├── ports/
|
|
89
|
+
│ ├── primary/create-user.usecase.ts
|
|
90
|
+
│ └── secondary/user-repository.port.ts
|
|
91
|
+
└── adapters/
|
|
92
|
+
├── primary/fastify-router.ts
|
|
93
|
+
└── secondary/kysely-user-repository.ts
|
|
94
|
+
```
|
|
95
|
+
|
|
50
96
|
### Go Scaffold (`go.mod`)
|
|
51
97
|
```
|
|
52
98
|
src/
|
|
@@ -89,7 +135,7 @@ src/
|
|
|
89
135
|
└── secondary/asyncpg_repository.py
|
|
90
136
|
```
|
|
91
137
|
|
|
92
|
-
### TypeScript Scaffold (`package.json` / `pnpm`)
|
|
138
|
+
### TypeScript Backend-Only Scaffold (`package.json` / `pnpm`)
|
|
93
139
|
```
|
|
94
140
|
src/
|
|
95
141
|
├── domain/
|
|
@@ -107,7 +153,8 @@ src/
|
|
|
107
153
|
|
|
108
154
|
## 3. Foundational Scaffold Invariants
|
|
109
155
|
|
|
110
|
-
1. **Domain Isolation**: Code in `src/domain/` must have **zero imports** from `src/adapters/`, external web frameworks, or database drivers.
|
|
156
|
+
1. **Domain Isolation**: Code in `src/domain/` must have **zero imports** from `src/adapters/`, `client/`, external web frameworks, or database drivers.
|
|
111
157
|
2. **Ports as Pure Contracts**: Code in `src/ports/` contains abstract interfaces, Command DTOs, Query DTOs, and Result containers.
|
|
112
158
|
3. **Adapters Depend on Ports**: `src/adapters/` implements ports defined in `src/ports/`. Adapters never depend directly on other adapters.
|
|
113
159
|
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.
|
|
160
|
+
5. **Frontend Decoupling via Contract**: The frontend in `client/` consumes backend driving ports strictly via canonical OpenAPI contracts (`specs/openapi`) and W3C Design Tokens (`specs/tokens/tokens.json`). It follows the 7-Pillar Design Architecture Triage Gate ([docs/rules/ui_ux_architecture.md](../../../../docs/rules/ui_ux_architecture.md)) and accessible headless primitives ([docs/rules/frontend_architecture.md](../../../../docs/rules/frontend_architecture.md)).
|
|
@@ -61,7 +61,7 @@ case "${TOPOLOGY}" in
|
|
|
61
61
|
create_leaf "${WORKSPACE_ROOT}/tests/integration"
|
|
62
62
|
;;
|
|
63
63
|
|
|
64
|
-
|
|
64
|
+
web|saas|fullstack)
|
|
65
65
|
echo "1. Scaffolding Backend / Enterprise Source Tree (src/)..."
|
|
66
66
|
create_leaf "${WORKSPACE_ROOT}/src/domain/entities"
|
|
67
67
|
create_leaf "${WORKSPACE_ROOT}/src/domain/value_objects"
|
|
@@ -70,6 +70,60 @@ case "${TOPOLOGY}" in
|
|
|
70
70
|
create_leaf "${WORKSPACE_ROOT}/src/ports/secondary"
|
|
71
71
|
create_leaf "${WORKSPACE_ROOT}/src/adapters/primary"
|
|
72
72
|
create_leaf "${WORKSPACE_ROOT}/src/adapters/secondary"
|
|
73
|
+
|
|
74
|
+
echo "2. Scaffolding Web Frontend Client Source Tree (client/)..."
|
|
75
|
+
create_leaf "${WORKSPACE_ROOT}/client/src/components/layout"
|
|
76
|
+
create_leaf "${WORKSPACE_ROOT}/client/src/components/ui"
|
|
77
|
+
create_leaf "${WORKSPACE_ROOT}/client/src/pages"
|
|
78
|
+
create_leaf "${WORKSPACE_ROOT}/client/src/hooks"
|
|
79
|
+
create_leaf "${WORKSPACE_ROOT}/client/src/services"
|
|
80
|
+
create_leaf "${WORKSPACE_ROOT}/client/public"
|
|
81
|
+
|
|
82
|
+
echo "3. Scaffolding Specifications (specs/)..."
|
|
83
|
+
create_leaf "${WORKSPACE_ROOT}/specs/openapi"
|
|
84
|
+
create_leaf "${WORKSPACE_ROOT}/specs/tokens"
|
|
85
|
+
|
|
86
|
+
echo "4. Scaffolding Fullstack Test Suites (tests/)..."
|
|
87
|
+
create_leaf "${WORKSPACE_ROOT}/tests/unit"
|
|
88
|
+
create_leaf "${WORKSPACE_ROOT}/tests/integration"
|
|
89
|
+
create_leaf "${WORKSPACE_ROOT}/tests/contracts"
|
|
90
|
+
create_leaf "${WORKSPACE_ROOT}/tests/client"
|
|
91
|
+
create_leaf "${WORKSPACE_ROOT}/tests/acceptance"
|
|
92
|
+
|
|
93
|
+
echo "5. Scaffolding Deployment Infrastructure (deploy/)..."
|
|
94
|
+
create_leaf "${WORKSPACE_ROOT}/deploy/docker"
|
|
95
|
+
create_leaf "${WORKSPACE_ROOT}/deploy/compose"
|
|
96
|
+
|
|
97
|
+
TOKEN_SPEC="${WORKSPACE_ROOT}/specs/tokens/tokens.json"
|
|
98
|
+
if [[ ! -f "${TOKEN_SPEC}" ]]; then
|
|
99
|
+
cat << 'EOF' > "${TOKEN_SPEC}"
|
|
100
|
+
{
|
|
101
|
+
"color": {
|
|
102
|
+
"brand": {
|
|
103
|
+
"primary": { "$value": "#2563eb", "$type": "color" },
|
|
104
|
+
"secondary": { "$value": "#475569", "$type": "color" },
|
|
105
|
+
"accent": { "$value": "#f59e0b", "$type": "color" }
|
|
106
|
+
}
|
|
107
|
+
},
|
|
108
|
+
"dimension": {
|
|
109
|
+
"radius": {
|
|
110
|
+
"base": { "$value": "6px", "$type": "dimension" }
|
|
111
|
+
}
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
EOF
|
|
115
|
+
fi
|
|
116
|
+
;;
|
|
117
|
+
|
|
118
|
+
backend)
|
|
119
|
+
echo "1. Scaffolding Headless Backend Source Tree (src/)..."
|
|
120
|
+
create_leaf "${WORKSPACE_ROOT}/src/domain/entities"
|
|
121
|
+
create_leaf "${WORKSPACE_ROOT}/src/domain/value_objects"
|
|
122
|
+
create_leaf "${WORKSPACE_ROOT}/src/domain/services"
|
|
123
|
+
create_leaf "${WORKSPACE_ROOT}/src/ports/primary"
|
|
124
|
+
create_leaf "${WORKSPACE_ROOT}/src/ports/secondary"
|
|
125
|
+
create_leaf "${WORKSPACE_ROOT}/src/adapters/primary"
|
|
126
|
+
create_leaf "${WORKSPACE_ROOT}/src/adapters/secondary"
|
|
73
127
|
|
|
74
128
|
echo "2. Scaffolding Specifications (specs/)..."
|
|
75
129
|
create_leaf "${WORKSPACE_ROOT}/specs/openapi"
|
|
@@ -106,6 +160,23 @@ EOF
|
|
|
106
160
|
fi
|
|
107
161
|
;;
|
|
108
162
|
|
|
163
|
+
frontend)
|
|
164
|
+
echo "1. Scaffolding Frontend Client Source Tree (src/)..."
|
|
165
|
+
create_leaf "${WORKSPACE_ROOT}/src/components/layout"
|
|
166
|
+
create_leaf "${WORKSPACE_ROOT}/src/components/ui"
|
|
167
|
+
create_leaf "${WORKSPACE_ROOT}/src/pages"
|
|
168
|
+
create_leaf "${WORKSPACE_ROOT}/src/hooks"
|
|
169
|
+
create_leaf "${WORKSPACE_ROOT}/src/services"
|
|
170
|
+
create_leaf "${WORKSPACE_ROOT}/public"
|
|
171
|
+
|
|
172
|
+
echo "2. Scaffolding Specifications (specs/)..."
|
|
173
|
+
create_leaf "${WORKSPACE_ROOT}/specs/tokens"
|
|
174
|
+
|
|
175
|
+
echo "3. Scaffolding Frontend Test Suites (tests/)..."
|
|
176
|
+
create_leaf "${WORKSPACE_ROOT}/tests/unit"
|
|
177
|
+
create_leaf "${WORKSPACE_ROOT}/tests/acceptance"
|
|
178
|
+
;;
|
|
179
|
+
|
|
109
180
|
*)
|
|
110
181
|
echo "1. Scaffolding Generic / Library Source Tree (src/)..."
|
|
111
182
|
create_leaf "${WORKSPACE_ROOT}/src"
|
|
@@ -113,6 +184,52 @@ EOF
|
|
|
113
184
|
;;
|
|
114
185
|
esac
|
|
115
186
|
|
|
187
|
+
# Ensure memory.md in fresh projects starts with a clean ADR slate (ADR-001)
|
|
188
|
+
MEMORY_FILE="${WORKSPACE_ROOT}/memory.md"
|
|
189
|
+
if [[ -f "${MEMORY_FILE}" ]]; then
|
|
190
|
+
if grep -qE "ADR-00[2-9]|ADR-0[1-9][0-9]" "${MEMORY_FILE}"; then
|
|
191
|
+
echo "🧹 Sanitizing memory.md: Resetting legacy template ADRs to clean slate (ADR-001)..."
|
|
192
|
+
cat << 'EOF' > "${MEMORY_FILE}"
|
|
193
|
+
# Workspace Memory, Architecture Decisions & Knowledge Hub
|
|
194
|
+
|
|
195
|
+
> **Core Purpose:** Authoritative persistent memory ledger for the workspace repository (`./`), maintaining Lightweight Architectural Decision Records (ADRs), system topologies, and living domain contracts.
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
## 1. Quick Navigation & Knowledge Repositories
|
|
200
|
+
|
|
201
|
+
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative, single-name domain vocabulary contract.
|
|
202
|
+
- 📜 **[Lightweight ADR Master Index](#adr-master-index)**: Summary of all architectural decisions and direct links to governing rules.
|
|
203
|
+
|
|
204
|
+
---
|
|
205
|
+
|
|
206
|
+
## 2. Consolidated Architectural Decision Records (ADRs)
|
|
207
|
+
|
|
208
|
+
### ADR Master Index
|
|
209
|
+
|
|
210
|
+
| ID | Title | Date | Status | Governing Rule / Skill |
|
|
211
|
+
|---|---|---|---|---|
|
|
212
|
+
| *(No decisions recorded yet)* | *Record initial architecture decisions during Phase 3 of /lets-build.* | *YYYY-MM-DD* | *ACCEPTED* | *e.g. [`clean_code.md`](./docs/rules/clean_code.md)* |
|
|
213
|
+
|
|
214
|
+
---
|
|
215
|
+
|
|
216
|
+
### Lightweight Decision Summaries
|
|
217
|
+
|
|
218
|
+
<!--
|
|
219
|
+
Record project Architectural Decision Records (ADRs) below as decisions are finalized.
|
|
220
|
+
Format:
|
|
221
|
+
|
|
222
|
+
#### ADR-001: [Imperative Title]
|
|
223
|
+
- **Date:** YYYY-MM-DD | **Status:** ACCEPTED
|
|
224
|
+
- **Context:** Problem space, constraints, and operational context requiring a decision.
|
|
225
|
+
- **Decision:** Chosen architecture, invariants, and implementation patterns.
|
|
226
|
+
- **Consequences:** Positive benefits and deliberate trade-offs accepted.
|
|
227
|
+
- **Enforced In:** Relevant rule files in docs/rules/ or code paths.
|
|
228
|
+
-->
|
|
229
|
+
EOF
|
|
230
|
+
fi
|
|
231
|
+
fi
|
|
232
|
+
|
|
116
233
|
# Deterministically generate boundary verification smoke test script (Phase 5 requirement)
|
|
117
234
|
SMOKE_TEST="${WORKSPACE_ROOT}/scripts/smoke_test.sh"
|
|
118
235
|
if [[ ! -f "${SMOKE_TEST}" ]]; then
|
|
@@ -53,7 +53,17 @@ Ensure every user story conforms to Bill Wake's **INVEST** criteria:
|
|
|
53
53
|
- **Small:** Sized to be completable in 1–2 development days.
|
|
54
54
|
- **Testable:** Accompanied by executable, unambiguous Gherkin acceptance criteria.
|
|
55
55
|
|
|
56
|
-
**The Multi-Layer Cake Rule
|
|
56
|
+
**The Multi-Layer Cake Rule & UI Integration:**
|
|
57
|
+
- **Never slice horizontally** (e.g. *"Create database schema only"* or *"Create backend API only"*). Always slice vertically through the full stack so that every story delivers working software.
|
|
58
|
+
- **Mandatory UI/UX Triage Gate for User-Facing Applications:** If the project has a frontend or user interface (Fullstack Web SaaS, Extension, Desktop), execute the **7-Pillar Design Architecture Triage Gate** ([`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md)) before finalizing stories:
|
|
59
|
+
1. *Role & Identity:* Define who the user is and their operational boundary.
|
|
60
|
+
2. *Information Architecture:* Define how the view fits into the Persistent App Shell vs Dynamic Canvas.
|
|
61
|
+
3. *Experience Duality:* Clarify whether the screen belongs to an Enterprise Operator Workspace or Consumer Portal.
|
|
62
|
+
4. *Navigation & Wayfinding:* Specify sidebar route, active tab, breadcrumbs, and command palette entries.
|
|
63
|
+
5. *State & URL Synchronization:* Specify query params (`?tab=`, `?q=`, `?page=`, `?modal=`).
|
|
64
|
+
6. *Access Control:* Specify route guards and permission checks.
|
|
65
|
+
7. *Accessibility & Feedback:* Specify accessible notifications, focus trapping, and zero native alerts.
|
|
66
|
+
- **Every user-facing story MUST specify:** (1) The UI view/component & user interaction, (2) The API Command/Query DTO, (3) The core domain invariant, and (4) The persistence change.
|
|
57
67
|
|
|
58
68
|
### Step 5: Decompose Stories into SMART Developer Tasks
|
|
59
69
|
For engineering execution, translate INVEST user stories into Bill Wake's **SMART** developer tasks:
|
|
@@ -71,7 +81,8 @@ Map all failure paths to HTTP status codes (`400`, `401`, `403`, `404`, `409`, `
|
|
|
71
81
|
## 3. Gotchas & What NOT to Do
|
|
72
82
|
|
|
73
83
|
- **DO NOT** confuse output (features shipped, story points burned) with outcome (value delivered, satisfaction gap closed).
|
|
74
|
-
- **DO NOT** write horizontal, technical user stories (e.g., *"As a developer, I want a database table"*).
|
|
84
|
+
- **DO NOT** write horizontal, technical user stories (e.g., *"As a developer, I want a database table"* or *"As an API, I want a REST endpoint"*).
|
|
85
|
+
- **DO NOT** author backend-only user stories or ignore the UI when analyzing a user-facing system. If the system has a web frontend or client interface, slicing must start with user interactions and views.
|
|
75
86
|
- **DO NOT** force technical constraints, security policies, or infrastructure upgrades into user story syntax. Treat them as non-story requirements or architectural spikes.
|
|
76
87
|
- **DO NOT** omit the Out-of-Scope ("Won't Have this time") section. Lack of negative boundaries causes runaway scope bloat.
|
|
77
88
|
- **DO NOT** allow developer tasks to be open-ended without a measurable time-box. If a task exceeds 4 hours, it must be split or paired.
|
|
@@ -37,6 +37,7 @@ Upon receiving a user task or feature prompt, classify the functional archetype
|
|
|
37
37
|
- **Archetype C: Asynchronous & Event Streaming** (background jobs, webhooks, queues, pub/sub)
|
|
38
38
|
- **Archetype D: 3rd-Party & External Integrations** (external APIs, payment gateways, mailers)
|
|
39
39
|
- **Archetype E: Read Performance & Search** (dashboards, aggregations, high-scale read traffic)
|
|
40
|
+
- **Archetype F: User Interface, Experience Duality & Interaction Flows** (personas, app shell, screen journeys, URL synchronization, WCAG accessibility per [`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md) and [`frontend_architecture.md`](../../../docs/rules/frontend_architecture.md))
|
|
40
41
|
|
|
41
42
|
---
|
|
42
43
|
|
|
@@ -62,6 +63,8 @@ Check the user's proposed answers against the **28 Cohesive Domain Rules** in `d
|
|
|
62
63
|
- If the user proposes writing to the database and publishing an event sequentially ➔ **Flag the dual-write anti-pattern** and mandate the Transactional Outbox pattern ([`database_design.md`](../../../docs/rules/database_design.md)).
|
|
63
64
|
- If the user proposes storing tenant data without an isolation mechanism ➔ **Flag the tenant leak risk** and mandate an isolation model ([`multitenancy_architecture.md`](../../../docs/rules/multitenancy_architecture.md)).
|
|
64
65
|
- If the user proposes arbitrary untrusted script execution ➔ **Flag the host security vulnerability** and mandate Wasm sandboxing ([`multitenancy_architecture.md`](../../../docs/rules/multitenancy_architecture.md)).
|
|
66
|
+
- If the user proposes a fullstack feature but ignores user workflows or screens ➔ **Flag the Anemic Core anti-pattern** and mandate Outside-In interaction discovery ([`frontend_architecture.md`](../../../docs/rules/frontend_architecture.md)).
|
|
67
|
+
- If the user proposes ad-hoc modal alerts or unstructured page navigation ➔ **Flag UX debt** and enforce the 7-Pillar Design Architecture Triage Gate ([`ui_ux_architecture.md`](../../../docs/rules/ui_ux_architecture.md)).
|
|
65
68
|
- Reconcile the conflict collaboratively before proceeding.
|
|
66
69
|
|
|
67
70
|
---
|
|
@@ -70,6 +70,24 @@ flowchart TD
|
|
|
70
70
|
|
|
71
71
|
---
|
|
72
72
|
|
|
73
|
+
## Decision Tree 5: User Interface, Experience Duality & Interaction Flows
|
|
74
|
+
|
|
75
|
+
```mermaid
|
|
76
|
+
flowchart TD
|
|
77
|
+
Q1["Does the feature introduce or modify a user interface?"]
|
|
78
|
+
Q1 -->|Yes| Q2["Who is the primary actor and operational persona?"]
|
|
79
|
+
|
|
80
|
+
Q2 -->|Operator / Admin| Q_Op["1. Information Density: Dense tabular grid with filters?\n2. Persistent App Shell: Left collapsible sidebar route?\n3. Actions: Inline row actions or full-page drawer?"]
|
|
81
|
+
Q2 -->|Consumer / Member| Q_Member["1. Experience Duality: Consumer portal (/portal)?\n2. Touch Ergonomics: Clean cards & mobile drawer?\n3. Simplified self-service actions?"]
|
|
82
|
+
|
|
83
|
+
Q_Op --> Q3["Navigation & State Synchronization"]
|
|
84
|
+
Q_Member --> Q3
|
|
85
|
+
|
|
86
|
+
Q3 --> Q_State["1. URL State: Deep-link query params (?tab=, ?q=, ?page=, ?modal=)?\n2. Server Cache: TanStack Query hook with automated invalidation?\n3. Accessibility: Accessible headless dialogs & ARIA live regions?"]
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
73
91
|
## Contextual Follow-Up Patterns
|
|
74
92
|
|
|
75
93
|
When conducting the interview, use this exact syntax pattern to chain questions adaptively:
|
package/.gitignore
CHANGED
package/AGENTS.md
CHANGED
|
@@ -99,4 +99,4 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
99
99
|
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
100
100
|
- **Relentless Skill Architecture Inquiry:** Never author or update skills on assumptions. Interrogate all 7 inquiry branches (placement, trigger intent, domain truth, gotchas/anti-patterns, determinism, progressive bloat, verification loop) defined in [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) before writing `SKILL.md`.
|
|
101
101
|
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge/ubiquitous_language.md`](./docs/knowledge/ubiquitous_language.md) for domain glossaries.
|
|
102
|
-
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, `agents.md`, `GEMINI.md`, `.cursorrules`, and `.
|
|
102
|
+
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, `agents.md`, `GEMINI.md`, `.cursorrules`, `.windsurfrules`, and `.github/copilot-instructions.md` must remain identical via filesystem symbolic links to eliminate configuration divergence across different agent harnesses.
|
package/bin/azcodr.js
CHANGED
|
@@ -97,6 +97,9 @@ async function runCli(rawArgs = process.argv.slice(2), io = {}) {
|
|
|
97
97
|
return exit(1);
|
|
98
98
|
} else if (!targetDir) {
|
|
99
99
|
targetDir = arg;
|
|
100
|
+
} else {
|
|
101
|
+
err(`❌ Error: Unexpected argument '${arg}'. Run 'npx azcodr --help' for available options.`);
|
|
102
|
+
return exit(1);
|
|
100
103
|
}
|
|
101
104
|
}
|
|
102
105
|
|
|
@@ -181,18 +184,20 @@ async function runCli(rawArgs = process.argv.slice(2), io = {}) {
|
|
|
181
184
|
out(' ✅ Workspace knowledge hub and ADR ledger copied (docs/knowledge/, memory.md)');
|
|
182
185
|
out(' ✅ Specialized agentic skills copied (.agents/skills/)');
|
|
183
186
|
out(' ✅ Editor formatting standards initialized (.editorconfig)');
|
|
184
|
-
out(' ✅ Agent directives and harness symlinks established (AGENTS.md, CLAUDE.md, agents.md, GEMINI.md, .cursorrules, .windsurfrules)');
|
|
187
|
+
out(' ✅ Agent directives and harness symlinks established (AGENTS.md, CLAUDE.md, agents.md, GEMINI.md, .cursorrules, .windsurfrules, .github/copilot-instructions.md)');
|
|
188
|
+
out(' ✅ Project configuration initialized (package.json)');
|
|
185
189
|
if (result.gitInitialized) {
|
|
186
190
|
out(' ✅ Git repository initialized');
|
|
187
191
|
}
|
|
188
192
|
|
|
189
193
|
out('\n🎉 azcodr initialized successfully!\n');
|
|
190
194
|
out('Next steps:');
|
|
195
|
+
let step = 1;
|
|
191
196
|
if (targetDir !== '.' && targetDir !== './') {
|
|
192
|
-
out(`
|
|
197
|
+
out(` ${step++}. cd ${targetDir}`);
|
|
193
198
|
}
|
|
194
|
-
out(
|
|
195
|
-
out(
|
|
199
|
+
out(` ${step++}. Open the project in your AI coding assistant (Antigravity, Claude Code, Cursor, OpenHands)`);
|
|
200
|
+
out(` ${step++}. Run /lets-build to start the architectural interview and scaffold your application stack!\n`);
|
|
196
201
|
}
|
|
197
202
|
return exit(0);
|
|
198
203
|
} catch (error) {
|
|
@@ -40,6 +40,7 @@ Different AI agents and IDE harnesses look for different configuration filenames
|
|
|
40
40
|
- Google Antigravity & Gemini CLI: `GEMINI.md`
|
|
41
41
|
- Cursor: `.cursorrules`
|
|
42
42
|
- Windsurf: `.windsurfrules`
|
|
43
|
+
- GitHub Copilot: `.github/copilot-instructions.md`
|
|
43
44
|
|
|
44
45
|
**Standard:** Maintain identical configuration across all harnesses by establishing filesystem symbolic links:
|
|
45
46
|
```bash
|
|
@@ -48,6 +49,7 @@ ln -sf AGENTS.md CLAUDE.md
|
|
|
48
49
|
ln -sf AGENTS.md GEMINI.md
|
|
49
50
|
ln -sf AGENTS.md .cursorrules
|
|
50
51
|
ln -sf AGENTS.md .windsurfrules
|
|
52
|
+
mkdir -p .github && ln -sf ../AGENTS.md .github/copilot-instructions.md
|
|
51
53
|
```
|
|
52
54
|
Never duplicate content into separate files.
|
|
53
55
|
|
|
@@ -253,4 +255,5 @@ Significant architectural, technical stack, or invariant decisions must be captu
|
|
|
253
255
|
### Numbering & Immutability:
|
|
254
256
|
- ADR numbers are monotonically increasing (`ADR-001`, `ADR-002`, ...).
|
|
255
257
|
- ADR entries are **immutable history**. Never edit past accepted ADRs to represent new decisions; author a new ADR that explicitly supersedes the former.
|
|
258
|
+
- **Fresh Project Baseline (ADR Clean Slate):** When starting or bootstrapping a new project from this starter template, the memory ledger in [`memory.md`](../../memory.md) must be a clean slate with zero prior decisions recorded. The initial technical foundation derived during `/lets-build` must always be recorded as **`ADR-001`**. Template development history from `azcodr` must never bleed into downstream project memory ledgers.
|
|
256
259
|
|
|
@@ -39,6 +39,10 @@ Questions must dynamically pivot depending on the technical archetype:
|
|
|
39
39
|
*Trigger:* The feature interacts with external SaaS, webhooks, or cloud services.
|
|
40
40
|
- *Adaptive Inquiries:* What is the project-owned Port/Adapter boundary interface? What are the rate-limiting and circuit-breaking parameters? How are mock test doubles constructed without mocking third-party types directly?
|
|
41
41
|
|
|
42
|
+
### Branch E: User Interface, Experience Duality & Interaction Flows
|
|
43
|
+
*Trigger:* The feature introduces or modifies user interfaces, web pages, screen layouts, form mutations, or navigation.
|
|
44
|
+
- *Adaptive Inquiries:* Who is the target user persona (Operator/Admin dense workspace vs Consumer/Member portal)? How does the view fit into the Persistent App Shell (collapsible sidebar, global header) vs Dynamic Canvas? What is the URL state synchronization strategy (`useSearchParams` for `?tab=`, `?q=`, `?page=`, `?modal=`)? What server-state cache manager synchronizes data (TanStack Query)? How are validation feedback and errors displayed (RFC 7807 inline/toast alerts, WCAG 2.2 live regions, zero native `window.alert()`)?
|
|
45
|
+
|
|
42
46
|
---
|
|
43
47
|
|
|
44
48
|
## 3. Anti-Assumption Guardrails
|
|
@@ -66,6 +66,7 @@ Deviating from this lifecycle introduces catastrophic defects and architectural
|
|
|
66
66
|
| **Skipping Domain Analysis** | Hallucinated entities, missing business invariants, wrong data models. | "The Toy Prototype Blunder": Foreign key string inputs, unvalidated states, costly migrations. |
|
|
67
67
|
| **Writing Code Before Tests** | Untested edge cases, unfalsifiable code, confirmation bias in test design. | Hidden bugs in production, regressions during refactoring, brittle codebases. |
|
|
68
68
|
| **Skipping Outer Acceptance Tests** | In-memory unit tests pass, but user interactions and network routing fail. | "The In-Memory Supertest Illusion": App says "Offline/Connecting" while 100% unit tests pass. |
|
|
69
|
+
| **Dropping the UI in Fullstack TDD** | Developer plunges into internal domain units, leaving the application headless with no web UI. | "The Headless Fallacy": User requests a fullstack web app but receives pure headless backend libraries. |
|
|
69
70
|
| **Skipping the Refactor Phase** | Technical debt accumulates immediately behind green tests. | Code rot, duplicated logic, bloated monolithic functions (> 30 lines), violated DRY/SLAP. |
|
|
70
71
|
|
|
71
72
|
---
|
package/lib/scaffold.js
CHANGED
|
@@ -11,7 +11,8 @@ const TEMPLATE_ITEMS = [
|
|
|
11
11
|
'docs',
|
|
12
12
|
'.agents',
|
|
13
13
|
'.gitignore',
|
|
14
|
-
'.editorconfig'
|
|
14
|
+
'.editorconfig',
|
|
15
|
+
'LICENSE'
|
|
15
16
|
];
|
|
16
17
|
|
|
17
18
|
/**
|
|
@@ -93,7 +94,7 @@ function ensureSymlink(targetDir, linkName, targetFileName, dryRun = false) {
|
|
|
93
94
|
return true;
|
|
94
95
|
} catch {
|
|
95
96
|
// Fallback if environment (e.g., certain Windows configs) prevents symlink creation
|
|
96
|
-
const sourceFile = path.
|
|
97
|
+
const sourceFile = path.resolve(targetDir, targetFileName);
|
|
97
98
|
if (fs.existsSync(sourceFile)) {
|
|
98
99
|
fs.copyFileSync(sourceFile, linkPath);
|
|
99
100
|
}
|
|
@@ -102,10 +103,29 @@ function ensureSymlink(targetDir, linkName, targetFileName, dryRun = false) {
|
|
|
102
103
|
}
|
|
103
104
|
|
|
104
105
|
/**
|
|
105
|
-
* Ensures all bash scripts in skill directories have executable permissions (0o755).
|
|
106
|
+
* Ensures all bash scripts in agent and skill directories have executable permissions (0o755).
|
|
106
107
|
*/
|
|
107
108
|
function makeScriptsExecutable(targetDir, dryRun = false) {
|
|
108
109
|
const modified = [];
|
|
110
|
+
|
|
111
|
+
const agentScriptsDir = path.join(targetDir, '.agents', 'scripts');
|
|
112
|
+
if (fs.existsSync(agentScriptsDir) && fs.statSync(agentScriptsDir).isDirectory()) {
|
|
113
|
+
const files = fs.readdirSync(agentScriptsDir);
|
|
114
|
+
for (const file of files) {
|
|
115
|
+
if (file.endsWith('.sh')) {
|
|
116
|
+
const filePath = path.join(agentScriptsDir, file);
|
|
117
|
+
modified.push(filePath);
|
|
118
|
+
if (!dryRun) {
|
|
119
|
+
try {
|
|
120
|
+
fs.chmodSync(filePath, 0o755);
|
|
121
|
+
} catch {
|
|
122
|
+
// Non-critical if filesystem does not support POSIX permissions
|
|
123
|
+
}
|
|
124
|
+
}
|
|
125
|
+
}
|
|
126
|
+
}
|
|
127
|
+
}
|
|
128
|
+
|
|
109
129
|
const skillsDir = path.join(targetDir, '.agents', 'skills');
|
|
110
130
|
if (!fs.existsSync(skillsDir)) return modified;
|
|
111
131
|
|
|
@@ -146,7 +166,13 @@ function copyTemplate(targetDir, templateDir = getTemplateDir(), options = {}) {
|
|
|
146
166
|
}
|
|
147
167
|
|
|
148
168
|
for (const item of TEMPLATE_ITEMS) {
|
|
149
|
-
|
|
169
|
+
let srcPath = path.join(resolvedTemplate, item);
|
|
170
|
+
if (item === '.gitignore' && !fs.existsSync(srcPath)) {
|
|
171
|
+
const npmIgnorePath = path.join(resolvedTemplate, '.npmignore');
|
|
172
|
+
if (fs.existsSync(npmIgnorePath)) {
|
|
173
|
+
srcPath = npmIgnorePath;
|
|
174
|
+
}
|
|
175
|
+
}
|
|
150
176
|
if (!fs.existsSync(srcPath)) continue;
|
|
151
177
|
|
|
152
178
|
const destPath = path.join(resolvedTarget, item);
|
|
@@ -173,6 +199,36 @@ function copyTemplate(targetDir, templateDir = getTemplateDir(), options = {}) {
|
|
|
173
199
|
actions.push(`symlink: .windsurfrules -> AGENTS.md`);
|
|
174
200
|
ensureSymlink(resolvedTarget, '.windsurfrules', 'AGENTS.md', dryRun);
|
|
175
201
|
|
|
202
|
+
// GitHub Copilot harness parity
|
|
203
|
+
const githubDir = path.join(resolvedTarget, '.github');
|
|
204
|
+
if (!dryRun && !fs.existsSync(githubDir)) {
|
|
205
|
+
fs.mkdirSync(githubDir, { recursive: true });
|
|
206
|
+
}
|
|
207
|
+
actions.push(`symlink: .github/copilot-instructions.md -> ../AGENTS.md`);
|
|
208
|
+
ensureSymlink(githubDir, 'copilot-instructions.md', '../AGENTS.md', dryRun);
|
|
209
|
+
|
|
210
|
+
// Starter package.json for project scripts validation
|
|
211
|
+
const pkgJsonPath = path.join(resolvedTarget, 'package.json');
|
|
212
|
+
if (!fs.existsSync(pkgJsonPath)) {
|
|
213
|
+
actions.push('create: package.json');
|
|
214
|
+
if (!dryRun) {
|
|
215
|
+
const projectName = path.basename(resolvedTarget) || 'my-project';
|
|
216
|
+
const starterPkg = {
|
|
217
|
+
name: projectName,
|
|
218
|
+
version: '0.1.0',
|
|
219
|
+
private: true,
|
|
220
|
+
description: 'Scaffolded with azcodr enterprise architecture template',
|
|
221
|
+
scripts: {
|
|
222
|
+
test: 'node --test',
|
|
223
|
+
'test:coverage': 'node --test --experimental-test-coverage',
|
|
224
|
+
lint: 'echo "No linter configured yet. Run /lets-build to configure toolchain."',
|
|
225
|
+
validate: 'bash .agents/skills/agentic-architect/scripts/validate_agentic_configs.sh'
|
|
226
|
+
}
|
|
227
|
+
};
|
|
228
|
+
fs.writeFileSync(pkgJsonPath, JSON.stringify(starterPkg, null, 2) + '\n', 'utf-8');
|
|
229
|
+
}
|
|
230
|
+
}
|
|
231
|
+
|
|
176
232
|
// Ensure scripts are executable
|
|
177
233
|
const inspectDir = dryRun ? resolvedTemplate : resolvedTarget;
|
|
178
234
|
const scripts = makeScriptsExecutable(inspectDir, dryRun);
|
|
@@ -183,6 +239,23 @@ function copyTemplate(targetDir, templateDir = getTemplateDir(), options = {}) {
|
|
|
183
239
|
return actions;
|
|
184
240
|
}
|
|
185
241
|
|
|
242
|
+
/**
|
|
243
|
+
* Detects whether targetDir is already inside an existing Git worktree.
|
|
244
|
+
*/
|
|
245
|
+
function isInsideGitWorkTree(targetDir) {
|
|
246
|
+
try {
|
|
247
|
+
const checkDir = fs.existsSync(targetDir) ? targetDir : path.dirname(targetDir);
|
|
248
|
+
const out = cp.execSync('git rev-parse --is-inside-work-tree', {
|
|
249
|
+
cwd: checkDir,
|
|
250
|
+
stdio: ['ignore', 'pipe', 'ignore'],
|
|
251
|
+
encoding: 'utf-8'
|
|
252
|
+
});
|
|
253
|
+
return out.trim() === 'true';
|
|
254
|
+
} catch {
|
|
255
|
+
return false;
|
|
256
|
+
}
|
|
257
|
+
}
|
|
258
|
+
|
|
186
259
|
/**
|
|
187
260
|
* Initializes a git repository in the target directory if not already inside one.
|
|
188
261
|
*/
|
|
@@ -193,12 +266,41 @@ function initGit(targetDir, options = {}) {
|
|
|
193
266
|
const gitDir = path.join(targetDir, '.git');
|
|
194
267
|
if (fs.existsSync(gitDir)) return false;
|
|
195
268
|
|
|
269
|
+
if (isInsideGitWorkTree(targetDir)) return false;
|
|
270
|
+
|
|
196
271
|
if (dryRun) {
|
|
197
272
|
return true;
|
|
198
273
|
}
|
|
199
274
|
|
|
200
275
|
try {
|
|
201
|
-
|
|
276
|
+
try {
|
|
277
|
+
cp.execSync('git init -b main -q', { cwd: targetDir, stdio: 'ignore' });
|
|
278
|
+
} catch {
|
|
279
|
+
cp.execSync('git init -q', { cwd: targetDir, stdio: 'ignore' });
|
|
280
|
+
try {
|
|
281
|
+
cp.execSync('git branch -m main', { cwd: targetDir, stdio: 'ignore' });
|
|
282
|
+
} catch {
|
|
283
|
+
// Non-critical if branch rename fails
|
|
284
|
+
}
|
|
285
|
+
}
|
|
286
|
+
|
|
287
|
+
try {
|
|
288
|
+
cp.execSync('git add -A', { cwd: targetDir, stdio: 'ignore' });
|
|
289
|
+
try {
|
|
290
|
+
cp.execSync('git commit -q -m "chore: initial scaffold from azcodr template"', {
|
|
291
|
+
cwd: targetDir,
|
|
292
|
+
stdio: 'ignore'
|
|
293
|
+
});
|
|
294
|
+
} catch {
|
|
295
|
+
cp.execSync('git -c user.name="azcodr" -c user.email="azcodr@local" commit -q -m "chore: initial scaffold from azcodr template"', {
|
|
296
|
+
cwd: targetDir,
|
|
297
|
+
stdio: 'ignore'
|
|
298
|
+
});
|
|
299
|
+
}
|
|
300
|
+
} catch {
|
|
301
|
+
// Non-critical if initial commit fails
|
|
302
|
+
}
|
|
303
|
+
|
|
202
304
|
return true;
|
|
203
305
|
} catch {
|
|
204
306
|
return false;
|
|
@@ -242,6 +344,7 @@ module.exports = {
|
|
|
242
344
|
ensureSymlink,
|
|
243
345
|
isSameCaseInsensitiveFile,
|
|
244
346
|
makeScriptsExecutable,
|
|
347
|
+
isInsideGitWorkTree,
|
|
245
348
|
initGit,
|
|
246
349
|
getTemplateDir,
|
|
247
350
|
TEMPLATE_ITEMS
|
package/memory.md
CHANGED
|
@@ -17,273 +17,20 @@
|
|
|
17
17
|
|
|
18
18
|
| ID | Title | Date | Status | Governing Rule / Skill |
|
|
19
19
|
|---|---|---|---|---|
|
|
20
|
-
|
|
|
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 | [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md) |
|
|
23
|
-
| **ADR-004** | Systemic Atomicity & Pure Single-Responsibility Rule Decomposition | 2026-09-16 | ACCEPTED | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
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 | [`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
|
-
| **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) |
|
|
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 | [`database_design.md`](./docs/rules/database_design.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md) |
|
|
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
|
-
| **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
|
-
| **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
|
-
| **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), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) |
|
|
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), [`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) |
|
|
45
|
-
|
|
20
|
+
| *(No decisions recorded yet)* | *Record initial architecture decisions during Phase 3 of /lets-build.* | *YYYY-MM-DD* | *ACCEPTED* | *e.g. [`clean_code.md`](./docs/rules/clean_code.md)* |
|
|
46
21
|
|
|
47
22
|
---
|
|
48
23
|
|
|
49
24
|
### Lightweight Decision Summaries
|
|
50
25
|
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
- **
|
|
59
|
-
- **
|
|
60
|
-
- **
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
#### ADR-003: Dual-Layer Multi-Tenancy Isolation with PostgreSQL RLS
|
|
64
|
-
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
65
|
-
- **Context:** Application-level `where: { tenantId }` filtering is prone to human error, risking catastrophic cross-tenant data leaks.
|
|
66
|
-
- **Decision:** Combine application middleware context resolution with database-level PostgreSQL Row-Level Security (RLS) policies as an immutable backstop.
|
|
67
|
-
- **Enforced In:** [`multitenancy_architecture.md`](./docs/rules/multitenancy_architecture.md).
|
|
68
|
-
|
|
69
|
-
#### ADR-004: Systemic Atomicity & Pure Single-Responsibility Rule Decomposition
|
|
70
|
-
- **Date:** 2026-09-16 | **Status:** ACCEPTED
|
|
71
|
-
- **Context:** Composite rules with conjunction names (`this_and_that.md`) mix disparate technical concerns, creating documentation bloat and ambiguity.
|
|
72
|
-
- **Decision:** Decompose all rules into strictly atomic, single-topic rule files with zero conjunction names, enforcing Single Responsibility Principle across skills, rules, and database operations.
|
|
73
|
-
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`agentic_configuration.md`](./docs/rules/agentic_configuration.md).
|
|
74
|
-
|
|
75
|
-
#### ADR-005: Universal Technology, Language, and Stack Agnosticism
|
|
76
|
-
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
77
|
-
- **Context:** Coupling architecture rules to a single programming language or database creates technical lock-in and prevents polyglot implementation.
|
|
78
|
-
- **Decision:** Adopt a Two-Tier Hexagonal / Ports-and-Adapters model across the entire system: Tier 1 mandates 100% technology-, language-, and stack-agnostic invariant domain capabilities and open standard specifications; Tier 2 encapsulates interchangeable polyglot adapters.
|
|
79
|
-
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`lets-build`](./.agents/skills/lets-build/SKILL.md).
|
|
80
|
-
|
|
81
|
-
#### ADR-006: Mandatory Full Lifecycle CRUD & Relational Foreign Key Selector Pattern
|
|
82
|
-
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
83
|
-
- **Context:** Prototypes often provide partial CRUD, leaving entities un-editable or undeletable. Exposing foreign keys as raw text inputs causes severe relational errors.
|
|
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.
|
|
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).
|
|
86
|
-
|
|
87
|
-
#### ADR-007: Strict Decoupling of Project Bootstrapping from Domain Analysis
|
|
88
|
-
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
89
|
-
- **Context:** Agents running `/lets-build` frequently fabricate domain entities on sheer assumptions during technical bootstrapping, skipping requirements discovery.
|
|
90
|
-
- **Decision:** Project bootstrapping terminates strictly after technical skeleton creation and health probe verification (`Phase 5`). A mandatory Handover Gate halts coding and directs the agent to initiate Domain Analysis via `product-analyst` and `relentless-questioner` before domain models or schemas are authored.
|
|
91
|
-
- **Enforced In:** [`lets-build`](./.agents/skills/lets-build/SKILL.md), [`product-analyst`](./.agents/skills/product-analyst/SKILL.md), [`requirements_engineering.md`](./docs/rules/requirements_engineering.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md).
|
|
92
|
-
|
|
93
|
-
#### ADR-008: Non-Negotiable 5-Phase Agile Domain Lifecycle & Outside-In TDD Invariant
|
|
94
|
-
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
95
|
-
- **Context:** Writing production code before tests or domain understanding leads to brittle code, regressions, and "toy prototypes."
|
|
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.
|
|
97
|
-
- **Enforced In:** Root [`AGENTS.md`](./AGENTS.md), [`test_driven_development.md`](./docs/rules/test_driven_development.md).
|
|
98
|
-
|
|
99
|
-
#### ADR-009: Many-to-Many Skill Composability & Orthogonal Pipeline Architecture
|
|
100
|
-
- **Date:** 2026-09-18 | **Status:** ACCEPTED
|
|
101
|
-
- **Context:** Complex engineering tasks require multiple orthogonal skills; coupling skills into monolithic bundles causes context bloat and cross-contamination.
|
|
102
|
-
- **Decision:** Codify Many-to-Many skill composability via three formal patterns: Sequential Pipeline Chaining, Dynamic Skill Stacking, and Multi-Agent Subagent Delegation, with standardized output contracts, pure function semantics, and zero cross-contamination.
|
|
103
|
-
- **Enforced In:** [`agentic_configuration.md`](./docs/rules/agentic_configuration.md), [`agentic-architect`](./.agents/skills/agentic-architect/SKILL.md).
|
|
104
|
-
|
|
105
|
-
#### ADR-011: The Canonical 6 Total Audit Fields Architecture & Modern React Stack
|
|
106
|
-
- **Date:** 2026-09-19 | **Status:** ACCEPTED
|
|
107
|
-
- **Context:** Inconsistent audit tracking risks SOC 2 / ISO 27001 non-compliance. Frontend `useEffect` fetch loops cause stale states and race conditions.
|
|
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.
|
|
109
|
-
- **Enforced In:** [`database_design.md`](./docs/rules/database_design.md), [`frontend_architecture.md`](./docs/rules/frontend_architecture.md).
|
|
110
|
-
|
|
111
|
-
#### ADR-012: State Machine Lifecycle Configurability & Living Ubiquitous Language Contract
|
|
112
|
-
- **Date:** 2026-09-19 | **Status:** ACCEPTED
|
|
113
|
-
- **Context:** Unconstrained state configurability causes the "Inner Platform Effect." Linguistic drift between business terms and code identifiers breaks domain models.
|
|
114
|
-
- **Decision:** Bifurcate state into Core Invariant States (Hard FSM in compiled aggregate roots) and Operational Workflow Stages (Soft FSM in declarative JSON state transition matrices evaluated via CEL/Temporal). Maintain a living, single-name Ubiquitous Language Glossary contract.
|
|
115
|
-
- **Enforced In:** [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`ubiquitous_language.md`](./docs/knowledge/ubiquitous_language.md).
|
|
116
|
-
|
|
117
|
-
#### ADR-013: Design Architecture Triage Framework, Persistent Shell & Dev Persona Isolation
|
|
118
|
-
- **Date:** 2026-09-20 | **Status:** ACCEPTED
|
|
119
|
-
- **Context:** Conflating developer demo personas with production auth creates toy-like prototypes. Untriaged UI produces layout shifts and broken navigation.
|
|
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`).
|
|
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).
|
|
122
|
-
|
|
123
|
-
#### ADR-014: Product Ownership, Backlog Prioritization Models, SMART Developer Tasks & INVEST Slicing
|
|
124
|
-
- **Date:** 2026-09-21 | **Status:** ACCEPTED
|
|
125
|
-
- **Context:** Teams frequently measure output (lines of code, story points) rather than outcome (customer value), leading to the "Feature Factory" anti-pattern.
|
|
126
|
-
- **Decision:** Ground backlog ordering in quantitative prioritization (Kano, MoSCoW, RICE) aligned with OKRs; decompose epics into vertically sliced INVEST user stories; decompose user stories into bounded SMART developer tasks (2–4 hours).
|
|
127
|
-
- **Enforced In:** [`product_ownership.md`](./docs/rules/product_ownership.md), [`requirements_engineering.md`](./docs/rules/requirements_engineering.md), [`project_management.md`](./docs/rules/project_management.md), [`product-analyst`](./.agents/skills/product-analyst/SKILL.md).
|
|
128
|
-
|
|
129
|
-
#### ADR-015: Problem-First Architecture, Topology Scaffolding, Evolutionary Tipping Points & Incremental Nano-Cycle TDD
|
|
130
|
-
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
131
|
-
- **Context:** Tool-first planning (asking for languages, databases, and microservices upfront) creates accidental complexity and forces non-backend projects (such as Chrome extensions, game engines, or CLIs) into heavy enterprise templates (as observed in `force-dark-light`). Furthermore, AI assistants naturally accelerate architectural drift by appending code without structural evolution, and fake TDD by batch-generating 15 tests and implementations at once.
|
|
132
|
-
- **Decision:**
|
|
133
|
-
1. Enforce **Problem-First Architecture**: Strictly separate Problem Space from Solution Space (Evans, Vernon, Brooks). Derive tools and runtimes from problem constraints (latency budget, GC tolerance, memory, execution target).
|
|
134
|
-
2. Implement **Topology-Aware Scaffolding**: Eliminate universal templates. Match architectural styles to system topologies (Platform Scripting for extensions, Data-Oriented Design for game engines, Command Pipeline for CLIs, Hexagonal for enterprise backends).
|
|
135
|
-
3. Codify **Evolutionary Architecture & Architectural Tipping Points**: Enforce Kent Beck's "Refactor-Before-Add" protocol and 5 explicit tipping points to halt AI-generated code rot.
|
|
136
|
-
4. Mandate **True Incremental TDD & Nano-Cycles**: Prohibit batch-test dumps ("Test-First Waterfall"); enforce Uncle Bob's Three Laws (especially Law #2) and Ping-Pong pair programming with verified RED failure proofs.
|
|
137
|
-
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`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), [`architecture_interview_matrix.md`](./.agents/skills/lets-build/references/architecture_interview_matrix.md).
|
|
138
|
-
|
|
139
|
-
#### ADR-016: Elimination of Static Markdown Knowledge Graph in Favor of Code-as-Truth & Living Glossary
|
|
140
|
-
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
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.
|
|
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.
|
|
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).
|
|
144
|
-
|
|
145
|
-
#### ADR-017: Progressive Rules Consolidation (DDD & GoF Design Patterns)
|
|
146
|
-
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
147
|
-
- **Context:** Multiple domain rules exhibited redundant overlaps: `domain_expertise.md` duplicated strategic capability mapping and tactical aggregate invariants already governed by `domain_driven_design.md`, while `gof_design_patterns_reference.md` artificially fragmented design patterns into a separate satellite file from `design_patterns.md`. This fragmentation caused token bloat in `AGENTS.md` and scattered domain invariants.
|
|
148
|
-
- **Decision:**
|
|
149
|
-
1. Merge business capability tiering (Core/Supporting/Generic) and the Aggregate Root Gatekeeper invariant example into [`domain_driven_design.md`](./docs/rules/domain_driven_design.md). Delete redundant `domain_expertise.md`.
|
|
150
|
-
2. Consolidate the 23 Gang of Four patterns catalog directly into [`design_patterns.md`](./docs/rules/design_patterns.md). Delete redundant `gof_design_patterns_reference.md`.
|
|
151
|
-
3. Streamline rule catalog across `AGENTS.md` and `README.md` to 45 lean, single-responsibility, non-overlapping rules.
|
|
152
|
-
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), [`domain_driven_design.md`](./docs/rules/domain_driven_design.md), [`design_patterns.md`](./docs/rules/design_patterns.md).
|
|
153
|
-
|
|
154
|
-
#### ADR-018: Elimination of Upstream Changes Ledger and Upstream Sync Tooling
|
|
155
|
-
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
156
|
-
- **Context:** Maintaining a manual `changes.md` ledger duplicated state already captured across Git commit history and formal ADR records in `memory.md`. Furthermore, scaffolding `changes.md` into downstream derived projects contaminated them with meta-tooling baggage about the upstream template, violating Problem-First Architecture and Workspace Sovereignty. Accompanying CLI subcommands (`npx azcodr change`) and rule files (`upstream_synchronization.md`) added over 200 lines of accidental maintenance complexity.
|
|
157
|
-
- **Decision:**
|
|
158
|
-
1. Permanently delete `changes.md` and retire `docs/rules/upstream_synchronization.md`.
|
|
159
|
-
2. Remove `changes.md` from scaffolded `TEMPLATE_ITEMS` and package manifests.
|
|
160
|
-
3. Purge `logChange` functions, types, and CLI subcommands, restoring `azcodr` CLI as a clean, single-purpose project bootstrapper.
|
|
161
|
-
4. Standardize exclusively on Git commits for historical revision logs and `memory.md` for architectural decision records.
|
|
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
|
-
|
|
289
|
-
|
|
26
|
+
<!--
|
|
27
|
+
Record project Architectural Decision Records (ADRs) below as decisions are finalized.
|
|
28
|
+
Format:
|
|
29
|
+
|
|
30
|
+
#### ADR-001: [Imperative Title]
|
|
31
|
+
- **Date:** YYYY-MM-DD | **Status:** ACCEPTED
|
|
32
|
+
- **Context:** Problem space, constraints, and operational context requiring a decision.
|
|
33
|
+
- **Decision:** Chosen architecture, invariants, and implementation patterns.
|
|
34
|
+
- **Consequences:** Positive benefits and deliberate trade-offs accepted.
|
|
35
|
+
- **Enforced In:** Relevant rule files in docs/rules/ or code paths.
|
|
36
|
+
-->
|