Integrate remaining low-risk upstream maintenance

.gitattributes

@@ -0,0 +1,5 @@
+# Lockfiles are generated files. Git's line-level merge can splice concurrent
+# edits into syntactically invalid content without reporting a conflict.
+# Treat them as binary so concurrent edits require explicit regeneration.
+package-lock.json merge=binary
+bun.lock merge=binary

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,33 @@
+## Summary
+
+<!-- What does this PR do in one or two sentences? -->
+
+## Why
+
+<!-- What problem does this solve, and why is this approach appropriate? -->
+
+## Changes
+
+<!-- Describe the outcome at a high level. Keep unrelated changes out. -->
+
+## Tradeoffs and risk
+
+<!-- What could break? Note security, privacy, data-boundary, migration,
+     deployment, release, or compatibility implications. -->
+
+## How verified
+
+<!-- List the exact commands, automated checks, and any manual verification. -->
+
+## Upstream provenance
+
+<!-- For upstream work, identify the source PR/commit and classify it as
+     Adopt, Adapt, Skip, or Investigate. Otherwise write "Not applicable". -->
+
+## Checklist
+
+- [ ] Ran the relevant focused tests and the applicable Baseline commands.
+- [ ] Reviewed the final diff and removed unrelated changes.
+- [ ] Preserved ROSS data-boundary, authentication, privacy, and release controls.
+- [ ] Updated documentation and environment examples when behaviour or setup changed.
+- [ ] No secrets, API keys, real client documents, privileged material, or `.env` files are committed.

.github/workflows/baseline.yml

@@ -35,6 +35,8 @@ jobs:
         uses: actions/checkout@v7
       - name: Set up pinned Node.js and npm
         uses: ./.github/actions/setup-ross-node
+      - name: Validate backend package manifests
+        run: node -e "const fs=require('fs'); for (const f of ['backend/package.json','backend/package-lock.json']) JSON.parse(fs.readFileSync(f, 'utf8'))"
       - name: Install backend dependencies
         run: npm ci --prefix backend
       - name: Run backend tests
@@ -51,6 +53,8 @@ jobs:
         uses: actions/checkout@v7
       - name: Set up pinned Node.js and npm
         uses: ./.github/actions/setup-ross-node
+      - name: Validate frontend package manifests
+        run: node -e "const fs=require('fs'); for (const f of ['frontend/package.json','frontend/package-lock.json']) JSON.parse(fs.readFileSync(f, 'utf8'))"
       - name: Install frontend dependencies
         run: npm ci --prefix frontend
       - name: Build frontend
@@ -65,6 +69,8 @@ jobs:
         uses: actions/checkout@v7
       - name: Set up pinned Node.js and npm
         uses: ./.github/actions/setup-ross-node
+      - name: Validate website package manifests
+        run: node -e "const fs=require('fs'); for (const f of ['website/package.json','website/package-lock.json']) JSON.parse(fs.readFileSync(f, 'utf8'))"
       - name: Install website dependencies
         run: npm ci --prefix website
       - name: Build website
@@ -83,6 +89,8 @@ jobs:
         uses: actions/checkout@v7
       - name: Set up pinned Node.js and npm
         uses: ./.github/actions/setup-ross-node
+      - name: Validate all package manifests
+        run: node -e "const fs=require('fs'); for (const d of ['.','backend','frontend','website']) for (const f of ['package.json','package-lock.json']) JSON.parse(fs.readFileSync(d === '.' ? f : d + '/' + f, 'utf8'))"
       - name: Install locked dependencies
         run: npm run install:all
       - name: Regenerate release manifest for verification

.gitignore

@@ -19,3 +19,7 @@ next-env.d.ts
 .DS_Store
 .vercel
 coverage
+
+# Generated local Supabase CLI scaffold. CI and production build their own
+# database state from the governed schema and migrations.
+backend/supabase/

CONTRIBUTING.md

@@ -30,6 +30,26 @@ Mike functionality recorded in the baseline contract.
     - changes
     - why
     - testing
+    - tradeoffs and risk
+    - upstream provenance, when applicable
+
+## Testing Expectations
+
+- Add a regression test at the lowest practical layer for each feature or bug
+  fix. Prefer a focused unit test, then a route or integration test, and use an
+  end-to-end test only when a browser or deployed service is necessary to prove
+  the behaviour.
+- Do not weaken, skip, broadly disable, or delete an existing test merely to
+  make a change pass. Correct stale expectations only when the implementation
+  and governing contract demonstrate that the expectation is obsolete.
+- Record the exact commands run in the PR description. Baseline verification is
+  required on the final PR head; a successful run on an earlier commit is not
+  sufficient.
+- Tests requiring live Supabase, provider keys, or deployed URLs must be
+  explicitly environment-gated and must not expose secrets or real client data.
+- Changes to authentication, authorization, privacy, data boundaries,
+  migrations, deployment, or release mechanics require focused verification in
+  addition to the normal Baseline.
 
 ## System Workflows
 

backend/src/lib/supabase.ts

@@ -12,33 +12,3 @@ export function createServerSupabase() {
   }
   return createClient(url, key, { auth: { persistSession: false } });
 }
