Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLI
AssigneesNone

Relationships

#1367 version-drift check (from #236) is a raw string-inequality, false-positives on multi-model manifests and metadata-only bumps

Opened by kitquiet · 7/23/2026

Context

Referencing #236, item 2: "Version drift between manifest.yaml and model exports." That check has since shipped as versionDriftWarnings on swamp extension push --dry-run. Confirmed live today:

"versionDriftWarnings": [
  {
    "check": "version-drift",
    "output": "host_ports.ts: model version \"2026.07.23.9\" differs from manifest version \"2026.07.23.1\" (update the model's version field to align)"
  }
]

Problem

The check is a raw string-inequality between the manifest's package version: and each listed model file's own version: field. Two legitimate cases will false-positive on this:

  1. Multi-model manifests. manifest.yaml's models: field accepts a list. Each model file has its own independent version:, representing that model type's version (what swamp model validate uses for upgrade-path checks) — not the package version. If a release only touches one of several bundled models, the untouched models' versions correctly should NOT move to match the new manifest version. Forcing alignment would make swamp think an unchanged model's schema/behavior changed, risking spurious upgrade prompts for existing instances.

  2. Metadata-only releases. Bumping the manifest version to publish a README fix, with no code change to any model, shouldn't require also bumping that model's version — nothing about its behavior changed.

In both cases the current check will warn, and the fix it suggests ("update the model's version field to align") is actively wrong advice.

Proposed solution

Make the check content-aware instead of a raw equality check:

  • Compute a content hash per model file (swamp already does this for the adversarial-review-report gate's content-hash-bound path — same primitive should be reusable here).
  • Only warn when a model file's content hash changed since its last-published version and its version: field did not move. That's the actual bug this check should catch (an author forgot to bump a model whose code changed) — not "these two numbers merely differ," which is often correct.
  • Optionally pair with a swamp extension version --apply flag that writes the computed next manifest version into manifest.yaml directly (still leaving each model's own version as an explicit per-file, per-author decision, never auto-written).

Alternatives considered

  • Leave as-is and just tell authors to ignore the warning when it's a false positive — works but trains authors to ignore a signal that's sometimes real, defeating the point of having it.
  • Drop model-level versions entirely in favor of the manifest as sole source of truth (mentioned as an alternative in #236) — rejected there already since model-level version drives the upgrade-path mechanism independently of package publishing cadence.

Environment

  • CLI: 20260722.020746.0-sha.5d00afa2
  • Reproduced against a real 1-model manifest (@kitquiet/host-ports) by deliberately desyncing the model's version field and observing the warning fire on swamp extension push --dry-run.
02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

7/23/2026, 5:31:25 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.