Connect a product to BuildVouch

Each product keeps its existing Mission Control and detailed Security Register. Add one protected BuildVouch connection panel and a server/CI adapter that submits aggregate release metadata. BuildVouch provides the cross-product history and review view.

The screen inside each app

Place this panel under the app's existing internal Mission Control → Integrations. Follow that app's existing operator authorization and visual system; ordinary customer administrators must not gain platform access.

| Field or action | Behaviour | | ----------------------- | ----------------------------------------------------------------------------------------------------------------- | | Connection | Connected, setup required, last attempt failed or revoked, based on the actual request result | | Source identity | Product, bound repository, environment and configured BuildVouch application ID | | Source vs running build | Latest fetched main commit, build-embedded runtime commit and observation timestamps; missing values show Unknown | | Lovable sync | Only report the commit actually observed in the editor/build system; GitHub merge alone is insufficient | | Database compatibility | Expected migration manifest versus applied migration manifest, with names and checksums | | Deployment identity | Initiator, approver(s) and the human or service executor; unknown identities remain explicitly Unknown | | Last submission | Server timestamp, returned observation ID, stage and bounded error code; no request headers or credentials | | Send current report | Operator-authorized server action; read metadata, submit, record success/failure locally | | Open timeline | Link to the matching BuildVouch product; BuildVouch independently authenticates the user | | Credential management | Secret-store configuration and revocation workflow; never render the token value in the panel |

The frontend must not receive the BuildVouch token or a Supabase service-role key. The backend must recheck operator authorization; hiding a navigation item is not access control. The browser must not choose arbitrary product IDs, destination origins or repositories for the sender.

The adapter

Use a dedicated product-scoped BuildVouch token with evidence:write in the app's server/CI secret store. Give a separate read token only to a server that actually needs to display BuildVouch status. Fixed configuration selects the HTTPS BuildVouch origin, application ID and repository. Do not reuse ChatGPT's GitHub connector credentials.

1. Embed the exact source commit into the build artifact. Read it from the running artifact when reporting runtime identity; do not take it from a browser field or fetch current main as a substitute. 2. Collect aggregate stage results. Send separate lovable_sync, deployment, runtime and migrations reports. Every deployment report must identify the human or service executor. Include the initiator and approver(s) when the provider exposes them. Do not infer an identity from a commit author, PR merger or API-token owner. 3. For migration comparison, generate the expected manifest from the exact deployed commit and the applied manifest from the intended database ledger. Missing historic checksums remain unknown; do not invent them or infer matches from row counts. 4. POST the validated report to the product's /observations endpoint. Retry with the same request key and payload. Use bounded retries and avoid logging secrets or raw provider responses. 5. Submit actual control results through the existing /evidence endpoint, with source links and exact commit/environment. API claims remain unverified until independently checked.

The shared sender is scripts/submit-observation.mjs; it validates the payload, restricts transport to the configured HTTPS origin, refuses redirects and omits credentials from errors. It is a BuildVouch repository script, not an already-installed adapter in the four apps.

Example payload (illustrative only; do not submit these example identifiers as evidence):

{
  "repository": "example/app",
  "environment": "production",
  "commit_sha": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "stage": "deployment",
  "status": "success",
  "observed_at": "2026-09-05T12:00:00Z",
  "request_key": "deployment-observation-unique-id",
  "initiated_by": {
    "provider": "app_adapter",
    "subject": "release-manager",
    "stable_id": "provider-user-17",
    "kind": "human"
  },
  "executed_by": {
    "provider": "app_adapter",
    "subject": "production-deploy-workflow",
    "stable_id": "workflow-42",
    "kind": "service"
  },
  "approved_by": [
    {
      "provider": "app_adapter",
      "subject": "environment-reviewer",
      "stable_id": "provider-user-23",
      "kind": "human"
    }
  ]
}

Product-specific control sources

These are adapter requirements, not claims that the listed checks currently pass. Review the actual repository workflows before configuring any control mapping.

| App | Aggregate evidence to send | Keep inside the app | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | RAQOZ | Golden Journey result, tenant isolation, maker-checker checks, Procurement Control Passport test, migration compatibility | Purchase records, supplier documents, vulnerability details | | CostGrid | Financial reconciliation result, organisation/project/storage isolation, measurement/certification journey, migration compatibility | Project finances, invoices, customer data, raw reconciliation rows | | Synquestra | Compose-to-receipt journey, publication idempotency, workspace isolation, migration compatibility | Draft content, media, social OAuth tokens and publication payloads | | UxerProof | Consent denial/withdrawal, masking, key revocation, workspace/source isolation, deletion tests, migration compatibility | Visitor events, identities, journey payloads and raw AI context |

Start with RAQOZ as an observational pilot. A reporting failure should be visible but must not newly block a production pipeline until an independently reviewed enforcement rollout is approved. The existing check-release.mjs can enforce an exact release decision later; this adapter does not automatically install or activate that gate.

Required integration tests in each app

Prove customer admins cannot access or invoke the panel's server action; tokens remain server-only; one app cannot submit into another; failed sync is surfaced; revoked credentials stop submission; runtime identity comes from the deployed artifact; a deployment cannot omit its executor; provider identities are not confused with commit authors or token owners; missing migration checksums remain unknown; duplicate retries create one observation. Then run the actual authenticated operator journey.

No screen, secret or workflow in RAQOZ, CostGrid, Synquestra or UxerProof is changed by the BuildVouch timeline PR. Roll these adapters out through each canonical repository after its existing operator boundaries and deployment mechanism have been inspected.