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>

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