azcodr 1.2.1 → 1.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +1 -1
- package/AGENTS.md +3 -6
- package/README.md +4 -11
- package/bin/azcodr.js +2 -81
- package/docs/knowledge/ubiquitous_language.md +1 -6
- package/docs/rules/continuous_learning.md +0 -1
- package/docs/rules/design_patterns.md +52 -2
- package/docs/rules/domain_driven_design.md +25 -1
- package/lib/index.d.ts +0 -30
- package/lib/scaffold.js +0 -46
- package/memory.md +29 -2
- package/package.json +1 -2
- package/changes.md +0 -62
- package/docs/knowledge/knowledge_graph.md +0 -188
- package/docs/rules/domain_expertise.md +0 -42
- package/docs/rules/gof_design_patterns_reference.md +0 -70
- package/docs/rules/upstream_synchronization.md +0 -53
|
@@ -12,7 +12,7 @@ Regardless of language, all bootstrapped projects must follow this high-level se
|
|
|
12
12
|
<project-root>/
|
|
13
13
|
├── .agents/skills/ # Specialized agentic workflows (carried from azcodr template)
|
|
14
14
|
├── docs/
|
|
15
|
-
│ ├── knowledge/ #
|
|
15
|
+
│ ├── knowledge/ # Domain knowledge & living ubiquitous language glossary
|
|
16
16
|
│ └── rules/ # 41 atomic single-responsibility domain rules
|
|
17
17
|
├── specs/ # Canonical contract specifications
|
|
18
18
|
│ ├── protobuf/ # gRPC service definitions (*.proto)
|
package/AGENTS.md
CHANGED
|
@@ -59,8 +59,7 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
59
59
|
| **TDD Double Loop** | [docs/rules/test_driven_development.md](./docs/rules/test_driven_development.md) | Outside-In TDD (London School), collaborator discovery, mock ownership. |
|
|
60
60
|
| **Test Coverage & Isolation** | [docs/rules/test_isolation.md](./docs/rules/test_isolation.md) | 100.00% full-stack coverage, status codes, transactional DB rollback. |
|
|
61
61
|
| **Clean Code** | [docs/rules/clean_code.md](./docs/rules/clean_code.md) | Naming, small functions, CQS, SLAP, DRY, DbC, zero side-effects. |
|
|
62
|
-
| **Design Patterns** | [docs/rules/design_patterns.md](./docs/rules/design_patterns.md) | Adapter, Factory,
|
|
63
|
-
| **GoF Design Patterns** | [docs/rules/gof_design_patterns_reference.md](./docs/rules/gof_design_patterns_reference.md) | Complete reference of all 23 GoF patterns across OOP and functional paradigms. |
|
|
62
|
+
| **Design Patterns** | [docs/rules/design_patterns.md](./docs/rules/design_patterns.md) | Adapter, Factory, Strategy, Result `<T, E>`, and complete 23 GoF catalog. |
|
|
64
63
|
| **Type Safety** | [docs/rules/typescript.md](./docs/rules/typescript.md) | Compiler strictness, branded nominal types, type safety, static sound invariants. |
|
|
65
64
|
| **ADRs** | [docs/rules/architecture_decision_records.md](./docs/rules/architecture_decision_records.md) | Authoring Lightweight Architectural Decision Records in `memory.md`. |
|
|
66
65
|
| **Authentication** | [docs/rules/authentication.md](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
@@ -93,16 +92,14 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
93
92
|
| **React & Frontend** | [docs/rules/react.md](./docs/rules/react.md) | Modern React, shadcn/ui, TanStack Query, React Hook Form, and Zod validation. |
|
|
94
93
|
| **Requirements Engineering** | [docs/rules/requirements_engineering.md](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
95
94
|
| **Product Ownership** | [docs/rules/product_ownership.md](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
96
|
-
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts,
|
|
95
|
+
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts, Aggregates, Capability Mapping. |
|
|
97
96
|
| **Workflow State Machines** | [docs/rules/workflow_state_machines.md](./docs/rules/workflow_state_machines.md) | Configurable workflows, in-aggregate invariant FSMs, transition guards & audit logs. |
|
|
98
97
|
| **Cloud-Native 12-Factor** | [docs/rules/cloud_native.md](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
99
98
|
| **Agentic Config & Skills** | [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) | Progressive disclosure architecture, skill inquiry branches, refinement loop. |
|
|
100
99
|
| **Project Management** | [docs/rules/project_management.md](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
101
|
-
| **Domain Modeling** | [docs/rules/domain_expertise.md](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
102
100
|
| **Relentless Questioning** | [docs/rules/relentless_questioning.md](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
103
101
|
| **Workspace Isolation** | [docs/rules/workspace_isolation.md](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
104
102
|
| **Continuous Learning** | [docs/rules/continuous_learning.md](./docs/rules/continuous_learning.md) | Direct rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
105
|
-
| **Upstream Sync** | [docs/rules/upstream_synchronization.md](./docs/rules/upstream_synchronization.md) | Logging generic architecture improvements to changes.md; zero baseline pollution. |
|
|
106
103
|
---
|
|
107
104
|
|
|
108
105
|
## 4. Agent Configuration & Workspace Architecture
|
|
@@ -116,5 +113,5 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
116
113
|
- [`lets-build`](.agents/skills/lets-build/SKILL.md): Conducting architecture interviews to finalize stack, frameworks, package managers, and bootstrapping projects.
|
|
117
114
|
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
118
115
|
- **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`.
|
|
119
|
-
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge
|
|
116
|
+
- **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.
|
|
120
117
|
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, and `agents.md` must remain identical via filesystem symbolic links to eliminate configuration divergence across different agent harnesses.
|
package/README.md
CHANGED
|
@@ -37,13 +37,11 @@
|
|
|
37
37
|
│ └── relentless-questioner/ # Context-aware dynamic interrogation loop
|
|
38
38
|
├── docs/
|
|
39
39
|
│ ├── knowledge/ # Institutional knowledge & domain contracts
|
|
40
|
-
│ │ ├── knowledge_graph.md # Visual topologies & fast-lookup matrices
|
|
41
40
|
│ │ └── ubiquitous_language.md # Living Ubiquitous Language glossary template
|
|
42
|
-
│ └── rules/ #
|
|
41
|
+
│ └── rules/ # 44 atomic single-responsibility domain rules
|
|
43
42
|
├── AGENTS.md # Lean root agentic configuration (< 120 lines)
|
|
44
43
|
├── CLAUDE.md -> AGENTS.md # Filesystem symlink for harness parity
|
|
45
44
|
├── agents.md -> AGENTS.md # Filesystem symlink for harness parity
|
|
46
|
-
├── changes.md # Upstream changes ledger
|
|
47
45
|
├── memory.md # Master memory hub & Lightweight ADR ledger
|
|
48
46
|
└── README.md # Project documentation
|
|
49
47
|
```
|
|
@@ -52,15 +50,14 @@
|
|
|
52
50
|
|
|
53
51
|
## 📋 Progressive Disclosure Rules Catalog (`docs/rules/`)
|
|
54
52
|
|
|
55
|
-
The architecture enforces
|
|
53
|
+
The architecture enforces 44 atomic, single-responsibility domain rules. Read on demand to prevent prompt context bloat:
|
|
56
54
|
|
|
57
55
|
| Domain | Rule Reference File | Key Focus & Invariants |
|
|
58
56
|
|---|---|---|
|
|
59
57
|
| **TDD Double Loop** | [`test_driven_development.md`](./docs/rules/test_driven_development.md) | Uncle Bob's 3 Laws, nano-cycles, Ping-Pong pairing, outside-in double loop. |
|
|
60
58
|
| **Test Coverage & Isolation** | [`test_isolation.md`](./docs/rules/test_isolation.md) | 100.00% full-stack coverage, status codes, transactional DB rollback. |
|
|
61
59
|
| **Clean Code** | [`clean_code.md`](./docs/rules/clean_code.md) | 5 evolutionary tipping points, Refactor-Before-Add, CQS, SLAP, DRY, fitness functions. |
|
|
62
|
-
| **Design Patterns** | [`design_patterns.md`](./docs/rules/design_patterns.md) | Adapter, Factory,
|
|
63
|
-
| **GoF Design Patterns** | [`gof_design_patterns_reference.md`](./docs/rules/gof_design_patterns_reference.md) | Complete reference of all 23 GoF patterns across OOP and functional paradigms. |
|
|
60
|
+
| **Design Patterns** | [`design_patterns.md`](./docs/rules/design_patterns.md) | Adapter, Factory, Strategy, Result `<T, E>`, and complete 23 GoF catalog. |
|
|
64
61
|
| **Type Safety** | [`typescript.md`](./docs/rules/typescript.md) | Compiler strictness, branded nominal types, type safety, static sound invariants. |
|
|
65
62
|
| **ADRs** | [`architecture_decision_records.md`](./docs/rules/architecture_decision_records.md) | Authoring Lightweight Architectural Decision Records in `memory.md`. |
|
|
66
63
|
| **Authentication** | [`authentication.md`](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
@@ -93,16 +90,14 @@ The architecture enforces 47 atomic, single-responsibility domain rules. Read on
|
|
|
93
90
|
| **React & Frontend** | [`react.md`](./docs/rules/react.md) | Modern React, shadcn/ui, TanStack Query, React Hook Form, and Zod validation. |
|
|
94
91
|
| **Requirements Engineering** | [`requirements_engineering.md`](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
95
92
|
| **Product Ownership** | [`product_ownership.md`](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
96
|
-
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Problem
|
|
93
|
+
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Problem vs Solution Space, Ubiquitous Language, Aggregates, Capability Mapping. |
|
|
97
94
|
| **Workflow State Machines** | [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md) | Configurable workflows, in-aggregate invariant FSMs, transition guards & audit logs. |
|
|
98
95
|
| **Cloud-Native 12-Factor** | [`cloud_native.md`](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
99
96
|
| **Agentic Config & Skills** | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) | Progressive disclosure architecture, skill inquiry branches, refinement loop. |
|
|
100
97
|
| **Project Management** | [`project_management.md`](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
101
|
-
| **Domain Modeling** | [`domain_expertise.md`](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
102
98
|
| **Relentless Questioning** | [`relentless_questioning.md`](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
103
99
|
| **Workspace Isolation** | [`workspace_isolation.md`](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
104
100
|
| **Continuous Learning** | [`continuous_learning.md`](./docs/rules/continuous_learning.md) | Direct 4-step rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
105
|
-
| **Upstream Sync** | [`upstream_synchronization.md`](./docs/rules/upstream_synchronization.md) | Logging generic architecture improvements to changes.md; zero baseline pollution. |
|
|
106
101
|
|
|
107
102
|
---
|
|
108
103
|
|
|
@@ -168,7 +163,5 @@ Once confirmed, the agent automatically executes:
|
|
|
168
163
|
|
|
169
164
|
## 🏛️ Workspace Memory & Knowledge Hub
|
|
170
165
|
|
|
171
|
-
- 🗺️ **[System Knowledge Graph](./docs/knowledge/knowledge_graph.md)**: Visual subsystem topologies and entity-relationship models.
|
|
172
166
|
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative domain vocabulary contract.
|
|
173
167
|
- 📜 **[Lightweight ADR Ledger](./memory.md)**: Formal Architectural Decision Records and governing rules.
|
|
174
|
-
- 📝 **[Upstream Changes Ledger](./changes.md)**: Record candidate improvements and generic patterns for the upstream azcodr template.
|
package/bin/azcodr.js
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
const path = require('node:path');
|
|
5
5
|
const readline = require('node:readline');
|
|
6
6
|
const fs = require('node:fs');
|
|
7
|
-
const { scaffold,
|
|
7
|
+
const { scaffold, getTemplateDir } = require('../lib/scaffold.js');
|
|
8
8
|
const pkg = require('../package.json');
|
|
9
9
|
|
|
10
10
|
function printHelp(out = console.log) {
|
|
@@ -14,13 +14,11 @@ Enterprise Multi-Tenant Architecture & Agentic Engineering Starter Template
|
|
|
14
14
|
|
|
15
15
|
Usage:
|
|
16
16
|
npx azcodr [directory] [options]
|
|
17
|
-
npx azcodr change <title> [options]
|
|
18
17
|
|
|
19
18
|
Commands:
|
|
20
19
|
[directory] Scaffold azcodr template into directory (default: current directory)
|
|
21
|
-
change <title> Log a generic architectural change to changes.md
|
|
22
20
|
|
|
23
|
-
|
|
21
|
+
Options:
|
|
24
22
|
-d, --dry-run Simulate scaffolding without modifying filesystem
|
|
25
23
|
-s, --silent Suppress console output messages
|
|
26
24
|
-f, --force Overwrite existing files in target directory without confirmation
|
|
@@ -28,17 +26,10 @@ Scaffold Options:
|
|
|
28
26
|
-v, --version Display version number
|
|
29
27
|
-h, --help Display this help message
|
|
30
28
|
|
|
31
|
-
Change Options:
|
|
32
|
-
-c, --category Category (Architecture | Rule | Skill | Infrastructure | CLI | Knowledge Hub)
|
|
33
|
-
-f, --files Target file(s) affected (e.g. "docs/rules/caching.md")
|
|
34
|
-
-r, --rationale Rationale for upstream template incorporation
|
|
35
|
-
-d, --desc Detailed description of the change
|
|
36
|
-
|
|
37
29
|
Examples:
|
|
38
30
|
npx azcodr my-project
|
|
39
31
|
npx azcodr . --dry-run
|
|
40
32
|
npx azcodr . --force
|
|
41
|
-
npx azcodr change "Add Wasm plugin interface" -c Architecture
|
|
42
33
|
`);
|
|
43
34
|
}
|
|
44
35
|
|
|
@@ -67,70 +58,6 @@ function askQuestion(query, { input = process.stdin, output = process.stdout } =
|
|
|
67
58
|
});
|
|
68
59
|
}
|
|
69
60
|
|
|
70
|
-
async function handleLogChange(rawArgs = process.argv.slice(2), io = {}) {
|
|
71
|
-
const {
|
|
72
|
-
out = console.log,
|
|
73
|
-
err = console.error,
|
|
74
|
-
exit = process.exit,
|
|
75
|
-
stdin = process.stdin,
|
|
76
|
-
stdout = process.stdout,
|
|
77
|
-
cwd = process.cwd(),
|
|
78
|
-
logChange: logChangeFn = logChange
|
|
79
|
-
} = io;
|
|
80
|
-
|
|
81
|
-
let title = null;
|
|
82
|
-
let category = 'Architecture';
|
|
83
|
-
let targetFiles = 'docs/rules/';
|
|
84
|
-
let rationale = 'Generic architectural enhancement';
|
|
85
|
-
let description = '';
|
|
86
|
-
|
|
87
|
-
for (let i = 1; i < rawArgs.length; i++) {
|
|
88
|
-
const a = rawArgs[i];
|
|
89
|
-
if (a === '-c' || a === '--category') {
|
|
90
|
-
category = rawArgs[++i] || category;
|
|
91
|
-
} else if (a === '-f' || a === '--files') {
|
|
92
|
-
targetFiles = rawArgs[++i] || targetFiles;
|
|
93
|
-
} else if (a === '-r' || a === '--rationale') {
|
|
94
|
-
rationale = rawArgs[++i] || rationale;
|
|
95
|
-
} else if (a === '-d' || a === '--desc' || a === '--description') {
|
|
96
|
-
description = rawArgs[++i] || description;
|
|
97
|
-
} else if (a.startsWith('-')) {
|
|
98
|
-
err(`❌ Error: Unknown argument '${a}'. Run 'npx azcodr --help' for available options.`);
|
|
99
|
-
return exit(1);
|
|
100
|
-
} else if (!title) {
|
|
101
|
-
title = a;
|
|
102
|
-
}
|
|
103
|
-
}
|
|
104
|
-
|
|
105
|
-
if (!title) {
|
|
106
|
-
if (stdin.isTTY) {
|
|
107
|
-
title = await askQuestion('? Change title: ', { input: stdin, output: stdout });
|
|
108
|
-
}
|
|
109
|
-
}
|
|
110
|
-
|
|
111
|
-
if (!title) {
|
|
112
|
-
err('❌ Error: A title is required to log an upstream change.');
|
|
113
|
-
err('Usage: npx azcodr change "<title>" [-c Category] [-f Files] [-r Rationale] [-d Description]');
|
|
114
|
-
return exit(1);
|
|
115
|
-
}
|
|
116
|
-
|
|
117
|
-
try {
|
|
118
|
-
const res = logChangeFn({
|
|
119
|
-
title,
|
|
120
|
-
category,
|
|
121
|
-
targetFiles,
|
|
122
|
-
rationale,
|
|
123
|
-
description,
|
|
124
|
-
targetDir: cwd
|
|
125
|
-
});
|
|
126
|
-
out(`\n✅ Upstream change logged to ${res.filePath}\n`);
|
|
127
|
-
return exit(0);
|
|
128
|
-
} catch (error) {
|
|
129
|
-
err(`\n❌ Failed to log change: ${error.message}\n`);
|
|
130
|
-
return exit(1);
|
|
131
|
-
}
|
|
132
|
-
}
|
|
133
|
-
|
|
134
61
|
async function runCli(rawArgs = process.argv.slice(2), io = {}) {
|
|
135
62
|
const {
|
|
136
63
|
out = console.log,
|
|
@@ -143,10 +70,6 @@ async function runCli(rawArgs = process.argv.slice(2), io = {}) {
|
|
|
143
70
|
scaffold: scaffoldFn = scaffold
|
|
144
71
|
} = io;
|
|
145
72
|
|
|
146
|
-
if (rawArgs[0] === 'change' || rawArgs[0] === 'log-change') {
|
|
147
|
-
return handleLogChange(rawArgs, io);
|
|
148
|
-
}
|
|
149
|
-
|
|
150
73
|
let targetDir = null;
|
|
151
74
|
let force = false;
|
|
152
75
|
let noGit = false;
|
|
@@ -257,7 +180,6 @@ async function runCli(rawArgs = process.argv.slice(2), io = {}) {
|
|
|
257
180
|
out(' ✅ Progressive disclosure rules copied (docs/rules/)');
|
|
258
181
|
out(' ✅ Workspace knowledge hub and ADR ledger copied (docs/knowledge/, memory.md)');
|
|
259
182
|
out(' ✅ Specialized agentic skills copied (.agents/skills/)');
|
|
260
|
-
out(' ✅ Upstream changes ledger initialized (changes.md)');
|
|
261
183
|
out(' ✅ Editor formatting standards initialized (.editorconfig)');
|
|
262
184
|
out(' ✅ Agent directives and harness symlinks established (AGENTS.md, CLAUDE.md, agents.md)');
|
|
263
185
|
if (result.gitInitialized) {
|
|
@@ -294,7 +216,6 @@ if (require.main === module) {
|
|
|
294
216
|
|
|
295
217
|
module.exports = {
|
|
296
218
|
runCli,
|
|
297
|
-
handleLogChange,
|
|
298
219
|
askQuestion,
|
|
299
220
|
printHelp,
|
|
300
221
|
printVersion,
|
|
@@ -8,12 +8,7 @@
|
|
|
8
8
|
|
|
9
9
|
| Canonical Term | Business Definition | Bounded Context | Forbidden Synonyms | Code & Database Identifiers |
|
|
10
10
|
|---|---|---|---|---|
|
|
11
|
-
|
|
|
12
|
-
| **User** | A human actor authenticated with verified credentials across the platform. | Identity & Access | Member (when unauthenticated), Account, Login | `User`, `userId`, `users` table |
|
|
13
|
-
| **Membership** | The formal association connecting a User to an Organization with assigned roles. | Authorization & RBAC | UserOrg, Seat, PermissionAssignment | `Membership`, `membershipId`, `memberships` table |
|
|
14
|
-
| **Role** | A named set of granular `<entity>:<action>` permissions within an organization. | Authorization | Group, Profile, Level | `Role`, `roleId`, `roles` table |
|
|
15
|
-
| **Resource** | The primary business entity managed within the domain core. | Core Domain | Item, Object, Record, Entity | `Resource`, `resourceId`, `resources` table |
|
|
16
|
-
| **Ledger Entry** | An immutable audit record detailing a financial or transactional state change. | Finance & Accounting | TransactionRow, MoneyLog, BillEntry | `LedgerEntry`, `ledgerEntryId`, `ledger_entries` table |
|
|
11
|
+
| *(No domain terms defined yet)* | *Define business meaning during Phase 1 Domain Discovery.* | *e.g. Core Domain* | *Synonyms strictly forbidden across code & UI.* | *Exact type, class, or table name.* |
|
|
17
12
|
|
|
18
13
|
---
|
|
19
14
|
|
|
@@ -26,5 +26,4 @@ Whenever an error, test failure, build friction, or architectural anti-pattern o
|
|
|
26
26
|
## 2. Institutional Memory Maintenance
|
|
27
27
|
|
|
28
28
|
- **Lightweight ADR Ledger**: Major technical decisions and invariant shifts are logged in [`memory.md`](../../memory.md) linking directly to the governing rule or skill.
|
|
29
|
-
- **System Knowledge Graph**: Keep [`docs/knowledge/knowledge_graph.md`](../knowledge/knowledge_graph.md) synchronized with new services, ports, or adapters to avoid repetitive token-expensive codebase discovery in future sessions.
|
|
30
29
|
- **Living Glossary**: Keep [`docs/knowledge/ubiquitous_language.md`](../knowledge/ubiquitous_language.md) updated with canonical domain terminology and forbidden synonyms.
|
|
@@ -36,6 +36,56 @@ Domain services must return explicit Result types, compelling callers to handle
|
|
|
36
36
|
|
|
37
37
|
---
|
|
38
38
|
|
|
39
|
-
## 3. GoF 23 Patterns Catalog
|
|
39
|
+
## 3. Gang of Four (GoF) 23 Patterns Master Catalog
|
|
40
40
|
|
|
41
|
-
|
|
41
|
+
### A. Creational Patterns (5 Patterns)
|
|
42
|
+
1. **Factory Method**: Define an interface for creating an object, but let subclasses or factory functions decide which class to instantiate.
|
|
43
|
+
- *Use Case:* Tenant-specific payment gateway instantiation (`StripeAdapter` vs `PayPalAdapter`).
|
|
44
|
+
2. **Abstract Factory**: Provide an interface for creating families of related or dependent objects without specifying concrete classes.
|
|
45
|
+
- *Use Case:* Multi-cloud storage factories creating matching `FileUploader`, `FileDownloader`, and `PresignedUrlGenerator` for S3, GCS, or MinIO.
|
|
46
|
+
3. **Builder**: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.
|
|
47
|
+
- *Use Case:* Fluent query builders, complex report generators, or test data builders (`OrderBuilder.withItems(...).build()`).
|
|
48
|
+
4. **Prototype**: Specify the kinds of objects to create using a prototypical instance, creating new objects by cloning this prototype.
|
|
49
|
+
- *Use Case:* Fast cloning of default tenant configuration templates without querying storage.
|
|
50
|
+
5. **Singleton (DI-Scoped)**: Ensure a class has only one instance and provide a global point of access.
|
|
51
|
+
- *Rule:* Avoid global static singletons (causes test coupling). Enforce singleton lifecycle strictly through Dependency Injection (DI) containers.
|
|
52
|
+
|
|
53
|
+
### B. Structural Patterns (7 Patterns)
|
|
54
|
+
6. **Adapter (Mandatory)**: Convert the interface of a class into another interface clients expect.
|
|
55
|
+
- *Use Case:* Wrapping 3rd-party SDKs, storage drivers, and external network clients in application-owned interfaces. *Rule: Only mock types you own.*
|
|
56
|
+
7. **Bridge**: Decouple an abstraction from its implementation so the two can vary independently.
|
|
57
|
+
- *Use Case:* Decoupling notification abstractions (`UrgentNotification`, `BatchNotification`) from delivery channels (`EmailChannel`, `SlackChannel`).
|
|
58
|
+
8. **Composite**: Compose objects into tree structures to represent part-whole hierarchies.
|
|
59
|
+
- *Use Case:* Nested RBAC permission trees or hierarchical menu navigation systems.
|
|
60
|
+
9. **Decorator**: Attach additional responsibilities to an object dynamically as a flexible alternative to subclassing.
|
|
61
|
+
- *Use Case:* Wrapping repository methods with distributed caching, OpenTelemetry tracing, or metrics logging.
|
|
62
|
+
10. **Facade**: Provide a unified, high-level interface to a complex set of interfaces in a subsystem.
|
|
63
|
+
- *Use Case:* Checkout facade orchestrating inventory verification, payment processing, invoice generation, and email notification.
|
|
64
|
+
11. **Flyweight**: Use sharing to support large numbers of fine-grained objects efficiently.
|
|
65
|
+
- *Use Case:* In-memory sharing of immutable tenant metadata and shared system role permission definitions.
|
|
66
|
+
12. **Proxy**: Provide a surrogate or placeholder for another object to control access to it.
|
|
67
|
+
- *Use Case:* Lazy-loading database relations, virtual proxies for large assets, or tenant-scoped connection proxies.
|
|
68
|
+
|
|
69
|
+
### C. Behavioral Patterns (11 Patterns)
|
|
70
|
+
13. **Chain of Responsibility**: Pass requests along a chain of handlers until a handler processes it or the chain ends.
|
|
71
|
+
- *Use Case:* Inbound gateway middleware pipelines (Authentication ➔ TenantResolution ➔ RateLimiting ➔ Controller).
|
|
72
|
+
14. **Command**: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo.
|
|
73
|
+
- *Use Case:* Asynchronous job queues, transactional audit commands, CQRS command handlers.
|
|
74
|
+
15. **Interpreter**: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences.
|
|
75
|
+
- *Use Case:* Custom search filter parsers (`status:active AND tier:pro`) or rule engine expression evaluation.
|
|
76
|
+
16. **Iterator**: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
|
|
77
|
+
- *Use Case:* Async iterators streaming large database cursor result sets or reading multi-part upload chunks.
|
|
78
|
+
17. **Mediator**: Define an object that encapsulates how a set of objects interact, preventing direct coupling between them.
|
|
79
|
+
- *Use Case:* In-memory event dispatcher mediating communication between decoupled domain services.
|
|
80
|
+
18. **Memento**: Without violating encapsulation, capture and externalize an object's internal state so the object can be restored to this state later.
|
|
81
|
+
- *Use Case:* Audit trail snapshots recording `before` and `after` states for rollback capabilities.
|
|
82
|
+
19. **Observer**: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.
|
|
83
|
+
- *Use Case:* Domain Event buses (`UserRegisteredEvent`, `PaymentFailedEvent`) invoking multiple listeners.
|
|
84
|
+
20. **State**: Allow an object to alter its behavior when its internal state changes, appearing as if it changed its class.
|
|
85
|
+
- *Use Case:* Subscription lifecycles (`TrialState` ➔ `ActiveState` ➔ `PastDueState` ➔ `CanceledState`) where allowed actions change dynamically.
|
|
86
|
+
21. **Strategy**: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
|
|
87
|
+
- *Use Case:* Dynamic fee calculation, tenant-specific password complexity policies, or feature flag evaluation providers.
|
|
88
|
+
22. **Template Method**: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
|
|
89
|
+
- *Use Case:* Base ETL or data import pipelines with fixed steps (Extract ➔ Validate ➔ Transform ➔ Persist) where subclasses define validation.
|
|
90
|
+
23. **Visitor**: Represent an operation to be performed on the elements of an object structure, defining a new operation without changing the classes of the elements.
|
|
91
|
+
- *Use Case:* Document export engines traversing an AST of content blocks to generate HTML, Markdown, or PDF.
|
|
@@ -27,6 +27,12 @@ Software engineering fails when teams jump directly into the **Solution Space**
|
|
|
27
27
|
- **The Solution Space (The Accidents):** Concerns *how* the system is realized. Runtimes, programming languages (C, Rust, TS, Go, Java), and storage engines are **emergent outputs** derived strictly from Problem Space constraints.
|
|
28
28
|
- **The Golden Hammer Anti-Pattern:** Selecting tools (e.g., "Let's use Next.js and PostgreSQL") before mapping problem constraints forces the domain to fit the tool, creating massive accidental complexity.
|
|
29
29
|
|
|
30
|
+
### Strategic Subdomain & Capability Mapping
|
|
31
|
+
Structure enterprise business capabilities into three distinct tiers:
|
|
32
|
+
1. **Core Subdomain / Capabilities**: Proprietary value drivers and business differentiators (e.g. specialized workflow engines, dynamic pricing algorithms). Allocate 80% of architectural effort here.
|
|
33
|
+
2. **Supporting Subdomain / Capabilities**: Business functions specific to the domain but not competitive differentiators (e.g. order tracking, invoice rendering).
|
|
34
|
+
3. **Generic Subdomain / Capabilities**: Standard commoditized software (e.g. authentication, audit logging, email transport). Rely exclusively on standard open-source libraries.
|
|
35
|
+
|
|
30
36
|
---
|
|
31
37
|
|
|
32
38
|
## 2. Domain-Code Language Agreement
|
|
@@ -89,6 +95,24 @@ Acceptance criteria must be written strictly in Ubiquitous Language, serving as
|
|
|
89
95
|
|
|
90
96
|
1. **Entities**: Objects defined by identity that persists across state changes (e.g. `User`, `Order`, `Invoice`).
|
|
91
97
|
2. **Value Objects**: Immutable objects defined strictly by their attributes with no identity (e.g. `Money`, `DateRange`, `EmailAddress`).
|
|
92
|
-
3. **Aggregates & Aggregate Roots**: Clusters of domain objects treated as a single transactional consistency boundary. All mutations must pass through explicit methods on the Aggregate Root
|
|
98
|
+
3. **Aggregates & Aggregate Roots**: Clusters of domain objects treated as a single transactional consistency boundary. All mutations must pass through explicit methods on the Aggregate Root that assert invariants before committing state:
|
|
99
|
+
- **Zero Anemic Domain Models**: Domain entities must encapsulate state and validation logic. Never expose public setters that allow outside code to corrupt business rules.
|
|
100
|
+
- **Aggregate Root Gatekeeper Pattern**:
|
|
101
|
+
```typescript
|
|
102
|
+
export class OrderAggregate {
|
|
103
|
+
private constructor(private order: OrderState) {}
|
|
104
|
+
|
|
105
|
+
submit(): Result<void, DomainError> {
|
|
106
|
+
if (this.order.items.length === 0) {
|
|
107
|
+
return err(new DomainError('Cannot submit empty order'));
|
|
108
|
+
}
|
|
109
|
+
if (this.order.status !== 'DRAFT') {
|
|
110
|
+
return err(new DomainError('Order already submitted'));
|
|
111
|
+
}
|
|
112
|
+
this.order.status = 'SUBMITTED';
|
|
113
|
+
return ok(undefined);
|
|
114
|
+
}
|
|
115
|
+
}
|
|
116
|
+
```
|
|
93
117
|
4. **Anti-Corruption Layer (ACL)**: When integrating with third-party APIs or legacy systems that use different terminology, translate external payloads into the internal Ubiquitous Language at the boundary adapter before they enter the domain core.
|
|
94
118
|
5. **Cross-Aggregate Coordination in Use Cases**: While an Aggregate Root guards its own internal invariants, business operations frequently span multiple aggregates (e.g. reserving an inventory item for an agreement). Application use cases or orchestrators must coordinate aggregate transitions atomically: asserting resource availability prior to state change, transitioning the constrained entity (e.g. `ALLOCATED`), and restoring state (`AVAILABLE`) upon cancellation, avoiding double-allocation race conditions without coupling aggregates directly.
|
package/lib/index.d.ts
CHANGED
|
@@ -31,30 +31,6 @@ export interface ScaffoldResult {
|
|
|
31
31
|
actions: string[];
|
|
32
32
|
}
|
|
33
33
|
|
|
34
|
-
export interface LogChangeOptions {
|
|
35
|
-
/** Short title describing the architectural change */
|
|
36
|
-
title: string;
|
|
37
|
-
/** Category of change (Architecture | Rule | Skill | Infrastructure | CLI | Knowledge Hub) */
|
|
38
|
-
category?: string;
|
|
39
|
-
/** Target file(s) affected by the change */
|
|
40
|
-
targetFiles?: string;
|
|
41
|
-
/** Architectural rationale for upstream template incorporation */
|
|
42
|
-
rationale?: string;
|
|
43
|
-
/** Detailed description of the change */
|
|
44
|
-
description?: string;
|
|
45
|
-
/** Working directory containing changes.md (default: process.cwd()) */
|
|
46
|
-
targetDir?: string;
|
|
47
|
-
}
|
|
48
|
-
|
|
49
|
-
export interface LogChangeResult {
|
|
50
|
-
/** Whether the log entry was successfully recorded */
|
|
51
|
-
success: boolean;
|
|
52
|
-
/** Absolute path to changes.md */
|
|
53
|
-
filePath: string;
|
|
54
|
-
/** Markdown entry text that was appended */
|
|
55
|
-
entry: string;
|
|
56
|
-
}
|
|
57
|
-
|
|
58
34
|
export interface ValidateTargetOptions {
|
|
59
35
|
/** Custom template root directory */
|
|
60
36
|
templateDir?: string;
|
|
@@ -79,11 +55,6 @@ export interface CopyTemplateOptions {
|
|
|
79
55
|
*/
|
|
80
56
|
export function scaffold(options?: ScaffoldOptions): ScaffoldResult;
|
|
81
57
|
|
|
82
|
-
/**
|
|
83
|
-
* Appends a standardized upstream change entry to changes.md.
|
|
84
|
-
*/
|
|
85
|
-
export function logChange(options: LogChangeOptions): LogChangeResult;
|
|
86
|
-
|
|
87
58
|
/**
|
|
88
59
|
* Validates the target directory to ensure it is suitable for scaffolding.
|
|
89
60
|
*/
|
|
@@ -139,7 +110,6 @@ export const TEMPLATE_ITEMS: readonly string[];
|
|
|
139
110
|
|
|
140
111
|
declare const defaultExport: {
|
|
141
112
|
scaffold: typeof scaffold;
|
|
142
|
-
logChange: typeof logChange;
|
|
143
113
|
validateTarget: typeof validateTarget;
|
|
144
114
|
copyTemplate: typeof copyTemplate;
|
|
145
115
|
ensureSymlink: typeof ensureSymlink;
|
package/lib/scaffold.js
CHANGED
|
@@ -7,7 +7,6 @@ const cp = require('node:child_process');
|
|
|
7
7
|
const TEMPLATE_ITEMS = [
|
|
8
8
|
'AGENTS.md',
|
|
9
9
|
'memory.md',
|
|
10
|
-
'changes.md',
|
|
11
10
|
'README.md',
|
|
12
11
|
'docs',
|
|
13
12
|
'.agents',
|
|
@@ -227,53 +226,8 @@ function scaffold(options = {}) {
|
|
|
227
226
|
};
|
|
228
227
|
}
|
|
229
228
|
|
|
230
|
-
/**
|
|
231
|
-
* Appends a standardized upstream change entry to changes.md.
|
|
232
|
-
*/
|
|
233
|
-
function logChange(options = {}) {
|
|
234
|
-
const {
|
|
235
|
-
title,
|
|
236
|
-
category = 'Architecture',
|
|
237
|
-
targetFiles = 'docs/rules/',
|
|
238
|
-
rationale = 'Generic architectural enhancement',
|
|
239
|
-
description = '',
|
|
240
|
-
targetDir = process.cwd()
|
|
241
|
-
} = options;
|
|
242
|
-
|
|
243
|
-
if (!title || typeof title !== 'string' || !title.trim()) {
|
|
244
|
-
throw new Error('A change title is required to log an upstream change.');
|
|
245
|
-
}
|
|
246
|
-
|
|
247
|
-
const cleanTitle = title.trim();
|
|
248
|
-
const changesFilePath = path.join(path.resolve(targetDir), 'changes.md');
|
|
249
|
-
const today = new Date().toISOString().slice(0, 10);
|
|
250
|
-
|
|
251
|
-
const entry = `\n### [${today}] ${cleanTitle}\n` +
|
|
252
|
-
`- **Category:** ${category}\n` +
|
|
253
|
-
`- **Target File(s):** ${targetFiles}\n` +
|
|
254
|
-
`- **Rationale:** ${rationale}\n` +
|
|
255
|
-
`- **Description:** ${description || cleanTitle}\n` +
|
|
256
|
-
`- **Domain Filter Verification:** Verified 100% generic; purged of all project-specific business entities and models.\n`;
|
|
257
|
-
|
|
258
|
-
if (fs.existsSync(changesFilePath)) {
|
|
259
|
-
fs.appendFileSync(changesFilePath, entry, 'utf-8');
|
|
260
|
-
} else {
|
|
261
|
-
const initialHeader = `# Upstream Changes Ledger (\`changes.md\`)\n\n` +
|
|
262
|
-
`> **Core Purpose:** Record candidate improvements, generic architectural updates, defect post-mortems, and rule enhancements discovered in this workspace that should be incorporated into the upstream \`azcodr\` baseline template.\n\n` +
|
|
263
|
-
`---\n\n## Upstream Changes Log\n`;
|
|
264
|
-
fs.writeFileSync(changesFilePath, initialHeader + entry, 'utf-8');
|
|
265
|
-
}
|
|
266
|
-
|
|
267
|
-
return {
|
|
268
|
-
success: true,
|
|
269
|
-
filePath: changesFilePath,
|
|
270
|
-
entry
|
|
271
|
-
};
|
|
272
|
-
}
|
|
273
|
-
|
|
274
229
|
module.exports = {
|
|
275
230
|
scaffold,
|
|
276
|
-
logChange,
|
|
277
231
|
validateTarget,
|
|
278
232
|
copyTemplate,
|
|
279
233
|
ensureSymlink,
|
package/memory.md
CHANGED
|
@@ -6,10 +6,8 @@
|
|
|
6
6
|
|
|
7
7
|
## 1. Quick Navigation & Knowledge Repositories
|
|
8
8
|
|
|
9
|
-
- 🗺️ **[System Knowledge Graph](./docs/knowledge/knowledge_graph.md)**: Architectural subsystems, Mermaid topologies, entity relationships, and fast-lookup matrices.
|
|
10
9
|
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative, single-name domain vocabulary contract.
|
|
11
10
|
- 📜 **[Lightweight ADR Master Index](#adr-master-index)**: Summary of all architectural decisions and direct links to governing rules.
|
|
12
|
-
- 📝 **[Upstream Changes Ledger](./changes.md)**: Ledger of candidate improvements and generic patterns for upstream azcodr.
|
|
13
11
|
|
|
14
12
|
---
|
|
15
13
|
|
|
@@ -33,6 +31,10 @@
|
|
|
33
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) |
|
|
34
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) |
|
|
35
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), [`continuous_learning.md`](./docs/rules/continuous_learning.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), [`workspace_isolation.md`](./docs/rules/workspace_isolation.md) |
|
|
37
|
+
|
|
36
38
|
|
|
37
39
|
---
|
|
38
40
|
|
|
@@ -126,3 +128,28 @@
|
|
|
126
128
|
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.
|
|
127
129
|
- **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).
|
|
128
130
|
|
|
131
|
+
#### ADR-016: Elimination of Static Markdown Knowledge Graph in Favor of Code-as-Truth & Living Glossary
|
|
132
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
133
|
+
- **Context:** Template repositories often maintain static markdown files containing Mermaid diagrams, ERDs, and component topologies (`docs/knowledge/knowledge_graph.md`). In practice, these static artifacts suffer from rapid maintenance drift, violate the Problem-First mandate by pre-fabricating multi-tenant web backend models before the user defines their project, duplicate existing domain rules and memory records, and become stale tokens consumed on every context load.
|
|
134
|
+
- **Decision:** Permanently delete `docs/knowledge/knowledge_graph.md`. Treat executable code, strict type definitions, and versioned database migrations as the sole source of truth for architectural topologies. Retain `docs/knowledge/ubiquitous_language.md` as the lightweight, living domain vocabulary contract.
|
|
135
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`clean_code.md`](./docs/rules/clean_code.md), [`continuous_learning.md`](./docs/rules/continuous_learning.md), [`memory.md`](./memory.md).
|
|
136
|
+
|
|
137
|
+
#### ADR-017: Progressive Rules Consolidation (DDD & GoF Design Patterns)
|
|
138
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
139
|
+
- **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.
|
|
140
|
+
- **Decision:**
|
|
141
|
+
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`.
|
|
142
|
+
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`.
|
|
143
|
+
3. Streamline rule catalog across `AGENTS.md` and `README.md` to 45 lean, single-responsibility, non-overlapping rules.
|
|
144
|
+
- **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).
|
|
145
|
+
|
|
146
|
+
#### ADR-018: Elimination of Upstream Changes Ledger and Upstream Sync Tooling
|
|
147
|
+
- **Date:** 2026-09-25 | **Status:** ACCEPTED
|
|
148
|
+
- **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.
|
|
149
|
+
- **Decision:**
|
|
150
|
+
1. Permanently delete `changes.md` and retire `docs/rules/upstream_synchronization.md`.
|
|
151
|
+
2. Remove `changes.md` from scaffolded `TEMPLATE_ITEMS` and package manifests.
|
|
152
|
+
3. Purge `logChange` functions, types, and CLI subcommands, restoring `azcodr` CLI as a clean, single-purpose project bootstrapper.
|
|
153
|
+
4. Standardize exclusively on Git commits for historical revision logs and `memory.md` for architectural decision records.
|
|
154
|
+
- **Enforced In:** [`AGENTS.md`](./AGENTS.md), [`README.md`](./README.md), [`lib/scaffold.js`](./lib/scaffold.js), [`bin/azcodr.js`](./bin/azcodr.js), [`memory.md`](./memory.md).
|
|
155
|
+
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "azcodr",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.3.0",
|
|
4
4
|
"description": "Enterprise Architecture & Agentic Engineering Starter Template",
|
|
5
5
|
"bin": {
|
|
6
6
|
"azcodr": "bin/azcodr.js"
|
|
@@ -19,7 +19,6 @@
|
|
|
19
19
|
"lib",
|
|
20
20
|
"AGENTS.md",
|
|
21
21
|
"memory.md",
|
|
22
|
-
"changes.md",
|
|
23
22
|
"README.md",
|
|
24
23
|
"docs",
|
|
25
24
|
".agents",
|
package/changes.md
DELETED
|
@@ -1,62 +0,0 @@
|
|
|
1
|
-
# Upstream Changes Ledger (`changes.md`)
|
|
2
|
-
|
|
3
|
-
> **Core Purpose:** Record candidate improvements, generic architectural updates, defect post-mortems, and rule enhancements discovered in this workspace that should be incorporated into the upstream `azcodr` baseline template. No automated git merging or external repo mutation is performed.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Specification & Protocol
|
|
8
|
-
|
|
9
|
-
When an AI agent or engineer discovers a generic architectural improvement, bug fix, or rule refinement during project development, append an entry below using this atomic format:
|
|
10
|
-
|
|
11
|
-
```markdown
|
|
12
|
-
### [YYYY-MM-DD] <Title of Change>
|
|
13
|
-
- **Category:** Rule | Skill | Infrastructure | CLI | Knowledge Hub
|
|
14
|
-
- **Target File(s):** `docs/rules/...`, `.agents/skills/...`, etc.
|
|
15
|
-
- **Rationale:** Why this improvement is necessary or valuable across all enterprise projects.
|
|
16
|
-
- **Description:** Concise summary of the mutation or invariant added.
|
|
17
|
-
- **Domain Filter Verification:** Verified 100% generic; purged of all project-specific business entities and models.
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## 2. Upstream Changes Log
|
|
23
|
-
|
|
24
|
-
### [2026-09-25] Initialized npx Scaffolder CLI and npm Package
|
|
25
|
-
- **Category:** CLI & Infrastructure
|
|
26
|
-
- **Target File(s):** `bin/azcodr.js`, `lib/scaffold.js`, `package.json`, `tests/`
|
|
27
|
-
- **Rationale:** Eliminate manual `cp -r` copying; enable anyone to pull and scaffold the azcodr architecture template via `npx azcodr`.
|
|
28
|
-
- **Description:** Implemented zero-dependency Node.js CLI executable with Outside-In TDD, harness parity symlink generation, script execution bit setting, and full test suite passing with 100% agentic config validation.
|
|
29
|
-
- **Domain Filter Verification:** Verified 100% generic; no project-specific business models.
|
|
30
|
-
|
|
31
|
-
### [2026-09-25] Streamlined Upstream Sync Protocol to changes.md Ledger
|
|
32
|
-
- **Category:** Rule & Process
|
|
33
|
-
- **Target File(s):** `docs/rules/upstream_synchronization.md`, `changes.md`, `AGENTS.md`
|
|
34
|
-
- **Rationale:** Remove fragile git repo resolution and merge scripts; replace with atomic change logging in `changes.md`.
|
|
35
|
-
- **Description:** Retired `merge-ai` skill and removed machine-specific hardcoded paths. All upstream improvements are now recorded atomically in `changes.md`.
|
|
36
|
-
- **Domain Filter Verification:** Verified 100% generic.
|
|
37
|
-
|
|
38
|
-
### [2026-09-25] Harden CLI, achieve 100% test coverage gates, add multi-OS CI workflow, and TypeScript declarations
|
|
39
|
-
- **Category:** CLI
|
|
40
|
-
- **Target File(s):** bin/azcodr.js, lib/scaffold.js, lib/index.d.ts, .github/workflows/ci.yml
|
|
41
|
-
- **Rationale:** Fulfill 100.00% test coverage mandate, cross-platform CI matrix, and library type safety
|
|
42
|
-
- **Description:** Remediate gap assessment findings: add --dry-run and --silent flags, enforce 100.00% line/branch/function coverage gates, add GitHub Actions CI matrix across Node 18/20/22/24 and Linux/macOS/Windows, add .editorconfig template item, and export ambient TypeScript typings.
|
|
43
|
-
- **Domain Filter Verification:** Verified 100% generic; purged of all project-specific business entities and models.
|
|
44
|
-
|
|
45
|
-
### [2026-09-25] Resolve macOS/Windows Git Case-Collision and Cross-Version CI Matrix Coverage
|
|
46
|
-
- **Category:** Infrastructure & CI
|
|
47
|
-
- **Target File(s):** .gitignore, lib/scaffold.js, scripts/test_coverage.js, validate_agentic_configs.sh
|
|
48
|
-
- **Rationale:** Ensure flawless cross-platform and multi-version Node execution across macOS, Windows, and Linux on Node 18, 20, 22, 24.
|
|
49
|
-
- **Description:** Untracked agents.md from Git to prevent cyclic symlink overwrite on case-insensitive filesystems; hardened ensureSymlink with isSameCaseInsensitiveFile check; added cross-version test coverage runner script; updated npm test runner to use native discovery.
|
|
50
|
-
- **Domain Filter Verification:** Verified 100% generic; purged of all project-specific business entities and models.
|
|
51
|
-
|
|
52
|
-
### [2026-09-25] Problem-First Architecture, Evolutionary Tipping Points, and Incremental Nano-Cycle TDD
|
|
53
|
-
- **Category:** Architecture, Rule & Skill
|
|
54
|
-
- **Target File(s):** `AGENTS.md`, `docs/rules/clean_code.md`, `docs/rules/domain_driven_design.md`, `docs/rules/test_driven_development.md`, `.agents/skills/lets-build/SKILL.md`, `.agents/skills/lets-build/references/architecture_interview_matrix.md`, `.agents/skills/lets-build/scripts/bootstrap_workspace.sh`, `memory.md`
|
|
55
|
-
- **Rationale:** Eliminate tool-first bias ("Solution-in-Search-of-a-Problem"), stop accidental complexity (as seen in `force-dark-light` where Chrome extension received Kubernetes and OpenAPI specs), prevent AI-accelerated architectural drift, and halt the "Test-First Waterfall" batch-test anti-pattern.
|
|
56
|
-
- **Description:**
|
|
57
|
-
1. Enforced Problem Space vs Solution Space decoupling with zero tool bias.
|
|
58
|
-
2. Made scaffolding strictly topology-aware (Web SaaS, Browser Extension, Game/Engine, CLI, Library) with zero speculative bloat.
|
|
59
|
-
3. Codified Evolutionary Architecture, the 5 Architectural Tipping Points, and Kent Beck's "Refactor-Before-Add" protocol.
|
|
60
|
-
4. Codified Uncle Bob's Three Laws of TDD, banned batch-test dumps, and introduced the Incremental Nano-Cycle and Ping-Pong Pair Programming protocol.
|
|
61
|
-
- **Domain Filter Verification:** Verified 100% generic; applicable across any language, stack, and project topology.
|
|
62
|
-
|
|
@@ -1,188 +0,0 @@
|
|
|
1
|
-
# System Knowledge Graph & Architectural Topology
|
|
2
|
-
|
|
3
|
-
> **Core Purpose:** High-density, token-efficient knowledge representation of the workspace architecture, data topologies, and subsystem boundaries, eliminating repetitive discovery prompts.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Universal Hexagonal Architectural Subsystems
|
|
8
|
-
|
|
9
|
-
```mermaid
|
|
10
|
-
flowchart TD
|
|
11
|
-
subgraph Ingress["Client & Primary Ingress Adapters"]
|
|
12
|
-
UI["Multi-Platform Client (Web / Mobile / Desktop SDUI)"]
|
|
13
|
-
Gateway["Ingress Gateway / Envoy (REST / gRPC / SSE)"]
|
|
14
|
-
BrokerIn["Message Consumer (Kafka / NATS / RabbitMQ)"]
|
|
15
|
-
end
|
|
16
|
-
|
|
17
|
-
subgraph Core["Pure Invariant Domain Core (Hexagonal Ports)"]
|
|
18
|
-
direction TB
|
|
19
|
-
TenantContext["Multi-Tenant Context Resolver Port"]
|
|
20
|
-
AuthPort["Authentication & Identity Port"]
|
|
21
|
-
AuthzPort["Authorization & Policy Port"]
|
|
22
|
-
DomainServices["Domain Services & Aggregate Roots"]
|
|
23
|
-
RulePort["Dynamic Rule Engine Port (CEL / Wasm)"]
|
|
24
|
-
WorkflowPort["Workflow Orchestration Port (Temporal / BPMN)"]
|
|
25
|
-
OutboxPort["Transactional Outbox Port"]
|
|
26
|
-
CachePort["Cache & Distributed Lock Port"]
|
|
27
|
-
RepoPort["Universal Repository Port"]
|
|
28
|
-
end
|
|
29
|
-
|
|
30
|
-
subgraph Egress["Secondary / Egress Polyglot Adapters"]
|
|
31
|
-
Storage["Relational & NoSQL Storage (Postgres / MySQL / Cockroach / Mongo)"]
|
|
32
|
-
CacheStore["In-Memory Store (Redis / Valkey / Dragonfly / Memcached)"]
|
|
33
|
-
BrokerOut["Event Streaming (Kafka / NATS / RabbitMQ / CloudEvents)"]
|
|
34
|
-
AuthEngines["Policy-as-Code (OPA Rego / OpenFGA ReBAC / Cerbos)"]
|
|
35
|
-
SMTP["Transactional Email Gateway (SMTP / Providers)"]
|
|
36
|
-
end
|
|
37
|
-
|
|
38
|
-
UI --> Gateway
|
|
39
|
-
Gateway --> TenantContext
|
|
40
|
-
BrokerIn --> DomainServices
|
|
41
|
-
TenantContext --> AuthPort
|
|
42
|
-
AuthPort --> AuthzPort
|
|
43
|
-
AuthzPort --> DomainServices
|
|
44
|
-
DomainServices --> RulePort
|
|
45
|
-
DomainServices --> WorkflowPort
|
|
46
|
-
DomainServices --> OutboxPort
|
|
47
|
-
DomainServices --> CachePort
|
|
48
|
-
DomainServices --> RepoPort
|
|
49
|
-
|
|
50
|
-
RepoPort --> Storage
|
|
51
|
-
OutboxPort --> Storage
|
|
52
|
-
OutboxPort --> BrokerOut
|
|
53
|
-
CachePort --> CacheStore
|
|
54
|
-
AuthzPort --> AuthEngines
|
|
55
|
-
DomainServices --> SMTP
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
---
|
|
59
|
-
|
|
60
|
-
## 2. Multi-Tenant Data Isolation & Schema Graph
|
|
61
|
-
|
|
62
|
-
```mermaid
|
|
63
|
-
erDiagram
|
|
64
|
-
TENANT ||--o{ USER : "owns"
|
|
65
|
-
TENANT ||--o{ ROLE : "defines"
|
|
66
|
-
TENANT ||--o{ TENANT_SCHEMA : "configures"
|
|
67
|
-
TENANT ||--o{ TENANT_ENTITY : "defines"
|
|
68
|
-
TENANT_ENTITY ||--o{ TENANT_RECORD : "stores"
|
|
69
|
-
TENANT ||--o{ OUTBOX_EVENT : "emits"
|
|
70
|
-
TENANT ||--o{ AUDIT_LOG : "records"
|
|
71
|
-
|
|
72
|
-
TENANT {
|
|
73
|
-
uuid id PK
|
|
74
|
-
string slug UK
|
|
75
|
-
string name
|
|
76
|
-
string subscription_tier
|
|
77
|
-
string status
|
|
78
|
-
json theme_tokens
|
|
79
|
-
timestamptz created_at
|
|
80
|
-
}
|
|
81
|
-
|
|
82
|
-
USER {
|
|
83
|
-
uuid id PK
|
|
84
|
-
uuid tenant_id FK
|
|
85
|
-
string email UK
|
|
86
|
-
string password_hash
|
|
87
|
-
boolean mfa_enabled
|
|
88
|
-
timestamptz created_at
|
|
89
|
-
}
|
|
90
|
-
|
|
91
|
-
TENANT_SCHEMA {
|
|
92
|
-
uuid id PK
|
|
93
|
-
uuid tenant_id FK
|
|
94
|
-
string entity_name
|
|
95
|
-
json json_schema
|
|
96
|
-
int version
|
|
97
|
-
}
|
|
98
|
-
|
|
99
|
-
OUTBOX_EVENT {
|
|
100
|
-
uuid id PK
|
|
101
|
-
uuid tenant_id FK
|
|
102
|
-
string aggregate_type
|
|
103
|
-
string aggregate_id
|
|
104
|
-
string event_type
|
|
105
|
-
json payload
|
|
106
|
-
string status
|
|
107
|
-
timestamptz created_at
|
|
108
|
-
}
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
---
|
|
112
|
-
|
|
113
|
-
## 3. Subsystem Fast Lookup Index
|
|
114
|
-
|
|
115
|
-
| Capability | Invariant Contract / Open Standard | Swappable Polyglot Adapters | Governing Rule |
|
|
116
|
-
|---|---|---|---|
|
|
117
|
-
| **Runtime & Language** | Hexagonal Core (Zero Deps) | Polyglot (Go, Rust, Python, Java, TypeScript) | [`clean_code.md`](../rules/clean_code.md) |
|
|
118
|
-
| **Type Safety** | Sound static types & branded primitives | Rust, TypeScript, Go, Python (type hints) | [`typescript.md`](../rules/typescript.md) |
|
|
119
|
-
| **Persistence / DAL** | Abstract Repository & Unit of Work | Atlas / Flyway migrations; SQL & NoSQL drivers | [`database_transactions.md`](../rules/database_transactions.md) |
|
|
120
|
-
| **Tenant Isolation** | 4 Models (AST Interceptor, Schema, DB, Proxy) | SQL AST parser, RLS, multi-pool router, Envoy | [`multitenancy_isolation.md`](../rules/multitenancy_isolation.md) |
|
|
121
|
-
| **Dynamic Schemas** | JSON Schema Draft 2020-12 | Polyglot validators (`valico`, `gojsonschema`, `ajv`) | [`tenant_dynamic_schemas.md`](../rules/tenant_dynamic_schemas.md) |
|
|
122
|
-
| **Authentication** | OIDC, OAuth 2.1, Passkeys (WebAuthn) | PASETO, JWT with JWKS, SPIFFE/SPIRE mTLS | [`authentication.md`](../rules/authentication.md) |
|
|
123
|
-
| **Authorization** | Policy-as-Code & ReBAC | OPA (Rego/Wasm), OpenFGA (Zanzibar), Cerbos | [`authorization.md`](../rules/authorization.md) |
|
|
124
|
-
| **Pluggable Logic** | Common Expression Language (CEL) / Wasm | `cel-go`, `cel-rust`, Extism (Wasm plugins) | [`tenant_pluggable_logic.md`](../rules/tenant_pluggable_logic.md) |
|
|
125
|
-
| **Workflows** | Durable Orchestration & Statecharts | Temporal.io SDKs, Camunda/Zeebe (BPMN 2.0) | [`tenant_pluggable_logic.md`](../rules/tenant_pluggable_logic.md) |
|
|
126
|
-
| **Caching** | Abstract Cache Port with XFetch | Redis, Valkey, Dragonfly, Memcached, Local LRU | [`caching.md`](../rules/caching.md) |
|
|
127
|
-
| **Feature Flags** | OpenFeature Standard | Flipt, Unleash, LaunchDarkly, GoFeatureFlag | [`feature_flags.md`](../rules/feature_flags.md) |
|
|
128
|
-
| **Testing** | Outside-In TDD, BDD & Consumer Contracts | Cucumber/Gherkin, Pact, Schemathesis | [`test_driven_development.md`](../rules/test_driven_development.md) |
|
|
129
|
-
| **Presentation / SDUI** | Declarative JSON SDUI + DTCG Tokens | Web (React/Vue/Svelte), Mobile (Flutter/Native) | [`server_driven_ui.md`](../rules/server_driven_ui.md) |
|
|
130
|
-
| **Transactional Email** | Declarative Email Specs / MJML | SMTP Gateway, Mailpit (Local), SES/Sendgrid | [`transactional_email.md`](../rules/transactional_email.md) |
|
|
131
|
-
| **Event Streaming** | CNCF CloudEvents v1.0.2 | Kafka, NATS JetStream, RabbitMQ, SQS | [`database_transactions.md`](../rules/database_transactions.md) |
|
|
132
|
-
| **Observability** | OpenTelemetry OTLP standard | OTel Collector, Jaeger, Prometheus, OpenSearch | [`cloud_native.md`](../rules/cloud_native.md) |
|
|
133
|
-
|
|
134
|
-
---
|
|
135
|
-
|
|
136
|
-
## 4. Agentic Skill Topology & Composability Matrix
|
|
137
|
-
|
|
138
|
-
```mermaid
|
|
139
|
-
flowchart TD
|
|
140
|
-
subgraph Inputs["Inception & Intent"]
|
|
141
|
-
Req["Stakeholder Feature Request / Mutation"]
|
|
142
|
-
end
|
|
143
|
-
|
|
144
|
-
subgraph Pattern1["Pattern 1: Sequential Pipeline Chaining (Workflows)"]
|
|
145
|
-
direction TB
|
|
146
|
-
SkillRQ["relentless-questioner"]
|
|
147
|
-
SkillPA["product-analyst"]
|
|
148
|
-
SkillTDD["test_driven_development"]
|
|
149
|
-
SkillRefactor["clean-code-refactor"]
|
|
150
|
-
|
|
151
|
-
SkillRQ -->|"Feature Alignment Spec (FAS)"| SkillPA
|
|
152
|
-
SkillPA -->|"INVEST Stories & Gherkin AC"| SkillTDD
|
|
153
|
-
SkillTDD -->|"Working Green Code"| SkillRefactor
|
|
154
|
-
end
|
|
155
|
-
|
|
156
|
-
subgraph Pattern2["Pattern 2: Dynamic Skill Stacking (Contextual Composition)"]
|
|
157
|
-
AgentCore["Primary Agent Session"]
|
|
158
|
-
SkillSec["compliance-audit"]
|
|
159
|
-
SkillArch["agentic-architect"]
|
|
160
|
-
|
|
161
|
-
AgentCore -.->|"Dynamic Load"| SkillSec
|
|
162
|
-
AgentCore -.->|"Dynamic Load"| SkillArch
|
|
163
|
-
end
|
|
164
|
-
|
|
165
|
-
subgraph Pattern3["Pattern 3: Multi-Agent Subagent Delegation (Division of Labor)"]
|
|
166
|
-
Coord["Coordinator Agent"]
|
|
167
|
-
SubA["Subagent A: Compliance Auditor"]
|
|
168
|
-
SubB["Subagent B: Code Refactorer"]
|
|
169
|
-
|
|
170
|
-
Coord -->|"Invoke Task"| SubA
|
|
171
|
-
Coord -->|"Invoke Task"| SubB
|
|
172
|
-
SubA -->|"Audit Findings"| Coord
|
|
173
|
-
SubB -->|"Refactored Units"| Coord
|
|
174
|
-
end
|
|
175
|
-
|
|
176
|
-
Req --> SkillRQ
|
|
177
|
-
```
|
|
178
|
-
|
|
179
|
-
### Many-to-Many Skill Cross-Matrix
|
|
180
|
-
|
|
181
|
-
| Skill Name | Functional Specialty | Applicable Lifecycle Stages | Target Artifacts Produced |
|
|
182
|
-
|---|---|---|---|
|
|
183
|
-
| `relentless-questioner` | Context-aware ambiguity interrogation | Pre-Discovery, Pre-Planning | Feature Alignment Spec (FAS), Invariant List |
|
|
184
|
-
| `product-analyst` | Requirements decomposition & Gherkin | Phase 1: Requirements | INVEST User Stories, Gherkin Scenarios |
|
|
185
|
-
| `lets-build` | Technical infrastructure scaffolding | Initial Bootstrapping only | Package manifests, build configs, `/healthz` |
|
|
186
|
-
| `clean-code-refactor` | Code smell eradication, GoF patterns | Phase 4: TDD Inner Loop | Decoupled classes, small functions (< 30 lines) |
|
|
187
|
-
| `compliance-audit` | Security & compliance verification | Phase 1, Phase 5: DoD | Gitleaks, Semgrep, Trivy, OWASP audit logs |
|
|
188
|
-
| `agentic-architect` | Agent configuration & skill governance | Continuous meta-refinement | Atomic `SKILL.md`, `AGENTS.md`, ADR records |
|
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
# Domain Expertise, Capability Mapping & Business Invariants
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Decompose business domains into distinct capability boundaries, enforce business invariants strictly within Aggregate Roots, and protect living Ubiquitous Language.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Business Capability Mapping
|
|
8
|
-
|
|
9
|
-
Structure enterprise business logic into three distinct capability tiers:
|
|
10
|
-
1. **Core Capabilities**: Proprietary value drivers and differentiators (e.g. specialized tenant workflow engines, dynamic pricing algorithms). Allocate 80% of architectural effort here.
|
|
11
|
-
2. **Supporting Capabilities**: Business functions specific to the domain but not competitive differentiators (e.g. order tracking, invoice rendering).
|
|
12
|
-
3. **Generic Capabilities**: Standard commoditized software (e.g. authentication, audit logging, email transport). Rely exclusively on standard open-source libraries.
|
|
13
|
-
|
|
14
|
-
---
|
|
15
|
-
|
|
16
|
-
## 2. Invariant Protection within Aggregate Roots
|
|
17
|
-
|
|
18
|
-
- **Zero Anemic Domain Models**: Domain entities must encapsulate state and validation. Do not expose public setters that allow outside code to corrupt business rules.
|
|
19
|
-
- **Aggregate Root Gatekeeper**: All mutations that modify entity state or related child entities must pass through explicit methods on the Aggregate Root that assert invariants before committing state:
|
|
20
|
-
```typescript
|
|
21
|
-
export class OrderAggregate {
|
|
22
|
-
private constructor(private order: OrderState) {}
|
|
23
|
-
|
|
24
|
-
submit(): Result<void, DomainError> {
|
|
25
|
-
if (this.order.items.length === 0) {
|
|
26
|
-
return err(new DomainError('Cannot submit empty order'));
|
|
27
|
-
}
|
|
28
|
-
if (this.order.status !== 'DRAFT') {
|
|
29
|
-
return err(new DomainError('Order already submitted'));
|
|
30
|
-
}
|
|
31
|
-
this.order.status = 'SUBMITTED';
|
|
32
|
-
return ok(undefined);
|
|
33
|
-
}
|
|
34
|
-
}
|
|
35
|
-
```
|
|
36
|
-
|
|
37
|
-
---
|
|
38
|
-
|
|
39
|
-
## 3. Living Ubiquitous Language Dictionary
|
|
40
|
-
|
|
41
|
-
- Maintain strict terminology discipline across models, database tables, API schemas, and frontend labels.
|
|
42
|
-
- When domain experts or users establish a term, document it immediately and eliminate all competing synonyms across the codebase.
|
|
@@ -1,70 +0,0 @@
|
|
|
1
|
-
# Gang of Four (GoF) Design Patterns — Universal Enterprise Reference
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Master catalog of all 23 Gang of Four design patterns mapped to real-world domain architectures across OOP and functional polyglot systems.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. Creational Patterns (5 Patterns)
|
|
8
|
-
|
|
9
|
-
Creational patterns abstract the instantiation process, making systems independent of how objects are created and composed.
|
|
10
|
-
|
|
11
|
-
1. **Factory Method**: Define an interface for creating an object, but let subclasses or factory functions decide which class to instantiate.
|
|
12
|
-
- *Use Case:* Tenant-specific payment gateway instantiation (`StripeAdapter` vs `PayPalAdapter`).
|
|
13
|
-
2. **Abstract Factory**: Provide an interface for creating families of related or dependent objects without specifying concrete classes.
|
|
14
|
-
- *Use Case:* Multi-cloud storage factories creating matching `FileUploader`, `FileDownloader`, and `PresignedUrlGenerator` for S3, GCS, or MinIO.
|
|
15
|
-
3. **Builder**: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.
|
|
16
|
-
- *Use Case:* Fluent query builders, complex report generators, or test data builders (`OrderBuilder.withItems(...).build()`).
|
|
17
|
-
4. **Prototype**: Specify the kinds of objects to create using a prototypical instance, creating new objects by cloning this prototype.
|
|
18
|
-
- *Use Case:* Fast cloning of default tenant configuration templates without querying storage.
|
|
19
|
-
5. **Singleton (DI-Scoped)**: Ensure a class has only one instance and provide a global point of access.
|
|
20
|
-
- *Rule:* Avoid global static singletons (causes test coupling). Enforce singleton lifecycle strictly through Dependency Injection (DI) containers.
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## 2. Structural Patterns (7 Patterns)
|
|
25
|
-
|
|
26
|
-
Structural patterns deal with object composition and relationships, ensuring subsystems remain decoupled and flexible.
|
|
27
|
-
|
|
28
|
-
6. **Adapter (Mandatory)**: Convert the interface of a class into another interface clients expect.
|
|
29
|
-
- *Use Case:* Wrapping 3rd-party SDKs, storage drivers, and external network clients in application-owned interfaces. *Rule: Only mock types you own.*
|
|
30
|
-
7. **Bridge**: Decouple an abstraction from its implementation so the two can vary independently.
|
|
31
|
-
- *Use Case:* Decoupling notification abstractions (`UrgentNotification`, `BatchNotification`) from delivery channels (`EmailChannel`, `SlackChannel`).
|
|
32
|
-
8. **Composite**: Compose objects into tree structures to represent part-whole hierarchies.
|
|
33
|
-
- *Use Case:* Nested RBAC permission trees or hierarchical menu navigation systems.
|
|
34
|
-
9. **Decorator**: Attach additional responsibilities to an object dynamically as a flexible alternative to subclassing.
|
|
35
|
-
- *Use Case:* Wrapping repository methods with distributed caching, OpenTelemetry tracing, or metrics logging.
|
|
36
|
-
10. **Facade**: Provide a unified, high-level interface to a complex set of interfaces in a subsystem.
|
|
37
|
-
- *Use Case:* Checkout facade orchestrating inventory verification, payment processing, invoice generation, and email notification.
|
|
38
|
-
11. **Flyweight**: Use sharing to support large numbers of fine-grained objects efficiently.
|
|
39
|
-
- *Use Case:* In-memory sharing of immutable tenant metadata and shared system role permission definitions.
|
|
40
|
-
12. **Proxy**: Provide a surrogate or placeholder for another object to control access to it.
|
|
41
|
-
- *Use Case:* Lazy-loading database relations, virtual proxies for large assets, or tenant-scoped connection proxies.
|
|
42
|
-
|
|
43
|
-
---
|
|
44
|
-
|
|
45
|
-
## 3. Behavioral Patterns (11 Patterns)
|
|
46
|
-
|
|
47
|
-
Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility.
|
|
48
|
-
|
|
49
|
-
13. **Chain of Responsibility**: Pass requests along a chain of handlers until a handler processes it or the chain ends.
|
|
50
|
-
- *Use Case:* Inbound gateway middleware pipelines (Authentication ➔ TenantResolution ➔ RateLimiting ➔ Controller).
|
|
51
|
-
14. **Command**: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo.
|
|
52
|
-
- *Use Case:* Asynchronous job queues, transactional audit commands, CQRS command handlers.
|
|
53
|
-
15. **Interpreter**: Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences.
|
|
54
|
-
- *Use Case:* Custom search filter parsers (`status:active AND tier:pro`) or rule engine expression evaluation.
|
|
55
|
-
16. **Iterator**: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
|
|
56
|
-
- *Use Case:* Async iterators streaming large database cursor result sets or reading multi-part upload chunks.
|
|
57
|
-
17. **Mediator**: Define an object that encapsulates how a set of objects interact, preventing direct coupling between them.
|
|
58
|
-
- *Use Case:* In-memory event dispatcher mediating communication between decoupled domain services.
|
|
59
|
-
18. **Memento**: Without violating encapsulation, capture and externalize an object's internal state so the object can be restored to this state later.
|
|
60
|
-
- *Use Case:* Audit trail snapshots recording `before` and `after` states for rollback capabilities.
|
|
61
|
-
19. **Observer**: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified automatically.
|
|
62
|
-
- *Use Case:* Domain Event buses (`UserRegisteredEvent`, `PaymentFailedEvent`) invoking multiple listeners.
|
|
63
|
-
20. **State**: Allow an object to alter its behavior when its internal state changes, appearing as if it changed its class.
|
|
64
|
-
- *Use Case:* Subscription lifecycles (`TrialState` ➔ `ActiveState` ➔ `PastDueState` ➔ `CanceledState`) where allowed actions change dynamically.
|
|
65
|
-
21. **Strategy**: Define a family of algorithms, encapsulate each one, and make them interchangeable at runtime.
|
|
66
|
-
- *Use Case:* Dynamic fee calculation, tenant-specific password complexity policies, or feature flag evaluation providers.
|
|
67
|
-
22. **Template Method**: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.
|
|
68
|
-
- *Use Case:* Base ETL or data import pipelines with fixed steps (Extract ➔ Validate ➔ Transform ➔ Persist) where subclasses define validation.
|
|
69
|
-
23. **Visitor**: Represent an operation to be performed on the elements of an object structure, defining a new operation without changing the classes of the elements.
|
|
70
|
-
- *Use Case:* Document export engines traversing an AST of content blocks to generate HTML, Markdown, or PDF.
|
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
# Upstream Baseline Synchronization & changes.md Ledger
|
|
2
|
-
|
|
3
|
-
> **Core Mandate:** Upstream template/baseline workspaces (`azcodr`) must remain strictly untouched during project development. When generic architectural improvements, rule refinements, or post-mortems are identified, record them solely into the `changes.md` ledger with zero automated repo merging or baseline contamination.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 1. The Baseline-Project Decoupling Principle
|
|
8
|
-
|
|
9
|
-
Workspaces operate under a clean, decoupled flow:
|
|
10
|
-
|
|
11
|
-
```
|
|
12
|
-
[Upstream Generic Baseline: azcodr]
|
|
13
|
-
│
|
|
14
|
-
▼ (Scaffolded via npx azcodr)
|
|
15
|
-
[Derived Project Workspace: my-app / others]
|
|
16
|
-
│
|
|
17
|
-
│ (Accumulates project code, specificities, and institutional lessons)
|
|
18
|
-
│
|
|
19
|
-
▼ (Record reusable improvements)
|
|
20
|
-
[Upstream Changes Ledger: changes.md]
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
- **Pristine Upstream Mandate:** Never edit, commit, or attempt automated git merges to an upstream baseline repository during routine project development, feature implementation, or bug fixes.
|
|
24
|
-
- **Ledger-Only Synchronization:** When generic architectural discoveries or defect post-mortems occur, document them cleanly in `changes.md` at the workspace root. No automated merge AI or remote repo synchronization is executed.
|
|
25
|
-
|
|
26
|
-
---
|
|
27
|
-
|
|
28
|
-
## 2. Zero-Contamination Invariant (Generic vs. Specific)
|
|
29
|
-
|
|
30
|
-
When logging proposed changes into `changes.md`, enforce strict domain filtering:
|
|
31
|
-
|
|
32
|
-
| Element Category | Keep in Specific Project Workspace | Allow in changes.md for Upstream (`azcodr`) |
|
|
33
|
-
|---|---|---|
|
|
34
|
-
| **Domain Entities** | Concrete business models (`Order`, `Customer`, `Invoice`, etc.) | Abstract archetypes (`Entity`, `Aggregate`, `ValueObject`, `Resource`) |
|
|
35
|
-
| **Tech Stack / Adapters** | Concrete choices (Prisma, SQLite dev, PostgreSQL prod, Vite React) | Hexagonal Ports, abstract repository contracts, polyglot adapter guidance |
|
|
36
|
-
| **Architectural Rules** | Specific entity validation, specific route paths | Universal invariants (5-Phase Agile Lifecycle, SemVer trigger matrix, FK dropdowns) |
|
|
37
|
-
| **ADRs** | Stack decisions (`ADR-006: Target Tech Stack for Project`) | Generic architecture patterns (`ADR-007` to `ADR-010`) |
|
|
38
|
-
| **Test Suites** | Concrete domain tests (`order_domain.test.ts`, domain-specific suites) | Boundary smoke test pattern (`scripts/smoke_test.sh`), 100% coverage gate |
|
|
39
|
-
|
|
40
|
-
---
|
|
41
|
-
|
|
42
|
-
## 3. Atomic changes.md Entry Protocol
|
|
43
|
-
|
|
44
|
-
Every upstream-bound proposal logged to `changes.md` must follow the standardized format:
|
|
45
|
-
|
|
46
|
-
```markdown
|
|
47
|
-
### [YYYY-MM-DD] <Title of Change>
|
|
48
|
-
- **Category:** Rule | Skill | Infrastructure | CLI | Knowledge Hub
|
|
49
|
-
- **Target File(s):** `docs/rules/...`, `.agents/skills/...`, etc.
|
|
50
|
-
- **Rationale:** Why this improvement is necessary or valuable across all enterprise projects.
|
|
51
|
-
- **Description:** Concise summary of the mutation or invariant added.
|
|
52
|
-
- **Domain Filter Verification:** Verified 100% generic; purged of all project-specific business entities and models.
|
|
53
|
-
```
|