IPCEICIS-9609 Spike: Current State and Gaps

ABOUTME: Tracks the IPCEICIS-9609 spike scope, investigation approach, and working todo list.

Task

Assess the current implementation state and gaps for Epic IPCEICIS-9600: use case onboarding and KRM consumption enablement.

The spike focuses on whether the current codebase and platform setup support the target flow:

1. Organization onboarding via API.
2. Organization and workspace creation.
3. User authentication, access management, and tenant administration.
4. Cluster creation or association through the platform model.
5. Deployment preparation or triggering for Edge Connect / Magenta Edge.
6. Kubeconfig or cluster access delivery.
7. Documentation and developer onboarding for consumers.

Expected Outputs

By the end of the spike, we should have:

• Current-state assessment of implemented, partially implemented, missing, and unclear capabilities.
• Gap analysis mapping Epic IPCEICIS-9600 requirements to current implementation status.
• Open questions with proposed owners.
• Cross-team dependency map.
• Candidate implementation stories and technical enablers.
• Risks, assumptions, and blockers.
• Recommendation describing what can be delivered immediately, what needs clarification, what needs implementation, and what requires input from other teams.

The stakeholder-facing package is derived from these outputs and currently consists of stakeholder-summary.md, call-agenda-2026-07-10.md, and cross-issue-handoff.md.

Approach

Use evidence-first discovery. For each capability, record the repo/component, API or CRD, source file or manifest, observed behavior, gap, and likely owner.

This spike is backend-focused. The proper frontend code is not available locally, so we do not assess frontend UX implementation. We only assess whether the backend and KRM/kcp layers expose enough capability for a future frontend or API consumer to build a usable onboarding flow.

For every capability, distinguish two layers:

• BFF/API availability: whether there is a consumer-facing backend endpoint or backend workflow in edge-connect-portal-poc or another backend API.
• KRM/kcp availability: whether the capability exists as Kubernetes/kcp resources, CRDs, controllers, APIExports, APIBindings, or Secrets even if no BFF endpoint exists yet.

A capability can therefore be implemented at the KRM/kcp layer but still be partially implemented for use case onboarding if there is no usable BFF/API workflow, no documented retrieval path, or no sensible end-to-end operational flow.

Primary investigation areas:

• Tenant and organization onboarding.
• Workspace provisioning and KCP access.
• IAM, users, roles, RBAC, and identity propagation.
• BFF/API endpoints exposed to consumers or frontend.
• Cluster/KRM consumption model.
• Deployment and kubeconfig/access delivery.
• Existing onboarding and consumption documentation.
• Cross-team dependencies and ownership boundaries.

Primary repos/components to inspect:

• edge-connect-portal-poc: BFF/API surface.
• tenant-controller: tenant and organization onboarding.
• workspace-controller: workspace provisioning and hierarchy.
• zitadel-controller-manager: users, SSO, and IAM-related custom resources.
• zitadel-bootstrap: initial Zitadel/bootstrap setup.
• provider-controller: provider-facing cluster provisioning model.
• cluster-controller-manger: user-facing cluster matchmaking and provider-facing cluster projection.
• poc-core-deploy: platform wiring, GitOps manifests, runtime setup.
• ai-knowledge-base: existing user/developer documentation.

Working Rules

• Keep findings factual and source-backed.
• Distinguish implemented, partially implemented, missing, and unclear.
• Do not treat PoC-only behavior as stable without evidence.
• Track ownership separately from implementation status.
• Capture questions as soon as ambiguity appears.
• Prefer small follow-up story candidates over broad umbrella items.

Todo List

ID	Task	Status	Output
T01	Confirm target flow, terms, and acceptance criteria from IPCEICIS-9600 and IPCEICIS-9609.	In progress	notes.md, terminology.md
T02	Map organization and tenant onboarding implementation.	In progress	capability-matrix.md, findings.md
T03	Map workspace creation, hierarchy, and KCP access implementation.	In progress	capability-matrix.md, notes.md
T04	Map IAM, users, roles, RBAC, tenant admin, and identity propagation.	In progress	capability-matrix.md, findings.md
T05	Map BFF/API endpoints relevant to onboarding and consumer access.	In progress	capability-matrix.md, findings.md
T06	Map cluster creation, cluster association, provider APIs, and KRM consumption model.	In progress	capability-matrix.md, notes.md
T07	Map deployment flow and kubeconfig/access delivery capabilities.	In progress	capability-matrix.md, findings.md
T08	Review existing documentation for onboarding, workspace use, and KRM consumption.	In progress	notes.md, cross-issue-handoff.md
T09	Build gap analysis, dependency map, risks, assumptions, and blockers.	In progress	findings.md
T10	Draft questions for Alexander Klauke and proposed owners.	In progress	questions.md, call-agenda-2026-07-10.md
T11	Draft candidate follow-up Jira stories and technical enablers.	In progress	follow-up-stories.md, cross-issue-handoff.md
T12	Produce final spike recommendation.	Not finalized	findings.md, stakeholder-summary.md

Next Investigation Steps

1. Validate BFF onboarding workflows end-to-end from source: registration, workspace creation, KRM resource creation, status/watch behavior, and error surfaces.
2. Validate kcp/APIExport/APIBinding wiring from poc-core-deploy, especially which APIs are bound into new tenant workspaces by default.
3. Validate IAM and tenant-admin gaps: initial owner, optional initial user, declarative users, SSOConfig, missing invite/member APIs.
4. Validate cluster lifecycle: user-facing cluster create/status/delete, provider-facing cluster reconciliation, mock vs real provider path, and kubeconfig Secret copy-back.
5. Confirm whether any backend or ADR exists for application/Magenta Edge deployment. If none exists, keep deployment marked missing and propose follow-up work.
6. Turn open questions into stakeholder-specific agenda for the Alexander Klauke call.

Deliverable Files

• capability-matrix.md: evidence-backed capability mapping.
• findings.md: synthesized current state, gaps, dependencies, risks, and recommendation.
• questions.md: questions for Alexander Klauke and other owners.
• follow-up-stories.md: candidate Jira follow-up stories.
• stakeholder-summary.md: concise stakeholder-facing summary of working spike findings.
• call-agenda-2026-07-10.md: proposed agenda and decision list for the stakeholder call.
• cross-issue-handoff.md: points that should be handled by other issues, epics, or follow-up spikes.
• terminology.md: working glossary mapping product/Jira terms to backend/kcp terms.
• notes.md: working notes and source references gathered during investigation.