bug: SwampVersion drops leading zeros from calver time component

[stack72]

The Bug

SwampVersion.create() uses parseInt() to parse the calver components, which strips leading zeros. When toString() reconstructs the version string, the zero-padding is lost.

This means a build at 00:39:01 produces version 20260224.003901.0, but after round-tripping through SwampVersion:

SwampVersion.create("20260224.003901.0")
  → parseInt("003901") = 3901
  → toString() = "20260224.3901.0"  // 💥 4 digits instead of 6

The version written to .swamp.yaml becomes 20260224.3901.0, which fails the UAT regex /^\d{8}\.\d{6}\.\d+$/ expecting exactly 6 digits in the time segment.

Why It Went Unnoticed

Every previous release was built during daytime hours where the HHMMSS component has no leading zeros:

• 234448 (23:44:48) → parseInt → 234448 ✓ (6 digits)
• 170836 (17:08:36) → parseInt → 170836 ✓ (6 digits)
• 150150 (15:01:50) → parseInt → 150150 ✓ (6 digits)

The first release built after midnight was 20260224.003901.0-sha.69631cc7 (00:39:01), and parseInt("003901") = 3901 — only 4 digits. This broke the UAT run.

Root Cause

src/domain/repo/swamp_version.ts lines 56-61:

const major = parseInt(match[1], 10);  // date — always 8 digits, never has leading zeros
const minor = parseInt(match[2], 10);  // time — CAN have leading zeros (00:00:00–09:59:59)
const patch = parseInt(match[3], 10);  // patch — typically "0", no padding issue

And toString() at line 106:

return `${this.major}.${this.minor}.${this.patch}`;
// No zero-padding — "20260224.3901.0" instead of "20260224.003901.0"

Fix

toString() needs to zero-pad the components to preserve the calver format:

toString(): string {
  const major = String(this.major).padStart(8, "0");
  const minor = String(this.minor).padStart(6, "0");
  return `${major}.${minor}.${this.patch}`;
}

Or alternatively, store the raw string segments instead of parsing them as integers.

[stack72]

Fix Plan

Root cause

SwampVersion.create() uses parseInt() to parse version components, which strips leading zeros. toString() then reconstructs from the integer values, losing the original formatting. This is only observable for calver time components with leading zeros (builds between midnight and ~09:59:59).

Constraint

Existing tests assert SwampVersion.create("1.2.3").toString() === "1.2.3". A naive padStart(8, "0") approach would break this by producing "00000001.000002.3". The fix must preserve the original string representation for all input formats — both semver (1.2.3) and calver (20260224.003901.0).

Approach: Store raw string segments alongside integer values

File: src/domain/repo/swamp_version.ts

Add a private rawVersion field that stores the original major.minor.patch string (suffix stripped). Use it in toString() instead of reconstructing from integers.

private constructor(
  readonly major: number,
  readonly minor: number,
  readonly patch: number,
  private readonly rawVersion: string,
) {}

static create(version: string): SwampVersion {
  // ... existing parsing ...
  const rawVersion = `${match[1]}.${match[2]}.${match[3]}`;
  return new SwampVersion(major, minor, patch, rawVersion);
}

toString(): string {
  return this.rawVersion;
}

This preserves exact round-tripping for all formats. Integer fields remain unchanged for compareTo/equals.

Impact analysis

SwampVersion is used in exactly 3 places outside its own file:

1. repo_marker_repository.ts — calls version.toString() to write .swamp.yaml
2. repo_service.ts — calls SwampVersion.create(version) and .toString() for init/upgrade results
3. repo_marker_repository_test.ts — creates versions with "1.0.0" etc., never inspects .major/.minor/.patch

The change is fully encapsulated. No public interface changes. The only observable difference: SwampVersion.create("20260224.003901.0").toString() returns "20260224.003901.0" instead of the broken "20260224.3901.0".

Regression tests

File: src/domain/repo/swamp_version_test.ts

• create("20260224.003901.0").toString() === "20260224.003901.0" (the bug fix)
• create("20260224.003901.0-sha.abc123").toString() === "20260224.003901.0" (suffix stripped, zeros preserved)
• create("20260224.003901.0").minor === 3901 (integer comparison still works)

Verification

1. deno run test src/domain/repo/swamp_version_test.ts — new + existing tests
2. deno check — type checking
3. deno lint && deno fmt — style
4. deno run test — full suite