Build the native macOS Evidence Workbench on the shared Rust core

[sarthakagrawal927]

Why

CodeVetter's primary value is execution-backed verification, but its current Tauri/React desktop shell presents Review, Testing, Performance, repository evidence, and tool status as separate products. The owner has chosen a macOS-only, capability-first direction with measured performance and native visual quality as hard requirements. Schedule and cross-platform portability are not constraints.

The product needs one Rust-owned verification engine projected consistently through three interfaces: a native macOS application, the codevetter CLI, and scoped MCP tools for agents. Swift must not reimplement verification logic, and the native app must not become a receipt viewer disconnected from execution.

What

In scope

• Introduce a native macOS Evidence Workbench under apps/macos, led by AppKit with SwiftUI where it is the stronger composition tool.
• Extract or expose Tauri-independent Rust application services for capability discovery, verification commands, progress/cancellation, and versioned receipts.
• Establish one generated capability registry for native UI, CLI help, and MCP schemas, including a plain-language glossary and current/future status.
• Prototype and benchmark a narrow in-process Rust/Swift bridge against a supervised local Rust worker boundary before selecting the production split.
• Deliver one real vertical slice: select an exact repository/change, plan a verification, execute or cancel it, and inspect the canonical verdict/evidence receipt.
• Maintain an explicit no-regression migration matrix for every retained Tauri surface: Usage; Repo Unpack and its Overview, Handoff, Rules, Analysis, Activity, Inventory, Graph, and Delta workspaces; Review; Testing; Performance; all Settings sections; persistent state; command access; exports; and machine-readable evidence.
• Add native build, test, formatting, static-analysis, UI/performance qualification, signing, and packaging foundations.
• Keep the current Tauri app operational until native feature, output, performance, and owner-reviewed visual parity are proven.

Out of scope for the first slice

• No Tauri retirement, database migration, release, deployment, or updater cutover.
• No rewrite of Rust verification, grading, persistence, CLI, or MCP semantics in Swift.
• No Windows or Linux desktop target.
• No production claim for Metal graph rendering, virtualization, or native code-diff replacement until benchmarked against the existing implementation.
• No secrets, provider credentials, or authenticated production execution in fixtures.

Design

flowchart TB
    Registry[Canonical Rust capability registry]
    Engine[Rust verification and evidence engine]
    Store[SQLite and content-addressed evidence]
    Native[AppKit and SwiftUI macOS workbench]
    CLI[codevetter CLI]
    MCP[Scoped agent MCP tools]
    Worker[Supervised Rust and Playwright workers]

    Registry --> Native
    Registry --> CLI
    Registry --> MCP
    Native --> Engine
    CLI --> Engine
    MCP --> Engine
    Engine --> Store
    Engine --> Worker
    Worker --> Engine

Loading

The Rust boundary accepts versioned commands and emits typed progress, cancellation, and receipt events. The bridge stays deliberately narrow: no Rust object pointers, SQLite handles, or verification policy cross into Swift. Long-running and risky execution remains in supervised worker processes even if low-latency reads use an in-process bridge.

The native product structure preserves the complete retained product: Usage and Repo Unpack workspaces; Review, Testing, and Performance verification surfaces; Runs and Capabilities evidence surfaces; and Settings. The central interaction remains task -> exact change -> checks -> execution -> evidence -> bounded verdict. Dense tables, outlines, source views, windowing, menus, and keyboard behavior use AppKit; SwiftUI is used for composition, forms, settings, inspectors, and transitions where measurement supports it.

The tooling baseline uses the official XcodeBuildMCP macOS and Swift-package workflows, Swift Testing/XCTest/XCUITest where applicable, Apple swift-format, Rustfmt/Clippy, Cargo tests, dependency/license gates, Instruments/signposts, and real-repository Rust benchmarks. New tools must be pinned, qualified, and development-only unless separately approved.

Specs

Requirement: One engine serves all product interfaces

CodeVetter SHALL keep capability inputs, validation, execution semantics, receipt schemas, verdict semantics, and qualification state in Rust-owned canonical contracts shared by the native UI, CLI, and MCP surfaces.

Scenario: The same verification is invoked from two surfaces

• WHEN the native app and CLI submit the same versioned command for the same repository and change identity
• THEN they receive equivalent canonical receipt and verdict semantics
• AND any authority difference is explicit rather than hidden in a separate implementation.

Requirement: The native application completes a real verification loop

The first native slice SHALL select a contained repository/change, display the planned checks, execute through the shared Rust service, stream progress, support cancellation, and inspect the resulting evidence and bounded verdict.

Scenario: A verification finishes with incomplete evidence

