L00 current pipeline map

This lesson is the delivery-platform baseline. It maps what exists today in fos-workbench and the sibling fos repo without redesigning either set of workflows.

The point is to separate CI, CD, validation-only automation, artifacts, gates, and environments. Once those labels are clear, a workflow file stops looking like a blob of shell commands and starts looking like a delivery graph.

Current operating model

fos-workbench is the tutorial/docs repo. Its delivery path validates lesson code, generated references, docs-site content, and analytical surfaces, then publishes the public tutorial/docs surface to Cloudflare Pages on main.

The sibling fos repo is the application repo. Its delivery path validates the outliner application on pull requests, deploys staging from main, and deploys production from tags or a manual release after the GitHub production environment gate.

Azure is not part of the current delivery-platform operating model. There is no automatic Azure GitHub Actions workflow. The deploy/azure/ files remain as deployment-target historical context for fos-workbench; they are not the current way the tutorial/docs site or the sibling fos application is shipped.

Sandcastle is issue-to-PR and branch automation feeding CI, not CI/CD itself. It can choose an issue, prepare a worktree, push a branch, and open a pull request. GitHub Actions still owns validation, artifact production, environment gates, deployment, and smoke checks.

fos-workbench: tutorial/docs publishing

The main workflow is .github/workflows/ci.yml.

Trigger	Delivery meaning	What runs
Pull request to main	CI	Validate editor code, generated OpenAPI references, root typecheck/test, Evalite gate, serving/data-platform samples, dbt, docs build, serving tests, Dagster checks, and streaming marker e2e.
Push to main	CI plus CD	Run the same validation shape, then deploy the docs site after the editor and serving jobs have produced the required artifacts.

The editor job is CI. It installs Node dependencies, checks generated OpenAPI client and docs reference drift, runs the root typecheck and test suites, runs the Evalite gate, and snapshots assistant evaluation results for the docs site.

The serving job is CI with build artifacts. It validates the app-contract schema, loads EB-NeRD, Adressa, and MIND samples, runs dbt, generates dbt docs, builds the docs site with generated references, runs serving pytest suites, validates Dagster definitions, and runs the streaming marker e2e. It uploads generated docs references and the serving DuckDB warehouse for the downstream docs deploy.

The deploy-docs job is CD. It runs only on a push to main, after both CI jobs pass. It downloads generated references, the evaluation snapshot, and the serving warehouse; writes the Operator hub status snapshot; builds the docs site; builds the Observable analyst dashboards; merges the dashboard bundle under docs-site/dist/dashboard; deploys docs-site/dist to the fos-workbench-docs Cloudflare Pages project; then smoke-checks public analytical-surface routes.

The public environment is https://dataplatform.kodeklaus.dk. The published artifacts are the Astro docs site, generated API/data references, the Operator hub status snapshot, and the Observable dashboard bundle mounted at /dashboard/.

fos-workbench: archived Azure target

.github/workflows/azure-deploy.yml is intentionally absent. Azure automation must not build, push, what-if, or deploy from GitHub Actions in this repo.

The remaining deploy/azure/ tree is historical deployment-target material. Manual operator commands may still validate that archive when someone is explicitly studying it, but it is not a CI/CD lane, not the operating model for current tutorial/docs publishing, and not the sibling fos application release path.

Sibling fos: app staging and production

The sibling fos repo has a different delivery shape because it ships an application, not a tutorial/docs surface.

Workflow	Trigger	Delivery meaning	Environment
pr.yml	Pull request to main, push to fos-orch/**, or manual dispatch	CI	None
staging.yml	Push to main affecting apps/outliner/**, or manual dispatch	CD	Cloudflare Pages staging
release.yml	v* tag push, or manual dispatch	CD with release gate	Cloudflare Pages production
sandcastle.yml	Hourly schedule, or manual dispatch	Automation feeding CI	Sandcastle worktree and pull request branch

pr.yml builds apps/outliner, runs Svelte typechecking, unit tests, and an advisory high-severity npm audit. That is CI because it proves a proposed app change without deploying it.

staging.yml deploys the built app to the fos-app-staging Cloudflare Pages project. Its smoke check verifies that /login is reachable without a Cloudflare Access redirect and that a private workspace API returns an auth failure rather than public data. That is CD to a staging environment.

release.yml deploys production to the fos-app Cloudflare Pages project from a v* tag or manual dispatch. It uses the GitHub production environment, which is the human approval gate for the release. Its smoke check verifies the Better Auth provider boundary and private API authorization. That is CD to production.

sandcastle.yml is not a deployment workflow. It runs the issue loop on a self-hosted Spark runner, finds ready issues, prepares a clean worktree, installs dependencies, builds the Sandcastle image, runs Sandcastle, and lets the resulting branch or pull request enter the normal validation path.

Gates, artifacts, and environments

Category	fos-workbench	Sibling fos
CI gates	Typecheck, tests, generated-reference drift, Evalite, dbt, pytest, Dagster validation, streaming e2e.	Build, Svelte typecheck, unit tests, advisory audit.
CD gates	deploy-docs requires editor and serving jobs to pass and only runs on main.	Staging requires main; production requires a tag/manual dispatch plus the GitHub production environment gate.
Artifacts	Generated OpenAPI/dbt references, evaluation snapshot, serving DuckDB warehouse, Astro docs bundle, Observable dashboard bundle.	SvelteKit build output deployed by Wrangler to Cloudflare Pages.
Environments	Public Cloudflare Pages docs site at dataplatform.kodeklaus.dk, including /dashboard/.	Cloudflare Pages staging at fos-app-staging.pages.dev and production at fhest.dk.
Smoke checks	Public analytical-surface route checks after docs deploy.	Staging single-gate auth reachability; production Better Auth boundary and private API authorization.

Checkpoint questions

These checkpoint questions cover CI, CD, gate, artifact, and environment identification in the current repos.

1. Which parts of fos-workbench are CI, and which part is CD?
2. Which artifacts does fos-workbench produce before the docs deploy job can publish to Cloudflare Pages?
3. What gate prevents a failed serving job from publishing the docs site?
4. Why is the sibling fos staging workflow CD rather than CI?
5. What environment gate exists before sibling fos production release?
6. Why is Azure excluded from the current delivery-platform operating model even though an Azure workflow exists?
7. Where does Sandcastle stop and GitHub Actions CI/CD begin?
8. If a pull request changes only lesson prose, which current repo is being validated: fos-workbench or sibling fos?