You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce higher-order, generator-oriented metadata to the schema DSL: .lifecycle(), .policy(), .events(), and .meta(). Add AST types for LifecycleDef, PolicyDef, EventDef and wire them into the builder/runtime (builders expose the new chainable methods and perform lazy validation). Add structured error codes for lifecycle/policy/events and extend the error-preview test output. Also update architecture/docs (CLAUDE.md) to describe the metadata-oriented approach and add comprehensive unit tests for meta, lifecycle, policy and events handling. Changes include AST/type updates, builder validations (lifecycle/event checks), and multiple new runtime tests.
Copy file name to clipboardExpand all lines: CLAUDE.md
+28-9Lines changed: 28 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,20 @@ task check # Run lint + vuln + test
46
46
47
47
## Architecture Overview
48
48
49
-
AstrolaDB is a **polyglot code generator** with a Go core that embeds a JavaScript runtime (Goja) to execute user-written schemas and generators.
49
+
AstrolaDB is a **documentation-oriented meta-model system** that captures higher-order system metadata through a declarative JavaScript DSL. It's fundamentally about modeling system intent across multiple dimensions — structural, behavioral, and operational — making this metadata consumable by generators and documentation tooling.
50
+
51
+
### What is Higher-Order System Metadata?
52
+
53
+
AstrolaDB schemas are **not just database schemas**. They encode:
**Migrations are just one built-in core** that consumes structural metadata to generate SQL. Generators consume the full metadata graph to produce application code, documentation, infrastructure templates, and more.
50
63
51
64
### Three-Layer Architecture
52
65
@@ -66,10 +79,11 @@ AstrolaDB is a **polyglot code generator** with a Go core that embeds a JavaScri
**Unified Error Pipeline — Schemas, Migrations, and Generators:**
127
+
**Unified Error Pipeline — All DSL Features:**
112
128
113
-
All three JS file types (schemas, migrations, generators) execute through the **same Sandbox** and must follow the **same error pipeline**:
129
+
All JavaScript DSL features (table definitions with higher-order metadata, manual migrations, custom generators) execute through the **same Sandbox** and must follow the **same error pipeline**:
114
130
115
131
1. JS code executes in Goja VM → validation errors `panic(vm.ToValue(string))`
116
132
2. Goja captures the JS call site (line:col) in the Exception stack
@@ -192,6 +208,8 @@ help: try `col.belongs_to('namespace.table')` or `col.belongs_to('.table')` for
192
208
193
209
**Consistency rule:** If a new DSL feature (schema, migration, or generator) can produce an error, it MUST go through the same pipeline and produce this same format. Test with `CRITICAL` prefix tests in `error_pipeline_test.go`.
194
210
211
+
**Error preview rule:** Every new error MUST be added to `TestPreviewAllErrors` in `internal/runtime/preview_errors_test.go`. This visual test renders every structured error with `cli.FormatError()` so developers can inspect formatting. Run with `go test -run TestPreviewAllErrors ./internal/runtime/ -v -count=1` or `task preview-errors`.
212
+
195
213
### Help Text Style Guide (Cargo conventions)
196
214
197
215
All `help:` text follows Rust/Cargo conventions for consistency:
@@ -235,13 +253,14 @@ All `help:` text follows Rust/Cargo conventions for consistency:
235
253
236
254
### Project Philosophy (from CONTRIBUTING.md)
237
255
238
-
**Four Core Principles:**
256
+
**Five Core Principles:**
239
257
240
258
1.**Simple** - One way to do things. No config options where a default will do.
241
259
2.**Boring** - No magic. Predictable behavior. Convention over configuration.
242
260
-**ALL validation should happen during JavaScript execution**, not post-parse
243
261
3.**Deterministic** - Same input = same output, always.
244
262
4.**JS-Friendly** - All types safe in JavaScript (no int64, float64, etc.)
263
+
5.**Documentation-Oriented** - Schemas are living documentation capturing system intent across structural, behavioral, and operational dimensions. All higher-order metadata is **declarative and generator-consumable only** — no runtime enforcement.
0 commit comments