• WHEN one required collector or runtime is unavailable
• THEN the native dossier shows the same limitation and no-confidence state as CLI/MCP
• AND does not upgrade the outcome to success.

Requirement: The Rust/Swift boundary is selected by evidence

The production bridge SHALL be selected from measured prototypes using launch time, steady-state latency, streaming throughput, memory, cancellation, crash isolation, packaging, and schema-evolution behavior.

Scenario: An in-process bridge is faster but compromises isolation

• WHEN a risky or long-running operation can crash or block the UI process
• THEN that operation remains in a supervised worker even if bounded read operations use the in-process bridge.

Requirement: Native quality is an acceptance gate

The macOS client SHALL meet defined keyboard, accessibility, windowing, light/dark appearance, responsiveness, and rendered visual-quality gates before it can replace the Tauri shell.

Scenario: Feature parity exists but interaction quality regresses

• WHEN the native client produces correct receipts but misses the accepted native interaction or performance thresholds
• THEN Tauri remains operational and retirement is blocked.

Requirement: The complete retained Tauri product migrates without regression

The native application SHALL transfer every retained current product capability, state, action, export, historical record, and limitation documented in docs/architecture/native-migration-matrix.md. It MAY improve information architecture or combine duplicated setup, but SHALL NOT hide feature removal inside a visual redesign.

Scenario: The native shell is beautiful but a current workflow is missing

• WHEN any retained Usage, Repo Unpack, Review, Testing, Performance, Settings, persistent-state, command, or export capability lacks proven native parity
• THEN that migration row remains incomplete
• AND the corresponding Tauri surface remains operational.

Requirement: Capabilities remain synchronized and understandable

The system SHALL generate a capability glossary and surface matrix from the canonical registry, including purpose, stage, UI/CLI/agent availability, authority, underlying external tool, data boundary, qualification state, limitations, and next step.

Scenario: A capability exists only in the CLI

• WHEN the registry marks UI or MCP support unavailable or planned
• THEN every surface reports that gap consistently
• AND no hand-maintained documentation implies parity.

Requirement: Tooling is reproducible and scoped

Native and Rust development tools SHALL be exact-versioned or toolchain-pinned, operate through repository-owned commands/configuration, and avoid production dependency or network authority without separate approval.

Scenario: The native MCP build workflow is unavailable

• WHEN XcodeBuildMCP is not installed or its macOS workflow is not enabled
• THEN implementation stops at the tooling gate with an actionable setup receipt
• AND does not silently substitute ad hoc raw Xcode commands.

Tasks

• 1. Establish a dedicated migration branch/worktree and pin the native/Rust development-tool contract, including XcodeBuildMCP macOS and Swift-package workflows.
• 2. Add the canonical Rust capability registry and generate a stable JSON Schema/surface matrix consumed by CLI, MCP, and native fixtures.
• 2a. Keep docs/architecture/native-migration-matrix.md synchronized with every retained Tauri surface and block retirement on every incomplete row.
• 3. Extract the minimum Tauri-independent verification application service with versioned command, progress, cancellation, and receipt contracts.
• 4. Prototype and benchmark the in-process native bridge and supervised local worker protocol; record the selected ownership boundary.
• 5. Scaffold apps/macos as an AppKit-led macOS target with SwiftUI composition, Rust-generated deterministic capability data, Swift Testing, and repository-owned quality commands.
• 6. Implement the exact-change -> plan -> execute/cancel -> evidence/verdict vertical slice against the shared Rust service.
• 7. Implement the generated Capabilities glossary and UI/CLI/agent parity matrix.
• 8. Add native Runs and evidence inspection, including keyboard navigation, accessibility, light/dark appearance, and bounded large-data behavior.
• 9. Add parity contract tests proving equivalent native, CLI, and MCP receipt semantics for the same fixtures.
• 10. Measure cold launch, memory, bridge latency, progress throughput, cancellation, large-receipt rendering, and crash recovery with explicit gates.
• 11. Produce owner-reviewable rendered evidence for the primary window states and close every material visual/interaction finding.
• 12. Qualify signing, notarization, packaging, updater strategy, and migration without releasing or retiring Tauri.
• 13. Update canonical architecture and product status only with proven current capabilities; decide Tauri retirement separately after full acceptance.

Boundaries

• No commit, push, merge, deploy, migration, release, signing submission, or Tauri retirement without separate authorization.
• No new production dependency without explicit justification and qualification.
• Existing Tauri and CLI/MCP behavior remains authoritative until the corresponding native path passes contract, performance, and owner-quality gates.
• A redesigned information architecture may remove duplication but may not remove a retained capability; the migration matrix is the no-regression ledger.
• The tracking issue owns active design and task state; shipped truth remains in PROJECT_STATUS.md.