Issue 113 resolved by the repin, and what issue 064 did not cover #108

2026-09-24T22:55:30Z

jschoubben commented

2026-09-24 22:55:30 +00:00

The object-store module was repinned to a maintained fork of the withdrawn server image, its runtime sidecar built rather than pulled, and its data moved off the predecessor's live directory. The report's status: and fixed-by: now say so.

A resolved status should not imply the general points are closed, so What was done states plainly that the instance is answered and the three standing points are not: the mesh still cannot say which of its other pinned third-party images remain obtainable, and would still learn of a withdrawal only when a node without the image tried to deploy. The replacement question is carried by research 015; the detection question is carried by nothing, and is the first open question.

Also folds in the one thing a duplicate report of this symptom had that this one did not: issue 064 asked whether the build environment can reach a declared vendor image, and assumed that once declared it stays fetchable. Withdrawal is the case that assumption does not cover.

The duplicate itself is not merged — it carried the token evidence (actions: [], $disabled) that this report's 01-diagnosis.md retracts in full.

Checks: cycle 265 documents, the chain holds; records 97, all passed; index current.

The object-store module was repinned to a maintained fork of the withdrawn server image, its runtime sidecar built rather than pulled, and its data moved off the predecessor's live directory. The report's `status:` and `fixed-by:` now say so. A resolved status should not imply the general points are closed, so **What was done** states plainly that the instance is answered and the three standing points are not: the mesh still cannot say which of its other pinned third-party images remain obtainable, and would still learn of a withdrawal only when a node without the image tried to deploy. The replacement question is carried by research 015; the detection question is carried by nothing, and is the first open question. Also folds in the one thing a duplicate report of this symptom had that this one did not: issue 064 asked whether the build environment can **reach** a declared vendor image, and assumed that once declared it stays fetchable. Withdrawal is the case that assumption does not cover. The duplicate itself is not merged — it carried the token evidence (`actions: []`, `$disabled`) that this report's `01-diagnosis.md` retracts in full. Checks: cycle 265 documents, the chain holds; records 97, all passed; index current.

jschoubben added 1 commit 2026-09-24 22:55:31 +00:00

Issue 113 resolved by the repin, and what issue 064 did not cover ab7d216fc6

The object-store module was repinned to a maintained fork of the withdrawn server image, its
runtime sidecar built rather than pulled, and its data moved off the predecessor's live
directory. The instance is closed; the three general points the report makes are not, and What
was done says so rather than letting a resolved status imply otherwise.

Folds in the one thing a duplicate report of this symptom had that this one did not: issue 064
asked whether the build environment can reach a declared vendor image and assumed that, once
declared, it stays fetchable. Withdrawal is the case that assumption does not cover. The
duplicate is not merged — it carried the reading this report's diagnosis retracts.

jschoubben merged commit 77934991c4 into main

2026-09-26 12:13:52 +00:00

jschoubben deleted branch issue/113-record-the-repin-and-fold-114

2026-09-26 12:13:53 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#108