Expose machine-readable share-safety status in verify output

[danielgwilson]

Summary

mimetic verify --json should expose a machine-readable share-safety result separate from local bundle validity.

Today a run can correctly return ok: true while warning that evidence such as raw screenshots is full-fidelity and local-only. That is honest, but downstream adopters and agents need a first-class field they can gate on without parsing warning prose.

Proposed shape

Add a structured field such as:

"shareSafety": {
  "status": "share_ready | local_only | blocked",
  "reasons": [
    {
      "code": "RAW_SCREENSHOTS",
      "message": "Screenshots are full-fidelity local evidence and must be redacted before sharing."
    }
  ]
}

Naming is flexible. The important distinction is:

• ok: true: the local run bundle is structurally valid evidence.
• shareSafety.status: share_ready: the bundle can be attached to a public issue/PR/report as-is.
• shareSafety.status: local_only: valid local evidence, but not publish-safe without export/redaction.
• shareSafety.status: blocked: public-bound output must not be produced.

Acceptance criteria

• verify --json includes a stable share-safety object.
• Raw full-fidelity screenshots set local_only unless capture/export policies redacted them.
• Missing or failed redaction sets blocked.
• feedback issue and any future publish/export commands gate on share-safety instead of warning text.
• Docs explain that local proof and public/share-ready proof are different contracts.

Related

• Add redact-on-export for existing raw run bundles #136 tracks redact-on-export for already-captured raw bundles.
• Validate screenshot evidence by decoding image bytes, not only file signatures #210 tracks decoding screenshot bytes during verification.

[danielgwilson]

Downstream adapter migration note: this is now a concrete deletion-readiness blocker for product repos that can verify local evidence but must not accidentally treat raw run bundles as public/share-ready artifacts.

Useful acceptance detail:

• expose shareSafety.status in machine-readable output, not warning prose only
• include reason codes for raw screenshots, adapter-declared local-only artifacts, unredacted external state, and missing redacted export
• keep full-fidelity screenshots local by default
• let downstream readiness gates assert valid local proof separately from share-ready proof

[danielgwilson]

Implemented the core machine-readable share-safety contract in #249 and published it in mimetic-cli@0.12.22.

Shipped:

• mimetic verify --json now includes shareSafety.status (share_ready, local_only, blocked) plus structured reason codes.
• Raw full-fidelity screenshot runs remain valid local evidence (verify.ok === true) but report shareSafety.status: local_only with RAW_SCREENSHOTS.
• mimetic feedback draft|verify|issue|issue-url now fail closed unless shareSafety.status === "share_ready", returning MIMETIC_FEEDBACK_SHARE_SAFETY_BLOCKED with the structured share-safety object.
• README and contract docs now distinguish verify-valid from public-promotable evidence.

Proof:

• feat: expose verify share safety #249 CI green
• chore: release 0.12.22 #250 release PR green
• publish workflow green for tag v0.12.22
• npm latest is 0.12.22

I split the broader future reason taxonomy into #251 so this issue can close without pretending every publish-boundary reason class is complete.