Add development-gated verified repository file creation

[Wright-Shawn]

Implements the Guard-only development path for #36. Verified native Ledger v4 publications evaluate each create/modify action's own role, allow and deny rules. A create-authorized callback receives an expiring capability whose create_bytes() method exclusively creates one regular file under a held existing workspace parent; it cannot obtain modify capability.

Both WAVEFRAME_GUARD_ACTION_POLICY_DEV=1 and WAVEFRAME_LEDGER_ACTION_POLICY_DEV=1 are required. Standalone new contracts, caller verification flags, downgraded envelopes, injected facts, authority/cache substitutions and operation mismatches fail closed. Historical authorities cannot authorize creation. The original contract is retained and local replay revalidates the full publication through Ledger.

Creation failures preserve the authorization decision. The final local v3 attestation records observed creation and bytes written separately, without content capture or rollback claims. Readers enforce permitted combinations of outer execution state, operation status and fixed error codes: a collision cannot claim creation/writes, and operation success requires successful execution and observed creation. Incomplete snapshots, partial-write failures and zero-byte creation remain valid. Historical v1/v2 evidence and the public API are unchanged.

The review correction adds 34 focused regressions. Both reported contradictions were reproduced before the fix. Rehashed contradictory proofs are now rejected through public validation, validation against the saved record, and saved-attestation loading. The installed-wheel runner also checks both reported cases through public validation and saved loading, alongside real creation, collision, partial-write failure and zero-byte creation.

Exact development dependency commits are verified through installed PEP 610 provenance:

• Compiler: 3b91fcc03c804804b2ace7302f37340a787496d9 (reports 0.4.0).
• Ledger: 54379d9c8044544fc1b8f32109bdfce35c1c6a05 (reports 0.8.0).

All three upstream fixture chains are retained byte-for-byte with source SHA and SHA256SUMS. No upstream validator is copied or bypassed. Development Git requirements remain separate from unchanged published runtime dependencies.

Exact corrected head: 5e41e454ccd54d7dcce34ecacb41b2ea20cf73b1.

Local Windows verification passed: Python 3.10 default suite 1,259 passed / 99 skipped; Python 3.14 opted-in suite 1,339 passed / 19 skipped. The 34 new consistency cases and 50 action-policy cases also passed together on Python 3.10. Fresh Python 3.10 wheel/sdist inspection, Twine, isolated installed-wheel acceptance and pip check passed with the exact dependency provenance above.

All 10 CI jobs passed on the corrected head. Downloaded artifacts from all four development jobs were checked for exact dependency provenance, contradiction rejection and valid zero-byte creation.

Platform	Python	Default passed / skipped	Opt-in passed / skipped	Fresh wheel/sdist, installed acceptance, pip check
Linux	3.10	1,271 / 87	1,351 / 7	passed
Linux	3.14	1,271 / 87	1,351 / 7	passed
Windows	3.10	1,265 / 93	1,345 / 13	passed
Windows	3.14	1,265 / 93	1,345 / 13	passed

The tested PR merge tree matches the corrected implementation head tree: 9f056a516a2e7f8c78af4f8eb4fc491809187b73.

Representative installed-wheel results:

Case	Authorization	Execution	Created	Bytes written
New file	admissible	succeeded	true	27
Exclusive collision	admissible	failed	false	0
Failure after a real prefix write	admissible	failed	true	3
Zero-byte creation	admissible	succeeded	true	0
Denied path	blocked	not_run	false	0

Collisions preserve the existing file and report exclusive_create_collision. Partial-write failures retain the new file and report creation_or_callback_failed; their overall mutation status stays unknown, with observed creation/write facts recorded separately.

Development CI and downloadable artifacts retain JUnit, package digests, installed PEP 610 provenance and local operation evidence, including rehashed_contradictions_rejected and zero_byte_creation. Existing compatibility/package/governance CI checks historical behavior and published dependencies.

Public API: example. Boundary and acceptance commands: documentation.

This PR remains draft and development-only. The real same-device bind-mount test remains unavailable on the Linux CI runners because unprivileged mount namespaces are disabled. Published dependency compatibility, production availability semantics and coordinated Cloud/customer acceptance remain separate gates in Cloud #143. No deletion, rename, macOS, merge, tag, release, publication or Cloud activation is included.

[Wright-Shawn]

Review of exact head 79dc7c9bac912952aa9dea2e8666f9a8191b3ef6: one correction requested before downstream Cloud integration.

P2 — Reject contradictory creation facts in the v3 attestation validator

In guard/sdk/repository_evidence.py, validate_repository_attestation validates individual operation fields and only some relationships to the outer execution state. It checks the successful outer execution case, but does not constrain the collision error or require an operation claiming success to agree with the outer execution.

Two concrete accepted combinations follow directly from the current conditions:

