shard-wiki/research/260614-glamorous-toolkit-deep-dive/findings.md

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).