Production foundation and activation plan

Production Architecture Plan

Foundation implemented - production activation blocked.

ForgeLayer now has server-owned identity and workspace interfaces, membership and role enforcement, a tenant-scoped durable schema, an RLS migration, append-only Ledger controls, and safe product APIs. Local isolated validation passed for Auth, 61/61 RLS assertions, workspace switching, and durable restart behavior. Production adapters remain inactive, production validation is unavailable, and production activation is blocked.

Keep production blocked while reviewing an approved production target, operational controls, and a separate production validation plan; do not treat localhost validation as production evidence.

Back to readiness First repo setup Ledger Review Runs GitHub Checks plan AgentOS PromptForge

Current product truth

Implemented foundation, inactive production runtime

These states are deliberately distinct. Local isolated validation passed, but it does not activate or validate the production runtime.

Foundation Implemented

Trusted identity foundation

Server-owned authenticated identity, session, membership, role, and current-workspace interfaces are implemented.

Foundation Implemented

Durable schema foundation

Workspace-scoped control-plane tables, tenant references, and append-only Ledger controls are defined.

Adapter Inactive

Production adapters

Concrete Supabase session and user-context Postgres adapters passed isolated local validation; production adapters are not configured or active.

Local Validation Passed

Local migration replay

Migrations 001-003 replayed successfully against isolated local Postgres only; no remote or production migration was applied.

Local Validation Passed

Local isolated integration

Local Supabase Auth, 61/61 database-backed RLS assertions, workspace switching, tenant isolation, and durable reload/restart behavior passed.

Hosted Staging Pending

Hosted staging validation

Explicit hosted staging mode and operator safeguards exist, but no hosted project has been contacted or validated.

Production Validation Unavailable

Production validation

Production Auth, RLS execution, workspace switching, durability, monitoring, recovery, and token operations remain unvalidated.

Production Activation Blocked

Production activation

Production authentication and persistence remain unavailable until the isolated integration and operational gates are complete.

Workspace boundary

Security and RLS requirements

The trusted identity, membership, role, tenant-schema, and RLS migration foundations are implemented, but production adapters are inactive. Migrations 001-003, local Supabase Auth, 61/61 pgTAP RLS assertions, tenant isolation, workspace switching, and durability passed against isolated localhost only. Hosted staging configuration is inactive and hosted staging validation is pending; no hosted Supabase project has been contacted. No migration was applied to a remote or production database, and local validation is not production validation. Service-role writes for webhooks must stay server-side only, must not expose secrets, and must write only safe summaries by default. Raw diffs, raw repo rules, raw prompts, tokens, private keys, webhook payloads, provider errors, and stack traces remain excluded unless a future explicit privacy model allows otherwise.

Blocked until activation gates pass

What stays blocked

Production persistent Agent Work Records before the real adapter and RLS integration tests pass.
Raw prompt persistence before explicit privacy and retention controls.
Billing before auth, workspace roles, and plan enforcement are ready.
No live agent execution or autonomous workflows before approval gates and audit logs.
GitHub posting by default or auto-merge behavior.

Entity model

Implemented foundations and future data boundaries

users

Users

foundation_only

Represent authenticated people who can belong to workspaces.

Phase: production_auth
RLS required: yes
Workspace scoped: no
Sensitive fields: email, auth_provider_id

Supabase Auth and the server identity interface passed isolated local validation; production remains inactive and production integration is unvalidated.

workspaces

Workspaces

foundation_only

Group repositories, review runs, ledger records, and members under one tenant boundary.

Phase: production_auth
RLS required: yes
Workspace scoped: no
Sensitive fields: name, slug

Workspace schema, server resolution, switching, and restart durability passed isolated local validation; production durability is unvalidated.

workspace_members

Workspace Members

foundation_only

Map users to workspaces with owner, admin, reviewer, and viewer roles.

Phase: production_auth
RLS required: yes
Workspace scoped: yes
Sensitive fields: user_id, workspace_id, role

Membership and role enforcement passed the isolated local runtime and 61/61 pgTAP assertions; production RLS remains unexecuted.

github_installations

GitHub Installations

existing

Track GitHub App installations associated with a workspace.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: installation_id, account_login

Installation tokens must never be stored or exposed.

repositories

Repositories

existing

Track approved repositories connected through the GitHub App.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: owner, name, full_name

Repository rows should remain tied to allowlisted installations and workspaces.

review_runs

Review Runs

existing

Store safe summaries for GitHub webhook reviews and MergeGuard decisions.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: github_pr_url, pull_request_title, review_run_payload

Current storage excludes raw diffs, raw repo rules, raw prompts, tokens, and webhook payloads by default.

agent_work_records

Agent Work Records

foundation_only

Persist draft/proposed/completed AI-agent work records with evidence, risks, approvals, and blocked actions.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: task_description, changed_paths, evidence, risks, approvals

Currently derived locally and not production-persisted. The implemented identity/schema foundation still requires active adapters and real RLS validation.

ledger_entries

Ledger Entries

foundation_only

Provide the unified AI Work Ledger timeline across review runs, agent work records, approvals, prompts, and evidence.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: summary, audit_summary, metadata