1. Start with a valid collision proof. Set repository_operation.created=true and bytes_written=3, leaving status=failed, error=exclusive_create_collision, and the original failed/admissible/callback-invoked outer state. Recompute only attestation_hash. The current validator accepts a report saying this same attempt both collided and created/wrote a file.
2. Start with a valid successful creation proof. Change the outer state to callback_invoked=false, callback_completed=false, execution_status=not_run, mutation_status=not_performed, mutation_executed=false. Set operation created=false, bytes_written=0, but retain status=succeeded, error=null. Recompute attestation_hash. The validator accepts an operation claiming success without execution or creation.

The record-binding branch checks the original authorization receipt/request/authority, so it does not reject these contradictions either. This is an artifact-consistency issue, not a claim that the mediated execution path currently overwrites files or produces these contradictory collision results. Self-hashing is not a replacement for semantic validation.

A focused reproduction using the existing acceptance helper, with both development opt-ins enabled:

from copy import deepcopy
from guard.runtime.identity import stable_hash
from guard.sdk.local_persistence import validate_execution_attestation
from tools.acceptance.action_policy_creation import run

evidence = run()
bad = deepcopy(evidence["collision"])
bad["repository_operation"].update(created=True, bytes_written=3)
bad["attestation_hash"] = stable_hash(
    {key: value for key, value in bad.items() if key != "attestation_hash"}
)
validate_execution_attestation(bad)  # Must reject; current conditions accept it.

Scope of correction: define and enforce the permitted combinations of outer execution state, operation status, creation/write observations and fixed error codes. Cover the two cases above through both the public validator and saved-attestation loading. Retain valid pre-callback/incomplete/unknown states, zero-byte successful creation, correct collision evidence, and truthful partial-write failure. Do not turn a collision into policy denial or claim rollback. Preserve historical v1/v2 evidence behavior and the current public API. Keep this in PR #45; no upstream implementation or new feature scope is requested.

Independently checked evidence

• All 10 CI jobs passed. I read the four development job logs: Linux default 1,271 passed/53 skipped and opt-in 1,317/7; Windows default 1,265/59 and opt-in 1,311/13, on Python 3.10 and 3.14.
• Logs show fresh wheel/sdist checks, installed-wheel acceptance and pip check succeeded. Installed core/normalizer remain cricore==0.14.0 and cricore-proposal-normalizer==0.2.0.
• The implementation and tested merge commit have the identical tree fce55a8917b1cb4a9a49cf912758d4c674f67902. Four retained development artifacts are associated with this implementation head.
• Source review confirms native v4 public verification, independent action grants/roles, explicit development gates, exclusive filesystem creation, and separate authorization/failure reporting.

This review is source analysis plus live CI/log verification. I did not execute Python or independently unpack the acceptance artifact ZIPs in this session. Please reproduce the finding locally, add focused regression coverage, and return the corrected exact head with CI/package results.

The mount-namespace test remains explicitly unverified. Published dependency compatibility, production availability semantics, and Cloud/customer acceptance remain separate gates in Cloud #143. Keep the PR draft; no merge, release, publication, deletion/rename/macOS work or activation.

[Wright-Shawn]

Re-review at exact corrected head 5e41e454ccd54d7dcce34ecacb41b2ea20cf73b1: the requested creation-attestation consistency correction is resolved; proceed to downstream development.

I reviewed the four-file correction against the previously reviewed 79dc7c9... implementation. CREATION_STATES now constrains outer execution status, operation status and fixed errors together; explicit checks prevent a collision or a not-run operation from claiming creation/writes. Successful operation reports must agree with successful execution and observed creation. The 34 added cases cover both reported contradictions through public validation, record-bound validation and saved loading, while retaining legitimate incomplete/unknown, failure and zero-byte-success states. The installed-wheel runner also exercises both rehashed contradictions and real zero-byte creation.

I independently checked all 10 job conclusions and the four development logs at this head:

• Linux Python 3.10/3.14: default 1,271 passed / 87 skipped; opt-in 1,351 / 7.
• Windows Python 3.10/3.14: default 1,265 / 93; opt-in 1,345 / 13.
• Fresh wheel/sdist and installed-wheel acceptance completed successfully; pip check passed.
• The corrected implementation and tested merge commit share tree 9f056a516a2e7f8c78af4f8eb4fc491809187b73.

This was source/diff and live CI/log verification, not an independent local rerun. I found no remaining blocker in this correction to beginning the Cloud-side development slice.

The real same-device bind-mount/mount-namespace case remains unverified. Production dependencies, the transition from development-only availability, and actual Cloud-connected Guard execution are still separate gates in Cloud #143. Guard's explicit rejection of Cloud clients for this new authority remains intentional: the next Cloud slice will establish authoring/review/native-publication compatibility, with SDK Cloud support coordinated afterward.

Keep this PR draft. This review does not authorize merging, tagging, PyPI publication, hosted activation or additional operation/platform scope.