Backfill hasCoreSwarmParticipant misses 33 sessions with non-shared userId

Context

Surfaced by the new buildChromaMigrationStats projection in mcp__neo-mjs-memory-core__healthcheck response post-#11200 backfill --apply execution (2026-05-11T12:24:20Z):

"session": {
    "totalRecords": 980,
    "tagged": 980,
    "missingUserId": 0,
    "shared": 934,
    "migrationDebt": 33,
    "coreSwarmParticipant": 83,
    "coreSwarmParticipantHidden": 33,
    "perUserId": {
        "neo-gemini-3-1-pro": 46,
        "shared": 934
    }
}

33 sessions remain visibility-hidden despite backfillChromaSharedUserId.mjs --apply at 12:20Z (which tagged 8392 memory + 934 session records, matching the dry-run count exactly). These 33 sessions:

• Have core-swarm participants in their participatingAgents metadata
• Have userId='neo-gemini-3-1-pro' (not 'shared')
• Should have been re-tagged to 'shared' by the backfill script per #11181's contract
• Were NOT re-tagged → cross-clone visibility regression remains for these 33 sessions for @neo-opus-4-7 + @neo-gpt

Independently corroborated by @neo-gpt's healthcheck at ~12:25Z (same coreSwarmParticipantHidden: 33 value).

The Problem

The backfill script's hasCoreSwarmParticipant logic appears to have a metadata-shape edge case not covered by the V-B-A:

1. Shape variation hypothesis: 33 affected sessions may have participatingAgents metadata in a different shape than the parseAgentList function handles
   • parseAgentList accepts String | String[] | null | undefined
   • May NOT handle Set shape, comma-separated-with-spaces shape, JSON-stringified array shape, or other variants
2. Stale pre-#11200-metadata-shape hypothesis: these 33 sessions may pre-date the canonical participatingAgents writing contract; their metadata may be stored under a different key or encoded differently
3. Logic edge case hypothesis: the hasCoreSwarmParticipant check may have an off-by-one in the agent-list iteration

The healthcheck projection IS correctly identifying these 33 sessions as visibility-debt — so the OBSERVABILITY half of PR #11200 works. The MIGRATION half misses them.

The Architectural Reality

• ai/scripts/backfillChromaSharedUserId.mjs findRecordsToTag (lines ~similar to script + the hasCoreSwarmParticipant import from RequestContextService)
• ai/mcp/server/shared/services/RequestContextService.mjs parseAgentList + hasCoreSwarmParticipant (canonical implementations consumed by script)
• ai/services/memory-core/HealthService.mjs buildChromaMigrationStats + #scanChromaMetadata (NEW from PR #11200) — projection function that IS correctly exposing the visibility-debt
• The 33 affected sessions are NOT identified by row-ID anywhere; investigation requires direct Chroma metadata query

The Fix

Phase 1 — Diagnostic: Add a debug-print mode to backfillChromaSharedUserId.mjs that emits the actual metadata of the 33 unprocessed core-swarm-participant sessions when run with --debug-hidden flag. Identify the shape variation causing the gap.

Phase 2 — Fix parseAgentList: Once shape is identified (Set, JSON-stringified, comma-with-spaces, alternate-key), extend parseAgentList to canonicalize. Add unit test for the identified shape variant.

Phase 3 — Re-run backfill: After fix, run node ai/scripts/backfillChromaSharedUserId.mjs --port 8001 --apply again. Expected: coreSwarmParticipantHidden: 0 in subsequent healthcheck.

Acceptance Criteria

• --debug-hidden flag added to backfillChromaSharedUserId.mjs that identifies the shape of the 33 unprocessed sessions
• Investigation findings documented in this ticket as a comment (which shape variant caused the miss)
• parseAgentList extended to handle the identified shape variant (with unit test)
• Re-run backfill --apply shows coreSwarmParticipantHidden: 0 in healthcheck.migration.chromadb.session
• Verification: @neo-opus-4-7 + @neo-gpt confirm get_all_summaries({limit:5}) returns the previously-hidden 33 sessions

Out of Scope

• Refactoring the entire backfill script (just shape-handling extension)
• Adding new fields to participatingAgents metadata (the script reads existing data)
• Changing the canonical write-time contract (resolveSummaryVisibilityUserId is fine; it's the read-time visibility correction that's missing 33 sessions)

Avoided Traps

• Mass-tag-all-sessions-with-userId-neo-gemini-3-1-pro to shared — rejected. Some of the 46 neo-gemini-3-1-pro-tagged sessions may legitimately be Gemini-private (no core-swarm participants). Only the 33 with core-swarm participants should be re-tagged.
• Side-step the shape-variation diagnostic — rejected. Without knowing WHICH shape variant causes the miss, fixing parseAgentList is guess-and-check.
• Cross-syncer test-gap absorption — captured separately for #11195 30-day Step 2.5 validation tracker; that's a broader concern; this ticket is the specific 33-session-fix.

Related

• PR #11200 — fix(memory-core): share core swarm summaries (#11181) — substantive fix that surfaced this gap
• #11181 — original visibility regression ticket
• #11195 — 30-day Step 2.5 validation tracker (this gap is an empirical anchor for the cross-syncer test-coverage deficit captured there)
• 3-way V-B-A: @neo-opus-4-7 healthcheck 12:24Z + @neo-gpt healthcheck ~12:25Z both report coreSwarmParticipantHidden: 33

Origin Session ID

c2912891-b459-4a03-b2af-154d5e264df1

Handoff Retrieval Hints

• query_raw_memories(query="33 hidden sessions backfill hasCoreSwarmParticipant parseAgentList visibility")
• File anchors: ai/scripts/backfillChromaSharedUserId.mjs + ai/mcp/server/shared/services/RequestContextService.mjs + ai/services/memory-core/HealthService.mjs#buildChromaMigrationStats
• Healthcheck snapshot: mcp__neo-mjs-memory-core__healthcheck at 2026-05-11T12:24:20.947Z → migration.chromadb.session.coreSwarmParticipantHidden: 33