feat: execute release catalog 3 authorities without development flags

[Wright-Shawn]

Customer outcome

An installed Guard SDK can load a freshly approved catalog 3.0.0 authority and mediate supported create/modify calls on Windows/Linux without development flags, using the existing public APIs. It preserves the same approved identities and truthful decision/operation evidence.

Prerequisite: Ledger #22, accepted review. This is the next SDK step in Cloud release tracker #143. Production Cloud integration/activation follows separately.

Repository, base and dependencies

Work only in Waveframe-Guard. Stack a draft PR on feat/46-native-cloud-connection at 0d678db7c2f4c57de47955b83d2a1d72b01b2b42, targeting that branch. Preserve draft #45/#47 heads.

Candidate client dependencies:

• Ledger 40e0875ee9a973254bb3a4d0c228cad4fdce2bc0 from Waveframe-Labs/Waveframe-Ledger, draft Support Cloud resolution of complete Ledger v2 publication packages #22.
• Compiler ae590dee058d3481e384dea850d5b7d980f533ff from Waveframe-Labs/cricore-contract-compiler, draft fix external agent quickstart diagnostics #8 (metadata 0.5.0).
• Existing compatible CRI-CORE 0.14.0 and Proposal Normalizer 0.2.0; no new implementation there.

Installing these exact dependencies and importing their supplied fixtures is allowed. Do not implement or modify sibling repositories. Runtime package metadata must never contain development Git requirements.

Exact Ledger contract

Read the supplied public API and Guard/Cloud handoff and complete release fixtures.

Binding	Identity	Hash
Catalog	waveframe.coding-agent.repository-change@3.0.0	sha256:bd7fd23eb59b5521ef6780edec0667ce9b7ba9b5738dfa2701a575fb3efce930
Pack	repository-changes@3.0.0	sha256:78783654a8131cb7a6547ee2ed9507e1dced640aebe32d35057c385bb1dc4459
Runtime facts	repository-changes-runtime@3.0.0	sha256:3fcf3af0a61f91a78b171ccd6247db9f0f908e1baf44aa50ece12349c44bb582

Production enforcement point: waveframe.guard.repository-change.v2. Formats remain compiled_authority_contract.v3, authority_bundle.v4, publication_receipt.v4. Their shared format alone does not establish catalog support. Existing catalog-2 bindings and waveframe.guard.repository-change.v2-development remain development-only.

Ledger's public validators reconstruct the whole approved chain. Standalone compiled-authority validation establishes structure/provenance, not human approval; runtime use still requires the complete verified publication pair. Do not treat Ledger's runtime_activation_ready=False as invalid policy or rewrite it to true: the SDK separately verifies support and activation of its local runtime boundary.

Implementation

1. Verify exact generations. Replace blanket v4 development gates with explicit trusted generation checks. Catalog 3, pack 3, runtime 3 and enforcement-point bindings must agree and pass Ledger's complete public validators. Catalog 2 still requires both existing Ledger/Guard opt-ins; unknown/mixed/substituted identities reject. Old dependencies missing the required catalog/validators fail with useful diagnostics and no fallback.

2. Cover cold and warm paths. Audit authority/verifier.py, authority/runtime_facts.py, cached-load integrity, VerifiedRuntimeAuthority, target binding and compiled intake. Register the exact release fact-provider key. Preserve process verification markers, immutable snapshots, lifecycle/cache checks, runtime integrity and substitution rejection. An authority loaded with development flags must stop executing when its required opt-in is removed; catalog 3 must work with both flags absent. Never set flags inside Guard or expose a user-supplied “trust/enable creation” bypass.

3. Connect the actual filesystem boundary. RepositoryWorkspace.bind(...operation="create") currently applies a global development gate. Make supported release creation reachable through the verified SDK authority without weakening authorization or exposing a bypass. Preserve independent action-wide roles and path rules, missing-action/missing-allow denial and same-action deny precedence. Retain one regular new file, an existing parent, exclusive create/no overwrite/no mkdir, workspace identity/containment and existing Windows/Linux protection. Historical modify-only authority must never gain create permission.

4. Keep APIs simple. Use the existing Guard.local(...), Guard.cloud(...), repository_tool(action="create", target="path", return_result=True) and path.create_bytes(...) APIs. No customer catalog selector, release-mode flag, environment workaround or new parallel evaluator. Register support internally from verified authority. Creation through a raw compiled contract alone remains rejected.

