Integrate RAVEL with the persistent MNCS Fabric controller

[epi13]

Summary

Moves RAVEL’s preferred live Fabric integration onto the current persistent-controller consumer boundary while preserving the existing local/direct-network backends for historical compatibility and negative-matrix reproduction.

What this adds

• Adds ravel.fabric_persistent.FabricPersistentBackend using FabricClient.connect(...) rather than constructing/owning Fabric controllers or worker transports.
• Adds a deliberately narrow persistent config (ravel-fabric-persistent-config/0.1) containing only controller socket, client identity, and timeout.
  • Worker endpoints, CA/client cert/key material, TrustStore state, registries, bundle caches, and controller ledgers are rejected from the RAVEL persistent config.
• Delegates immutable execution-bundle verification/transfer to Fabric’s controller-owned native bundle transport.
• Uses Fabric’s controller-owned worker placement/capability inventory instead of hard-coded worker/model routing.
• Supports both synchronous execution and detached submit -> status -> result execution.
• Persists detached RAVEL submission provenance under the RAVEL workspace so a later RAVEL process can recover a Fabric work_id and interpret its final evidence after restart.
• Maps persistent Fabric consumer results into existing ravel-fabric-observation/0.1 references without copying Fabric authority into RAVEL.
• Keeps Fabric reconciliation UNKNOWN on this path until Fabric exposes a Fabric-owned reconciliation result through the persistent public boundary rather than reimplementing reconciliation inside RAVEL.
• Leaves model selection optional; no model name is hard-coded into the adapter.
• Keeps FabricLocalBackend / FabricNetworkBackend intact as compatibility/reference paths.

Contract and authority boundaries

RAVEL remains a Fabric consumer:

• RAVEL owns semantic questions, development workload identity, and advisory experience.
• Fabric owns worker membership, authenticated transport, placement, bundle transfer, raw execution records, receipts, detached execution lifecycle, and fleet state.
• Fabric execution PASS/FAIL/UNKNOWN remains execution evidence only; it does not become evaluator, selection, promotion, conformance, or custody authority.

The persistent adapter also hashes RAVEL’s provider/partition/Forge labels into Fabric’s opaque SHA-256 provenance fields rather than treating those labels as Fabric policy authority.

Detached execution / restart behavior

submit_provider_parity() uses Fabric’s persistent submit_execution() API and records only the RAVEL-side provenance needed to recover the submission. A later process can use:

• load_submission(work_id)
• execution_status(work_id)
• collect_work_id(work_id)

Fabric remains the source of truth for actual execution state.

Bundle compatibility

The existing RAVEL/MNCS validator execution-bundle builder and Fabric’s persistent bundle verifier implement the same EA-NEXT-002 contract (0.1-experimental, mncs-execution-bundle-zip-0.1), so this path reuses the existing immutable MNCS bundle rather than introducing another package format.

Tests and docs

Adds tests/test_fabric_persistent.py covering:

• consumer-only config boundaries and rejection of worker trust material,
• SHA-256 provenance translation,
• preservation of execution status vs evaluator authority,
• controller-native bundle semantics (pre_staged = NOT_REQUIRED), and
• detached submission serialization/identity round-trip.

Updates:

• README.md
• docs/FABRIC_INTEGRATION.md
• ravel_versions/0.6/RAVEL_0_6_IMPLEMENTATION_STATUS.md
• src/ravel/__init__.py
• config/ravel-fabric-persistent.example.toml

Validation status

Static/API compatibility was reviewed against current mncs-fabric 0.2.0a30, including the persistent controller implementation of execution.dispatch, execution.submit, execution.status, execution.result, controller-owned bundle cache, and worker backend.

The MNCS Control connector is not exposed to this chat session even when @mentioned, so I could not execute the live controller/fleet E2E from here. GitHub CI should exercise the repository unit/Rust/C suites on this PR. The remaining external validation is a live persistent-controller run against the enrolled Fedora/Windows fleet, including worker/controller restart and replay cases.

Follow-up after this PR

Once the live boundary is stable, port the same consumer contract to the canonical Rust implementation and prove Python/Rust parity before replacing the Python compatibility bridge. Do not move Fabric worker/trust responsibilities into Rust RAVEL during that migration.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.