Creatidy/scarcity-router

Fork 0

CI and public release-engineering foundation (Forgejo development CI, GitHub release pipeline) #97

New issue

Closed

opened 2026-09-19 17:24:16 +00:00 by kilo · 1 comment

kilo commented

2026-09-19 17:24:16 +00:00

Member

Goal

Establish the CI and public release-engineering foundation for Scarcity Router before substantial implementation of the execution-gateway modules proceeds.

The repository must have:

deterministic development CI on canonical Forgejo;
early package build/install verification;
an explicit stable-release contract;
a GitHub tag-driven public release pipeline for artifacts that already exist;
secure, reproducible foundations for future server and native-worker artifacts.

This issue establishes infrastructure and contracts. It does not perform a public release and must not pretend that server images, Windows workers or other not-yet-implemented artifacts already exist.

Context

Scarcity Router is an independent Apache-2.0 OSS project.

Canonical repository:

https://forgejo.creatidy.com/BioMedical-IT/scarcity-router

Public read-only mirror:

https://github.com/creatidy/scarcity-router

Development authority:

Forgejo
    issues
    branches
    PRs
    reviews
    development CI

Public distribution surface:

GitHub mirror
    release tags
    GitHub Releases
    GHCR
    public downloadable artifacts

Normal development flow:

feature branch
    -> PR to develop
    -> human merge
    -> develop

Stable release flow:

develop
    -> deliberate human-controlled promotion
    -> main
    -> SemVer release tag
    -> GitHub mirror
    -> public release workflow

main must remain stable and human-controlled. Development PRs must not automatically promote to main.

Architecture foundation issue #85 is complete and merged.

This issue should land before substantial implementation of #86–#95.

Issue #95 remains responsible for polished distribution, installation, upgrade, uninstall and end-to-end user experience. It must build on this foundation rather than becoming the first place where CI/CD architecture is introduced.

Principles

Prefer:

simple;
reproducible;
secure;
conventional OSS practices;
low maintenance;
auditable release provenance.

Avoid building a deployment platform.

CI and release jobs must not require:

live model quota;
paid inference;
personal subscriptions;
private Creatidy infrastructure;
personal credentials;
production provider secrets.

Use deterministic tests and synthetic/redacted fixtures.

Treat pull-request code as untrusted.

PR jobs must not receive publishing credentials or broadly privileged runner access.

Do not expose:

Docker sockets;
arbitrary host mounts;
privileged containers;
production credentials;
broad private-network access;

to normal PR CI.

Scope

1. Forgejo development CI

Introduce Forgejo Actions under:

.forgejo/workflows/

Development CI must run at minimum:

pull request -> develop
push/merge   -> develop

Use a stable required-check/job name suitable for branch protection.

Run the repository's authoritative validation gate, currently equivalent to:

uv sync --only-dev
make check
uv run basedpyright
git diff --check

Do not duplicate repository policy by manually maintaining a different test set inside the workflow where an existing Makefile/project command is authoritative.

Use appropriate concurrency/cancellation so superseded PR runs do not unnecessarily consume runner capacity.

Keep permissions minimal.

Third-party Actions should be minimized and pinned/versioned appropriately for a supply-chain-sensitive OSS workflow.

2. Package build/install validation

CI must validate the distributable Python package, not only the source checkout.

At minimum:

uv build

Then verify the produced wheel from a clean environment.

The smoke test must demonstrate that the installed package and its public console commands can start/import correctly without relying on the source tree.

The validation should catch problems such as:

missing packaged files;
invalid metadata;
broken entry points;
undeclared runtime dependencies;
accidental dependency on repository-relative files.

Do not publish anything from PR CI.

3. Development CI security contract

Document the trust model for CI.

At minimum freeze that:

PR CI is potentially hostile;
PR jobs receive no provider/publishing secrets;
publishing does not run from pull-request events;
public contribution code must not obtain a privileged path into private infrastructure;
release authority is separated from development CI;
secrets must not be required for ordinary deterministic tests.

If the current Forgejo deployment requires trusted/self-hosted runners, document the minimum safe runner boundary and any owner-side hardening required.

Do not solve this by granting PR jobs broad host access.

4. Branch-protection contract

Define the CI status/check that should be required for merging to develop.

Repository code/documentation should contain enough stable information that branch protection does not depend on an accidental workflow/job name.

