CUST-WP-0058: business platform enablement — DR set + workplan

Decision records DR-1 (tenancy), DR-2 (coulomb.social shape), DR-3
(external identity) framing the Binky Hedgehog commercial lane on the
coulomb/HelixForge platform; coordination workplan for service contract,
client-hub scoping, fin-hub billing gap, and delivery-lane pilot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/business-platform-decision-records.md

@@ -0,0 +1,140 @@
+# Business Platform Decision Records
+
+**Created:** 2026-07-10
+**Workplan:** `CUST-WP-0058`
+**Status:** All three decisions **pending** — Bernd's to resolve; this document
+frames options and recommendations only.
+
+## Context
+
+Binky Hedgehog GmbH intends to build commercial business applications on the
+coulomb/HelixForge platform (Forgejo → railiance-forge → railiance-apps →
+Core Hub ecosystem):
+
+1. **vergabe-teilnahme** — tender-participation web app as the first
+   commercial offering for business clients.
+2. **coulomb.social rebuild** — replace the current bubble.io implementation
+   as the second business project.
+
+The hub-ecosystem review (2026-07-09, see `hub-ecosystem-architecture.md`)
+concluded the architecture is sound but three decisions gate the business
+lane. Each is recorded here with options and a recommendation; resolution
+happens via State Hub decision records (`resolve_decision`).
+
+---
+
+## DR-1 — Tenancy model for vergabe-teilnahme
+
+**Status:** pending
+
+### Question
+
+How are business clients isolated: one deployed instance per client, or one
+multi-tenant instance?
+
+### Options
+
+| Option | Description | Consequences |
+| --- | --- | --- |
+| **A. Instance-per-client** | Each client gets a dedicated deployment (own DB, own release values in `railiance-apps`) | Strong isolation; simpler compliance story; per-client backup/restore; matches vergabe-teilnahme SCOPE ("no multi-tenancy"); ops-hub must model *client instances*; fin-hub needs per-instance cost attribution; N instances = N upgrade operations |
+| **B. Multi-tenant single instance** | One deployment, tenant column / row-level isolation | Cheaper to operate at scale; contradicts current SCOPE; requires tenancy rework in the app; single blast radius for incidents and data-protection failures |
+| **C. Hybrid (A now, B later)** | Start instance-per-client; revisit at a client-count threshold | Defers rework until demand proves it; risk of never consolidating |
+
+### Recommendation
+
+**Option A (instance-per-client) for v1**, with an explicit revisit trigger
+(e.g. >5 paying clients or upgrade toil exceeding one operator-day/month).
+It matches the app's current SCOPE, the railiance-apps per-app values
+pattern, and gives the cleanest early compliance/data-protection story for
+German business clients.
+
+### Downstream effects once resolved
+
+- ops-hub: add client-instance entity (environment × client mapping)
+- fin-hub: per-instance cost attribution keys
+- Business-app service contract (CUST-WP-0058-T04): codify instance
+  provisioning/backup/upgrade obligations
+
+---
+
+## DR-2 — coulomb.social rebuild architecture
+
+**Status:** pending
+
+### Question
+
+Is the coulomb.social rebuild a **Core Hub extension** (hubs/widgets/
+manifests, ops-hub pattern) or a **standalone application** (vergabe-
+teilnahme pattern)?
+
+### Options
+
+| Option | Description | Consequences |
+| --- | --- | --- |
+| **A. Core Hub extension** | Built on `/api/v2` framework: hubs, widgets, manifests, interaction events | Reuses production framework already at `hub.coulomb.social`; interaction-platform semantics fit; couples product evolution to core-hub framework maturity; framework gaps become product blockers |
+| **B. Standalone app** | Own service repo, own DB, deployed via forge→apps lane like vergabe-teilnahme | Full product freedom; no framework coupling; duplicates interaction/identity plumbing core-hub already has; two social-ish surfaces to keep coherent |
+| **C. Defer until after the vergabe-teilnahme pilot** | Run the delivery-lane pilot first; decide with evidence | Costs calendar time; decision made with real platform evidence instead of speculation |
+
+### Recommendation
+
+**Option C, with a leaning toward A.** The delivery-lane pilot
+(CUST-WP-0058-T07) will expose whether the forge→apps path and Core Hub
+framework are mature enough to host a client-facing interaction product.
+Deciding now would be speculation; the bubble.io exit additionally needs a
+separately-scoped **data migration** assessment regardless of which shape
+wins.
+
+### Downstream effects once resolved
+
+- A → core-hub gains its first external-product extension; widget/manifest
+  contract hardening becomes product-critical
+- B → second entry in the business-app service contract; shared identity
+  becomes the only coupling point
+- Either → bubble.io data-export/migration workplan in the owning repo
+
+---
+
+## DR-3 — External identity path for business clients
+
+**Status:** pending
+
+### Question
+
+What identity stack serves *external* users (client employees, later
+coulomb.social members): the current lightweight internal stack
+(KeyCape/Authelia/LLDAP) or the proposed expanded-mode Keycloak lane
+(`NK-WP-0011`)?
+
+### Options
+
+| Option | Description | Consequences |
+| --- | --- | --- |
+| **A. Lightweight stack, app-local accounts for v1** | vergabe-teilnahme manages its own user accounts per instance; platform identity stays internal | Fastest to ship; consistent with instance-per-client isolation; no SSO story; identity debt accrues per app |
+| **B. Activate NK-WP-0011 (Keycloak expanded mode) now** | Platform-level OIDC for external users before first client onboarding | One identity story from day one; enterprise federation ready; heavyweight — delays first client; NK-WP-0011 is only *proposed* |
+| **C. Trigger-based: A for vergabe-teilnahme v1, B gated on defined triggers** | Define explicit conditions that activate the Keycloak lane (e.g. coulomb.social greenlight, first client requesting SSO/AD federation, >2 apps with local accounts) | Ships v1 fast without pretending identity debt doesn't exist; triggers make the debt visible and bounded |
+
+### Recommendation
+
+**Option C.** Vergabe-teilnahme v1 explicitly excludes external partner
+accounts and is instance-per-client, so app-local auth is defensible *for
+that app*. coulomb.social is the forcing function: any resolution of DR-2
+that greenlights the rebuild should automatically activate the NK-WP-0011
+lane, because a social platform on app-local accounts is not viable.
+
+### Downstream effects once resolved
+
+- NetKingdom: NK-WP-0011 gets concrete activation triggers instead of
+  indefinite "proposed" status
+- Business-app service contract: identity section states which mode each
+  app class must use
+
+---
+
+## Resolution protocol
+
+1. Each DR is registered as a pending State Hub decision (custodian topic).
+2. Bernd resolves via `resolve_decision()` or by stating the choice in a
+   session; the resolving agent updates this document's status lines and the
+   hub record together.
+3. `CUST-WP-0058` tasks T01–T03 track the facilitation; downstream tasks
+   stay `wait` until their gating DR is resolved.