The PaperBell contract is currently one-way: we consume, and there is no publish path. PPBRequestSource has no field through which a sub-plugin exposes its own API, so Project Manager has no way to ask "what deliverables does this project have, and how far along is each one?" short of reaching into app.plugins.plugins["longform-paperbell"].api directly.
Today it can only scan frontmatter for the project: key #25 added. That works, but it is a snapshot: it cannot see compile status, and it re-scans the vault to learn anything.
This is roadmap Direction 2 in docs/PAPERBELL_SUITE.md and §6 of docs/PROPOSAL_PROJECTS_SCOPE.md.
Blocked on a host decision
Two ways to close the loop — either is fine, but the host has to pick one:
- Registry —
registerPPBplugin accepts an api field, and the host hands a sibling's API to another sub-plugin on request. Generic; solves this for every pair of plugins at once.
- Bus — the host exposes
emit(event, payload) and we broadcast paperout:deliverable-changed on scaffold and on compile completion. Simpler, push-based, no query surface to design.
Our side, once decided
src/api/LongformAPI.ts — today a private, Longform-legacy helper (scene numbering only), not registered with PaperBell. It is the natural home for an enumerate-projects/drafts/compile-status read API.src/main.ts (onload) — registration.src/compile/steps/harvest-manuscript-lines.ts — the emit point once sidecars are written.docs/MANUSCRIPT_REFS.md documents the sidecar shapes; promoting them to a stated cross-plugin contract is part of this.
Related
Also on the list: subscribe to paperbell:plugins-changed. The event constant is vendored but never subscribed — wiring it like the existing onConfigChange would refresh capabilities as siblings load and unload. Small, independent, and could ship first.
The PaperBell contract is currently one-way: we consume, and there is no publish path.
PPBRequestSourcehas no field through which a sub-plugin exposes its own API, so Project Manager has no way to ask "what deliverables does this project have, and how far along is each one?" short of reaching intoapp.plugins.plugins["longform-paperbell"].apidirectly.Today it can only scan frontmatter for the
project:key #25 added. That works, but it is a snapshot: it cannot see compile status, and it re-scans the vault to learn anything.This is roadmap Direction 2 in
docs/PAPERBELL_SUITE.mdand §6 ofdocs/PROPOSAL_PROJECTS_SCOPE.md.Blocked on a host decision
Two ways to close the loop — either is fine, but the host has to pick one:
registerPPBpluginaccepts anapifield, and the host hands a sibling's API to another sub-plugin on request. Generic; solves this for every pair of plugins at once.emit(event, payload)and we broadcastpaperout:deliverable-changedon scaffold and on compile completion. Simpler, push-based, no query surface to design.Our side, once decided
src/api/LongformAPI.ts— today a private, Longform-legacy helper (scene numbering only), not registered with PaperBell. It is the natural home for an enumerate-projects/drafts/compile-status read API.src/main.ts(onload) — registration.src/compile/steps/harvest-manuscript-lines.ts— the emit point once sidecars are written.docs/MANUSCRIPT_REFS.mddocuments the sidecar shapes; promoting them to a stated cross-plugin contract is part of this.Related
Also on the list: subscribe to
paperbell:plugins-changed. The event constant is vendored but never subscribed — wiring it like the existingonConfigChangewould refresh capabilities as siblings load and unload. Small, independent, and could ship first.