research: Processing / p5.js deep dive; SHARD-WP-0004 T4

Program-as-page rendered live at view time (no cached output). Adds
materialization-timing (ahead-of-time vs view-time) + continuity
(one-shot vs continuous) facets to the projection model; execute-in-viewer
= capability+trust. Enrichment-only (UC-54/55). Marks T4 done.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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, T2 Mathematica, T3 Jupyter, T6 Squeak + T8 Pharo (merged), T7 Glamorous Toolkit 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, T2 Mathematica, T3 Jupyter, T4 Processing, T6 Squeak + T8 Pharo (merged), T7 Glamorous Toolkit done) |
 
 ## In Scope (today)
 

research/260614-processing-deep-dive/README.md

@@ -0,0 +1,30 @@
+# 260614 — Processing & Processing.js deep dive
+
+Date: 2026-06-14 · Source: **SHARD-WP-0004 T4**
+
+## What this is
+
+A deep dive into **Processing** (creative coding) and **Processing.js / p5.js** (browser-run
+sketches): **the sketch *is* the document** — a program whose presentation is **live visual
+output rendered at view time** in the browser, with **no cached output** by default.
+
+## Why it matters
+
+- The cleanest **program-as-page** case: canonical content = **source text**, presentation =
+  **executable render** (no input/output cells, no prose envelope) — sharpens the page model
+  (T12/T15) and UC-54/55.
+- Adds a **view-time** variant to derivation-projection (the render runs **in the viewer,
+  continuously**) and a **continuity** facet (one-shot vs continuous/interactive); continuous
+  → static is a **snapshot frame/recording** on the live↔snapshot axis (T6).
+- "Execute/render in the viewer" = an explicit **capability + trust/sandbox** surface.
+
+## Yield
+
+- **No new UC** (enrichment / design prior art). Enriches **UC-54, UC-55**; links UC-83,
+  UC-84, UC-35.
+
+## Contents
+
+| Path | Role |
+|------|------|
+| `findings.md` | Program-as-page, view-time/live render, no-cached-output, capability+trust, INTENT mapping, UC disposition (enrichment-only), architecture notes |

research/260614-processing-deep-dive/findings.md

