TODO-11 — Fuller Relationship Graph (render) — Design

Status: Approved 2026-07-01
Source item: TODO-11 (work/TODO.md) — "Graph of the people and organizations Bucky interacted with."
Branch: pluck/todo-11-relationship-graph

Goal

Render the Fuller relationship graph that the IMP-16..19 work made possible: a
generator that reads the 113 typed entity pages (102 people + 11 organizations)
and produces (1) a static, relationship-colored SVG embedded on a
buckyverse.org page, and (2) a self-contained interactive HTML artifact in
the repo for exploration and future iframing.

Context

• The corpus now has 102 entity-person pages, each with a controlled
  relationship: field (9 values), and 11 entity-organization pages, plus
  a central r-buckminster-fuller node. Edges already exist as data: each
  person's relationship: (a typed spoke to Fuller) and the bidirectional
  ## See Also links between entities.
• WikiJS rendering constraints (verified on the live site): inline
  <script> is stripped (the synergetics page's custom script does not
  survive), Kroki is disabled (markdownKroki f), but iframes render
  (YouTube embeds work) and images render via relative paths (the Dome
  Cookbook page references <dir>.images/page-NN.png). Therefore the on-site
  deliverable is a static SVG embedded as an image, not inline JS.
• Prod pushes in this repo are deliberate and human-gated (e.g. the Dome
  Cookbook publish is ACC-5), so publishing + live verification is an ACC
  item, not part of this pluck.

Architecture

Two homes, one generator:

1. Wiki project .wiki/output/projects/relationship-graph/ — the tool and
   its generated outputs (a wiki "project", so it carries a WHY.md).
2. Publishable live page repo-root relationship_graph/ — index.md + the
   embedded graph.svg, following the repo's page/relative-image convention
   (published later via the publish-to-buckyverse skill).

Nodes (114)

• 102 people, 11 organizations, 1 central r-buckminster-fuller hub.
• Node id = the topic slug; label = the page title. Fuller hub enlarged.
• Node color = its relationship: value for people (9 colors), one neutral
  color for organizations, and a distinct color for the Fuller hub.

Edges

• Typed Fuller spokes: one edge person→r-buckminster-fuller per person,
  colored by the person's relationship: value (102 edges).
• Org spokes: one edge org→r-buckminster-fuller per organization, neutral
  color (11 edges), so organizations are anchored to the hub.
• Cross-links: the ~89 entity↔entity ## See Also edges (undirected, dedup
  by sorted pair), drawn in a light neutral color to show the lateral web.

The generator — build_graph.py

A dependency-light Python script (uses only stdlib + a shell-out to graphviz
sfdp, both confirmed available; networkx available if convenient but not
required). Steps:

1. Walk .wiki/wiki/topics/*.md; for each page containing entity-person or
   entity-organization, record slug, title, kind, and relationship:.
2. Build nodes + edges as above (See Also parsed from the ## See Also section,
   keeping only links whose target is another entity node).
3. Emit graph.json — {nodes:[{id,label,kind,relationship,color}], edges:[{source,target,type,color}]}.
4. Emit graph.dot and render graph.svg via sfdp -Tsvg
   (force-directed; Fuller node large; per-type node fill colors; a legend
   subgraph listing the 9 relationship types + org + Fuller with their colors).
   Node URLs in the dot point at each entity's live page path so the SVG is
   click-through where the viewer supports it.
5. Write the self-contained interactive index.html — loads vis-network
   from a CDN, embeds the graph data inline (from graph.json), draws a
   force-directed network with: color legend + per-type show/hide toggles, a
   node search box, and click-a-node → open that entity's buckyverse page.
6. Copy graph.svg into the repo-root relationship_graph/ page dir (the
   published image).

Re-running the script regenerates all outputs from current wiki state (the sync
story: run it after entity pages change).

The live page — relationship_graph/index.md

WikiJS frontmatter (title, description ≤255 chars, published, date, tags,
editor: markdown) + body: a short explainer of what the graph shows and how it
was built, the embedded ![Fuller relationship graph](graph.svg), a
legend table (each relationship type → color swatch description + count), a
one-line pointer to the interactive artifact, and a note that node positions are
force-directed. No inline JS (stripped by WikiJS).

Colors (relationship → fill)

collaborator, influence-on-fuller, influenced-by-fuller, friend, family,
contemporary, rival-critic, forebear, chronicler — nine visually distinct fills;
organization = grey; r-buckminster-fuller hub = a distinct accent. Exact hex
chosen in implementation for contrast; legend documents them.

Verification

• build_graph.py runs cleanly and regenerates graph.json, graph.dot,
  graph.svg, index.html, and the page-dir SVG copy.
• Node count = live entity count (114 incl. Fuller); every node id resolves to
  an existing wiki/topics/<slug>.md; every edge's endpoints are nodes.
• Relationship colors cover exactly the 9-value vocab; counts in the page legend
  match the generator's tallies.
• graph.svg is valid SVG (renders in a browser); index.html opens and draws
  the network.
• /wiki:lint --local clean for the new wiki project (WHY.md present, indexes
  updated). No live push in this pluck.

Not doing (YAGNI)

• No live publish/verify (queued as an ACC item).
• No work/book nodes (people + orgs + Fuller only, per the approved scope).
• No enabling of Kroki, no iframe hosting, no build tooling/bundler — the
  interactive page is a single hand-written HTML file with a CDN script tag.
• No automatic regeneration hook — the generator is run on demand.

Testing / verification

Tooling task. Success = the generator deterministically produces a valid
relationship-colored graph.svg (114 nodes, correct edges/colors) and a working
interactive index.html, the relationship_graph/ page embeds the SVG with a
correct legend, the wiki project has a WHY.md, lint is clean, and publish is
queued for human sign-off.