Consolidate three web repos into one — embeddedos-org serves a 404 and is still being committed to

[srpatcha]

The organisation has three web repositories. One serves the public site, one
serves a 404 while still receiving weekly commits, and the third is a full-stack
application with no deploy configuration in version control.

This is the consolidation plan, and the evidence behind it.

What exists

repo	commits	since	Pages status	serves
embeddedos-org.github.io	98	2026-04-03	built	the live site — 12 nav sections
embeddedos-org	29	2026-05-04	404, no source, no URL	nothing
www.embeddedos.org	—	—	built, no CNAME	Express + React + Drizzle app

embeddedos-org.github.io and embeddedos-org share 110 file paths and have
no common git ancestor. They are independent copies, not a fork, and they
have diverged in both directions:

embeddedos-org.github.io   index.html  1018 lines, last changed 2026-07-11
embeddedos-org             index.html   933 lines, last changed 2026-08-24

The harm, concretely

embeddedos-org publishes nothing:

$ gh api repos/embeddedos-org/embeddedos-org/pages
status: 404   url: None   source: None

$ curl https://embeddedos-org.github.io/embeddedos-org/
HTTP 404

and it received real work as recently as 2026-08-30:

2026-08-30  Fix stale org-profile claim in README; remove orphaned style.css.bak
2026-08-24  fix(seo): make canonical URLs absolute
2026-08-24  chore: untrack test-screenshots/, 66 MB of generated output
2026-08-24  fix(ebot): stop injecting a second FAB with a duplicate id
2026-08-24  test: guard the mobile-nav selectors instead of dereferencing null

An SEO fix, a duplicate-element bug fix and a null-dereference guard, all applied
to a site nobody can load. Meanwhile the live repository still carries the
style.css.bak orphan that was cleaned up in the dead one.

Survivor: embeddedos-org.github.io

It serves the site, has 3× the history, and is the <org>.github.io name GitHub
reserves for the organisation page. Not a close call.

But six files must be salvaged first

embeddedos-org holds substantive work that does not exist in the live repo:

file	why it matters
scripts/build-deploy.py	HTML/CSS/JS minification for a deploy branch — the only deploy tooling in either repo
.github/workflows/health-check.yml	weekly scheduled uptime check
.github/workflows/lint-readme.yml	README lint on push
.github/dependabot.yml	dependency updates
tests/simulation/test_mobile_full_simulation.py	mobile simulation coverage
package-lock.json	pinned dependency tree

Archiving before porting these loses them. The deploy script in particular is
the closest thing the organisation has to a reproducible web deploy.

The deploy problem is worse than the repo problem

www.embeddedos.org — the production site on the custom domain — is
Express + React/Vite + Drizzle ORM with a database, plus e2e, security,
performance and accessibility suites. It cannot be GitHub Pages.

It contains no deploy configuration at all: no vercel.json, no
netlify.toml, no Dockerfile, no render.yaml, no fly.toml, and its only
workflow is claude-code-review.yml. Neither Pages site has a CNAME.

So the live production site is deployed by hand, or from something outside
version control, and nothing in the repository records how. That is a larger
risk than the duplication and should be fixed first.

Plan

1. Wire the deploy into version control. Record how www.embeddedos.org
reaches production. Until this exists, nothing else is safe to move.

2. Port the six files from embeddedos-org into embeddedos-org.github.io,
and remove the style.css.bak orphan the dead repo had already cleaned.

3. Archive embeddedos-org with a README pointing at the survivor. Archive
rather than delete: 29 commits of history stay readable.

4. Set the CNAMEs so the domain architecture is real rather than aspirational.

5. Then restructure, once there is one repo and a working deploy:

web/
├── apps/
│   ├── www/          static marketing, blog, news, research  -> CDN
│   ├── members/      the Express + Drizzle application       -> server
│   └── status/       status page                             -> separate host
├── content/          MDX: blog, news, press, case-studies, research
├── packages/ui/      shared brand components
└── infra/            DNS, CNAMEs, deploy workflows

Two design notes

Subdomains are not repositories. research., events., training. and
community. are static content — collections in content/, not applications.
The proposed 21 marketing and 16 research categories are a content taxonomy:
37 directories, which is fine, and 37 repositories, which would not be.

docs.embeddedos.org should build from the code repositories, not live here.
ebuild now has a test asserting every command shown in its README exists in the
CLI (embeddedos-org/ebuild#89). That check works only because the README and the
CLI are in the same repository. Move documentation away from the code and it
becomes a cross-repository problem nobody solves — which is how eNet's README
described a shipped subsystem as "Planned", and how EoStudio published an
ebuild invocation that was never valid CLI. Narrative guides can live centrally;
reference documentation should be generated from the repositories it describes
and aggregated at build time.