Topic · catalog version pinned

Catalog version pinned

Gist

Catalog version pinned is whether proof.yaml names the catalog this binary ships, under the upgrade policy you chose. Proof runs proof audit --check catalog_version_pinned. A Magento catalog version is not that pin. Jama still authors.

proof audit --check catalog_version_pinned

Keep Magento if it already versions a store. Keep Jama if it already authors the shall. Neither one warns when a Proof upgrade ships new obligation classes against a project that never pinned.

Request demo Last silent upgrade vs this stamp

01 · The unpinned binary

A new Proof release can ship new classes. Without a pin, that is silent.

Proof ships its catalog of obligation classes inside the binary. A missing pin still passes. The hop only names a pin that no longer matches.

The check is informational. It runs at spec stage. A project with no project.catalog.version passes, with a note to add a pin if an auditor needs the catalog frozen. A pin that still matches the shipped version under the upgrade policy also passes. A pin that does not match reports fail at warning severity. See catalog completeness for class drift on the catalog you already have. This hop is the version of that catalog, not the four invariants.

Pinning is a YAML block, not a store SKU:

project:
  catalog:
    version: 1.0.0
    upgrade_policy: manual

manual (the default) wants an exact match. auto-patch wants major.minor to match; patch may differ. auto-minor wants major to match; minor and patch may differ. Widening the policy to clear one warning is the same mistake as bumping the pin without reading the delta.

proof catalog version
proof catalog upgrade --check
proof catalog upgrade --diff
proof catalog upgrade --dry-run
proof audit --check catalog_version_pinned

Always read the delta first. proof catalog upgrade --apply rewrites only project.catalog.version in proof.yaml. It preserves comments, key order, and indentation. Commit the pin bump with the baseline obligations the new catalog activates. Do not apply blind. Do not pin to a neighbour version so the hop goes green. A matching string is not a reviewed catalog move.

02 · The exhibit

Same project. A silent upgrade, or this stamp.

The binary moved. The pin did not. Click the tabs.

The row

Ask did CI stay green after the binary bump
Stamp no project.catalog.version
Why missing pin is a pass

Status green

This hop

No pin. Shipped catalog 1.1.0 is in use. New baseline classes can activate without a reviewed bump.

No stamp

The row

Keep the Magento SKU. Keep the npm lock. That is not this hop.

Keep the record

Proof

Ask does pin 1.0.0 still match shipped 1.1.0 under manual
Out catalog version pin "1.0.0" does NOT match shipped 1.1.0 (policy=manual)

Pin mismatch

Same project. A silent upgrade, or this stamp. Click the tabs.

Surface	What they do	What Proof does	What we lose
Magento catalog version	A store catalog SKU.	Warn when `project.catalog.version` no longer matches the shipped catalog under the policy.	We do not version Magento. Bare "catalog version" is that SERP, not this hop.
npm lockfile	Pins package versions in the tree.	Pins the obligation-class catalog inside this binary.	We do not lock npm. A matching lockfile is not a catalog pin.
Jama baseline	The authoring programme. Baselines if you put them there.	A YAML pin the auditor can re-read next to the binary.	Not Jama's V&V. Jama still authors. We have not run a frozen Jama pack.
Catalog completeness	Four invariants on classes, rules, overlays, checklists.	The version of the catalog those classes live in.	Not the four invariants. See catalog completeness.

The teaching graph is still one pin next to one shipped version. Read proof catalog upgrade --diff and --dry-run before you bump. Then pick one of four resolutions. They are alternatives.

proof catalog upgrade --apply
proof catalog upgrade --to 1.0.0 --diff
proof catalog upgrade --to 1.0.0 --apply
proof audit --check catalog_version_pinned --verbose

Accept the shipped catalog and bump the pin when the dry-run delta is understood. Pin to a specific version when the project must stay on a catalog an auditor already reviewed. Loosen upgrade_policy only when the project's stability needs changed, never to clear today's warning. Start pinning if the finding is "no pin configured". The class-drift hop stays on catalog completeness. Jama still authors. Proof vs Jama.

03 · The honest loss

Proof names a pin that no longer matches. It does not freeze the catalog for you.

A green catalog_version_pinned can still mean no pin at all. It is not a proof of the Go. Jama still authors.

Missing pin is a pass. The hop nudges; it does not fail the merge for being unpinned. A mismatch is fail at warning severity, not a hard gate unless you raise the fail level. The hop does not rewrite proof.yaml. It does not run --apply. It does not activate the new classes. It does not prove the Go. We have not scored this pin against a frozen Jama pack, Magento, or npm. The loss is named, not scored.

The four class invariants stay on catalog completeness. The engagement stays on software correctness audit. Jama still authors.

Request demo How the install is bought

04 · Nearby questions

What people type next.

What is catalog version pinned? Same question. Same URL.

Is this catalog completeness? No. Completeness is whether yaml, catalog, rules, and checklists still name the same classes. This hop is the version of that catalog. See catalog completeness.

Is this a Magento catalog version? No. That SERP is a store SKU. The command on this install is proof audit --check catalog_version_pinned.

Does a missing pin fail the merge? No. No pin is a pass. A mismatch warns.

Does the hop bump the pin? No. Read proof catalog upgrade --dry-run, then apply, or pin to a reviewed version.

Can I set auto-minor to silence 1.0.0 vs 1.1.0? That is a standing policy decision, not a way to clear today's warning.

Is Proof a Jama alternative for the catalog? No. Jama still authors. Proof vs Jama.