ci: migrate to Gitea Actions

README.md

@@ -238,24 +238,15 @@ The image builds the Angular application with Bun and Node, then runs the genera
 
 ## Continuous integration
 
-CI execution is frozen after the migration to Gitea, and Gitea Actions is disabled. [Issue #268](https://gitea.nessar.fr/nessar/vac-optimizer/issues/268) tracks conversion of the preserved CI configuration to Gitea Actions. There is no checked-in `.gitea/workflows/` workflow yet.
+[`.gitea/workflows/ci.yml`](.gitea/workflows/ci.yml) defines Gitea Actions validation, functional coverage, production builds, security scans, and Docker image publication. [Issue #268](https://gitea.nessar.fr/nessar/vac-optimizer/issues/268) tracks activation. Actions is enabled with owner approval; publisher credentials and live workflow validation are still pending. The [activation guide](docs/gitea-actions.md) records runner, credential, permission, and merge-gate requirements.
 
-The preserved `.gitlab-ci.yml` defines validation, test, build, security, and image stages:
+The workflow runs on branch/tag pushes, PR opening/reopening/synchronization/edits, and manual dispatch. Manual runs validate without publishing images. Required jobs cover policy regression tests, GitFlow and Conventional Commits, ESLint, Prettier, application/test type checks, Vitest coverage, the production build, Semgrep SAST, and Trivy dependency/secret scans. Coverage, build output, and SARIF reports are retained for seven days.
 
-- ESLint, Prettier, and TypeScript checks;
-- Vitest with coverage artifacts;
-- an optimized production build;
-- legacy GitLab SAST and Trivy filesystem scanning;
-- GitFlow, Conventional Commit, and release-version checks;
-- Docker image publication for successful branch pushes and same-project reviews.
+Functional tests use one worker and a 2 GiB Node heap. The separate benchmark job runs without coverage and keeps its five-minute protocol timeout. At the user's request, it has `continue-on-error: true` while [#78](https://gitea.nessar.fr/nessar/vac-optimizer/issues/78) is open. #78 must restore the benchmark gate after the protocol passes. Passing functional checks during this exception does not establish benchmark acceptance.
 
-These definitions are migration inputs; they do not execute on Gitea. The policy script also still expects GitLab `CI_*` variables. Triggers, required checks, runner requirements, secrets, security scanning, image publication, and merge-message templates must be reviewed as part of #268 before the owner enables the converted workflow. Historical CI logs, reports, and downloadable artifacts were not imported; administrator rollback backups retain them.
+The `required` job aggregates successful validation and expected image publication, accepting the image job's intentional skip for fork PRs and manual runs. Image jobs require successful validation and are limited to pushes and same-repository PRs. Registry credentials are confined to the publishing step.
 
-In the preserved configuration, the required `test` job runs application tests with coverage, one worker and a 2 GiB Node heap limit. A separate `benchmark` job uses the same environment outside coverage instrumentation, with the unchanged five-minute timeout and protocol assertions.
-
-At the user's request, the preserved benchmark job has `allow_failure: true` while [#78](https://gitea.nessar.fr/nessar/vac-optimizer/issues/78) is open. Carry that advisory status into the converted workflow; #78 must restore the required benchmark gate after the protocol passes. Passing functional checks during this exception does not establish benchmark acceptance.
-
-Both protected branches require the unsatisfied status `gitlab-to-gitea/ci-conversion-required` until conversion is reviewed. Local validation does not satisfy this status; owner review and replacement of the migration gate are required before merges resume. See #268 for the migration requirements.
+Both protected branches still require `gitlab-to-gitea/ci-conversion-required` until the owner approves the first merge message and a successful Gitea PR run, then replaces the migration gate with the actual pull-request context for `required`. Local validation does not satisfy this status. Historical CI reports and artifacts remain in administrator rollback backups; the original configuration is retained in Git history.
 
 ### GitFlow and releases
 
@@ -263,18 +254,18 @@ Both protected branches require the unsatisfied status `gitlab-to-gitea/ci-conve
 
 Create `release/X.Y.Z` from `develop` when the release scope is ready. Set `package.json` to `X.Y.Z` on this branch, stabilize it, then merge it into `main` and back into `develop`. Keep the release branch until both PRs have merged. A `hotfix/X.Y.Z` starts from `main`, changes the package version, and follows the same two-target merge process. Do not rebase `main`, `develop`, or a frozen release onto ongoing development.
 
-Use Conventional Commits for new commits and PR titles, for example `feat(calendar): add planning periods`, `fix(planner): handle expired balances`, or `chore(release): prepare 1.6.0`. Scopes are optional; `!` marks a breaking change. The merge commit subject must preserve the validated PR title. Gitea supports a [Git-based merge-message template](https://docs.gitea.com/usage/issues-prs/merge-message-templates/) at `.gitea/default_merge_message/MERGE_TEMPLATE.md`, using `${PullRequestTitle}` and `${PullRequestReference}`. Its introduction and an example expanded message are part of #268; legacy history is not rewritten.
+Use Conventional Commits for new commits and PR titles, for example `feat(calendar): add planning periods`, `fix(planner): handle expired balances`, or `chore(release): prepare 1.6.0`. Scopes are optional; `!` marks a breaking change. The merge commit subject must preserve the validated PR title. Gitea supports a [Git-based merge-message template](https://docs.gitea.com/usage/issues-prs/merge-message-templates/) at `.gitea/default_merge_message/MERGE_TEMPLATE.md`, using `${PullRequestTitle}` and `${PullRequestReference}`. The committed template and a checked example expansion are documented in the [activation guide](docs/gitea-actions.md); legacy history is not rewritten.
 
-The image tag contract to preserve during CI conversion is:
+The image publisher implements this tag contract in `gitea.nessar.fr/nessar/vac-optimizer`:
 
 | Trigger | Published image tags |
 | --- | --- |
 | Successful push to any branch | `branch-<normalized branch slug>` and `sha-<full commit SHA>` |
 | Explicit release tag `vX.Y.Z` | `vX.Y.Z` and `latest`, using the existing SHA image |
 
-For example, `feature/calendar` uses `branch-feature-calendar`; integration uses `branch-develop`. Preserve the previous slug normalization: lowercase the branch name, replace characters other than `a-z` and `0-9` with `-`, truncate to 63 bytes, and remove leading/trailing `-`. Choose branch names with distinct slugs. Only valid release tags can update `latest`. Automatic image publication and tag promotion remain frozen until #268 is complete.
+For example, `feature/calendar` uses `branch-feature-calendar`; integration uses `branch-develop`. Preserve the previous slug normalization: lowercase the branch name, replace characters other than `a-z` and `0-9` with `-`, truncate to 63 bytes, and remove leading/trailing `-`. Choose branch names with distinct slugs. Only valid release tags can update `latest`. Automatic image publication and tag promotion begin after the owner provisions publisher credentials and validates publication permissions.
 
-After CI conversion is complete, the PR into `main` has merged, and its full checks and SHA image publication have succeeded, tag the published main commit:
+After owner activation, the PR into `main` has merged, and its full checks and SHA image publication have succeeded, tag the published main commit:
 
 ```bash
 git fetch origin
@@ -284,11 +275,11 @@ git push origin v1.6.0
 
 The tag must match the tagged commit's `package.json` version, use stable `vMAJOR.MINOR.PATCH` syntax, and point to a commit reachable from `main`. Wait for the main checks and image publication before tagging: promotion requires its `sha-<commit>` image. Tags do not increment the version automatically.
 
-The Gitea repository policy requires `develop` as the default branch and **Merge commit** as the merge method, with squash and rebase merge methods disabled. Configure [branch protection](https://docs.gitea.com/usage/access-control/protected-branches/) for `main` and `develop` to disable direct and forced pushes, restrict the merge allowlist to designated maintainers, require successful status checks, and block outdated PRs. Administrators must follow the protection rules. Replace the migration gate with the reviewed check contexts only after #268 is complete. These are required settings; the migration does not establish that every setting has already been applied.
+The Gitea repository policy requires `develop` as the default branch and **Merge commit** as the merge method, with squash and rebase merge methods disabled. Configure [branch protection](https://docs.gitea.com/usage/access-control/protected-branches/) for `main` and `develop` to disable direct and forced pushes, restrict the merge allowlist to designated maintainers, require successful status checks, and block outdated PRs. Administrators must follow the protection rules. After merge-message approval and a successful reviewed PR run, replace the migration gate with the reported pull-request context for the `required` job, as described in the activation guide. These are required settings; the migration does not establish that every setting has already been applied.
 
-Only `release/*` and `hotfix/*` PRs may target `main`; working PRs target `develop`. The converted CI must retain these rules and the rebase checks. If `develop` advances after validation, rebase and rerun the PR checks before merging.
+Only `release/*` and `hotfix/*` PRs may target `main`; working PRs target `develop`. CI validates these rules and checks working-branch rebases against the fetched integration head. If `develop` advances after validation, rebase and rerun the PR checks before merging.
 
-Run the preserved policy integration check locally with `node scripts/ci-policy.test.mjs`. It verifies the legacy policy adapter; it does not validate a Gitea workflow or satisfy the migration gate.
+Run `node scripts/ci-policy.test.mjs` and `node scripts/ci-image.test.mjs` locally to verify GitFlow event handling and image publication without writing to a registry. The adapter reads Gitea webhook data through the runner's `GITHUB_*` compatibility variables. Local checks do not satisfy the migration gate.
 
 ## Domain and design references