azcodr 1.1.0 → 1.2.1
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/SKILL.md +71 -78
- package/.agents/skills/lets-build/references/architecture_interview_matrix.md +78 -157
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +75 -35
- package/AGENTS.md +12 -10
- package/README.md +40 -50
- package/changes.md +12 -0
- package/docs/rules/api_versioning.md +0 -15
- package/docs/rules/clean_code.md +37 -0
- package/docs/rules/continuous_learning.md +14 -13
- package/docs/rules/database_integrity.md +9 -17
- package/docs/rules/design_patterns.md +1 -0
- package/docs/rules/domain_driven_design.md +31 -21
- package/docs/rules/error_handling.md +14 -1
- package/docs/rules/multitenancy_isolation.md +2 -0
- package/docs/rules/product_ownership.md +0 -18
- package/docs/rules/project_management.md +0 -17
- package/docs/rules/react.md +4 -14
- package/docs/rules/requirements_engineering.md +0 -17
- package/docs/rules/rest_api_conventions.md +0 -16
- package/docs/rules/test_driven_development.md +42 -20
- package/docs/rules/transactional_email.md +11 -4
- package/docs/rules/ui_ux_architecture.md +5 -26
- package/docs/rules/upstream_synchronization.md +0 -15
- package/docs/rules/workflow_state_machines.md +0 -18
- package/memory.md +85 -219
- package/package.json +2 -2
- package/docs/knowledge/dos_and_donts.md +0 -540
- package/docs/knowledge/issue_log.md +0 -25
- package/docs/knowledge/lessons_learned.md +0 -107
|
@@ -1,52 +1,84 @@
|
|
|
1
1
|
#!/usr/bin/env bash
|
|
2
2
|
# ==============================================================================
|
|
3
3
|
# bootstrap_workspace.sh
|
|
4
|
-
# Deterministic Scaffolder
|
|
4
|
+
# Topology-Aware Deterministic Scaffolder (Strict YAGNI, Zero Speculative Bloat)
|
|
5
5
|
# ==============================================================================
|
|
6
6
|
|
|
7
7
|
set -euo pipefail
|
|
8
8
|
|
|
9
9
|
WORKSPACE_ROOT="${1:-$(pwd)}"
|
|
10
|
-
|
|
10
|
+
TOPOLOGY="${2:-backend}"
|
|
11
|
+
LANGUAGE="${3:-generic}"
|
|
11
12
|
|
|
12
|
-
echo "🚀 Initializing
|
|
13
|
+
echo "🚀 Initializing Topology-Aware Workspace in: ${WORKSPACE_ROOT}"
|
|
14
|
+
echo "🏗️ Target Topology: ${TOPOLOGY}"
|
|
13
15
|
echo "📦 Target Language Profile: ${LANGUAGE}"
|
|
14
16
|
echo "--------------------------------------------------------------"
|
|
15
17
|
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
20
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
21
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
18
|
+
case "${TOPOLOGY}" in
|
|
19
|
+
extension)
|
|
20
|
+
echo "1. Scaffolding Browser Extension Source Tree (src/)..."
|
|
21
|
+
mkdir -p "${WORKSPACE_ROOT}/src/background"
|
|
22
|
+
mkdir -p "${WORKSPACE_ROOT}/src/content"
|
|
23
|
+
mkdir -p "${WORKSPACE_ROOT}/src/popup"
|
|
24
|
+
mkdir -p "${WORKSPACE_ROOT}/src/shared"
|
|
25
|
+
mkdir -p "${WORKSPACE_ROOT}/public"
|
|
26
|
+
|
|
27
|
+
echo "2. Scaffolding Extension Test Suites (tests/)..."
|
|
28
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/unit"
|
|
29
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/e2e"
|
|
30
|
+
;;
|
|
22
31
|
|
|
23
|
-
|
|
24
|
-
echo "
|
|
25
|
-
mkdir -p "${WORKSPACE_ROOT}/src/
|
|
26
|
-
mkdir -p "${WORKSPACE_ROOT}/src/
|
|
27
|
-
mkdir -p "${WORKSPACE_ROOT}/src/
|
|
28
|
-
mkdir -p "${WORKSPACE_ROOT}/src/
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
32
|
+
game|engine)
|
|
33
|
+
echo "1. Scaffolding Game/Engine Source Tree (src/)..."
|
|
34
|
+
mkdir -p "${WORKSPACE_ROOT}/src/core"
|
|
35
|
+
mkdir -p "${WORKSPACE_ROOT}/src/ecs"
|
|
36
|
+
mkdir -p "${WORKSPACE_ROOT}/src/renderer"
|
|
37
|
+
mkdir -p "${WORKSPACE_ROOT}/src/assets"
|
|
38
|
+
|
|
39
|
+
echo "2. Scaffolding Game/Engine Test Suites (tests/)..."
|
|
40
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/unit"
|
|
41
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/benchmarks"
|
|
42
|
+
;;
|
|
32
43
|
|
|
33
|
-
|
|
34
|
-
echo "
|
|
35
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
36
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
37
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
38
|
-
|
|
44
|
+
cli)
|
|
45
|
+
echo "1. Scaffolding CLI Source Tree (src/)..."
|
|
46
|
+
mkdir -p "${WORKSPACE_ROOT}/src/cmd"
|
|
47
|
+
mkdir -p "${WORKSPACE_ROOT}/src/core"
|
|
48
|
+
mkdir -p "${WORKSPACE_ROOT}/src/io"
|
|
49
|
+
|
|
50
|
+
echo "2. Scaffolding CLI Test Suites (tests/)..."
|
|
51
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/unit"
|
|
52
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/integration"
|
|
53
|
+
;;
|
|
39
54
|
|
|
40
|
-
|
|
41
|
-
echo "
|
|
42
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
43
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
44
|
-
mkdir -p "${WORKSPACE_ROOT}/
|
|
55
|
+
backend|web|saas)
|
|
56
|
+
echo "1. Scaffolding Backend / Enterprise Source Tree (src/)..."
|
|
57
|
+
mkdir -p "${WORKSPACE_ROOT}/src/domain/entities"
|
|
58
|
+
mkdir -p "${WORKSPACE_ROOT}/src/domain/value_objects"
|
|
59
|
+
mkdir -p "${WORKSPACE_ROOT}/src/domain/services"
|
|
60
|
+
mkdir -p "${WORKSPACE_ROOT}/src/ports/primary"
|
|
61
|
+
mkdir -p "${WORKSPACE_ROOT}/src/ports/secondary"
|
|
62
|
+
mkdir -p "${WORKSPACE_ROOT}/src/adapters/primary"
|
|
63
|
+
mkdir -p "${WORKSPACE_ROOT}/src/adapters/secondary"
|
|
64
|
+
|
|
65
|
+
echo "2. Scaffolding Specifications (specs/)..."
|
|
66
|
+
mkdir -p "${WORKSPACE_ROOT}/specs/openapi"
|
|
67
|
+
mkdir -p "${WORKSPACE_ROOT}/specs/tokens"
|
|
68
|
+
|
|
69
|
+
echo "3. Scaffolding Backend Test Suites (tests/)..."
|
|
70
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/unit"
|
|
71
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/integration"
|
|
72
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/contracts"
|
|
73
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/acceptance"
|
|
74
|
+
|
|
75
|
+
echo "4. Scaffolding Deployment Infrastructure (deploy/)..."
|
|
76
|
+
mkdir -p "${WORKSPACE_ROOT}/deploy/docker"
|
|
77
|
+
mkdir -p "${WORKSPACE_ROOT}/deploy/compose"
|
|
45
78
|
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
cat << 'EOF' > "${TOKEN_SPEC}"
|
|
79
|
+
TOKEN_SPEC="${WORKSPACE_ROOT}/specs/tokens/tokens.json"
|
|
80
|
+
if [[ ! -f "${TOKEN_SPEC}" ]]; then
|
|
81
|
+
cat << 'EOF' > "${TOKEN_SPEC}"
|
|
50
82
|
{
|
|
51
83
|
"color": {
|
|
52
84
|
"brand": {
|
|
@@ -62,7 +94,15 @@ if [[ ! -f "${TOKEN_SPEC}" ]]; then
|
|
|
62
94
|
}
|
|
63
95
|
}
|
|
64
96
|
EOF
|
|
65
|
-
fi
|
|
97
|
+
fi
|
|
98
|
+
;;
|
|
99
|
+
|
|
100
|
+
*)
|
|
101
|
+
echo "1. Scaffolding Generic / Library Source Tree (src/)..."
|
|
102
|
+
mkdir -p "${WORKSPACE_ROOT}/src"
|
|
103
|
+
mkdir -p "${WORKSPACE_ROOT}/tests/unit"
|
|
104
|
+
;;
|
|
105
|
+
esac
|
|
66
106
|
|
|
67
107
|
echo "--------------------------------------------------------------"
|
|
68
|
-
echo "✅
|
|
108
|
+
echo "✅ Topology '${TOPOLOGY}' scaffolded with strict YAGNI (0 speculative folders)!"
|
package/AGENTS.md
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
> **Rule Zero:** Assume nothing. Every action must be grounded in verified evidence from this workspace or direct instructions from the user.
|
|
5
5
|
> **Open-Source Mandate:** Always utilize 100% open-source tools, frameworks, libraries, and packages across all architectural domains.
|
|
6
6
|
> **Atomicity Mandate:** All rules, skills, code units, migrations, and transactions must be strictly atomic (indivisible, self-contained, and composable with full ACID safety).
|
|
7
|
-
> **
|
|
7
|
+
> **Architecture Mandate:** Architecture emerges strictly from problem constraints and execution targets (Problem-First; zero tool/platform bias). Match architectural style to problem topology (Hexagonal for enterprise backends, Platform Scripting for extensions, Data-Oriented Design for game engines, Command Pipeline for CLIs, Game Loop for canvas games). Never force premature abstractions or universal templates.
|
|
8
8
|
|
|
9
9
|
---
|
|
10
10
|
|
|
@@ -14,10 +14,12 @@
|
|
|
14
14
|
2. **Ground Truth Only:** A statement is only true if proven by a workspace file, verified command output, or direct user instruction.
|
|
15
15
|
3. **Unknown Until Verified:** If something is not explicitly written in the workspace or stated by the user, treat it as unknown.
|
|
16
16
|
4. **Strict Open Standards:** Standardize on open-source solutions and open specs (Semgrep, Trivy, Gitleaks, OpenTelemetry, OPA, OCI, Wasm, CloudEvents).
|
|
17
|
-
5. **
|
|
18
|
-
6. **
|
|
19
|
-
7. **
|
|
20
|
-
8. **
|
|
17
|
+
5. **Problem-First & Topology Alignment:** Problem domain and operational constraints (latency budget, GC tolerance, memory, execution environment) strictly dictate the architectural style and toolchain. Never select tools before defining the problem space.
|
|
18
|
+
6. **Evolutionary Architecture & Refactor-Before-Add:** As complexity grows, code must graduate across explicit architectural tipping points. Refactor structure first under existing green tests before implementing new features. Never append code into rotting files.
|
|
19
|
+
7. **True Incremental TDD & Nano-Cycles:** Never dump test suites in batches ("Test-First Waterfall"). Follow Uncle Bob's Three Laws: write one micro-assertion at a time, verify RED failure output, write minimal code to turn GREEN, and refactor under green.
|
|
20
|
+
8. **Systemic Atomicity:** Every skill, rule, database transaction, and refactoring step must be atomic (Single Responsibility, zero side-effects, full rollback).
|
|
21
|
+
9. **Workspace Sovereignty:** Total containment within the local workspace root (`./`). Zero interference from global configs, tools, or sibling projects.
|
|
22
|
+
10. **Continuous Learning:** Ingest all verified defects, lessons, and architectural invariants directly into domain rules and `memory.md`.
|
|
21
23
|
|
|
22
24
|
### The 5 Core Branch Questions
|
|
23
25
|
Before acting on any decision branch, answer:
|
|
@@ -40,10 +42,10 @@ Before acting on any decision branch, answer:
|
|
|
40
42
|
|
|
41
43
|
Progress all tasks systematically through the unified **Agent Cognitive & Agile Domain Lifecycle**, seamlessly interlocking the 5 agent operational disciplines with the 5-phase domain engineering pipeline:
|
|
42
44
|
```
|
|
43
|
-
1. DISCOVER / REQUIREMENTS ──► Read-only inspection; INVEST
|
|
44
|
-
2. INTERROGATE / DOMAIN ──► Relentless questioning; Ubiquitous Language &
|
|
45
|
+
1. DISCOVER / REQUIREMENTS ──► Read-only inspection; Problem Space & operational constraints; INVEST stories & Gherkin.
|
|
46
|
+
2. INTERROGATE / DOMAIN ──► Relentless questioning; Ubiquitous Language, Aggregate invariants & state machines.
|
|
45
47
|
3. PLAN / OUTER TDD ──► Minimal blast radius; failing Outer Acceptance Test (UI/API RED).
|
|
46
|
-
4. EXECUTE / INNER TDD ──►
|
|
48
|
+
4. EXECUTE / INNER TDD ──► Incremental nano-cycles (Uncle Bob's 3 Laws: 1 micro-assertion RED ➔ MINIMAL pass GREEN ➔ REFACTOR).
|
|
47
49
|
5. VERIFY / DoD & PROOF ──► Outer test turns GREEN; boundary smoke tests & 100.00% test coverage.
|
|
48
50
|
```
|
|
49
51
|
---
|
|
@@ -99,7 +101,7 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
99
101
|
| **Domain Modeling** | [docs/rules/domain_expertise.md](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
100
102
|
| **Relentless Questioning** | [docs/rules/relentless_questioning.md](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
101
103
|
| **Workspace Isolation** | [docs/rules/workspace_isolation.md](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
102
|
-
| **Continuous Learning** | [docs/rules/continuous_learning.md](./docs/rules/continuous_learning.md) |
|
|
104
|
+
| **Continuous Learning** | [docs/rules/continuous_learning.md](./docs/rules/continuous_learning.md) | Direct rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
103
105
|
| **Upstream Sync** | [docs/rules/upstream_synchronization.md](./docs/rules/upstream_synchronization.md) | Logging generic architecture improvements to changes.md; zero baseline pollution. |
|
|
104
106
|
---
|
|
105
107
|
|
|
@@ -114,5 +116,5 @@ To prevent context bloat and keep prompt overhead minimal, detailed engineering
|
|
|
114
116
|
- [`lets-build`](.agents/skills/lets-build/SKILL.md): Conducting architecture interviews to finalize stack, frameworks, package managers, and bootstrapping projects.
|
|
115
117
|
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
116
118
|
- **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`.
|
|
117
|
-
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge/`](./docs/knowledge/knowledge_graph.md) for system topologies
|
|
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.
|
|
118
120
|
- **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
|
@@ -1,23 +1,25 @@
|
|
|
1
|
-
# azcodr: Enterprise
|
|
1
|
+
# azcodr: Enterprise Architecture & Agentic Engineering Starter Template
|
|
2
2
|
|
|
3
|
-
> **Production-ready, battle-tested
|
|
3
|
+
> **Production-ready, battle-tested software architecture governed by problem-first topology alignment, strict systemic atomicity, evolutionary architecture tipping points, 100% open-source standards, true incremental TDD nano-cycles, and zero speculative bloat.**
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
## 🌟 Architectural Pillars
|
|
8
8
|
|
|
9
|
-
1. **
|
|
10
|
-
2. **
|
|
11
|
-
3. **
|
|
12
|
-
4. **
|
|
13
|
-
5. **
|
|
14
|
-
6. **
|
|
9
|
+
1. **Problem-First & Topology Alignment**: Architecture emerges strictly from problem constraints and execution targets (Problem-First; zero preemptive tool bias). Architectural styles match the problem topology: Hexagonal for enterprise backends, Platform Scripting for extensions, Data-Oriented Design for game engines, Command Pipeline for CLIs, and Game Loop for canvas games.
|
|
10
|
+
2. **Systemic Atomicity**: Every rule, skill, database transaction, and code unit adheres to the Single Responsibility Principle (SRP)—indivisible, self-contained, orthogonal, and composable with zero conjunction naming.
|
|
11
|
+
3. **Evolutionary Architecture & Refactor-Before-Add**: To eliminate AI-accelerated architectural drift, code graduates across 5 deterministic tipping points. Refactor structure first under existing green tests before implementing new features. Never append code into rotting files.
|
|
12
|
+
4. **True Incremental TDD & Nano-Cycles**: Prohibit batch-test dumps ("Test-First Waterfall"). Follow Uncle Bob's Three Laws: write one micro-assertion at a time, verify RED failure output, write minimal code to turn GREEN, and refactor under green with Ping-Pong pair programming.
|
|
13
|
+
5. **100% Open-Source & Open Standards**: Standardized exclusively on open-source solutions and vendor-neutral specifications (OpenTelemetry, OPA, OpenFGA, Protocol Buffers, OpenAPI 3.1, JSON Schema Draft 2020-12, CloudEvents, Semgrep, Trivy, Gitleaks, Cosign).
|
|
14
|
+
6. **Zero-Assumption Framework**: Ground truth is established solely through workspace configurations, code evidence, or direct user confirmation.
|
|
15
|
+
7. **Hardened Multi-Tenancy (When Applicable)**: 4 interchangeable isolation models (AST query interceptor filtering, schema-per-tenant, database-per-tenant, transparent storage proxy) backed by transaction-scoped session context.
|
|
16
|
+
8. **Dynamic Extensibility Without Code Branching**:
|
|
15
17
|
- Custom tables and columns via hybrid core relational/document models and validated JSON Schema.
|
|
16
18
|
- Pluggable business logic via Common Expression Language (CEL), GoF Strategy registries, and WebAssembly (Wasm) micro-sandboxes.
|
|
17
19
|
- Tenant lifecycles via durable workflows (Temporal / BPMN 2.0 / statecharts).
|
|
18
20
|
- Server-Driven UI (SDUI) component registries and W3C Design Tokens Community Group (DTCG) theming.
|
|
19
|
-
|
|
20
|
-
|
|
21
|
+
9. **Resilient Database Architecture**: Full ACID atomicity, Transactional Outbox pattern eliminating dual-writes, declarative expand-contract zero-downtime migrations, and continuous Point-In-Time Recovery (PITR).
|
|
22
|
+
10. **Workspace Knowledge Hub & Token Economy**: In-workspace system knowledge graphs and Lightweight Architectural Decision Records (ADRs) to eliminate repetitive token-expensive discovery loops.
|
|
21
23
|
|
|
22
24
|
---
|
|
23
25
|
|
|
@@ -34,11 +36,8 @@
|
|
|
34
36
|
│ ├── product-analyst/ # INVEST user stories & Gherkin criteria
|
|
35
37
|
│ └── relentless-questioner/ # Context-aware dynamic interrogation loop
|
|
36
38
|
├── docs/
|
|
37
|
-
│ ├── knowledge/ # Institutional knowledge &
|
|
38
|
-
│ │ ├── dos_and_donts.md # Consolidated DO's and DONT's directory
|
|
39
|
-
│ │ ├── issue_log.md # Defect post-mortems & preventing rules
|
|
39
|
+
│ ├── knowledge/ # Institutional knowledge & domain contracts
|
|
40
40
|
│ │ ├── knowledge_graph.md # Visual topologies & fast-lookup matrices
|
|
41
|
-
│ │ ├── lessons_learned.md # Strategic architectural takeaways
|
|
42
41
|
│ │ └── ubiquitous_language.md # Living Ubiquitous Language glossary template
|
|
43
42
|
│ └── rules/ # 47 atomic single-responsibility domain rules
|
|
44
43
|
├── AGENTS.md # Lean root agentic configuration (< 120 lines)
|
|
@@ -57,9 +56,9 @@ The architecture enforces 47 atomic, single-responsibility domain rules. Read on
|
|
|
57
56
|
|
|
58
57
|
| Domain | Rule Reference File | Key Focus & Invariants |
|
|
59
58
|
|---|---|---|
|
|
60
|
-
| **TDD Double Loop** | [`test_driven_development.md`](./docs/rules/test_driven_development.md) |
|
|
59
|
+
| **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. |
|
|
61
60
|
| **Test Coverage & Isolation** | [`test_isolation.md`](./docs/rules/test_isolation.md) | 100.00% full-stack coverage, status codes, transactional DB rollback. |
|
|
62
|
-
| **Clean Code** | [`clean_code.md`](./docs/rules/clean_code.md) |
|
|
61
|
+
| **Clean Code** | [`clean_code.md`](./docs/rules/clean_code.md) | 5 evolutionary tipping points, Refactor-Before-Add, CQS, SLAP, DRY, fitness functions. |
|
|
63
62
|
| **Design Patterns** | [`design_patterns.md`](./docs/rules/design_patterns.md) | Adapter, Factory, Facade, Strategy, and Result `<T, E>` pattern. |
|
|
64
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. |
|
|
65
64
|
| **Type Safety** | [`typescript.md`](./docs/rules/typescript.md) | Compiler strictness, branded nominal types, type safety, static sound invariants. |
|
|
@@ -94,7 +93,7 @@ The architecture enforces 47 atomic, single-responsibility domain rules. Read on
|
|
|
94
93
|
| **React & Frontend** | [`react.md`](./docs/rules/react.md) | Modern React, shadcn/ui, TanStack Query, React Hook Form, and Zod validation. |
|
|
95
94
|
| **Requirements Engineering** | [`requirements_engineering.md`](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
96
95
|
| **Product Ownership** | [`product_ownership.md`](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
97
|
-
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts,
|
|
96
|
+
| **Domain-Driven Design** | [`domain_driven_design.md`](./docs/rules/domain_driven_design.md) | Problem Space vs Solution Space, Ubiquitous Language, Bounded Contexts, Aggregates. |
|
|
98
97
|
| **Workflow State Machines** | [`workflow_state_machines.md`](./docs/rules/workflow_state_machines.md) | Configurable workflows, in-aggregate invariant FSMs, transition guards & audit logs. |
|
|
99
98
|
| **Cloud-Native 12-Factor** | [`cloud_native.md`](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
100
99
|
| **Agentic Config & Skills** | [`agentic_configuration.md`](./docs/rules/agentic_configuration.md) | Progressive disclosure architecture, skill inquiry branches, refinement loop. |
|
|
@@ -102,7 +101,7 @@ The architecture enforces 47 atomic, single-responsibility domain rules. Read on
|
|
|
102
101
|
| **Domain Modeling** | [`domain_expertise.md`](./docs/rules/domain_expertise.md) | Business capabilities, Aggregate Root invariants, Ubiquitous Language. |
|
|
103
102
|
| **Relentless Questioning** | [`relentless_questioning.md`](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
104
103
|
| **Workspace Isolation** | [`workspace_isolation.md`](./docs/rules/workspace_isolation.md) | Strict workspace sovereignty, zero global contamination, local ground truth. |
|
|
105
|
-
| **Continuous Learning** | [`continuous_learning.md`](./docs/rules/continuous_learning.md) |
|
|
104
|
+
| **Continuous Learning** | [`continuous_learning.md`](./docs/rules/continuous_learning.md) | Direct 4-step rule ingestion, root-cause analysis, dynamic invariant updates. |
|
|
106
105
|
| **Upstream Sync** | [`upstream_synchronization.md`](./docs/rules/upstream_synchronization.md) | Logging generic architecture improvements to changes.md; zero baseline pollution. |
|
|
107
106
|
|
|
108
107
|
---
|
|
@@ -137,48 +136,39 @@ In your AI coding assistant (Google Antigravity, Claude Code, Cursor, or OpenHan
|
|
|
137
136
|
```
|
|
138
137
|
*(Or simply prompt: "Let's build a new project from this template.")*
|
|
139
138
|
|
|
140
|
-
### Step 3: The
|
|
141
|
-
The agent will execute a deep research loop and systematically
|
|
142
|
-
|
|
143
|
-
1. **
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
12. **Authorization Engine**: Open Policy Agent (OPA Rego via HTTP/Wasm), OpenFGA (Zanzibar ReBAC), or Cerbos.
|
|
155
|
-
13. **Frontend / Client**: Web (React, Vue, Svelte), Mobile (Flutter, Native), Server-Driven UI (SDUI), and W3C DTCG Design Tokens.
|
|
156
|
-
14. **Caching & Locks**: Redis, Valkey, Dragonfly, Memcached, or local LRU with XFetch stampede defense.
|
|
157
|
-
15. **Event Streaming**: Apache Kafka, NATS JetStream, RabbitMQ, SQS with Transactional Outbox.
|
|
158
|
-
16. **Observability**: OpenTelemetry OTLP traces/metrics/logs over gRPC/HTTP with W3C trace context.
|
|
159
|
-
17. **DevSecOps & Verification**: Semgrep SAST, Gitleaks, Trivy scanning, CycloneDX SBOM, Cosign, and Outside-In TDD (100% coverage gates).
|
|
160
|
-
18. **Deployment Target**: Minimal OCI Distroless/Scratch, Docker Compose, Kubernetes, and OpenTofu IaC.
|
|
139
|
+
### Step 3: The Problem-First Architectural Interview
|
|
140
|
+
The agent will execute a deep research loop and systematically derive your technical stack strictly from problem constraints (with zero preemptive tool bias) across 5 tiered dimensions:
|
|
141
|
+
|
|
142
|
+
1. **Problem Space & Topology Classification**: What real-world problem is being solved? What data moves and transforms? Classifies the system topology:
|
|
143
|
+
- *Topology A: Web SaaS / Cloud Microservices*
|
|
144
|
+
- *Topology B: Browser Extension (Manifest V3)*
|
|
145
|
+
- *Topology C: Game Engine / High-Performance Simulator (Bare metal, GPU)*
|
|
146
|
+
- *Topology D: Browser / Canvas Game (HTML5 Canvas / WebGL / WebGPU)*
|
|
147
|
+
- *Topology E: Desktop Application / CLI Utility (Native POSIX/Windows)*
|
|
148
|
+
- *Topology F: Systems / Embedded / Cryptographic Library*
|
|
149
|
+
2. **Physical & Operational Constraints**: Latency budget (hard real-time <16.6ms frame loop vs interactive low-latency vs batch), memory model & GC tolerance (zero-GC pause tolerance vs managed throughput GC vs single-threaded event loop), and concurrency topology.
|
|
150
|
+
3. **Architectural Style Derivation**: Matches style strictly to topology (Hexagonal for enterprise backends, Platform Scripting for extensions, Data-Oriented Design for game engines, Game Loop for canvas games, Command Pipeline for CLIs).
|
|
151
|
+
4. **Emergent Stack & Toolchain**: Derives the optimal language (C, Rust, TypeScript, Go, Java, C#, Python), package manager, and build system strictly from the verified constraints.
|
|
152
|
+
5. **Targeted Invariants (Strictly Topology-Scoped)**: Inquires *only* into the dimensions relevant to the selected topology (e.g. database migrations for web backends, content script isolation for extensions, CLI flags for CLIs; zero Docker, Kubernetes, or OpenAPI bloat for non-backend projects).
|
|
161
153
|
|
|
162
154
|
### Step 4: Blueprint Synthesis & Explicit Approval
|
|
163
155
|
The agent consolidates all your choices into a formal **Architectural Specification & Technology Blueprint** and records a formal ADR in [`memory.md`](./memory.md).
|
|
164
156
|
**The agent will stop and ask for your explicit confirmation before generating any code.**
|
|
165
157
|
|
|
166
|
-
### Step 5: Deterministic
|
|
158
|
+
### Step 5: Deterministic Topology Scaffolding (Strict YAGNI)
|
|
167
159
|
Once confirmed, the agent automatically executes:
|
|
168
|
-
1.
|
|
169
|
-
2.
|
|
170
|
-
3. Build manifests, strict linter/formatter configurations,
|
|
171
|
-
4.
|
|
172
|
-
5.
|
|
173
|
-
6.
|
|
160
|
+
1. Topology-aware directory scaffolding via `bootstrap_workspace.sh . <topology> <language>`, generating **0 speculative folders** (e.g. extensions get no Kubernetes or OpenAPI specs; CLIs get no Dockerfiles).
|
|
161
|
+
2. Targeted contract and entrypoint generation matching the derived topology.
|
|
162
|
+
3. Build manifests, strict linter/formatter configurations, and boundary smoke test (`scripts/smoke_test.sh`).
|
|
163
|
+
4. **Project-Specific README Generation**: Completely replaces the starter template `README.md` with clean, project-specific documentation (mission, stack highlights, quickstart setup, build/test commands, and directory structure), preserving links to `docs/rules/`.
|
|
164
|
+
5. Deterministic validation via `validate_agentic_configs.sh` and initial smoke test execution.
|
|
165
|
+
6. **Handover Gate to Domain Analysis**: Halts technical scaffolding and instructs the user to invoke `product-analyst` and `relentless-questioner` for domain modeling.
|
|
174
166
|
|
|
175
167
|
---
|
|
176
168
|
|
|
177
169
|
## 🏛️ Workspace Memory & Knowledge Hub
|
|
178
170
|
|
|
179
171
|
- 🗺️ **[System Knowledge Graph](./docs/knowledge/knowledge_graph.md)**: Visual subsystem topologies and entity-relationship models.
|
|
180
|
-
-
|
|
181
|
-
-
|
|
182
|
-
- 💡 **[Institutional Lessons Learned](./docs/knowledge/lessons_learned.md)**: Strategic engineering insights.
|
|
183
|
-
- 📜 **[Lightweight ADR Ledger](./memory.md)**: Formal Architectural Decision Records.
|
|
172
|
+
- 📖 **[Living Ubiquitous Language Glossary](./docs/knowledge/ubiquitous_language.md)**: Authoritative domain vocabulary contract.
|
|
173
|
+
- 📜 **[Lightweight ADR Ledger](./memory.md)**: Formal Architectural Decision Records and governing rules.
|
|
184
174
|
- 📝 **[Upstream Changes Ledger](./changes.md)**: Record candidate improvements and generic patterns for the upstream azcodr template.
|
package/changes.md
CHANGED
|
@@ -48,3 +48,15 @@ When an AI agent or engineer discovers a generic architectural improvement, bug
|
|
|
48
48
|
- **Rationale:** Ensure flawless cross-platform and multi-version Node execution across macOS, Windows, and Linux on Node 18, 20, 22, 24.
|
|
49
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
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
|
+
|
|
@@ -111,18 +111,3 @@ specs/
|
|
|
111
111
|
│ └── openapi.yaml
|
|
112
112
|
```
|
|
113
113
|
|
|
114
|
-
---
|
|
115
|
-
|
|
116
|
-
## 5. Invariants, DO's & DONT's
|
|
117
|
-
|
|
118
|
-
### DO's:
|
|
119
|
-
- **DO:** Prefix all public REST endpoints with major version identifiers (`/api/v1/`, `/api/v2/`).
|
|
120
|
-
- **DO:** Bump MAJOR and cut a new `/api/v2/` prefix whenever request or response breaking changes occur.
|
|
121
|
-
- **DO:** Inject RFC 8594 `Sunset` and `Deprecation` headers on all retired endpoints and provide a 90-day grace period.
|
|
122
|
-
- **DO:** Organize specs into versioned folders (`specs/openapi/v1/`, `v2/`) with an interactive Swagger selector.
|
|
123
|
-
|
|
124
|
-
### DONT's:
|
|
125
|
-
- **DONT:** Never expose minor or patch numbers in the URL path (e.g. `/api/v1.2/`).
|
|
126
|
-
- **DONT:** Never introduce breaking schema or status code changes within an existing major version.
|
|
127
|
-
- **DONT:** Never delete an active endpoint without a formal deprecation lifecycle.
|
|
128
|
-
|
package/docs/rules/clean_code.md
CHANGED
|
@@ -23,3 +23,40 @@
|
|
|
23
23
|
- **Orthogonality**: Eliminate coupling between unrelated modules. Changing one component must not cascade unexpected side effects into another.
|
|
24
24
|
- **Broken Windows Theory**: Never leave bad code, failing lint checks, or out-of-date documentation unfixed. Fix defects immediately before entropy normalizes.
|
|
25
25
|
- **Design by Contract (DbC)**: Define explicit preconditions (runtime boundary validation), postconditions (guaranteed response envelopes), and domain invariants.
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## 3. Evolutionary Architecture & Architectural Tipping Points (Ford, Parsons & Fowler)
|
|
30
|
+
|
|
31
|
+
Architecture is not a static Day 1 monument; it evolves incrementally as complexity grows. AI coding tools naturally take the path of least resistance (local token minimization), repeatedly appending code to simple files until they rot into a Big Ball of Mud. To eliminate **AI-Accelerated Architectural Drift**, the agent must pause and execute an architectural upgrade whenever code hits a **Deterministic Tipping Point**:
|
|
32
|
+
|
|
33
|
+
| Simple Baseline (Day 1) | Tipping Point / Mutation Trigger | Required Architectural Upgrade |
|
|
34
|
+
|---|---|---|
|
|
35
|
+
| **Flat Script / Single File** | File exceeds **250 lines**, or coordinates **>2 distinct I/O resources**, or is imported by **>3 distinct callers**. | **Extract Modular Subsystems:** Decouple domain logic from platform I/O; split into dedicated, focused submodules. |
|
|
36
|
+
| **Inline `if/else` or `switch` Cascades** | **Rule of Three:** The 3rd branching variant, payment provider, or protocol format is introduced. | **Strategy Pattern / Registry:** Replace conditional branching with a polymorphic Strategy interface or handler registry; update `memory.md`. |
|
|
37
|
+
| **In-Memory Store / Global State** | State requires **concurrent mutations**, **persistence across process restarts**, or **transactional rollback**. | **Repository Pattern & Persistence Port:** Introduce an explicit storage port contract; swap in-memory mock for a persistent database adapter. |
|
|
38
|
+
| **Direct Platform / Third-Party Calls** | External SDK or platform API is called from **>2 places**, or SDK throws untyped exceptions across boundaries. | **Adapter Pattern (Anti-Corruption Layer):** Wrap external SDK inside an application-owned port interface; mock only the owned interface in tests. |
|
|
39
|
+
| **Monolithic Domain Model** | The same business noun represents divergent lifecycles or definitions across workflows (e.g. `User` in Auth vs `User` in Billing). | **Bounded Context Split:** Separate into isolated domain contexts with explicit DTO / Anti-Corruption translation between them. |
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## 4. The "Refactor-Before-Add" Protocol (Kent Beck's Rule)
|
|
44
|
+
|
|
45
|
+
> *"Make the change easy (warning: this may be hard), then make the easy change."* — Kent Beck
|
|
46
|
+
|
|
47
|
+
Before writing production code for any new feature or user story, the agent must execute the **Refactor-Before-Add Check**:
|
|
48
|
+
1. **Assess Tipping Points**: Will adding this requirement cause any module, function, or data structure to cross an architectural tipping point?
|
|
49
|
+
2. **Phase A — Structural Refactoring (Under Green)**: If yes, refactor the existing architecture *first* while existing test suites remain 100% green. Zero behavioral changes; purely structural evolution.
|
|
50
|
+
3. **Phase B — ADR Mutation**: When an architectural tipping point is crossed, log a Lightweight Architectural Decision Record in `memory.md` summarizing the new structural boundary and trade-off.
|
|
51
|
+
4. **Phase C — Feature Implementation (Inner TDD)**: Only once the architecture cleanly accommodates the new capability, write the failing micro-test and implement the feature.
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## 5. Architectural Fitness Functions (Automated Tripwires)
|
|
56
|
+
|
|
57
|
+
Prevent AI-generated code rot using automated fitness functions integrated into linting and continuous verification:
|
|
58
|
+
- **File Length Gates**: Maximum 250–300 lines per file (ESLint `max-lines`).
|
|
59
|
+
- **Function Length Gates**: Maximum 20–30 lines per function (ESLint `max-lines-per-function`).
|
|
60
|
+
- **Dependency Direction Gates**: Enforce unidirectional import rules (e.g. `import/no-restricted-paths`, `dependency-cruiser`, `ArchUnit`) ensuring domain core never imports infrastructure or transport adapters.
|
|
61
|
+
- **Complexity Budgets**: Enforce cyclomatic complexity limits (maximum 10 per function).
|
|
62
|
+
If an AI attempt to add code violates any fitness function, the build fails immediately, blocking completion until the architecture is refactored.
|
|
@@ -1,29 +1,30 @@
|
|
|
1
1
|
# Continuous Learning & Automated Rule Ingestion
|
|
2
2
|
|
|
3
|
-
> **Core Mandate:** Automatically
|
|
3
|
+
> **Core Mandate:** Automatically capture development defects, analyze root causes, and directly update domain rules or skills to permanently prevent recurrence without intermediate bloat.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
## 1. The
|
|
7
|
+
## 1. The Direct Rule Ingestion Loop
|
|
8
8
|
|
|
9
|
-
Whenever an error, test failure, build friction, or architectural anti-pattern occurs during development, immediately execute the
|
|
9
|
+
Whenever an error, test failure, build friction, or architectural anti-pattern occurs during development, immediately execute the 4-step loop:
|
|
10
10
|
|
|
11
11
|
```
|
|
12
|
-
1. Capture Defect ──► 2. Root Cause Analysis ──► 3.
|
|
12
|
+
1. Capture Defect ──► 2. Root Cause Analysis ──► 3. Synthesize Invariant ──► 4. Update Rule / Skill
|
|
13
13
|
```
|
|
14
14
|
|
|
15
|
-
1. **Capture Defect**: Record the failure symptoms and
|
|
15
|
+
1. **Capture Defect**: Record the failure symptoms, stack trace, and failing test case.
|
|
16
16
|
2. **Root Cause Analysis**: Identify the fundamental architectural or operational gap (not just the surface symptom).
|
|
17
|
-
3. **
|
|
18
|
-
4. **
|
|
19
|
-
|
|
20
|
-
- If the
|
|
21
|
-
- If it
|
|
22
|
-
- Run
|
|
17
|
+
3. **Synthesize Invariant**: Formulate a concrete, positive architectural invariant and code example showing the correct implementation.
|
|
18
|
+
4. **Update Rule / Skill**:
|
|
19
|
+
- Update the governing domain rule in `docs/rules/<domain>.md` or specialized skill in `.agents/skills/` directly.
|
|
20
|
+
- If the lesson introduces an architectural trade-off or paradigm shift, record a lightweight ADR in [`memory.md`](../../memory.md).
|
|
21
|
+
- If it unlocks a new domain, author a new atomic rule file and index it in [`AGENTS.md`](../../AGENTS.md).
|
|
22
|
+
- Run verification (`npm test && npm run validate`) to ensure 100% integrity.
|
|
23
23
|
|
|
24
24
|
---
|
|
25
25
|
|
|
26
26
|
## 2. Institutional Memory Maintenance
|
|
27
27
|
|
|
28
|
-
- **ADR
|
|
29
|
-
- **Knowledge Graph
|
|
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
|
+
- **Living Glossary**: Keep [`docs/knowledge/ubiquitous_language.md`](../knowledge/ubiquitous_language.md) updated with canonical domain terminology and forbidden synonyms.
|
|
@@ -69,20 +69,12 @@ Pure financial ledgers (e.g. `PaymentLedgerEntry`, `JournalEntry`) and event out
|
|
|
69
69
|
|
|
70
70
|
---
|
|
71
71
|
|
|
72
|
-
## 6.
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
- **
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
- **DO:** Filter active records with `WHERE deleted_at IS NULL` and pair uniqueness with partial indexes (`WHERE deleted_at IS NULL`).
|
|
82
|
-
|
|
83
|
-
### DONT's:
|
|
84
|
-
- **DONT:** Never create a database table or entity without `createdAt` and `createdBy`.
|
|
85
|
-
- **DONT:** Never omit `updatedBy` or `deletedBy` on mutable tables. Every mutation and deletion must have an accountable actor.
|
|
86
|
-
- **DONT:** Never expose raw string text inputs for foreign key identifiers in the user interface.
|
|
87
|
-
- **DONT:** Never consider a feature complete if it only implements creation or listing without update, transition, or deletion capabilities.
|
|
88
|
-
- **DONT:** Never allow cascading deletes on master entities with dependent transactional history.
|
|
72
|
+
## 6. Semi-Structured Evolution & Cryptographic Audit Trails
|
|
73
|
+
|
|
74
|
+
- **Non-Destructive Schema Evolution via JSON**: For contractual covenants, dynamic conditions, or variable metadata subject to rapid domain iteration, employ semi-structured JSON fields (`termsJson`, `metadataJson`) validated against JSON Schema rather than premature table migrations.
|
|
75
|
+
- **Cryptographic Electronic Signatures & Execution Auditing**: Legal agreements and execution records require defensible evidence beyond a boolean `isSigned` flag. All executed agreements must capture:
|
|
76
|
+
1. Typed signer legal name and designated role.
|
|
77
|
+
2. ISO 8601 UTC execution timestamp.
|
|
78
|
+
3. Authenticated actor ID (`userId`).
|
|
79
|
+
4. Client network IP address and User-Agent string.
|
|
80
|
+
5. Deterministic cryptographic checksum / hash of the executed terms.
|
|
@@ -10,6 +10,7 @@
|
|
|
10
10
|
- **Factory Method**: Encapsulate complex collaborator instantiation (e.g. tenant-specific payment gateways or notification dispatchers) behind factory functions.
|
|
11
11
|
- **Facade Pattern**: Expose a unified, simplified interface to complex underlying multi-service subsystems.
|
|
12
12
|
- **Decorator / Middleware**: Compose cross-cutting concerns (observability, authentication, tenant context resolution, rate limiting) via middleware pipelines.
|
|
13
|
+
- **Dependency Injection & Composition Hygiene**: Application factories (`createApp(deps)`) must accept an explicit composite container (`AppDependencies`). Never provide silent default fallback instances inside factories that instantiate disconnected repositories or services when partial dependencies are passed (the Split-Brain Anti-Pattern). Assemble the full dependency graph explicitly at the composition root.
|
|
13
14
|
|
|
14
15
|
---
|
|
15
16
|
|