Feedback submissions are silently dropped on memex.systemorph.com — the Untracked-module-content park (#3583) costs user data, not just adoption

Root cause is #3583 and this is not a new mechanism report — #5265 was closed as a duplicate of
it on 2026-09-23, and the refusal text on the affected nodes cites #3583 by number. This is filed
for the consequence, which #3583 (labelled enhancement, no severity) does not carry: on the
feedback path this park causes silent loss of user-submitted data.

The exact refusal, from a live node

sglauser/Feedback/2026-09-24T15-42-23-client-b-reconcile, compilationError:

Untracked module content: NodeType 'Feedback/Feedback' is a module's content, but partition
'Feedback' tracks no source on this mesh (no configured sync source), and the prebuilt bundle for
framework s158b93682af6855aac841424dd01e973/linux-x64 names this type but was DECLINED: its source
fingerprint disagrees with the files this mesh holds, and nothing syncs those files. This mesh does
not compile a module's content it does not track — a local build of an install's leftover copy
would serve old code as if it were current. Fix: add a sync source for 'Feedback' (Partition Sync
administration) and sync it, or publish/rebake the package for this framework identity; then
request a release to retry (MeshWeaver#3583).

Why this instance is worse than adoption lag

A user presses Submit and the submission is accepted with no error. Nothing then reaches triage:
no hand-over, no thread, no ticket, no version bump on the node. The submission is silently lost, and
the person who wrote it has no way to tell.

Measured, on memex.systemorph.com

Submissions under sglauser/Feedback/ before and after the framework identity moved:

node	filed (UTC)	handedOverAt	outcome
`2026-09-23-whoami-display-profile-menu`	19:06:46	19:07:44	`MeshWeaver.Feedback#33`
`2026-09-23-whoami-mcp-tool-missing`	19:07:03	19:07:23	`MeshWeaver.Feedback#34`
`2026-09-23-agents-md-stale-triage-rationale`	19:43:24	—	still v1, ~19 h
`2026-09-23-crm-has-triage-feature-not-the-rule`	19:51:45	—	still v1, ~19 h
`2026-09-24T15-42-23-client-b-reconcile`	15:42:37	—	stuck, carries the refusal above
`20260924-162034`	16:20:45	—	stuck

The first two were handed over in 20 and 58 seconds. Everything filed after roughly 19:22Z on
2026-09-23 — when Hosting/Triage/Status was re-created, consistent with a roll onto a new framework
identity — has not been handed over at all.

The control side is demonstrably alive throughout: Hosting/Triage/Status recorded ciFailure: 9,
threadsStarted: 6 on 2026-09-24 with its last event at 09:03:13Z. The ci-failure intake works;
the feedback intake has produced zero events.

The backlog does not drain on restart. Hosting/Triage/Status has been re-created at least
twice on 2026-09-24 (08:23:20Z, then again 16:45:12Z). Across both, none of the parked submissions
above was picked up, so a parked submission is not queued for later delivery.

Suggested remedy, per the refusal text itself

Add a sync source for the Feedback partition (Partition Sync administration) and sync it —
administrative, no release needed. Alternatively publish/rebake the package for framework identity
s158b93682af6855aac841424dd01e973/linux-x64.

What I did NOT establish

Whether the same park affects the Feedback partition on other portals; I measured only
memex.systemorph.com.
Whether the stuck submissions recover once a sync source is added, or are lost permanently.
I cannot read Hosting/PlatformBuilds (Access denied: user 'sglauser' lacks Read permission), so
I cannot say whether these submissions' events are sitting undrained in the inbox or were never
posted.
Whether this warrants a severity label is triage's call, not mine. If the view is that the
consequence is adequately covered by Bundles are baked for ONE framework identity per run, so a portal's GitSynced sources stay days behind main (or its types go unadopted) — options 1-4 undecided #3583, close this as a duplicate — the evidence above is the
point, and it is cross-referenced either way.

Refs #3583 (root), #5265 (closed as duplicate of #3583), MeshWeaver.Plugins#2285 (adjacent: the
Feedback Inbox lists a different path from where submissions are written).

Read-only follow-up, 2026-09-26: the Feedback partition still has no configured sync source (@Admin/Partition/Feedback reports the default data source and no source mapping), and there is no GitHub-sync configuration under Feedback. The similarly named Systemorph/MeshWeaver.Feedback repository contains only its LICENSE, so it is not currently a source for the code in the partition. The current Feedback/Feedback definition compiles on framework c003e001 (last successful compile 16:13Z), but it still reports AdoptedUnverified, adopted module version 1.2.0 versus current 1.3, so that alone does not prove the untracked-source refusal or the parked submission has been remediated. I did not read the submission body. Because the Feedback partition also holds user-submitted records, I have not configured a whole-partition Git sync to a newly created repo; doing that without a code-only source boundary could publish user data. This remains open pending an authoritative code-only sync source or a verified package rebake/release for the running identity, then a targeted handover verification.

Production check on memex.systemorph.com, 2026-09-28 14:34–14:38 UTC:

I created a clearly labelled test Draft at rbuergi/Feedback/verification-5670-20260928-1434, opened its Compose view in the signed-in portal, and clicked Submit. The source now reads as a Redirect to Feedback/_Submissions/fb-a851cc0bbbb354b27191c09fb652e3c1, so the portal button did cause the move into the shared Inbox.
The downstream hand-over is not verified. Hosting/Triage/Status's feedback count stayed at 9 from 14:33 through 14:38 UTC, and there is no matching item under Hosting/Triage/feedback. My credential cannot read the moved submission directly under RLS, so I cannot inspect its handedOverAt field.
The production Feedback/Feedback definition reads compilationStatus: Ok but buildProvenance: StaleAdopted: adopted source fingerprint 1967047c7205c8c3 differs from current 3c0024e16dfbc3ef. It adopted module 1.3.2 while Plugins/Feedback records an Auto-installed 1.3.3 at 13:44 UTC. That is evidence of a content/bundle mismatch, not proof by itself that it caused this hand-over gap.

Keeping this open. Next check is a matching sealed Feedback bundle on the running image, then the moved node's own handedOverAt/control-inbox/triage path (using an identity allowed to read it). The test message explicitly says it reports no new defect.

Control-portal follow-up, 2026-09-28 18:03 UTC: Feedback/Feedback remains Ok but StaleAdopted (adopted source fingerprint 1967047c7205c8c3, current 3c0024e16dfbc3ef; adopted module 1.3.2, installed package 1.3.3). Hosting/Triage/Status now counts 11 feedback events today, but a search of its six current feedback items found no match for the portal Submit test Feedback/_Submissions/fb-a851cc0bbbb354b27191c09fb652e3c1; a direct read of that moved node is still Not found under my credential, so its handover state remains unverified.

I attempted a narrow unforced release request on the NodeType, but the mesh correctly denied my identity Update permission. I filed the privileged operation at https://memex.systemorph.com/rbuergi/Requests/activate-feedback-handover-20260928 for global-admin review. It reads the type, then writes only requestedReleaseAt, requestedReleaseForce=false, and requestedReleaseBy through the operation plan; it does not edit submissions. The request is Proposed, not executed. After it runs, verify the adopted fingerprint and the Submit→handover→inbox→triage chain before closing #5670.

Root cause found and reproduced deterministically. Fix: Systemorph/MeshWeaver.Plugins#2536. It does not close this issue; that waits for the production check below.

Measured on memex.systemorph.com (read-only Logs actions Ops/Actions/logs-5670-*):

Portal Submit dropped. The portal Submit test rbuergi/Feedback/verification-5670-20260928-1434 (category bug, status New) was moved at 14:34:21.353Z to Feedback/_Submissions/fb-a851cc0b…. Nothing followed: no control-inbox event, no triage item, no triage thread, and no [Feedback] warning or error. Every failure branch of the hand-over logs at Warning or above, so the moved report's watcher took a silent exit.
Agent filings delivered. Every agent-filed report that day produced its Hosting/Triage/feedback/… item 0.4–1.5 s after its move (13:47, 17:16, 17:46, 19:56).
Four other unpaired moves are historical records. They already carried handedOverAt, so no new triage item is correct.

Mechanism:

Publish flips Draft → New as the owning hub's in-memory commit. Storage receives it afterwards (the post-commit flush, with the 200 ms write-behind sampler behind it).
The watcher saw the in-memory New and moved at once. A move copies its source from storage, so the Inbox got the stored Draft.
The destination's watcher skips a Draft, so the report was never handed over and nothing was logged.
Agent filings are created New directly in storage, so they never raced.

Proof. FeedbackSubmitRelocationTest (Plugins Hosting.Monolith.Test) compiles the real Feedback sources and holds the submission's storage writes open with an innermost gate:

Unfixed watcher: fails. The move enumerated the source from storage about 150 ms after the held New write.
Fixed watcher: passes. It moves only after the post-commit IMeshInvalidationFeed reports the version stored, and the Inbox copy is New with the edited message.

Closes after deploy: one portal Submit of a bug report on memex.systemorph.com. It should end with a Redirect at the old path, an Inbox copy with New and handedOverAt set, and exactly one triage item.

The 14:34Z test report (fb-a851cc0b…) is still a Draft in the Inbox and will not re-drive by itself. It reports no defect.

Status 2026-09-30 ~16:50Z: the fix is live on the control instance; the closing Submit is still owed

Plugins#2536 merged 2026-09-28 21:25:37Z. On memex.systemorph.com, Feedback/Feedback/Source/FeedbackHandover is version 16, last modified 2026-09-28 21:38:22Z, and its source contains the fix: DurableVersions(...) over IMeshInvalidationFeed and WhenDurable(durable, node.Version).SelectMany(_ => MoveToInbox(...)).
Feedback/Feedback reads compilationStatus: Ok, lastCompileSucceededAt 2026-09-30 16:01:28Z, compiledSources["…/FeedbackHandover"] = 639262283029633520 (that same 09-28 21:38:22Z version), framework c003e001. The running build therefore compiles the fixed watcher.
Hand-overs are flowing: Hosting/Triage/feedback holds new items every day since the deploy, for example …fb-64de5b4a… (sglauser, 2026-09-30 15:21Z, status: Done).

Why this is not a close. The closing condition is one portal Submit (Draft → New through the Compose view). I could not tell from outside whether any post-deploy item came through that path or through an agent's direct New create: the source nodes sit in partitions my credential cannot read, and the moved Feedback/_Submissions/fb-… nodes answer Not found under RLS. I did not press Submit myself, because that would manufacture a triage item.

Ask (maintainer, ~1 minute): submit one bug report through the portal's Compose → Submit on memex.systemorph.com, then check that (1) the old path is a Redirect, (2) the Inbox copy reads New with handedOverAt set, and (3) exactly one Hosting/Triage/feedback/… item appears. The 09-28 14:34Z test report (fb-a851cc0b…) is still a stranded Draft and will not re-drive; it can be deleted.

Reopened by the fleet's bug-fix pool hand-over (maintainer request 2026-09-30: start a bug-fix thread for every open sev:H bug). This bug never got a bug-fix thread (it was recorded before the intake handed classified bugs to one, or never recorded); the reopened event is the intake's supported path to start it on the EU bug-fix pool. The close/reopen changes nothing else.

Status read on memex.systemorph.com on 2026-10-07 ~07:10Z, through the control MCP as rbuergi:

The park this issue names is gone. Feedback/Feedback reads content.compilationStatus: Ok (NodeType version 323195, modified 05:56Z today). The "Untracked module content … DECLINED" refusal from Bundles are baked for ONE framework identity per run, so a portal's GitSynced sources stay days behind main (or its types go unadopted) — options 1-4 undecided #3583 is therefore not what the type serves now.
Feedback reaches triage again. Hosting/Triage/Status counts feedback events of 18 on 10-06 and 11 so far on 10-07. Triage items for Feedback/_Submissions/* were created within about a minute of each submission today, for example …fb-coord-20261007-issue-sweep-frozen-no-run, which became MeshWeaver.Plugins#3048/MessageDeliveryConverter OOMs while serializing a DeliveryFailure for a large RawJson delivery — sender's failure notification is lost #3049. sglauser's own later submissions also arrived: …fb-5d425e4b810eb7ec9bbd59dc695e1c22 and …fb-df30d681b581ed854815b5f5708743ae, both on 2026-10-04.
NOT established: whether the four submissions in the table recovered. Their inbox paths (FeedbackHandover.InboxPathFor) would be fb-597cd16bdedcc7c7fbee1da87e7375ad, fb-bb747d2b1ad4332bc8c2e1d9624483cb, fb-aa049c6a289cb34693b9113779357374 and fb-d2a21194040800c4c0b50e21fd8b91e1. No Hosting/Triage/feedback/… item exists for any of them. I cannot read the sglauser partition or Feedback/_Submissions: both answer Not found or 0 to this credential, which cannot be told apart from absent. So I cannot say whether they are still in sglauser/Feedback and unmoved, moved without a hand-over, or deleted.
A separate, still-live variant of the symptom ("a submission is accepted and never reaches triage, silently") is MeshWeaver.Plugins#3042: content in a shape the bound type does not know is skipped without a word. It is being fixed in core (Create refuses unknown content) and in Plugins (an unreadable submission is reported loudly).

Leaving this open as sev:H until someone who can read sglauser/Feedback confirms those four submissions are handed over, or re-files them. If they are still there unmoved, waking the Inbox (recycle Feedback/Inbox) re-runs the backlog watcher over them.

Related: Systemorph/MeshWeaver.Plugins#3042, Systemorph/MeshWeaver.Plugins#3044. Cross-linked, not merged.

Plugins#3042 has the same symptom (a submission is accepted and never handed over) but a different root: an old content shape, fixed by fix(write): refuse a content $type that names no type, and Create's silent member drop (Plugins#3042) #6231 and Plugins#3059. This issue's Bundles are baked for ONE framework identity per run, so a portal's GitSynced sources stay days behind main (or its types go unadopted) — options 1-4 undecided #3583 park is gone, and its closing condition (the four sglauser submissions) is its own.
Plugins#3044. Governance/Activity is held right now by the same Bundles are baked for ONE framework identity per run, so a portal's GitSynced sources stay days behind main (or its types go unadopted) — options 1-4 undecided #3583 delivery park ("Untracked module content … DECLINED") that caused this issue. Its fix is a Governance rebake or sync source, not anything here.

@sierragolflima

(re-posted 2026-10-11; originally by @sierragolflima on 2026-09-25)

Correction: two rows of the evidence table are confounded, and I should say so before anyone works this

MeshWeaver.Plugins/Hosting/Triage.md ("What lives where") documents a precondition I did not
account for when I built the table above:

the hand-over on the posting side — Feedback/Feedback/Source/FeedbackHandover.cs, the OWNING
HUB's watcher, HandOverOnActivation … 🚨 But it is not universal, and the gap is the WAKE, not
the writer. The watcher only observes a submission once the node's own hub has ACTIVATED, and
creating a node reaches the OWNER namespace's hub, not the node's — core's MeshOperations.Create
performs no read-back. So a writer that does not read the node once after creating it gets no
hand-over: FeedbackSubmitter.Submit:220 (Wake) and ThreadSupervisor.FileFeedback both
discharge that obligation explicitly, a bare MCP create does NOT, and Feedback/Guide.md
records it as the caller's duty — enforced by nothing (#2041).

I created rows 1–4 with a bare MCP create. Rows 3 and 4 I only ever read back with search, which
reads the query index and wakes no hub; rows 1 and 2 I read back with get. So:

Rows 3 and 4 are not evidence of this fault. They would have parked whether or not the NodeType
compiled, because nothing woke their hubs.
Rows 1 and 2 are not a clean control either. Their hand-over is equally explained by my get
as by the NodeType still compiling at the time.

What survives unconfounded is the part that matters: rows 5 and 6. Both were submitted through
the portal's /feedback, which calls FeedbackSubmitter.Submit and discharges the wake explicitly.
They parked anyway, and 2026-09-24T15-42-23-client-b-reconcile carries the compilationError quoted
in the issue body. Those are real user submissions on the supported path, and they are lost silently.

The claim in the title stands. The supporting table overstated it, and an issue that overstates its
certainty sends the next person down a branch I had already muddied.

One further correction to the body: I wrote that the ci-failure intake "works" on the strength of
threadsStarted. Triage.md is explicit that threadsStarted counts thread NODES CREATED, not
threads that ran — it records 100 threads measured at version 1 with the task never ingested, the
ledger truthfully counting each one. So that sentence should be read as "events were recorded", not
"the agent worked them".

Refs #3583, #2041.

@sierragolflima

(re-posted 2026-10-11; originally by @sierragolflima on 2026-09-25)

Second correction, and a status reading as of 2026-09-25 ~11:00 Zurich

Classification

Labelled bug, sev:H by the author. The triage agent never classified this issue (see the
last section), so it has been classified by hand on the documented Classified path. The severity
reason: a feedback submission on the supported path is accepted without error and then silently
lost, which is "silently WRONG results anywhere".

Row 6 was never submitted

sglauser/Feedback/20260924-162034 carries status: "Draft" and an empty timestamp. It was never
submitted, so it is not evidence of a submission being dropped. That leaves one confirmed case of
a submitted feedback that then parked: 2026-09-24T15-42-23-client-b-reconcile (no status key, which
means New; timestamp stamped by the server at 15:44:58Z). The claim in the title rests on that
node alone.

Unverified hypothesis, noted so nobody has to rediscover it: the Compose area that carries the
Submit button is a layout area of the same Feedback/Feedback NodeType that does not compile. If
so, a draft cannot be submitted at all on this instance, which is a worse failure than a submission
being lost afterwards. I have not tested this.

The fault is unchanged

20260924-162034 still carries the Untracked module content refusal for the same framework
identity, s158b93682af6855aac841424dd01e973/linux-x64. So there has been no roll or rebake since the
filing, and no sync source has been added for the Feedback partition.
Hosting/Triage/Status records feedback: 0 for both 2026-09-24 and 2026-09-25. It records
ciFailure: 11 and 13 on the same days, so the pooled inbox is recording events. Only the
feedback intake is producing none.

The `issue` intake is not classifying anything either

Evidence, for issues opened since 2026-09-23 in MeshWeaver, MeshWeaver.Plugins and Memex:

Every labelled issue was labelled by its own author at creation, within one or two seconds
(for example memex-cloud: routed self-update Restarts re-opened per replica announcement during an in-flight rollout — six ReplicaSets for one image tag in <2h (not a render checksum) #5677, AdoptedSourceStamp logs 'the write did not converge' for stamps that converged — the commit mark moved inside the lambda (split off #1105) #5662 and Batched source discovery is all-or-nothing: one partition that cannot answer sends EVERY pending NodeType to the activation sweep on every boot #5654 here, and MeshWeaver.Plugins#2364). That is the Classified
path, which involves no triage.
There is no LabelIssue event by systemorph-com[bot] on any directly filed issue in that window.
Every issue opened without labels stayed without labels: this one, Memex#515 and Memex#513.
The last was filed by a maintainer, so this is not specific to one author.
The current ledger node was created 2026-09-24T16:45:12Z. This issue and Memex#515 were opened at
17:16Z, after it existed, and the ledger shows no issue count on either day.
MeshWeaver.Plugins/Hosting/Triage.md states that "an issue count of zero on a day somebody
opened an issue means the organisation webhook did not deliver".

I cannot confirm the webhook directly: gh api orgs/Systemorph/hooks answers 404 to this credential,
which lacks admin:org_hook. On this evidence, neither route into triage is currently reaching it,
and an issue filed without labels is invisible to the release gate until a person classifies it.

What remains the fix

The one the refusal text names: add a sync source for the Feedback partition on
memex.systemorph.com (Partition Sync administration) and sync it, or rebake the package for the
identity above. Adding a sync is the sync.add class in Governance/Catalogue.md, approved by a
global admin. That standard is not yet built, so the approval should be recorded on the change itself.

Refs #3583.

@rbuergi

(re-posted 2026-10-11; originally by @rbuergi on 2026-09-25)

Triage re-read 2026-09-25 ~15:30Z. Running builds (/api/version): memex.systemorph.com = 39f49494eb (ci.9218), memex.meshweaver.cloud = 140c5fb7ae (ci.9291). Ancestry was checked with git merge-base --is-ancestor against origin/main. Both portals are still held at the V58 migration: the ci.9332 pods crash-loop on DbVersionGate db_version=57 < expected 58. Nothing will roll until a governed Reconcile of Deployments/memex runs the migration Job.

Classification: needs production action only (no core code defect found). The refusal is #3583 working as designed on a partition that tracks no source. The fix is one of these owner acts on memex.systemorph.com:

add a sync source for the Feedback partition (Partition Sync administration) and sync it; or
rebake and publish the Feedback package for the running framework identity.

After that, request a release on Feedback/Feedback and wake the parked submission sglauser/Feedback/2026-09-24T15-42-23-client-b-reconcile (a get, or a recycle of that address) so its hand-over runs. Not established: whether a parked submission is re-driven once the type compiles. That should be checked on that node after the fix.

@rbuergi

(re-posted 2026-10-11; originally by @rbuergi on 2026-09-26)

Re-measured on the running control instance, 2026-09-26 ~18:20Z: the feedback path hands over end to end

memex.systemorph.com /api/version reports core 45e7f94e4ec3. #5701 is on it.

The type compiles. Feedback/Feedback reads compilationStatus: Ok, compiledFrameworkVersion: c003e001 and lastCompileSucceededAt 18:17:00Z. It still reads buildProvenance: AdoptedUnverified. It no longer carries the Untracked module content refusal quoted in this issue's body. That refusal was for framework s158b936….

A submission reaches triage. I followed one submission through every stage:

step	node	when
submitted (`New`, created by `rbuergi`)	`rbuergi/Feedback/notification-config-per-application-20260926` v1	16:48:58Z
woken by a `get` of its exact path; `handedOverAt` stamped	same node, v2	18:15:17Z
signed `event: feedback` stored in the control inbox	`Hosting/PlatformBuilds/_Inbox/bc328f1546db47919ce34bf87ab0b1b8`	18:15:17Z
drained (inbox claim)	same node, v2	18:16:36Z
triage item created	`Hosting/Triage/feedback/memex-systemorph-com-rbuergi-feedback-notification-config-per-application-20260926`	18:17:33Z

A second submission, …/stuck-roll-recurred-20260926T1216Z, was handed over at 15:25:31Z. Its triage item was not in Hosting/Triage when I read it; that folder was re-created at 18:12:57Z.

So the mechanism in this issue's title (a submission accepted and then silently dropped because the NodeType was parked) does not reproduce on the running build.

Why this stays open, and what closes it:

The one confirmed lost case has not been re-driven. That is sglauser/Feedback/2026-09-24T15-42-23-client-b-reconcile. Hand-over runs when the node's own hub activates, so a single get of that exact path by someone who can read it should hand it over. From my credential, get answers Not found and namespace:sglauser/Feedback returns count 0 over coverage [sglauser]. Under RLS that means either absent or not readable by me, so I can tell nothing about it. This is an act for the owner or an admin with read on that partition.
I did not establish why the park lifted. It could be fix(gitsync): sync every module by its manifest hash — no whole-Space seal hold #5701's per-module manifest-hash sync counting the partition as tracked, or the local compile on c003e001. So I cannot say whether the park returns at the next framework identity. The check after the next roll is the same compilationStatus read.
I exercised the MCP/agent path (create, then read back). I did not exercise the portal's /feedback Submit button (FeedbackSubmitter.Submit).

Related, and fixed separately (#5766): agents filing into triage got Access denied: Create permission required. That was not this park. Every refused path in twelve agent transcripts from 2026-09-20 to 09-25 was Feedback/<id>, Feedback/_Submissions/<id> or Feedback/Inbox/<id>, all refused by design. The fleet-wide AGENTS.md block named the node type and never the namespace ({user}/Feedback). #5766 fixes the block. My own filing through rbuergi/Feedback/… landed at version 1 at 18:22Z.

Cluster note: #1246 (the PluginGating reconciler reporting its writes are "NOT STAYING") and #5264 (a type collision at the Feedback path, closed today) do not share this issue's root.

@sierragolflima

(re-posted 2026-10-11; originally by @sierragolflima on 2026-09-28)

@rbuergi on your first open condition: we will not re-drive
sglauser/Feedback/2026-09-24T15-42-23-client-b-reconcile. The request in it is obsolete. The client-b
reconcile it asked for completed on 2026-09-25 (Ops/Actions/reconcile-client-b-20260925-apply3,
state: Done), and Memex#515, which tracked the same request, is closed. Handing it over now would
only give triage a stale request to file.

So please treat that condition as withdrawn. Whether the issue closes on your end-to-end reading, or
waits for your other two conditions (why the park lifted, and the portal's Submit button), is your call.

@rbuergi

(re-posted 2026-10-11; originally by @rbuergi on 2026-10-07)

Status, 2026-10-07 ~16:15Z, read through the systemorph MCP as rbuergi. Still open. My credential cannot read the four submissions.

Read readings

search namespace:sglauser/Feedback returns count 0 over coverage [sglauser].
search namespace:Feedback/_Submissions returns 0 over [feedback].
get @Feedback/_Submissions/fb-597cd16bdedcc7c7fbee1da87e7375ad (the computed Inbox path of the first one) returns Not found.
Under RLS, none of these can tell "absent" from "not readable by me", so this reading says nothing about the four.

Recycle attempts

recycle @Feedback/Inbox was refused: no Update on the system-owned Feedback partition.
I filed the governed alternative instead: Ops/Actions/recycle-memex-feedback-inbox-20261007-1625 (a Recycle InstanceAction, target Feedback/Inbox, unforced). It is parked at AwaitingApproval and needs a global administrator other than the requester.

The live mechanism is unchanged from the 07:10Z reading.

Feedback/Feedback compiles.
Submissions reach triage within about a minute.
The Inbox watcher now names every submission it cannot hand over: dead letters Determine back-end contributors #3–Import #32, from Ops/Actions/logs-3042-deadletters-20261007-1630, tracked on Plugins#3042.
None of the four sglauser paths is on that roster. Two explanations fit: they were handed over, or they are not Feedback/Feedback records the watcher lists. I cannot tell which.

What closes this. Someone who can read sglauser/Feedback does one of the following:

Approves the recycle above, then confirms each of the three non-draft rows carries handedOverAt.
Or confirms that they are gone.

sglauser has already withdrawn 2026-09-24T15-42-23-client-b-reconcile, and row 6 was a Draft, so the open question is down to 2026-09-23-agents-md-stale-triage-rationale and 2026-09-23-crm-has-triage-feature-not-the-rule.

@rbuergi

(re-posted 2026-10-11; originally by @rbuergi on 2026-10-09)

Production verification on memex.systemorph.com, 2026-10-09 ~05:45Z. Closing.

The mechanism in the title is gone. memex runs 3.0.0-ci.10294, core dfc4a37ace, with sealed Plugins ea0f03d6. Feedback/Feedback compiles (/health bake-report: no Feedback type among the non-baked; "STALE-BUT-SERVING: none"), and the #3583 Untracked module content … DECLINED park is not served.

Submissions reach triage.

On control, namespace:Hosting/Triage/feedback holds 32 items, not truncated. Items arrived within about a second of their submission from 10-08 17:28Z to 10-09 05:40Z, including 24 re-handed records (Plugins#3042) and two later ordinary submissions.
Today I filed one myself: rbuergi/Feedback/fleet-switchedoff-test-red-20261007 was submitted at 05:40:10Z and became Hosting/Triage/feedback/memex-systemorph-com-feedback-submissions-fb-3a6ffa7eabc4392108d7cda569945168 in the same second.

The two outstanding sglauser submissions are not waiting anywhere. My credential cannot read sglauser/Feedback, so I used the system-side instrument instead. The Inbox watcher lists nodeType:Feedback/Feedback mesh-wide as System, across every partition (FeedbackBacklog.PendingQuery). It wakes every submitted record that has not been handed over, and it names every record it cannot read as a numbered [Feedback] dead letter #N (Plugins#3059).

Ops/Actions/logs-3042-deadletters-postrepair-20261009-0540 (18:29Z → 05:39Z, 102 lines, not truncated) covers about 51 Inbox listings on every replica generation. The only dead letters named are two rbuergi/Feedback/* records, since repaired. No sglauser path appears.
Ops/Actions/logs-5670-sglauser-feedback-20261009-0550 (\[Feedback\].*sglauser, 3 days, 10-06 05:44Z → 10-09 05:44Z) returns 0 lines, not truncated. No hand-over failure, no settle timeout and no dead letter names sglauser in 72 h.

So 2026-09-23-agents-md-stale-triage-rationale and 2026-09-23-crm-has-triage-feature-not-the-rule are not in a waiting or unreadable state on the running portal: each was handed over, retired, or removed. sglauser had already withdrawn 2026-09-24T15-42-23-client-b-reconcile, and row 6 was a Draft.

Not established: which of those three outcomes applies to each of the two records. Telling them apart needs a read of sglauser/Feedback by someone with access. Their triage items, if any, would be older than the 32 the folder currently retains.

Navigation Menu

Repository navigation

Feedback submissions are silently dropped on memex.systemorph.com — the Untracked-module-content park (#3583) costs user data, not just adoption #5670

The exact refusal, from a live node

Why this instance is worse than adoption lag

Measured, on memex.systemorph.com

Suggested remedy, per the refusal text itself

What I did NOT establish

Status 2026-09-30 ~16:50Z: the fix is live on the control instance; the closing Submit is still owed

Correction: two rows of the evidence table are confounded, and I should say so before anyone works this

Second correction, and a status reading as of 2026-09-25 ~11:00 Zurich

Classification

Row 6 was never submitted

The fault is unchanged

The `issue` intake is not classifying anything either

What remains the fix

Re-measured on the running control instance, 2026-09-26 ~18:20Z: the feedback path hands over end to end

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feedback submissions are silently dropped on memex.systemorph.com — the Untracked-module-content park (#3583) costs user data, not just adoption #5670

Description

The exact refusal, from a live node

Why this instance is worse than adoption lag

Measured, on memex.systemorph.com

Suggested remedy, per the refusal text itself

What I did NOT establish

Activity

rbuergi commented on Sep 26, 2026

rbuergi commented on Sep 28, 2026

rbuergi commented on Sep 28, 2026

rbuergi commented on Sep 28, 2026

rbuergi commented on Sep 30, 2026

Status 2026-09-30 ~16:50Z: the fix is live on the control instance; the closing Submit is still owed

rbuergi commented on Sep 30, 2026

rbuergi commented on Oct 7, 2026

rbuergi commented on Oct 7, 2026

rbuergi commented on Oct 11, 2026

Correction: two rows of the evidence table are confounded, and I should say so before anyone works this

rbuergi commented on Oct 11, 2026

Second correction, and a status reading as of 2026-09-25 ~11:00 Zurich

Classification

Row 6 was never submitted

The fault is unchanged

The issue intake is not classifying anything either

What remains the fix

rbuergi commented on Oct 11, 2026

rbuergi commented on Oct 11, 2026

Re-measured on the running control instance, 2026-09-26 ~18:20Z: the feedback path hands over end to end

rbuergi commented on Oct 11, 2026

rbuergi commented on Oct 11, 2026

rbuergi commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

The `issue` intake is not classifying anything either