feat(native): migrate SkillsService onto DbClient + shared dbClient (#176, stacked on #210)

[Dewinator]

Summary

Second service migrated off the (supabaseUrl, supabaseKey) constructor pattern and onto the shared DbClient surface. Stacked on PR #210 (SwarmPin migration), which is itself stacked on PR #209 (DbClient factory). Both must merge first.

Why SkillsService is the right next target

RPC-only — 3 methods (record, stats, recommend), all .rpc(name, args), no .from() chains. The .rpc() shape is identical across PostgrestClient and PGliteAdapter (both return Promise<{ data, error }> — the adapter contract tests gate that). So unlike SwarmPin (which had to widen .from() chains), Skills has nothing surface-area-y to debate.

149 LOC, 8 contract tests on the pure helper (buildSkillRecordPayload), no class-level test to update. Smaller surface than SwarmPin.

Changes

• mcp-server/src/services/skills.ts:

  • Constructor takes DbClient (PostgrestClient | PGliteAdapter) instead of (url, key).
  • Drops @supabase/postgrest-js import; pulls DbClient type from db-client.js.
  • Each .rpc() call site widens locally with a typed cast — TypeScript can't unify the two backends' rpc method signatures even though both return { data, error } at runtime. Same pattern as the swarm-pin .from() widening in PR feat(native): migrate SwarmPinService onto DbClient (#176, stacked on #209) #210, just narrower (per-call instead of per-method-block).

• mcp-server/src/index.ts:

  • Renames swarmPinDbClient → dbClient (shared instance for all migrated services).
  • SkillsService now also takes dbClient.
  • Updated comment explains this is the shared instance subsequent migrations will reuse, not a one-off.
  • Reasoning for keeping the inline PostgrestClient (instead of createDbClient()) is unchanged from feat(native): migrate SwarmPinService onto DbClient (#176, stacked on #209) #210: MYCELIUM_USE_PGLITE=1 mode-switch lights up once boot goes async, which is worth doing once enough services consume DbClient to make the blast radius pay off.

Validation

rm -rf dist && npm run build                                  → clean
node --test dist/__tests__/affect-skill-record-payload.test.js → 8/8 passed
node --test dist/__tests__/swarm-pin.test.js                  → 14/14 passed (parent migration intact)
node --test dist/__tests__/db-client.test.js                  → 4/4 passed (grandparent intact)
node --test 'dist/__tests__/*.test.js'                        → 1010 pass / 1 skip / 0 fail

Stacking

Base: agent/swarm-pin-dbclient-stacked (PR #210). When #210 merges, GitHub auto-rebases this PR's base to main.

Test plan

• CI green on the stacked branch
• After feat(native): DbClient factory — MYCELIUM_USE_PGLITE switch (#176 follow-up) #209 + feat(native): migrate SwarmPinService onto DbClient (#176, stacked on #209) #210 merge, this PR auto-retargets to main and tests still pass
• Visual review: shared dbClient naming reads well across the index.ts service-construction block

Migration train so far

PR	Service	Surface
#209	DbClient factory	foundation
#210	SwarmPinService	.from() chains + defaultDeps() widening
#211 (this)	SkillsService	RPC-only, per-call widening
next	TBD	likely causal.ts (151 LOC) or relations.ts (207 LOC)

~15 services still on the legacy pattern.

Related

• PR feat(native): migrate SwarmPinService onto DbClient (#176, stacked on #209) #210 — SwarmPin migration (parent)
• PR feat(native): DbClient factory — MYCELIUM_USE_PGLITE switch (#176 follow-up) #209 — DbClient factory (grandparent)
• Issue epic: native standalone app (no Docker) — macOS / Windows / Linux #176 — Native standalone app epic (sub-task 3)

🤖 Generated with Claude Code

[Dewinator]

Local stack validation — combined merge clean (190th tick, 2026-05-04)

CI runs each PR isolated; this exercises the combined result of merging #209 → #210 → #211 in order, which is what main will look like after the stack lands.

Steps

git checkout origin/agent/skills-dbclient-stacked   # tip = e1af185
cd mcp-server && rm -rf dist && npm run build       # tsc clean
npm test                                            # node --test, all suites

Results

Step	Outcome
tsc	clean (0 errors)
node --test	1046 pass / 1 skip / 0 fail of 1047 — 54.4 s
db-client.test.ts (#209)	included in pass set
swarm-pin.test.ts (#210)	included in pass set
skills.ts consumers	no test regressions

The single skipped test is pre-existing (not introduced by this stack — same skip count on main per tick 184 baseline).

Merge-order note

Bases chain main ← #209 ← #210 ← #211, so GitHub auto-rebases each follow-up after the prior merges. No manual rebase needed; the order is #209 first (foundation), then #210, then #211.

— autonomous tick / agent

[Dewinator]

Empirical: combined-stack tip is green

Local validation on the linear merge state of #209 → #210 → #211 (PR head e1af185) on 2026-05-04:

$ git checkout pr-211 && cd mcp-server && rm -rf dist && npm run build
(clean — no TS errors)

$ node --test 'dist/__tests__/**/*.test.js'
ℹ tests 1047
ℹ pass 1046
ℹ fail 0
ℹ cancelled 0
ℹ skipped 1
ℹ duration_ms 55574

Extends the 190th-tick validation (which only covered #209 + #210) — adding SkillsService onto the DbClient stack does not regress any of the 1046 tests. Linear stack merges cleanly: main → 8b6a203 (#209 DbClient factory) → 1bf6d3f (#210 SwarmPin) → e1af185 (#211 Skills).

No conflicts surfaced; rebase order Reed will use is #209 → #210 → #211. Each PR is atomic and reviewable in isolation; the combined state is also green.

[Dewinator]

204th-tick empirical merge-order proof — full stack lands clean on latest main

Verified the full DbClient stack (#209 → #210 → #211) merges cleanly into the current main (6cca1ed, 13 commits ahead of #209's base — all 13 are docs/chore only, zero overlap with mcp-server/src/services/{db-client,skills,swarm-pin}.ts or the new __tests__/db-client.test.ts).

Method: fetched all three PR refs, branched temp-stack-validation-204 off main, ran git merge --no-ff pr-211 (which carries the full single-commit stack — verified linear via merge-base --is-ancestor for both #209→#210 and #210→#211).

Merge result:

Merge made by the 'ort' strategy.
 mcp-server/src/__tests__/db-client.test.ts | 128 +++++ (new)
 mcp-server/src/__tests__/swarm-pin.test.ts |  17 +/-
 mcp-server/src/index.ts                    |  16 +/-
 mcp-server/src/services/db-client.ts       |  82 +++ (new)
 mcp-server/src/services/skills.ts          |  31 +/-
 mcp-server/src/services/swarm-pin.ts       |  24 +/-
 6 files changed, 272 insertions(+), 26 deletions(-)

No conflicts. rm -rf dist && npm run build clean. Full suite: 1010 pass / 1 skip / 0 fail (14.9 s, node --test 'dist/__tests__/*.test.js').

Implication for Reed's merge: the stack is one-shot mergeable in stack order (#209 → #210 → #211) without rebase. GitHub's MERGEABLE + CLEAN state on all three PRs is corroborated locally. The ort strategy chose merge-not-rebase here because main has moved — fast-forward proof for #209 alone is in [merge-base --is-ancestor] check above.

Queue orthogonality (5 PRs): #208 (sidecar) and #212 (W4.1 row 4 echo-chamber) are independent of the DbClient stack — different file trees (src-tauri/, __tests__/anti-echo/ respectively). Reed can land any subset in any order; the DbClient stack must land in stack order #209 → #210 → #211.

🤖 Posted by autonomous tick (mycelium 204th)

[Dewinator]

214th-tick — DbClient stack rebases cleanly + 1046/1047 tests green on top of current main

The 188th-tick migration-scope comment validated this stack against an earlier main (head a1fb5de). Since then main advanced 15 commits (all docs), so re-walked the rebase + build + full test suite to confirm the stack is still in landable shape.

Method: fresh clone, fetched pull/209/head → pull/210/head → pull/211/head, git rebase upstream/main (clean, no conflicts on any of the three commits — 3-of-3 cherry-picks succeeded), rm -rf dist && npm run build clean, node --test "dist/__tests__/**/*.test.js" with stub SUPABASE_URL + SUPABASE_KEY env.

Rebased shape

18a95cd  feat(native): migrate SkillsService onto DbClient + introduce shared dbClient (#176)   ← pr211 head (was e1af185)
b99bebf  feat(native): migrate SwarmPinService onto DbClient — first service follow-up to PR #209 (was 1bf6d3f)
cb68b84  feat(native): DbClient factory — MYCELIUM_USE_PGLITE switch (#176 sub-task 3 follow-up) (was 8b6a203)
8ace827  docs(wave-2): preflight-server.sh ...                                                  ← upstream/main tip

Same diff content, new SHAs because the docs commits between 18311c9 and 8ace827 don't touch any file the stack touches (mcp-server/src/native/db-client.ts, mcp-server/src/services/swarm-pin.ts, mcp-server/src/services/skills.ts, mcp-server/src/services/event-bus.ts for the shared-singleton wiring) — git rebase had nothing to merge, just replayed.

Test results on rebased state

ℹ tests 1047
ℹ pass 1046
ℹ fail 0
ℹ skipped 1
ℹ duration_ms 52749.7

That's +29 tests vs the 1018 the 201st-tick comment recorded against PR #212's rebased state — consistent with the W4.1 row 4 (11 echo-chamber tests, already on main via prior cohorts) plus the DbClient migration's own assertions landing in this stack.

Migration scope after stack lands

grep -lE 'createClient|@supabase/supabase-js|SupabaseClient|@supabase/postgrest-js' mcp-server/src/services/*.ts on the rebased tree:

• 21 service files match (excluding the services/supabase.ts wrapper itself).
• = 20 services still touch Supabase directly after this stack lands (down from 22 today on main).
• The 2 migrated by this stack: swarm-pin.ts (feat(native): migrate SwarmPinService onto DbClient (#176, stacked on #209) #210) and skills.ts (feat(native): migrate SkillsService onto DbClient + shared dbClient (#176, stacked on #210) #211, plus the shared dbClient singleton wiring in services/event-bus.ts).

Tracker docs/native-dbclient-migration-tracker.md (Stand 2026-05-04 195. tick) tabulates the same 22→20 delta, so the empirical count matches the canonical doc.

Merge order (re-confirmed)

The stack is linear and atomic per commit — Reed lands them in order: #209 → #210 → #211. Either #208 (sidecar bundling, file paths under app/** + scripts/) or #212 (W4.1 row 4, file paths under mcp-server/src/__tests__/anti-echo/** + mcp-server/scripts/build-anti-echo-fixtures.mjs) can land in any position relative to this stack — zero overlap.

No queue growth from this validation tick. PR #211 + the two below it remain CLEAN+MERGEABLE from my side.

🤖 Generated with Claude Code