OpenWork Architecture Reconciliation + Labs Launch Gate
Status: Decision note (Phase 0 gate)
Date: 2026-03-07
Linear issue: PLT-1073
Related project: OpenWork Platform Integration
Primary plan: OpenWork Standup Plan
Launch ticket using this gate: PLT-1074
Decision
Recommendation: Proceed with conditions.
We should continue toward a Labs launch only after the blockers in this memo are closed.
Current implementation work provides a valid platform entry surface, but it does not yet satisfy the launch-shape assumptions in the plan for a standalone Labs runtime.
Inputs reviewed
knowledge/engineering/openwork-platform-integration/openwork-platform-integration-plan.md- Implemented platform integration:
apps/platform/src/app/(main)/openwork/[[...path]]/page.tsxapps/platform/src/utils/supabase/middleware.tsapps/platform/src/components/Sidebar.tsxapps/platform/scripts/sync-openwork-web-assets.mjsapps/platform/package.json(openwork:build-web)
- Clarence architecture reference as cited in the plan (Slack artifact path)
Note: The Clarence architecture artifact itself is referenced from a local absolute path in the plan and is not available in-repo. This creates one explicit human-review blocker below.
Reconciliation (plan + implementation vs architecture guidance)
| Topic | Architecture/plan intent | Current state | Delta | Risk |
|---|---|---|---|---|
| Ownership boundaries | Keep platform concerns aligned, OpenWork runtime decoupled for initial launch | /openwork route is implemented in platform and loads a static OpenWork bundle from public/openwork-static | Runtime ownership is currently mixed in platform for web assets; standalone Labs runtime is not yet proven | Medium |
| Ingress model | Initial path recommends standalone labs.brainforge.ai; platform route should link/embed Labs | Current route iframes same-origin static file (/openwork-static/index.html#...) | Cross-origin Labs ingress, CORS/CSP, and domain routing behavior are not yet validated in app flow | High |
| Identity/session | Validate identity/session assumptions before Phase 2 routing decisions | Platform auth middleware protects /openwork; OpenWork server auth uses token-based calls (Authorization bearer / host token patterns) | End-to-end SSO/session bridge policy between platform identity and OpenWork server token lifecycle is not finalized | High |
| Runtime assumptions | Validate Linux container deploy, persistent storage, sidecar strategy before launch | No evidence in this branch of completed Labs runtime validation; plan references this in separate tickets | Launch prerequisites are tracked but not yet closed in this issue scope | High |
Blockers, mitigations, owners
| Blocker (must close before Labs deploy starts) | Mitigation / required proof | Owner |
|---|---|---|
| B1. Clarence architecture review is not yet verifiable from repo artifacts | Add/attach the architecture diagram (or extracted decision bullets) to a durable repo/Linear location, then confirm ownership + ingress + identity assumptions against this memo | Platform lead + Clarence (human step) |
| B2. Launch shape mismatch (standalone Labs runtime vs current same-origin static embed) | Complete PLT-1074 deployment validation on labs.brainforge.ai and confirm platform /openwork entry mode for Labs (external link vs cross-origin iframe) | Platform engineering (PLT-1074 owner) |
| B3. Identity/session boundary not finalized for hosted mode | Define hosted auth contract: how a platform-authenticated user gets OpenWork server access (token issuance, storage, rotation, revoke path), and document failure behavior | Platform engineering + security reviewer |
| B4. Ingress constraints for hosted mode not validated | Confirm CORS/CSP/frame-ancestors/domain rules for chosen entry mode; test login, session start, SSE stream, and workspace operations in hosted path | Platform engineering + ops |
| B5. Runtime reliability prerequisites still pending | Close PLT-1071 and PLT-1072 checks (sidecar strategy, persistent volumes, env contract) and attach smoke evidence to PLT-1074 | Platform engineering + ops |
What must be true before PLT-1074 can start deployment execution
The Labs deployment should be considered go only when all conditions below are true:
- Clarence architecture constraints are explicitly reviewed and approved for this launch shape (B1 closed).
- Entry mode decision is locked for Labs (
external linkorcross-origin iframe) and ingress controls are validated (B2 + B4 closed). - Hosted identity/session contract is documented and test-verified (B3 closed).
- Runtime prerequisites from Phase 0 are complete with evidence (B5 closed).
If any condition remains open, recommendation reverts to stop for deployment execution.
Open question resolution
Q: Are there any identity or ingress constraints from the Clarence architecture that require human review before deployment?
A: Yes. Because the authoritative architecture artifact is not currently available in-repo and hosted ingress/identity paths differ from the current same-origin static embed path, human architecture review is required before Labs deployment begins.
Traceability
- This note satisfies plan items:
- “Reconcile plan assumptions against Clarence architecture and capture deltas/unknowns.”
- “Publish a go/no-go note in vault with blockers, mitigations, and owners.”
- Use this file as the launch-gate reference in PLT-1074.