Country OS — _global

This is not a country. It is the cross-country workspace: repo-wide and platform-wide maintenance that isn't tied to any single country's business — work that benefits every site. Tasks here own the health of the shared application repos (Sentry triage, PR review follow-up), not a market.

Country workspaces (de, tn, …) run their business. This one runs the plumbing underneath all of them. If a task only makes sense for one country, it belongs in that country's workspace, not here.

Historically these tasks lived in countries/fr/ because France is Selectra's main country and the cms was "its" repo — that conflation ended 2026-08-11 when this workspace was created. The fr history (journal, triage records, review rules) moved here unchanged: it is this workspace's history.

Where things live

The repos are declared in orchestrator/src/repos.yaml — that file is the source of truth for where each clone is, which branch to work from, and which Sentry project reports on it. A run is told the same facts in its prompt. All are Laravel.

cms — the monorepo hosting every site. No admin UI, content is Blade files in git.

• Sites: sites/<domain>/ (pages, config)
• Shared verticals/data: departments/<name>/
• App code: app/ (controllers, services), routes/
• The monorepo has its own Claude skills — use them when relevant.

telecom — the telecom comparator (comparateur.selectra.info/telecom). France live, Belgium in progress. A single application, standard Laravel layout.

renovation — the Renovation API, part of Web Sales Telecom. A single application, standard Laravel layout.

Each repo has its own CLAUDE.md. When you are working in one, it governs — read it before you change anything there.

Hard rules

1. Maintenance, not features. Fixes here must be minimal, mechanical and low-risk: handle the exact failing case, no refactors, no behavior changes on the happy path. Human teams own every site's roadmap.
2. All changes go through git branches named countryos/global/<date>-<topic> (no underscore — reviewers see this name), then a DRAFT PR to that repo's base branch — never commit to a base branch directly, never merge or mark a PR ready. One repo per branch and per PR: they are separate remotes with separate reviewers, and a branch spanning two of them cannot be reviewed by either.
3. Never invent factual data. If a fix needs a real-world fact (tariff, phone number, address), stop and flag it instead of guessing.
4. Never touch vendor/, dependency manifests (composer.*, package*), CI/deploy config, or .env* files.
5. Match each site's language and the conventions of the code you edit.
6. memory/review-feedback.md is binding. It holds rules distilled from human PR reviews. Read it before changing any code; never ship a pattern a reviewer has rejected. If a rule seems to forbid the only viable fix, classify the issue REPORT instead of overriding the rule.
7. As few comments as possible in the code you ship. A comment says why, and only when the reason is genuinely unusual. Delete it and re-read the code: if it still makes sense, it stays deleted. Configuration files are the exception — see the full rule and its worked examples in memory/review-feedback.md.
8. Blast radius is what the repo makes it. In cms, a fix in app/ or departments/ serves dozens of sites in several languages: "safe for the site that errored" is not the bar, "safe for every site touching this code" is. In telecom and renovation — single applications — shared code has one caller set you can actually read, so the same caution would just be superstition. Judge the reach of the code you are touching, in the repo you are touching it.

Memory

memory/journal.md is your run journal — read it at the start of every run, append a dated entry at the end. Durable lessons go to memory/ as separate files.