You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(adapters,plugins,edge): a restarted server serves its cached bundle in place of an older or refused pull, and doesn't write it back - #1137
The saas source keeps a last-good bundle cache: a file in bundleCacheDir on Node, KV on a Worker. Three gaps showed when a server or isolate starts with nothing served yet:
An offline start rewrote the cache. When the first pull failed, the source served the cached bundle, and the plugin then kept that same bundle again. That was a needless file or KV write. On KV it also renews an expirationTtl, so a fallback the bundle server never confirmed stayed alive across restarts.
A cold start applied an older pulled bundle. The forward-only gate (fix(adapters,plugins,edge): an older saas bundle, pulled or pushed, doesn't roll the server back #1119) compares a bundle with the one served, and a start has none. So an endpoint that served an older bundle than the cached last-good one, such as a stale CDN or a rolled-back origin, took a restarted server back, and the older bundle replaced the cache.
A cold start served nothing when its pulled bundle was refused. A bad signature, or a bundle that failed part-way, left the isolate with no bundle, although the cache held a good one. Only a pull that failed fell back to the cache.
The cached bundle stands in for the served one. While no bundle serves, the sync service reads the source's cached bundle and uses it in place of the served bundle the gate has yet to compare with:
The source has a new optional keptBundle(), the read side of keepBundle(). SaasPullSource reads the file or the injected cache, through the same schema check as before.
A forward-only source's pulled bundle older than the cached one (compareBundleVersions) is not applied. The cached bundle serves instead. With allowRollback: true the pulled bundle serves, as before.
A pulled bundle that is not applied leaves the cached bundle serving, as a failed pull does. This holds with allowRollback too.
If the cached bundle is refused too, for example its signature no longer checks out, the pulled bundle is applied when it passes. Otherwise nothing serves, as before.
A pulled bundle that is newer than the cached one, or the same, is applied once and kept, as before.
A push that arrives while nothing serves gets the same comparison. An older one answers 409 bundle_outdated.
The cache is read only while nothing serves. Once a bundle serves, the gate compares with it, as before.
The cached bundle is never written back. A bundle the source hands over with origin.pullFailure (the cached one, served because the pull failed) is not kept again, and neither is the cached bundle served in place of an older or refused pull.
The load state says why. When the cached bundle serves in place of the pulled one, lastSync is refused, with the pulled bundle's id and version, the reason, and cacheFallback: true. For an older pull the reason is older than the cached bundle <id>@<version> (generatedAt <date>). /readyz shows the skilled-openapi check as degraded (still ready), with the cached bundle as the one served. The log says [bundle-sync] bundle <pulled> not applied: <reason>; serving the cached bundle <cached>. On a Worker the Cron run fails with bundle <id>@<version> was not applied, so the cached bundle serves: <reason>.
The change sits in the source and the sync service's apply path before apply(). apply() is unchanged. The content-digest skip from #1136 doesn't come into play, since a cold start has no served bundle. An identical cached and pulled bundle is applied once, from the pull, and reported applied.
Scenarios covered:
B2: the saas source's cache, on Node and on a Worker.
B3: a bundle that is not applied leaves the last good one serving, now on a cold start too.
B4: the failure shows in /readyz and in the Cron run.
B6 and J2: a managed Cloudflare Worker's new isolate.
User-facing change
What changed:
A server or isolate that starts, with a saas source, serves its cached bundle in place of a pulled bundle that is older than it (unless allowRollback) or that is refused.
Serving the cached bundle no longer writes it back to the cache file or KV.
BundleSyncOutcome's refused status has an optional cacheFallback: true, set when the cached bundle serves in place of the refused one. /readyz shows it in lastSync.
A Cron run's error says was not applied, so the cached bundle serves: ... in that case.
@frontmcp/adapters/skills: SkillBundleSource has an optional keptBundle(), which SaasPullSource implements.
Before → after:
A server restarted against an endpoint that serves acme:billing@1.4.0, with 1.5.0 cached: served 1.4.0 and cached it → serves 1.5.0 and keeps it cached. /readyz shows lastSync: { status: 'refused', bundleVersion: '1.4.0', reason: 'older than the cached bundle acme:billing@1.5.0 (...)', cacheFallback: true }.
A restart whose pulled bundle fails its signature: /readyz 503 and SKILL_BUNDLE_NOT_LOADED from every tool → the cached bundle serves, /readyz is ready with the check degraded.
A start during an outage: served the cached bundle and wrote it back → serves it and writes nothing.
The plugin's and the edge's READMEs are updated too.
Tests
Added:
@frontmcp/adapters:
saas-pull.source.spec.ts: keptBundle() reads back the kept bundle without pulling, and nothing when none is kept or the file fails the schema check.
saas-pull.source.edge.spec.ts: it reads the injected cache through the schema check; an offline start reads the cache and writes nothing.
Plugin, bundle-sync.service.spec.ts:
the cached bundle serving in place of an older pull, kept by neither, with the outcome and the log line;
a newer pull, and one identical to the cache, applied once and kept;
allowRollback serving an older pull;
a refused pull (forward-only or not) falling back to the cache;
a refused cached bundle letting an older pull serve;
both refused, so nothing serves;
an older push while nothing serves answered outdated;
the cache read only while nothing serves;
a cache that can't be read;
the outage start not keeping the cached bundle again.
Plugin, last-good-bundle.integration.spec.ts (a real server): a restart during an outage writes nothing to the cache; a Cron refresh that starts it against an older bundle serves the cached one and resolves refused with cacheFallback; a restart whose pull fails its signature serves the cached one.
Edge:
index-wiring.spec.ts: the Cron run's error for a refused pull with the cache serving.
index.spec.ts (a real scope): an isolate started against an older bundle fails its run, serves the cached one, and /readyz says why; no isolate start writes the cache.
demo-e2e-skilled-openapi, saas on Node:
a restart during an outage leaves the cache file unmodified;
a server restarted against an endpoint that serves an older version keeps serving the cached newer one;
a restart whose pulled version was changed after signing serves the cached one;
in both, /readyz says why.
demo-e2e-cloudflare, managed Worker in workerd:
a third replica, so a test gets one more fresh isolate;
a new isolate whose first Cron run pulls an older bundle fails the run, serves the KV bundle, and /readyz names the refusal;
an outage start leaves the KV entry byte for byte as it was.
npx nx test demo-e2e-skilled-openapi: 11 suites, 97 tests, passed.
npx nx test demo-e2e-cloudflare: 3 suites, 32 tests, passed.
npx nx run <project>:typecheck for adapters, plugin-skilled-openapi, edge and demo-e2e-skilled-openapi, and npx tsc --noEmit -p <lib>/tsconfig.lib.json for adapters, plugin-skilled-openapi and edge: no errors.
Prettier and ESLint on the changed files: clean.
The SDK is unchanged, so the bundle-size e2e doesn't apply.
Summary by CodeRabbit
New Features
On startup, the last-good cached bundle is served if a pull fails, is refused, or is older than the cache. When rollback is allowed, an older pulled bundle can be served.
Serving a cached bundle no longer rewrites the cache. Invalid cached bundles are not used.
Readiness reports a degraded state when a bundle is serving but its latest sync failed or was refused; the endpoint continues to return HTTP 200.
Bug Fixes
Scheduled refresh failures now distinguish when the isolate is serving the cached bundle.
Documentation
Updated deployment, caching, and readiness guidance to reflect these behaviors.
… an older or refused pull, and doesn't write it back
A start has no served bundle, so the forward-only version gate had nothing to
compare a pulled bundle with: an endpoint serving an older bundle than the
cached last good one (a stale CDN, a rolled-back origin) took the server back,
and a pulled bundle refused for its signature left the isolate serving nothing,
although the cache held a good one. A start that served the cached bundle after
a failed pull also wrote that bundle back to the cache, a needless file or KV
write that renewed a KV expirationTtl.
While no bundle serves, the sync service now reads the source's cached bundle
(the new optional SkillBundleSource.keptBundle(), which SaasPullSource reads
from its file or injected cache) and lets it stand in for the served one:
- a forward-only source's pulled bundle older than the cached one is not
applied, and the cached bundle serves, unless allowRollback;
- a pulled bundle that is not applied leaves the cached bundle serving;
- a cached bundle that is refused too lets the pulled one serve when it passes.
The cached bundle served is never kept again. lastSync says the pull was
refused, with the reason and cacheFallback: true, so /readyz shows why, and a
Worker's Cron run fails with "was not applied, so the cached bundle serves".
No actionable comments were generated in the recent review.
Walkthrough
Cold-start synchronization can compare a pulled bundle with the cached bundle and serve the cache when the pull is older or refused. Cached fallback does not rewrite the cache. Refused sync outcomes and readiness checks report when the cache serves.
Changes: Cold-Start Bundle Cache Fallback
Layer / File(s)
Summary
Expose the retained bundle libs/adapters/src/skills/sources/saas-pull.source.ts, libs/adapters/src/skills/sources/skill-bundle-source.interface.ts, libs/adapters/src/skills/__tests__/*
SaaS sources expose keptBundle() to read a cached bundle. Tests cover absent, valid, and schema-invalid cache entries, and verify that reading the cache does not make HTTP requests or write the cache.
Select and apply the cold-start bundle plugins/plugin-skilled-openapi/src/sync/*, plugins/plugin-skilled-openapi/src/__tests__/bundle-sync.service.spec.ts, plugins/plugin-skilled-openapi/README.md
Cold-start sync compares pulls with the cache, serves the cache for eligible older or unapplied pulls, and avoids keeping a cached fallback again. Tests cover forward-only and rollback-capable sources, apply failures, and cache-read failures. The README describes startup fallback and cache-write behavior.
Report cache fallback in refresh outcomes libs/edge/src/*, libs/edge/README.md, libs/skills/catalog/*
Refused outcomes can include cacheFallback. Edge refresh errors and documentation describe cached fallback, Cron failures, readiness details, and token-check details.
Verify restart and cache preservation apps/e2e/demo-e2e-cloudflare/e2e/*, apps/e2e/demo-e2e-skilled-openapi/e2e/*, plugins/plugin-skilled-openapi/src/__tests__/last-good-bundle.integration.spec.ts
Restart and integration tests cover older, refused, and failed pulls. They check the served version, readiness state, and that serving cached content does not update the cache. The Cloudflare Worker fixture adds a third replica and raw KV entry accessors.
sequenceDiagram
participant SkillBundleSource
participant BundleSyncService
participant BundleLoadState
SkillBundleSource->>BundleSyncService: Offer pulled bundle
BundleSyncService->>SkillBundleSource: Read keptBundle()
SkillBundleSource-->>BundleSyncService: Return cached bundle or undefined
BundleSyncService->>BundleSyncService: Apply offered bundle or cached fallback
BundleSyncService->>BundleLoadState: Record refused outcome with cacheFallback
Loading
Possibly related PRs
agentfront/frontmcp#1094: Introduced the managed Worker fixture and KV cache path extended by this change.
agentfront/frontmcp#1128: Defines sync outcomes and readiness behavior extended here with cache-fallback reporting.
agentfront/frontmcp#1100: Established applied-bundle retention and scheduler behavior extended here for cold-start cache comparison.
Suggested reviewers:alexmercerpo
Merge Risk: Minimal · up to aaf30
No actionable issue remains identified for this change; it is mergeable after normal checks.
Pre-merge checks: 5
Check name
Status
Explanation
Title check
The title names the main change: a restarted server serves its cached bundle instead of an older or refused pull, and does not write it back. The changeset adds keptBundle() and cold-start fallback lo…
Description check
The description follows the template. It has the 'What and why' section with the problem, the change, and the issue context. It has a 'User-facing change' section that lists what changed, before and a…
Docstring Coverage
Docstring coverage is 66.67% which is sufficient. The required threshold is 65.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentati…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Title check
Explanation
The title names the main change: a restarted server serves its cached bundle instead of an older or refused pull, and does not write it back. The changeset adds keptBundle() and cold-start fallback logic in the sync service, the saas source, and the edge managed mode, which matches. The title is long (135 characters, 21 words), but it is specific and on topic.
Full details: Description check
Explanation
The description follows the template. It has the 'What and why' section with the problem, the change, and the issue context. It has a 'User-facing change' section that lists what changed, before and after behavior, the frontmcp.dev pages affected, and the skills catalog entries updated. It has a 'Tests' section that lists added tests, the commands run, and the typecheck and lint results. It does not link a closed issue, but the template only asks for one if it exists.
Full details: Docstring Coverage
Explanation
Docstring coverage is 66.67% which is sufficient. The required threshold is 65.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 3 functions across 14 files. (4 skipped: 4 unsupported.)
Finishing Touches
Generate docstrings
Commit to this branch
Create a new PR
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 5 included reviews per hour; 0 remain after this review.
Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.
Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.
* Cherry-pick: fix(adapters,plugins,edge): an older saas bundle, pulled or pushed, doesn't roll the server back
Cherry-picked from #1119 (merged to release/1.11.x)
Original commit: d88f422
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,plugins): an @app's Skilled OpenAPI credential resolver reaches execute_action and this.callTool() of an operation
Cherry-picked from #1120 (merged to release/1.11.x)
Original commit: 00a3b00
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(adapters,plugins,edge): a push token replayed to another replica or Worker isolate is refused
Cherry-picked from #1122 (merged to release/1.11.x)
Original commit: 1341026
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(plugins): a skill a skills:filter hook hides can't be run by naming its actions
Cherry-picked from #1123 (merged to release/1.11.x)
Original commit: a081fbf
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk): a plugin listed twice in one plugins list is refused at startup instead of keeping only its last entry
Cherry-picked from #1127 (merged to release/1.11.x)
Original commit: 3dbadd3
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(plugins,edge): a Cron run that doesn't apply its bundle fails, and /readyz says the bundle served is stale
Cherry-picked from #1128 (merged to release/1.11.x)
Original commit: 4938d21
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk): connect() with an authToken connects an anonymous caller again on a server without auth
Cherry-picked from #1129 (merged to release/1.11.x)
Original commit: 3d238da
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(auth,adapters,plugins,edge): operators can tell why a pull or push token was refused, while callers still get the generic answer
Cherry-picked from #1130 (merged to release/1.11.x)
Original commit: 913f4f5
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,auth,plugins): this.authProviders works: the SDK wires the AuthProviders vault from a new authProvidersVault option
Cherry-picked from #1131 (merged to release/1.11.x)
Original commit: e14c30c
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,auth): /oauth/connect connects a verified caller who has no vault yet, and asks an anonymous one to sign in
Cherry-picked from #1132 (merged to release/1.11.x)
Original commit: f46a87a
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,plugins): the SDK skill surfaces say a plugin's skills haven't loaded yet, retryable, and carry bundleVersion
Cherry-picked from #1133 (merged to release/1.11.x)
Original commit: 0d1dc94
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,auth,cli,plugins): the credentials-required error keeps its connect link out of the message, and asks through URL elicitation where the client supports it
Cherry-picked from #1134 (merged to release/1.11.x)
Original commit: 6d8ea24
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk): a health check registered after startup runs in /readyz, and registerHealthProbe returns a remover
Cherry-picked from #1135 (merged to release/1.11.x)
Original commit: 7f2f48f
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,plugins): a bundle swap sends one list_changed per list it changed, not one per entry
Cherry-picked from #1136 (merged to release/1.11.x)
Original commit: 0296291
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(adapters,plugins,edge): a restarted server serves its cached bundle in place of an older or refused pull, and doesn't write it back
Cherry-picked from #1137 (merged to release/1.11.x)
Original commit: 358d114
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,adapters,plugins,edge): a push token with a body_sha256 claim can't carry another bundle
Cherry-picked from #1138 (merged to release/1.11.x)
Original commit: b870325
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(plugins,edge): managed mode takes confirm, and the audit log says whether the user confirmed a call
Cherry-picked from #1139 (merged to release/1.11.x)
Original commit: 588289f
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(cli): the generated CLI says unknown command, prints an MCP error prefix once, and offers load_skill only the run lines it has
Cherry-picked from #1140 (merged to release/1.11.x)
Original commit: 4cfe9a2
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(plugins): load_skill's outputSchema describes a loaded skill once
Cherry-picked from #1141 (merged to release/1.11.x)
Original commit: 470010e
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
* Cherry-pick: fix(sdk,cli): skills/load's default answer sends formattedContent again, as 1.11.0 did; format: 'markdown' is the opt-in for the smaller one
Cherry-picked from #1142 (merged to release/1.11.x)
Original commit: a680fe7
Co-Authored-By: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
---------
Co-authored-by: agentfront[bot] <agentfront[bot]@users.noreply.github.com>
Co-authored-by: frontegg-david <69419539+frontegg-david@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![agentfront[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
Stacks on #1136.
What and why
The
saassource keeps a last-good bundle cache: a file inbundleCacheDiron Node, KV on a Worker. Three gaps showed when a server or isolate starts with nothing served yet:expirationTtl, so a fallback the bundle server never confirmed stayed alive across restarts.The cached bundle stands in for the served one. While no bundle serves, the sync service reads the source's cached bundle and uses it in place of the served bundle the gate has yet to compare with:
keptBundle(), the read side ofkeepBundle().SaasPullSourcereads the file or the injected cache, through the same schema check as before.compareBundleVersions) is not applied. The cached bundle serves instead. WithallowRollback: truethe pulled bundle serves, as before.allowRollbacktoo.409 bundle_outdated.The cached bundle is never written back. A bundle the source hands over with
origin.pullFailure(the cached one, served because the pull failed) is not kept again, and neither is the cached bundle served in place of an older or refused pull.The load state says why. When the cached bundle serves in place of the pulled one,
lastSyncisrefused, with the pulled bundle's id and version, the reason, andcacheFallback: true. For an older pull the reason isolder than the cached bundle <id>@<version> (generatedAt <date>)./readyzshows theskilled-openapicheck asdegraded(still ready), with the cached bundle as the one served. The log says[bundle-sync] bundle <pulled> not applied: <reason>; serving the cached bundle <cached>. On a Worker the Cron run fails withbundle <id>@<version> was not applied, so the cached bundle serves: <reason>.The change sits in the source and the sync service's apply path before
apply().apply()is unchanged. The content-digest skip from #1136 doesn't come into play, since a cold start has no served bundle. An identical cached and pulled bundle is applied once, from the pull, and reportedapplied.Scenarios covered:
saassource's cache, on Node and on a Worker./readyzand in the Cron run.User-facing change
saassource, serves its cached bundle in place of a pulled bundle that is older than it (unlessallowRollback) or that is refused.BundleSyncOutcome'srefusedstatus has an optionalcacheFallback: true, set when the cached bundle serves in place of the refused one./readyzshows it inlastSync.was not applied, so the cached bundle serves: ...in that case.@frontmcp/adapters/skills:SkillBundleSourcehas an optionalkeptBundle(), whichSaasPullSourceimplements.acme:billing@1.4.0, with1.5.0cached: served1.4.0and cached it → serves1.5.0and keeps it cached./readyzshowslastSync: { status: 'refused', bundleVersion: '1.4.0', reason: 'older than the cached bundle acme:billing@1.5.0 (...)', cacheFallback: true }./readyz503 andSKILL_BUNDLE_NOT_LOADEDfrom every tool → the cached bundle serves,/readyzis ready with the checkdegraded./readyz)frontmcp-deployment/references/deploy-to-cloudflare-skills-only.mdfrontmcp-production-readiness/references/health-readiness-endpoints.mdThe plugin's and the edge's READMEs are updated too.
Tests
Added:
@frontmcp/adapters:saas-pull.source.spec.ts:keptBundle()reads back the kept bundle without pulling, and nothing when none is kept or the file fails the schema check.saas-pull.source.edge.spec.ts: it reads the injected cache through the schema check; an offline start reads the cache and writes nothing.bundle-sync.service.spec.ts:allowRollbackserving an older pull;outdated;last-good-bundle.integration.spec.ts(a real server): a restart during an outage writes nothing to the cache; a Cron refresh that starts it against an older bundle serves the cached one and resolvesrefusedwithcacheFallback; a restart whose pull fails its signature serves the cached one.index-wiring.spec.ts: the Cron run's error for a refused pull with the cache serving.index.spec.ts(a real scope): an isolate started against an older bundle fails its run, serves the cached one, and/readyzsays why; no isolate start writes the cache.demo-e2e-skilled-openapi, saas on Node:/readyzsays why.demo-e2e-cloudflare, managed Worker in workerd:/readyznames the refusal;Run:
npx nx run-many -t build -p sdk,adapters,plugin-skilled-openapi,edge,testing: passed.@frontmcp/adapters: 63 suites, 1128 tests, passed.@frontmcp/plugin-skilled-openapi: 53 suites, 822 tests, passed.@frontmcp/edge: 10 suites, 110 tests, passed.@frontmcp/skills: 3 suites, 249 tests, passed.npx nx test demo-e2e-skilled-openapi: 11 suites, 97 tests, passed.npx nx test demo-e2e-cloudflare: 3 suites, 32 tests, passed.npx nx run <project>:typecheckfor adapters, plugin-skilled-openapi, edge and demo-e2e-skilled-openapi, andnpx tsc --noEmit -p <lib>/tsconfig.lib.jsonfor adapters, plugin-skilled-openapi and edge: no errors.The SDK is unchanged, so the bundle-size e2e doesn't apply.
Summary by CodeRabbit