Current ledger entries are derived/foundation-only except stored review-run summaries.

prompt_records

Prompt Records

planned

Track prompt-analysis metadata, safety scores, rewrites, and test outcomes without raw prompt exposure by default.

Phase: beta_persistence
RLS required: yes
Workspace scoped: yes
Sensitive fields: prompt_hash, analysis_payload, rewrite_summary

Raw prompt persistence should remain off until explicit product and privacy controls exist.

approval_records

Approval Records

foundation_only

Record human approvals, rejections, required checks, and merge-readiness decisions.

Phase: production_auth
RLS required: yes
Workspace scoped: yes
Sensitive fields: approver_user_id, decision, notes

Approval control records have a tenant-scoped schema foundation; production identity, adapter, and database behavior remain unavailable.

test_evidence

Test Evidence

planned

Attach safe evidence that required tests, builds, security checks, and manual reviews occurred.

Phase: production_auth
RLS required: yes
Workspace scoped: yes
Sensitive fields: command, result_summary, artifact_links

Evidence should store summaries and artifact references, not secret logs.

audit_events

Audit Events

foundation_only

Capture security-relevant state changes, posting decisions, approvals, and future agent-control events.

Phase: production_auth
RLS required: yes
Workspace scoped: yes
Sensitive fields: actor_user_id, event_payload, ip_metadata

Append-only workspace Ledger event controls are defined and statically checked; production retention and database behavior remain unverified.

billing_customers

Billing Customers

future

Future billing/customer mapping for paid workspaces.

Phase: billing_future
RLS required: yes
Workspace scoped: yes
Sensitive fields: billing_provider_customer_id, plan, billing_email

Billing remains future-only and must not be added before private beta demand is validated.

Remaining activation work

Integration and operational gates

No production adapter should be enabled until these checks are completed and independently reviewed.

01Review and approve a separate production Supabase target and activation plan.
02Review Migration 003 for production application without reusing local validation as production evidence.
03Repeat cross-workspace and role-specific RLS tests against the approved production-like target.
04Validate the production server session and user-context Postgres adapter configuration.
05Review CSRF, session rotation, expiry, and sign-out behavior.
06Add membership administration and workspace-switching validation.
07Define retention, deletion, backup, recovery, monitoring, and incident response.
08Complete an independent security review before production activation.

Migration phases

Safe path from private beta to production

phase_1_private_beta_demo

Private beta demo

planned

Keep the current demo and GitHub review-run loop stable while reviewers validate the workflow.

Allowed changes: planning docs, safe read-only pages, deterministic previews, non-persistent helpers
Blocked changes: production login requirement, billing, live agent execution, autonomous workflows
Manual checks: /api/health green, /readiness reviewed, GitHub posting disabled by default
Risk notes: Avoid confusing demo-safe foundations with production self-serve capabilities.

phase_2_workspace_auth

Workspace auth activation

planned

Activate and integration-test the implemented identity, membership, role, and workspace-resolution foundation.

Allowed changes: isolated auth adapter integration, membership administration, role-aware UI validation, RLS integration tests
Blocked changes: billing checkout, agent execution, broad public installs before RLS is verified
Manual checks: users cannot read other workspace data, anonymous demo path remains intentionally available or clearly gated
Risk notes: The foundation exists, but production identity remains unavailable until the adapter and real RLS behavior are validated.

phase_3_persistent_records

Durable records activation

planned

Activate reviewed Postgres repositories over the implemented tenant schema after Migration 003 and RLS pass isolated integration tests.

Allowed changes: append-only ledger writes, approval records, test evidence summaries, prompt metadata without raw prompt defaults
Blocked changes: raw secret storage, raw prompt persistence by default, cross-workspace records
Manual checks: RLS tests pass, raw diffs/rules/prompts remain excluded by default, audit events capture writes
Risk notes: Persistent records become customer data and need retention/privacy controls.

phase_4_github_app_production

GitHub App production

planned

Move from selected private beta repos to a controlled production GitHub App install flow.

Allowed changes: workspace-linked installations, repository selection, posting approvals, check-run implementation after preview validation
Blocked changes: posting enabled by default, auto-merge, unbounded repo access
Manual checks: allowlist or workspace repo selection enforced, posting remains explicit, tokens are never logged
Risk notes: GitHub permissions and repo access must remain least-privilege.

phase_5_billing_and_teams

Billing and teams

planned

Add paid plans, team limits, and workspace billing only after beta demand is proven.

Allowed changes: billing customer mapping, plan enforcement, team role polish
Blocked changes: billing before auth/workspace RLS, payment claims before checkout exists
Manual checks: billing is clearly marked live only after checkout is connected, team roles are tested
Risk notes: Billing data creates a new sensitive surface and should stay future until needed.

phase_6_agent_execution_controls_future

Agent execution controls

planned

Future-only controls for live agent execution, command access, repo access, approval gates, and audit logs.

Allowed changes: architecture planning, permission models, approval gate design
Blocked changes: live agent execution, autonomous workflows, secret access, command execution
Manual checks: strict approval gates exist, audit events are immutable, repo access is least-privilege
Risk notes: This stays blocked until authentication, workspace persistence, approvals, and audit operations are validated for production activation.