Repository navigation
effect catalog pin is 10 betas behind, and the bump invalidates our effect patch #4797
Description
Activity
⚠️ SCOPE CORRECTION — it is not one patch, it is FOUR OF FOUR; and this one patches the crew's own substratePosted from intake, 2026-08-03, after this issue's triage was dispatched — so if the triage verdict below does not reflect this, this supersedes it. Everything here was verified by direct read at
main, not relayed.1. All four pnpm patches are invalidated, not just this one
patchedDependenciescarries four entries, every one keyed to an exact version, and every one of those deps has a newer version available:Patched dep Pinned Available effect4.0.0-beta.924.0.0-beta.102alchemy2.0.0-beta.592.0.0-beta.67@nkzw/fate1.3.11.3.2react-fate1.3.11.3.2Four of four. So the invalidation is not a property of this ticket — it is a property of any dependency sweep in this repo. A pnpm patch key is exact-version, so every patched dep breaks its patch on bump, by construction.
Consequence for planning: any sweep that prices patched deps as version-string edits is wrong on all four. This ticket owns the
effectone; the other three need the same treatment wherever they are planned.2. This patch touches the crew's own MCP substrate — a self-referential risk
The patch modifies, verified by reading it:
dist/unstable/ai/McpSchema.d.ts/.jsdist/unstable/ai/McpServer.d.ts/.jsdist/unstable/rpc/RpcSerialization.js
The MCP surface. Its consumers are
packages/pipeline-crew-mcp/—bin.ts,crew/session.ts,crew/served-toolset.ts,edge/channel-sink.ts,edge/claim-tool.ts,edge/kinds-tool.ts, and others — which is the crew channel substrate itself.So the failure mode is self-referential: if the patch does not re-derive cleanly against the new version, the thing that breaks is the MCP server the crew coordinates over. The channel could be lost mid-upgrade, and the coordination needed to recover the upgrade would be unavailable at exactly that moment.
Acceptance criterion this implies — it is not optional: wave B must verify the crew MCP still BOOTS, not merely that typecheck passes. A green typecheck against a patched-away MCP surface proves nothing about whether the server runs.
3. Still unverified — flagged, not guessed
Nobody has determined which of the three outcomes applies, for ANY of the four patches:
- still needed and re-derivable,
- still needed and not re-derivable (the upgrade stalls until upstream), or
- obsolete, because upstream landed the fix.
That requires reading each patch against the new source. It is real work, not a formality, and it should be a named first step rather than an assumption folded into the bump.
4. Structural parallel — the same trap in both halves of the ruling
#4796's triage found that the
tsgobinary is a patched@typescript/native-preview, overwritten in place by the rootpostinstall. So both halves of the founder's "typescript and effect" ruling sit on top of a patched dependency, and in both cases the bump is entangled with the patch rather than independent of it. Neither is routine.chief-of-staff spike — the patch question is ANSWERED for effect: B, RE-DERIVABLE, and one hunk is now obsolete upstream
Read-only spike, dispatched to settle acceptance criterion 1 before anyone plans the bump. Verdict is
git applyoutput, not judgement.Verdict: B — re-derivable. The upgrade is NOT stalled.
Four of the five patched files re-apply to
beta.102. The fifth must be deleted, not re-authored.Pre-image hashes for all five
indexblobs matchbeta.92exactly, so the baseline is verbatim and the check is meaningful.$ git apply --check -p1 effect@4.0.0-beta.92.patch # against beta.92 exit=0 $ git apply --check -p1 effect@4.0.0-beta.92.patch # against beta.102 error: patch failed: dist/unstable/ai/McpServer.d.ts:247 error: patch failed: dist/unstable/rpc/RpcSerialization.js:266 exit=1Per-file against
beta.102:McpSchema.d.ts0,McpSchema.js0,McpServer.js0,McpServer.d.ts1,RpcSerialization.js1.McpServer.d.tsfails only on a doc-comment reword in trailing context — upstream rewrote thelayerHttpdocblock. Reducing context fixes it; the four still-needed files apply as a set:$ git apply --check -p1 -C1 --include=<the four> effect@4.0.0-beta.92.patch Context reduced to (2/2) to apply fragment at 250 exit=0All five paths still exist at
beta.102— no upstream reorganisation.The
RpcSerialization.jshunk is OBSOLETE — delete itThis is the hunk flagged as an undescribed re-derivation hazard. It omitted the
idmember whenresponse.idwas nullish, becausebeta.92didNumber(undefined)→NaN→JSON.stringifyemittedid: null, which the MCP-SDK client reads as a malformed request (it routes on id-member presence) and never dispatches. Zero delivery.beta.102rewrote the same line:- id: response.id !== "" ? Number(response.id) : "", + id: response.id,
With the coercion gone,
response.idisundefinedfor a drain-built notification andJSON.stringifydrops undefined-valued keys — same wire outcome, different shape. That is also why it fails to apply: upstream changed the exact line.Tradeoff to keep visible: dropping it relies on
JSON.stringifyomitting undefined keys. Spec-guaranteed for JSON, but it would break if a non-JSON serialization (MsgPack) were ever swapped in.notif-id-omit.repro.test.tsshould keep covering it.The other three hunks are still load-bearing at beta.102
grep -rn "claude/channel\|ChannelNotification"inbeta.102'sdist/unstable/ai/→ zero hits.experimentalinMcpServer.{js,d.ts}→ zero hits.encodeNotificationis still the blindSchema.Union(...).Including the one that looks fixed and isn't:
beta.102did add a real"notifications/initialized"handler that doesserver.initializedClients.add(client.id). It is still unreachable — the routing branch doeshandlers.mapUnsafe.get(request.tag)with the bare tag, while that context is keyed byrpc.key, defined as`effect/rpc/Rpc/${_tag}`. So the phoenix hunk is still required; applying it yields a harmless idempotent double-add.Correction to the working record — the header count is wrong in TWO ways
The prose block above
patchedDependencies:inpnpm-workspace.yaml(~lines 139–152) is already stale at beta.92, not merely at bump time: it says "TWO hunks" when the shipped patch touches five files, and it describes the channel payload as{ message, _meta }when the patch has{content, meta}. A re-deriver skims exactly that block first. Worth fixing in the same PR.Unverified — stated, not guessed
- Not run against the real crew MCP at beta.102. One new gate in
beta.102sits before the phoenix insert point:if (!getInitializedClient(...)) return Effect.void. Traced in source to resolve correctly for stdio, but not executed. The five@patch-pin: effect@4.0.0-beta.92tests underpackages/pipeline-crew-mcp/src/edge/are where that gets settled in one run — which is exactly the "must BOOT, not just typecheck" criterion. - Whether
@effect/platform-node,@effect/vitest,@effect/sql-d1etc. havebeta.102releases and peer-compat — out of scope, unchecked.
Recommended shape
Bump, re-key the patch to
effect@4.0.0-beta.102, delete theRpcSerialization.jssection, update the five@patch-pin:header comments together with thepatchedDependencieskey, and record inpnpm-workspace.yamlthat upstream fixed the id-coercion.- Not run against the real crew MCP at beta.102. One new gate in
Founder ruling (2026-08-13, via chief-of-staff): out of scope for the current phase — removed from M44, and deliberately NOT moved to M46 (fabrika fast follows) either. The effect catalog bump is phoenix platform maintenance, not fabrika work. This supersedes the 2026-08-03 'update immediately' urgency: the ticket stays open, un-milestoned, until the founder re-picks it after the fabrika switch.
- No description provided.
Triage note: metadata-only repair of the live homing-guard report #8477, authorized by the supervising intake session after reading this issue's rulings. The later founder ruling at #4797 (comment) supersedes the original immediate urgency and explicitly keeps this ticket open and un-milestoned until the founder re-picks it. Preserve that deferral rather than force-fitting a home or treating it as fog/pipeline maintenance.
Park on
status:needs-info, with no type, priority, audience or home, while preserving the report and all founder comments. This is neither closure nor authorization for a dependency upgrade.Unblock question for the founder: has this platform-maintenance ticket been re-picked, and if so under which current scope/home? On a re-pick, revalidate its original patch and test criteria against current source before returning it to agent-ready.
pnpm-workspace.yamlat origin/main still uses defaulteffect: 4.0.0-beta.92; the Tuval rc.112 catalog is separate, not completion of this ticket. The original crew MCP surface and patch account have since changed, so the historical criteria are not silently certified today. No registry call, bump, release, implementation, or new scope was performed in this repair.4 remaining items
- No description provided.
Opened #8934 at b4cc8bf through Fabrika after independent triage. The claimed tree starts at main bc7c6b8 and preserves the prepared 149-path change.
Review the Alchemy D1 migration patch and its twelve actual-pipeline tests first, then shared-D1 auth ownership and explicit remote-D1 dev policy. Product behavior and named CLI contracts are preserved; Alchemy dev migration application and stage defaults intentionally change. General agent-doc cleanup is separate and overlaps AGENTS.md, the pattern index and feature-services.md; its organization should win while retaining this PR's current API/runtime facts.
Node 26.2.0 validation passed: frozen install, Fabrika code/prose checks, builds, web 2797 unit and 366 client tests, Tuval 3097 unit and 79 local integration tests, package/infra 20 tasks including CLI 9078 tests, catalog/patch guards, executable doc examples and offline bundle guard with positive control. Initial parallel Tuval failures passed unchanged on focused main/upgraded comparisons and sequential full reruns; the PR records them without asserting a cause.
No manual deployment or cloud-resource changes were run. Real D1 conversion, DO migrations, Flagship API state, auth startup and SSE/HMR remain unverified. The branch is pushed and ready for independent PR review; it is not merged.
- added 6 commits that reference this issue
on Sep 10, 2026
Current scope
Unify workspace consumers on one exact compatible Effect 4 release and migrate the Alchemy stack and required libraries together. Preserve product behavior, CLI contracts, shared D1/auth ownership and maintained patch protections. General agent-context restructuring and the TypeScript upgrade are separate work.
Triage note: verified the gap at origin/main 29c791b. The root catalog still uses beta.92 while Tuval uses rc.112. The old MCP consumer named in earlier criteria is absent; current CLI patch tests replace that obsolete validation target. The user requested this upgrade next. This is dependency maintenance, not a new product capability.
Triage note: the owner search for Effect, Alchemy, dependency and catalog found this issue; #8930 was folded here. #8115 is a separate credential-permission problem, and #8909 concerns the pattern-reading tool. Home this shared runtime/tooling maintenance in the existing pipeline and reliability lane; no product milestone owns the whole dependency graph.
Triage note: independently rechecked at origin/main bc7c6b8. This upgrade preserves product behavior and the named CLI contracts. It intentionally adopts Alchemy beta.77 dev migration application and stage precedence/default changes described below; it does not promise identical operational behavior. Cloudflare runtime checks remain unverified and must not be claimed from local tests.
Implementation boundary
Use Effect and platform/sql/vitest companions 4.0.0-rc.112, Alchemy 2.0.0-beta.77, Distilled Cloudflare 1.0.0-rc.9 and Drizzle ORM/Kit 1.0.0-rc.5-ab785fc. Required worker-types and React patch alignment may move to maintain one compatible resolved graph. Recheck the current registry; a newer tag alone is not grounds to abandon this source-verified compatible set. Ground API choices in Effect-TS/effect main LLMS.md and exact release source. Alchemy beta.77 still calls Config.string, which rc.113 removed.
Preserve the existing local implementation rather than rebuilding it. Move it to a clean Fabrika-claimed tree from fresh main, then validate that tree. No cloud deployment, credential changes or manual remote-resource operations are part of this build.
Acceptance criteria
Original report (verbatim)
Founder ruling, 2026-08-03 (authoritative): "we should do the typescript and effect version updates immediately imo." This issue is the
effecthalf;#4796is thetypescripthalf. Both aretype:chore·p0, homed in the fabrika campaign milestone.The problem
The
effectcatalog pin inpnpm-workspace.yamlis4.0.0-beta.92, ten betas behind the registry'sbetadist-tag, and that exact version string is also the key of apatchedDependenciesentry. A pnpm patch is keyed to an exact version, so the bump is entangled with the patch: it is not a version-string edit.Verified at
origin/main(triage re-verified every price-moving claim)pnpm-workspace.yamlcatalog:effect: 4.0.0-beta.92, plus five@effect/*siblings pinned to the same exact version and needing to move in lockstep —@effect/platform-bun,@effect/platform-node,@effect/sql-d1,@effect/sql-pg,@effect/vitest. (@effect/language-serviceand@effect/tsgoare on independent^ranges and are not part of the lockstep set.)patchedDependenciescarrieseffect@4.0.0-beta.92: patches/effect@4.0.0-beta.92.patch. Confirmed 175 lines across five files, all underdist/:dist/unstable/ai/McpSchema.{d.ts,js},dist/unstable/ai/McpServer.{d.ts,js},dist/unstable/rpc/RpcSerialization.js.package.jsonfiles declareeffect, all viacatalog:. The version string moves in one place; the blast radius is the runtime surface, not the manifests.npm view effect dist-tags→latest: 3.22.1(the v3 line),beta: 4.0.0-beta.102(the line we are on). Target version selection is the implementer's call; this is the observation, not a proposal.The unresolved question that sizes the work
Whoever picks this up must first settle, by reading
patches/effect@4.0.0-beta.92.patchagainst the target beta's source, which of three applies per hunk:This is UNVERIFIED and triage does not guess it. It is acceptance criterion 1 below because it sizes everything downstream.
Triage note — the patch has THREE hunks, not two (the rationale header undercounts)
The filing flagged this as observed-not-diagnosed; triage read the patch and resolves it:
patchedDependenciesrationale comment inpnpm-workspace.yamlsays "TWO hunks on 4.0.0-beta.92" and describes only theMcpServerexperimentalcapability passthrough and theMcpSchemaChannelNotification(both from#3053, epic#3045, behavior-pinned bypackages/pipeline-crew-mcp/src/edge/mcp-channel.test.ts— the@patch-pinguard,#3040/#3051).dist/unstable/rpc/RpcSerialization.js: a third, independently-motivated hunk that omits the JSON-RPCidmember for notifications instead of coercing it tonull. That hunk is self-documenting — it carries its own inline rationale naming#3495and ADR 0038, and states the failure it prevents (anid: nullreads as a malformed request to the MCP-SDK client and is never dispatched → zero delivery).Triage note — both halves of the ruling sit on a patched dependency
Carried from
#4796's triage, not re-derived here: thetsgobinary is a patched@typescript/native-preview, overwritten in place by a rootpostinstall. Both halves of the founder's ruling are entangled with a patch mechanism. A planner must not price either half as a routine bump.Sequencing — triage agrees, but this is not triage's ruling
The filing recommends wave B (this) as a separate PR from
#4796's wave A. Triage concurs on the stated reasoning: they share no failure mode, and one PR carrying both is unbisectable — a red typecheck could come from the compiler swap or the runtime bump with no cheap way to tell which. Recorded as a recommendation; triage does not rule sequencing and has taken no action on it. Neither issue blocks the other.Control-plane surface
Ran
pipeline-cli cp-classify classifythis run over the expected change set (pnpm-workspace.yaml,pnpm-lock.yaml,patches/effect@4.0.0-beta.92.patch, the@patch-pintest, workspacepackage.jsonfiles):not-control-plane [path-clear-no-content-source]— proven ordinary. Conditional, same as#4796: adding a.decisions/**ADR to the change set flips it tocontent-undetermined(ADR 0164 content clause), which requiresguard-content-probe classifyat the PR head before claiming ordinary. Re-run the classifier against the actual diff; do not carry this verdict blind.Acceptance criteria
patches/effect@4.0.0-beta.92.patchis read against the target version's source and each of its three hunks is resolved to (a) applies as-is, (b) re-derived, or (c) deleted-because-upstream-landed — with the per-hunk verdict recorded in the PR description.effectcatalog pin and the five lockstep@effect/*pins (platform-bun,platform-node,sql-d1,sql-pg,vitest) all move to the same target version; no@effect/*is left at4.0.0-beta.92.patchedDependencieskey and the patch filename are renamed to the new exact version, andpnpm installapplies it without a "patch did not apply" warning.patchedDependenciesentry, the patch file, and the rationale comment go with it.pnpm-workspace.yamlrationale comment abovepatchedDependenciesis corrected to describe all surviving hunks — the "TWO hunks" count is wrong today (RpcSerialization.jsis undescribed there).packages/pipeline-crew-mcp/src/edge/mcp-channel.test.ts(the@patch-pinguard) passes — the behavior the patch buys is still pinned, or the guard is updated with a recorded reason if upstream now provides it natively.catalog:—pipeline-cli catalog-guard checkis green (CLAUDE.md, "Every dependency viacatalog:").pnpm typecheck,pnpm lint, and the test suite are green across all 25 dependent workspace packages.#4796'stypescriptwave (see Sequencing above).Original report (verbatim)
Summary
The founder ruled on 2026-08-03 that "we should do the typescript and effect version updates immediately imo." The TypeScript half is tracked at #4796, but the
effecthalf has no ticket at all — this files it. The catch: oureffectpin is a patched dependency, and a pnpm patch is keyed to an exact version, so bumping the version invalidates the patch. This is not a version-string edit.What I was doing
Following up on the founder's ruling covering two version updates. #4796 covers
typescript; checking whether theeffecthalf was tracked anywhere turned up nothing — #4796's body does not mention the effect version, and an open-issue search for an effect bump returns no match.What I observed
1. The pinned version (
pnpm-workspace.yaml, catalog, read atmain):Five
@effect/*siblings are pinned to the same exact version in the same catalog and would have to move in lockstep:2. The catalog also carries a PATCH keyed to that exact version —
pnpm-workspace.yaml,patchedDependencies:The patch is 175 lines and touches five files, all under
dist/:The inline rationale above
patchedDependenciesdescribes it as "TWO hunks on 4.0.0-beta.92 (dist only)" giving the MCP channel edge what the fixed publicMcpServer/McpSchemasurface can't express (#3053, epic #3045), behavior-pinned bypackages/pipeline-crew-mcp/src/edge/mcp-channel.test.ts(the@patch-pinguard, #3040/#3051), and ends "Retire when effect ships these natively." Note the comment names two files while the patch modifies five — theRpcSerialization.jsdiff is not described there. Flagging as observed, not diagnosed.3. Latest published on the live npm registry (
npm view effect dist-tags):{ "latest": "3.22.1", "beta": "4.0.0-beta.102" }So
latestis the v3 line (3.22.1) and the v4 beta line is at4.0.0-beta.102— our pin is 10 betas behind on the line we're actually on. I am not proposing a target version beyond reporting what the registry says.4. Workspace packages depending on
effect: 25, all viacatalog:(apps/web,infra/ci-credentials,infra/depo, andpackages/:admin-grant,anka-ops,audit-run,audit-stage,audit-verdict,authz,cf-credentials,d1-rest,depo,design-capture,fabrika-cli,fate-effect,flake-rate,founder-seed,fts-backfill,local-render,migrations-guard,moderator-grant,orphan-sweep,pipeline-cli,pipeline-crew-mcp,preview-seed). The catalog means the version string itself changes in one place; the blast radius is the runtime surface, not the manifests.Why it matters
The pin is patched, and a pnpm patch entry is keyed to an exact version. Bumping
effectinvalidatespatches/effect@4.0.0-beta.92.patch— it will either fail to apply or need re-deriving against the new source. So the shape of the work is not "change a version string", it is:Which of (a)/(b)/(c) applies is UNVERIFIED. It needs someone to read what the patch actually does and check it against the target version's source. I am deliberately not guessing, and not proposing how to re-derive it.
The same trap, twice. #4796's triage found that the
tsgobinary is a patched@typescript/native-preview, overwritten in place by a rootpostinstall. Both halves of the founder's ruling sit on top of a patched dependency, and in both cases the version bump is entangled with the patch rather than independent of it. Worth stating so a planner does not price either half as a routine bump.Pointers
pnpm-workspace.yaml— thecatalog:block (theeffectand@effect/*pins) and thepatchedDependenciesblock plus its inline rationale comment.patches/effect@4.0.0-beta.92.patch— the patch itself; read this to resolve (a)/(b)/(c).packages/pipeline-crew-mcp/src/edge/mcp-channel.test.ts— the@patch-pinbehavior guard (Investigation: channel-edge architecture — pnpm-patched McpServer vs bespoke RpcServer+McpSchema edge vs raw MCP SDK shim #3040/pipeline-cli patch-guard — fail-closed guard: no pnpm patch without a behavior-pinning test #3051) that pins what the patch buys.typescripthalf of the same founder ruling).catalog:" — the catalog invariant, enforced bypipeline-cli catalog-guard check.Suggested next step (non-binding)
A guess, and the implementer's call. Read
patches/effect@4.0.0-beta.92.patchand the corresponding source at the target beta first, to settle whether the patch is still needed, needs re-deriving, or can be deleted — that answer sizes everything else.On sequencing, carried as a recommendation and not a decision: this looks like wave B, a separate PR from #4796's wave A (
typescript+ the tsgo patcher, coupled by their own patch mechanism, ~27 manifests). The two share no failure mode, and one PR carrying both is unbisectable — a red typecheck could come from the compiler swap or the runtime bump with no cheap way to tell which.Relationship to #4796: siblings under one founder ruling, independent to build. Neither blocks the other.
Filed by an agent · session
51a8e31d-bfd4-4627-af80-f00fcd0805c5· branchmain· 2026-08-03T02:30:39ZAmendment — 2026-09-10
Current dependency findings from the repository audit
Report #8930 covers this same upgrade and is being folded here. Current main still has Effect beta.92 plus Tuval's rc.112 named catalog. The user requested the repo-wide upgrade next and a separate Fabrika PR.
The compatible prepared target is Effect and its platform/sql/vitest companions 4.0.0-rc.112, Alchemy 2.0.0-beta.77, Distilled Cloudflare 1.0.0-rc.9 and Drizzle 1.0.0-rc.5-ab785fc. Alchemy beta.77 calls Config.string, removed in rc.113, so the newer RC tag is not a compatible stack. Follow Effect-TS/effect main LLMS.md and exact release source.
Required migration work includes Schema.TaggedError, CLI boolean defaults and hidden positional help, Alchemy worker bundling, mixed D1 migration history and explicit rename-only adoption. Phoenix already owns its auth implementation; retain the shared D1, secret binding and plugins using a local service contract when removing the obsolete upstream auth tag package. Real Cloudflare checks remain unverified; no cloud deployment is authorized in this task.
The old MCP consumer and its named test have been deleted from main. Review every current patch hunk against actual consumers rather than requiring that retired test. Fresh claimed-tree checks must cover the updated graph and current CLI/migration regressions. General agent-doc restructuring is a separate change.