SocialMedia 1.2/1.3 (SocialMedia/Home) never reached memex.systemorph.com although the publish-bake passed #6624

Activity

1. rbuergi

   added

   bugSomething isn't workingSomething isn't working

   sev:MMedium - secondary path broken, or easy workaroundMedium - secondary path broken, or easy workaround

   feedback

   on Oct 12, 2026
2. rbuergi commented on Oct 13, 2026

   

   rbuergi

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Re-measured 2026-10-13 ~07:45Z (agent session):

   • memex.systemorph.com: SocialMedia is still version: 6, lastModified 2026-09-17T10:39Z, content.version 1.1; search path:SocialMedia/Home → count 0 over partition socialmedia.
   • memex.meshweaver.cloud (the public registry instance): SocialMedia is version: 47, lastModified 2026-10-12T09:25Z.

   So it is not a lag — nothing has updated the package record on memex.systemorph.com for ~4 weeks while the registry instance moved.

   Does the per-package seal work explain it? Not on its face. MeshWeaver#6609 / Plugins#3507 change how the plugins publication seals (packages withheld per lock/floor); SocialMedia is its own satellite publication, and the issue reports its publish-bake green. Neither PR touches how an already installed package record on a consumer instance is moved to a newer listed version.

   Not established: whether memex.systemorph.com's install-defaults/auto-update pass ever offers SocialMedia >1.1 (no log read); whether the registry it consumes lists 1.3 for its framework identity. Next instrument: a governed Logs action on the control instance for memex.systemorph.com, query SocialMedia over a 24 h window, plus the registry's /api/plugins listing for that identity.
3. rbuergi commented on Oct 13, 2026

   

   rbuergi

   on Oct 13, 2026

   ContributorAuthor

   More actions

   Re-measured 2026-10-13 ~15:15Z on memex.systemorph.com (core ec7763883b). One new reading narrows where the gap is.

   • Still absent: the SocialMedia root is version 6, lastModified 2026-09-17T10:39Z. path:SocialMedia/Home returns count 0 over partition socialmedia.
   • New: the package's NodeType records DO move. namespace:SocialMedia lists PostsHub at v671, modified 2026-10-12 21:45Z; Profile and Post at v653/v660 (10-11); PostTarget at 10-08; SocialTests at 10-07. So something keeps the type definitions current, while the root record and the package's new non-type nodes (Home, SocialMediaApp) never arrive.
   • /health on all three replicas reports the socialmedia publication at e4cd122e, "NOT sealed: sealed … only by platform 3.1.10699, which is NEWER than the running platform 3.1.10681 … the sources still sync and compile against the running platform". So the bytes are withheld by design, and the sources are said to sync.

   Reading, not yet proved: the path that keeps NodeType definitions current (the sealed-publication reconciler / bundle-keyed hold, which works per listed NodeType) is not a package install. There is no SocialMedia/_GitSync on this instance. So nothing on this instance re-imports the package's other nodes or moves the root to the newer listed version. It would explain why a package that changes only types looks current, and why one that adds nodes stays at the version it was first installed at.

   Next instrument, unchanged: a governed Logs action for memex.systemorph.com, query SocialMedia over 24 h, to see whether the install/update pass ever considers SocialMedia beyond 1.1. Also the registry listing for framework c003e001. Not done in this session.
