spec(leaf): app-leaf-provider-registration — sibling apps register render/data leaves into OpenRegister

[rubenvdlinde]

Proposal only — do NOT merge without human review

This is an OpenSpec change proposal (no PHP/JS implementation). It designs the umbrella "apps hook themselves into OpenRegister" system: a sanctioned server-side seam so any sibling Nextcloud app can register itself as a leaf — contributing render surfaces (tab/widget on an object) and data (notes/records backed by the app's own store) — cleanly and generically.

The gap it fills

• PHP: IntegrationProvider is already a rich full-CRUD data-provider contract, but every provider registers inside OpenRegister's own bootBuiltinIntegrationProviders(). There is no event/hook for a sibling app to contribute one, and the storage-strategy enum has no value for data living in another NC app's store. (ADR-041 records this exact limitation.)
• JS: the cross-app registerIntegration() + window.OCA.OpenRegister.integrations stub-queue already exists in @conduction/nextcloud-vue — but it is unspecified in OpenRegister and invisible to the server.

The design

• RegisterLeafProvidersEvent — a typed IEventDispatcher collect-event mirroring RegisterMcpToolProvidersEvent. Sibling apps write one listener; dispatched once, lazily; a throwing listener costs only its own leaf.
• LeafDescriptor — server declaration of availability + capability metadata (id, label, icon, requiredApp, surfaces, referenceType, requiresPermission, kinds). No Vue components; render stays on the JS layer under the same id.
• app-local storage strategy — data lives in the contributing app's own store; read + optional write served by the provider's own methods in the app's DI context. This is the generalisation of the built-in files/notes/calendar leaves and the concrete shape of "apps offering notes to OpenRegister."
• Discovery + parity — descriptors surfaced via OCS capabilities; ADR-019 tab+widget parity preserved and extended cross-app; ADR-013 first-wins on collision.

Layer decision

Both layers, correlated by a shared id: server owns discovery + data + capability declaration; JS (already built) owns render-component registration.

ADR alignment

Strictly render-and-read only — no command path. Cross-app commands remain ADR-041 typed events. This change deliberately lifts the ADR-041 moratorium ("do not extend the OR registry with cross-app contribution until decided") for the collect/render/read case — so it needs a companion org-wide ADR in hydra/openspec/architecture/ and human ratification before implementation. (Recommended in design.md; not authored here.)

Out of scope / cross-refs

Command invocation (ADR-041 events); the hermiq agent-leaf consumer (separate change — only the agent-runner kind name is reserved here); the manifest type: agent action (nextcloud-vue change); IReferenceProvider convergence (deferred to the companion ADR).

Contents

• proposal.md, design.md, tasks.md
• Spec deltas (3 capabilities): leaf-provider-registration, leaf-data-providers, leaf-discovery-parity
• openspec validate app-leaf-provider-registration --strict → valid

[github-actions]

Quality Report — ConductionNL/openregister @ 609fbcc

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
composer			❌	✅ 174/174
npm			✅	✅ 555/555
PHPUnit					⏭️
Newman					⏭️
Playwright					⏭️

---

Quality workflow — 2026-07-25 08:13 UTC

Download the full PDF report from the workflow artifacts.