f9d6b57f0f
The docs lived on one lineage and the fleet code on another. That is why six pages described a shared fleet key as how an agent authenticates, why COLLECTOR-AUTH had to warn that the per-PC credential code was not in the repository it sat in, and why ADR-019 recorded a decision whose implementation was somewhere else. Documentation that cannot see the code it documents goes stale by construction, and no amount of editing fixes that. So the corpus moves here: 84 files, 56 pages, 20 ADRs, the proposals, INDEX.md, llms.txt and both gates. Filenames are unchanged, because a wiki page name is derived from the filename and a rename breaks every link anybody saved. THE POINT OF THE MOVE IS THE CORRECTION IT ENABLES. Every caveat that said "not in this tree" was false the moment the files landed beside the code, so each was rewritten from what is actually here: - COLLECTOR-AUTH gained the real enroll request body, the two bounds on the unauthenticated route (per-IP rate limit, pending cap with stale rows dropped before a real PC is refused), and the rejected pending reason that binds to the endpoint identity rather than the nonce. - ADR-019 now describes an implementation that is present, including its tests, and says plainly that what remains is the FLEET migration, not the code. - proposals/device-identity claimed phase 1 was unbuilt. plugins/computers declares deviceid on the collector schema and prefers it over the older fallbacks. Corrected in the page, its summary and the index. WINDOWS/IIS IS NOW DOCUMENTED AS THE LEGACY PATH, per the product decision, and carefully: it is what production runs today. Every Windows page opens by saying it is supported, not for a new site, and where a new site should go instead. No procedure was cut - an operator on an IIS box at 2am needs these pages to work exactly as well tomorrow. MIGRATE-TOPOLOGY stops being a footnote and becomes the off-ramp, which is why it nearly doubled: what was there did not match how the Docker stack really works here. The Docker material that already lived on this line was kept and given ownership rather than buried under the ported Windows-centric prose: DEPLOY now describes the four services, the migrate service that runs the upgrade chain before api starts, TLS terminated by nginx, and the plugin count corrected from thirteen to seventeen - a number both lineages had wrong. ROADMAP is rewritten from evidence rather than memory: what has shipped, read out of the changelog, the ADRs and the manifests, and ahead of it exactly two items - finalize a distributed release and polish the setup wizard. PROJECT-MAP is generated and was stale; the GENERATOR was what was wrong. --check passes now. API-REFERENCE is retired to a pointer. /api/docs serves 573 operations with derived auth, query parameters and harvested examples, and a hand-written page competing with that is a liability. The file stays so its wiki page and its inbound links survive. AND THE MOVE TURNED ON A SCRUB THAT HAD NEVER RUN HERE. test_docs_publishable keys on docs/*.md, which this line did not have, so it skipped - its own comment predicted what would surface. Porting the corpus activated it and it found 48 lines that must not reach a published wiki: branch names abbreviating the site, assistant-tooling paths, the site name in two deployment pages, and an employee ID in a Windows path that the scrub does not even look for.
Architecture Decision Records
An ADR captures one decision: the context, the decision, the consequences and the alternatives. ADRs are immutable once accepted. A superseded ADR stays in this folder, marked at the top, pointing forward.
Read the index, not the folder. Find the one line that matches your question, open that ADR, and skip the rest. Nothing here is a prerequisite for anything else.
Which decision governs your question
| ADR | The question it answers | Holds? |
|---|---|---|
| 001 | What may a plugin depend on? What is the versioned platform surface? | In force |
| 002 | How is that surface versioned, and what does a plugin's core_version mean? |
In force |
| 003 | How does a plugin reach a site - bundled, or from its own repo? | In force. ADR-013 added the catalog, artifact and signing on top |
| 004 | One instance per site, or one multi-tenant instance for all sites? | In force, except its "Migration strategy" section, replaced by ADR-008 |
| 005 | Are metrology instruments a separate asset class from machinery? | Superseded by 018. Answer reversed |
| 006 | How does a plugin accept data pushed in from outside? | In force |
| 007 | What version is the PRODUCT, as distinct from the plugin contract? | In force |
| 008 | Whose Alembic chain owns a plugin's tables? | In force |
| 009 | What happens when someone opens a URL belonging to a disabled plugin? | In force |
| 010 | How does a plugin add UI without editing core Vue files? | In force |
| 011 | Why is the code called machines and what happened to machinetypes? |
In force |
| 012 | Does ShopDB own GE-Enforce manifests, and does it own the engine? | In force |
| 013 | How does a site ship only the plugins it chose, and how is plugin code trusted? | In force |
| 014 | Does a lean site still create tables for plugins it never installed? | In force |
| 015 | Where may one site's hostnames, shares and defaults live? | In force |
| 016 | How does a bay get a controller credential without a cleartext file on a share? | Superseded by 019, and never built. Do not build against it |
| 017 | How does the floor map hold more than one floor and more than one building? | In force |
| 018 | Where do CMMs and vision systems live now that measuringtools is retired? |
In force |
| 019 | How does the server know WHICH PC is calling, and what replaced the fleet-wide key? | In force. Built, not yet merged into this tree |
Related decisions that are not ADRs, kept as records of why something was built: docs/proposals.
Status vocabulary
The Status: line at the top of each ADR uses these, and nothing else:
- PROPOSED - drafted, awaiting decision.
- ACCEPTED - in effect.
- SUPERSEDED by ADR-NNN - replaced. The link forward is part of the status, and the superseded ADR carries a note at the top saying not to build against it and what changed.
- DEPRECATED - no longer in effect, with no replacement.
Authoring
- Copy the most recent ADR as a template and increment the number.
- Start the file with a
docmetacomment, before the H1. ADRs arepurpose: explanation. - Add a row to the table above: the QUESTION it answers, not its title.
- Add it to docs/INDEX.md too - under "Decisions" while it is
current, under "Archive" once it is superseded. It has to be a table ROW
with its real line count, not a mention in a paragraph:
tests/test_docs_index.pyfails on an ADR no row routes to, and on a row whose line count is stale. - Never edit an accepted ADR's decision. Supersede it with a new one, and mark the old one at the top - ADR-005 and ADR-016 are the worked examples.