azcodr 1.5.0 → 1.5.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/hooks.json +42 -0
- package/.agents/hooks.json.example +42 -42
- package/.agents/mcp_config.json.example +29 -24
- package/.agents/scripts/safety_guard.sh +34 -16
- package/.agents/scripts/verify_completion.sh +27 -13
- package/.agents/skills/agentic-architect/SKILL.md +125 -125
- package/.agents/skills/agentic-architect/references/agents_md_template.md +62 -62
- package/.agents/skills/agentic-architect/references/refinement_workflow.md +32 -32
- package/.agents/skills/agentic-architect/references/skill_architecture_inquiry.md +63 -63
- package/.agents/skills/agentic-architect/references/skill_template.md +56 -56
- package/.agents/skills/agentic-architect/scripts/validate_agentic_configs.sh +402 -362
- package/.agents/skills/clean-code-refactor/SKILL.md +91 -91
- package/.agents/skills/clean-code-refactor/references/clean_code_smells.md +27 -27
- package/.agents/skills/clean-code-refactor/references/design_patterns_ts.md +65 -65
- package/.agents/skills/compliance-audit/SKILL.md +120 -120
- package/.agents/skills/compliance-audit/references/owasp_top10_controls.md +16 -16
- package/.agents/skills/compliance-audit/references/soc2_iso_controls.md +28 -28
- package/.agents/skills/lets-build/SKILL.md +173 -172
- package/.agents/skills/lets-build/references/architecture_interview_matrix.md +115 -115
- package/.agents/skills/lets-build/references/hexagonal_bootstrap_scaffolds.md +160 -160
- package/.agents/skills/lets-build/references/project_readme_template.md +79 -79
- package/.agents/skills/lets-build/scripts/bootstrap_workspace.sh +255 -253
- package/.agents/skills/product-analyst/SKILL.md +154 -154
- package/.agents/skills/product-analyst/references/backlog_ordering_techniques.md +107 -107
- package/.agents/skills/product-analyst/references/gherkin_patterns.md +46 -46
- package/.agents/skills/product-analyst/references/invest_checklist.md +38 -38
- package/.agents/skills/product-analyst/references/okr_alignment_guide.md +76 -76
- package/.agents/skills/product-analyst/references/smart_tasks.md +59 -59
- package/.agents/skills/relentless-questioner/SKILL.md +128 -128
- package/.agents/skills/relentless-questioner/references/adaptive_question_trees.md +102 -102
- package/.editorconfig +19 -19
- package/.github/copilot-instructions.md +1 -0
- package/.github/workflows/ci.yml +78 -0
- package/.gitignore +25 -25
- package/AGENTS.md +102 -102
- package/LICENSE +21 -21
- package/README.md +165 -154
- package/bin/azcodr.js +228 -228
- package/data/.gitkeep +0 -0
- package/docs/knowledge/ubiquitous_language.md +18 -18
- package/docs/rules/agentic_configuration.md +259 -259
- package/docs/rules/api_architecture.md +179 -179
- package/docs/rules/authentication.md +76 -76
- package/docs/rules/authorization.md +75 -75
- package/docs/rules/caching.md +69 -69
- package/docs/rules/clean_code.md +62 -62
- package/docs/rules/cloud_native.md +41 -41
- package/docs/rules/cqrs.md +203 -203
- package/docs/rules/database_design.md +125 -125
- package/docs/rules/database_operations.md +69 -69
- package/docs/rules/design_patterns.md +98 -98
- package/docs/rules/devops_ci_cd.md +76 -76
- package/docs/rules/domain_driven_design.md +122 -122
- package/docs/rules/error_handling.md +52 -52
- package/docs/rules/feature_flags.md +59 -59
- package/docs/rules/frontend_architecture.md +157 -157
- package/docs/rules/multitenancy_architecture.md +98 -98
- package/docs/rules/product_ownership.md +127 -127
- package/docs/rules/project_management.md +49 -49
- package/docs/rules/relentless_questioning.md +52 -52
- package/docs/rules/requirements_engineering.md +98 -98
- package/docs/rules/security_compliance.md +53 -53
- package/docs/rules/server_driven_ui.md +88 -88
- package/docs/rules/test_driven_development.md +185 -185
- package/docs/rules/transactional_email.md +27 -27
- package/docs/rules/type_safety.md +65 -65
- package/docs/rules/ui_ux_architecture.md +150 -150
- package/docs/rules/workflow_state_machines.md +117 -117
- package/lib/index.d.ts +134 -123
- package/lib/index.js +5 -5
- package/lib/scaffold.js +448 -351
- package/memory.md +36 -36
- package/package.json +62 -59
- package/scripts/test_coverage.js +38 -0
- package/scripts/validate.js +258 -0
|
@@ -1,102 +1,102 @@
|
|
|
1
|
-
# Adaptive Questioning Trees & Contextual Branching Matrices
|
|
2
|
-
|
|
3
|
-
> **Core Purpose:** Detailed decision trees for the `relentless-questioner` skill, demonstrating how subsequent questions adapt dynamically based on previous user responses.
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## Decision Tree 1: Mutating Operations & State Changes
|
|
8
|
-
|
|
9
|
-
```mermaid
|
|
10
|
-
flowchart TD
|
|
11
|
-
Q1["Does the operation mutate database state?"]
|
|
12
|
-
Q1 -->|Yes| Q2["Does it involve multiple tables, monetary balances, or inventory?"]
|
|
13
|
-
Q1 -->|No / Read Only| Q_Read["Branch: Read Performance & Consistency"]
|
|
14
|
-
|
|
15
|
-
Q2 -->|Yes: Financial / Inventory| Q_Acid["1. Transaction Isolation: REPEATABLE READ or SERIALIZABLE?\n2. Lock Ordering: How to prevent deadlocks?\n3. Concurrency: Optimistic Concurrency Control (version) or pessimistic locking?"]
|
|
16
|
-
Q2 -->|No: Standard Entity CRUD| Q_Crud["1. Soft delete or hard delete?\n2. Unique constraints across tenant?\n3. Cascading relations?"]
|
|
17
|
-
|
|
18
|
-
Q_Acid --> Q3["Does the mutation emit domain events or notify external systems?"]
|
|
19
|
-
Q_Crud --> Q3
|
|
20
|
-
|
|
21
|
-
Q3 -->|Yes| Q_Outbox["How is the dual-write avoided?\n(Enforce Transactional Outbox pattern before broker publish)"]
|
|
22
|
-
Q3 -->|No| Q4["Idempotency: Is an Idempotency-Key header required to guard against network retries?"]
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
---
|
|
26
|
-
|
|
27
|
-
## Decision Tree 2: Multi-Tenancy & Authorization Boundaries
|
|
28
|
-
|
|
29
|
-
```mermaid
|
|
30
|
-
flowchart TD
|
|
31
|
-
Q1["Who executes this action and across which boundary?"]
|
|
32
|
-
Q1 -->|End User via Web/API| Q_Auth["1. What roles are permitted (ADMIN, MEMBER, CUSTOMER)?\n2. Are dynamic ABAC attributes involved (e.g. order value threshold)?\n3. Can a user act across multiple tenants (switch tenant)?"]
|
|
33
|
-
Q1 -->|System / Background Job| Q_Worker["1. How is tenant context established without an HTTP session?\n2. What service principal / token credentials are used?"]
|
|
34
|
-
|
|
35
|
-
Q_Auth --> Q2["What happens if an unauthorized tenant accesses this resource ID?"]
|
|
36
|
-
Q2 --> Q_Sec["1. Return 404 Not Found (enumeration masking) or 403 Forbidden?\n2. Is isolation enforced at the DB layer (RLS / AST interceptor)?"]
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
---
|
|
40
|
-
|
|
41
|
-
## Decision Tree 3: External Integrations & 3rd-Party APIs
|
|
42
|
-
|
|
43
|
-
```mermaid
|
|
44
|
-
flowchart TD
|
|
45
|
-
Q1["Does the feature integrate with an external SaaS or network endpoint?"]
|
|
46
|
-
Q1 -->|Yes| Q2["What is the failure tolerance of the integration?"]
|
|
47
|
-
|
|
48
|
-
Q2 -->|Synchronous / Critical| Q_Sync["1. What is the strict HTTP timeout (e.g. 3000ms)?\n2. What is the circuit breaker threshold before fast-failing?\n3. What fallback response is served if the 3rd-party is down?"]
|
|
49
|
-
Q2 -->|Asynchronous / Event-Driven| Q_Async["1. Does the external system provide webhooks?\n2. How are webhook signatures cryptographically verified?\n3. What is the retry backoff and dead-letter queue (DLQ) policy?"]
|
|
50
|
-
|
|
51
|
-
Q_Sync --> Q_Port["How is the external SDK isolated?\n(Enforce application-owned Port interface so domain never imports SDK)"]
|
|
52
|
-
Q_Async --> Q_Port
|
|
53
|
-
```
|
|
54
|
-
|
|
55
|
-
---
|
|
56
|
-
|
|
57
|
-
## Decision Tree 4: Read Performance, Caching & Search
|
|
58
|
-
|
|
59
|
-
```mermaid
|
|
60
|
-
flowchart TD
|
|
61
|
-
Q1["What is the expected read volume and latency requirement?"]
|
|
62
|
-
Q1 -->|High Volume / Sub-50ms Latency| Q2["Is stale data acceptable for seconds/minutes?"]
|
|
63
|
-
|
|
64
|
-
Q2 -->|Yes| Q_Cache["1. What is the cache TTL and jitter window?\n2. What domain events trigger cache eviction?\n3. Is probabilistic early expiration (XFetch) needed?"]
|
|
65
|
-
Q2 -->|No: Strict Read-After-Write Consistency| Q_Consistent["1. Read from primary database instance for 2s after mutation\n2. Bypass read replicas during write session"]
|
|
66
|
-
|
|
67
|
-
Q_Cache --> Q_Page["Pagination Strategy: Enforce keyset/cursor pagination over OFFSET"]
|
|
68
|
-
Q_Consistent --> Q_Page
|
|
69
|
-
```
|
|
70
|
-
|
|
71
|
-
---
|
|
72
|
-
|
|
73
|
-
## Decision Tree 5: User Interface, Experience Duality & Interaction Flows
|
|
74
|
-
|
|
75
|
-
```mermaid
|
|
76
|
-
flowchart TD
|
|
77
|
-
Q1["Does the feature introduce or modify a user interface?"]
|
|
78
|
-
Q1 -->|Yes| Q2["Who is the primary actor and operational persona?"]
|
|
79
|
-
|
|
80
|
-
Q2 -->|Operator / Admin| Q_Op["1. Information Density: Dense tabular grid with filters?\n2. Persistent App Shell: Left collapsible sidebar route?\n3. Actions: Inline row actions or full-page drawer?"]
|
|
81
|
-
Q2 -->|Consumer / Member| Q_Member["1. Experience Duality: Consumer portal (/portal)?\n2. Touch Ergonomics: Clean cards & mobile drawer?\n3. Simplified self-service actions?"]
|
|
82
|
-
|
|
83
|
-
Q_Op --> Q3["Navigation & State Synchronization"]
|
|
84
|
-
Q_Member --> Q3
|
|
85
|
-
|
|
86
|
-
Q3 --> Q_State["1. URL State: Deep-link query params (?tab=, ?q=, ?page=, ?modal=)?\n2. Server Cache: TanStack Query hook with automated invalidation?\n3. Accessibility: Accessible headless dialogs & ARIA live regions?"]
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
---
|
|
90
|
-
|
|
91
|
-
## Contextual Follow-Up Patterns
|
|
92
|
-
|
|
93
|
-
When conducting the interview, use this exact syntax pattern to chain questions adaptively:
|
|
94
|
-
|
|
95
|
-
1. **Acknowledge and Pin Previous Answer**:
|
|
96
|
-
`"Understood, you specified [Option A] for [Requirement X]."`
|
|
97
|
-
2. **Surface Immediate Architectural Implication**:
|
|
98
|
-
`"Because of [Option A], [Potential Failure / Edge Case Y] becomes the primary risk."`
|
|
99
|
-
3. **Ask Context-Dependent Question**:
|
|
100
|
-
`"How should the system behave when [Condition Y] occurs? Specifically:"`
|
|
101
|
-
- *Sub-question 1*
|
|
102
|
-
- *Sub-question 2*
|
|
1
|
+
# Adaptive Questioning Trees & Contextual Branching Matrices
|
|
2
|
+
|
|
3
|
+
> **Core Purpose:** Detailed decision trees for the `relentless-questioner` skill, demonstrating how subsequent questions adapt dynamically based on previous user responses.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Decision Tree 1: Mutating Operations & State Changes
|
|
8
|
+
|
|
9
|
+
```mermaid
|
|
10
|
+
flowchart TD
|
|
11
|
+
Q1["Does the operation mutate database state?"]
|
|
12
|
+
Q1 -->|Yes| Q2["Does it involve multiple tables, monetary balances, or inventory?"]
|
|
13
|
+
Q1 -->|No / Read Only| Q_Read["Branch: Read Performance & Consistency"]
|
|
14
|
+
|
|
15
|
+
Q2 -->|Yes: Financial / Inventory| Q_Acid["1. Transaction Isolation: REPEATABLE READ or SERIALIZABLE?\n2. Lock Ordering: How to prevent deadlocks?\n3. Concurrency: Optimistic Concurrency Control (version) or pessimistic locking?"]
|
|
16
|
+
Q2 -->|No: Standard Entity CRUD| Q_Crud["1. Soft delete or hard delete?\n2. Unique constraints across tenant?\n3. Cascading relations?"]
|
|
17
|
+
|
|
18
|
+
Q_Acid --> Q3["Does the mutation emit domain events or notify external systems?"]
|
|
19
|
+
Q_Crud --> Q3
|
|
20
|
+
|
|
21
|
+
Q3 -->|Yes| Q_Outbox["How is the dual-write avoided?\n(Enforce Transactional Outbox pattern before broker publish)"]
|
|
22
|
+
Q3 -->|No| Q4["Idempotency: Is an Idempotency-Key header required to guard against network retries?"]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Decision Tree 2: Multi-Tenancy & Authorization Boundaries
|
|
28
|
+
|
|
29
|
+
```mermaid
|
|
30
|
+
flowchart TD
|
|
31
|
+
Q1["Who executes this action and across which boundary?"]
|
|
32
|
+
Q1 -->|End User via Web/API| Q_Auth["1. What roles are permitted (ADMIN, MEMBER, CUSTOMER)?\n2. Are dynamic ABAC attributes involved (e.g. order value threshold)?\n3. Can a user act across multiple tenants (switch tenant)?"]
|
|
33
|
+
Q1 -->|System / Background Job| Q_Worker["1. How is tenant context established without an HTTP session?\n2. What service principal / token credentials are used?"]
|
|
34
|
+
|
|
35
|
+
Q_Auth --> Q2["What happens if an unauthorized tenant accesses this resource ID?"]
|
|
36
|
+
Q2 --> Q_Sec["1. Return 404 Not Found (enumeration masking) or 403 Forbidden?\n2. Is isolation enforced at the DB layer (RLS / AST interceptor)?"]
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Decision Tree 3: External Integrations & 3rd-Party APIs
|
|
42
|
+
|
|
43
|
+
```mermaid
|
|
44
|
+
flowchart TD
|
|
45
|
+
Q1["Does the feature integrate with an external SaaS or network endpoint?"]
|
|
46
|
+
Q1 -->|Yes| Q2["What is the failure tolerance of the integration?"]
|
|
47
|
+
|
|
48
|
+
Q2 -->|Synchronous / Critical| Q_Sync["1. What is the strict HTTP timeout (e.g. 3000ms)?\n2. What is the circuit breaker threshold before fast-failing?\n3. What fallback response is served if the 3rd-party is down?"]
|
|
49
|
+
Q2 -->|Asynchronous / Event-Driven| Q_Async["1. Does the external system provide webhooks?\n2. How are webhook signatures cryptographically verified?\n3. What is the retry backoff and dead-letter queue (DLQ) policy?"]
|
|
50
|
+
|
|
51
|
+
Q_Sync --> Q_Port["How is the external SDK isolated?\n(Enforce application-owned Port interface so domain never imports SDK)"]
|
|
52
|
+
Q_Async --> Q_Port
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Decision Tree 4: Read Performance, Caching & Search
|
|
58
|
+
|
|
59
|
+
```mermaid
|
|
60
|
+
flowchart TD
|
|
61
|
+
Q1["What is the expected read volume and latency requirement?"]
|
|
62
|
+
Q1 -->|High Volume / Sub-50ms Latency| Q2["Is stale data acceptable for seconds/minutes?"]
|
|
63
|
+
|
|
64
|
+
Q2 -->|Yes| Q_Cache["1. What is the cache TTL and jitter window?\n2. What domain events trigger cache eviction?\n3. Is probabilistic early expiration (XFetch) needed?"]
|
|
65
|
+
Q2 -->|No: Strict Read-After-Write Consistency| Q_Consistent["1. Read from primary database instance for 2s after mutation\n2. Bypass read replicas during write session"]
|
|
66
|
+
|
|
67
|
+
Q_Cache --> Q_Page["Pagination Strategy: Enforce keyset/cursor pagination over OFFSET"]
|
|
68
|
+
Q_Consistent --> Q_Page
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Decision Tree 5: User Interface, Experience Duality & Interaction Flows
|
|
74
|
+
|
|
75
|
+
```mermaid
|
|
76
|
+
flowchart TD
|
|
77
|
+
Q1["Does the feature introduce or modify a user interface?"]
|
|
78
|
+
Q1 -->|Yes| Q2["Who is the primary actor and operational persona?"]
|
|
79
|
+
|
|
80
|
+
Q2 -->|Operator / Admin| Q_Op["1. Information Density: Dense tabular grid with filters?\n2. Persistent App Shell: Left collapsible sidebar route?\n3. Actions: Inline row actions or full-page drawer?"]
|
|
81
|
+
Q2 -->|Consumer / Member| Q_Member["1. Experience Duality: Consumer portal (/portal)?\n2. Touch Ergonomics: Clean cards & mobile drawer?\n3. Simplified self-service actions?"]
|
|
82
|
+
|
|
83
|
+
Q_Op --> Q3["Navigation & State Synchronization"]
|
|
84
|
+
Q_Member --> Q3
|
|
85
|
+
|
|
86
|
+
Q3 --> Q_State["1. URL State: Deep-link query params (?tab=, ?q=, ?page=, ?modal=)?\n2. Server Cache: TanStack Query hook with automated invalidation?\n3. Accessibility: Accessible headless dialogs & ARIA live regions?"]
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Contextual Follow-Up Patterns
|
|
92
|
+
|
|
93
|
+
When conducting the interview, use this exact syntax pattern to chain questions adaptively:
|
|
94
|
+
|
|
95
|
+
1. **Acknowledge and Pin Previous Answer**:
|
|
96
|
+
`"Understood, you specified [Option A] for [Requirement X]."`
|
|
97
|
+
2. **Surface Immediate Architectural Implication**:
|
|
98
|
+
`"Because of [Option A], [Potential Failure / Edge Case Y] becomes the primary risk."`
|
|
99
|
+
3. **Ask Context-Dependent Question**:
|
|
100
|
+
`"How should the system behave when [Condition Y] occurs? Specifically:"`
|
|
101
|
+
- *Sub-question 1*
|
|
102
|
+
- *Sub-question 2*
|
package/.editorconfig
CHANGED
|
@@ -1,19 +1,19 @@
|
|
|
1
|
-
# http://editorconfig.org
|
|
2
|
-
root = true
|
|
3
|
-
|
|
4
|
-
[*]
|
|
5
|
-
indent_style = space
|
|
6
|
-
indent_size = 2
|
|
7
|
-
end_of_line = lf
|
|
8
|
-
charset = utf-8
|
|
9
|
-
trim_trailing_whitespace = true
|
|
10
|
-
insert_final_newline = true
|
|
11
|
-
|
|
12
|
-
[*.md]
|
|
13
|
-
trim_trailing_whitespace = false
|
|
14
|
-
|
|
15
|
-
[Makefile]
|
|
16
|
-
indent_style = tab
|
|
17
|
-
|
|
18
|
-
[*.go]
|
|
19
|
-
indent_style = tab
|
|
1
|
+
# http://editorconfig.org
|
|
2
|
+
root = true
|
|
3
|
+
|
|
4
|
+
[*]
|
|
5
|
+
indent_style = space
|
|
6
|
+
indent_size = 2
|
|
7
|
+
end_of_line = lf
|
|
8
|
+
charset = utf-8
|
|
9
|
+
trim_trailing_whitespace = true
|
|
10
|
+
insert_final_newline = true
|
|
11
|
+
|
|
12
|
+
[*.md]
|
|
13
|
+
trim_trailing_whitespace = false
|
|
14
|
+
|
|
15
|
+
[Makefile]
|
|
16
|
+
indent_style = tab
|
|
17
|
+
|
|
18
|
+
[*.go]
|
|
19
|
+
indent_style = tab
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
../AGENTS.md
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
name: CI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
branches: [ main ]
|
|
6
|
+
pull_request:
|
|
7
|
+
branches: [ main ]
|
|
8
|
+
|
|
9
|
+
jobs:
|
|
10
|
+
test:
|
|
11
|
+
name: Node ${{ matrix.node-version }} on ${{ matrix.os }}
|
|
12
|
+
runs-on: ${{ matrix.os }}
|
|
13
|
+
strategy:
|
|
14
|
+
fail-fast: false
|
|
15
|
+
matrix:
|
|
16
|
+
os: [ ubuntu-24.04, macos-latest, windows-latest ]
|
|
17
|
+
node-version: [ 18.x, 20.x, 22.x, 24.x ]
|
|
18
|
+
|
|
19
|
+
steps:
|
|
20
|
+
- name: Checkout Repository
|
|
21
|
+
uses: actions/checkout@v7
|
|
22
|
+
|
|
23
|
+
- name: Setup Node.js ${{ matrix.node-version }}
|
|
24
|
+
uses: actions/setup-node@v7
|
|
25
|
+
with:
|
|
26
|
+
node-version: ${{ matrix.node-version }}
|
|
27
|
+
|
|
28
|
+
- name: Verify Environment
|
|
29
|
+
run: |
|
|
30
|
+
node --version
|
|
31
|
+
npm --version
|
|
32
|
+
|
|
33
|
+
- name: Run Syntax & Lint Checks
|
|
34
|
+
run: npm run lint
|
|
35
|
+
|
|
36
|
+
- name: Validate Agentic Architecture
|
|
37
|
+
run: npm run validate
|
|
38
|
+
|
|
39
|
+
- name: Run Test Suite
|
|
40
|
+
run: npm test
|
|
41
|
+
|
|
42
|
+
coverage:
|
|
43
|
+
name: 100.00% Coverage Gate (Node 24)
|
|
44
|
+
runs-on: ubuntu-24.04
|
|
45
|
+
steps:
|
|
46
|
+
- name: Checkout Repository
|
|
47
|
+
uses: actions/checkout@v7
|
|
48
|
+
|
|
49
|
+
- name: Setup Node.js 24.x
|
|
50
|
+
uses: actions/setup-node@v7
|
|
51
|
+
with:
|
|
52
|
+
node-version: 24.x
|
|
53
|
+
|
|
54
|
+
# Native 100% threshold flags require Node >=22.8.0 (see scripts/test_coverage.js),
|
|
55
|
+
# so the coverage gate runs once on the newest runtime instead of every matrix cell.
|
|
56
|
+
- name: Verify 100.00% Test Coverage Gates
|
|
57
|
+
run: npm run test:coverage
|
|
58
|
+
|
|
59
|
+
security:
|
|
60
|
+
name: Secret & Vulnerability Scans
|
|
61
|
+
runs-on: ubuntu-24.04
|
|
62
|
+
steps:
|
|
63
|
+
- name: Checkout Repository
|
|
64
|
+
uses: actions/checkout@v7
|
|
65
|
+
|
|
66
|
+
- name: Secret Scan (Gitleaks)
|
|
67
|
+
uses: gitleaks/gitleaks-action@v2
|
|
68
|
+
env:
|
|
69
|
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
70
|
+
|
|
71
|
+
- name: Filesystem Vulnerability Scan (Trivy)
|
|
72
|
+
uses: aquasecurity/trivy-action@v0.36.0
|
|
73
|
+
with:
|
|
74
|
+
scan-type: fs
|
|
75
|
+
scan-ref: .
|
|
76
|
+
scanners: vuln
|
|
77
|
+
severity: HIGH,CRITICAL
|
|
78
|
+
exit-code: '1'
|
package/.gitignore
CHANGED
|
@@ -1,25 +1,25 @@
|
|
|
1
|
-
# Node dependencies
|
|
2
|
-
node_modules/
|
|
3
|
-
npm-debug.log*
|
|
4
|
-
yarn-debug.log*
|
|
5
|
-
yarn-error.log*
|
|
6
|
-
*.log
|
|
7
|
-
*.log.*
|
|
8
|
-
|
|
9
|
-
# Test coverage
|
|
10
|
-
coverage/
|
|
11
|
-
|
|
12
|
-
# Pack tarballs
|
|
13
|
-
*.tgz
|
|
14
|
-
|
|
15
|
-
# OS files
|
|
16
|
-
.DS_Store
|
|
17
|
-
Thumbs.db
|
|
18
|
-
|
|
19
|
-
# Local environment
|
|
20
|
-
.env
|
|
21
|
-
.env.local
|
|
22
|
-
.env.*.local
|
|
23
|
-
|
|
24
|
-
# Case-insensitive filesystem parity (agents.md is generated/symlinked on Linux, native on macOS/Windows)
|
|
25
|
-
agents.md
|
|
1
|
+
# Node dependencies
|
|
2
|
+
node_modules/
|
|
3
|
+
npm-debug.log*
|
|
4
|
+
yarn-debug.log*
|
|
5
|
+
yarn-error.log*
|
|
6
|
+
*.log
|
|
7
|
+
*.log.*
|
|
8
|
+
|
|
9
|
+
# Test coverage
|
|
10
|
+
coverage/
|
|
11
|
+
|
|
12
|
+
# Pack tarballs
|
|
13
|
+
*.tgz
|
|
14
|
+
|
|
15
|
+
# OS files
|
|
16
|
+
.DS_Store
|
|
17
|
+
Thumbs.db
|
|
18
|
+
|
|
19
|
+
# Local environment
|
|
20
|
+
.env
|
|
21
|
+
.env.local
|
|
22
|
+
.env.*.local
|
|
23
|
+
|
|
24
|
+
# Case-insensitive filesystem parity (agents.md is generated/symlinked on Linux, native on macOS/Windows)
|
|
25
|
+
agents.md
|
package/AGENTS.md
CHANGED
|
@@ -1,102 +1,102 @@
|
|
|
1
|
-
# AGENTS.md
|
|
2
|
-
|
|
3
|
-
> **azcodr: Enterprise Architecture & Agentic Engineering Starter Template**
|
|
4
|
-
> **Workspace Mission:** Problem-first, topology-aligned production architectures governed by strict systemic atomicity, 100% open-source standards, true incremental TDD nano-cycles, and zero speculative bloat.
|
|
5
|
-
> **Runtime & Tools:** Node.js (`>=18.0.0`), npm (`>=10.0.0`) | `npm test` (test runner), `npm run test:coverage` (100% gate), `npm run lint`, `npm run validate`.
|
|
6
|
-
> **Rule Zero:** Assume nothing. Every action must be grounded in verified evidence from this workspace or direct instructions from the user.
|
|
7
|
-
> **Atomicity Mandate:** All rules, skills, code units, migrations, and transactions must be strictly atomic (indivisible, self-contained, composable with full ACID safety).
|
|
8
|
-
> **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 backends, Platform Scripting for extensions, Data-Oriented Design for game engines, Command Pipeline for CLIs, Game Loop for canvas games).
|
|
9
|
-
|
|
10
|
-
---
|
|
11
|
-
|
|
12
|
-
## 1. Zero-Assumption Operating Framework
|
|
13
|
-
### Core Principles
|
|
14
|
-
1. **No External Assumptions:** You have no prior knowledge of external setups, hidden tools, libraries, or unverified conventions outside this workspace.
|
|
15
|
-
2. **Ground Truth Only:** A statement is only true if proven by a workspace file, verified command output, or direct user instruction.
|
|
16
|
-
3. **Unknown Until Verified:** If something is not explicitly written in the workspace or stated by the user, treat it as unknown.
|
|
17
|
-
4. **Strict Open Standards:** Standardize on open-source solutions and open specs (Semgrep, Trivy, Gitleaks, OpenTelemetry, OPA, OCI, Wasm, CloudEvents).
|
|
18
|
-
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.
|
|
19
|
-
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.
|
|
20
|
-
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.
|
|
21
|
-
8. **Systemic Atomicity:** Every skill, rule, database transaction, and refactoring step must be atomic (Single Responsibility, zero side-effects, full rollback).
|
|
22
|
-
9. **Workspace Sovereignty:** Total containment within the local workspace root (`./`). Zero interference from global configs, tools, or sibling projects.
|
|
23
|
-
10. **Continuous Learning:** Ingest all verified defects, lessons, and architectural invariants directly into domain rules and `memory.md`.
|
|
24
|
-
|
|
25
|
-
### The 5 Core Branch Questions
|
|
26
|
-
Before acting on any decision branch, answer:
|
|
27
|
-
1. **Current State:** What do workspace files currently show? (Inspect before assuming).
|
|
28
|
-
2. **Target Goal:** Is the goal clear, bounded, and explicit? (Stop & ask if ambiguous).
|
|
29
|
-
3. **Tools & Setup:** Are tools defined in workspace configs? (Never assume commands exist).
|
|
30
|
-
4. **Impact & Risk:** Have all references, callers, and side effects been traced?
|
|
31
|
-
5. **Verification:** How will we prove it works with tests or build commands?
|
|
32
|
-
|
|
33
|
-
### Conflict Resolution & Order of Authority
|
|
34
|
-
1. **User Request (Current Session)** ➔ 2. **Workspace Configurations** (lockfiles, linters, scripts) ➔ 3. **Existing Code Patterns** ➔ 4. **Direct Confirmation (Stop & Ask)**.
|
|
35
|
-
|
|
36
|
-
### Action Boundaries
|
|
37
|
-
- **ALWAYS:** Read files before editing; verify commands before running; verify results with evidence.
|
|
38
|
-
- **ASK FIRST:** Adding/removing external dependencies; deleting/renaming files; changing DB schemas or build scripts; modifying existing tests.
|
|
39
|
-
- **NEVER:** Guess paths, flags, or signatures; silently ignore errors; bypass unresolved questions.
|
|
40
|
-
---
|
|
41
|
-
|
|
42
|
-
## 2. Execution Lifecycle
|
|
43
|
-
|
|
44
|
-
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:
|
|
45
|
-
```
|
|
46
|
-
1. DISCOVER / REQUIREMENTS ──► Read-only inspection; Problem Space & operational constraints; INVEST stories & Gherkin.
|
|
47
|
-
2. INTERROGATE / DOMAIN ──► Relentless questioning; Ubiquitous Language, Aggregate invariants & state machines.
|
|
48
|
-
3. PLAN / OUTER TDD ──► Minimal blast radius; failing Outer Acceptance Test (UI/API RED).
|
|
49
|
-
4. EXECUTE / INNER TDD ──► Incremental nano-cycles (Uncle Bob's 3 Laws: 1 micro-assertion RED ➔ MINIMAL pass GREEN ➔ REFACTOR).
|
|
50
|
-
5. VERIFY / DoD & PROOF ──► Outer test turns GREEN; boundary smoke tests & 100.00% test coverage.
|
|
51
|
-
```
|
|
52
|
-
---
|
|
53
|
-
|
|
54
|
-
## 3. Progressive Disclosure: Specialized Domain Rules
|
|
55
|
-
|
|
56
|
-
To prevent context bloat and keep prompt overhead minimal, detailed engineering and architectural standards are decoupled into dedicated reference files. **Read these files on demand when working in the relevant domain:**
|
|
57
|
-
|
|
58
|
-
| Domain | Rule Reference File | When to Consult |
|
|
59
|
-
|---|---|---|
|
|
60
|
-
| **TDD & Isolation** | [docs/rules/test_driven_development.md](./docs/rules/test_driven_development.md) | Outside-In TDD, Uncle Bob's 3 Laws, 100% coverage, test isolation & DB rollback. |
|
|
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, Strategy, Result `<T, E>`, and GoF pattern catalog. |
|
|
63
|
-
| **Type Safety** | [docs/rules/type_safety.md](./docs/rules/type_safety.md) | Compiler strictness, branded nominal types, type discriminators across polyglot languages. |
|
|
64
|
-
| **Authentication** | [docs/rules/authentication.md](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
65
|
-
| **Authorization** | [docs/rules/authorization.md](./docs/rules/authorization.md) | CASL, OPA Rego policy engines, OpenFGA ReBAC, server guards. |
|
|
66
|
-
| **Multi-Tenancy** | [docs/rules/multitenancy_architecture.md](./docs/rules/multitenancy_architecture.md) | Tenant context, 4 isolation models, RLS, dynamic schemas, pluggable logic & YAGNI gates. |
|
|
67
|
-
| **API Architecture** | [docs/rules/api_architecture.md](./docs/rules/api_architecture.md) | HTTP status codes, sync vs async (202), `_actions`, idempotency keys, cursor pagination, OCC, versioning. |
|
|
68
|
-
| **Server-Driven UI** | [docs/rules/server_driven_ui.md](./docs/rules/server_driven_ui.md) | Backend-driven layout schemas, multi-renderer component registries, DTCG tokens & YAGNI gate. |
|
|
69
|
-
| **Database Design** | [docs/rules/database_design.md](./docs/rules/database_design.md) | Relational integrity, FKs, CHECK constraints, Canonical 6 audit fields, ACID transactions, Outbox CDC. |
|
|
70
|
-
| **Database Operations** | [docs/rules/database_operations.md](./docs/rules/database_operations.md) | Zero-downtime expand-contract migrations, N+1 elimination, DataLoader, indexing, pooling, PITR. |
|
|
71
|
-
| **Caching** | [docs/rules/caching.md](./docs/rules/caching.md) | Cache Port semantics, Cache-Aside, jittered TTLs, XFetch stampede defense & YAGNI gate. |
|
|
72
|
-
| **Security & Compliance** | [docs/rules/security_compliance.md](./docs/rules/security_compliance.md) | OWASP Top 10 defenses, rate limiting, crypto, SOC 2 Type II, ISO 27001, GDPR data erasure. |
|
|
73
|
-
| **DevOps & CI/CD** | [docs/rules/devops_ci_cd.md](./docs/rules/devops_ci_cd.md) | Shift-left trunk-based CI, OCI distroless containers, Secretlint/Trivy DevSecOps, zero-downtime CD. |
|
|
74
|
-
| **Cloud-Native 12-Factor** | [docs/rules/cloud_native.md](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
75
|
-
| **Error Architecture** | [docs/rules/error_handling.md](./docs/rules/error_handling.md) | Fail-fast schema validation, structured OTel/Pino tracing, RFC 7807 envelopes. |
|
|
76
|
-
| **Feature Flags** | [docs/rules/feature_flags.md](./docs/rules/feature_flags.md) | OpenFeature standard, Flipt/Unleash backends, targeting, kill switches & YAGNI gate. |
|
|
77
|
-
| **Transactional Email** | [docs/rules/transactional_email.md](./docs/rules/transactional_email.md) | Declarative templates (MJML/JSON), safe interpolation, SMTP integration testing. |
|
|
78
|
-
| **UI/UX Architecture** | [docs/rules/ui_ux_architecture.md](./docs/rules/ui_ux_architecture.md) | Design triage gate, persistent app shell, collapsible sidebar, dual-experience portals, dev persona. |
|
|
79
|
-
| **Frontend Architecture** | [docs/rules/frontend_architecture.md](./docs/rules/frontend_architecture.md) | Accessible headless primitives, WCAG 2.2 AA, server cache sync, form validation, 5-tier state, URL navigation. |
|
|
80
|
-
| **Requirements Engineering** | [docs/rules/requirements_engineering.md](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
81
|
-
| **Product Ownership** | [docs/rules/product_ownership.md](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
82
|
-
| **Project Management** | [docs/rules/project_management.md](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
83
|
-
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts, Aggregates, Capability Mapping. |
|
|
84
|
-
| **CQRS & Projections** | [docs/rules/cqrs.md](./docs/rules/cqrs.md) | Evolutionary CQRS spectrum, YAGNI defense, read projections, outbox CDC. |
|
|
85
|
-
| **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 & YAGNI gate. |
|
|
86
|
-
| **Agentic Governance** | [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) | Progressive disclosure, ADR ledger, workspace sovereignty, continuous learning, YAGNI gate triad. |
|
|
87
|
-
| **Relentless Questioning** | [docs/rules/relentless_questioning.md](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
88
|
-
---
|
|
89
|
-
|
|
90
|
-
## 4. Agent Configuration & Workspace Architecture
|
|
91
|
-
- **Progressive Disclosure Principle:** Never load all documentation upfront. Rely on the table above to pull specialized instructions only when performing relevant tasks.
|
|
92
|
-
- **Nested AGENTS.md for Monorepos:** In multi-package workspaces (e.g. `apps/backend`, `apps/frontend`), place package-specific conventions in nested `AGENTS.md` files scoped strictly to those subtrees.
|
|
93
|
-
- **Specialized Skills Catalog:** On-demand multi-step workflows are encapsulated under `.agents/skills/`:
|
|
94
|
-
- [`agentic-architect`](.agents/skills/agentic-architect/SKILL.md): Authoring, auditing, and modularizing agent configurations and skills.
|
|
95
|
-
- [`product-analyst`](.agents/skills/product-analyst/SKILL.md): Aligning OKRs, backlog ordering (Kano/MoSCoW/RICE), INVEST stories, and Gherkin criteria.
|
|
96
|
-
- [`compliance-audit`](.agents/skills/compliance-audit/SKILL.md): Conducting SOC 2, ISO 27001, and OWASP audits using open-source scanners.
|
|
97
|
-
- [`clean-code-refactor`](.agents/skills/clean-code-refactor/SKILL.md): Refactoring code smells with Clean Code, SOLID, and design patterns.
|
|
98
|
-
- [`lets-build`](.agents/skills/lets-build/SKILL.md): Conducting architecture interviews to finalize stack, frameworks, package managers, and bootstrapping projects.
|
|
99
|
-
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
100
|
-
- **Relentless Skill Architecture Inquiry:** Never author or update skills on assumptions. Interrogate all 7 inquiry branches (placement, trigger intent, domain truth, gotchas/anti-patterns, determinism, progressive bloat, verification loop) defined in [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) before writing `SKILL.md`.
|
|
101
|
-
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge/ubiquitous_language.md`](./docs/knowledge/ubiquitous_language.md) for domain glossaries.
|
|
102
|
-
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, `agents.md`, `GEMINI.md`, `.cursorrules`, `.windsurfrules`, and `.github/copilot-instructions.md` must remain identical via filesystem symbolic links to eliminate configuration divergence across different agent harnesses.
|
|
1
|
+
# AGENTS.md
|
|
2
|
+
|
|
3
|
+
> **azcodr: Enterprise Architecture & Agentic Engineering Starter Template**
|
|
4
|
+
> **Workspace Mission:** Problem-first, topology-aligned production architectures governed by strict systemic atomicity, 100% open-source standards, true incremental TDD nano-cycles, and zero speculative bloat.
|
|
5
|
+
> **Runtime & Tools:** Node.js (`>=18.0.0`), npm (`>=10.0.0`) | `npm test` (test runner), `npm run test:coverage` (100% gate), `npm run lint`, `npm run validate`.
|
|
6
|
+
> **Rule Zero:** Assume nothing. Every action must be grounded in verified evidence from this workspace or direct instructions from the user.
|
|
7
|
+
> **Atomicity Mandate:** All rules, skills, code units, migrations, and transactions must be strictly atomic (indivisible, self-contained, composable with full ACID safety).
|
|
8
|
+
> **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 backends, Platform Scripting for extensions, Data-Oriented Design for game engines, Command Pipeline for CLIs, Game Loop for canvas games).
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## 1. Zero-Assumption Operating Framework
|
|
13
|
+
### Core Principles
|
|
14
|
+
1. **No External Assumptions:** You have no prior knowledge of external setups, hidden tools, libraries, or unverified conventions outside this workspace.
|
|
15
|
+
2. **Ground Truth Only:** A statement is only true if proven by a workspace file, verified command output, or direct user instruction.
|
|
16
|
+
3. **Unknown Until Verified:** If something is not explicitly written in the workspace or stated by the user, treat it as unknown.
|
|
17
|
+
4. **Strict Open Standards:** Standardize on open-source solutions and open specs (Semgrep, Trivy, Gitleaks, OpenTelemetry, OPA, OCI, Wasm, CloudEvents).
|
|
18
|
+
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.
|
|
19
|
+
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.
|
|
20
|
+
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.
|
|
21
|
+
8. **Systemic Atomicity:** Every skill, rule, database transaction, and refactoring step must be atomic (Single Responsibility, zero side-effects, full rollback).
|
|
22
|
+
9. **Workspace Sovereignty:** Total containment within the local workspace root (`./`). Zero interference from global configs, tools, or sibling projects.
|
|
23
|
+
10. **Continuous Learning:** Ingest all verified defects, lessons, and architectural invariants directly into domain rules and `memory.md`.
|
|
24
|
+
|
|
25
|
+
### The 5 Core Branch Questions
|
|
26
|
+
Before acting on any decision branch, answer:
|
|
27
|
+
1. **Current State:** What do workspace files currently show? (Inspect before assuming).
|
|
28
|
+
2. **Target Goal:** Is the goal clear, bounded, and explicit? (Stop & ask if ambiguous).
|
|
29
|
+
3. **Tools & Setup:** Are tools defined in workspace configs? (Never assume commands exist).
|
|
30
|
+
4. **Impact & Risk:** Have all references, callers, and side effects been traced?
|
|
31
|
+
5. **Verification:** How will we prove it works with tests or build commands?
|
|
32
|
+
|
|
33
|
+
### Conflict Resolution & Order of Authority
|
|
34
|
+
1. **User Request (Current Session)** ➔ 2. **Workspace Configurations** (lockfiles, linters, scripts) ➔ 3. **Existing Code Patterns** ➔ 4. **Direct Confirmation (Stop & Ask)**.
|
|
35
|
+
|
|
36
|
+
### Action Boundaries
|
|
37
|
+
- **ALWAYS:** Read files before editing; verify commands before running; verify results with evidence.
|
|
38
|
+
- **ASK FIRST:** Adding/removing external dependencies; deleting/renaming files; changing DB schemas or build scripts; modifying existing tests.
|
|
39
|
+
- **NEVER:** Guess paths, flags, or signatures; silently ignore errors; bypass unresolved questions.
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## 2. Execution Lifecycle
|
|
43
|
+
|
|
44
|
+
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:
|
|
45
|
+
```
|
|
46
|
+
1. DISCOVER / REQUIREMENTS ──► Read-only inspection; Problem Space & operational constraints; INVEST stories & Gherkin.
|
|
47
|
+
2. INTERROGATE / DOMAIN ──► Relentless questioning; Ubiquitous Language, Aggregate invariants & state machines.
|
|
48
|
+
3. PLAN / OUTER TDD ──► Minimal blast radius; failing Outer Acceptance Test (UI/API RED).
|
|
49
|
+
4. EXECUTE / INNER TDD ──► Incremental nano-cycles (Uncle Bob's 3 Laws: 1 micro-assertion RED ➔ MINIMAL pass GREEN ➔ REFACTOR).
|
|
50
|
+
5. VERIFY / DoD & PROOF ──► Outer test turns GREEN; boundary smoke tests & 100.00% test coverage.
|
|
51
|
+
```
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 3. Progressive Disclosure: Specialized Domain Rules
|
|
55
|
+
|
|
56
|
+
To prevent context bloat and keep prompt overhead minimal, detailed engineering and architectural standards are decoupled into dedicated reference files. **Read these files on demand when working in the relevant domain:**
|
|
57
|
+
|
|
58
|
+
| Domain | Rule Reference File | When to Consult |
|
|
59
|
+
|---|---|---|
|
|
60
|
+
| **TDD & Isolation** | [docs/rules/test_driven_development.md](./docs/rules/test_driven_development.md) | Outside-In TDD, Uncle Bob's 3 Laws, 100% coverage, test isolation & DB rollback. |
|
|
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, Strategy, Result `<T, E>`, and GoF pattern catalog. |
|
|
63
|
+
| **Type Safety** | [docs/rules/type_safety.md](./docs/rules/type_safety.md) | Compiler strictness, branded nominal types, type discriminators across polyglot languages. |
|
|
64
|
+
| **Authentication** | [docs/rules/authentication.md](./docs/rules/authentication.md) | In-memory access tokens, refresh token rotation (RTR), WebAuthn passkeys. |
|
|
65
|
+
| **Authorization** | [docs/rules/authorization.md](./docs/rules/authorization.md) | CASL, OPA Rego policy engines, OpenFGA ReBAC, server guards. |
|
|
66
|
+
| **Multi-Tenancy** | [docs/rules/multitenancy_architecture.md](./docs/rules/multitenancy_architecture.md) | Tenant context, 4 isolation models, RLS, dynamic schemas, pluggable logic & YAGNI gates. |
|
|
67
|
+
| **API Architecture** | [docs/rules/api_architecture.md](./docs/rules/api_architecture.md) | HTTP status codes, sync vs async (202), `_actions`, idempotency keys, cursor pagination, OCC, versioning. |
|
|
68
|
+
| **Server-Driven UI** | [docs/rules/server_driven_ui.md](./docs/rules/server_driven_ui.md) | Backend-driven layout schemas, multi-renderer component registries, DTCG tokens & YAGNI gate. |
|
|
69
|
+
| **Database Design** | [docs/rules/database_design.md](./docs/rules/database_design.md) | Relational integrity, FKs, CHECK constraints, Canonical 6 audit fields, ACID transactions, Outbox CDC. |
|
|
70
|
+
| **Database Operations** | [docs/rules/database_operations.md](./docs/rules/database_operations.md) | Zero-downtime expand-contract migrations, N+1 elimination, DataLoader, indexing, pooling, PITR. |
|
|
71
|
+
| **Caching** | [docs/rules/caching.md](./docs/rules/caching.md) | Cache Port semantics, Cache-Aside, jittered TTLs, XFetch stampede defense & YAGNI gate. |
|
|
72
|
+
| **Security & Compliance** | [docs/rules/security_compliance.md](./docs/rules/security_compliance.md) | OWASP Top 10 defenses, rate limiting, crypto, SOC 2 Type II, ISO 27001, GDPR data erasure. |
|
|
73
|
+
| **DevOps & CI/CD** | [docs/rules/devops_ci_cd.md](./docs/rules/devops_ci_cd.md) | Shift-left trunk-based CI, OCI distroless containers, Secretlint/Trivy DevSecOps, zero-downtime CD. |
|
|
74
|
+
| **Cloud-Native 12-Factor** | [docs/rules/cloud_native.md](./docs/rules/cloud_native.md) | 12-Factor (2026 Edition), OpenTelemetry (OTel), stateless isolates. |
|
|
75
|
+
| **Error Architecture** | [docs/rules/error_handling.md](./docs/rules/error_handling.md) | Fail-fast schema validation, structured OTel/Pino tracing, RFC 7807 envelopes. |
|
|
76
|
+
| **Feature Flags** | [docs/rules/feature_flags.md](./docs/rules/feature_flags.md) | OpenFeature standard, Flipt/Unleash backends, targeting, kill switches & YAGNI gate. |
|
|
77
|
+
| **Transactional Email** | [docs/rules/transactional_email.md](./docs/rules/transactional_email.md) | Declarative templates (MJML/JSON), safe interpolation, SMTP integration testing. |
|
|
78
|
+
| **UI/UX Architecture** | [docs/rules/ui_ux_architecture.md](./docs/rules/ui_ux_architecture.md) | Design triage gate, persistent app shell, collapsible sidebar, dual-experience portals, dev persona. |
|
|
79
|
+
| **Frontend Architecture** | [docs/rules/frontend_architecture.md](./docs/rules/frontend_architecture.md) | Accessible headless primitives, WCAG 2.2 AA, server cache sync, form validation, 5-tier state, URL navigation. |
|
|
80
|
+
| **Requirements Engineering** | [docs/rules/requirements_engineering.md](./docs/rules/requirements_engineering.md) | User stories vs requirements, 3 C's, INVEST vertical cake slicing, Gherkin. |
|
|
81
|
+
| **Product Ownership** | [docs/rules/product_ownership.md](./docs/rules/product_ownership.md) | Product Backlog Management, OKRs, Kano/MoSCoW/RICE, Product Value, empiricism. |
|
|
82
|
+
| **Project Management** | [docs/rules/project_management.md](./docs/rules/project_management.md) | Work-In-Progress limits (WIP = 1), SMART developer tasks, Definition of Done. |
|
|
83
|
+
| **Domain-Driven Design** | [docs/rules/domain_driven_design.md](./docs/rules/domain_driven_design.md) | Ubiquitous Language, Bounded Contexts, Aggregates, Capability Mapping. |
|
|
84
|
+
| **CQRS & Projections** | [docs/rules/cqrs.md](./docs/rules/cqrs.md) | Evolutionary CQRS spectrum, YAGNI defense, read projections, outbox CDC. |
|
|
85
|
+
| **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 & YAGNI gate. |
|
|
86
|
+
| **Agentic Governance** | [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) | Progressive disclosure, ADR ledger, workspace sovereignty, continuous learning, YAGNI gate triad. |
|
|
87
|
+
| **Relentless Questioning** | [docs/rules/relentless_questioning.md](./docs/rules/relentless_questioning.md) | Dynamic context-aware interrogation loops, adaptive decision trees. |
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## 4. Agent Configuration & Workspace Architecture
|
|
91
|
+
- **Progressive Disclosure Principle:** Never load all documentation upfront. Rely on the table above to pull specialized instructions only when performing relevant tasks.
|
|
92
|
+
- **Nested AGENTS.md for Monorepos:** In multi-package workspaces (e.g. `apps/backend`, `apps/frontend`), place package-specific conventions in nested `AGENTS.md` files scoped strictly to those subtrees.
|
|
93
|
+
- **Specialized Skills Catalog:** On-demand multi-step workflows are encapsulated under `.agents/skills/`:
|
|
94
|
+
- [`agentic-architect`](.agents/skills/agentic-architect/SKILL.md): Authoring, auditing, and modularizing agent configurations and skills.
|
|
95
|
+
- [`product-analyst`](.agents/skills/product-analyst/SKILL.md): Aligning OKRs, backlog ordering (Kano/MoSCoW/RICE), INVEST stories, and Gherkin criteria.
|
|
96
|
+
- [`compliance-audit`](.agents/skills/compliance-audit/SKILL.md): Conducting SOC 2, ISO 27001, and OWASP audits using open-source scanners.
|
|
97
|
+
- [`clean-code-refactor`](.agents/skills/clean-code-refactor/SKILL.md): Refactoring code smells with Clean Code, SOLID, and design patterns.
|
|
98
|
+
- [`lets-build`](.agents/skills/lets-build/SKILL.md): Conducting architecture interviews to finalize stack, frameworks, package managers, and bootstrapping projects.
|
|
99
|
+
- [`relentless-questioner`](.agents/skills/relentless-questioner/SKILL.md): Dynamic context-aware interrogation loops before planning and coding.
|
|
100
|
+
- **Relentless Skill Architecture Inquiry:** Never author or update skills on assumptions. Interrogate all 7 inquiry branches (placement, trigger intent, domain truth, gotchas/anti-patterns, determinism, progressive bloat, verification loop) defined in [docs/rules/agentic_configuration.md](./docs/rules/agentic_configuration.md) before writing `SKILL.md`.
|
|
101
|
+
- **Workspace Memory & Knowledge Hub:** Consult [`memory.md`](./memory.md) for ADRs, and [`docs/knowledge/ubiquitous_language.md`](./docs/knowledge/ubiquitous_language.md) for domain glossaries.
|
|
102
|
+
- **Harness Parity & Symlinks:** `AGENTS.md`, `CLAUDE.md`, `agents.md`, `GEMINI.md`, `.cursorrules`, `.windsurfrules`, and `.github/copilot-instructions.md` must remain identical via filesystem symbolic links to eliminate configuration divergence across different agent harnesses.
|