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
Second half of #75 on top of the section node (2e96173/784f21d):
- Install gate for section_style CSS (plugin-css.ts): every rule must be
scoped under one of the plugin's own .dt-style-<pluginId>-<styleId>
classes (enforced, not rewritten — grouping at-rules checked inside,
@font-face/@keyframes exempt, statement at-rules rejected); positioning
out of the content flow (anything but static/relative) is rejected as an
overlay vector; "</style" is rejected as a breakout vector for inlined
embedding. Hostile fixtures from the acceptance list are pinned in
plugin-css.test.ts.
- Web: usePondPlugins loads the pond's active plugins once per visit;
SectionStyleSheets links each active style plugin's immutable
styles.css; SectionStyleMenu (toolbar) wraps/restyles/unwraps with a
picker fed from the plugins' i18n titles. Sections show a faint dashed
hint while editing so unstyled (plugin-disabled) sections stay findable.
- PDF export: PluginsService.sectionStyleCssForPond inlines the pond's
active section-style CSS into the Gotenberg HTML, so styled sections
survive the network-isolated render; covered in export.service.db.test.
- Reference plugin packages/plugins/section-styles-basic (callout, info,
warning, colored-box; theme-neutral semi-transparent backgrounds), a
workspace package whose tests validate it against the SDK schema and
whose real files run through the api install gate.
- e2e section-styles.spec.ts: install → wrap → computed background in edit
and read mode → unwrap → neutral fallback after disabling the plugin.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EwZ4jR4KFAPvpjWevfUGX1
pnpm workspace with apps/web, apps/api, apps/collab, and
packages/shared; strict TypeScript base config, repo-wide ESLint (flat)
+ Prettier, Vitest per package, and root scripts lint/typecheck/test/
build. @dorfteich/shared ships a first health-response helper consumed
by apps/api to prove workspace linking. Existing markdown docs are
reformatted once by the new Prettier setup.
Closes#1
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Initial deliverable of the architecture phase: 16 ADRs (stack, CRDT
collaboration, plugin sandbox, import/export, backups, CI/CD), data
model, permission model, real-time collaboration and plugin concepts,
deployment/operations/security documentation, and the milestone roadmap
that the implementation issues are derived from.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
