Implementation status

The final record of what CommonLayer implements, where, how it was tested and where that testing happened, and what is not done. It is compiled from the work-package status files in docs/status/ (WP-01 to WP-81), the security review of November 2026, and the list of GitHub Actions runs of this repository as read on 2026-11-10 around 22:40 UTC. Where a status file and the code disagreed, the code was read and this page follows it.

Repository stewardship and onboarding through the GitHub App (WP-80, WP-81; plan 13) were added on 2026-11-11. Their commits were pushed without workflow runs to save runner minutes (ADR-0048); the final tree (0c3ffd0) was then checked on GitHub runners by ci, security, docs and infra. What ran for the stewardship work, and where, is stated in each section below.

After that, the first-party projects were corrected (WP-83, plan 14, ADR-0049): the base image, nginx, Valkey and PostgreSQL had been built as directories of this repository, by its workflows. Each is now a complete repository tree of its own (commonlayer-org/<project>), kept under projects/ only until those repositories exist. The same day a missing object storage bucket became its own error, the development GitHub learned to serve a project directory of the checkout, and a helper registers the GitHub App from a manifest (WP-82).

On 2026-11-12 the portal was reworked by one rule, "don't make me think" (WP-90, plan 15): every page says where you are, what the state is and what to do next; dashboards start with what is waiting; explanations moved behind disclosures or into the documentation. A check holds 117 page types to the countable parts of that rule.

Words used on this page:

• Tested locally: automated tests or a scripted drill ran and passed in the build sandbox (linux/amd64, Docker 29, one shared machine), as recorded in a status file.
• Tested on a GitHub runner: a workflow job ran and passed on a GitHub-hosted runner (ubuntu-24.04, linux/amd64). The run id is given.
• Validated statically: linted, schema-checked, rendered or unit-tested as configuration, but never executed against the thing it configures.
• Never run: exists in the repository; nothing has executed it.

Nothing is in production. No artifact has been published to a CommonLayer registry, no contribution has been accepted with real money, and no payout has been made.

Not done or not verified

Read this section before relying on any part of the platform. It is ordered by consequence: what has never run at all, then what ran only on GitHub runners or only locally, what is implemented only in part, and the decisions that only the operating entity can make.

Never run anywhere

Ran only on GitHub runners

Ran only locally (build sandbox)

Implemented but partial, and open requests nobody picked up

Repository stewardship (WP-80, WP-81):

• The API process holds the GitHub App key as well as the worker, because the repository picker asks GitHub synchronously (threat model O16). The plan wanted it in the worker only.
• Backups hold git history only. Issues, pull requests, release pages, wikis and Git LFS objects are not backed up; every manifest says so. A bundle is assembled in memory before upload, bounded by github.backup_max_bytes (2 GiB by default).
• An accepted collaborator invitation is noticed at the next reconciliation, not when it happens (the member webhook is not processed).
• The rule catalogue knows one template version. A second version needs versioned rule sets. First-party projects in this repository report their CI rules as not applicable, because this repository's workflows build them.
• Five of the new metrics are on no dashboard; the three alerts and their runbook sections exist.
• The development GitHub provider resolves concurrent writes to one repository by last write wins, and reads its repositories from the checkout, so it works in make dev and in the Compose stack (checkout mounted) and nowhere else.
• A release backup links to the release history, not to one release: the portal has no page per release.
• Verifying a restore needs project.maintainers.manage. The successor creates the new repository; a project admin or a platform reviewer runs the verification.
• The stewardship-hosted restore was never run end to end, in the portal or against GitHub: the development stack has no stewardship organization. Its service path is tested with wiremock and a local bare repository.
• The seeded RabbitMQ project was seeded in review directly, not through an onboarding, so its repository link reads pending; a project that comes through onboarding has a verified primary repository.
• The project trees still live in this repository. They are complete repositories (projects/base, nginx, valkey, postgresql), exported unchanged by scripts/export-project.sh, and stay here until commonlayer-org/<project> exist. After that the trees, the projects workflow, mk/projects.mk and the platform's local base image fallback are removed from this repository.
• No base image is released, so nginx, Valkey and PostgreSQL have an empty images[].base.digest and build from a base built out of a checkout of the base project. Their release workflows refuse to release until the digest is filled in.

Platform and backend:

