Upstream Mike PR #293 review

[github-actions]

Automated-Upstream-Mike-Sync: true
Upstream-Risk: high

Promising schema-convergence control, but it crosses ROSS schema, migration, Supabase/RLS, privilege, and CI boundaries and therefore requires human architectural approval.

Mike PR Open-Legal-Products#293

• Outcome: needs-decision
• Capability: Verify that a fresh install from backend/schema.sql and an existing deployment upgraded through dated migrations converge to the same behaviorally and security-relevant PostgreSQL schema.
• Series: testing-17
• Dependencies: Supabase/PostgreSQL disposable test stack, Canonical schema fingerprinting, A verified historical ROSS schema baseline, Ordered ROSS migration discovery, Prior schema-drift design work referenced as Mike PR [Testing 16] ci: run the RLS/stack integration suite on every PR Open-Legal-Products/mike#256
• Prerequisites: Identify and approve a ROSS commit where schema.sql and migrations demonstrably converged, Run both installation paths against ROSS's supported Supabase/PostgreSQL version, Validate fingerprint coverage for tables, columns, constraints, indexes, RLS policies, functions, triggers, views, enums, and effective privileges, Review the apparent current drift: workflow_open_source_submissions exists in a migration but not backend/schema.sql, Confirm any privilege-remediation migration against production upgrade and rollback procedures
• Reason: ROSS has the same dual schema seams—backend/schema.sql and backend/migrations—and current inspection already indicates plausible drift. However, adopting the control and any fixes affects schemas, migrations, Supabase/RLS, service-role privileges, CI, and production upgrade behavior; upstream cherry-pickability is irrelevant, and repository-only inspection cannot establish a safe baseline or runtime equivalence.

Architecture brief

Implement a ROSS-native disposable-database evaluator that builds an upgraded database from an approved historical ROSS schema plus migrations added afterward, separately builds a fresh database from current backend/schema.sql, canonicalizes behaviorally and security-relevant catalog state, and fails on semantic differences. Keep baseline selection and privilege/schema remediation subject to explicit database-owner review.

Implementation plan

• Record an approved, evidence-backed ROSS convergence baseline rather than reusing Mike's commit pin.
• Prototype the two-path build and canonical fingerprint in an isolated Supabase stack matching ROSS's supported runtime.
• Add focused fixtures proving detection of missing tables, RLS/policy drift, function drift, and effective ACL drift while ignoring benign column and ACL ordering.
• Run the harness on current main and classify every difference, including workflow_open_source_submissions, before changing schema or migrations.
• Have database/security owners approve new forward-only, transactional remediations and rollback procedures.
• Only after approval, add the reviewed harness and CI gate without altering shipped migrations or weakening existing controls.

Required human action

This is a draft state-only architecture record. Review the brief and implementation plan before any code is attempted.