All checks were successful
CI / Auth e2e pack (push) Successful in 4m37s
CI / Import/export fidelity gate (push) Successful in 43s
CI / Lint, typecheck, test (push) Successful in 2m54s
CI / Build container images (push) Has been skipped
CD / Build and push images (push) Successful in 3m14s
CD / Deploy to Test (push) Successful in 9s
CD / Smoke tests against Test (push) Successful in 1m8s
CD / Promote to Int (push) Successful in 9s
The read-only widget surface over page/pond data (ADR 0008 extension point `pageTool`): - Host: PageToolsPanel lists the pond's active pageTool surfaces behind disclosures — each sandbox iframe mounts lazily on first open and tears down on close. The same surfaces are insertable as plugin_block embeds (#76's insert picker now offers pageTool points too; the sandbox drives both through the same render lifecycle). - New `ui.scrollToHeading(headingId)` capability: outline ids are derived from the doc and never stamped into the DOM, so the host resolves the id to its heading position via the shared extractOutline and scrolls the matching rendered heading. - `readPond.listPages` now carries label *names* per summary (PagesService.pluginPageSummaries) — the page-index filter chips work on data the viewer could resolve anyway; per-page permission filtering stays in the service as before. - Reference plugins packages/plugins/toc and packages/plugins/page-index: real SDK consumers (createPlugin + windowTransport), bundled with esbuild into the package ZIP; i18n de/en is inlined at build time — the sandbox CSP forbids runtime fetches, the i18n/ files stay the single source. The toc re-fetches its outline on a slow poll, so live heading edits appear once the collab server has re-derived the content cache. - e2e page-tools.spec.ts covers the acceptance criteria: live outline updates after the persistence debounce, heading click scrolls, embedded page-index navigates via ui.openPage, and a label-restricted reader never sees the denied page in the index. - CI: the auth-e2e job now runs the section-styles (missed in #75), plugin-blocks, and page-tools packs, with login-rate-limit resets. - plugins.e2e.db.test clears the plugin registry up front: a local dev DB is shared with the e2e stack, whose installed real `toc` would otherwise collide with the fixture of the same id. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EwZ4jR4KFAPvpjWevfUGX1
60 lines
2.4 KiB
TypeScript
60 lines
2.4 KiB
TypeScript
/**
|
|
* Plugin API capabilities (ADR 0008, plugin-architecture.md §"Plugin API").
|
|
*
|
|
* A capability is a named group of host methods a plugin may call. The plugin
|
|
* declares the capabilities it needs in its manifest `permissions`; the host
|
|
* router rejects any call to a method whose capability was not declared. Every
|
|
* call is executed by the host against the REST API with the **viewing user's**
|
|
* session, so a plugin can never read more than the person looking at it could.
|
|
*/
|
|
|
|
/** The capability names a manifest may declare in `permissions`. */
|
|
export const CAPABILITIES = [
|
|
'readCurrentPage',
|
|
'readPond',
|
|
'readBlock',
|
|
'blockData',
|
|
'ui',
|
|
] as const;
|
|
|
|
export type Capability = (typeof CAPABILITIES)[number];
|
|
|
|
/**
|
|
* Which host methods each capability unlocks. This is the single source of
|
|
* truth mapping an RPC method name to the capability that must be declared for
|
|
* it; both the host router (permission filtering) and the plugin-side `host`
|
|
* proxy derive from it.
|
|
*/
|
|
export const CAPABILITY_METHODS = {
|
|
readCurrentPage: ['getOutline', 'getContent', 'getMeta'],
|
|
readPond: ['listPages', 'getPageOutline', 'getPageContent'],
|
|
readBlock: ['getBlock'],
|
|
blockData: ['getData', 'setData'],
|
|
ui: ['resize', 'openPage', 'toast', 'scrollToHeading'],
|
|
} as const satisfies Record<Capability, readonly string[]>;
|
|
|
|
/** Every host method name across all capabilities. */
|
|
export type HostMethod = (typeof CAPABILITY_METHODS)[Capability][number];
|
|
|
|
/** Reverse index: method name → the capability that must be declared for it. */
|
|
export const METHOD_CAPABILITY: Readonly<Record<string, Capability>> = Object.fromEntries(
|
|
CAPABILITIES.flatMap((capability) =>
|
|
CAPABILITY_METHODS[capability].map((method) => [method, capability] as const),
|
|
),
|
|
);
|
|
|
|
/** Returns the capability a host method belongs to, or `undefined` if the
|
|
* method is not part of the v1 API surface. */
|
|
export function capabilityForMethod(method: string): Capability | undefined {
|
|
return METHOD_CAPABILITY[method];
|
|
}
|
|
|
|
/**
|
|
* Lifecycle methods the **host** calls on the **plugin** (the reverse
|
|
* direction of the capability methods above). A code plugin implements the
|
|
* subset it needs; unimplemented methods are answered with an
|
|
* `unknown_method` error by the plugin endpoint.
|
|
*/
|
|
export const PLUGIN_LIFECYCLE_METHODS = ['render', 'edit', 'destroy'] as const;
|
|
export type PluginLifecycleMethod = (typeof PLUGIN_LIFECYCLE_METHODS)[number];
|