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.
@@ -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/ # System knowledge graph, issue log, DO's/DONT's
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, Facade, Strategy, and Result `<T, E>` pattern. |
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, Value Objects, Aggregates. |
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/`](./docs/knowledge/knowledge_graph.md) for system topologies and domain glossaries.
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/ # 47 atomic single-responsibility domain 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 47 atomic, single-responsibility domain rules. Read on demand to prevent prompt context bloat:
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, Facade, Strategy, and Result `<T, E>` pattern. |
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 Space vs Solution Space, Ubiquitous Language, Bounded Contexts, Aggregates. |
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, logChange, getTemplateDir } = require('../lib/scaffold.js');
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
- Scaffold Options:
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
- | **Organization** | The top-level administrative and multi-tenant isolation container. | Multi-Tenancy & Identity | Account, Company, Workspace, TenantGroup | `Organization`, `organizationId`, `organizations` table |
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
- For reference implementations of all 23 Gang of Four patterns across OOP and functional paradigms, consult [docs/rules/gof_design_patterns_reference.md](./gof_design_patterns_reference.md).
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.2.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
- ```