FORQA AI-Native SDLC & CI/CD Plan

CTO conclusion

BLOCKED for broad multi-company SaaS CI/CD

PASS WITH WARNINGS for controlled single-tenant/design-partner hardening

FORQA should absolutely adopt GitHub Actions and an AI-native SDLC, but the pipeline must reflect current product reality: the inspected repo is a HubSpot-backed, Entra-authenticated, Supabase Edge Function forecasting app that was intentionally designed as an internal/single-tenant tool.

Priority: do not optimize for faster production deploys first. Optimize for making unsafe deploys impossible.

Immediate risks

Hard-coded PAT in current mirror workflow; treat as compromised.
Production deploy path does not clearly prove verify_jwt=true is applied.
Deploy script omits newer functions.
Scheduled sync auth conflicts with Entra-token validation.
No durable tenant boundary yet.

Evidence reviewed

Jack OS docs

FORQA.md, CTO lane, multi-tenant blocker analysis, CTO deep-work review pack, prior multi-tenant implementation plan.

Repo docs/code

Auth ADR, architecture/deployment docs, production deploy script, workflow YAML, frontend package scripts, Vitest workspace, Supabase configs, migrations, shared auth/client helpers, api-forecast, sync-hubspot, E2E specs.

Current facts

ADR says internal single-tenant; Edge Functions validate Entra then use service-role client; HubSpot is implemented source; Sage actuals were not found in repo evidence.

AI-native SDLC: idea to production

Idea/spec/issue

Every change starts as an issue/spec with outcome, evidence paths, risk class, data touched, acceptance criteria and rollback.

Risk gate

Green: UI/docs/tests. Amber: functions, migrations, auth, sync. Red: production, secrets, Entra, Supabase settings, production data, Sage write-back.

Branch

Use ai/<issue>-slug, human/<issue>-slug, hotfix/<issue>-slug, or release branches. No direct pushes to main.

Agent implementation

AI works in small scoped branches, adds tests, runs local gates, summarizes evidence and residual risk. It never touches production secrets or deploys production.

PR + CI + review

PR template captures risk, tests, tenant/RLS impact, HubSpot/Sage impact, secrets/env impact, rollback and AI model/agent used.

Dev/test deploy

After merge, deploy to non-production Supabase/frontend, run authenticated and unauthenticated smoke tests, run seeded E2E checks.

Release candidate

RC contains SHA, migrations, functions, artifact versions, env requirements, smoke matrix, approvals and rollback plan.

Production + monitoring

Production requires GitHub Environment approval, then migration/function/frontend deploy, smoke tests and watch window.

Workflow architecture

PR CI: secret scan, changed-file policy, frontend build/lint/unit, backend function tests, migration checks, Playwright smoke.
Dev/test deploy: deploy to test Supabase and preview frontend; run smoke/E2E.
Production release: manual approval, preflight, deploy, smoke, monitor.
Scheduled security: dependency audit, secret scan, workflow permission checks, endpoint smoke probes.
AI guard: PR metadata, AI labels, high-risk reviewer enforcement.

Branch + environment model

Recommendation: start simple with protected main, feature PRs, release tags, and GitHub Environments test and production. Add develop only if release contention appears.

test: auto deploy after CI; test-only secrets.
production: required reviewers, main only, no AI auto-deploy.
main protection: required PR, status checks, code owners, no force pushes.

Example PR CI skeleton

name: PR CI
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
  pull-requests: read
  security-events: write
jobs:
  policy-secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0, persist-credentials: false }
      - uses: gitleaks/gitleaks-action@v2
      - run: ./scripts/ci/check-changed-files.sh
  frontend-build-test:
    runs-on: ubuntu-latest
    defaults: { run: { working-directory: frontend } }
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm, cache-dependency-path: frontend/package-lock.json }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --run
      - run: npm run build
  supabase-migration-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
      - run: supabase db start && supabase db reset --local

Supabase rules

Migrations append-only after merge.
Validate migrations from clean state in CI.
Deploy all functions or generated list, not stale hand-maintained subset.
Prove verify_jwt=true for production functions.
Move service-role use behind tenant-aware helpers.
Scheduled/background sync needs a dedicated machine-auth design.

Secrets/env handling

No secrets in YAML, docs, examples, logs, screenshots or AI context.
GitHub Environment secrets for deploy credentials.
Supabase Edge Function secrets for runtime tokens.
Frontend VITE_* values are public only.
Future HubSpot/Sage tokens must become per-tenant encrypted integration config.

Tenant/RLS/security gates

Current state: acceptable only for single-tenant/internal/design-partner mode. Unsafe for multiple customers in one database.

Add tenants and tenant_memberships.
Add tenant_id to every tenant-owned table.
Tenant-scope HubSpot/Sage IDs, pipeline/stage/owner IDs, presets, invoices and customer keys.
RLS deny-by-default with membership-derived access.
Edge Functions resolve tenant server-side and fail closed.
Cross-tenant negative tests become release gates.

Integration gates

HubSpot

Line-item association tests.
Idempotency and stale/deleted handling.
Per-tenant tokens/pipelines/locks/logs before SaaS.

Sage

Not implemented in evidence reviewed.
Read-only actuals first.
Mark must choose product/version and matching key.

AI guardrails and roles

CTO Spec Agent

Drafts specs/issues/risk classification. Strongest reasoning model. Read-only by default.

Implementation Agent

Scoped branch implementation with tests. Strong coding model. No production deploy/secrets.

Test Agent

Regression, RLS, sync, Playwright tests. Avoids product logic changes unless tasked.

Security/RLS Agent

Reviews auth, RLS, service-role usage, secrets and workflow permissions.

Release Manager Agent

Prepares RC notes, checklists, smoke matrix and rollback. Does not approve production.

Rule of thumb: AI may propose and implement scoped changes; humans approve production, secrets, providers, data migrations and SaaS tenant-boundary decisions.

P0

Credential incident response.
Remove/quarantine mirror workflow.
Add PR CI.
Fix deploy consistency and JWT proof.
Decide scheduled sync auth.

P1

Create test/production environments.
Add dev/test deploy workflow.
Add RC process.
Add smoke test scripts.
Add CODEOWNERS and PR template.

P2/P3

Tenancy/RLS test harness.
Service-role guard checks.
Tenant-aware integration tests.
Forecast reconciliation gates.
Sage discovery/spec + sandbox CI.

Acceptance criteria

Baseline is acceptable when PRs cannot merge without CI/review; no credentials are in repo/workflows; deployments use GitHub Environments; all functions are deployed consistently; JWT/unauth smoke tests pass; AI-authored PRs are labelled; and multi-tenant claims are blocked until tenant/RLS/cross-tenant tests pass.

Mark decision questions

Stay single-tenant/design-partner while hardening, or prioritize shared multi-tenant SaaS now?
Is the mirror workflow still needed, and what least-privilege auth model should replace the PAT?
Who approves production: Mark, Jack, or both?
Main-only PR model or develop + main?
What is the authoritative frontend hosting target?
Which Supabase environments exist today?
What secure auth model should scheduled HubSpot sync use?
Which smoke tests define release acceptance?
Which Sage product/version is in scope, and is first integration read-only actuals?
What is the go/no-go date and minimum gate set for the next beta/demo?

Recommended next action: hold a 30-minute Jack/Mark CTO decision session, then implement P0 as one small branch per item.