v1.12.1 — Post-Migration CLI Contract Hardening

[franchoy]

Coldkeep v1.12.1 — Post-Migration CLI Contract Hardening

Coldkeep v1.12.1 is a patch release focused on post-v1.12 CLI contract hardening.

This release tightens selected command validation and automation-facing behavior after the v1.12 engine/catalog boundary migration, while intentionally avoiding new architecture work, storage changes, schema changes, or backend behavior changes.

Highlights

• Added v1.12.1 patch-release planning and validation documentation.
• Rejected selected ignored extra positional arguments.
• Rejected selected empty or whitespace-only flag values where they could broaden scope or fall through into another mode.
• Locked selected boolean flag semantics with regression tests.
• Locked selected --json shorthand compatibility with parity tests.
• Reviewed Codacy/static-analysis state and recorded safe cleanup closure.
• Added final patch release-gate evidence.

CLI contract hardening

v1.12.1 improves validation for selected malformed commands.

The release now rejects selected extra positional arguments for commands such as:

• init
• version
• help
• verify system
• snapshot stats <snapshotID>
• repair ref-counts

It also rejects selected empty or whitespace-only values for flags such as:

• search --name
• search --path
• search --extension
• snapshot list --path
• remove --stored-path
• restore --stored-path
• snapshot create --id

These changes prevent malformed user input from being silently ignored, broadened, or interpreted as a different command mode.

JSON and automation behavior

This release adds parity coverage for selected --json shorthand forms and confirms that they remain equivalent to existing --output json behavior where supported.

Covered examples include:

• list --json
• search --json
• remove --json
• gc --json
• config get <key> --json
• snapshot stats <snapshotID> --json

JSON envelope shape is unchanged.

Boolean flag behavior

v1.12.1 locks selected boolean flag semantics with tests, including explicit false handling and compatibility for bare/true forms where applicable.

This phase was intentionally conservative and did not introduce a broad parser rewrite.

Compatibility

No changes to:

• repository format
• storage format
• database schema
• default backend behavior
• engine/catalog architecture
• packed/legacy storage semantics
• valid command behavior

The only intended behavior changes are that selected malformed command forms now fail earlier with usage errors.

---

This discussion was created from the release v1.12.1 — Post-Migration CLI Contract Hardening.