feat(009): pin the Deployment to the fleet placement-enablers image

[bartekus]

Digest f9fa57c9 (tag 676b642, the PR #65 merge): the deploy-chosen container port and the FLEET_IMAGE_PULL_SECRET consumer enter production.

• The fleet_app port ALTER (BIGINT NOT NULL DEFAULT 4000) was applied to the live database before this pin (verified with \d "fleet_app"), so no ordering window exists.
• FLEET_IMAGE_PULL_SECRET=ghcr-pull is plain-env config that landed on the Deployment in feat(006): deploy-chosen container port + FLEET_IMAGE_PULL_SECRET wiring #65; this digest is the first image whose code reads it.
• The digest change rolls the pod by itself (Recreate strategy); no pod delete is needed.
• Spec 009 carries the third-pin amendment; derived shards regenerated; couple clean.

[github-actions]

AI Code Review

Code Review

Spec Coupling

The spec was edited, .derived/ shards were regenerated (both spec-registry and codebase-index hashes updated), and the deployment manifest moved atomically with its owning spec amendment. Coupling looks clean.

Security

FLEET_IMAGE_PULL_SECRET classification — The spec amendment explicitly justifies passing this as plain env ("a resource name, not a secret value"). That's defensible for a K8s imagePullSecret name, but the env var name itself is misleading and could cause future maintainers to treat it incorrectly in either direction: leaking the actual secret content into plain env, or unnecessarily encrypting a resource name. Consider renaming to FLEET_IMAGE_PULL_SECRET_NAME to make the type unambiguous, and document in section 4.4 what values are valid (must match a pre-existing K8s Secret of type kubernetes.io/dockerconfigjson).

Logic / Correctness

imagePullPolicy: IfNotPresent with a digest pin — Correct: the digest uniquely identifies the layer set, so IfNotPresent won't silently serve stale content. No issue.

"No pod delete needed" assertion — True for a Recreate strategy (K8s terminates and restarts on spec change), but this assumes Recreate is already set in the Deployment. The diff doesn't show the strategy field; if it's absent, K8s defaults to RollingUpdate, which could result in two revisions of the image running simultaneously during rollout. Confirm strategy.type: Recreate is present in the full manifest.

.derived/ Hygiene

Cannot verify the shard hashes are correct without running spec-spine compile && spec-spine index, but the shape of the changes (both hashes updated, amendment appears in the registry JSON) is consistent with a proper regeneration rather than a hand-edit.

Minor

The spec amendment abbreviates the image digest as f9fa57c9 (8 chars) while the manifest carries the full 64-char sha256. This is fine for prose but the truncation is 8 hex chars = 32 bits, which is tight for collision resistance in a human-readable reference if the registry ever serves adversarially crafted images. Not a practical concern here, but worth being consistent with at least 12–16 chars in future amendments.

---

Automated review by Claude. Diff size: 35 lines.

[bartekus]

AI review acknowledgment: merging

• Rename to FLEET_IMAGE_PULL_SECRET_NAME: declined as churn. The name is spec 006 §3 vocabulary consumed by fleet/config.ts since the fleet landed; its docstring, the Deployment comment, the catalog entry, and spec 009 §4.4 all now state the name-not-credential semantics in place. Renaming would touch code, image, catalog, .env, and specs to remove an ambiguity those four surfaces already resolve.
• strategy.type: Recreate: present in the full manifest (deployment.yaml spec.strategy.type: Recreate, with the single-replica rationale comment); the "no pod delete needed" claim is sound.
• Digest truncation in prose: the 8-char form follows the existing pin-amendment precedent; the manifest carries the full sha256, which is what deploys. Noted for future amendments.