v2.0.0

This section is prepared for the authorized stable v2.0.0 Release. The exact-tag
release workflow may publish it only with make_latest=false; v1.4.4 remains
GitHub latest. All child tickets through Issue #31 are closed and the #31 final readiness
proof is an executable, non-publishing verify release profile whose
final v2-readiness-report check validates the checked-in evidence map against
the live manifest. BC-1 through BC-10 are the approved compatibility migration
rows; their complete field-level old/new/action/machine/rollback matrix
is part of this release contract. Verification is non-mutating and does not publish
a tag or release. Only the official exact-tag release workflow may
publish after every source release blocker, migration review, pinned provenance
check, rollback rehearsal, native CI gate, and independent review passes.

Pinned release provenance

• The updater contract requires automatic and manual same-major updates,
  explicitly authorized major migrations, and installer replacements to carry both the selected
  SHA-256 digest and keyless provenance for the exact downloaded asset.
• Provenance is pinned to Cd1s/ssm, the reviewed release workflow identity,
  GitHub Actions' OIDC issuer, the supported six-target manifest, and the
  reviewed identity-rotation state. Missing, malformed, unverifiable,
  wrong-subject, or expired provenance leaves the existing executable intact.
• The official release build publishes one adjacent Sigstore bundle per binary.
  Checksums remain an independent digest input but cannot authorize replacement alone.
• Redirected and unknown-length release responses are streamed through exact
  1 MiB metadata/provenance, 16 KiB checksum, and 64 MiB binary ceilings.
• The installer uses a same-directory staging template accepted by both
  GNU and macOS/BSD mktemp. Windows self-update renames the mapped old image
  aside under an exclusive same-directory update lock, installs the
  identity-checked sibling stage synchronously, and rolls back bytes and
  security on failure. Ordinary users preserve and verify owner, primary
  group, DACL, and DACL inheritance; tokens that can enable all three Windows
  backup/restore/security privileges also preserve the complete descriptor.
  A later launch removes only an identity-bound completed rollback image.
• On a trust failure, keep using the preserved executable and wait for a
  repaired release through a reviewed identity. Installer users need a current
  GitHub CLI with attestation verification and head -c; there is no
  verification skip.

Reviewed saved-key publication

• The v2 publication preflight rejects unsatisfied cross-alias saved-key
  create, replace, rename, delete, prune, and reference prerequisites before
  any sync request.
• The safe failure message lists every required stable transaction ID in
  ledger order with alias, operation, key name, and reason. Publish those IDs
  explicitly in order, then retry the original transaction; SSM never adds
  prerequisites or unrelated pending mutations to the selected scope.
• Modern direct and request-v1 host mutations retain their existing encrypted
  vault/ledger schema, transaction ID format, and typed success fields. Legacy
  remove, saved-key removal, and guarded import now append pending transactions
  without automatic publication.
• A state-changing host mutation returns a stable transaction_id. An
  idempotent update/upsert can instead return changed:false,
  action:"unchanged", with transaction_id omitted; it creates no new
  transaction, so do not publish it.

Exact push scopes and empty-ledger safety

• Bare push is invalid and is rejected before vault unlock or any sync HTTP
  request. Callers must choose sshctl --json push --only <transaction-id> or
  sshctl --json push --all.
• sshctl --json push --all publishes only the invocation-start ordered pending-ID snapshot;
  later transactions remain pending.
• An empty push --all performs one identity HEAD and no GET or PUT. Identical
  local, cached, and remote encrypted-blob identities return action:"noop";
  any missing or different identity returns a safe sync_conflict, preserves
  both blobs and private identity evidence, and never publishes a full blob.
• English, Chinese, agent-skill, command-help, and recovery guidance now use
  only explicit publication scopes.
• The empty-ledger sync_conflict hint recommends the guarded --merge
  recovery path. It does not suggest --replace --yes; the longer recovery
  guide permits replacement only after explicit full-replacement review.

Complete v2 compatibility migration

• BC-1: a present malformed or unreadable cloud.json is a fatal
  sync_config_error for every online inventory operation. Missing remains
  unconfigured; explicit global --offline alone accepts cached state and
  performs no cloud parsing or network access.
• BC-2: exact scoped publication preflights transitive alias and saved-key
  prerequisites without automatically adding them. Publish the listed stable
  IDs explicitly in ledger order.
• BC-3: stream startup and terminal failures use compact NDJSON from the
  first byte. After initialization, each consumed non-empty input line has one
  ordered result; no ready, summary, or footer record is emitted.
• BC-4: state-changing inventory entry points, including legacy remove,
  saved-key removal, and guarded import, create stable pending transactions and
  never auto-publish. A preserved idempotent host no-op has changed:false,
  action:"unchanged", omits transaction_id, and creates no transaction.
• BC-5: bare push is invalid, non-empty --all fixes its ordered scope at
  invocation start, and empty --all never performs a PUT.
• BC-6: online streams require a positive refresh interval. Zero refresh
  is valid only with explicit global offline mode and one fixed cached
  snapshot.
• BC-7: direct and request-v1 file/directory put/get results have matching
  direction, kind, and stage. Directory operations report
  atomic:false, integrity:not_available, and resume:unsupported;
  directory get omits bytes_received rather than inventing a tar byte count.
• BC-8: automatic and ordinary manual replacement remains within the
  installed major. ssm update --major reviews the migration and
  ssm update --major --yes is the sole non-interactive major authorization.
• BC-9: checksums cannot authorize replacement without pinned keyless
  provenance and the exact 14-name release manifest.
• BC-10: make check is the non-mutating go run ./cmd/verify ci adapter;
  verify release is a non-publishing strict superset.

The completed issues #2 through #11 remain preserved baselines rather than new
v2 features: non-interactive execution, scoped transactions, stable machine
errors, explicit offline/freshness, exact alias and host-key handling,
observable/resumable transfers, agent-safe invocation, and pre-unlock help all
remain compatible.

Migration and rollback

• Back up the encrypted vault, remote.etag, publishing-intent.json,
  sync-conflict.json, pending ID order, and authenticated executable-recovery
  state without exposing their contents.
• Run ssm --json update --major first. Require all automated checks and
  manually review bare-push consumers, zero-refresh online streams, and
  directory-transfer parsers before using --major --yes on a canary.
• Authorization never bypasses digest/provenance verification. A failed trust,
  migration, or replacement gate preserves the old executable and evidence.
• There is no automatic down-migration. Reinstall v1 only when the encrypted
  on-disk state is compatible, no publication/update recovery is outstanding,
  and remote identities and pending transactions have been reconciled. When
  state is uncertain, restore/recover v2 first and do not mutate further.
• Verification does not merge, tag, install, upload, publish artifacts, or
  create a release. Only the official exact-tag workflow can publish after all
  migration, CI, provenance, rollback, and review blockers pass.