@@ -0,0 +1,114 @@
+# Processing & Processing.js — deep dive (findings)
+
+**Date:** 2026-06-14 · **Source:** SHARD-WP-0004 T4 · **Subject:** Processing (creative
+coding) and Processing.js / p5.js — **the sketch *is* the document**, rendered live at view
+time in the browser.
+
+## Why this dive
+
+Low-priority, enrichment-focused. Processing tests a page-model edge the notebooks (T2/T3)
+didn't: a page that is **wholly a program whose presentation *is* its running output** — no
+separate input/output cells, no prose envelope. The defining question: what is a "page" when
+**the rendered form is a live computation evaluated at view time**? It feeds UC-54
+(computation-defined content) and UC-55 (non-Markdown / executable content) and sharpens the
+**live↔snapshot** axis named at T6.
+
+## 1. Program-as-page
+
+- A **Processing sketch** is a program (`setup()` + `draw()`) whose output is a **canvas of
+  visual/animated/interactive content**. There are no "output cells" — **the program's
+  execution is the content**.
+- **Processing.js** (Resig, 2008; now largely **p5.js**) runs sketches **client-side in the
+  browser** on `<canvas>`. The page ships the **source**; the **rendering happens at view
+  time** in the reader's browser — no server, no pre-rendered artifact required.
+- So the durable artifact is **text (the sketch source)**; the *presentation* is a **live,
+  view-time derivation** of that source (a derivation-projection, T1) — with the twist that
+  the derivation runs **in the viewer**, continuously (animation/interaction), not once.
+
+## 2. The view-time / live-render dimension
+
+This adds a wrinkle beyond Jupyter's *captured* outputs (UC-84) and Mathematica's CDF:
+
+- **No captured output at all by default** — unlike a notebook, a sketch typically stores
+  **only source**; there is nothing cached. The output exists only when executed.
+- **Continuous & interactive** — `draw()` loops; mouse/keyboard drive it. The output is
+  **time-based and interaction-based**, so any static capture is a **single frame** (or a
+  recording) — it cannot represent the artifact faithfully (shared limit with Mathematica
+  `Dynamic` and, more extremely, Strudel T5).
+- **Client-side execution = a capability + trust surface** — running arbitrary sketch code in
+  the viewer is an execution capability with sandboxing concerns; shard-wiki must treat
+  "render live in the viewer" as an explicit, gated capability, never an automatic behavior.
+
+## 3. INTENT mapping (enrichment-only — no new UC)
+
+### Reinforcements / refinements
+
+- **Executable-as-page (UC-54/55).** Processing is the cleanest **"the whole page is the
+  program"** case: content = source text, presentation = view-time live render. Strengthens
+  the page model's need to represent **executable content whose rendered form is derived at
+  view time**, distinct from notebooks (which interleave cells + captured outputs).
+- **Derivation-projection, view-time variant (T1/UC-83).** The render is a derivation-
+  projection that runs **in the viewer, continuously** — extends the projection model: a
+  derivation may be *materialized ahead* (CDF/nbconvert) or *run at view time* (sketch).
+- **Live↔snapshot axis (T6).** With **no cached output** and **continuous/interactive**
+  rendering, the only static form is a **snapshot frame or recording** — a concrete point on
+  the live↔snapshot axis; honest treatment offers the snapshot and **marks it as a frame of a
+  live artifact**, never as the artifact.
+- **Capability + trust gating.** "Execute in the viewer" is an explicit capability with a
+  sandbox/trust boundary — mechanism-over-policy: whether to run, sandbox, or only snapshot
+  stays configurable.
+
+### Boundaries
+
+- shard-wiki is **not a sketch runtime**; default is **attach the source + offer a captured
+  snapshot/recording**; live in-viewer rendering is a gated capability. Source is canonical;
+  the render is a degrading, view-time projection.
+
+## 4. UC disposition (enrichment-only)
+
+| Mechanism (findings §) | Catalog UC / thread |
+|------------------------|---------------------|
+| Sketch = program-as-page; presentation = view-time live render (§1) | UC-54 (enriched: executable/view-time content), UC-55 (enriched: non-Markdown executable) |
+| Render = derivation-projection run **in the viewer, continuously** (§1, §2) | links UC-83 (view-time variant) |
+| No cached output; continuous/interactive → static = snapshot frame only (§2) | links UC-84, live↔snapshot axis (T6) |
+| Client-side execution = capability + trust/sandbox surface (§2) | links UC-35 (capability-awareness) |
+
+**No new UC** — Processing is design prior art reinforcing executable-as-page; its
+contribution is the **view-time, no-cached-output, continuous-render** point on the
+projection/liveness model.
+
+## 5. Architecture notes for SHARD-WP-0002
+
+- **T12/T15 (page model):** represent **program-as-page** — a page whose canonical content is
+  **source text** and whose presentation is an **executable render**; no inherent cached
+  output (contrast notebooks). Non-Markdown executable content type.
+- **T16 (projection):** add a **materialization timing** facet to derivation-projection:
+  **ahead-of-time** (CDF/nbconvert/static HTML) vs **at view time** (sketch render); and a
+  **continuity** facet: one-shot vs continuous/interactive. Continuous → static is a snapshot
+  frame/recording on the live↔snapshot axis (T6).
+- **T11 (capabilities):** "execute/render in the viewer" is a capability with a **trust/
+  sandbox** sub-concern; default off → snapshot.
+
+## 6. Open questions
+
+1. Is **view-time execution** ever offered (sandboxed in-viewer render), or does shard-wiki
+   always degrade program-as-page to a captured snapshot/recording? (Capability/trust policy.)
+2. Should **materialization timing** (ahead-of-time vs view-time) and **continuity**
+   (one-shot vs continuous) be explicit projection metadata, alongside the live↔snapshot
+   axis? (Recurs at T5.)
+
+## 7. Sources
+
+- `processing.org`; **p5.js** (`p5js.org`); Processing.js (Resig) history; `<canvas>` /
+  client-side rendering model.
+- prior: `research/260614-jupyter-deep-dive/` (captured vs no-cached output, UC-84);
+  `research/260614-mathematica-deep-dive/` (`Dynamic`/CDF, snapshot-only);
+  `research/260614-squeak-pharo-deep-dive/` (live↔snapshot axis).
+
+## 8. Traceability
+
+**No new UC** (enrichment / design prior art). Enriched: UC-54, UC-55; links UC-83 (view-time
+derivation-projection), UC-84 (no-cached-output contrast), UC-35 (execute capability +
+trust). Architecture cross-refs: SHARD-WP-0002 T12/T15 (program-as-page, source-canonical/
+render-derived), T16 (materialization-timing + continuity facets on the live↔snapshot axis),
+T11 (view-time-execute capability + sandbox).

