The problem
defineFragment, runQuery, runQueryOne and ResultOf were deleted from @opensaas/stack-core by ADR-0041. Three skills in claude-plugins/opensaas-migration/skills/ still import them from that package and build whole recipes on them:
migrate-context-calls/SKILL.md — 39 references, including import { defineFragment, type ResultOf } from '@opensaas/stack-core' and import { runQuery, runQueryOne } from '@opensaas/stack-core', plus "Recipe 3 — gql.tada typed documents → defineFragment + ResultOf" built end to end on themkeystone-virtual-fields-context/SKILL.md — 5 referencesopensaas-migration/SKILL.md — 10 references
An agent that loads one of these writes an import that does not resolve. The mechanism they reach for is native on the secured surface now: .select() narrows the result type and composes inside .include() at every level, and reuse is an ordinary function returning a composed query value, which needs no bespoke type.
Why this is filed rather than fixed
ADR-0041 names these skills explicitly and puts them out of scope for the Prisma 8 map, and §15 of the architecture spec rules the whole Keystone-migration story out of scope. The documentation site's own migration guides (docs/content/how-to/migrate.md, migrate-from-keystone.md) were already corrected by #1174 and carry no reference to the deleted API — every "fragment" left in them names Keystone's own GraphQL fragments on the Keystone side of a mapping table, which is right.
So #1175's "migration-guide references to the fragment API are removed" is satisfied for the guides. This is the remainder, surfaced rather than left implicit, per that ticket's third acceptance criterion.
What to do
Rewrite the three skills' read-migration recipes onto the composed read. Note that this touches claude-plugins/, so it needs a plugin-version bump in plugin.json and the matching .claude-plugin/marketplace.json entry, not a changeset.
Worth deciding at the same time whether the opensaas-migration plugin is still supported at all, given §15. If it is not, deleting these recipes is cheaper than rewriting them.
Context
🤖 Generated with Claude Code
The problem
defineFragment,runQuery,runQueryOneandResultOfwere deleted from@opensaas/stack-coreby ADR-0041. Three skills inclaude-plugins/opensaas-migration/skills/still import them from that package and build whole recipes on them:migrate-context-calls/SKILL.md— 39 references, includingimport { defineFragment, type ResultOf } from '@opensaas/stack-core'andimport { runQuery, runQueryOne } from '@opensaas/stack-core', plus "Recipe 3 — gql.tada typed documents →defineFragment+ResultOf" built end to end on themkeystone-virtual-fields-context/SKILL.md— 5 referencesopensaas-migration/SKILL.md— 10 referencesAn agent that loads one of these writes an import that does not resolve. The mechanism they reach for is native on the secured surface now:
.select()narrows the result type and composes inside.include()at every level, and reuse is an ordinary function returning a composed query value, which needs no bespoke type.Why this is filed rather than fixed
ADR-0041 names these skills explicitly and puts them out of scope for the Prisma 8 map, and §15 of the architecture spec rules the whole Keystone-migration story out of scope. The documentation site's own migration guides (
docs/content/how-to/migrate.md,migrate-from-keystone.md) were already corrected by #1174 and carry no reference to the deleted API — every "fragment" left in them names Keystone's own GraphQL fragments on the Keystone side of a mapping table, which is right.So #1175's "migration-guide references to the fragment API are removed" is satisfied for the guides. This is the remainder, surfaced rather than left implicit, per that ticket's third acceptance criterion.
What to do
Rewrite the three skills' read-migration recipes onto the composed read. Note that this touches
claude-plugins/, so it needs aplugin-versionbump inplugin.jsonand the matching.claude-plugin/marketplace.jsonentry, not a changeset.Worth deciding at the same time whether the
opensaas-migrationplugin is still supported at all, given §15. If it is not, deleting these recipes is cheaper than rewriting them.Context
🤖 Generated with Claude Code