Checkpoint (2026-08-25) — CollabCore Rollout + PyTorch Source Build (Clone)

Status: CollabCore, md_bbc, lmv_bbcode, and listatt all shipped and confirmed working on Live. PyTorch source build in progress on Clone (via Gemini), restarted once after an unrecoverable error, currently past the protobuf stage.

---

Part 1 — CollabCore rollout (DONE, confirmed working)

What shipped

• CollabCore v1.0 — new shared-library package. Installs to $sourcedir/CollabCore/ on any given SMF system (installed per-system, one per box — no shared/networked install). Ships CollabCore.php (manifest + requireOrDie() dependency-enforcement helper) and MDParser.php (the Markdown engine, relocated out of md_bbcode). No BBC tags/hooks of its own — pure library.
• md_bbc v13.0 — MDParser.php removed from this package entirely; now depends on CollabCore. Install's first <code> step (md_check_collabcore.php) hard-fails with a specific message if CollabCore isn't present/new enough, instead of installing "successfully" and fataling on first render.
• lmv_bbcode v3.3.0 — same treatment. This one had a real latent bug found during the split: it was silently reaching into $sourcedir/MDParser.php at runtime assuming md_bbcode happened to be installed, with zero install-time check. Now an explicit, enforced CollabCore dependency instead of an invisible one. Also normalized mixed LF/CRLF line endings in LMVBBC.php while in there (pure cleanup, no behavior change).
• listatt v6.4 — new "MMM" (multi-media-mad) INFO panel: true on-disk filename (computed from id_attach/id_folder/file_hash, not the display filename column), resolved storage directory labelled base vs "2", live file-exists check, and audio/video technical metadata (sample rate, channels, bit depth, duration, codec; resolution/frame rate for video) via getID3 or ffprobe, whichever's available. New shared logic lives in collabware/AttachMeta.php, bundled with listatt's own package (not yet migrated into CollabCore — only one consumer so far; the "second consumer" threshold that triggered MDParser's move into CollabCore hasn't been hit for AttachMeta yet).
• Andrew tested all four packages together — confirmed working.

Standing conventions established this session

