plan: north star — the metamodel as a system-construction kit
Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 17s
Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 17s
Name the destination: the host becomes a self-describing metamodel where you define a domain (types + relations with signatures/algebra) and a working system falls out — the blog is one seeded configuration. Most instance UI is already generic (relation editors iterate the relations, pickers come from declares-anchors, validation from :schema), so 'define the types' is mostly a metamodel editor + a generic instance form + a clear-and-reseed. Frames Slices 6-7 as the schema language this is for. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -11,6 +11,31 @@ itself in its own graph.
|
||||
|
||||
Supersedes the hardcoded `:candidates "types"/"tags"/"all"` field of `host/blog-rel-kinds`.
|
||||
|
||||
## North star — the metamodel as a system-construction kit
|
||||
|
||||
The destination this is all heading toward: the host stops being "a blog" and becomes a
|
||||
**self-describing metamodel**. You *define a domain* — types (with schemas/refinements) and
|
||||
relations (with role signatures + algebra) — and a working system falls out. The blog content
|
||||
is one seeded configuration; clear it and define different types and you have a different system
|
||||
on the same engine. Framework, not application (cf. `[[feedback_runtime_control]]`,
|
||||
`[[project_zero_dependencies]]`).
|
||||
|
||||
Most of the **instance UI is already generic** — the edit page's relation editors are generated
|
||||
by iterating the relations; each picker's candidates come from the relation's `declares`-anchor /
|
||||
role type; validation comes from the type's `:schema`. So once Slices 6–7 land, "define the
|
||||
types" through a UI is mostly two surfaces, plus a reset:
|
||||
|
||||
1. **Metamodel editor** — create a type-post (give it a schema/refinement); create a relation-post
|
||||
(give it a role signature + algebra). The thing that lets you *construct* a system.
|
||||
2. **Generic instance form** — create/edit any post of any type, driven entirely by the
|
||||
definitions above (the relation editors + pickers + save-time validation we already have).
|
||||
3. **Clear-and-reseed** — wipe instance data, seed only the metamodel roots (`type`, `relation`,
|
||||
the core relations); start from a bare kit and build a domain up from nothing.
|
||||
|
||||
Sequence: finish the schema language (Slices 6–7) → the two UI surfaces + reset → clear the demo
|
||||
data and define a real domain through the UI. The slices below are the schema language; this is
|
||||
what it's *for*.
|
||||
|
||||
## Why (the wrinkle that started this)
|
||||
|
||||
Candidates for `is-a`/`subtype-of` were `instances-of("type")` — the *instances* that are
|
||||
|
||||
Reference in New Issue
Block a user