Regeneration-Prompt: |
Chutes CI was still failing before test discovery with a Node module-loader error
tied to importing the extension entry module. Replace that test with extension-local
onboarding coverage that still exercises real Chutes code but avoids the plugin
entrypoint entirely. Keep the lane meaningful by checking provider catalog setup,
alias registration, and default model wiring in onboard.ts.
Regeneration-Prompt: |
Fix the chutes extension-fast test after CI hit a Node module-loader error while
importing the real Chutes auth runtime. Keep the test focused on provider
registration shape, and avoid pulling in the OAuth command stack that the test
does not exercise. Mock the provider-auth and local onboarding/catalog seams,
then import the plugin lazily inside the test so the extension harness only
validates the registration contract.
Regeneration-Prompt: |
Follow up on PR #49244 after Greptile feedback and failing CI runs. Keep the
provider contract registry behavior intact, but add a note that the static
bundled loader map must stay aligned with the manifest registry. Preserve the
simplified Discord inbound contract seam because handler-path coverage already
lives in the Discord extension tests.
Fix the concrete failing checks only: format the docs page, add a minimal
chutes extension test so extension-fast has coverage, raise the fast-xml-parser
override to the patched production version and refresh the lockfile, remove
stale configSchema/groups arguments from built-in channel plugin factory call
sites so current TypeScript gates pass, and address any surfaced lint failures
with the smallest rule-compliant edits.
Add capability plan alignment section with key decisions and required test
matrix. Rename seams to capabilities for consistency.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add the public capability model section documenting the six capability types,
plugin shape classification, capability labels, legacy hook guidance, export
boundary rules, and the new plugins inspect command.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix(telegram): persist sticky IPv4 fallback across polling restarts (fixes#48177)
Hoist resolveTelegramTransport() out of createTelegramBot() so the
transport (and its sticky IPv4 fallback state) persists across polling
restarts. Previously, each polling restart created a new transport with
stickyIpv4FallbackEnabled=false, causing repeated IPv6 timeouts on
hosts with unstable IPv6 connectivity.
Changes:
- bot.ts: accept optional telegramTransport in TelegramBotOptions
- monitor.ts: resolve transport once before polling loop
- polling-session.ts: pass transport through to bot creation
AI-assisted (Claude Sonnet 4). Tested: tsc --noEmit clean.
* Update extensions/telegram/src/polling-session.ts
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
* style: fix oxfmt formatting in bot.ts
* test: cover telegram transport reuse across restarts
* fix: preserve telegram sticky IPv4 fallback across polling restarts (#48282) (thanks @yassinebkr)
---------
Co-authored-by: Yassine <yassinebkr@users.noreply.github.com>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