• Platform binaries carry no dependency metadata. syft and Trivy see no Rust crate in the platform images; only cargo-deny and cargo-audit in CI cover the Rust dependencies. Request (WP-70g): build release binaries with cargo auditable.
• commonlayer_build_info reports commit="unknown" in the images: the build passes VCS_REF as a label only. Request (WP-70g): pass the commit to the metric.
• The bundled cosign 3.1.4 (worker image and scripts/dev/install-tools.sh) contains golang.org/x/net 0.61.0 (CVE-2026-78661, HIGH, fixed in 0.62.0), go-chi/chi 5.3.2 (CVE-2026-114437, MEDIUM) and x/crypto 0.58.0 (GO-2026-5932). Request (WP-70g): update when a cosign release with the fixes exists.
• The seed writes before it has read every manifest, so a failing seed leaves the database marked seed.partial and has to be reset. Request (WP-70g to WP-40).
• No public list of organizations, so organization pages are not in the sitemap (WP-70e). Also requested by WP-70e and not done: GET /admin/maintenance/sla (the platform default SLA can be written but not read), usernames on payout runs and on updated_by of settings, project slugs on ledger accounts and evaluation details, and a paginated public contributor list per project (first requested by WP-31).
• Ledger and audit tamper resistance against the owner role or a superuser (threat model O1, O2): the runtime role cannot disable the triggers, but whoever holds the owner credentials can. Not done: a hash chain over the ledger, and exporting audit checkpoint digests outside the database.
• The API still holds the payment provider's secret key and the registry token signing key (O7): checkout, refunds and subscription changes are synchronous provider calls, and the token realm signs pull tokens. Moving provider calls into worker jobs and a separate promoter process are follow-ups.
• Repository links verified before migration 0016 are not re-checked against GitHub's numeric id (review MEDIUM-5).
• Areas the security review did not cover: registry retention and registry-event ingestion beyond authentication; the SBOM, VEX, Trivy and Grype parsers and the subprocess adapter; outbound webhook sending; organization role APIs and the last-admin trigger; password reset details (reset tokens issued before an email change stay valid, noted, not analysed); lockout and rate-limit internals; audit and log redaction coverage; the web content security policy and the development-only pages; gRPC parity for maintenance, security and artifact mutations; rounding in settlement beyond the largest-remainder approach. The review also did not run the test suites.
• Rate limiting during a Valkey outage is per process: N API replicas allow up to N times each limit (ADR-0019).
• Registry retention protects digests with open findings or named in a published advisory (the security domain's retention_protection, since WP-70g) and promoted digests with any present vulnerability; blobs are reclaimed only by Distribution's offline garbage collection. Retention was outside the security review.
• OSV pagination beyond the first page is not followed; CVSS v4 vectors are not scored.
• Stripe: the invoice_payment.paid event must be enabled on the webhook endpoint; without it the link is resolved on demand (one API call per unmatched refund or dispute). A refund hold whose provider webhook arrives before the request stored the refund reference lapses after 7 days instead of being released.
• clctl registry verify-preservation ran against the drill's registry, where 15 of 18 preserved digests are reported missing_manifest: the development seed records digests it never pushes.
• gRPC has no RPC for operations that need an interactive session, and no GRPCRoute; the chart exposes it through an Ingress with h2c to the pod (rendered, not installed).
• Portal: three maintainer actions have API operations but no portal page, found while writing the handbooks (not recorded in any status file): reviewing a community contribution (POST /contributions/{id}/review), submitting a contribution by hand (POST /projects/{slug}/contributions) and deciding a task waiver (POST /tasks/{id}/waive with a decision). The platform default SLA editor starts from a project that uses it (no read API); "set back to the default" for a runtime setting stores the default as an override (no delete); the unknown-payout resolve dialog has not run end to end (no seeded unknown payout); contribution targets can be reported for abuse only through the API; ledger accounts and payout-run initiator/approver show ids, resolved on the page.
• Compose stack: all portal traffic counts against the web container's address unless the stack trusts it (ADR-0040).
• Load: the musl allocator under multi-threaded load was not measured (WP-50 asked WP-70 to).

Images, charts, catalog and CI:

• Scanner coverage of source-built components rests on Grype alone: Trivy evaluates none of the declared nginx, Valkey, PostgreSQL and darkhttpd components (ADR-0039). CommonLayer's own helpers (cl-probe, cl-kube-label) have no vulnerability feed; Valkey's vendored deps/ are not declared separately.
• Requests of WP-70f to the CI owner not yet done: upload the SBOM-scan SARIF (sarif/trivy-sbom, sarif/grype-sbom) to code scanning when it is available (only the image-scan SARIF is uploaded); run make -C projects/postgresql chart-test-kind instead of the scripts/test-kind.sh wrapper. Done in the workflows as they stand: the "Keep reports" step uploads hidden files, projects-rescan installs syft, and one tool installer is used everywhere.
• The Valkey HA test and the PostgreSQL HA hooks, which failed on GitHub runners during this work, pass there now (runs 42932208078 and 42920329890; see above).
• Base image not released, so images[].base.digest is empty in every manifest; the release order is in projects/base/README.md.
• Bitnami catalog: nginx, Valkey and PostgreSQL are in_development (built and tested here, nothing published) (ADR-0042).

Decisions that belong to the operating entity

State of the GitHub workflows (2026-11-11, after the push for the standalone projects)

The stewardship commits were pushed without workflow runs (ADR-0048). The final push (0c3ffd0) then ran ci, security and docs, and infra was started by hand for the same commit, because its path filter only sees the last push. Scheduled workflows ran regardless of the markers. The work after that (WP-82, WP-83) was pushed the same way; its final push (d6e382b) ran ci, security and docs, and projects was started by hand for two trees.

Acceptance workflows A–E

The product brief's five workflows, and what proves each. "Fakes at the boundary" means the real composition (AppContext::assemble) over a real PostgreSQL database per test, with fakes only for time, the source and destination registries, cosign, Trivy/Grype, repository files, the Actions OIDC verifier and SMTP; the payment provider is the real simulator with signed webhooks; jobs run through the real job registry.

Not proven by any of these: keyless signatures, GitHub's provenance format, live payments and payouts, a GitHub App, and anything on a cluster.

Repository stewardship added three workflows of its own (plan 13 §10, §11):

Test inventory

Counts as recorded in the status files; the date of every run is 2026-11-10.

Status by work package

Feature areas

Foundation

Identity and organizations

Projects

Artifacts and registry

Security

Maintenance and eligibility

Funding and ledger

GitHub and notifications

Repository stewardship and onboarding

gRPC

Web portal

Images, charts and template

Platform deployment, CI and operations

Documentation