Problem
Features that land in src/core/ + src/providers/*/adapter.ts do not automatically reach the plugin build. The plugin entrypoint (src/plugin/, 7 files) is a separate code path that imports its own subset of core.
Concretely: the GitHub-style callout embeds from #62 are not in the packaged plugin. Grepping the packed entry.js for callout returns zero hits, despite the feature being merged to rc and the standalone suite being green (540/540).
How this was found
While building and signing the plugin from rc (npm run build:plugin && npm run pack:plugin) right after merging #62, to smoke-test the RC as a Maestro plugin. The build succeeds and is sandbox-safe — nothing fails. The feature is simply absent, silently.
$ grep -rl "callout" src/plugin/
(no matches)
$ grep -rl "callout" src/ --include="*.ts" | grep -v __tests__
src/core/callouts.ts
src/core/api.ts
src/core/queue.ts
src/core/types.ts
src/providers/discord/adapter.ts
src/providers/slack/adapter.ts
Why it matters
The failure mode is silent. There is no build warning, no failing test, no signal at package time that a merged feature isn't in the artifact. Anyone testing the plugin build would reasonably expect parity with the standalone bridge and find the feature missing with no explanation.
Callouts are the instance that surfaced this, but the underlying question is broader: which core features is the plugin path expected to carry, and how would we notice when one is missing?
Possible directions
- Decide and document the intended scope: is the plugin meant to be at parity with standalone, or a deliberate subset?
- If parity: have
src/plugin/entry.ts consume the shared core rendering path instead of reimplementing the outgoing-message pipeline.
- If subset: document the gap, and consider a build-time check or test asserting which core features are expected in the bundle, so drift becomes visible rather than silent.
Filed while smoke-testing the rc plugin build (sh.maestro.relay-0.5.0-rc.2, built from 5799f25).
Problem
Features that land in
src/core/+src/providers/*/adapter.tsdo not automatically reach the plugin build. The plugin entrypoint (src/plugin/, 7 files) is a separate code path that imports its own subset of core.Concretely: the GitHub-style callout embeds from #62 are not in the packaged plugin. Grepping the packed
entry.jsforcalloutreturns zero hits, despite the feature being merged torcand the standalone suite being green (540/540).How this was found
While building and signing the plugin from
rc(npm run build:plugin && npm run pack:plugin) right after merging #62, to smoke-test the RC as a Maestro plugin. The build succeeds and is sandbox-safe — nothing fails. The feature is simply absent, silently.Why it matters
The failure mode is silent. There is no build warning, no failing test, no signal at package time that a merged feature isn't in the artifact. Anyone testing the plugin build would reasonably expect parity with the standalone bridge and find the feature missing with no explanation.
Callouts are the instance that surfaced this, but the underlying question is broader: which core features is the plugin path expected to carry, and how would we notice when one is missing?
Possible directions
src/plugin/entry.tsconsume the shared core rendering path instead of reimplementing the outgoing-message pipeline.Filed while smoke-testing the
rcplugin build (sh.maestro.relay-0.5.0-rc.2, built from5799f25).