If actual Forgejo branch-protection configuration is outside repository authority or requires owner/admin action, record the exact required setting as an explicit owner action instead of silently claiming it is configured.

Do not modify main promotion policy in this issue.

5. Release/versioning contract

Document and implement the release invariants.

Public releases originate only from stable main.

A release workflow must fail closed unless all applicable conditions hold:

the ref is a valid supported SemVer release tag, e.g. vX.Y.Z;
package version equals the release tag version;
the tagged commit belongs to stable main;
artifacts are built from the exact tagged commit;
release artifacts pass their applicable verification before publication.

Do not automatically bump versions or automatically promote develop to main.

Do not release arbitrary development commits.

Release tags are intentional human-controlled actions.

6. GitHub public release workflow

Add the GitHub Actions release workflow under:

.github/workflows/

GitHub should not become a second full development-CI authority.

Do not add duplicate GitHub PR CI merely because GitHub Actions exists.

The primary GitHub workflow should be release-oriented and triggered by the deliberate release-tag path.

It must use full enough Git history to verify the release commit against main.

7. Python release artifacts

For the currently existing Python package, prepare the release path for:

scarcity-router-X.Y.Z-py3-none-any.whl
scarcity-router-X.Y.Z.tar.gz

The release workflow should:

build artifacts from the release commit;
validate them;
generate release checksums;
attach appropriate artifacts to GitHub Releases;
support publication to PyPI.

Prefer PyPI Trusted Publishing / OIDC.

Do not introduce a long-lived PyPI API token when Trusted Publishing is available.

External PyPI project/trusted-publisher configuration that cannot be represented in Git should be documented as an explicit owner setup step.

Creating the workflow must not itself publish a package or create a release.

8. Integrity and provenance

Generate at minimum:

SHA256SUMS

for public release artifacts.

Where practical with the current GitHub public repository and workflow model, add GitHub artifact attestations / Sigstore-compatible build provenance using short-lived identity/OIDC rather than persistent signing secrets.

If some provenance mechanism cannot yet be enabled without external owner configuration, implement the repository side and document the exact remaining gate.

Do not add complicated bespoke signing infrastructure merely to satisfy this issue.

9. GHCR foundation

Define the release contract for future server OCI images.

Expected eventual image namespace:

ghcr.io/creatidy/scarcity-router

Expected release tags eventually include:

X.Y.Z
X.Y
latest

latest means the latest stable release, never arbitrary develop.

Prefer:

linux/amd64
linux/arm64

when the actual server image supports and justifies multi-architecture builds.

However:

Do not invent a production server image or fake a successful GHCR publishing job if the repository does not yet contain the required production container artifact.

The foundation should make the future insertion point and release contract explicit. Actual image publication should activate only when a real supported image exists.

Use GitHub's short-lived workflow identity / repository token where appropriate rather than introducing permanent registry credentials.

10. Windows worker release contract

Record the eventual public artifact contract:

scarcity-worker-X.Y.Z-windows-x64.msix
scarcity-worker-X.Y.Z-windows-x64.zip

Windows artifacts must eventually be built on Windows runners.

MSIX remains the preferred main installation direction, subject to implementation evidence.

Portable ZIP may be provided for testing/diagnostics.

Code signing is part of reaching professional public-release quality.

But no Windows worker exists yet.

Therefore this issue must not:

create fake worker binaries;
claim MSIX support;
introduce a placeholder artifact presented as functional;
implement the worker;
solve the installer/update UX assigned to #95.

Record the release contract and the future workflow insertion point only where implementation does not yet exist.

11. Linux/Python installation contract

For the existing Python component, the intended initial public Linux/WSL installation path is:

uv tool install scarcity-router

with:

pipx install scarcity-router

as a conventional alternative after PyPI publication exists.

Do not build or host custom:

apt repositories;
RPM repositories;
pacman repositories.

A Homebrew tap may be considered later but is not required here.

Do not confuse Python-package distribution with eventual native Linux-worker packaging.

12. Documentation

Update the appropriate repository documentation to explain:

Forgejo versus GitHub responsibilities;
development CI;
release authority;
version/tag contract;
available/current artifact types;
future artifact types that are not yet implemented;
security/trust boundaries;
owner-side external configuration still required;
how #95 builds on this foundation.

Documentation must distinguish clearly between:

implemented now
configured externally
defined as future contract
not yet supported

Non-goals

