The Atlas MikeOSS.Azure's docs, bound to the code — and to the migration that built it
108 documents

How the fork is published

The three-tier model that lets this repo be an open fork without leaking the proprietary deployment code — and the rules that route every file.

Tier C — proprietary retention (rationale)

This document explains what stays out of the public AGPL fork and why — even though the AGPL covers everything that "interacts with users over a network."

Tier C content does not stay frozen in the dev repo. It ships to a separate private deploy repository (Repo 3 in the three-repo topology) so the marketplace listing has its own home with its own commit history. The publication mechanism is documented in 07-private-deploy-repo.md. This document is the rationale for why each Tier C item exists at all and why it should not appear in Repo 2.

AGPL §13 obliges us to publish the source of the application that network-attached users interact with. It does not oblige us to publish:

  • The build pipeline, CI, or signing infrastructure that produces the binary.
  • The provisioning templates that stand up the cloud resources the binary runs on.
  • The packaging that lists the application on a marketplace.
  • Operator-facing tools that automate one-time setup outside the application's runtime (Entra app registration, Azure OpenAI resource provisioning, role assignments).

Tier C contains exactly those artefacts. They are the how-it-gets- to-Azure layer; the published Tier B fork is the how-it-runs-when-it-gets-there layer. A determined operator with the Tier B fork can deploy Mike themselves; the Tier C artefacts make it dramatically easier — and that ease is the marketplace proposition.

Files retained as Tier C

This is the canonical list. Anything not on this list and not on 01-classification.md Tier C should be assumed Tier B.

Bicep templates (infra/)

Why retained: these encode every parameterization choice (SKUs, NAT gateway, Postgres backup window, Container Apps internal-only ingress trust model) we made when designing the deployment. The PostgREST trust-model rationale embedded in containerapp-postgrest.bicep's comments is itself the most valuable single piece of architectural IP in the deployment.

Operator deployment scripts

  • deploy.ps1 — single-command full deployment.
  • check-azure.ps1 — read-only health check tied to our resource names.

Why retained: these are the marketplace's "I clicked Deploy" button. Publishing them is publishing the marketplace.

One-time-setup operator scripts (scripts/install/)

Why retained: these are the operator-side companions to the /install configurator. They run on the operator's machine with their own az login to do work the Container App's Managed Identity cannot do (Entra app creation, AOAI Foundry deployment, role assignment to the deployer). They are the "Marketplace Onboarding Wizard" of our IP and need to be inspectable by us across customers.

The published /install route degrades gracefully when these scripts are absent — see 06-agent-runbook.md for the runtime check the agent must verify.

CI / supply-chain plumbing

  • scripts/setup-github-oidc.sh — provisions our GitHub Actions federated identity. Internal CI plumbing.
  • scripts/mirror-postgrest.sh — mirrors the upstream PostgREST image into our ACR. Internal supply-chain step.
  • .github/workflows/deploy.yml (if/when added) — internal CI that builds, pushes, migrates, and promotes. Not for public consumption.

Deployment-specific documentation

Internal issue and design docs that reveal IP

A subset of docs/issues/azure-migration/ is Tier C because it references concrete deployment artefacts. The rest is Tier B (application-layer design discussion).

Tier C (do not publish):

  • 001-bicep-infra-foundation.md
  • 002-acr-and-postgrest-mirror.md
  • 003-postgres-provisioning.md
  • 005-storage-provisioning-and-blob-adapter.md
  • 006-cae-postgrest-backend-deployment.md
  • 007-cicd-pipeline.md
  • 007-implementation-plan.md
  • 015-implementation-plan.md
  • 015-managed-identity-db-auth.md
  • 016-marketplace-listing.md
  • 023-install-configurator.md
  • 029-bicep-drift-reconciliation.md

Tier B (do publish, sanitized):

  • 004-schema-migration-tooling.md
  • 006.1-storage-provider-interface.md
  • 006.2-auth-provider-interface.md
  • 008-backend-auth-provider-abstraction.md
  • 008.0-local-auth-provider.md
  • 009-backend-entra-jwt-validation.md
  • 010-tenant-group-enforcement.md
  • 011-user-bootstrap-and-profile-endpoints.md
  • 012-frontend-userprofile-refactor.md
  • 013-frontend-msal-auth-provider.md
  • 014-postgrest-jwt-switch-to-jwks.md
  • 017-local-first-auth-boundary.md
  • 018-frontend-api-token-boundary.md
  • 019-frontend-hosted-dependency-isolation.md
  • 020-azure-blob-storage-first.md
  • 021-backend-postgrest-client-boundary.md
  • 022-frontend-deployment.md
  • 024-postgrest-caddy-sidecar.md
  • 025-diagnostics-page-lockdown.md
  • 026-surface-frontend-silent-fallbacks.md
  • 027-msal-silent-token-refresh.md
  • 028-api-prefix.md

Stays only in Repo 1 (not even Tier C): docs/migration/ (this directory) — internal planning that has no place in either the public fork or the private deploy repo.

Internal harness configuration

  • .claude/ — internal agent commands and skills. Not relevant to either publication target. Stays only in Repo 1; remains in .gitignore on Repo 2 and Repo 3.

Files that look proprietary but are NOT

For clarity, these files do publish to Tier B even though they contain Azure-shaped code:

The line is: runtime application code → Tier B, even when it imports @azure/*. Provisioning, packaging, and operator-side automation → Tier C.

What this leaves a third-party operator with

If someone clones the public Tier B fork and wants to deploy it on their own Azure tenant, they get:

  • Application code, ready to build and run.
  • Local-stack docker-compose for development.
  • A schema-migration story (node-pg-migrate).
  • A /install route that, once their KV is provisioned and the Container App's Managed Identity has KV access, lets them configure the app through a browser.
  • A list of prerequisites (docs/azure-prereqs.md) describing what Azure resources they need.

What they don't get:

  • One-click ./deploy.ps1.
  • Bicep modules to copy-paste.
  • The marketplace UX.

That gap is intentional and is what justifies the marketplace listing's price point.