docs: adopt manual server deployment

docs/decisions/0001-repository-topology.md

@@ -15,6 +15,5 @@ Use three Git repositories: deployment, Go backend, and SvelteKit frontend. The
 
 - Service changes can run focused CI and then trigger the deployment workflow.
 - Deployment remains the authoritative location for Compose, Nginx, backup/restore, and server automation.
-- A release manifest must record the exact commit SHA of each service; local nested checkouts alone are not sufficient provenance.
+- A server-side release record must capture the exact deployment, backend, and frontend commit SHAs before each build; local nested checkouts alone are not sufficient provenance.
 - Cross-repository contract changes require coordinated, backward-compatible rollout or an explicit release plan.
-

docs/decisions/0002-immutable-cross-repository-releases.md

@@ -1,49 +0,0 @@
-# ADR 0002: Immutable cross-repository releases
-
-- Status: Proposed
-- Date: 2026-08-20
-
-## Context
-
-The deployment repository composes independently owned backend and frontend repositories. A production release must identify one compatible revision of each repository, survive unavailable source forges, and roll back without rebuilding. The Qlockify reference updates nested server checkouts to mutable branches and builds in place. That is useful for a small deployment but makes the deployed inputs dependent on branch movement, server toolchains, and build timing.
-
-Service repositories also need focused CI without gaining independent authority to mutate the shared production server. Backend, frontend, and deployment changes can arrive close together, so direct per-repository SSH deploys would race and could assemble an unreviewed combination.
-
-## Decision
-
-Build each application image once in its owning repository after protected-revision quality gates, publish it to a private OCI registry, and address it in production by immutable digest.
-
-An authenticated backend or frontend event creates a deployment candidate containing its source SHA, image digest, interface/migration compatibility metadata, and provenance references. The event never directly deploys production. The deployment repository is the only release coordinator and serializes production changes under one deployment lock.
-
-Every approved release has a manifest containing the deployment, backend, and frontend SHAs; all image digests; expected migration version; non-secret configuration checksum; provenance/SBOM references; previous release; approval; and health outcome. Production pulls and runs only the digests in that manifest. Server-side source builds, `git reset --hard` synchronization, branch-name deployment, and floating image tags are not permitted.
-
-Migrations run as a one-off candidate-backend command before API/worker replacement. They use an expand/contract compatibility policy. Application rollback selects the previous manifest and never automatically runs a database down migration.
-
-## Alternatives considered
-
-### Qlockify-style server checkout and in-place build
-
-- Pros: simple; already proven on the reference server; no registry required.
-- Cons: mutable inputs, larger server trust/toolchain surface, slow rollback, weak build provenance, and race risk across three repositories.
-- Rejected for production: it cannot prove that a rebuilt server artifact is identical to the CI-tested artifact.
-
-### Let each service repository deploy its own services
-
-- Pros: fast and locally owned.
-- Cons: backend/frontend/deployment workflows can race; no atomic compatibility manifest; migrations and Nginx/config changes cannot be coordinated safely.
-- Rejected: the deployment repository is the approved operational control plane.
-
-### Git submodules
-
-- Pros: a deployment commit can pin service SHAs.
-- Cons: conflicts with ADR 0001 and the approved ignored-checkout topology; still does not guarantee build-once artifacts.
-- Rejected: release manifests provide provenance without merging repository mechanics.
-
-## Consequences
-
-- A private registry and trusted CI runner are release dependencies.
-- Service CI owns testing/building its artifact; deployment CI owns compatibility, production approval, migration orchestration, health gates, and rollback.
-- The server can roll back application images even if the source forge is temporarily unavailable, provided required digests remain in the registry/cache.
-- Production rollout events must coalesce/serialize instead of racing.
-- Registry retention must protect every digest referenced by the active and rollback manifests.
-- Exact Gitea cross-repository event support and runner version remain implementation decisions in the Platform Operations spec.

docs/decisions/0002-manual-server-build-releases.md