No public release as part of this issue.
No develop -> main promotion.
No automatic release creation from develop.
No duplicate full PR CI on GitHub.
No gateway implementation.
No native worker implementation.
No Windows tray implementation.
No MSIX implementation unless an independently existing supported worker artifact makes a narrowly required packaging proof useful — otherwise defer to #95.
No custom Linux package repositories.
No Kubernetes.
No Jenkins/GitLab CI/second CI platform.
No new artifact registry beyond the agreed GitHub/GHCR/PyPI surfaces.
No private Creatidy deployment assumptions.
No provider secrets or live paid inference in CI.
No elaborate release-management service.

Relationship to existing program

This issue follows the merged architecture foundation #85.

It provides infrastructure used by later implementation issues but should not redefine their architecture.

In particular:

#86–#94 implement execution-gateway capabilities;
#95 owns polished distribution/install/update/uninstall/E2E behavior;
this issue owns the reusable CI/release foundation that #95 will consume.

Do not move product implementation from those issues into this one.

Do not add new dependency cycles to the #85–#95 program.

Acceptance criteria

Forgejo Actions development CI exists and runs for PRs targeting develop.
The same authoritative CI runs after changes land on develop.
CI executes the repository's required validation gate.
CI builds the Python distribution.
A clean-environment wheel/install/entry-point smoke test exists.
PR CI does not require provider credentials, paid inference or private infrastructure.
PR jobs have a documented minimal-permissions/untrusted-code security model.
A stable Forgejo status/check suitable for develop branch protection is defined.
Any owner-only branch-protection configuration still required is explicitly documented.
The release/versioning contract requires valid SemVer, matching package version, stable-main ancestry and exact-commit artifact provenance.
GitHub does not run a duplicate full development-CI pipeline.
A GitHub tag-driven public release workflow exists for artifacts that are actually supported.
Python wheel and sdist release paths are implemented.
PyPI publication uses or is prepared for Trusted Publishing/OIDC; no long-lived PyPI token is introduced.
GitHub Release artifact publication is implemented for supported artifacts.
SHA256SUMS is generated.
Artifact attestation/provenance is implemented where practical, or the precise external gate is documented.
GHCR's future stable-release contract is defined without pretending a nonexistent production image is supported.
Windows worker/MSIX/ZIP release contracts are recorded as future artifacts without fake implementation.
Linux/WSL Python installation guidance uses PyPI/uv tool/pipx; no custom apt/RPM/pacman repository is introduced.
Documentation clearly distinguishes implemented capabilities from future release contracts.
No public package/image/release is actually published merely by implementing this issue.
No runtime Scarcity Router behavior is changed except where a narrowly scoped package/install smoke test requires exposing an already-existing supported entry point.
Repository validation is green.
One feature branch from current develop, one PR targeting develop, left open for human review.

Validation

At minimum run:

uv sync --only-dev
make check
uv run basedpyright
uv build
git diff --check

Also execute the new clean-install package smoke test through the same mechanism that CI will use.

Where workflow syntax cannot be executed locally, validate it using the most appropriate deterministic tooling available and inspect the workflow permissions/triggers manually.

Security considerations

The most important trust boundary is:

untrusted development input
        !=
release authority

No path from an ordinary PR should grant publication authority or access to provider/private-infrastructure secrets.

Use narrowly scoped ephemeral identities for publication where supported.

Release jobs must build the artifact they publish from the exact verified release commit.

Deliverable

One PR to develop containing the minimal CI/release-engineering foundation described above.

Leave it open for human review.

Do not merge it and do not publish a release.

