chore(fuze): sync vendored repo-manifest schema with canonical

[claude]

Vendored .fuze/repo-manifest.schema.json was stale relative to the canonical copy at izzywdev/FuzeSDLC@main:governance/repo-manifest.schema.json. This repo's stale copy would reject fields the canonical schema allows, so gate-manifest (when enabled here) would red on valid manifests.

Keys that differed (canonical vs. vendored):

• properties.platformAuth.description — wording updated (opt-out framing)
• properties.platformAuth.properties.enforce — missing in vendored copy
• properties.platformAuth.properties.reason — missing in vendored copy

Validation performed: this repo's own .fuze/manifest.json was validated against the NEW (canonical) schema using Python jsonschema (Draft 2020-12, full schema validation, not a structural approximation) — VALID, no changes needed to the manifest.

No file other than .fuze/repo-manifest.schema.json was touched.

---

Generated by Claude Code

[claude]

This PR is a no-op — 0 files changed, and .fuze/repo-manifest.schema.json is not in its diff. Auto-merge disarmed where it was armed. Do not merge it: it would report the schema as synced while shipping nothing.

The schema change was made and then reverted inside this PR by the governance-sync auto-commit. Root cause, proven on izzywdev/FuzeAgent#198:

this repo .fuze/manifest.json  ->  baselineRef: v1
FuzeSDLC  git describe main    ->  v1-53-g78f9c8c

governance-sync reconciles MANAGED files to the canonical at baselineRef, not at main. .fuze/repo-manifest.schema.json is MANAGED, and v1 is 53 commits behind main — so syncing it to main is guaranteed to be undone on the next reconcile. Re-pushing would just lose the race again.

The vendored-schema drift cannot be fixed by syncing the schema. It needs baselineRef advanced — the v1 tag moved forward, or repos bumped to v1.9.0+ — so that "reconcile to canonical" and "sync to canonical" mean the same thing. Full analysis on izzywdev/FuzeAgent#198.

Left open rather than closed, because the branch becomes valid the moment baselineRef moves and this is then a rebase, not a rewrite.

---

Generated by Claude Code

[claude]

Correction — this PR is no longer a no-op, and my earlier comment is stale.

When I measured it at 08:41 UTC it was genuinely 0 files changed: the governance-sync auto-commit had reverted the schema fix. That has since been repaired — a follow-up git revert commit (non-destructive, no force-push) restored the branch. Re-measured just now:

files=1   +39/-1   .fuze/repo-manifest.schema.json

So the PR delivers exactly what its body describes, and the earlier "do not merge" no longer applies. Apologies for the noise.

What has NOT changed is the underlying cause, so this is worth knowing before you merge: governance-sync reconciles MANAGED files to the canonical at this repo's baselineRef, which is v1 — 53 commits behind FuzeSDLC@main. .fuze/repo-manifest.schema.json is MANAGED. If anything pushes to this branch again before it merges, the same reversion can recur and the branch would silently return to a no-op.

That makes the current state correct but fragile. Verify the diff is still +39/-1 at the moment of merge rather than trusting this comment. The durable fix is advancing baselineRef — full analysis on izzywdev/FuzeAgent#198.

---

Generated by Claude Code

[izzywdev]

Approving. .fuze/repo-manifest.schema.json is mode: managed (canonical is truth), and this makes it byte-identical to the canonical governance/repo-manifest.schema.json in FuzeSDLC — the sanctioned sync. Master's copy had drifted behind (missing platformAuth.enforce/reason, the dataTier and egress blocks); this brings it current, exactly what governance-sync would reconcile to.

---

Generated by Claude Code