4. rbuergi commented on Oct 14, 2026

   

   rbuergi

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Re-measured 2026-10-14 ~07:15Z. Root cause: memex.systemorph.com has no delivery channel for SocialMedia at all. The package root is left over from a GitSync that was removed, so this is not a defect in the update pass. It needs an owner decision.

   Readings (MCP systemorph = memex.systemorph.com, memex = memex.meshweaver.cloud, control):

   1. There is no GitSync. SocialMedia/_GitSync returns Not found on memex.systemorph.com. Its history ends at v600 (2026-10-09 10:53Z, lastSyncCommitSha 5387581d, last import 2026-10-02). No SocialMedia/* source node has changed since 2026-10-02. Today's governed log read (Ops/Actions/w3-6624-socialmedia-install-logs-20261014 on control, 24 h) shows every SocialMedia seal delivery arriving and going nowhere: GitHub webhook (seal of 'socialmedia' at e4cd122e) for Systemorph/MeshWeaver.SocialMedia matched NONE of the 15 sync config(s) in the mesh — nothing will sync for this delivery. Manufacturing has the same shape of package and still has Manufacturing/_GitSync, so its root keeps moving (v229, 2026-10-13).
   2. The registry does not offer it. memex.systemorph.com consumes one registry, https://memex.meshweaver.cloud (Deployments/memex → pluginRepos). That registry serves SocialMedia as its own source, SocialMedia. The grant for this instance, Admin/_PluginGrant/memex on the registry, covers only Plugins/* and Crm/*. The consumer's Plugins/_RegistryReconcileLedger (06:57Z safety-net pass) lists 80 served packages, and SocialMedia is not one of them.
   3. There is no install record. Plugins/SocialMedia does not exist, and the registry reconcile works only from install records. That is also why UndeliveredModules does not name SocialMedia: that ledger lists only installed packages the registry did not offer.

   So nothing on this instance has an input for SocialMedia's content. The root (v6, 1.1) and Guide/Skill are what the old GitSync last wrote. The NodeType records "moving" are compile and adoption stamps on the existing records ([AdoptedSourceStamp] SocialMedia/PostsHub …), not imports. Packages that do have a channel move as designed: registry-installed packages such as Cornerstone (root v32, 2026-10-13) and GitSync-fed packages such as Manufacturing and Personal.

   This is consistent with two earlier owner decisions: MeshWeaver.SocialMedia#242 took SocialMedia out of the platform baseline (preInstalled: false, 1.4; the registry now holds 1.4), and MeshWeaver.SocialMedia#238 recommended removing the SocialMedia sync source from this instance. Only the first half of #238 was done: the sync source is gone, but the synced SocialMedia/* content is still here. That remnant is also why SocialMedia/SocialTests stays in Error (#238).

   Decision for the maintainer (pick one):

   • A (recommended): finish retiring it. Uninstall or delete the remnant SocialMedia/* content on memex.systemorph.com. The result matches fix(portal): identity-casing home bug, Blazor kernel-leak wedge, doc-example E2E sweeps #242 and fix(content): ingest a collection's own write immediately — kill the CI-only file-render flake #238, the SocialTests error goes away, and this issue closes as "not delivered by decision".
   • B: deliver it properly. Add SocialMedia/* to Admin/_PluginGrant/memex on the registry instance (global admin), then install SocialMedia from the catalog on memex.systemorph.com. That creates the install record, and from then on the registry reconcile keeps the root, Home, SocialMediaApp and the MeshWeaver.Social module current. This also fixes fix(content): ingest a collection's own write immediately — kill the CI-only file-render flake #238.
   • C: re-add the GitSync. Not recommended: it delivers sources without the module, so fix(content): ingest a collection's own write immediately — kill the CI-only file-render flake #238 comes back.

   An agent should not do any of the three: A deletes instance content, B changes a sync licence, and C reverses an owner act.

   Incidental, not chased: no surface flags a Store/Plugin root that no delivery channel tracks (no install record, no sync config, not served). The undelivered-modules ledger covers only installed packages, so a package orphaned like this one looks just like a current one until someone compares versions by hand.
5. rbuergi commented on Oct 14, 2026

   

   rbuergi

   on Oct 14, 2026

   ContributorAuthor

   More actions

   Decision (maintainer): finish retiring SocialMedia on memex.systemorph.com. That portal has no delivery channel for the package, so the leftover SocialMedia/* content is being removed rather than repaired.

   Approval needed: https://memex.systemorph.com/rbuergi/Requests/socialmedia-finish-retire-6624

   What the request does (governed Essentials/OperationRequest, same shape as the earlier stranded-space removals):

   1. Probes first: counts nodes typed by each of the 5 SocialMedia NodeTypes (Post, PostsHub, PostTarget, Profile, SocialTests) across partitions:all. Each must read 0 before you approve.
   2. Records the subtree, then Space("SocialMedia").Delete(), which drains it in chunks. Two query deletes then remove any leaves the drain left behind.
   3. A final read of namespace:SocialMedia scope:descendants, which must be 0.

   Why it is half-deleted now: rbuergi/Requests/remove-socialmedia (2026-10-09) deleted SocialMedia/_GitSync at step 14. Its last step, delete-space SocialMedia, then FAILED: a one-call delete of 400 descendants timed out waiting on the Postgres pool. Everything below is what that left behind.

   Readings taken 2026-10-14 as rbuergi. The socialmedia partition is readable to me only in part, so these counts are floors:

   • The SocialMedia root (Store/Plugin, content.version 1.1).
   • 36 non-Release descendants: 5 NodeType, 27 Code, 2 Markdown, 1 Skill, 1 PartitionAccessPolicy.
   • 266 Release nodes: Post 86, PostTarget 79, Profile 78, PostsHub 23.
   • SocialMedia/SocialTests is at compilationStatus: Error (CS0234).
   • Type usage outside the space: each of the 5 nodeType:SocialMedia/<T> partitions:all searches returned 0 over 117 declared partitions. 84 of those partitions are readable to me only in part, which is why the request repeats the probes as System.
   • get Posts: Not found.
   • whoami at SocialMedia: Read, Execute, Api. I have no Delete there, so this needs your approval.

   Not done: approval and execution. Not established: whether a partial-grant row exists outside my readable reach (the System probes in steps 1–5 answer that). Refs Systemorph/MeshWeaver.SocialMedia#238.
6. rbuergi commented on Oct 19, 2026

   

   rbuergi

   on Oct 19, 2026

   ContributorAuthor

   More actions

   Closing: resolved by retiring SocialMedia on memex.systemorph.com, as decided on 2026-10-14.

   • What ran: the governed request rbuergi/Requests/socialmedia-finish-retire-6624 ran 2026-10-18 07:56:10Z–07:56:28Z and finished Succeeded.
     • Its five type-usage probes all read 0.
     • It deleted the space.
     • Its final read of namespace:SocialMedia scope:descendants, run as System, returned 0.
   • Check today on the running portal:
     • nodeType:NodeType content.compilationStatus:Error partitions:all returns 0, and socialmedia is no longer among the partitions it covers.
     • The SocialTests compile failure, SocialMedia/SocialTests in-mesh NodeType does not compile — its migrated test sources reference MeshWeaver.Social types that are not on the NodeType's assembly reference set #6857, stopped firing before the request ran.
     • Details: SocialMedia/SocialTests in-mesh NodeType does not compile — its migrated test sources reference MeshWeaver.Social types that are not on the NodeType's assembly reference set #6857 (comment)
   • Not fixed by this: that portal still has no delivery channel for the package. That was the decision, and it is not a defect left open here. The gate behaviour behind Untracked-module gate parks leftover SocialMedia/SocialTests NodeType on memex; declined bundle for framework c003e001 disagrees with in-mesh source fingerprint #6930 is tracked there.
7. rbuergi

   closed this as completedon Oct 19, 2026