## Goal Establish the CI and public release-engineering foundation for Scarcity Router before substantial implementation of the execution-gateway modules proceeds. The repository must have: * deterministic development CI on canonical Forgejo; * early package build/install verification; * an explicit stable-release contract; * a GitHub tag-driven public release pipeline for artifacts that already exist; * secure, reproducible foundations for future server and native-worker artifacts. This issue establishes infrastructure and contracts. It does **not** perform a public release and must not pretend that server images, Windows workers or other not-yet-implemented artifacts already exist. ## Context Scarcity Router is an independent Apache-2.0 OSS project. Canonical repository: `https://forgejo.creatidy.com/BioMedical-IT/scarcity-router` Public read-only mirror: `https://github.com/creatidy/scarcity-router` Development authority: ```text Forgejo issues branches PRs reviews development CI ``` Public distribution surface: ```text GitHub mirror release tags GitHub Releases GHCR public downloadable artifacts ``` Normal development flow: ```text feature branch -> PR to develop -> human merge -> develop ``` Stable release flow: ```text develop -> deliberate human-controlled promotion -> main -> SemVer release tag -> GitHub mirror -> public release workflow ``` `main` must remain stable and human-controlled. Development PRs must not automatically promote to `main`. Architecture foundation issue #85 is complete and merged. This issue should land before substantial implementation of #86–#95. Issue #95 remains responsible for polished distribution, installation, upgrade, uninstall and end-to-end user experience. It must build on this foundation rather than becoming the first place where CI/CD architecture is introduced. ## Principles Prefer: * simple; * reproducible; * secure; * conventional OSS practices; * low maintenance; * auditable release provenance. Avoid building a deployment platform. CI and release jobs must not require: * live model quota; * paid inference; * personal subscriptions; * private Creatidy infrastructure; * personal credentials; * production provider secrets. Use deterministic tests and synthetic/redacted fixtures. Treat pull-request code as untrusted. PR jobs must not receive publishing credentials or broadly privileged runner access. Do not expose: * Docker sockets; * arbitrary host mounts; * privileged containers; * production credentials; * broad private-network access; to normal PR CI. ## Scope ### 1. Forgejo development CI Introduce Forgejo Actions under: ```text .forgejo/workflows/ ``` Development CI must run at minimum: ```text pull request -> develop push/merge -> develop ``` Use a stable required-check/job name suitable for branch protection. Run the repository's authoritative validation gate, currently equivalent to: ```bash uv sync --only-dev make check uv run basedpyright git diff --check ``` Do not duplicate repository policy by manually maintaining a different test set inside the workflow where an existing Makefile/project command is authoritative. Use appropriate concurrency/cancellation so superseded PR runs do not unnecessarily consume runner capacity. Keep permissions minimal. Third-party Actions should be minimized and pinned/versioned appropriately for a supply-chain-sensitive OSS workflow. ### 2. Package build/install validation CI must validate the distributable Python package, not only the source checkout. At minimum: ```bash uv build ``` Then verify the produced wheel from a clean environment. The smoke test must demonstrate that the installed package and its public console commands can start/import correctly without relying on the source tree. The validation should catch problems such as: * missing packaged files; * invalid metadata; * broken entry points; * undeclared runtime dependencies; * accidental dependency on repository-relative files. Do not publish anything from PR CI. ### 3. Development CI security contract Document the trust model for CI. At minimum freeze that: * PR CI is potentially hostile; * PR jobs receive no provider/publishing secrets; * publishing does not run from pull-request events; * public contribution code must not obtain a privileged path into private infrastructure; * release authority is separated from development CI; * secrets must not be required for ordinary deterministic tests. If the current Forgejo deployment requires trusted/self-hosted runners, document the minimum safe runner boundary and any owner-side hardening required. Do not solve this by granting PR jobs broad host access. ### 4. Branch-protection contract Define the CI status/check that should be required for merging to `develop`. Repository code/documentation should contain enough stable information that branch protection does not depend on an accidental workflow/job name. If actual Forgejo branch-protection configuration is outside repository authority or requires owner/admin action, record the exact required setting as an explicit owner action instead of silently claiming it is configured. Do not modify `main` promotion policy in this issue. ### 5. Release/versioning contract Document and implement the release invariants. Public releases originate only from stable `main`. A release workflow must fail closed unless all applicable conditions hold: 1. the ref is a valid supported SemVer release tag, e.g. `vX.Y.Z`; 2. package version equals the release tag version; 3. the tagged commit belongs to stable `main`; 4. artifacts are built from the exact tagged commit; 5. release artifacts pass their applicable verification before publication. Do not automatically bump versions or automatically promote `develop` to `main`. Do not release arbitrary development commits. Release tags are intentional human-controlled actions. ### 6. GitHub public release workflow Add the GitHub Actions release workflow under: ```text .github/workflows/ ``` GitHub should **not** become a second full development-CI authority. Do not add duplicate GitHub PR CI merely because GitHub Actions exists. The primary GitHub workflow should be release-oriented and triggered by the deliberate release-tag path. It must use full enough Git history to verify the release commit against `main`. ### 7. Python release artifacts For the currently existing Python package, prepare the release path for: ```text scarcity-router-X.Y.Z-py3-none-any.whl scarcity-router-X.Y.Z.tar.gz ``` The release workflow should: * build artifacts from the release commit; * validate them; * generate release checksums; * attach appropriate artifacts to GitHub Releases; * support publication to PyPI. Prefer PyPI Trusted Publishing / OIDC. Do not introduce a long-lived PyPI API token when Trusted Publishing is available. External PyPI project/trusted-publisher configuration that cannot be represented in Git should be documented as an explicit owner setup step. Creating the workflow must not itself publish a package or create a release. ### 8. Integrity and provenance Generate at minimum: ```text SHA256SUMS ``` for public release artifacts. Where practical with the current GitHub public repository and workflow model, add GitHub artifact attestations / Sigstore-compatible build provenance using short-lived identity/OIDC rather than persistent signing secrets. If some provenance mechanism cannot yet be enabled without external owner configuration, implement the repository side and document the exact remaining gate. Do not add complicated bespoke signing infrastructure merely to satisfy this issue. ### 9. GHCR foundation Define the release contract for future server OCI images. Expected eventual image namespace: ```text ghcr.io/creatidy/scarcity-router ``` Expected release tags eventually include: ```text X.Y.Z X.Y latest ``` `latest` means the latest stable release, never arbitrary `develop`. Prefer: ```text linux/amd64 linux/arm64 ``` when the actual server image supports and justifies multi-architecture builds. However: **Do not invent a production server image or fake a successful GHCR publishing job if the repository does not yet contain the required production container artifact.** The foundation should make the future insertion point and release contract explicit. Actual image publication should activate only when a real supported image exists. Use GitHub's short-lived workflow identity / repository token where appropriate rather than introducing permanent registry credentials. ### 10. Windows worker release contract Record the eventual public artifact contract: ```text scarcity-worker-X.Y.Z-windows-x64.msix scarcity-worker-X.Y.Z-windows-x64.zip ``` Windows artifacts must eventually be built on Windows runners. MSIX remains the preferred main installation direction, subject to implementation evidence. Portable ZIP may be provided for testing/diagnostics. Code signing is part of reaching professional public-release quality. But no Windows worker exists yet. Therefore this issue must **not**: * create fake worker binaries; * claim MSIX support; * introduce a placeholder artifact presented as functional; * implement the worker; * solve the installer/update UX assigned to #95. Record the release contract and the future workflow insertion point only where implementation does not yet exist. ### 11. Linux/Python installation contract For the existing Python component, the intended initial public Linux/WSL installation path is: ```bash uv tool install scarcity-router ``` with: ```bash pipx install scarcity-router ``` as a conventional alternative after PyPI publication exists. Do not build or host custom: * apt repositories; * RPM repositories; * pacman repositories. A Homebrew tap may be considered later but is not required here. Do not confuse Python-package distribution with eventual native Linux-worker packaging. ### 12. Documentation Update the appropriate repository documentation to explain: * Forgejo versus GitHub responsibilities; * development CI; * release authority; * version/tag contract; * available/current artifact types; * future artifact types that are not yet implemented; * security/trust boundaries; * owner-side external configuration still required; * how #95 builds on this foundation. Documentation must distinguish clearly between: ```text implemented now configured externally defined as future contract not yet supported ``` ## Non-goals * No public release as part of this issue. * No `develop -> main` promotion. * No automatic release creation from `develop`. * No duplicate full PR CI on GitHub. * No gateway implementation. * No native worker implementation. * No Windows tray implementation. * No MSIX implementation unless an independently existing supported worker artifact makes a narrowly required packaging proof useful — otherwise defer to #95. * No custom Linux package repositories. * No Kubernetes. * No Jenkins/GitLab CI/second CI platform. * No new artifact registry beyond the agreed GitHub/GHCR/PyPI surfaces. * No private Creatidy deployment assumptions. * No provider secrets or live paid inference in CI. * No elaborate release-management service. ## Relationship to existing program This issue follows the merged architecture foundation #85. It provides infrastructure used by later implementation issues but should not redefine their architecture. In particular: * #86–#94 implement execution-gateway capabilities; * #95 owns polished distribution/install/update/uninstall/E2E behavior; * this issue owns the reusable CI/release foundation that #95 will consume. Do not move product implementation from those issues into this one. Do not add new dependency cycles to the #85–#95 program. ## Acceptance criteria * [ ] Forgejo Actions development CI exists and runs for PRs targeting `develop`. * [ ] The same authoritative CI runs after changes land on `develop`. * [ ] CI executes the repository's required validation gate. * [ ] CI builds the Python distribution. * [ ] A clean-environment wheel/install/entry-point smoke test exists. * [ ] PR CI does not require provider credentials, paid inference or private infrastructure. * [ ] PR jobs have a documented minimal-permissions/untrusted-code security model. * [ ] A stable Forgejo status/check suitable for `develop` branch protection is defined. * [ ] Any owner-only branch-protection configuration still required is explicitly documented. * [ ] The release/versioning contract requires valid SemVer, matching package version, stable-`main` ancestry and exact-commit artifact provenance. * [ ] GitHub does not run a duplicate full development-CI pipeline. * [ ] A GitHub tag-driven public release workflow exists for artifacts that are actually supported. * [ ] Python wheel and sdist release paths are implemented. * [ ] PyPI publication uses or is prepared for Trusted Publishing/OIDC; no long-lived PyPI token is introduced. * [ ] GitHub Release artifact publication is implemented for supported artifacts. * [ ] `SHA256SUMS` is generated. * [ ] Artifact attestation/provenance is implemented where practical, or the precise external gate is documented. * [ ] GHCR's future stable-release contract is defined without pretending a nonexistent production image is supported. * [ ] Windows worker/MSIX/ZIP release contracts are recorded as future artifacts without fake implementation. * [ ] Linux/WSL Python installation guidance uses PyPI/`uv tool`/`pipx`; no custom apt/RPM/pacman repository is introduced. * [ ] Documentation clearly distinguishes implemented capabilities from future release contracts. * [ ] No public package/image/release is actually published merely by implementing this issue. * [ ] No runtime Scarcity Router behavior is changed except where a narrowly scoped package/install smoke test requires exposing an already-existing supported entry point. * [ ] Repository validation is green. * [ ] One feature branch from current `develop`, one PR targeting `develop`, left open for human review. ## Validation At minimum run: ```bash uv sync --only-dev make check uv run basedpyright uv build git diff --check ``` Also execute the new clean-install package smoke test through the same mechanism that CI will use. Where workflow syntax cannot be executed locally, validate it using the most appropriate deterministic tooling available and inspect the workflow permissions/triggers manually. ## Security considerations The most important trust boundary is: ```text untrusted development input != release authority ``` No path from an ordinary PR should grant publication authority or access to provider/private-infrastructure secrets. Use narrowly scoped ephemeral identities for publication where supported. Release jobs must build the artifact they publish from the exact verified release commit. ## Deliverable One PR to `develop` containing the minimal CI/release-engineering foundation described above. Leave it open for human review. Do not merge it and do not publish a release.

