Read before you write any infrastructure code

Architecture Constitution

Five rules, non-negotiable across every team's pipeline this trimester. Every one of them exists because a TR2 team lost real time to the mistake it prevents. Read this before your first commit — not after your first outage.

The Rules

1. No Cloudflare Workers. Ever.

Not for a "quick" API proxy, not for a webhook relay, not for anything. This was tried and abandoned in TR2 — the free-tier limits and cold-start behaviour made it unreliable as a dependency for anything graded.

WHY — it silently degrades under real usage and is hard to debug from outside the Cloudflare dashboard, which most teams don't have shared access to.

2. GitHub API is the shared datastore. Not localStorage, not a database only one teammate can reach.

Anything that needs to sync across devices or across teammates — sprint data, scores, logs — gets written through the GitHub API (Contents endpoint or a committed JSON file), not browser-local storage.

WHY — a TR2 team's tracker relied on localStorage and failed live in front of the class the moment two people opened it on different machines. GitHub gives you one shared source of truth for free, already inside your existing repo.

3. Dashboards fetch only from a public path — never an unauthenticated call to a private repo.

If your dashboard is client-side JavaScript running in a browser, it cannot hold a secret. Any private-repo data it needs must be published by a script (a GitHub Action, a scheduled job) to a public file first, and the dashboard reads that file.

WHY — a browser-side fetch to a private repo with no token just fails silently. This exact bug broke a TR2 dashboard's live refresh for days before anyone noticed the numbers were stale.

4. One CI workflow file, one standard name: main-pipeline.yml.

Whatever your team's automated pipeline is called internally, the GitHub Actions workflow file that runs it is named main-pipeline.yml.

WHY — TR2 teams each named theirs differently (python-checks, Auto Prediction, Update Market Data...), which made "is your pipeline actually running" impossible to check at a glance across five teams. One name, one place to look.

5. A green checkmark is not proof of output. Your pipeline must verify it actually produced something new.

Add an explicit guard step: after your pipeline runs, check that new data was actually committed (a changed file, a new row, a new timestamp) — don't just trust that the job exiting with code 0 means it worked.

WHY — a TR2 pipeline passed CI every week while silently failing to commit any new data, for weeks, because "the script ran without error" and "the script did its job" turned out to be two different things.

What This Means Day-to-Day

Before you add any new service to your pipeline, ask: "does this route around GitHub as the datastore?" If yes, don't.
Before your dashboard fetches anything, ask: "is this path public, or would this call fail with no token?" If it would fail, publish the data first.
Name your CI file main-pipeline.yml from the very first commit — renaming it later just means old runs vanish from the history you can point to.
Your Sprint 2 submission should already include an output-verification step, not bolt one on later.