#1817 @swamp/container-image@2026.08.25.1 fails to install: upgrades[0] is missing upgradeAttributes (plus: doctor validates the cached bundle, not the source)

@swamp/container-image@2026.08.25.1 cannot be installed: its model declaration fails schema validation, so the model never loads and none of its methods are reachable. The extension is unusable as published.

While reducing this I found a second, independent defect: swamp doctor extensions reports its verdict from the cached bundle rather than from the source on disk, so its answer can disagree with the source in both directions.

Defect 1 — upgrades[0] omits the required upgradeAttributes

.swamp/pulled-extensions/@swamp/container-image/models/container_image.ts:75-80 declares:

upgrades: [
  {
    toVersion: "2026.08.25.1",
    description: "Add privileged and extraArgs inputs to the run method.",
  },
],

The validator requires upgradeAttributes on each entry. It is absent, so validation fails with:

upgrades.0.upgradeAttributes: Invalid input

Repro (clean repo, ~15 seconds)

mkdir ci-probe && cd ci-probe
swamp repo init
swamp extension pull @swamp/container-image

Error: Install partially applied for @swamp/container-image — files extracted but the
catalog write failed (upgrades.0.upgradeAttributes: Invalid input).

swamp doctor extensions then reports:

• model .../models/container_image.ts ValidationFailed: upgrades.0.upgradeAttributes: Invalid input
  @swamp/container-image@2026.08.25.1 [pulled]  1 source(s)
    ValidationFailed: 1
3 passed, 1 failed — OVERALL: FAIL

Confirmed fix

Adding the missing field to that entry makes the extension index cleanly:

upgrades: [
  {
    toVersion: "2026.08.25.1",
    description: "Add privileged and extraArgs inputs to the run method.",
    upgradeAttributes: () => ({}),
  },
],

@swamp/container-image@2026.08.25.1 [pulled]  1 source(s)
  Indexed: 1
4 passed, 0 failed — OVERALL: PASS

So the defect is one missing field in the published package. Note the rm -rf .swamp/bundles in the repro below — without it the fix is invisible, which is defect 2.

Impact

• The extension is unusable as published. Every method (validate, build, run, login, push, multi-platform-build) is unreachable.
• The failure is not recoverable by the user: retrying swamp extension pull re-reports it, and the only workaround is hand-editing vendored source under .swamp/.
• It leaves the repo in a partially-installed state — files extracted, catalog write failed — so swamp doctor extensions reports OVERALL: FAIL and swamp model type search emits Failed to load user model "container_image.ts" on every subsequent invocation until the extension is removed.
• Concrete cost: this is an official @swamp/* extension, and repo rule 1 ("prefer @swamp/* official extensions first") makes it the first candidate for any container work. We were choosing a container mechanism and could not evaluate it at all, so the decision was made against third-party alternatives instead.

Defect 2 — swamp doctor extensions validates the cached bundle, not the source

.swamp/bundles/ is not invalidated when a model source changes. doctor emits a warning about this —

warning swamp·model·loader  Using cached bundle for "container_image.ts" —
                            source may have changed but bundle could not be regenerated

— but it is a warning, not a failure, and the verdict printed underneath follows the stale bundle.

Measured, three states, same repo

Row 3 is the serious one: doctor printed 4 passed, 0 failed — OVERALL: PASS for a source tree that fails validation the moment the cache is cleared.

rm -rf .swamp/bundles before swamp doctor extensions is currently the only way to get a verdict about what is actually on disk.

What I did not measure

I did not check whether the runtime model loader also follows the cached bundle. If it does, doctor is at least self-consistent with execution and this is a staleness/UX problem; if it does not, doctor's verdict and the runtime's behaviour can disagree outright. Worth confirming before deciding severity — I am reporting only what I observed.

Suggested fix

Invalidate a bundle on source-hash change, or make the "could not be regenerated" condition a failure rather than a warning, so doctor never issues a verdict it cannot stand behind.

Environment

• swamp 20260823.200111.0-sha.2e5008d6
• deno 2.9.5, Linux x86_64 (WSL2)
• @swamp/container-image@2026.08.25.1
• Reproduced in a freshly swamp repo init'd directory, so it is not repo-specific state.