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