5. Preserve evidence and replay. Exercise actual saving, public validation/loading, local attestation, replay and Cloud package serialization with catalog-3 authority. Preserve exact source/approval/authority/receipt, runtime/actor/run identities and original requests. Review wording and saved approvals stay unchanged. A logical allow is separate from the outcome: empty creation succeeds with mutation; collision fails without mutation; known partial write fails with mutation; unknown stays unknown; evaluation-only has no terminal report. Retain Add development-gated verified repository file creation #45's contradictory-proof rejection and feat: connect native Cloud authority preservation and runtime reports #47's automatic report/identity behavior. Neither reporting failure nor timeout may rerun a mutation or imply confirmed preservation.

6. Client-side Cloud compatibility. Exercise Guard.cloud with exact catalog-3 publication responses through HTTP contract tests, including automatic preservation/runtime-report requests, tenant/runtime/lifecycle binding and failure behavior. Validate the full native pair through the existing loader. Do not rewrite server approval or claim a stub proves production Cloud acceptance. The actual Cloud service has not adopted catalog 3 yet.

Dependency and CI adjustment

The current test/dev extras pin Compiler 0.4.0 and conflict with the accepted 0.5.0 candidate. This issue explicitly authorizes changing those test/dev constraints to cricore-contract-compiler>=0.4.0,<0.6.0, with explicit 0.4.0 pins in independent historical-baseline validation and the exact 0.5.0 candidate in new acceptance. Test both supported paths through ordinary resolution; no --no-deps or forced incompatible installs as compatibility evidence.

Update candidate provenance/tests/fixture acquisition to the exact Ledger/Compiler commits above. Preserve original development fixtures and prior acceptance records. Do not overwrite an original compiler/fixture provenance claim; distinguish unchanged retained fixture bytes from their reproduction with the newer candidates.

Keep Guard's temporary package version and runtime Ledger range unchanged in this implementation PR. Final Ledger 0.9.0/Guard version and Ledger[guard] metadata are the coordinated release step. These changed Guard contents must never be published as another 0.18.0.

Extend automatic CI to this stacked base and verify the actual final PR head. Run Windows/Linux × Python 3.10/3.14:

• source and isolated installed-wheel release acceptance with both development flags absent;
• existing historical behavior and explicit catalog-2 development acceptance;
• real allowed create/modify, denied zero callbacks/writes, role/path/action isolation, empty creation, collision, known partial/unknown outcomes, missing parent, supported path/race/alias/escape cases, and unchanged old-authority denial;
• complete-pair validation, stale approval/mixed generations, fresh/cached/warm tampering, runtime-context overrides, saved evidence/replay and Cloud-client faults;
• fresh sdist/wheel, package checks, exact dependency provenance and ordinary pip check.

Required release cases must execute; enumerate legitimate platform/optional skips. Reuse existing focused tests and acceptance helpers where they cover the contract.

Retain the real connected development regression

Keep #47's real-server acceptance against unchanged Cloud 547291b525e2f1d05d92ed65b6058c4ca91588a8 using its original isolated server dependency pins and explicit development flags. The candidate client now uses the Ledger/Compiler commits above; record client and server provenance separately rather than falsely requiring identical commits. The retained catalog-2 wire artifacts/hashes must still agree.

Fetching this exact private Cloud commit into a disposable test-server directory and running it unchanged remains authorized. The existing read-only CLOUD_TEST_READ_TOKEN is already configured; use that secret name, never expose its value. Do not ask for a new credential merely because the next branch is different. Credential skips are not connected passes.

The 23-case connected development regression does not establish production catalog-3 server support. Real catalog-3 Cloud/sandbox/browser acceptance is the next Cloud task.

The unverified real same-device bind-mount/mount-namespace case remains a release gate. Run the existing isolated test if a suitable Linux environment is available; record exact results/environment. Do not weaken containment or count an unavailable case as passed.

Deliverables and boundaries

Return a stacked draft PR, exact head/base, working public local example, release and retained-development fixture provenance, executed CI/package results, sanitized client protocol evidence and a precise Cloud handoff. Include saved proof/receipt identities and explicit operation outcomes.

No merge, tag, PyPI publication, deployment, Cloud implementation/activation, changes to Ledger's approved wording, deletion, rename or macOS. Existing accepted development work remains accepted at its original pins; this task validates the new release bindings.

[Wright-Shawn]

Implemented and reviewed in draft #49 at 473422b1220fa621cb7895d54f1e18e72ffaba58. No blocking implementation finding for this scope. Four final-head source/package/connected jobs passed; the isolated mount case is reported passed, with an existing-log retention follow-up on the PR. Next repository task is Cloud #150 for catalog-3 fresh approval, real service/sandbox/SDK/browser integration. This issue and the PR remain open pending the authorized merge/release process; nothing is published or activated.