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`.
|
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)
|
## Why (the wrinkle that started this)
|
||||||
|
|
||||||
Candidates for `is-a`/`subtype-of` were `instances-of("type")` — the *instances* that are
|
Candidates for `is-a`/`subtype-of` were `instances-of("type")` — the *instances* that are
|
||||||
|
|||||||
Reference in New Issue
Block a user