• "Collabware" = the name for the whole multi-agent collaboration (Andrew.human + Claude.ai/api + ChatGPT.ai/api + Gemini.ai/api), AND the naming convention for shared-library directories generally.
• CollabCore = the specific shared-code package/class/directory name (capitalized, distinct from the lowercase collabware/ convention for a mod's own self-contained fallback copy).
• CollabCore update policy — IMPORTANT, explicitly stated by Andrew: never recreate/reinstall CollabCore wholesale for future changes. Only add/delete/replace individual files within the existing install. A library gets promoted into CollabCore once it has a second real consumer, not preemptively.
• CollabCore needs installing independently on each of Andrew's ~6 systems (each has its own $sourcedir) — no shared/networked install. A from-scratch VM rebuild wipes it; a VM-folder backup restore preserves it.
• Mandatory doc-block/version-banner convention (established pre-session, reconfirmed and applied throughout): every module gets a versioned header block and a visible on-page version+date stamp.

Ideas raised, explicitly NOT built yet (future scope)

• Manifest-based dependency versioning (Option A) vs. a full Collabware Manager admin-panel mod (Option B) — real one-click ordered installs, orphan detection, version-aware upgrades, reading manifests across all installed mods. (B) is the bigger, "envy of SM" project; today's dependency check is the simple file_exists()-based version, not (A) or (B) in full.
• Service-registry pattern (call_named_service('markdown_render', ...) instead of hard-wired require_once) — would let providers be swapped without touching consumers. Not started.
• Crash-isolation/circuit-breaker system — per-hook try/catch supervision + register_shutdown_function() fatal logging + auto-disable a mod that fatally crashed last request. Real PHP limitation confirmed: true fatals can't be resumed mid-request (no continuations), so this would be quarantine-between-requests, not true mid-request recovery. Not started.
• Forking SMF itself ("2.0.20") floated and explicitly walked back — Andrew confirmed not serious about a full core fork (correctly identified as taking on permanent security-maintainer burden); landed on building the above as mods/admin-pages on top of stock 2.0.19 instead.
• Eventual candidates to migrate into CollabCore once they get a second consumer: AttachMeta.php (listatt's path-resolution/media- metadata logic), pieces of ISE itself ("we can split ISE up one day too").

---

Part 2 — PyTorch source build on Clone (IN PROGRESS)

• Context: this is the alternative path to the original glibc 2.17 upgrade (see prior checkpoint, checkpoint_as_at_just_before_the_Grand_MAKE.md) — that glibc upgrade did succeed and is confirmed stable on Clone, but was the higher-risk/highest-blast-radius fix for the underlying "torch won't import" problem. Gemini proposed building PyTorch from source against Clone's existing toolchain instead (no glibc touch needed at all for this path) as a lower-risk, higher-patience-cost alternative; Andrew took that option specifically because of its lower risk, despite Gemini ranking it least attractive of the options presented.
• Reverted Clone to vanilla (pre-glibc-upgrade state) for this attempt — the glibc-upgraded Clone snapshot is NOT what this build is running on.
• Allocated 3GB RAM / 4 CPU to the VM for the build.
• Toolchain: devtoolset-7 (GCC 7.3.1) — separate/newer than devtoolset-2 (GCC 4.8.2) used for the earlier glibc build. Needed for PyTorch's C++ to compile at all.
• First attempt reached 74% before hitting an unrecoverable error; Gemini diagnosed and fixed it, but the build itself could not be resumed from that point — required a full restart.
• Recovery steps taken (per Gemini's own checkpoint, Gemini_pytorch_build_checkpoint.md, uploaded by Andrew):
  • Build directory wiped clean (rm -rf ~/pytorch/build/*) and reconfigured.
  • Missing/incompatible submodules bypassed via CMake flags: -DUSE_BREAKPAD=OFF, -DUSE_QNNPACK=OFF, -DUSE_PYTORCH_QNNPACK=OFF, -DUSE_NNPACK=OFF.
  • Global warning suppression added (-DCMAKE_CXX_FLAGS="-w", -Dprotobuf_DISABLE_WARNINGS=ON) to stop GCC 7 treating outdated/unsupported warning flags (e.g. -Werror=cast-function-type) as fatal. Flagged as a "fine for this build, not something to leave default long-term" pragmatic choice, not a real fix to the underlying flag mismatch.
  • Building via gmake -j 2.
• State at last check: past the protobuf compilation stage (the restart's furthest-verified point), progressing into core PyTorch/Caffe2 source compilation. Percentage-complete not re-established after the restart (74% was pre-restart progress, not current).
• Not yet done: full build completion, Python bindings validation, real import torch test, open_clip install, real CLIP embedding test against Andrew's actual uploaded images/video (same end-goal validation steps as the original glibc checkpoint's plan).

Immediate next step when resumed

1. Check current build progress/percentage on Clone.
2. If still running clean: let it finish (multi-hour builds are normal for this).
3. If it errors again: check whether it recurs at the same protobuf-adjacent point (would suggest a real incompatibility, not a transient/cache issue) or somewhere new.
4. Once build completes: python3 -c "import torch; print(torch.__version__)" as the first real test, same as the original glibc-path checkpoint.
5. From there: pip install open_clip_torch, then a real CLIP embedding test against actual uploaded attachments — this is the actual point of the whole exercise, unchanged from the original plan regardless of which path (glibc upgrade vs. source compile) gets torch working first.

Still open / parked, not urgent

• Everything listed under "Ideas raised, not built yet" in Part 1.
• The original glibc-upgraded Clone snapshot remains available as a proven fallback if the source-compile path doesn't pan out — reverting to vanilla Clone for this attempt didn't discard that work, it's a separate, still-valid path.
• ISEmedia's indexer/search components remain entirely off Claude's plate per Andrew's earlier instruction — Andrew is building/ overseeing that himself (with Gemini's help on the indexer), this checkpoint only covers the infrastructure (PyTorch/CLIP availability) blocking it.