coulomb/state-hub
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
state-hub/dashboard/src/docs/services.md
tegwick ce82ada0fa STATE-WP-0062 T5: docs, first-party↔repo test, mark workplan finished 
- Add /docs/services reference (two-dimension model, persistence, API) and a
  pointer note from /docs/tpsc; add it to the Reference nav.
- Add a test asserting first_party.repo_slug resolves to a managed_repos FK
  (8 services tests green).
- Mark STATE-WP-0062 tasks done / status finished.

Known classes seeded in the live catalog via the API (Gitea, Postgres as
self-hosted/third-party; State Hub as self-hosted/first-party at Level 2).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-19 21:16:37 +02:00

2.5 KiB
Raw Blame History

title
Service Catalog — Reference

Service Catalog (two dimensions)

Every service coulomb consumes or operates is classified along two independent dimensions, so four classes fall out of their product:

third-party (not dev-responsible) first-party (dev-responsible)
cloud-hosted (consumed) SaaS / APIs — the classic TPSC a coulomb service deployed to a cloud
self-hosted (operated) OSS coulomb runs (Gitea, Postgres…) a coulomb service on coulomb infra
  • Hosting — self_hosted (coulomb operates the service) vs cloud_hosted (coulomb consumes someone else's running service).
  • Development — first_party (coulomb is development-responsible) vs third_party (coulomb is not).

Persistence

A common service_catalog core table holds the shared fields (slug, name, owner_or_provider, category, status, hosting_type, development_type, maturity_level). Dimension-specific data lives in 1:1 extension tables that compose — a self-hosted first-party service carries both the self-hosted and first-party extensions:

Extension Keyed on Holds
service_third_party development_type = third_party upstream packages, support/service contacts, source, license, pricing
service_first_party development_type = first_party internal dev repo (managed_repos FK), owning domain
service_cloud hosting_type = cloud_hosted GDPR maturity, DPA, ToS/privacy, data-processing regions, retention
service_self_hosted hosting_type = self_hosted three-helix instance/host, deployment & runbook refs, upstream OSS project

maturity_level (1 · Core → 2 · Standard → 3 · Mature) tracks a service against the Service DoM.

API

  • GET /services/catalog?hosting_type=&development_type=&maturity_level=&status= — filtered list; each row includes its applicable extensions.
  • GET /services/{slug} — one service with extensions.
  • POST /services/catalog — upsert by slug; pass first_party.repo_slug to link the internal dev repo.

The dashboard Services section renders three views over this catalog: Third Party, First Party, and Self Hosted.

Migration & back-compat

Existing TPSC catalog rows migrated into service_catalog as (cloud_hosted, third_party), reusing their ids so tpsc_entries.catalog_id keep resolving. The /tpsc/* endpoints and tpsc.yaml ingestion are unchanged.