cohosting-regression-test-plan

Platform + OpenWork Co-hosting Regression Test Plan

Status: Draft
Last updated: 2026-03-07
Related issue: PLT-1081
Related docs: OpenWork Platform Integration Plan

---

1) Purpose

Define regression coverage for Platform and OpenWork co-hosting so the team can validate integration safety before tightening from Labs-first entry to deeper same-origin behavior.

This plan is intentionally scoped to web co-hosting paths only (no desktop/Tauri coverage).

2) Proportionality by integration depth

Use this as a guardrail to avoid overbuilding too early:

Integration mode	Coverage level	Why
Mode A: Labs-first entry (Platform route links/iframes Labs)	Baseline	Lower coupling; focus on route gating and embed behavior
Mode B: same-origin co-hosting (proxy/rewrites under /openwork)	Expanded	Higher blast radius across auth, routing, streaming, and API isolation

3) Environment assumptions and prerequisites

Environments

• Local dev for fast iteration and route/auth checks:
  • Platform on http://localhost:3000
  • OpenWork service or built web assets reachable from local environment
• Staging/pre-production for cookie/session/CSP/proxy validation:
  • Real auth enabled
  • Domain and TLS setup close to production behavior

Prerequisites

• Platform route entry (/openwork) enabled in the target environment.
• OpenWork integration mode is explicitly known (Mode A vs Mode B).
• A dedicated internal test user exists for:
  • Authorized access to Platform and OpenWork entry.
  • Unauthorized/limited access checks (role or membership mismatch).
• Test data/workspace available for a basic OpenWork session flow.
• Log visibility for both Platform and OpenWork paths during tests.

4) Highest-risk scenarios and expected outcomes

These are the minimum scenarios that must remain green after changes touching routing, auth, middleware, rewrites, or OpenWork integration.

Risk area	Scenario	Expected outcome
Route ownership	Navigate to /openwork and deep links (/openwork/*)	Correct handler resolves every path; no accidental capture of non-OpenWork Platform routes
Auth boundary	Unauthenticated and authorized users hit /openwork	Unauthenticated users are redirected/blocked consistently; authorized users reach expected OpenWork entry
Session continuity	Authenticated user enters OpenWork from Platform	Session is preserved as designed (or explicit re-auth prompt appears with clear UX)
Iframe behavior (Mode A)	Open /openwork iframe wrapper and interact with OpenWork UI	No blocked frame due to CSP/X-Frame-Options; primary interactions load and respond
Proxy path rewriting (Mode B)	OpenWork assets/API under proxied /openwork paths	Asset and API paths rewrite correctly; no broken static assets or 404 rewrite loops
API isolation	Exercise Platform APIs and OpenWork APIs in same session	No route collisions; Platform APIs remain protected; OpenWork endpoints are scoped and reachable only as intended
Streaming/long-lived requests	Trigger OpenWork streaming endpoint (SSE/WebSocket/long poll)	Stream connects and remains stable for expected duration; no proxy timeout or buffering regression
Failure behavior	OpenWork service unavailable/degraded	Platform route fails gracefully (clear error state/fallback), without degrading unrelated Platform pages

5) Minimum automated regression coverage

Automated checks should focus on fast, high-signal failures. Keep these in CI for changes touching integration surfaces.

Required automated checks (baseline)

1. Route and middleware tests
   • /openwork access rules for unauthenticated vs authenticated users.
   • No regression on existing protected Platform route behavior.
2. Rewrite/proxy contract tests
   • (Mode B only) mapping for /openwork/* asset/API routes.
   • Guard against rewrite loops and incorrect destination paths.
3. API boundary tests
   • Validate that OpenWork integration does not bypass Platform API auth.
   • Validate expected status codes for unauthorized access attempts.
4. Availability fallback tests
   • Simulate upstream OpenWork unavailability and assert graceful fallback UI/response.

Optional automated checks (add when integration depth increases)

• Browser E2E smoke for /openwork happy path in staging:
  • Login → open /openwork → create/load a basic session → verify UI readiness.
• Streaming stability smoke against proxied OpenWork endpoints in staging.

6) Minimum manual regression coverage

Manual checks are required for browser/runtime details that unit tests miss.

Manual checklist (every release touching integration paths)

1. Authorized happy path
   • Login as allowed user.
   • Open /openwork and complete one meaningful interaction.
2. Unauthorized path
   • Use user without access (or logged-out state).
   • Confirm redirect/deny behavior and no leaked OpenWork content.
3. Deep-link behavior
   • Open at least one deep link under /openwork/*.
   • Refresh browser and validate route resolves correctly.
4. Back/forward navigation
   • Move Platform → OpenWork → Platform via browser history.
   • Confirm no broken history state or redirect loops.
5. Failure mode
   • Test with OpenWork unavailable (or simulated error).
   • Confirm fallback message and Platform stability.

7) Execution strategy

• Run baseline automated checks on every PR that touches:
  • Platform middleware/auth
  • /openwork route implementation
  • proxy/rewrites or API gateways for OpenWork
• Run manual checklist:
  • Before enabling/tightening integration mode in staging.
  • Before production rollout changes for /openwork.
• Keep a short test evidence note per rollout (date, environment, owner, pass/fail, known exceptions).

8) Ownership, location, and maintenance

• Source of truth: this file in knowledge/engineering/openwork-platform-integration/.
• Owner: Platform engineering (integration owner) with OpenWork owner as reviewer.
• Maintenance trigger: update this plan when any of the following changes:
  • integration mode (Mode A vs Mode B),
  • auth model,
  • proxy/rewrite architecture,
  • OpenWork runtime contract affecting route/API behavior.

9) Deferred scope if we remain Labs-first

If the team stays on Labs-first entry mode, these items can remain deferred:

• Full same-origin proxy rewrite contract test suite.
• Expanded streaming/proxy timeout coverage for /openwork/* proxied endpoints.
• Cookie/domain edge-case matrix specific to same-origin session sharing.

Do not defer:

• /openwork route access checks (auth/role behavior).
• iframe/embed viability checks (if iframe mode is used).
• graceful failure handling and fallback UX.