# RobCo U.O.S. — Local Artifact Archive (PRIVATE) **This is the PRIVATE companion backup to the PUBLIC repo [`zerckzzyHD/Robco-UOS`](https://github.com/zerckzzyHD/Robco-UOS).** It durably backs up the project artifacts that live **only on the owner's machine** — they are gitignored (or entirely outside) the public repo, so without this archive they exist in exactly one place and one disk failure loses them. This repo is deliberately **private** and must stay that way: some of these docs are internal working notes never meant for public release. ## Corresponds to public repo commit > **`ce368bd`** - last synced **2026-07-24** Each sync stamps this line with the public repo's current `HEAD` at the moment of the sync, so you can always tell which state of the code this archive matches. ## What's in here | Folder | Files | What it is | | ----------- | ----- | ---------- | | `library/` | 5 | Deep Claude-facing reference docs — `BRAIN_DUMP.md`, `CODE_MAP.md`, `TEST_CATALOG.md`, `PROMPT_MULTI_AI_REMAKE.md`, `MANIFEST.txt` (gitignored in the public repo). **Mirrored** (see below). | | `planning/` | 580 | Every audit, plan, synthesis, slate, and design mockup — the full planning history and mockup image set (outside the public repo). **Additive-only** (see below). | | `memory/` | many | The orchestrator's persistent memory — **all** discovered stores, one per subfolder (see below). `memory/_CAPTURE_MANIFEST.txt` records which stores were captured and how many files came from each. | | `graveyard/`| 6 | Ideas tried or proposed and deliberately ruled out, one `<slug>/record.md` each, pointing at the original in-archive decision record. Read through the museum's GRAVEYARD room. | | `museum/` | — | The archive museum — a generated, browsable view of everything above. **Entry point: [`museum/site/index.html`](museum/site/index.html)** (see below). | ## The archive museum **Open [`museum/site/index.html`](museum/site/index.html).** Not `museum/index.html` — that path has never existed; if anyone reports the museum "missing", this is the correction. It is a generated, browsable view of this archive: a lobby, one room per release, the standing tools, the graveyard, a growth exhibit and full-text search over every document. It is a plain static site — no build step, no dependencies, no server. Double-click the file, or read it on GitHub through the rendered file view. - **Generator:** `museum/generate.mjs`, Node built-ins only. It walks this archive once into a single manifest and renders every page from that one manifest. - **Regenerated AT A RELEASE, not on every sync**, and **pinned to the released state** — never to `dev` and never to whatever is checked out. The pinned release is recorded in `museum/release-pin.json` and advanced only by the release ritual: ```powershell node museum/generate.mjs --release # pin to the newest shipped tag and rebuild node museum/generate.mjs --release=v2.8.5 # pin to a specific shipped tag ``` The pin must name a tag that already exists — a version that has not been tagged has not shipped, and the museum will not render it as a release. Because the museum tracks releases rather than a moving branch, it is **current by definition between releases**. That is what makes its NOT CURRENT notice worth reading: it can only mean *a release shipped and nobody regenerated the museum*. `sync.ps1` no longer regenerates; it runs `node museum/generate.mjs --check`, which reports that one condition and builds nothing. It remains a **ritual, never a gate**: any failure inside it leaves the previous museum intact, leaves the pin unadvanced, exits 0, and cannot block a sync or a release. - **Release measurements are frozen, in `museum/release-measurements.json`.** Line count, file count and the **test count** are measured from each release tag once and never updated. The test count is measured by exporting the tag and running the runner that tag's own `package.json` declares — it is never copied from the changelog. (Measuring a *released* count is not the retired count-sync protocol returning: that retired the obligation to keep a **live** number in step across many files, and explicitly kept frozen per-release counts as history. This is that, measured rather than typed.) - **`museum/site/` is committed.** It is regenerable output, but the owner reads this archive through GitHub on a phone, so output living on one disk defeated the point. Only `museum/.cache/` and `museum/.build-tmp/` are ignored. - **`museum/accounts/<version>.md` is the only hand-written content** in the whole museum — one frozen prose account per release. A missing account renders "ACCOUNT NOT FILED"; nothing is ever written in its place. - **No wall-clock timestamp** anywhere in the output, so an unchanged archive regenerates byte-identically and a sync produces no spurious diff. ### How `memory/` is laid out There is more than one memory store on this machine, in two ecosystems, so the sync backs up **every** one it finds into its own clearly-named subfolder rather than guessing which is canonical: - `memory/project-<project-slug>/` — a CLI project's memory (`~\.claude\projects\<slug>\memory`). This is the store the project's orchestrator actually reads and writes; the important one is `project-C--Dev--GEM-Website-version`. - `memory/localmode-<guid>/` — a desktop local-agent-mode session's memory. Empty stores are skipped (and reported); the sync fails loudly rather than push a backup with no memory at all. `_CAPTURE_MANIFEST.txt` is the at-a-glance record of what landed, so a run that ever captures the wrong or empty store is visible in the tree instead of hidden behind "sync complete". Nothing here contains credentials — it was secret-scanned before the first push, and re-scanned 2026-07-18 (no API keys, tokens, private keys, `.env` files, or service-account JSON). The only key-shaped strings in the public app are the client-side Firebase/reCAPTCHA IDs that already ship publicly, and none of those appear in these docs. The ~172MB snapshot **zip** and its `README.txt` also sit in this working folder but are **not** committed (`.gitignore`) — the zip exceeds GitHub's 100MB per-file limit, and the three folders above already hold the same content in a browsable, diff-able form. ## Additive vs mirrored — what can and can't be deleted from this backup Not every folder is treated the same way, and the difference is deliberate. It follows the main project's own **3-class model** for local-only docs (`CLAUDE.md`): LIVE (actively maintained), GENERATED (produced by a script), and ARCHIVE (frozen point-in-time snapshots). The class decides how the sync keeps each folder current, and the decision is made at the **folder level** because that is the only place it can be made reliably: - **`planning/` → ARCHIVE-class → additive-only.** The audits, plans, mockups, and slates under `planning/` are frozen snapshots. Once a file is captured here it is kept **forever** — even after the owner deletes it from his working `planning/` folder. This is the whole point of the archive: he can clear `planning/` once an audit or mockup has served its purpose **without losing the record**. New and changed files are still copied and updated on every sync; the only thing additive-only removes is the *deletion* step. (Under the hood: `robocopy /E`, no `/PURGE`.) - **`library/` → LIVE/GENERATED → mirrored.** These docs are actively maintained, so an updated version **replaces** the old one rather than piling up stale copies. Git history already preserves every prior version, so nothing is lost. (Under the hood: `robocopy /MIR`, which purges backup files that are gone from the source.) - **`memory/` → live agent state → mirrored** per store. A deleted memory file is an intentional consolidation, and git history preserves it, so this folder tracks the source rather than accumulating. **The safe direction is "never delete."** A wrong call that keeps too much is harmless; a wrong call that deletes is exactly the loss this archive exists to prevent. So if a new synced source is ever added and its class is unclear, it should be treated as additive. **It's visible, not something you have to trust.** Every sync writes [`ARCHIVE_RETAINED.md`](ARCHIVE_RETAINED.md) listing the `planning/` files that are in this backup but no longer in the owner's working folder — the additive set, made browsable — and prints a `N archive artifact(s) RETAINED that are no longer present locally` line in its run summary. If that list is empty, every backed-up planning file still exists at the source. ## How to refresh it From this folder, in a normal PowerShell window, run: ```powershell ./sync.ps1 ``` That one command re-copies all three source locations over this working copy, re-stamps the commit line above with the public repo's **current** `HEAD`, checks whether a release has shipped that the museum has not been regenerated for, then commits and pushes to the private remote. The sync does **not** regenerate the museum — see the cadence note above. To rebuild the museum against its existing pin, without a sync: ```powershell node museum/generate.mjs ``` To advance it to a release that has just shipped (the release ritual): ```powershell node museum/generate.mjs --release ``` ### If the copy sources ever move The `library/` and `planning/` source paths are defined at the top of `sync.ps1` and are stable (inside the public repo working tree). The **memory** sources are **not** hardcoded — the script discovers every store at runtime (both `~\.claude\projects\*\memory` and the desktop local-agent-mode `…\<guidA>\<guidB>\agent\memory` locations, including the packaged-app path), so a fresh session or a changed GUID needs no edit. If a memory *root* ever moves, the discovery lives in `Get-LocalModeBases` / `Find-ProjectStores` in `sync.ps1`.