The Serena knowledge base did not move with the code: eight memories are anchored to the archived legacy repository

[rldyourmnd]

Found while auditing memories, documentation and skills for currency on 24 August. Related to #22, and probably the same root.

Where the knowledge base actually is

The eight core-* memories Serena serves for this project live in
~/Developer/control-plane/github-device-sync/.serena/memories/ — the legacy superproject, archived on 2026-08-23. They are tracked in that repository's git.

Their provenance points there too:

scope_id:      repo_01KX7BV07RHD6KRA4Z4J0KCHGR      <- legacy repository id
source_commit: ff2ae35f72d9b385369a4831d6c5a65fa369c984
verified_at:   2026-08-22T21:27:00Z
status:        verified
generated_by:  gds-memory-compiler

ff2ae35 is ci: align GDS with the public fleet toolchain in the legacy repository. It does not exist in this module.

For comparison:

	scope_id
memories claim	repo_01KX7BV07RHD6KRA4Z4J0KCHGR
estate	repo_01M0F128B3N0VGB1A71Y5SCQGM
this module	repo_01M0EZ7TB3KNXNSP78Z8M64WXG

This module has zero Serena memories. So does the estate.

What is and is not wrong

gds memory validate in the legacy checkout returns succeeded, all eight verified. They are not corrupt and their digests hold — against the archived repository they describe. The defect is not corruption, it is location: the code moved to NDDev-OpenNetwork and the knowledge base stayed behind, still answering as authoritative to any agent opening that directory.

That is the same shape as #22, where the installed gds binary is built from the same archived lineage.

Why this is not something to just move

All eight carry visibility: private. Their content is architectural description of the engine — bundle rollout, context resolution, estate layout, the GitHub controller, harness adapters, assurance, operation safety, policy projection — and it is clean: no fleet addresses, no host names, no credentials (checked).

So the destination is a decision, not a tidy-up:

• this module (public) is where the code they describe now lives, but they are marked private and something decided that;
• the estate (private) matches their marking and is the control plane, but they describe a public module's internals;
• either way they must be regenerated by gds-memory-compiler against the new scope, not copied. Hand-editing scope_id, source_commit and the digests would forge provenance on documents whose whole value is that the provenance is machine-made.

Acceptance

gds memory validate returns a non-zero count in whichever repository is chosen, with scope_id and source_commit naming that repository, and the legacy copies are retired rather than left as a second answer.

Filed rather than fixed: choosing the visibility boundary for the estate's architectural knowledge is an owner decision, and regeneration needs the toolchain question in #22 settled first.