Sam & Claude 6275fee97e docs: harness-neutral cleanup + restore green markdown gate

Pi-era residue in current-tense docs/strings (CHANGELOG history left intact):
- ONBOARDING-SIMPLIFICATION: COLIBRI_AUTOSPAWN_PI -> COLIBRI_AUTOSPAWN; 'Pi
  agent' -> 'agent'.
- clawdie-join-hive.sh: user-facing 'Pi agent is live' / 'no Pi agent' ->
  harness-neutral (default agent is now zot).
- clawdie-live-seed.README.txt: COLIBRI_AUTOSPAWN_PI -> COLIBRI_AUTOSPAWN.
- stage-colibri-iso.sh provider.env.sample: the AUTOSPAWN_ARGS example showed
  '--mode json' (invalid for the zot default); note the default is
  harness-derived (zot -> rpc, pi -> --mode json).

Also restore the markdown format gate: 5 docs from the 0.12.0 work were
prettier-dirty, so ./scripts/check-format.sh was already failing on main (the
gate was red and unenforced — same pattern as the colibri build break).
prettier --write brings them to style; gate is green again. No prose changes
in those 5 — formatting only.

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

2026-06-23 18:08:58 +02:00

3.3 KiB

Raw Blame History

Blender vs geodesic-dome-mcp — Capability Comparison

2026-06-23 | OSA (mother node) | FreeBSD 15.0

The problem

Generate geodesic dome wireframes for architectural visualization and bill-of-materials calculation. The obvious answer was Blender — it has bpy.ops.mesh.primitive_ico_sphere_add() built in.

Before: Blender

Metric	Value
Packages installed	53
Download size	323 MiB
Installed size	1 GiB
Key dependencies	llvm19, ffmpeg, openimageio, opencolorio, openvdb, pulseaudio
Headless mode	`blender --background` (still pulls X11 deps)
Dome generation time	~14s (Eevee render, 2000×2000)

After: geodesic-dome-mcp

Metric	Value
File size	6 KB (294 lines of Python)
Dependencies	numpy, Pillow (already installed on all nodes)
Dome generation time	<1s (wireframe), sub-second (BOM only)
Headless	Always — no X11, no GPU, no display server
Outputs	Wireframe PNG + structural BOM (JSON)

Capability impact

Capability	Before (Blender)	After (geodesic-dome-mcp)
Can run on 32GB USB ISO?	❌ (1 GiB, exceeds headroom)	✅ (6 KB, negligible)
Can run on 12GB RAM VPS?	❌ (would fit disk but overkill)	✅ (already running)
Can run on bare-metal?	✅ (if installed)	✅ (always)
Structural BOM?	❌ (needs separate script)	✅ (built-in)
Half-sphere mode?	Manual mesh cut	✅ (`half=true`)
Connector analysis?	❌	✅ (3/4/5/6-way counts)
Strut length table?	❌	✅ (grouped by size)
Material cost estimates?	❌	✅ (glass/polycarbonate/insulated)

Registering capabilities

This comparison feeds into the mother node's PostgreSQL usb_nodes table. When a node registers its hardware profile, the capability derivation trigger marks nodes that can run geodesic-dome-mcp (all of them — numpy + Pillow are universal). Nodes that have Blender installed get an additional has_blender: true capability for 3D rendering workloads.

OSA as example (registered 2026-06-23)

{
  "hostname": "osa.smilepowered.org",
  "ram_gb": 12,
  "cpu_cores": 6,
  "capabilities": {
    "has_gpu": false,
    "cpu_only": true,
    "geodesic_dome_mcp": true
  }
}

12GB RAM, no GPU, but geodesic_dome_mcp runs fine. No Blender needed.

3.3 KiB Raw Blame History Unescape Escape