fix: limit exact version pins to what a project builds from and runs

CHANGELOG.md

@@ -13,6 +13,7 @@ This project follows [Common Changelog](https://common-changelog.org/) and [Sema
 - Write tracker issues and comments for people. Issues open with one to three plain sentences on where they came from, the problem and why it matters, followed by short `###` sections for Definition of Done, Out of Scope, Verification and Risks, leaving out empty ones. Detail only agents need moves into collapsed agent notes below a divider, with fixed labels and no status, dates, assignees or Loaf naming. Comments and Ship's review lead with one to three plain lines. Records link issues natively, write exact moments in UTC, point only to places everyone with tracker access can reach, and keep magic words in PR descriptions and commit messages. The GitHub and Linear skills describe each tracker's syntax, and migrated records keep their source marker in the agent notes instead of a visible line ([#391](https://github.com/levifig/loaf/issues/391)).
 - Ship confirms every Verification box on an issue is ticked before marking it Done or merging a PR that closes it, and does so before the merge because merging can close linked issues automatically; the merge hooks check the same boxes. An open box blocks closing and merging unless a reason from a person with authority over the work is written on it; a reason can defer only a check that cannot run before the merge or that only a person can do, and Ship reports that criterion as deferred rather than proven. Whoever ran a check ticks its box, an agent only after the check ran and its result is recorded; checks only a person can do stay for that person, and Implement hands off with the boxes it ran already ticked. Implement and Ship now declare that bounded body write in the Flow contract ([#392](https://github.com/levifig/loaf/issues/392)).
 - Keep the continuity digest small enough for harnesses to inject it whole. Claude Code saves hook context over 10,000 characters to a file and injects only a 2,000-character preview, and Codex does the same past about 2,500 tokens, so a busy journal reached agents as a preview of one old wrap. The default `loaf journal context`, every SessionStart hook and post-compaction resumption now print a compact digest. Each entry is one line with its date, id and a shortened message, and `loaf journal show <id>` prints it in full. Pagination cursors and empty layers are gone, repeated diagnostics collapse to one line per code, and a layer showing fewer items than it has names a command that lists them. The digest stays under 8,000 bytes; when that is tight, every layer keeps its first items in priority order before any layer gets more, and the digest says how many entries it left out. Each target's injection limit, its source and the date it was checked are recorded in `config/target-capabilities.json`. `--json` and single-`--layer` output are unchanged ([#345](https://github.com/levifig/loaf/issues/345)).
+- Limit exact version pins to what a project builds from and runs: lockfile packages, including declared dev tools, providers, the release toolchain, and base images. Applications and tools installed for people or agents, such as agent CLIs and third-party images a project deploys, follow their own documented upgrade policy, which may be a release channel such as `latest`. Infrastructure guidance and the security review checklist flag a floating version only when no upgrade policy is documented, and the Python Dockerfile example now pins its `uv` image ([#411](https://github.com/levifig/loaf/issues/411)).
 
 ### Fixed
 

content/skills/infrastructure-management/SKILL.md

@@ -27,15 +27,16 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Use multi-stage builds to minimize image size
 - Run containers as non-root user (UID 1000)
 - Include health checks in all services
-- Pin specific image versions (no `:latest`)
+- Pin what the project builds from and runs: lockfile packages, providers, the release toolchain, and base images (a specific version, never `:latest`)
+- Let applications and tools installed for people or agents, including third-party images the project deploys, follow their documented upgrade policy, which may be a release channel such as `latest`
 - Set resource requests AND limits
 - Use `npm ci` / `pip-sync` in CI (not install)
 - Commit lockfiles to version control
 
 ### Never
 
 - Commit secrets to version control
-- Use `:latest` tags in production
+- Build from a `:latest` base image, or deploy a `:latest` image that has no documented upgrade policy
 - Skip security scanning in CI
 - Deploy without rollback capability
 - Store state in containers
@@ -52,15 +53,15 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Check for common issues:
   - Missing resource limits/requests (CPU, memory)
   - Missing liveness/readiness probes
-  - Using `:latest` tag (prefer specific versions)
+  - A `:latest` tag on an image with no documented upgrade policy
   - Privileged containers (security concern)
   - No namespace specified
 - If `kubesec` is available: `kubesec scan {manifest}`
 
 **Dockerfiles:**
 - Check for:
   - Non-root USER specified
-  - Specific image versions (no `:latest`)
+  - Base and build-stage images at a specific version (no `:latest`)
   - HEALTHCHECK instruction
   - No secrets in ENV instructions
   - Using COPY instead of ADD for local files

content/skills/infrastructure-management/references/ci-cd.md

@@ -39,7 +39,8 @@ Key conventions:
 - Tests run with real database services (Postgres 17)
 - Build step only runs on `main` branch
 - Use `npm ci` (not `npm install`) for lockfile fidelity
-- Pin tool versions exactly in lockfiles
+- Pin dependencies exactly through the committed lockfile, including dev tools such as linters that the project declares
+- Tools installed on a machine for people or agents, such as agent CLIs, aren't project dependencies; they follow their own documented upgrade policy
 
 ## Caching Strategies
 

content/skills/python-development/references/deployment.md

@@ -16,7 +16,7 @@ Multi-stage build with uv, non-root user:
 ```dockerfile
 FROM python:3.12-slim as builder
 WORKDIR /build
-COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /usr/local/bin/uv
 COPY pyproject.toml uv.lock ./
 RUN uv sync --frozen --no-dev --no-install-project
 

content/skills/security-compliance/references/security-review.md

@@ -50,7 +50,8 @@ For every PR:
 [ ] Default credentials changed
 [ ] Error messages don't leak internals
 [ ] Security headers configured (X-Content-Type-Options, X-Frame-Options, HSTS, CSP)
-[ ] Dependencies pinned to specific versions
+[ ] Project dependencies pinned to specific versions through a committed lockfile
+[ ] Applications and tools that track a release channel have a documented upgrade policy
 [ ] Dependency scanning in CI
 [ ] Unnecessary features disabled
 ```

dist/amp/skills/infrastructure-management/SKILL.md

@@ -28,15 +28,16 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Use multi-stage builds to minimize image size
 - Run containers as non-root user (UID 1000)
 - Include health checks in all services
-- Pin specific image versions (no `:latest`)
+- Pin what the project builds from and runs: lockfile packages, providers, the release toolchain, and base images (a specific version, never `:latest`)
+- Let applications and tools installed for people or agents, including third-party images the project deploys, follow their documented upgrade policy, which may be a release channel such as `latest`
 - Set resource requests AND limits
 - Use `npm ci` / `pip-sync` in CI (not install)
 - Commit lockfiles to version control
 
 ### Never
 
 - Commit secrets to version control
-- Use `:latest` tags in production
+- Build from a `:latest` base image, or deploy a `:latest` image that has no documented upgrade policy
 - Skip security scanning in CI
 - Deploy without rollback capability
 - Store state in containers
@@ -53,15 +54,15 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Check for common issues:
   - Missing resource limits/requests (CPU, memory)
   - Missing liveness/readiness probes
-  - Using `:latest` tag (prefer specific versions)
+  - A `:latest` tag on an image with no documented upgrade policy
   - Privileged containers (security concern)
   - No namespace specified
 - If `kubesec` is available: `kubesec scan {manifest}`
 
 **Dockerfiles:**
 - Check for:
   - Non-root USER specified
-  - Specific image versions (no `:latest`)
+  - Base and build-stage images at a specific version (no `:latest`)
   - HEALTHCHECK instruction
   - No secrets in ENV instructions
   - Using COPY instead of ADD for local files

dist/amp/skills/infrastructure-management/references/ci-cd.md

@@ -39,7 +39,8 @@ Key conventions:
 - Tests run with real database services (Postgres 17)
 - Build step only runs on `main` branch
 - Use `npm ci` (not `npm install`) for lockfile fidelity
-- Pin tool versions exactly in lockfiles
+- Pin dependencies exactly through the committed lockfile, including dev tools such as linters that the project declares
+- Tools installed on a machine for people or agents, such as agent CLIs, aren't project dependencies; they follow their own documented upgrade policy
 
 ## Caching Strategies
 

dist/amp/skills/python-development/references/deployment.md

@@ -16,7 +16,7 @@ Multi-stage build with uv, non-root user:
 ```dockerfile
 FROM python:3.12-slim as builder
 WORKDIR /build
-COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /usr/local/bin/uv
 COPY pyproject.toml uv.lock ./
 RUN uv sync --frozen --no-dev --no-install-project
 

dist/amp/skills/security-compliance/references/security-review.md

@@ -50,7 +50,8 @@ For every PR:
 [ ] Default credentials changed
 [ ] Error messages don't leak internals
 [ ] Security headers configured (X-Content-Type-Options, X-Frame-Options, HSTS, CSP)
-[ ] Dependencies pinned to specific versions
+[ ] Project dependencies pinned to specific versions through a committed lockfile
+[ ] Applications and tools that track a release channel have a documented upgrade policy
 [ ] Dependency scanning in CI
 [ ] Unnecessary features disabled
 ```

dist/codex/skills/infrastructure-management/SKILL.md

@@ -28,15 +28,16 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Use multi-stage builds to minimize image size
 - Run containers as non-root user (UID 1000)
 - Include health checks in all services
-- Pin specific image versions (no `:latest`)
+- Pin what the project builds from and runs: lockfile packages, providers, the release toolchain, and base images (a specific version, never `:latest`)
+- Let applications and tools installed for people or agents, including third-party images the project deploys, follow their documented upgrade policy, which may be a release channel such as `latest`
 - Set resource requests AND limits
 - Use `npm ci` / `pip-sync` in CI (not install)
 - Commit lockfiles to version control
 
 ### Never
 
 - Commit secrets to version control
-- Use `:latest` tags in production
+- Build from a `:latest` base image, or deploy a `:latest` image that has no documented upgrade policy
 - Skip security scanning in CI
 - Deploy without rollback capability
 - Store state in containers
@@ -53,15 +54,15 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Check for common issues:
   - Missing resource limits/requests (CPU, memory)
   - Missing liveness/readiness probes
-  - Using `:latest` tag (prefer specific versions)
+  - A `:latest` tag on an image with no documented upgrade policy
   - Privileged containers (security concern)
   - No namespace specified
 - If `kubesec` is available: `kubesec scan {manifest}`
 
 **Dockerfiles:**
 - Check for:
   - Non-root USER specified
-  - Specific image versions (no `:latest`)
+  - Base and build-stage images at a specific version (no `:latest`)
   - HEALTHCHECK instruction
   - No secrets in ENV instructions
   - Using COPY instead of ADD for local files

dist/codex/skills/infrastructure-management/references/ci-cd.md

@@ -39,7 +39,8 @@ Key conventions:
 - Tests run with real database services (Postgres 17)
 - Build step only runs on `main` branch
 - Use `npm ci` (not `npm install`) for lockfile fidelity
-- Pin tool versions exactly in lockfiles
+- Pin dependencies exactly through the committed lockfile, including dev tools such as linters that the project declares
+- Tools installed on a machine for people or agents, such as agent CLIs, aren't project dependencies; they follow their own documented upgrade policy
 
 ## Caching Strategies
 

dist/codex/skills/python-development/references/deployment.md

@@ -16,7 +16,7 @@ Multi-stage build with uv, non-root user:
 ```dockerfile
 FROM python:3.12-slim as builder
 WORKDIR /build
-COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /usr/local/bin/uv
 COPY pyproject.toml uv.lock ./
 RUN uv sync --frozen --no-dev --no-install-project
 

dist/codex/skills/security-compliance/references/security-review.md

@@ -50,7 +50,8 @@ For every PR:
 [ ] Default credentials changed
 [ ] Error messages don't leak internals
 [ ] Security headers configured (X-Content-Type-Options, X-Frame-Options, HSTS, CSP)
-[ ] Dependencies pinned to specific versions
+[ ] Project dependencies pinned to specific versions through a committed lockfile
+[ ] Applications and tools that track a release channel have a documented upgrade policy
 [ ] Dependency scanning in CI
 [ ] Unnecessary features disabled
 ```

dist/cursor/skills/infrastructure-management/SKILL.md

@@ -28,15 +28,16 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Use multi-stage builds to minimize image size
 - Run containers as non-root user (UID 1000)
 - Include health checks in all services
-- Pin specific image versions (no `:latest`)
+- Pin what the project builds from and runs: lockfile packages, providers, the release toolchain, and base images (a specific version, never `:latest`)
+- Let applications and tools installed for people or agents, including third-party images the project deploys, follow their documented upgrade policy, which may be a release channel such as `latest`
 - Set resource requests AND limits
 - Use `npm ci` / `pip-sync` in CI (not install)
 - Commit lockfiles to version control
 
 ### Never
 
 - Commit secrets to version control
-- Use `:latest` tags in production
+- Build from a `:latest` base image, or deploy a `:latest` image that has no documented upgrade policy
 - Skip security scanning in CI
 - Deploy without rollback capability
 - Store state in containers
@@ -53,15 +54,15 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Check for common issues:
   - Missing resource limits/requests (CPU, memory)
   - Missing liveness/readiness probes
-  - Using `:latest` tag (prefer specific versions)
+  - A `:latest` tag on an image with no documented upgrade policy
   - Privileged containers (security concern)
   - No namespace specified
 - If `kubesec` is available: `kubesec scan {manifest}`
 
 **Dockerfiles:**
 - Check for:
   - Non-root USER specified
-  - Specific image versions (no `:latest`)
+  - Base and build-stage images at a specific version (no `:latest`)
   - HEALTHCHECK instruction
   - No secrets in ENV instructions
   - Using COPY instead of ADD for local files

dist/cursor/skills/infrastructure-management/references/ci-cd.md

@@ -39,7 +39,8 @@ Key conventions:
 - Tests run with real database services (Postgres 17)
 - Build step only runs on `main` branch
 - Use `npm ci` (not `npm install`) for lockfile fidelity
-- Pin tool versions exactly in lockfiles
+- Pin dependencies exactly through the committed lockfile, including dev tools such as linters that the project declares
+- Tools installed on a machine for people or agents, such as agent CLIs, aren't project dependencies; they follow their own documented upgrade policy
 
 ## Caching Strategies
 

dist/cursor/skills/python-development/references/deployment.md

@@ -16,7 +16,7 @@ Multi-stage build with uv, non-root user:
 ```dockerfile
 FROM python:3.12-slim as builder
 WORKDIR /build
-COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /usr/local/bin/uv
 COPY pyproject.toml uv.lock ./
 RUN uv sync --frozen --no-dev --no-install-project
 

dist/cursor/skills/security-compliance/references/security-review.md

@@ -50,7 +50,8 @@ For every PR:
 [ ] Default credentials changed
 [ ] Error messages don't leak internals
 [ ] Security headers configured (X-Content-Type-Options, X-Frame-Options, HSTS, CSP)
-[ ] Dependencies pinned to specific versions
+[ ] Project dependencies pinned to specific versions through a committed lockfile
+[ ] Applications and tools that track a release channel have a documented upgrade policy
 [ ] Dependency scanning in CI
 [ ] Unnecessary features disabled
 ```

dist/opencode/skills/infrastructure-management/SKILL.md

@@ -28,15 +28,16 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Use multi-stage builds to minimize image size
 - Run containers as non-root user (UID 1000)
 - Include health checks in all services
-- Pin specific image versions (no `:latest`)
+- Pin what the project builds from and runs: lockfile packages, providers, the release toolchain, and base images (a specific version, never `:latest`)
+- Let applications and tools installed for people or agents, including third-party images the project deploys, follow their documented upgrade policy, which may be a release channel such as `latest`
 - Set resource requests AND limits
 - Use `npm ci` / `pip-sync` in CI (not install)
 - Commit lockfiles to version control
 
 ### Never
 
 - Commit secrets to version control
-- Use `:latest` tags in production
+- Build from a `:latest` base image, or deploy a `:latest` image that has no documented upgrade policy
 - Skip security scanning in CI
 - Deploy without rollback capability
 - Store state in containers
@@ -53,15 +54,15 @@ Infrastructure patterns for containerization, orchestration, CI/CD pipelines, an
 - Check for common issues:
   - Missing resource limits/requests (CPU, memory)
   - Missing liveness/readiness probes
-  - Using `:latest` tag (prefer specific versions)
+  - A `:latest` tag on an image with no documented upgrade policy
   - Privileged containers (security concern)
   - No namespace specified
 - If `kubesec` is available: `kubesec scan {manifest}`
 
 **Dockerfiles:**
 - Check for:
   - Non-root USER specified
-  - Specific image versions (no `:latest`)
+  - Base and build-stage images at a specific version (no `:latest`)
   - HEALTHCHECK instruction
   - No secrets in ENV instructions
   - Using COPY instead of ADD for local files

dist/opencode/skills/infrastructure-management/references/ci-cd.md

@@ -39,7 +39,8 @@ Key conventions:
 - Tests run with real database services (Postgres 17)
 - Build step only runs on `main` branch
 - Use `npm ci` (not `npm install`) for lockfile fidelity
-- Pin tool versions exactly in lockfiles
+- Pin dependencies exactly through the committed lockfile, including dev tools such as linters that the project declares
+- Tools installed on a machine for people or agents, such as agent CLIs, aren't project dependencies; they follow their own documented upgrade policy
 
 ## Caching Strategies
 

dist/opencode/skills/python-development/references/deployment.md

@@ -16,7 +16,7 @@ Multi-stage build with uv, non-root user:
 ```dockerfile
 FROM python:3.12-slim as builder
 WORKDIR /build
-COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.13.4 /uv /usr/local/bin/uv
 COPY pyproject.toml uv.lock ./
 RUN uv sync --frozen --no-dev --no-install-project
 

dist/opencode/skills/security-compliance/references/security-review.md

@@ -50,7 +50,8 @@ For every PR:
 [ ] Default credentials changed
 [ ] Error messages don't leak internals
 [ ] Security headers configured (X-Content-Type-Options, X-Frame-Options, HSTS, CSP)
-[ ] Dependencies pinned to specific versions
+[ ] Project dependencies pinned to specific versions through a committed lockfile
+[ ] Applications and tools that track a release channel have a documented upgrade policy
 [ ] Dependency scanning in CI
 [ ] Unnecessary features disabled
 ```