docs(config): federated configuration sharing — one fleet standard (design)#2132
Closed
rubenvdlinde wants to merge 1 commit into
Closed
docs(config): federated configuration sharing — one fleet standard (design)#2132rubenvdlinde wants to merge 1 commit into
rubenvdlinde wants to merge 1 commit into
Conversation
…esign) Design-only OpenSpec change (no code). One OpenRegister-owned way for any app to publish/discover/install its configuration over GitHub — flows, registers & schemas, OpenBuild apps, procest case types, payroll packs, agents & skills, NL Design themes. Grounded in a fleet scan: OpenRegister's ConfigurationService is already a generic multi-entity, GitHub-bidirectional bundle; OpenBuild already ships the object->GitHub sync (broker-routed tokens, topic discovery, git-data-API push) and hermiq copied it. 10/11 apps store shareable config as OR objects. So this unifies + generalises + democratises what exists rather than building anew — and needs no openconnector dependency. Decisions captured (from review): - Engine = a FederatedConfigService in OpenRegister + an IShareableConfigType registration event (same idiom as flow nodes); storage-agnostic so app-specific storage works too (NL Design themes wrap ConfigBundleService, no OR-object migration). - GitHub credentials custodied in Doriath (the credential broker's vault leaf, encrypted/audited/rotatable) per user/org — no shared app token; NC-vault fallback where Doriath is absent. - Trust v1 = org source allowlist + version pinning + secret exclusion; signing deferred. Sharing is user/org-scoped, not admin-only. - #2065's flow "integration network" becomes one flow-shaped consumer of this. Contains proposal, spec (5 requirements + scenarios), tasks (6 phases with the per-app adoption plan). Left open for review before any implementation.
Contributor
Quality Report — ConductionNL/openregister @
|
| 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-26 07:39 UTC
Download the full PDF report from the workflow artifacts.
Contributor
Author
rubenvdlinde
added a commit
that referenced
this pull request
Jul 26, 2026
…y + Flows (+ e2e) (#2134) Builds the foundation of the fleet-wide federated-config standard (design in the carried openspec change; supersedes the design-only #2132). One OpenRegister- owned way for any app to share configuration over GitHub; Flows is the first consumer (the reframed #2065). - IShareableConfigType + RegisterShareableConfigTypesEvent + registry — the contribution seam, same idiom as flow nodes. Storage-agnostic: a type owns (de)serialisation, so app-specific storage (e.g. NL Design themes in IConfig) works too, not only OR objects. - FederatedConfigService — the engine: types(), bundle() (serialise a selection), install() (deserialise, gated by the org source allowlist), publish() (push to GitHub with the token supplied by the credential broker — Doriath's vault where installed, NC vault otherwise; the token never enters the service). Trust v1 = org allowlist (empty = not-yet-enforced) + version pinning + secret exclusion. - FlowShareableConfigType — flows as a type: serialise to a portable shape (no id/uuid/owner/organisation), install back into the flow store. - FederatedConfigController + routes (/api/federated-config/types|bundle|install), all #[NoCSRFRequired] so API/MCP clients can call them. Tests: 13 unit (registry event-once, service allowlist enforcement + prefix match, Flow type round-trip strips instance fields). Playwright e2e tests/e2e/api-direct/federated-config.spec.ts (4): types include Flows; a flow bundles → installs as a fresh flow → the installed flow RUNS to completion; unknown type = 404; the org allowlist refuses a non-allowlisted source (403) and allows an allowlisted one. phpcs clean. Live-verified on 8080: full round-trip (bundle a flow → install a fresh one → run it → {shared:true}). Follow-ups (per the design's phases 4-6): fold hermiq's duplicated GitHub sync onto this; roll out declared types per app (procest case types, shillinq payroll packs, opencatalogi publication types, docudesk, softwarecatalog, pipelinq, larpingapp, NL Design themes); the publish/discover UI; per-org RBAC beyond admin; signing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Design-only OpenSpec change (no code) — for review before implementation, like the per-item-routing design.
One OpenRegister-owned standard for any app to publish / discover / install its configuration over GitHub — flows, registers & schemas, OpenBuild apps, procest case types, payroll packs, agents & skills, NL Design themes. Full write-up + fleet inventory + architecture: the design artifact shared with the team.
Why this shape (from a fleet scan)
ConfigurationServiceis already a generic multi-entity, GitHub-bidirectional bundle (publish + install, version tracking, preview-diff).Decisions captured (from review)
FederatedConfigServicein OpenRegister + anIShareableConfigTyperegistration event (same idiom as flow nodes). Storage-agnostic — app-specific storage works too, so NL Design themes wrapConfigBundleServicewith no migration onto OR objects.Contents
proposal.md(problem, solution, consumer table, out-of-scope) ·spec.md(5 requirements + scenarios) ·tasks.md(6 phases with per-app adoption).Left open for review — no code until the design is agreed.
🤖 Generated with Claude Code