-
-/**
- * Extract and verify the Supabase JWT from the Authorization header.
- * Returns the user's UUID string, or throws a Response with 401.
- */
-export async function getUserIdFromRequest(req: Request): Promise<string> {
-  const auth = req.headers.get("authorization") ?? "";
-  if (!auth.startsWith("Bearer ")) {
-    throw new Response("Missing or invalid Authorization header", {
-      status: 401,
-    });
-  }
-  const token = auth.slice(7).trim();
-
-  const supabaseUrl = process.env.SUPABASE_URL || "";
-  const serviceKey = process.env.SUPABASE_SECRET_KEY || "";
-
-  if (!supabaseUrl || !serviceKey) {
-    throw new Response("Server auth is not configured", { status: 500 });
-  }
-
-  const admin = createClient(supabaseUrl, serviceKey, {
-    auth: { persistSession: false },
-  });
-  const { data } = await admin.auth.getUser(token);
-  if (!data.user) {
-    throw new Response("Invalid or expired token", { status: 401 });
-  }
-  return data.user.id;
-}

docs/upstream-integration-plan.md

@@ -0,0 +1,65 @@
+# Upstream integration plan
+
+## Objective
+
+Integrate useful changes from `Open-Legal-Products/mike` incrementally while
+preserving ROSS-specific security, privacy, legal-source, data-boundary, and
+release controls.
+
+## Required method
+
+Every upstream change is classified before implementation:
+
+- **Adopt** — incorporate substantially as written.
+- **Adapt** — port the useful behaviour around ROSS architecture and controls.
+- **Skip** — irrelevant, already implemented, superseded, or incompatible.
+- **Investigate** — potentially useful, but requires focused security,
+  migration, dependency, deployment, licensing, or product analysis.
+
+Do not bulk-merge upstream. Each implementation batch must be independently
+reviewable, reversible, and verified by Baseline on its exact final head.
+
+## ROSS safeguards that upstream work must not weaken
+
+- governed release train, immutable digest promotion, rollback, and manifests;
+- authentication, authorization, MFA, and encrypted provider-key handling;
+- data-boundary and upload/document scanning controls;
+- Ontario legal-source integrations and health checks;
+- privacy, public-beta evidence, and operational policy controls;
+- trusted-agent final-head verification and bounded automatic repair.
+
+## Completed low-risk inventory
+
+| Upstream change | Classification | ROSS disposition |
+| --- | --- | --- |
+| `cb2306c5` — unify full-screen loading markup | **Adapt** | Ported in ROSS PR #32 while preserving `DataBoundaryGate`, auth redirects, and MFA behaviour. |
+| PR #240 — prevent silently merge-corrupted lockfiles | **Adapt** | Extended across ROSS backend, frontend, website, and governance Baseline partitions in ROSS PR #33. |
+| PR #234 — contributor testing policy and PR template | **Adapt** | Added ROSS-specific final-head, privacy, data-boundary, release, and upstream-provenance requirements in ROSS PR #33. |
+| `fb3ec2d6` — ignore generated local Supabase scaffold | **Adopt** | Added `backend/supabase/` to `.gitignore` in ROSS PR #33. |
+| PR #186 — remove unused `getUserIdFromRequest` helper | **Adopt** | Removed after confirming no repository references in ROSS PR #33. Active Express authentication middleware is unchanged. |
+| `4728fd19` — pin Turbopack workspace root | **Skip: already implemented** | ROSS already sets `turbopack.root` to its resolved repository root. |
+| PR #270 — discover workflow packs through `pack.yaml` | **Skip: architecture differs** | ROSS discovers governed workflows directly from `mike-workflows/system/*/SKILL.md`; it does not use upstream pack-directory discovery. |
+| PR #258 — synchronize Bun lockfile | **Skip: not applicable** | ROSS uses npm lockfiles for its governed workspaces. |
+| PR #236 — Anthropic-specific E2E key instructions | **Skip: superseded** | ROSS uses provider-neutral encrypted user keys and a separate dedicated `OPENAI_API_KEY` only for bounded CI repair. |
+| PR #232 / reference CI workflow | **Skip: superseded** | ROSS has a partitioned Baseline, final aggregation gate, event-driven merge, manifest refresh, and bounded repair. |
+| Reference Vitest/evals harnesses | **Skip: superseded for the low-risk batch** | ROSS already has governed backend, frontend build, website, evaluation, security, operational, and release checks. Broader new test dependencies require a separate dependency-reviewed batch. |
+
+## Remaining work — not low risk
+
+The remaining useful upstream areas require dedicated focused batches and are
+not part of routine maintenance integration:
+
+- ownership and authorization fixes for tabular reviews, projects, folders, and
+  shared resources;
+- RLS, schema, migration, Supabase, and tenant-isolation changes;
+- prompt-injection, SSRF, download-token, connector-secret, CORS, and other
+  security hardening;
+- broad route-level, browser E2E, or new test-runner dependency additions;
+- workflow-pack format changes with external repository dependencies;
+- provider, local inference, storage, DMS, telemetry, queue, RAG, organization,
+  service-layer, deployment, Docker, and air-gap architecture;
+- changes affecting release, staging, rollback, production configuration, or
+  public operational evidence.
+
+For these categories, implementation begins only after architecture and threat
+analysis identifies the ROSS-specific adaptation and validation requirements.