research/README.md

@@ -41,4 +41,5 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 | 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) |
 | 2026-06-14 | `260614-mathematica-deep-dive/` | Mathematica Notebooks — the original computational notebook (`.nb` = a Wolfram expression); nestable cell groups, structured re-evaluable outputs, `Manipulate` live widgets, CDF; confirms UC-84 notebook shape is a genus; SHARD-WP-0004 T2; enrichment-only (reinforces UC-84; UC-54/55) |
-| 2026-06-14 | `260614-squeak-pharo-deep-dive/` | Squeak & Pharo (image-based Smalltalk) — the live-object image (purest "live" end); image-is-not-a-store boundary (export→files only); Pharo Tonel/Iceberg externalizes code to git text; names the live↔snapshot projection axis; SHARD-WP-0004 **T6 + T8** (merged); boundary/enrichment-only, no new UC |
+| 2026-06-14 | `260614-squeak-pharo-deep-dive/` | Squeak & Pharo (image-based Smalltalk) — the live-object image (purest "live" end); image-is-not-a-store boundary (export→files only); Pharo Tonel/Iceberg externalizes code to git text; names the live↔snapshot projection axis; SHARD-WP-0004 **T6 + T8** (merged); boundary/enrichment-only, no new UC |
+| 2026-06-14 | `260614-processing-deep-dive/` | Processing / p5.js — program-as-page rendered live at view time (no cached output); adds materialization-timing + continuity facets to projection; execute-in-viewer = capability+trust; SHARD-WP-0004 T4; enrichment-only (UC-54/55) |

spec/UseCaseCatalog.md

@@ -2486,6 +2486,30 @@ batch's spectrum). **No new UC.** Architecture logged for `SHARD-WP-0002` (T14/T
 image-is-not-a-store binding boundary (export→files only); a live↔snapshot axis on every
 projection.
 
+### processing mapping
+
+(Enrichment dive — **no new UC**; design prior art. Source: the **Processing deep dive**,
+`research/260614-processing-deep-dive/findings.md`.)
+
+| Processing mechanism (findings §) | Catalog UC / thread |
+|-----------------------------------|---------------------|
+| Sketch = program-as-page; presentation = view-time live render (§1) | UC-54 / UC-55 (enriched) |
+| Render = derivation-projection run **in the viewer, continuously** (§1, §2) | links UC-83 (view-time variant) |
+| No cached output; continuous/interactive → static = snapshot frame only (§2) | links UC-84, live↔snapshot axis |
+| Client-side execution = capability + trust/sandbox surface (§2) | links UC-35 |
+
+Note: Processing / p5.js is the cleanest **program-as-page** case — the whole page is a
+program whose **presentation is its running output, rendered at view time** in the browser,
+with **no cached output** (contrast notebooks UC-84). It adds two facets to the projection
+model: **materialization timing** (ahead-of-time CDF/static vs **view-time** sketch render)
+and **continuity** (one-shot vs **continuous/interactive**); a continuous artifact's only
+static form is a **snapshot frame/recording** on the live↔snapshot axis. "Execute/render in
+the viewer" is an explicit **capability with a trust/sandbox** sub-concern. **Boundary
+recorded:** shard-wiki is **not a sketch runtime** — default attach the **source** + offer a
+captured snapshot/recording; live in-viewer rendering is gated. **No new UC.** Architecture
+logged for `SHARD-WP-0002` (T12/T15/T16/T11): program-as-page (source-canonical/render-
+derived), materialization-timing + continuity facets, view-time-execute capability + sandbox.
+
 ---
 
 ## Open questions

workplans/SHARD-WP-0004-computational-knowledge-systems.md

@@ -109,7 +109,7 @@ with computed-output provenance**; feed T12/T15.
 
 ```task
 id: SHARD-WP-0004-T4
-status: todo
+status: done
 priority: low
 state_hub_task_id: "0f54cb0e-ca8a-4131-ad4d-a675f21e153c"
 ```