feat: split backend-core artifact ci cd

docs/reference/ci.md

@@ -19,6 +19,7 @@ Each commit CI run performs:
 - `git clone` and checkout of the requested repository revision.
 - `bun install --frozen-lockfile` at the repo root and `src/`, because `bun scripts/cli.ts check` compiles all `src/components` and needs the component workspace lockfile for frontend React dependencies.
 - `UNIDESK_D601_RUST_CHECK=1 bun scripts/cli.ts check --full --rust`, so Rust backend-core is checked only inside the D601 CI execution boundary.
+- Backend-core production artifact publication when enabled: build the requested pushed commit on D601, stamp Docker image labels, and push a commit-pinned image to the D601 loopback artifact registry.
 - Temporary `code-queue-ci-read` Deployment and ClusterIP Service in `unidesk-ci`.
 - Code Queue read performance checks against the production PostgreSQL through `d601-tcp-egress-gateway`.
 - Manual dev desired-state smoke for Code Queue via `ci run-dev-e2e`, using the Git-pinned `code-queue` service commit from `origin/master:deploy.json#environments.dev`.
@@ -45,6 +46,21 @@ The temporary Code Queue service uses:
 
 This means the CI service can read existing tasks, Trace summaries, Trace steps and Trace step details from the main database, but it must not schedule, mutate, notify, backfill or become deployment truth.
 
+## Backend-Core Artifact Publication
+
+backend-core production image creation belongs to D601 CI, not to master server CD. The purpose is to keep Rust compilation, Docker build cache, dependency downloads and image push on the higher-resource D601 side while leaving production deployment with a small pull/recreate/verify surface.
+
+The CI artifact task must follow these rules:
+
+- Input revision comes from pushed Git and is resolved to a full 40-character commit. A dirty worktree or unpushed local tree must never be used as the image source.
+- The source checkout, Rust build and Docker build run on D601 CI infrastructure. The master server must not run `cargo build`, `docker compose build backend-core` or `server rebuild backend-core` as part of production backend-core deployment.
+- The image is tagged with the source commit, for example `unidesk/backend-core:<commit>`, and pushed to the D601 artifact registry as `127.0.0.1:5000/unidesk/backend-core:<commit>`.
+- The image must carry at least `unidesk.ai/service-id=backend-core`, `unidesk.ai/source-repo`, `unidesk.ai/source-commit` and `unidesk.ai/dockerfile=src/components/backend-core/Dockerfile`.
+- Publication must fail if the D601 artifact registry is not healthy. It must not fall back to a third-party registry or a mutable `latest` tag.
+- CI may output the image ref and digest as deployment input, but it must not restart production Compose services, call production `deploy apply`, mutate production namespaces, or change `deploy.json`.
+
+The artifact registry contract and CD consumption path are defined in `docs/reference/artifact-registry.md`. CI is the producer of the backend-core image artifact; CD is only the consumer.
+
 ## Dev Namespace E2E
 
 `ci run-dev-e2e` is the manual dev desired-state smoke flow. The single authoritative reference for its Git-controlled runner script, short launcher, result directory and no-CD boundary is `docs/reference/dev-ci-runner.md`.
@@ -83,6 +99,14 @@ Run CI manually for a commit:
 bun scripts/cli.ts ci run --revision <commit>
 ```
 
+Publish a backend-core artifact for production CD:
+
+```bash
+bun scripts/cli.ts ci publish-backend-core --commit <full-sha> --wait-ms 1200000
+```
+
+This command creates the `unidesk-backend-core-artifact-publish` Tekton PipelineRun. It is a CI producer action only: it may build and push `127.0.0.1:5000/unidesk/backend-core:<commit>`, but it must not recreate the master server container. Production deployment is triggered separately with `artifact-registry deploy-backend-core`.
+
 Run the dev namespace e2e harness manually:
 
 ```bash