theam / theam/facility

Automate stable workspace public-site provisioning

Open
#376 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
71
Forks
64
Avg merge
15h 38m
Merged PRs (30d)
66

Description

Goal

Automatically provision a dedicated stable public site per workspace/service.
Today FACILITY_PREVIEW_SITES supports exact bindings, but an operator must create
the distribution, update configuration and refresh the API. Merging Compose code
alone does not create a public origin.

This remains a follow-up after the manual-site integration pilot for AIFindr D3
(theam/aifindr-dev-environment#30). Generic story facts, integrationState and GitHub
notifications are now in #374 / #375; the project-owned Auth0 consumer is in
theam/aifindr-dev-environment#31. They are not part of provider provisioning here.

Incremental plan

  1. Add a provider-neutral stable-site provision/reconcile contract, initially for
    the CloudFront path supported by the internal deployment. Bind exact
    org/project/workspace/service idempotently and persist provider identity.
  2. Create a disabled distribution/per-site credential, register and read back the
    mapping, refresh configuration, then publish the configured origin after gateway
    routing/authentication checks. Do not require the app's Auth0 login before
    reporting the origin: its consumer needs that origin to register the callback.
  3. Keep site/storage separate from compute. Suspension retains identity. Never
    reassign browser origins across workspaces; coordinate retirement so external
    cleanup finishes before removing its configuration/tombstone.
  4. Make site changes observable by the generic lifecycle notification mechanism.
    No Auth0-specific script or provider credentials in agent workspaces. Consumers
    own business policy and use Facility's generic integration state if needed.
  5. Add a scoped operator workflow in the private deployment repository. Existing
    release-on-merge remains; its role currently does not provision CloudFront sites
    or write preview configuration. Review exact IAM, cost and secret targets with
    deterministic fake-provider/denial/recovery tests before live application.

Acceptance

A fresh story obtains an isolated root-origin site without manual per-story cloud
work. Sleep/resume retains identity. Public origin publication enables project
integrations to complete login setup; retired stories can clean owned registrations
without destroying retained work. A second story is isolated. Failed/partial
provisioning and retries cannot duplicate, cross-bind or expose a workspace.

No automatic provider or real D3 preview is claimed by creating this issue.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing manual-site integration and CloudFront path in the private deployment repository; the issue does not identify files or tests. Trace configuration refresh, gateway routing and authentication checks, lifecycle notifications, and the provider boundary before defining the reconcile contract. Done means isolated, idempotent provisioning with retained identities, safe retries and recovery, scoped cleanup, and deterministic fake-provider and denial tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.