adrian.tkacz referenced this issue from a commit

2026-09-19 17:46:23 +00:00

ci(foundation): Forgejo development CI and GitHub tag-driven release pipeline (issue #97)

kilo referenced this issue

2026-09-19 17:46:53 +00:00

ci(foundation): Forgejo development CI and GitHub tag-driven release pipeline (issue #97) #98

adrian.tkacz referenced this issue from a commit

2026-09-19 18:11:51 +00:00

fix(release): structurally separate the PyPI payload from the release bundle (issue #97)

adrian.tkacz referenced this issue from a commit

2026-09-19 18:56:09 +00:00

Merge pull request 'ci(foundation): Forgejo development CI and GitHub tag-driven release pipeline (issue #97)' (#98) from ci/release-foundation into develop

kilo referenced this issue

2026-09-21 05:35:42 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108

kilo commented

2026-09-21 17:06:16 +00:00

Author

Member

Closeout (v0.1.0 release-readiness reconciliation, 2026-09-21). The CI and public release-engineering foundation (D-046, docs/release-engineering.md) is implemented and operating; every repository-side acceptance criterion is satisfied.

Forgejo Actions development CI (.forgejo/workflows/ci.yml, workflow ci, job check) exists, runs on every PR to develop and every push to develop, executes the authoritative gate (uv sync --only-dev, make check, uv run basedpyright, git diff --check) plus make package-check, with contents: read only, pinned-by-SHA actions, per-ref concurrency cancellation, and no secrets anywhere in the path. It is not just defined — it has been running green on this infrastructure (runs #16–#25, latest on develop @ 9d6192e, 11m46s, success).
Package build/install validation: make package-check builds wheel+sdist, inspects contents/metadata, and smoke-installs the wheel into a throwaway uv tool environment (four console scripts, packaged resources, MCP discovery, loopback REST healthz) — catching missing package data, broken entry points, undeclared dependencies and repository-relative assumptions.
Release/versioning contract enforced fail-closed by .github/workflows/release.yml (verify job): strict SemVer tag, package version equality from the single __version__ literal, tagged-commit ancestry in stable main, exact-commit artifact builds, make package-check before any publication; GitHub hosts exactly one tag-driven workflow and no duplicate development CI; no PR event can trigger release and PR code receives no release secrets; SHA256SUMS covers wheel/sdist/worker-zip and is re-verified and attested with final bytes; PyPI input is structurally restricted to *.whl/*.tar.gz via separate artifact upload plus a guard step; publication uses only short-lived OIDC (Trusted Publishing) — no long-lived token exists.
Owner-only configuration is explicitly documented as owner actions (not claimed configured): Forgejo runner boundary, develop branch protection requiring the check status, PyPI Trusted Publisher entry, GitHub pypi environment with reviewers. The runner itself is now demonstrably operating; the remaining items stay recorded in docs/release-engineering.md.
GHCR image, MSIX and future worker artifact contracts are recorded without pretending nonexistent artifacts exist; nothing was published by this work.

Validation: full gate green (1868 tests, basedpyright clean, package-check green); workflow YAML re-inspected manually per the documented discipline. Closing as complete; docs/roadmap.md records the foundation as in place.

**Closeout (v0.1.0 release-readiness reconciliation, 2026-09-21).** The CI and public release-engineering foundation (D-046, `docs/release-engineering.md`) is implemented and operating; every repository-side acceptance criterion is satisfied. - Forgejo Actions development CI (`.forgejo/workflows/ci.yml`, workflow `ci`, job `check`) exists, runs on every PR to `develop` and every push to `develop`, executes the authoritative gate (`uv sync --only-dev`, `make check`, `uv run basedpyright`, `git diff --check`) plus `make package-check`, with `contents: read` only, pinned-by-SHA actions, per-ref concurrency cancellation, and no secrets anywhere in the path. It is not just defined — it has been running green on this infrastructure (runs #16–#25, latest on `develop` @ `9d6192e`, 11m46s, success). - Package build/install validation: `make package-check` builds wheel+sdist, inspects contents/metadata, and smoke-installs the wheel into a throwaway `uv tool` environment (four console scripts, packaged resources, MCP discovery, loopback REST healthz) — catching missing package data, broken entry points, undeclared dependencies and repository-relative assumptions. - Release/versioning contract enforced fail-closed by `.github/workflows/release.yml` (`verify` job): strict SemVer tag, package version equality from the single `__version__` literal, tagged-commit ancestry in stable `main`, exact-commit artifact builds, `make package-check` before any publication; GitHub hosts exactly one tag-driven workflow and no duplicate development CI; no PR event can trigger release and PR code receives no release secrets; `SHA256SUMS` covers wheel/sdist/worker-zip and is re-verified and attested with final bytes; PyPI input is structurally restricted to `*.whl`/`*.tar.gz` via separate artifact upload plus a guard step; publication uses only short-lived OIDC (Trusted Publishing) — no long-lived token exists. - Owner-only configuration is explicitly documented as owner actions (not claimed configured): Forgejo runner boundary, `develop` branch protection requiring the `check` status, PyPI Trusted Publisher entry, GitHub `pypi` environment with reviewers. The runner itself is now demonstrably operating; the remaining items stay recorded in `docs/release-engineering.md`. - GHCR image, MSIX and future worker artifact contracts are recorded without pretending nonexistent artifacts exist; nothing was published by this work. Validation: full gate green (1868 tests, basedpyright clean, package-check green); workflow YAML re-inspected manually per the documented discipline. Closing as complete; `docs/roadmap.md` records the foundation as in place.

kilo closed this issue

2026-09-21 17:06:25 +00:00

adrian.tkacz referenced this issue from a commit

2026-09-21 19:00:09 +00:00

docs(program): close out the execution-gateway program in roadmap and README

kilo referenced this issue

2026-09-21 19:00:37 +00:00

v0.1.0 release readiness: first-run availability + Z.ai endpoint path + TLS healthcheck fixes, PyPI-last publication ordering, candidate preflight, program closeout #109