First-party image pull verification does not block an unsigned first-party image

🤖 Generated by the Agentic Engineer

Evidence

talos/cluster/verify-first-party-images.yaml ends with a catch-all rule over ghcr.io/devantler-tech/* that requires a keyless cosign signature issued by the shared publish-app.yaml workflow. Any image matching a rule but failing verification is supposed to be blocked at the containerd pull layer.

The public first-party package doggy-countdown is currently deployed from this org and carries no cosign signature at all. Read anonymously from GHCR (the package is public, so no credentials were involved):

the image manifest for the running digest resolves — HTTP 200;
the cosign signature tag for that same digest — HTTP 404;
the repository's tag listing contains a sha256-<digest> referrer-style tag (an actions/attest artifact, artifactType: application/vnd.oci.empty.v1+json) but no sha256-<digest>.sig entry.

So the artifact has attestations and no signature. Despite that, the workload is running, and one of its replicas is on a node that was provisioned after the image was published — meaning a fresh pull of an unsigned first-party image succeeded on a node that had no cached copy.

Why it matters

This is the node-pull layer — the control that decides whether image bytes may run at all, and the backstop beneath the Kyverno admission layer. Two readings, and both are worth knowing:

The rule is not being enforced as believed. Then every conclusion drawn from "first-party images are signature-gated at pull" is unfounded, and the control is providing assurance it does not deliver.
The rule is enforced and this image is an exception for some reason not visible in the file. Then the reason is undocumented, and the next person to reason about this policy will reach the wrong conclusion too.

Either way the file and reality disagree, and the file is what people are trusting.

There is also a latent availability edge: if enforcement is working and this image simply predates it on the nodes that hold it, then the next node to pull it fresh gets ImagePullBackOff. The in-file comment records exactly that failure mode happening once before.

Scope note — this blocks tightening

#2815 proposes narrowing these same matchers. That work assumes the current rules are enforcing and that every running first-party image satisfies them. This finding contradicts that assumption for at least one image family, so #2815's evidence step should establish enforcement state first — narrowing a rule that is not enforcing changes nothing except the confidence people place in it.

Acceptance criteria

Determine, from the live machine configuration rather than from the repository, whether ImageVerificationConfig is active on nodes and which rules it carries.
Explain why an unsigned first-party image pulls successfully today.
Either the image family becomes signed by the expected workflow, or the rule is amended to describe what is actually true — with the reason recorded in the file.
A signal exists that would catch this disagreeing again, rather than it being found by hand.

Rough size: S–M (mostly investigation).

🔗 Related PRs

#2382 - fix(policies): accept the provider publish-workflow cosign identity in verify-app-images [merged]
#2416 - fix(talos): trust provider-upjet-* publish-provider-package.yml signing identity [merged]
#2429 - fix(policy): trust the actions publish-app identity for app-image verification [merged]
#2457 - fix(talos): accept the actions publish-app identity at node image verification [merged]
#2633 - fix(deploy): verify incoming image on Talos nodes [merged]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

🤖 Generated by the Agentic Engineer

Re-checked the premise 13 days on — it holds, but my probe needs a positive control before anyone acts on it

Not claiming this issue; this is a read-only revalidation so whoever picks it up starts from current
facts rather than 07-29 ones.

doggy-countdown is still unsigned by this issue's own method. Anonymous GHCR read, 2026-08-11:
latest resolves to sha256:6a4285ef…, and the corresponding sha256-6a4285ef….sig tag returns
HTTP 404. So the disagreement between talos/cluster/verify-first-party-images.yaml and reality
has not closed on its own.

But the same probe returns 404 for ksail too, and that is the part worth flagging. Two readings,
and I could not separate them:

the finding is wider than one image family — other first-party packages are unsigned as well; or
the probe is wrong — cosign signatures for these packages are not stored as .sig sibling tags
(the referrers API and actions/attest artifacts are both in play here, and this issue already
records seeing a referrer-style tag on doggy-countdown).

I have no image I know to be signed by publish-app.yaml returning HTTP 200, so I cannot tell a
genuinely unsigned image from a probe looking in the wrong place. A 404 with no positive control is a
claim about the probe, not about the artifact.

Suggested addition to the acceptance criteria: establish a positive control first — one image
whose signature this method does find — and record it in the issue. Every later measurement here,
including the "is it signed now" check that closes this issue, is uninterpretable without it. That is
cheap and it protects the criterion 3 decision (sign the family vs. amend the rule) from being made
on a measurement artifact.

Criterion 1 still needs the live Talos ImageVerificationConfig read, which I did not attempt.

🤖 Generated by the Agentic Engineer

Evidence refreshed 2026-08-11 — the finding still holds, and one of its supporting arguments needs correcting

The image is still unsigned. Read anonymously from GHCR today (public package, no credentials):

latest resolves to sha256:6a4285efcbdae0a8d69867ca92378cc5bb7547a621afe47ce1a96f90c33603d0
the cosign signature tag sha256-6a4285ef….sig → HTTP 404
the OCI referrers API for that digest → empty

That exact digest is what is running. Both replicas report
imageID=ghcr.io/devantler-tech/doggy-countdown@sha256:6a4285ef…, on prod-worker-1 and autoscale-cx33-27e0aeaa0c6be36.

Correction: the "node provisioned after the image" argument does not hold — but the conclusion is stronger without it

The original evidence argued that one replica sits on a node provisioned after the image was published. Checked directly, that is not true of any current node:

Node	Created
`prod-worker-1`	2026-06-16T07:00:30Z
`autoscale-cx33-12ac9ae5b0b9effe`	2026-06-30T18:21:10Z
`autoscale-cx33-27e0aeaa0c6be36`	2026-06-30T18:24:52Z
`autoscale-cx43-d63a60203d535b1`	2026-07-17T00:19:54Z

Every node predates the image, whose config blob records created: 2026-07-26T17:06:19Z.

That inverts the argument in a way that makes it stronger, not weaker. The original framing invited the rebuttal "the other nodes just have it cached from before enforcement". They cannot: the digest did not exist until 2026-07-26, so every node now running it necessarily pulled it fresh after that date. A warm containerd cache cannot explain any of these pulls.

And the rule predates the pull: talos/cluster/verify-first-party-images.yaml has been at this path since 2026-07-06 (4ee654ab), with the cosign subject pinning tightened on 2026-08-05 (a8e6404c) and 2026-08-10 (2126815b). doggy-countdown matches no earlier rule, so it falls to the ghcr.io/devantler-tech/* catch-all requiring a keyless publish-app.yaml signature — which it does not have.

So the disagreement is real and current: an image that matches a rule, fails that rule, and runs anyway.

What remains unverified — and why

Acceptance criterion 1 asks for the live machine configuration rather than the repository. I could not satisfy it: talosctl is not installed on the agent host (~/.talos/clusters exists, but the binary does not), so I could not read whether ImageVerificationConfig is actually active on the nodes or which rules it carries.

That is the one question that discriminates between the issue's two readings, and I am deliberately not guessing at it. The likeliest mechanism worth testing first is that the patch reaches nodes only through a Talos cluster update, so the config on disk may lag the repository — but that is a hypothesis, not a finding, and ksail.prod.yaml does not reference this file explicitly (whether KSail auto-discovers talos/cluster/ was not confirmed here).

Next step for whoever picks this up: install talosctl on the runner and read the applied ImageVerificationConfig from a node — ideally prod-worker-1 and one autoscaler node, since a divergence between them would itself be the answer.

Leaving this unassigned; the remaining work is gated on tooling I do not have rather than on analysis.

🤖 Generated by the Agentic Engineer

Acceptance criterion 1 answered — read from the live machine configuration

talosctl is now available on the runner, so I could do the read that was blocked earlier. The ImageVerificationConfig IS active on the nodes, and it carries the current rules.

talosctl get imageverificationrules on both nodes hosting the workload — prod-worker-1 (10.0.1.4) and the autoscaler node autoscale-cx33-27e0aeaa0c6be36 (10.0.1.11) — returns identical output:

ID	Pattern	skip	deny
0000	`ghcr.io/devantler-tech/ksail*`	false	false
0001	`ghcr.io/devantler-tech/provider-upjet-*`	false	false
0002	`ghcr.io/devantler-tech/*`	false	false

There is no node divergence — the hypothesis that the autoscaler node might be missing the config is refuted, even though it runs an older Talos (v1.13.4 vs v1.13.7 on the static nodes).

Rule 0002 — the one doggy-countdown falls to — carries the current, tightened verifier, matching main after 2126815b:

imagePattern: ghcr.io/devantler-tech/*
skip: false
deny: false
keylessVerifier:
    issuer: https://token.actions.githubusercontent.com
    subjectRegex: ^https://github\.com/devantler-tech/actions/\.github/workflows/publish-app\.yaml@[0-9a-f]{40}$

And containerd has the verifier plugin loaded: io.containerd.image-verifier.v1.bindir — loading plugin.

So this is not the "rule is not deployed" reading. The config on the nodes and the file in the repository agree. The disagreement is between the config and observed behaviour.

A hypothesis I tested and discarded — do not reuse it

The rule resources report created: 2026-08-11T15:14:53Z, which looks like "the rules only landed minutes ago". That reading is wrong. nodename (15:14:53Z) and imagecacheconfigs (15:14:39Z) carry the same stamp, and machinestatus shows the node entering running at 15:14:39Z — the node had just rebooted under the in-flight cluster update. Talos resource created timestamps reset on every config reload, so they say nothing about when a rule first reached a node. Recording this so the next investigation does not spend the same effort or draw the false conclusion.

Where that leaves the "why"

The remaining explanation consistent with all the evidence is that verification happens at pull time only, and the pull already happened. The running pods have not re-pulled since enforcement reached these nodes, and containerd serves the cached image. That is consistent with the in-file comment recording an ImagePullBackOff the one time a fresh pull did hit the rule.

I am labelling that a hypothesis, not a finding — proving it needs a fresh pull of the unsigned digest on one of these nodes, which is a cluster mutation I must not perform. What would settle it without a mutation is the first natural reschedule of this workload onto a node with a cold cache: under these rules it should fail with ImagePullBackOff.

Updated criteria status

1 — ImageVerificationConfig is active on nodes; all three rules present, current subject pinning, no divergence between static and autoscaler nodes.
[~] 2 — narrowed to the pull-time/cache hypothesis above; not proven.
3 — unchanged: either doggy-countdown gets signed by publish-app.yaml, or the rule records what is actually true. Signing it is the better fix — it is the only first-party app image not covered, and the rule is correct as written.
4 — no signal exists yet. This is the part worth building: nothing currently reports "a running first-party image does not satisfy the rule that matches it", which is exactly why this went unnoticed.

Still leaving this unassigned. Criterion 3 is a doggy-countdown CI change and criterion 4 is a detection control; they are separable and neither is blocked any more.

🤖 Generated by the Agentic Engineer

Acceptance criteria 1 and 2 are now answered, and the answer is the first of the two readings in the
issue body: the rule is not enforcing. The cache explanation is refuted by direct observation
rather than by inference.

Criterion 1 — the live rules (read from the node, not the repo)

All three rules are present and active on prod-worker-1, carrying the current tightened
subjectRegex values, with skip: false and deny: false. The catch-all is:

# ImageVerificationRules.security.talos.dev, id 0002
spec:
    imagePattern: ghcr.io/devantler-tech/*
    skip: false
    deny: false
    keylessVerifier:
        issuer: https://token.actions.githubusercontent.com
        subjectRegex: ^https://github\.com/devantler-tech/actions/\.github/workflows/publish-app\.yaml@[0-9a-f]{40}$

So the matcher does cover ghcr.io/devantler-tech/doggy-countdown, and nothing is skipping it.

Criterion 2 — why the unsigned image pulls: it just did, on a node with the rule active

The obvious defence was that the image predates enforcement on the nodes holding it and is simply
cached, since containerd verifies at pull. That is now ruled out — the image was pulled fresh from
the registry today, minutes after the rule was confirmed in place:

Time	Event
15:49:52Z	rule `0002` present on `prod-worker-1` (resource stamp; see caveat below)
15:54:57Z	`Pulling image "ghcr.io/devantler-tech/doggy-countdown@sha256:6a4285ef…"`
15:55:00Z	`Successfully pulled image … in 3.021s. Image size: 23108742 bytes`

A Pulling event followed by Successfully pulled … in 3.021s with a byte count is a real registry
fetch. A cache hit reports Container image … already present on machine and emits no Pulling — so
this was not a cached layer being reused. That image carries no cosign signature (the evidence in the
issue body still holds), the active rule requires one, and the pull succeeded anyway.

⚠️ Caveat on the timestamp, so it is not over-read: Talos resource created stamps reset on every
machine-config reload, so 15:49:52Z is the most recent reload, not when the rule was introduced.
It bounds the claim in the direction that matters — the rule was in place before the pull — and the
rules were independently observed active on this node earlier in the day as well.

Conclusion: the pull-layer control is configured as intended and is not blocking an image that
fails it. Any reasoning that treats "first-party images are signature-gated at pull" as an enforced
property is currently unfounded, and #2815's narrowing work should not assume otherwise.

What this leaves

Criterion 2 is answered. Criteria 3 and 4 are unchanged and now separable:

3 — either doggy-countdown starts being signed by the expected workflow, or the rule is
amended to describe what is actually true, with the reason recorded in the file. Given the finding
above, amending the file alone would be recording a control that does not work; the underlying
non-enforcement needs its own answer first (Talos-side behaviour vs. our configuration).
4 — a signal that catches this disagreeing again. Worth noting the shape it needs: this was only
found by pulling node state by hand, and the same class of gap (a control believed active, silently
evaluating nothing) is the one flagged in the Kubescape notes — a check that asserts a known-bad
image is actually refused would catch it, whereas asserting the config exists would not have.

I have not claimed this issue — this is investigation recorded for whoever picks up 3 and 4.

🤖 Generated by the Agentic Engineer

Criterion 3 unblocked: the root cause is ours, and the control has never enforced

Claiming this issue. The previous comment left criterion 3 blocked on a fork — "the underlying
non-enforcement needs its own answer first (Talos-side behaviour vs. our configuration)". That fork
is now resolved, from live node state: it is our node image. The verifier component that would
consume these rules is not installed, so ImageVerificationConfig is producing rules that nothing
reads.

The mechanism

containerd does not verify images itself. It loads an image-verifier plugin, and the only one
present on these nodes is the bindir plugin, which works by executing every binary in a configured
bin_dir. Both containerd instances on prod-worker-1 log it loading and nothing further:

{"id":"io.containerd.image-verifier.v1.bindir","msg":"loading plugin","type":"io.containerd.image-verifier.v1"}

containerd's own documentation states the behaviour for an unconfigured directory verbatim:

If bin_dir does not exist or contains no files, the image verifier does not block image pulls.

That is exactly the state of these nodes.

Evidence, each with its control

Check	Result
`bin_dir` configured?	No. Grep for `verif\|bin_dir\|bindir` across every `/etc/cri/conf.d/*` file and `/etc/containerd/config.toml` returns nothing. The rendered `cri.toml` configures `images`, `runtime` and `nri` only.
`/opt/containerd/image-verifier`	Does not exist — `lstat … no such file or directory`.
`/opt/containerd/bin`, `/opt/containerd/lib`	Both empty (only `.`). Control: `ls -l /opt` on the same node correctly lists `cni` and `containerd`, so the listing does show children when there are any.
Verifier binary anywhere?	None. No entry matching `verif\|cosign\|sigstore\|notation` in `/usr/local/bin`, `/usr/local/lib/containerd`, `/usr/bin`, `/sbin`, `/opt`. Control: `/usr/bin` and `/sbin` enumerate 140 entries each, so the probe reads real directories; `/usr/local/bin` contains exactly one binary, `nsenter`.
Installed system extensions	`iscsi-tools`, `qemu-guest-agent`, `util-linux-tools`, `schematic`. Nothing signature-related.

So the chain is complete and consistent with the observed pull: the rules are correct and active
(criterion 1), no verifier binary exists to evaluate them, containerd's documented response to that
state is to permit the pull, and an unsigned matching image duly pulled fresh and ran (criterion 2).

What this rules out

This is not a rule-authoring error, not first-match-wins ordering, not a stale node
config, and not a containerd cache artifact. Every one of those was a live hypothesis on this
issue at some point. The rules are fine; nothing is reading them.

It also means amending verify-first-party-images.yaml would be the wrong fix. The previous
comment already suspected this — "amending the file alone would be recording a control that does not
work" — and that now has a mechanism behind it. Rewriting the rules to match observed behaviour
would document a control that cannot enforce regardless of what the rules say.

Consequence for #2815

#2815 proposes narrowing these matchers.
Narrowing a rule set that nothing evaluates changes nothing except confidence. #2815 should be
sequenced after enforcement is real, and its evidence step can now be satisfied by pointing here
rather than re-deriving it.

The one thing I could not establish — stated as an open question, not a guess

Which mechanism is supposed to supply the verifier binary. The Talos v1.13
ImageVerificationConfig reference page documents the rule schema — ordering, skip, deny,
keyless and public-key verifiers — but says nothing about what enforces them, whether a system
extension is required, or what bin_dir should be. I am deliberately not asserting "a cosign
extension is missing": I have positive evidence that no verifier is installed and none is wired, and
no evidence about which supported mechanism is meant to install one. That is the next question, and
it decides the shape of the fix (schematic/extension change vs. containerd config vs. both).

Criterion 4 gets a cheaper form as a result

The signal this issue asks for now has an obvious low-cost shape alongside the gold-standard one,
because we know precisely which condition failed:

Liveness — assert the verifier can enforce at all: bin_dir is configured and contains at
least one executable, on every node. This exact check would have caught this on day one, and it is
a plain node read.
Behavioural — assert a known-unsigned first-party image is actually refused. This is the
real proof and stays the target; the liveness check is what makes its absence visible in the
meantime.

Asserting the rules exist would still not have caught this — that was already true and remains the
trap. This is the same failure class as the Kubescape notes: a control believed active while
evaluating nothing, reading identically to a compliant one.

Live re-measurement — the disagreement is still open, and the cause is settled

Re-verified against the cluster today rather than inferred from the repository.

Criterion 1 — is ImageVerificationConfig active on nodes? The rules are present and syntactically valid (talosctl validate passes), but they are not evaluated. scripts/validate-image-verifier-liveness.sh against prod, 2026-08-18:

7 of 7 node(s) cannot enforce image verification.

Every node, on both /etc/cri/conf.d/cri.toml and /etc/containerd/config.toml: no bin_dir in the io.containerd.image-verifier.v1.bindir table.

Criterion 2 — why does an unsigned first-party image pull successfully? Because containerd does not verify images itself. It delegates to that plugin, and its documented behaviour when bin_dir is unset, absent, or empty is to permit the pull. No verifier binary is installed fleet-wide, so the rules below it never run. The image is not an exception to an enforcing rule — there is no enforcement at all. Installing and wiring the verifier is #3101.

The unsigned image is still unsigned. Confirmed anonymously against public GHCR for the digest currently running (doggy-countdown, 2 replicas):

Artifact	Result
image manifest for the running digest	resolves
`sha256-<digest>.sig` (cosign signature)	HTTP 404

So criterion 3's first branch ("the image family becomes signed") is not met.

What this PR does — and deliberately does not do

#3219 takes criterion 3's second branch: it amends the file to describe what is actually true, with the reason recorded in it. Until then the file asserted the opposite — that a matching-but-unverified image is blocked — which is the "the file and reality disagree, and the file is what people are trusting" complaint in this issue's own body.

It does not install the verifier. That is #3101, and it is a node-config rollout rather than a comment change.

A hazard #3101 should know about before it activates

These two findings compose into something neither shows alone: ghcr.io/devantler-tech/doggy-countdown is running, unsigned, and matches the ghcr.io/devantler-tech/* catch-all rule. Enforcement is the only thing currently absent. So the moment #3101 makes the verifier work, that workload's next fresh pull is refused and it goes ImagePullBackOff — the "latent availability edge" this issue predicted, now with a named image.

That wants resolving before activation, not during it: either sign the image family through publish-app.yaml, or scope the rule off it with a recorded reason. I have written the warning into the policy file itself, since that is where the person doing the activation will be looking.

Criteria status

1 — determined from live node state; the config is present, the enforcement path is not.
2 — explained: empty bin_dir ⇒ containerd permits every pull.
3 — addressed by docs(security): record that the node image-verification rules are inert #3219 via the "amend the rule to describe what is true" branch. The signing branch remains open and is the better long-term answer.
4 — a signal exists (validate-image-verifier-liveness.sh + its workflow) but is deliberately dormant: workflow_dispatch only, because it would report red fleet-wide every day while Establish that first-party image signature verification actually enforces on the fleet #3101 is open. Activation is one line, and belongs to Establish that first-party image signature verification actually enforces on the fleet #3101. Worth noting the signal has therefore never run on a schedule — today's run was by hand, which is the same way this issue was found.

chore: agent-claim #2856 nonce=5e634c614a5a211e3b6f78ee5a32345b

🤖 Generated by the Agentic Engineer

Closing — all four acceptance criteria are met

Re-verified live against the prod cluster today (2026-08-19) rather than inferred from the
repository, per this issue's own instruction to determine enforcement state from the live machine
configuration.

Live measurement: scripts/validate-image-verifier-liveness.sh exits 1 —
7 of 7 nodes cannot enforce image verification, on both /etc/cri/conf.d/cri.toml and
/etc/containerd/config.toml. This matches the 2026-08-18 measurement, so the state is unchanged
and the documented status is accurate. (Per-node detail stays in the private operator notes.)

Criteria

Enforcement state determined from live config. The io.containerd.image-verifier.v1.bindir
table carries no bin_dir on any node, so the ImageVerificationConfig rules are never
evaluated.
Why an unsigned first-party image pulls. containerd does not verify images itself; it
delegates to the bindir plugin and, per its documented behaviour, permits the pull when that
directory is unset, absent, or empty. The rules were correct throughout — they were simply
never consulted.
The rule now describes what is actually true. talos/cluster/verify-first-party-images.yaml
leads with a STATUS — THESE RULES ARE INERT ON THIS CLUSTER TODAY block recording the
mechanism, the measurement, and the pre-activation hazard that
ghcr.io/devantler-tech/doggy-countdown is running unsigned and matches the catch-all rule.
A signal exists. scripts/validate-image-verifier-liveness.sh asserts the enforcement
path rather than the configuration — deliberately, since asserting the rules exist would not
have caught this, the rules having been correct the whole time. Its own tests run in ci.yaml's
validate job, which CI - Required Checks depends on, so a regression in the checker blocks a
merge rather than merely reporting.

Why the fleet check is dormant, and why that is not a gap

The fleet sweep is workflow_dispatch-only on purpose. The verifier is absent fleet-wide, so a daily
run would publish RED every day for a condition #3101 already tracks — spending the repository's
"something broke, fix it now" channel on known, open work. Turning on the cadence is one reversible
line, and it belongs with the activation.

What remains, and where

Installing and wiring the verifier is #3101, which also carries the blocker that must be cleared
first: an image matching a rule but failing verification is refused, so doggy-countdown goes
ImagePullBackOff the moment the verifier starts working unless it is signed or the rule is scoped off
it beforehand.

This issue asked what the disagreement was, why it existed, and whether we would notice it again.
All three are answered and recorded, so it closes here; the remaining work is activation, not
investigation.

First-party image pull verification does not block an unsigned first-party image #2856

Description

Evidence

Why it matters

Scope note — this blocks tightening

Acceptance criteria

Activity

coderabbitai commented on Jul 29, 2026

devantler commented on Aug 11, 2026

Re-checked the premise 13 days on — it holds, but my probe needs a positive control before anyone acts on it

devantler commented on Aug 11, 2026

Evidence refreshed 2026-08-11 — the finding still holds, and one of its supporting arguments needs correcting

Correction: the "node provisioned after the image" argument does not hold — but the conclusion is stronger without it

What remains unverified — and why

devantler commented on Aug 11, 2026

Acceptance criterion 1 answered — read from the live machine configuration

A hypothesis I tested and discarded — do not reuse it

Where that leaves the "why"

Updated criteria status

devantler commented on Aug 11, 2026

Criterion 1 — the live rules (read from the node, not the repo)

Criterion 2 — why the unsigned image pulls: it just did, on a node with the rule active

What this leaves

devantler commented on Aug 11, 2026

Criterion 3 unblocked: the root cause is ours, and the control has never enforced

The mechanism

Evidence, each with its control

What this rules out

Consequence for #2815

The one thing I could not establish — stated as an open question, not a guess

Criterion 4 gets a cheaper form as a result

Next

devantler commented on Aug 18, 2026

Live re-measurement — the disagreement is still open, and the cause is settled

What this PR does — and deliberately does not do

A hazard #3101 should know about before it activates

Criteria status

devantler commented on Aug 19, 2026

Closing — all four acceptance criteria are met

Criteria

Why the fleet check is dormant, and why that is not a gap

What remains, and where

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions