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