@@ -0,0 +1,61 @@
+# ADR 0002: Manual server-build releases
+
+- Status: Accepted
+- Date: 2026-08-20
+
+## Context
+
+The project has three repositories but one small hackathon server. The Qlockify reference already proves a simple operational model: the deployment repository contains ignored backend/frontend checkouts, a trusted operator pulls source on the server, and Docker Compose builds and starts the stack there.
+
+An earlier proposed design used CI/CD, a private image registry, immutable image digests, and cross-repository candidate events. The stakeholder explicitly rejected that complexity for this project. No CI/CD pipeline is needed.
+
+The platform still needs to answer which source is running and how to return to the previous version.
+
+## Decision
+
+Use manual Qlockify-style deployment on the production server.
+
+For a normal release, a trusted deployment user:
+
+1. verifies the exact deployment/backend/frontend repository paths, remotes, branches, and clean working trees;
+2. fetches and fast-forwards each checkout to the latest `origin/main`;
+3. records the exact three resulting Git commit hashes;
+4. builds application images locally with Docker Compose;
+5. runs the dedicated migration and health/smoke checks; and
+6. records the release as active only after validation passes.
+
+Rollback selects the previous release record, checks out its three hashes, rebuilds locally, and repeats the checks. Database down-migration is never automatic; migrations follow expand/contract compatibility.
+
+The deploy flow may adapt Qlockify's `deploy.sh`, but it must not unconditionally `git reset --hard`. A dirty or divergent checkout stops for operator resolution so user changes are not destroyed.
+
+There is no CI/CD workflow, Actions runner, automated cross-repository event, private image registry, or direct automated production mutation.
+
+## Alternatives considered
+
+### CI/CD plus private registry
+
+- Pros: build-once artifacts, automated checks, stronger image provenance.
+- Cons: more services, credentials, runner maintenance, workflow coordination, and implementation effort than the hackathon needs.
+- Rejected: stakeholder chose the simpler manual Qlockify model.
+
+### Per-service manual deployment
+
+- Pros: each repository can be changed independently.
+- Cons: services could be built from incompatible revisions and migration/config changes could race.
+- Rejected: the deployment repository remains the single manual operational entry point.
+
+### Git submodules
+
+- Pros: deployment commits can pin service revisions.
+- Cons: conflicts with accepted ADR 0001 and the Qlockify-style ignored checkout layout.
+- Rejected: server release records provide the required three-hash provenance.
+
+## Consequences
+
+- The trusted deployment user and production server contain the source/build toolchain.
+- Deployment is slower and less artifact-reproducible than build-once registry delivery, but exact Git hashes and build records preserve practical traceability.
+- Source forge availability is required for new deployment and usually for rollback unless the target commits remain locally available.
+- Manual quality commands and health checks are essential because no pipeline enforces them.
+- Dirty/diverged checkout handling must fail safely rather than destroying changes.
+- The server stores active and previous non-secret release records.
+- Any future CI/CD or registry introduction requires a new approved ADR.

docs/decisions/0003-consume-licensed-font-from-frontend.md

@@ -16,7 +16,7 @@ The deployment repository must not duplicate application assets or introduce a s
 
 Treat both files as ordinary frontend-owned build inputs. Frontend CI builds them through the normal frontend context and the immutable frontend image contains the emitted font resource. Deployment consumes only that normal frontend image/build context.
 
-Platform Operations does not create a separate asset-injection path, copy either file into deployment Git, or maintain font-specific credentials. Release provenance is the frontend Git SHA and immutable frontend image digest.
+Platform Operations does not create a separate asset-injection path, copy either file into deployment Git, or maintain font-specific credentials. Release provenance is the recorded frontend Git commit and the local image built from that checkout.
 
 Frontend CI and deployment smoke checks must fail if the required source inputs are absent, the built resource is absent, or the resource is not served with the expected font MIME type. The deployment repository records no second binary or license copy.
 
@@ -42,6 +42,6 @@ Frontend CI and deployment smoke checks must fail if the required source inputs
 
 - Frontend commit `64f5ac2` is the first approved provenance point for the tracked assets.
 - Frontend repository policy and license compliance govern changes to the files.
-- Deployment rollback automatically rolls font output back with the selected frontend image digest.
+- Deployment rollback restores the recorded frontend commit and rebuilds its font output through the normal context.
 - No separate font injection workflow, font-specific deployment secret, or deployment-repository font copy is allowed.
 - Platform smoke tests verify the emitted resource without reading or reproducing the license text.