userarena1002 adds a parallel Databricks-target app alongside the upstream codebase

The new app has a clean service-boundary layout. FastAPI (app/main.py) serves a Vite React port and delegates to four adapters in app/services/: a Databricks backend service (808 lines), storage, model, and persistence adapters. Two Databricks notebook jobs (app/jobs/) handle DOCX review and tabular review - both are intentionally import-light so they can be lifted into Databricks Jobs against cluster-specific libraries. An app.yaml covers Databricks Apps deployment using valueFrom resource bindings for volumes, warehouses, serving endpoints, and job IDs.

Model routing is handled by a MODEL_BACKEND environment variable: mock returns hardcoded redlines and cells, openai calls GPT-5.4, and databricks is a placeholder that currently falls back to mock until Model Serving is configured in a live workspace. The README is direct about this: the architecture is wired but the real engines aren't in yet.

The fork's docs/databricks/migration_inventory.md documents what gets cut in this reframing: Supabase auth, all auth-adjacent pages, R2/S3 storage, Cloudflare/OpenNext deployment, project sharing, free-form document generation, and general chat. What survives is the DOCX tracked-change engine, edit cards, the assistant timeline UI, and tabular/workflow components - reframed around single-user document_sessions and review_events rather than shared projects. That inventory is the most informative artifact in the commit: it's a concrete checklist of what an enterprise, upload-first version of mike looks like.

Author metadata is the git default (Your Name <you@example.com>), which puts this in personal-workspace territory. No tests, no CI configuration, and the Databricks job paths return mock data.