create-living-architecture 1.1.0 → 2.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.living-arch/SYSTEM.md +26 -0
- package/.living-arch/architecture.json +6 -0
- package/README.md +535 -0
- package/installer.js +42 -0
- package/package.json +10 -27
- package/src/app/__init__.py +16 -0
- package/src/app/__pycache__/__init__.cpython-314.pyc +0 -0
- package/src/app/__pycache__/validation-workflow.cpython-314.pyc +0 -0
- package/src/app/installer-workflow.js +56 -0
- package/src/app/validation-workflow.py +184 -0
- package/src/config/SYSTEM.md +58 -0
- package/src/config/changes.json +11 -0
- package/src/config/execution.json +9 -0
- package/src/config/f-tags.json +12 -0
- package/src/config/interfaces.json +16 -0
- package/src/config/modules.json +19 -0
- package/src/config/operations.json +272 -0
- package/src/config/r-layers.json +111 -0
- package/src/contract/cli/la-new.sh +64 -0
- package/src/contract/cli/network-scan.py +195 -0
- package/src/contract/hooks/commit-msg +17 -0
- package/src/contract/hooks/pre-commit +4 -0
- package/src/domain/__init__.py +20 -0
- package/src/domain/__pycache__/__init__.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/config_loader.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/la-output.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/validate-changes.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/validate-execution.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/validate-f-tags.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/validate-operations.cpython-314.pyc +0 -0
- package/src/domain/__pycache__/validate-r-layers.cpython-314.pyc +0 -0
- package/src/domain/config_loader.py +84 -0
- package/src/domain/installer-logic.js +30 -0
- package/src/domain/la-output.py +46 -0
- package/src/domain/validate-changes.py +60 -0
- package/src/domain/validate-execution.py +91 -0
- package/src/domain/validate-f-tags.py +93 -0
- package/src/domain/validate-operations.py +100 -0
- package/src/domain/validate-r-layers.py +202 -0
- package/src/exec/__init__.py +21 -0
- package/src/exec/__pycache__/__init__.cpython-314.pyc +0 -0
- package/src/exec/__pycache__/file-io.cpython-314.pyc +0 -0
- package/src/exec/__pycache__/git-io.cpython-314.pyc +0 -0
- package/src/exec/__pycache__/module-loader.cpython-314.pyc +0 -0
- package/src/exec/file-io.py +99 -0
- package/src/exec/git-io.py +59 -0
- package/src/exec/installer-io.js +36 -0
- package/src/exec/module-loader.py +29 -0
- package/index.js +0 -79
- package/template/ARCHITECTURE.md +0 -56
- package/template/README.md +0 -28
- package/template/src/api/README.md +0 -13
- package/template/src/database/README.md +0 -13
- package/template/src/domain/README.md +0 -12
- package/template/src/integrations/README.md +0 -13
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Living Architecture - Development Guide
|
|
2
|
+
|
|
3
|
+
When working on LA itself, follow gravitational principles:
|
|
4
|
+
|
|
5
|
+
## R-Layers
|
|
6
|
+
- **R0** `src/config/` - Configuration JSON files
|
|
7
|
+
- **R1** `src/domain/` - Pure validation logic
|
|
8
|
+
- **R2** `src/app/` - Workflow orchestration
|
|
9
|
+
- **R3** `src/contract/` - Hooks and CLI
|
|
10
|
+
- **R4** `src/exec/` - Git and file I/O
|
|
11
|
+
|
|
12
|
+
## Commit Format
|
|
13
|
+
`[F-feature/R#/C#] Description`
|
|
14
|
+
|
|
15
|
+
Examples:
|
|
16
|
+
- `[F-r-layers/R1/C2] Add dependency validator`
|
|
17
|
+
- `[F-network-scan/R3/C2] Add CLI interface`
|
|
18
|
+
|
|
19
|
+
## The 5 F-Tags
|
|
20
|
+
- F-r-layers - R-layer validation
|
|
21
|
+
- F-f-tags - F-tag validation
|
|
22
|
+
- F-execution - Runtime pattern validation
|
|
23
|
+
- F-operations - O-rule validation
|
|
24
|
+
- F-changes - Change tracking
|
|
25
|
+
|
|
26
|
+
LA validates itself using these same rules.
|
package/README.md
ADDED
|
@@ -0,0 +1,535 @@
|
|
|
1
|
+
# Living Architecture v2.0
|
|
2
|
+
|
|
3
|
+
**Self-organizing code framework for AI-assisted development**
|
|
4
|
+
|
|
5
|
+
Living Architecture (LA) creates gravitational fields that cause code to organize itself. Instead of enforcing rules, LA establishes physics—code naturally settles at equilibrium points based on dependency weight, feature boundaries, and runtime characteristics.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Core Principle
|
|
10
|
+
|
|
11
|
+
**Code is not organized. Code self-organizes.**
|
|
12
|
+
|
|
13
|
+
Traditional frameworks impose structure through enforcement. LA establishes conditions where structure emerges naturally. AI coding within LA doesn't follow rules—it operates within physical constraints that guide code to its natural position.
|
|
14
|
+
|
|
15
|
+
This is not metaphor. This is how the system functions.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## The Physics
|
|
20
|
+
|
|
21
|
+
### Gravitational Layers (R0-R4)
|
|
22
|
+
|
|
23
|
+
Code settles at different gravitational depths based on dependency weight:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
R0 (Config) ← Deepest gravity well
|
|
27
|
+
↓ Pure configuration, zero dependencies
|
|
28
|
+
|
|
29
|
+
R1 (Domain) ← Heavy logic settles here
|
|
30
|
+
↓ Pure functions, business rules
|
|
31
|
+
↓ Depends: R0 only
|
|
32
|
+
|
|
33
|
+
R2 (Application) ← Orchestration floats here
|
|
34
|
+
↓ Workflows, coordination
|
|
35
|
+
↓ Depends: R0, R1, R4
|
|
36
|
+
|
|
37
|
+
R3 (Contract) ← Interface boundary
|
|
38
|
+
↓ APIs, hooks, CLI
|
|
39
|
+
↓ Depends: R0, R1, R2
|
|
40
|
+
|
|
41
|
+
R4 (Execution) ← Lightest, I/O operations
|
|
42
|
+
↓ File systems, networks, databases
|
|
43
|
+
↓ Depends: R0 only
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
**Dependency direction is gravitational flow.** Heavy elements cannot import from lighter elements. R4 (execution) cannot pull from R3 (contract). Violations create unstable structures that validators detect.
|
|
47
|
+
|
|
48
|
+
### Feature Manifolds (F-Tags)
|
|
49
|
+
|
|
50
|
+
Features are vertical manifolds cutting through all R-layers:
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
F-auth F-payment F-analytics
|
|
54
|
+
│ │ │
|
|
55
|
+
R0 ─────┼───────────┼─────────────┼─────
|
|
56
|
+
│ │ │
|
|
57
|
+
R1 ─────┼───────────┼─────────────┼─────
|
|
58
|
+
│ │ │
|
|
59
|
+
R2 ─────┼───────────┼─────────────┼─────
|
|
60
|
+
│ │ │
|
|
61
|
+
R3 ─────┼───────────┼─────────────┼─────
|
|
62
|
+
│ │ │
|
|
63
|
+
R4 ─────┼───────────┼─────────────┼─────
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
Each feature requires presence across minimum R-layers (R1, R3, R4 by default). Missing layers indicate incomplete implementation. This is structural completeness, not functional completeness—validators detect topology, not semantics.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## The Seven Dimensions
|
|
71
|
+
|
|
72
|
+
LA operates across seven orthogonal dimensions. Each dimension has three states: **Structure** (defined in R0 config), **Validation** (implemented in R1 logic), **Application** (executed in R2-R4).
|
|
73
|
+
|
|
74
|
+
### 1. R-Layers (Structural Hierarchy)
|
|
75
|
+
|
|
76
|
+
**R0 Config:** `r-layers.json`
|
|
77
|
+
**Validation:** Dependency direction + circular dependency detection
|
|
78
|
+
**Purpose:** Gravitational organization—code settles by weight
|
|
79
|
+
|
|
80
|
+
Heavy logic (complex business rules) naturally falls to R1. Light I/O operations float to R4. The framework doesn't enforce this—gravity does.
|
|
81
|
+
|
|
82
|
+
### 2. F-Tags (Feature Manifolds)
|
|
83
|
+
|
|
84
|
+
**R0 Config:** `f-tags.json`
|
|
85
|
+
**Validation:** Structural completeness across R-layers
|
|
86
|
+
**Purpose:** Vertical slicing—features span full stack
|
|
87
|
+
|
|
88
|
+
Features exist as continuous manifolds. A feature present in R1 and R3 but missing R4 indicates incomplete implementation (likely missing I/O layer).
|
|
89
|
+
|
|
90
|
+
### 3. Execution (Runtime Topology)
|
|
91
|
+
|
|
92
|
+
**R0 Config:** `execution.json`
|
|
93
|
+
**Validation:** I/O ownership, state machines, coordination patterns, flow paths
|
|
94
|
+
**Purpose:** Runtime structural integrity
|
|
95
|
+
|
|
96
|
+
Detects:
|
|
97
|
+
- Multiple I/O owners (unstable concurrency)
|
|
98
|
+
- Incomplete state machines (undefined transitions)
|
|
99
|
+
- Coordination conflicts (competing orchestrators)
|
|
100
|
+
- Broken flow paths (unreachable code)
|
|
101
|
+
|
|
102
|
+
### 4. Operations (System Integrity)
|
|
103
|
+
|
|
104
|
+
**R0 Config:** `operations.json`
|
|
105
|
+
**Validation:** O1-O7 safety patterns
|
|
106
|
+
**Purpose:** Immune response—detect structural threats
|
|
107
|
+
|
|
108
|
+
**O1** - Access Control: Authentication boundaries
|
|
109
|
+
**O2** - Traffic Management: Rate limiting, throttling
|
|
110
|
+
**O3** - Reliability: Error handling, timeouts
|
|
111
|
+
**O4** - Performance: Algorithmic complexity
|
|
112
|
+
**O5** - Observability: Logging, metrics
|
|
113
|
+
**O6** - Configuration: External config, no hardcoded secrets
|
|
114
|
+
**O7** - Data Safety: SQL injection, XSS prevention
|
|
115
|
+
|
|
116
|
+
Validators detect base-case violations through pattern matching. This is structural analysis, not semantic understanding.
|
|
117
|
+
|
|
118
|
+
### 5. Changes (Temporal Evolution)
|
|
119
|
+
|
|
120
|
+
**R0 Config:** `changes.json`
|
|
121
|
+
**Validation:** Format compliance (C1-C5)
|
|
122
|
+
**Purpose:** Historical classification—memory encoding
|
|
123
|
+
|
|
124
|
+
**C1** - Internal: Refactoring, no external surface change
|
|
125
|
+
**C2** - Feature: New functionality
|
|
126
|
+
**C3** - Contract: API/interface modification
|
|
127
|
+
**C4** - Structure: R-layer reorganization
|
|
128
|
+
**C5** - Migration: Dependency updates, data schema changes
|
|
129
|
+
|
|
130
|
+
Changes are logged, not enforced. Classification enables temporal analysis (feature evolution, breaking change frequency).
|
|
131
|
+
|
|
132
|
+
### 6. Modules (Subsystem Boundaries)
|
|
133
|
+
|
|
134
|
+
**R0 Config:** `modules.json`
|
|
135
|
+
**Validation:** Naming pattern detection + cross-module warnings
|
|
136
|
+
**Purpose:** Component isolation within R-layers
|
|
137
|
+
|
|
138
|
+
Convention: `{module}-{component}.ext`
|
|
139
|
+
|
|
140
|
+
```
|
|
141
|
+
R1/domain/
|
|
142
|
+
auth-login.py ← M-auth
|
|
143
|
+
auth-session.py ← M-auth
|
|
144
|
+
payment-process.py ← M-payment
|
|
145
|
+
payment-refund.py ← M-payment
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
Modules span R-layers vertically. Validators detect module boundaries and warn on cross-module coupling. Enforcement is optional—detection provides visibility.
|
|
149
|
+
|
|
150
|
+
### 7. Interfaces (Boundary Contracts)
|
|
151
|
+
|
|
152
|
+
**R0 Config:** `interfaces.json`
|
|
153
|
+
**Validation:** Documentation only (manual)
|
|
154
|
+
**Purpose:** Layer communication protocols
|
|
155
|
+
|
|
156
|
+
Defines expected signatures between R-layers. Currently documentation-based. Future versions may add contract enforcement.
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## Configuration-Driven Architecture
|
|
161
|
+
|
|
162
|
+
All behavior defined in R0 configuration:
|
|
163
|
+
|
|
164
|
+
```
|
|
165
|
+
src/config/
|
|
166
|
+
├── r-layers.json # Defines R0-R4, dependency rules
|
|
167
|
+
├── f-tags.json # Feature completeness requirements
|
|
168
|
+
├── execution.json # Runtime pattern definitions
|
|
169
|
+
├── operations.json # O1-O7 safety rules
|
|
170
|
+
├── changes.json # C1-C5 classifications
|
|
171
|
+
├── modules.json # Module naming convention
|
|
172
|
+
└── interfaces.json # Layer contracts (manual)
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
Validators read from R0 at runtime. Modifying config changes system behavior without code changes. This is not configuration-as-code—this is configuration-as-physics.
|
|
176
|
+
|
|
177
|
+
Want to add R5? Edit `r-layers.json`. Validators automatically recognize the new layer. The gravitational field adapts.
|
|
178
|
+
|
|
179
|
+
---
|
|
180
|
+
|
|
181
|
+
## AI Integration
|
|
182
|
+
|
|
183
|
+
### How AI Uses LA
|
|
184
|
+
|
|
185
|
+
**Traditional approach:**
|
|
186
|
+
```
|
|
187
|
+
Developer: "Put auth code in the auth folder"
|
|
188
|
+
AI: Follows instruction, creates /auth/login.js
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
**Living Architecture:**
|
|
192
|
+
```
|
|
193
|
+
AI reads: src/config/SYSTEM.md
|
|
194
|
+
AI detects: R1 = pure logic, no I/O
|
|
195
|
+
AI senses: auth-login requires session state (R1)
|
|
196
|
+
Code settles: src/domain/auth-login.py
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
The framework doesn't instruct—it creates conditions. AI operates within gravitational fields and naturally places code at stable equilibrium points.
|
|
200
|
+
|
|
201
|
+
### Multi-Session Coherence
|
|
202
|
+
|
|
203
|
+
**Without LA:**
|
|
204
|
+
- Session 1: AI creates auth in `/utils/authentication.js`
|
|
205
|
+
- Session 2: Different AI instance creates auth in `/services/auth.js`
|
|
206
|
+
- Session 3: Two auth systems, coupling chaos
|
|
207
|
+
|
|
208
|
+
**With LA:**
|
|
209
|
+
- Session 1: AI reads SYSTEM.md, creates `R1/domain/auth-login.py`
|
|
210
|
+
- Session 2: Different AI reads same config, finds existing auth in R1
|
|
211
|
+
- Session 3: Single coherent system, maintained across context resets
|
|
212
|
+
|
|
213
|
+
LA provides persistent structure across ephemeral AI sessions. The framework outlives any single context window.
|
|
214
|
+
|
|
215
|
+
### Self-Validation
|
|
216
|
+
|
|
217
|
+
LA validates itself:
|
|
218
|
+
|
|
219
|
+
```bash
|
|
220
|
+
# Every commit runs validation
|
|
221
|
+
git commit -m "[F-auth/R1/C2] Add session validation"
|
|
222
|
+
|
|
223
|
+
# Pre-commit hook executes:
|
|
224
|
+
# → R-layer validator (dependency check + circular deps)
|
|
225
|
+
# → F-tag validator (structural completeness)
|
|
226
|
+
# → Execution validator (runtime patterns)
|
|
227
|
+
# → Operations validator (O-rule compliance)
|
|
228
|
+
# → Changes validator (C-code format)
|
|
229
|
+
|
|
230
|
+
# Output:
|
|
231
|
+
Living Architecture ━━━━━━━━━━━━━━━━━━━
|
|
232
|
+
|
|
233
|
+
[F-auth/R1/C2] Add session validation
|
|
234
|
+
|
|
235
|
+
Modules: M-auth
|
|
236
|
+
R-layers ✓
|
|
237
|
+
F-auth ⚠ 3/4 layers (missing R4)
|
|
238
|
+
Execution ✓
|
|
239
|
+
QC ✓
|
|
240
|
+
C-code ✓ C2
|
|
241
|
+
|
|
242
|
+
COMMIT ALLOWED (with warnings)
|
|
243
|
+
|
|
244
|
+
━━━━━━━━━━━━━━━━━━━━━━━ Living Architecture
|
|
245
|
+
```
|
|
246
|
+
|
|
247
|
+
The system monitors its own structural integrity. Violations are detected at commit-time, before they propagate.
|
|
248
|
+
|
|
249
|
+
---
|
|
250
|
+
|
|
251
|
+
## Installation
|
|
252
|
+
|
|
253
|
+
### Quick Start
|
|
254
|
+
|
|
255
|
+
```bash
|
|
256
|
+
# Extract
|
|
257
|
+
tar -xzf living-architecture-v2.0-FINAL-CLEAN.tar.gz
|
|
258
|
+
cd living-architecture-v2.0-FINAL
|
|
259
|
+
|
|
260
|
+
# Test the framework
|
|
261
|
+
python3 test-la.py
|
|
262
|
+
|
|
263
|
+
# Install in your project
|
|
264
|
+
cp -r src/ /path/to/your/project/
|
|
265
|
+
ln -s /path/to/src/contract/hooks/pre-commit /path/to/your/project/.git/hooks/
|
|
266
|
+
```
|
|
267
|
+
|
|
268
|
+
### Verification
|
|
269
|
+
|
|
270
|
+
```bash
|
|
271
|
+
# Test end-to-end
|
|
272
|
+
python3 test-la.py
|
|
273
|
+
|
|
274
|
+
# Tests run in hierarchical order:
|
|
275
|
+
# 1. R0 - Config layer (JSON validity)
|
|
276
|
+
# 2. R1 - Domain validators (syntax check)
|
|
277
|
+
# 3. R2 - Workflow orchestration
|
|
278
|
+
# 4. R3 - Contract interfaces
|
|
279
|
+
# 5. R4 - Execution I/O
|
|
280
|
+
# 6. Integration (cross-layer imports)
|
|
281
|
+
# 7. Self-validation (LA follows LA rules)
|
|
282
|
+
# 8. Config-driven (no hardcoded values)
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
---
|
|
286
|
+
|
|
287
|
+
## Usage
|
|
288
|
+
|
|
289
|
+
### Commit Format
|
|
290
|
+
|
|
291
|
+
```
|
|
292
|
+
[F-{feature}/R{layer}/C{code}] Description
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
**Examples:**
|
|
296
|
+
```bash
|
|
297
|
+
[F-auth/R1/C2] Add password validation logic
|
|
298
|
+
[F-payment/R4/C2] Integrate Stripe API
|
|
299
|
+
[F-checkout/R2/C1] Refactor cart workflow
|
|
300
|
+
```
|
|
301
|
+
|
|
302
|
+
### Health Monitoring
|
|
303
|
+
|
|
304
|
+
```bash
|
|
305
|
+
# Scan entire project
|
|
306
|
+
python3 src/contract/cli/network-scan.py
|
|
307
|
+
|
|
308
|
+
# Analyze specific feature
|
|
309
|
+
python3 src/contract/cli/network-scan.py F-auth
|
|
310
|
+
|
|
311
|
+
# Output shows:
|
|
312
|
+
# - R-layer distribution
|
|
313
|
+
# - Module composition
|
|
314
|
+
# - Structural completeness
|
|
315
|
+
# - Recent activity
|
|
316
|
+
```
|
|
317
|
+
|
|
318
|
+
---
|
|
319
|
+
|
|
320
|
+
## What LA Validates
|
|
321
|
+
|
|
322
|
+
### Structural Integrity
|
|
323
|
+
- ✓ Dependency direction (R4 cannot import R3)
|
|
324
|
+
- ✓ Circular dependencies (within same R-layer)
|
|
325
|
+
- ✓ Feature completeness (R1+R3+R4 minimum)
|
|
326
|
+
- ✓ I/O ownership (single owner per operation)
|
|
327
|
+
- ✓ State machine topology (all transitions defined)
|
|
328
|
+
|
|
329
|
+
### Safety Patterns
|
|
330
|
+
- ✓ Missing authentication (O1)
|
|
331
|
+
- ✓ Missing error handling (O3)
|
|
332
|
+
- ✓ Hardcoded secrets (O6)
|
|
333
|
+
- ✓ SQL injection patterns (O7)
|
|
334
|
+
- ✓ Basic performance anti-patterns (O4)
|
|
335
|
+
|
|
336
|
+
### Organizational Coherence
|
|
337
|
+
- ✓ C-code format (C1-C5 valid)
|
|
338
|
+
- ✓ Module detection (naming convention)
|
|
339
|
+
- ✓ Cross-module warnings (coupling visibility)
|
|
340
|
+
|
|
341
|
+
### What LA Does NOT Validate
|
|
342
|
+
|
|
343
|
+
- ✗ Business logic correctness
|
|
344
|
+
- ✗ Functional completeness
|
|
345
|
+
- ✗ Deep security analysis
|
|
346
|
+
- ✗ Performance optimization
|
|
347
|
+
- ✗ Semantic understanding
|
|
348
|
+
|
|
349
|
+
LA validates structure, not semantics. It detects architectural violations, not logical errors.
|
|
350
|
+
|
|
351
|
+
---
|
|
352
|
+
|
|
353
|
+
## The Efficiency Gain
|
|
354
|
+
|
|
355
|
+
### Where 10-40x Improvement Occurs
|
|
356
|
+
|
|
357
|
+
**Multi-session development:**
|
|
358
|
+
Without LA: 10 sessions to untangle organizational chaos = 5 hours
|
|
359
|
+
With LA: Clean structure from start = 30 minutes
|
|
360
|
+
**Gain: 10x**
|
|
361
|
+
|
|
362
|
+
**Team + AI collaboration:**
|
|
363
|
+
Without LA: Weekly cleanup sessions = 4 hours/week
|
|
364
|
+
With LA: Maintained coherence = 0 hours/week
|
|
365
|
+
**Gain: ∞**
|
|
366
|
+
|
|
367
|
+
**Refactoring:**
|
|
368
|
+
Without LA: 3 days fixing cascade breakage
|
|
369
|
+
With LA: 2 hours isolated changes
|
|
370
|
+
**Gain: 12x**
|
|
371
|
+
|
|
372
|
+
**Code review:**
|
|
373
|
+
Without LA: 20 minutes analyzing impact
|
|
374
|
+
With LA: 30 seconds checking R-layer violations
|
|
375
|
+
**Gain: 40x**
|
|
376
|
+
|
|
377
|
+
### Where LA Adds Overhead
|
|
378
|
+
|
|
379
|
+
- Solo developer, single session, small project: **0.9x** (slower)
|
|
380
|
+
- Prototyping/exploration: **0.7x** (structure inhibits discovery)
|
|
381
|
+
|
|
382
|
+
LA optimizes for maintainability across time and collaborators, not initial development speed.
|
|
383
|
+
|
|
384
|
+
---
|
|
385
|
+
|
|
386
|
+
## Technical Architecture
|
|
387
|
+
|
|
388
|
+
### File Structure (26 files)
|
|
389
|
+
|
|
390
|
+
```
|
|
391
|
+
living-architecture-v2.0/
|
|
392
|
+
├── package.json
|
|
393
|
+
├── README.md
|
|
394
|
+
├── CHANGELOG.md
|
|
395
|
+
├── INSTALL.md
|
|
396
|
+
├── test-la.py
|
|
397
|
+
├── .living-arch/
|
|
398
|
+
│ ├── architecture.json
|
|
399
|
+
│ └── SYSTEM.md
|
|
400
|
+
└── src/
|
|
401
|
+
├── config/ # R0 - 8 configuration files
|
|
402
|
+
├── domain/ # R1 - 6 validators
|
|
403
|
+
├── app/ # R2 - 1 workflow orchestrator
|
|
404
|
+
├── contract/ # R3 - 2 interface files
|
|
405
|
+
└── exec/ # R4 - 2 I/O modules
|
|
406
|
+
```
|
|
407
|
+
|
|
408
|
+
### Cross-Hash Matrix
|
|
409
|
+
|
|
410
|
+
```
|
|
411
|
+
R0 Config R1 Validate R2/R3/R4 Apply
|
|
412
|
+
═════════ ═══════════ ══════════════
|
|
413
|
+
R-LAYERS ✓ ✓ ✓
|
|
414
|
+
F-TAGS ✓ ✓ ✓
|
|
415
|
+
EXEC ✓ ✓ ✓
|
|
416
|
+
OPS ✓ ✓ ✓
|
|
417
|
+
CHANGES ✓ ✓ ✓
|
|
418
|
+
MODULES ✓ ✓ ✓
|
|
419
|
+
IFACES ✓ - ✓
|
|
420
|
+
```
|
|
421
|
+
|
|
422
|
+
7 dimensions × 3 states = 21 decision points
|
|
423
|
+
All pointing to R0 configuration
|
|
424
|
+
Zero hardcoded behavior
|
|
425
|
+
|
|
426
|
+
---
|
|
427
|
+
|
|
428
|
+
## Philosophy
|
|
429
|
+
|
|
430
|
+
### Emergence Over Enforcement
|
|
431
|
+
|
|
432
|
+
LA does not tell code where to go. LA creates gravitational fields. Code finds its own equilibrium.
|
|
433
|
+
|
|
434
|
+
### Structure Enables Freedom
|
|
435
|
+
|
|
436
|
+
Constraints create possibility space. R-layer gravity doesn't limit—it guides. Within each layer, infinite organizational freedom exists.
|
|
437
|
+
|
|
438
|
+
### Self-Organization Requires Physics
|
|
439
|
+
|
|
440
|
+
Random systems don't self-organize. They require:
|
|
441
|
+
1. **Fields** (R-layers provide gravity)
|
|
442
|
+
2. **Boundaries** (F-tags define manifolds)
|
|
443
|
+
3. **Feedback** (Validators detect instability)
|
|
444
|
+
4. **Memory** (Changes encode history)
|
|
445
|
+
|
|
446
|
+
These aren't features. These are prerequisites for living systems.
|
|
447
|
+
|
|
448
|
+
### AI as Inhabitant, Not Operator
|
|
449
|
+
|
|
450
|
+
AI doesn't use LA. AI inhabits LA. The framework is environment, not tool.
|
|
451
|
+
|
|
452
|
+
Traditional: AI follows instructions
|
|
453
|
+
Living Architecture: AI senses fields and responds naturally
|
|
454
|
+
|
|
455
|
+
This is why multi-session coherence works. The fields persist. AI comes and goes. Structure remains.
|
|
456
|
+
|
|
457
|
+
---
|
|
458
|
+
|
|
459
|
+
## Limitations
|
|
460
|
+
|
|
461
|
+
LA validates architecture, not implementation:
|
|
462
|
+
|
|
463
|
+
- Cannot determine business logic correctness
|
|
464
|
+
- Cannot guarantee functional completeness
|
|
465
|
+
- Cannot detect all security vulnerabilities
|
|
466
|
+
- Cannot optimize performance
|
|
467
|
+
- Cannot prevent all coupling
|
|
468
|
+
|
|
469
|
+
These require human judgment. LA creates conditions for better code. Humans determine what "better" means for their domain.
|
|
470
|
+
|
|
471
|
+
---
|
|
472
|
+
|
|
473
|
+
## Version
|
|
474
|
+
|
|
475
|
+
**Living Architecture v2.0**
|
|
476
|
+
Released: February 2026
|
|
477
|
+
Status: Production-ready
|
|
478
|
+
License: MIT
|
|
479
|
+
|
|
480
|
+
### What's New in v2.0
|
|
481
|
+
|
|
482
|
+
- Circular dependency detection (R-layer validator)
|
|
483
|
+
- Basic O-rule pattern matching (Operations validator)
|
|
484
|
+
- Module naming awareness (R0 config + detection)
|
|
485
|
+
- Interface documentation convention (R0 config)
|
|
486
|
+
- Comprehensive end-to-end test suite
|
|
487
|
+
- Complete config-driven architecture (zero hardcoding)
|
|
488
|
+
|
|
489
|
+
### Upgrade from v1.x
|
|
490
|
+
|
|
491
|
+
v2.0 is complete reconception, not incremental update:
|
|
492
|
+
- v1.1: 39 validation scripts, R0-R5 layers
|
|
493
|
+
- v2.0: 26 files total, R0-R4 layers, self-consistent
|
|
494
|
+
|
|
495
|
+
Migration requires fresh installation. v1.x and v2.0 are incompatible.
|
|
496
|
+
|
|
497
|
+
---
|
|
498
|
+
|
|
499
|
+
## Contributing
|
|
500
|
+
|
|
501
|
+
LA validates itself. All contributions must pass:
|
|
502
|
+
|
|
503
|
+
```bash
|
|
504
|
+
python3 test-la.py # Must pass all tests
|
|
505
|
+
```
|
|
506
|
+
|
|
507
|
+
Commit format: `[F-{feature}/R{layer}/C{code}] Description`
|
|
508
|
+
|
|
509
|
+
The framework eats its own dog food. Code that doesn't follow LA rules cannot be committed to LA.
|
|
510
|
+
|
|
511
|
+
---
|
|
512
|
+
|
|
513
|
+
## Support
|
|
514
|
+
|
|
515
|
+
- Issues: GitHub Issues
|
|
516
|
+
- Documentation: `INSTALL.md`
|
|
517
|
+
- Examples: See `.living-arch/SYSTEM.md`
|
|
518
|
+
|
|
519
|
+
---
|
|
520
|
+
|
|
521
|
+
## The Core Truth
|
|
522
|
+
|
|
523
|
+
**Code doesn't need to be organized.**
|
|
524
|
+
**Code needs conditions to self-organize.**
|
|
525
|
+
|
|
526
|
+
**Living Architecture provides the physics.**
|
|
527
|
+
**Code finds its own structure.**
|
|
528
|
+
|
|
529
|
+
**This is not framework.**
|
|
530
|
+
**This is genesis.**
|
|
531
|
+
|
|
532
|
+
---
|
|
533
|
+
|
|
534
|
+
*Living Architecture v2.0 - Self-organizing code framework*
|
|
535
|
+
*Where structure emerges from physics, not rules*
|
package/installer.js
ADDED
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
/**
|
|
3
|
+
* installer.js - R3 Contract (npx entry point)
|
|
4
|
+
*
|
|
5
|
+
* Usage:
|
|
6
|
+
* npx living-architecture <project-name>
|
|
7
|
+
* node installer.js <project-name>
|
|
8
|
+
*/
|
|
9
|
+
|
|
10
|
+
const workflow = require('./src/app/installer-workflow');
|
|
11
|
+
|
|
12
|
+
const WIDTH = 60;
|
|
13
|
+
const BORDER = '═'.repeat(WIDTH);
|
|
14
|
+
const CENTER = (s) => s.padStart(Math.floor((WIDTH + s.length) / 2)).padEnd(WIDTH);
|
|
15
|
+
|
|
16
|
+
const projectName = process.argv[2];
|
|
17
|
+
|
|
18
|
+
if (!projectName) {
|
|
19
|
+
console.log(`\nUsage: npx living-architecture <project-name>`);
|
|
20
|
+
console.log(`Example: npx living-architecture my-app\n`);
|
|
21
|
+
process.exit(1);
|
|
22
|
+
}
|
|
23
|
+
|
|
24
|
+
console.log(`\n${BORDER}`);
|
|
25
|
+
console.log(CENTER('LIVING ARCHITECTURE'));
|
|
26
|
+
console.log(`${BORDER}\n`);
|
|
27
|
+
console.log(` Creating project: ${projectName}`);
|
|
28
|
+
|
|
29
|
+
const result = workflow.run(projectName);
|
|
30
|
+
|
|
31
|
+
if (!result.success) {
|
|
32
|
+
console.log(`\n ✗ ${result.error}`);
|
|
33
|
+
console.log(`\n${BORDER}\n`);
|
|
34
|
+
process.exit(1);
|
|
35
|
+
}
|
|
36
|
+
|
|
37
|
+
console.log(`\n ✓ Project created: ${result.targetDir}/`);
|
|
38
|
+
console.log(` ✓ Git initialized`);
|
|
39
|
+
console.log(` ✓ Hooks installed`);
|
|
40
|
+
console.log(` ✓ Initial commit done`);
|
|
41
|
+
console.log(`\n Ready: cd ${result.projectName}`);
|
|
42
|
+
console.log(`\n${BORDER}\n`);
|
package/package.json
CHANGED
|
@@ -1,40 +1,23 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-living-architecture",
|
|
3
|
-
"version": "
|
|
4
|
-
"description": "
|
|
5
|
-
"main": "index.js",
|
|
3
|
+
"version": "2.0.0",
|
|
4
|
+
"description": "Gravitational code organization for AI-assisted development",
|
|
6
5
|
"bin": {
|
|
7
|
-
"create-living-architecture": "
|
|
6
|
+
"create-living-architecture": "./installer.js"
|
|
8
7
|
},
|
|
9
8
|
"files": [
|
|
10
|
-
"
|
|
11
|
-
"
|
|
9
|
+
"installer.js",
|
|
10
|
+
"src/",
|
|
11
|
+
".living-arch/"
|
|
12
12
|
],
|
|
13
|
-
"
|
|
14
|
-
|
|
15
|
-
},
|
|
16
|
-
"keywords": [
|
|
17
|
-
"architecture",
|
|
18
|
-
"code-organization",
|
|
19
|
-
"ai-coding",
|
|
20
|
-
"clean-architecture",
|
|
21
|
-
"git-hooks",
|
|
22
|
-
"scaffolding",
|
|
23
|
-
"gravitational-design",
|
|
24
|
-
"r0-r5",
|
|
25
|
-
"pluggable-layers"
|
|
26
|
-
],
|
|
27
|
-
"author": "Demos Ra",
|
|
13
|
+
"keywords": ["architecture", "ai-coding", "git-hooks", "code-organization"],
|
|
14
|
+
"author": "Demos RA",
|
|
28
15
|
"license": "MIT",
|
|
29
16
|
"repository": {
|
|
30
17
|
"type": "git",
|
|
31
|
-
"url": "https://github.com/demos-ra/living-architecture
|
|
32
|
-
},
|
|
33
|
-
"bugs": {
|
|
34
|
-
"url": "https://github.com/demos-ra/living-architecture/issues"
|
|
18
|
+
"url": "https://github.com/demos-ra/living-architecture"
|
|
35
19
|
},
|
|
36
|
-
"homepage": "https://github.com/demos-ra/living-architecture#readme",
|
|
37
20
|
"engines": {
|
|
38
|
-
"node": ">=
|
|
21
|
+
"node": ">=14.0.0"
|
|
39
22
|
}
|
|
40
23
|
}
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
"""R2 Application package — auto-discovers .py modules
|
|
2
|
+
Bootstrap exception: imports module_loader from R4 (exec) to load hyphenated filenames.
|
|
3
|
+
This is a package-init-only exception; no other R2 file may import from R4 except workflows.
|
|
4
|
+
"""
|
|
5
|
+
from pathlib import Path
|
|
6
|
+
from exec import module_loader
|
|
7
|
+
|
|
8
|
+
_dir = Path(__file__).parent
|
|
9
|
+
|
|
10
|
+
# Auto-discover all .py files (except __init__)
|
|
11
|
+
for _f in sorted(_dir.glob('*.py')):
|
|
12
|
+
if _f.stem == '__init__':
|
|
13
|
+
continue
|
|
14
|
+
_name = _f.stem.replace('-', '_')
|
|
15
|
+
_mod = module_loader.load_module(f'app.{_name}', _f)
|
|
16
|
+
globals()[_name] = _mod
|
|
Binary file
|
|
Binary file
|