Service inventory

Verified against: commit ab4b3ca1d9 (2026-09-26). The table below is generated; re-verify with python tools/scripts/generate/service-inventory.py --check.

This is the canonical list of the services Stella Ops runs: one row per compose service, bundle service and deployable key. It is generated from three sources and reconciles them:

• src/. The deployable keys and the projects they build. These are read from the publish helper’s SERVICES map in devops/docker/build-service-publish.sh, from devops/docker/services-matrix.env and from the deployables of docs/architecture/build-boundary/ownership-manifest.json. Every host project (a Program.cs outside tests, tools, examples and src/__Obsoleted/) is scanned, so a host that no key builds is reported.
• The compose estate. The files devops/compose/docker-compose.stella-ops.yml includes, which is what a plain docker compose up starts, plus the family overlays the generator lists. A service there that declares image or build is a row.
• The release bundle. devops/release/bundle/docker-compose.yml, which a customer installs.

How to read the table

Ownership rules the table reflects

• One service owns one database and its own role on the shared PostgreSQL server (.memory/standards/CODE_OF_CONDUCT.md §8.2, ADR-039). A web and a worker of the same family share that family’s database. The per-database detail and the migration history are in the database ownership matrix.
• Services reach each other through the owner’s API or events, never through a sibling’s database.
• Each deployable builds from its own source graph (build boundary).

Regenerate and check

python tools/scripts/generate/service-inventory.py            # rewrite the generated section
python tools/scripts/generate/service-inventory.py --check    # exit 1 when the section is stale
python tools/scripts/generate/service-inventory.py --self-test
python tools/scripts/generate/service-inventory.py --findings # print the reconciliation findings

--check runs in .gitea/workflows/test-architecture.yml beside the compose key inventory check. It fails when this document no longer matches its sources. A reconciliation finding does not fail the check, with one exception: one-project-two-services, because two compose services built from one project always run one deployable twice.

The generator reads only files git tracks. The src/ roots, the module dossiers and their contents, the host sources it scans for Doctor wiring, and every check that a path exists come from git ls-files. An untracked or ignored leftover, such as the build obj/ directory of a withdrawn src/ root, therefore cannot change the output. Run it in a git checkout.

Generated inventory

Counts

Services

Retired hosts and their successors

Every host project frozen under src/__Obsoleted/, with the successor its freeze record names and the live service that builds that successor.

Opt-in overlays outside the estate

Hosts that an opt-in compose overlay runs, never the estate or the release bundle.

Reconciliation findings

Each line is a disagreement between the sources. A finding is data, not a failure: --check fails only when this section is stale.