generated from coulomb/repo-seed
research: Glamorous Toolkit deep dive (moldable development); SHARD-WP-0004 T7
Moldable views (gtView) = open, type-keyed set of co-equal, computed projections, none canonical = a moldable view registry refining the projection model (T16). Lepiter live notebook over git files. Enrichment- only (UC-47/48/54); no new UC. Marks T7 done. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2
SCOPE.md
2
SCOPE.md
@@ -22,7 +22,7 @@ Learnings update both SCOPE and INTENT where necessary.
|
||||
| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki + Wikibase + git-forge wikis + TiddlyWiki + ikiwiki + Quip + MojoMojo + Oddmuse + UseModWiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
||||
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
||||
| Spec | Architecture blueprint drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
|
||||
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` active (8 computational-knowledge dives: T1 literate programming, T3 Jupyter done) |
|
||||
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` active (8 computational-knowledge dives: T1 literate programming, T3 Jupyter, T7 Glamorous Toolkit done) |
|
||||
|
||||
## In Scope (today)
|
||||
|
||||
|
||||
33
research/260614-glamorous-toolkit-deep-dive/README.md
Normal file
33
research/260614-glamorous-toolkit-deep-dive/README.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# 260614 — Glamorous Toolkit (moldable development) deep dive
|
||||
|
||||
Date: 2026-06-14 · Source: **SHARD-WP-0004 T7**
|
||||
|
||||
## What this is
|
||||
|
||||
A deep dive into **Glamorous Toolkit** (GT, on Pharo): **moldable development** — cheap,
|
||||
custom, **domain-specific views** (`gtView` methods) so any object explains itself through an
|
||||
**open set of co-equal projections, none canonical** — plus **Lepiter**, GT's live notebook/
|
||||
knowledge base (git-versionable JSON page files with live, inspectable code results).
|
||||
|
||||
## Why it matters
|
||||
|
||||
- Strongest prior art for **moldable, multi-view projection**: projection is not *a* view
|
||||
but an **open, type-keyed set of co-equal, possibly-computed views, none privileged** —
|
||||
refines SHARD-WP-0002 **T16** and unifies replication-/derivation-/dimensional-/query-
|
||||
projection under "many co-equal views."
|
||||
- Generalizes ZigZag dimensional views (UC-47/48) and query/computed views (UC-54) into a
|
||||
**pluggable view registry** keyed by content type (answers UC-55's open question on a
|
||||
content-type registry).
|
||||
- Reinforces **files-canonical, liveness-above, degrade-to-snapshot** (Lepiter files vs the
|
||||
Pharo image; same boundary as Jupyter UC-84 / Squeak T6).
|
||||
|
||||
## Yield
|
||||
|
||||
- **No new UC** (design prior art, not a candidate shard — like the UseModWiki lineage dive).
|
||||
- Enrich **UC-47, UC-48, UC-54**; links **UC-55, UC-83, UC-84, UC-79**.
|
||||
|
||||
## Contents
|
||||
|
||||
| Path | Role |
|
||||
|------|------|
|
||||
| `findings.md` | Moldable development & `gtView`, the Moldable Inspector, Lepiter, relation to ZigZag/query/derivation projection, INTENT mapping, UC disposition (enrichment-only), architecture notes, open questions |
|
||||
161
research/260614-glamorous-toolkit-deep-dive/findings.md
Normal file
161
research/260614-glamorous-toolkit-deep-dive/findings.md
Normal file
@@ -0,0 +1,161 @@
|
||||
# Glamorous Toolkit — deep dive (findings)
|
||||
|
||||
**Date:** 2026-06-14 · **Source:** SHARD-WP-0004 T7 · **Subject:** Glamorous Toolkit (GT) on
|
||||
Pharo — moldable development, custom views/inspectors, the live notebook (Lepiter).
|
||||
|
||||
## Why this dive
|
||||
|
||||
T1/T3 gave us **derivation-projection** (one source → rendered/computed forms). GT comes at
|
||||
projection from the *other* side: **many co-equal, domain-specific views over the same live
|
||||
content**, where the *environment molds itself to the knowledge* rather than forcing the
|
||||
knowledge into one fixed rendering. This is the strongest prior art for **moldable,
|
||||
multi-view projection** and a striking parallel to ZigZag's dimensional model (UC-47/48) and
|
||||
to query/computed views (UC-54). It is *design* prior art — GT is not a candidate shard —
|
||||
so the yield is **enrichment + projection design notes**, not a new shard UC.
|
||||
|
||||
## 1. Moldable development
|
||||
|
||||
GT's thesis: **systems should be explainable through custom tools that are cheap to build.**
|
||||
Instead of a single generic object inspector/renderer, a developer adds **small,
|
||||
domain-specific views** to a class so any instance explains itself in the terms that matter:
|
||||
|
||||
- **`gtView`-annotated methods** — a class declares extra inspector views by writing methods
|
||||
tagged `<gtView>` that return a view (tree, list, table, chart, source, raw, a custom
|
||||
diagram…). Each is a **co-equal projection of the same object**; none is privileged.
|
||||
- The **Moldable Inspector** shows these views as **switchable tabs** over one object, and
|
||||
lets you **dive** into sub-objects (each with its own custom views) — navigation *is*
|
||||
moving across projections.
|
||||
- Views are **cheap and local**: a view is just a method, versioned with the code, added
|
||||
incrementally as understanding grows. The environment **adapts to the domain**.
|
||||
|
||||
The key abstraction for us: **the same underlying content carries an open, extensible set of
|
||||
views, selected at inspection time, none canonical.**
|
||||
|
||||
## 2. Lepiter — the live notebook / knowledge base
|
||||
|
||||
GT ships **Lepiter**, a notebook/knowledge base where pages mix prose, **live code
|
||||
snippets** (evaluated in-image, results inspectable with the moldable views above), and
|
||||
links. Notebook pages are stored as **JSON "database" files** on disk (a Lepiter DB =
|
||||
directory of page files), so the knowledge base is **file-backed and git-versionable** while
|
||||
remaining live in the image.
|
||||
|
||||
This is the literate/notebook pattern (T1/T3) fused with moldable views: a snippet's result
|
||||
is not a static captured output but a **live object you can open into any of its views** —
|
||||
the *anti-snapshot*. (Boundary: that liveness is exactly what shard-wiki must degrade to a
|
||||
snapshot when the image isn't present — see §4.)
|
||||
|
||||
## 3. Relationship to ZigZag, query-views, and the projection model
|
||||
|
||||
- **vs ZigZag (UC-47/48):** ZigZag gives **dimensional** views — the *same cells* seen along
|
||||
different orthogonal axes. GT gives **moldable** views — the *same object* seen through
|
||||
different *purpose-built lenses*. Both reject a single privileged rendering; both make
|
||||
**multi-view, none-canonical** the norm. GT generalizes the idea from fixed dimensions to
|
||||
an **open, code-defined view set**.
|
||||
- **vs query/computed views (UC-54):** a `gtView` is a **computed projection** (it runs code
|
||||
to build the view) — like a query-defined page, but keyed to a **content type / domain**
|
||||
rather than a stored query. Strengthens "a view can be computed, not stored."
|
||||
- **vs derivation-projection (T1/UC-83):** GT confirms projections are **plural and
|
||||
co-equal**; UC-83/UC-84 had *few* well-known derivations (docs/code/outputs), GT has an
|
||||
**open registry** of them keyed by type.
|
||||
|
||||
So GT's contribution to the contract is: **projection is not one view but an open set of
|
||||
co-equal, type-keyed, possibly-computed views, none canonical** — a *moldable projection
|
||||
registry*. That is a refinement of T16's projection model, not a new shard.
|
||||
|
||||
## 4. INTENT mapping
|
||||
|
||||
### Reinforcements
|
||||
|
||||
- **Union without erasure / no privileged rendering.** GT's "many co-equal views, none
|
||||
canonical" is the same ethos as showing provenance/freshness without hiding any: a page's
|
||||
presentation is **plural**, and shard-wiki should be able to offer **multiple co-equal
|
||||
projections of the same content** (raw, rendered, structured, domain-specific) rather than
|
||||
one flattened view.
|
||||
- **Computed views (UC-54) keyed by content type.** A moldable view = a **computed
|
||||
projection registered against a content type** — directly supports a *pluggable view/
|
||||
projection registry* in the contract (the answer shape for UC-55's "pluggable content-type
|
||||
registry" open question).
|
||||
- **Files-canonical, live-on-top.** Lepiter stores pages as **git-versionable JSON files**
|
||||
while being live in the image — reinforcing "the durable artifact is files; liveness is a
|
||||
layer above," consistent with shard-wiki's git-canonical stance.
|
||||
- **Mechanism over policy.** Which views to show, and whether to compute or snapshot them,
|
||||
stay configurable; GT provides the *mechanism* (open view set), not a fixed presentation.
|
||||
|
||||
### Divergences / boundaries
|
||||
|
||||
- **The image is not a store (shared boundary with T6 Squeak).** GT's *liveness* lives in a
|
||||
Pharo image; shard-wiki must not treat the image as a shard. Attach the **Lepiter DB files**
|
||||
(git-versionable) as the durable content; treat live/computed views as **derivation-
|
||||
projections that degrade to captured snapshots** when no image/kernel is present (same rule
|
||||
as Jupyter UC-84).
|
||||
- **Not a view engine.** shard-wiki *models* "this content type has these co-equal views and
|
||||
one may be canonical-for-display"; it does not implement GT's rendering. Domain-specific
|
||||
view code stays with the source/adapter, surfaced as a capability.
|
||||
|
||||
### What to keep
|
||||
|
||||
1. **Moldable projection = an open, type-keyed set of co-equal, possibly-computed views,
|
||||
none canonical** — refine T16's projection model and the UC-47/48/54 cluster toward a
|
||||
**pluggable view/projection registry**.
|
||||
2. **Lepiter** = literate/notebook (T1/T3) with **live results** stored as git-versionable
|
||||
files — another "files-canonical, liveness-above, degrade-to-snapshot" instance.
|
||||
3. **Navigation = moving across projections** (dive into sub-objects) — a navigation idea
|
||||
beside dimensional movement (UC-47/48) for the derived-views thread.
|
||||
|
||||
## 5. UC disposition (enrichment-only — no new shard UC)
|
||||
|
||||
| Mechanism (findings §) | Catalog UC |
|
||||
|------------------------|------------|
|
||||
| Many co-equal, domain-specific views over the same content; none canonical (§1, §3) | UC-47 / UC-48 (enriched) |
|
||||
| `gtView` = a **computed projection registered against a content type** (§1, §3) | UC-54 (enriched) |
|
||||
| Open, pluggable view set keyed by type = the shape of a content-type/view registry (§3) | links UC-55 (open-Q #10) |
|
||||
| Lepiter live-snippet results = live objects → degrade to snapshot when no image (§2, §4) | links UC-84, UC-83 |
|
||||
| Lepiter pages = git-versionable JSON files; image is not the store (§2, §4) | links UC-79 (files-canonical) |
|
||||
| Dive-into-sub-object navigation = moving across projections (§1) | links UC-17–UC-20 (derived views) |
|
||||
|
||||
GT is **design prior art, not a candidate shard**, so it yields **no new UC** (like the
|
||||
UseModWiki lineage dive). Its value is sharpening the **projection model** for SHARD-WP-0002
|
||||
T16: projection is an **open set of co-equal, type-keyed, possibly-computed views, none
|
||||
privileged** — a moldable view registry.
|
||||
|
||||
## 6. Architecture notes for SHARD-WP-0002
|
||||
|
||||
- **T16 (projection):** generalize projection from "a view" to a **moldable view registry** —
|
||||
an open, extensible set of **co-equal, type-keyed, possibly-computed** projections of the
|
||||
same content, none canonical (display-canonical is a policy choice, not a fact). This
|
||||
unifies replication-projection (UC-53/57), derivation-projection (UC-83/84), dimensional
|
||||
views (UC-47/48), and query/computed views (UC-54) under one "many co-equal views" model.
|
||||
- **T12 (page model):** a content type may **carry/declare its own views** (a capability);
|
||||
the page model should allow attaching view definitions to a type (the registry's entries),
|
||||
answering UC-55's "pluggable content-type registry" question.
|
||||
- **Boundary (T14):** attach the **Lepiter DB files** (durable, git-versionable), never the
|
||||
Pharo image; live/computed views are derivation-projections degrading to snapshots — same
|
||||
rule as Jupyter (no kernel/image host).
|
||||
|
||||
## 7. Open questions
|
||||
|
||||
1. Does shard-wiki expose a **view/projection registry** as a first-class public concept
|
||||
(content type → its co-equal views), or keep "moldable" as an adapter-internal idea?
|
||||
2. When multiple co-equal views exist, is **"canonical-for-display"** a per-shard policy, a
|
||||
user preference, or unset (always show the chooser)? (Mechanism-over-policy says
|
||||
configurable.)
|
||||
3. How does a **computed view** (UC-54/`gtView`) declare its **freshness/provenance** so the
|
||||
union doesn't present a stale computed projection as current? (Ties UC-84's snapshot
|
||||
marking.)
|
||||
|
||||
## 8. Sources
|
||||
|
||||
- Glamorous Toolkit docs (`gtoolkit.com`): moldable development, the Moldable Inspector,
|
||||
`gtView` methods, Lepiter knowledge base; Feenk essays on moldable development.
|
||||
- Pharo (substrate — see T8 dive): live image, reflective environment.
|
||||
- prior: `research/260614-zigzag-deep-dive/` (dimensional multi-view UC-47/48);
|
||||
`research/260614-jupyter-deep-dive/` (live vs snapshot, UC-84);
|
||||
`research/260614-literate-programming-deep-dive/` (derivation-projection, UC-83).
|
||||
|
||||
## 9. Traceability
|
||||
|
||||
**No new UC** (GT is design prior art, not a candidate shard). Enriched: UC-47, UC-48,
|
||||
UC-54; links UC-55 (content-type/view registry), UC-83/UC-84 (live→snapshot), UC-79
|
||||
(files-canonical), UC-17–UC-20 (derived-view navigation). Architecture cross-refs:
|
||||
SHARD-WP-0002 T16 (moldable view registry: open set of co-equal type-keyed computed views),
|
||||
T12 (content type declares its views), T14 (attach Lepiter files, not the image).
|
||||
@@ -38,4 +38,5 @@ when multiple files or sources are involved. Findings here inform `spec/` and
|
||||
| 2026-06-14 | `260614-oddmuse-deep-dive/` | Oddmuse — single Perl CGI, plain-text `page/` files + `keep/` revisions, no DB; the minimal file-store floor / graceful-degradation baseline; partial-history honesty; UC-82 |
|
||||
| 2026-06-14 | `260614-usemodwiki-deep-dive/` | UseModWiki — flat-file ancestor (Wikipedia's MediaWiki Phase I); CamelCase linking; lineage grounding for the minimal file-store floor; enrichment-only (reinforces UC-82, UC-25) |
|
||||
| 2026-06-14 | `260614-literate-programming-deep-dive/` | Literate programming (Knuth's WEB / weave / tangle) — one source → N co-equal derived projections (docs + code); named-chunk transclusion; splits replication- vs derivation-projection; SHARD-WP-0004 T1; UC-83 |
|
||||
| 2026-06-14 | `260614-jupyter-deep-dive/` | Jupyter Notebooks — `.ipynb` JSON cells + embedded computed outputs with fragile execution provenance; derived output stored *inside* the source; non-Markdown/lossy; kernel = capability; SHARD-WP-0004 T3; UC-84 |
|
||||
| 2026-06-14 | `260614-jupyter-deep-dive/` | Jupyter Notebooks — `.ipynb` JSON cells + embedded computed outputs with fragile execution provenance; derived output stored *inside* the source; non-Markdown/lossy; kernel = capability; SHARD-WP-0004 T3; UC-84 |
|
||||
| 2026-06-14 | `260614-glamorous-toolkit-deep-dive/` | Glamorous Toolkit (moldable development on Pharo) — `gtView` open set of co-equal type-keyed computed views (none canonical) = moldable view registry; Lepiter live notebook over git files; SHARD-WP-0004 T7; enrichment-only (UC-47/48/54) |
|
||||
@@ -2401,6 +2401,34 @@ for history when the shard is git. Architecture logged for `SHARD-WP-0002` (T12/
|
||||
notebook page shape, lossy non-Markdown + MIME opacity, paired-text history, output =
|
||||
derivation-projection snapshot.
|
||||
|
||||
### glamorous-toolkit mapping
|
||||
|
||||
(Lineage dive — **no new UC**; design prior art, not a candidate shard. Source: the
|
||||
**Glamorous Toolkit deep dive**, `research/260614-glamorous-toolkit-deep-dive/findings.md`.)
|
||||
|
||||
| GT mechanism (findings §) | Catalog UC |
|
||||
|---------------------------|------------|
|
||||
| Many co-equal, domain-specific views over the same content; none canonical (§1, §3) | UC-47 / UC-48 (enriched) |
|
||||
| `gtView` = a **computed projection registered against a content type** (§1, §3) | UC-54 (enriched) |
|
||||
| Open, pluggable view set keyed by type = a content-type/view registry (§3) | links UC-55 (open-Q #10) |
|
||||
| Lepiter live-snippet results = live objects → degrade to snapshot when no image (§2, §4) | links UC-84, UC-83 |
|
||||
| Lepiter pages = git-versionable JSON files; image is not the store (§2, §4) | links UC-79 |
|
||||
| Dive-into-sub-object navigation = moving across projections (§1) | links UC-17–UC-20 |
|
||||
|
||||
Note: Glamorous Toolkit (moldable development on Pharo) is **design prior art**, not a
|
||||
candidate shard, so it adds **no new UC**. Its contribution is sharpening the **projection
|
||||
model**: a `gtView`-annotated object exposes an **open, type-keyed set of co-equal,
|
||||
possibly-computed views, none canonical** — generalizing ZigZag dimensional views (UC-47/48)
|
||||
and query/computed views (UC-54) into a **moldable view registry**. Its **Lepiter** notebook
|
||||
(live code results over git-versionable JSON page files) is another **files-canonical,
|
||||
liveness-above, degrade-to-snapshot** instance (boundary shared with Jupyter UC-84 and Squeak
|
||||
T6: attach the files, never the image). **Boundary recorded:** shard-wiki *models* "this
|
||||
content type has these co-equal views (one may be display-canonical *by policy*)"; it does
|
||||
not implement the view engine, and live/computed views degrade to snapshots. Architecture
|
||||
logged for `SHARD-WP-0002` (T16/T12/T14): a moldable view registry unifying replication-/
|
||||
derivation-/dimensional-/query-projection; content types declaring their views; attach
|
||||
Lepiter files, not the Pharo image.
|
||||
|
||||
---
|
||||
|
||||
## Open questions
|
||||
|
||||
@@ -156,7 +156,7 @@ inspiration).
|
||||
|
||||
```task
|
||||
id: SHARD-WP-0004-T7
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "9e11efac-92d1-4226-b532-7d916a26c70b"
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user