Move dictionary storage, PostgreSQL and agent workspaces to the external 2 TB drive — execution in #211

[holden]

Objective and priority

Execution now coordinated by #211: carry out the storage move by building and using the repeatable setup/restore process from #130. Preserve the current installation as the comparison baseline until the external installation passes exact-state and usability verification. See #211 for the executable stages and shared acceptance evidence.

Current sequence: complete the consolidation/preservation and migration-safety checkpoint, then execute #211. Full Routing Stage 2 acceptance is not a prerequisite; unfinished #194 work resumes after relocation. Capacity, data-preservation and recovery checks remain mandatory.

Move dictionary's source code, Git/worktrees, PostgreSQL databases, datasets, builds, recovery artifacts and project-related agent storage to the secondary 2 TB external drive chosen by the owner. Configure future tasks, worktrees and tests to use that drive so the internal drive does not fill again.

Owner decision: for dictionary, this replaces the previous instruction to keep source code and PostgreSQL internal. Update the applicable project guidance during migration. Other projects keep their own storage policies.

This issue defines the work; creating it does not mean the migration has happened. Detailed machine inventories and operational evidence remain in local private artifacts.

Scope

• Repository, Git metadata, branches, unpushed commits, local edits and all dictionary worktrees.
• Development and retained test/recovery databases, including their identities, references, schema, sequence state, ownership and grants.
• Downloaded source data, local archives, backups, audit evidence, attachments and necessary ignored files.
• Project-related agent sessions, logs, memories and artifacts where supported.
• Future agent working directories, build/dependency caches, test databases, logs and temporary outputs.
• Saved project paths, environment configuration, launchers, hooks and automation references.
• README, project/agent instructions and a storage operations runbook.

Identify shared resources before changing them. Preserve unrelated projects and shared credentials. Where a tool cannot isolate dictionary state, document a supported relocation strategy or an explicit, measured exception; do not silently exclude large agent stores.

Stage 1 — Inventory and preserve active work

• Record each dictionary storage location, its owner, logical/allocated size, destination and disposition: active, retain/archive, or confirmed regenerable.
• Inventory Git/worktree registrations and locks, active agents, unpushed/detached commits, dirty/untracked files and necessary ignored data. A merged PR does not by itself make a checkout disposable.
• Map databases to actual owners and current use. A name prefix alone is not deletion authority.
• Inventory saved agent project/session paths and shared-state constraints without exporting secrets or transcript contents.
• Verify the destination's actual mounted identity, filesystem, permissions and capacity. A directory under a mount path is not proof that the intended drive is mounted.
• Coordinate a maintenance window with relevant agents, application processes and database writers. Stop services through their owning launcher/terminal and verify their state.
• Preserve verified rollback artifacts externally. When internal capacity is critically low, establish initial headroom through verified relocation of inactive artifacts or confirmed regenerable caches before large builds or database operations.

Exit: every source has a disposition; active work is preserved; the destination is verified; the move fits within measured capacity.

Stage 2 — Move source, worktrees and agent storage

• Preserve repository history, unpushed commits, edits, file modes, symlinks and needed ignored artifacts. A fresh clone alone is insufficient.
• Use supported Git and agent-app relocation mechanisms; repair and verify worktree/common-directory references when paths change.
• Use Codex's managed archive/recovery tools for genuinely retired managed worktrees, preserving needed ignored files separately.
• Update saved project roots, shells, editors, launch settings, hooks, permissions and automation paths.
• Configure future dictionary worktrees, caches, logs and temporary outputs externally. Keep concurrent agents' writable build outputs isolated.
• Preserve existing session continuity and verify both a resumed dictionary session and a newly created task/worktree.
• Use supported controls for agent-state relocation. Do not rewrite live shared metadata databases or relocate unrelated project state blindly.
• Any temporary compatibility symlink needs a documented lifetime and a mount check that prevents silent internal fallback.

Codex documents a configurable Worktree root under Settings → Worktrees. Its broader local state also includes configuration and authentication, so moving the repository alone is insufficient. Verify the installed app's supported behavior and setting scope: worktree storage, configuration/state locations.

Exit: local work and session continuity survive, and new dictionary tasks actually write to external storage.

Stage 3 — Move dictionary PostgreSQL data

• Identify shared-cluster boundaries. Prefer a dedicated external dictionary cluster when relocating a shared cluster would affect other projects.
• Match the required PostgreSQL version, extensions, encoding, locale/collation, ownership, grants and permissions.
• Use consistent backups and explicitly isolated restore destinations. Never copy individual database files out of a running shared cluster.
• Preserve exact identities, references, sequences, migration state, routing history and curation approvals. Storage relocation must not rebuild, re-materialize or reclassify the corpus.
• Compare source and destination at the same schema/data state using complete manifests, key sets and reference fingerprints; row counts alone are insufficient.
• Account for unresolved recovery-tool findings in PR Stage 2 recovery: rehearse on the development corpus, then repair and re-run (#194) #208. Prove the source and destination endpoints differ and do not rely on an unverified source-protection claim.
• Update every dictionary client: development, active worktrees, test configuration/private partitions, scripts, background jobs and recovery tools.
• Ensure there is one intended writable endpoint after cutover. Preserve any destination writes if rollback becomes necessary; switching back to an older source is not a lossless rollback.

Reference: PostgreSQL logical backup guidance.

Exit: exact state preservation, healthy application/jobs, verified client configuration and a usable rollback procedure.

Stage 4 — Verify operation and prevent internal fallback

• Run relevant tests and mix precommit from the external checkout on an isolated external test database; record the revision and results.
• Exercise normal reads, representative writes, jobs, source-file access and recovery verification without unrelated feature changes or publication.
• Restart services and relevant agent launchers; confirm saved paths and database configuration still work.
• Verify missing/wrong/unwritable-drive startup refuses clearly and creates no replacement internal directories, database or checkout.
• Test absence through controlled configuration or clean shutdown/unmount procedures, never by unplugging a live database volume.
• Measure representative build/test/query performance and both drives' storage growth. Resolve unexpected internal writes.
• Demonstrate backup restoration from the new setup and document an independent backup destination/retention policy. A second copy on the same physical drive does not cover drive failure.

Exit: normal operation and restart work externally; missing storage is handled safely; recovery is demonstrated.

Stage 5 — Reclaim space and document the new default

• Remove superseded internal copies only after successful copy verification and cutover.
• Drop only individually verified inactive dictionary databases through PostgreSQL; never remove files from a shared cluster manually.
• Reconcile old worktree registrations and saved paths using the owning tools. Preserve in-use/pinned/shared work until accounted for.
• Retain recovery evidence and backups according to the recorded retention plan.
• Report actual before/after free space, bytes reclaimed, remaining dictionary paths and all accepted internal exceptions. Set and meet an explicit operating-headroom target from the measured workload.
• Update README, applicable AGENTS/Claude/Codex instructions, setup hooks, database/test configuration and recovery documentation. Reconcile contradictory internal-storage guidance in related handoffs, including Local curation runtime: persistent Ollama service, pinned models and bounded Req inference #195/Local curation portability: measured Mac Studio to Mac Mini handoff #199 where applicable.
• Commit a storage runbook covering canonical roots, mount checks, startup/shutdown, new-agent/worktree setup, test isolation, backup/restore, retention and rollback.
• Obtain independent verification before closing this blocker. Post the completion evidence and updated handoff to Routing before launch: On overviews, standards-informed namespaces, and stable subject URLs #194.

Definition of done

All identified dictionary bulk storage and future dictionary work use the external drive, with explicit accepted exceptions for unavoidable small shared metadata. Active code/session history and exact database state are preserved. Unrelated projects remain operational. Restart, missing-drive and restore checks pass. Internal space has actually been reclaimed, and documentation agrees with the running setup.

The consolidation/preservation and migration-safety checkpoint is the prerequisite to executing this migration under #211; full Routing Stage 2 remains separate. Migration success does not close routing #194 or grant reader/publication approval; those remain later stages.

Copyable implementation prompt

Own the combined repeatable-setup and dictionary storage migration specified in #211, using this issue and #130 as requirement sources. First verify the consolidation/preservation and migration-safety checkpoint; full Routing Stage 2 acceptance is not required before relocation. Read current main, the latest routing recovery audit and applicable project instructions. The owner's new direction is external storage on the chosen 2 TB drive, superseding the earlier internal-drive preference for dictionary. Inventory and preserve active work first; then carry out the staged source/worktree/agent and database migration, exact verification, client cutover, restart/recovery checks and verified cleanup. Protect unrelated shared resources, retain rollback evidence, prevent silent internal fallback and configure future tasks/tests externally. Update README, instructions and the storage runbook. Deliver a reviewable change set and measured completion report, then hand back to the next routing stage.

Curation runtime checkpoint available — 2026-09-27

The in-flight #195 runtime proof has reached its preservation checkpoint in PR #210, head cb2e236917c67286dc13c67c5ab2258bb87d9feb: 32 planned benchmark calls recorded, nine CodeRabbit threads resolved and both checks green. Independent audit/merge remain outstanding. This is not completion of routing Stage 2. Current execution follows #211 after the consolidation and migration-safety checkpoint.

The Ollama endpoint is stopped; weights/binary/runtime home and temp are already external. Preserve the pushed branch, committed benchmark packets/results, exact model identities and the two isolated evidence databases devils_dictionary_runtime_bench and devils_dictionary_runtime_bench_b in the migration inventory. Do not delete them as disposable tests without accounting for their audit evidence. The service's database/cluster authority binding must be deliberately reconciled after database relocation; copying its old binding file is not sufficient verification.

Internal capacity at this check was about 4.6 GiB. No further inference, full-suite database creation or large recovery run was launched by the status assessment. Verify capacity before heavy work; read-only review and non-disruptive migration inventory can continue meanwhile. No migration or cleanup has been started by this update.

[holden]

Revised owner sequence: consolidation checkpoint, then relocation

The owner clarified that the immediate goal is to finish Stage 2 enough to consolidate and preserve current work, then migrate dictionary storage, rather than require every Stage 2 deliverable first.

The coordinating plan is #193 (comment).

Before relocation: account for all code in accepted main plus one designated integration branch where necessary; preserve uncommitted work, databases and evidence; resolve migration-relevant safety blockers; record verification and prepare the supported backup/restore, rollback and post-move checks. An integration branch does not mean its work is accepted. Known-unsafe recovery tooling must not be used for the move.

Full routing replay/backfill/review, repeat-run/crash-resume and candidate-manifest work may remain explicitly open and resume after migration. Existing Stage 2 acceptance criteria remain unchanged; neither consolidation nor relocation completes them. This sequencing update supersedes the earlier finish-all-Stage-2-before-relocation schedule. Actual relocation remains its own execution task, not part of the closure handoff.

[holden]

Shared implementation now tracked in #211

The owner requested one combined effort: perform the required external-drive migration by building and using the repeatable setup/restore process itself.

Execution and acceptance are specified in #211. Preserve the current installation as the frozen comparison baseline through acceptance; prove exact restored state and usable behavior, then repeat setup on a clean external target using only the documented process. Cutover, rollback, agent/worktree continuity and verified disk reclamation are part of the same delivery.

This issue remains a requirement source. #211 owns the shared implementation and evidence, avoiding competing implementations. Full Routing Stage 2 is not a prerequisite: the consolidation and migration-safety checkpoint comes first, then this combined move/setup task, with unfinished routing work resumed afterward. Keep this issue open until its own requirements are accounted for by the shared evidence.

[holden]

Migration-readiness handoff: consolidation checkpoint 697ac8a

Code checkpoint:

• main c6bd882;
• plus codex/consolidation-2026-09-27 at 697ac8a33ea9b5f3620807495779d8d5523a1bca (compare).

The branch's manifest and full handoff are in docs/operations/consolidation-checkpoint-2026-09-27.md. The raw inventories stay private, on the external drive.

Included	Status
#202 7711e31	Accepted (independent A− readiness audit), not merged. The owner's merge decision
#210 cb2e236	Not accepted. No independent audit
#208 2d495e8	Not accepted, in flight. The PR head plus four commits an active session had not pushed; its uncommitted edits stay in its worktree

Checks run on the branch, on isolated partitions:

• compile --warnings-as-errors;
• the combined migration path: main → head, a rollback of the two new migrations, and from zero, where the schema is identical to the upgraded one;
• mix precommit at 92d7265: 2,453 tests, 0 failures; re-run at 697ac8a: 2,453 tests, 0 failures;
• Stage 2 recovery: rehearse on the development corpus, then repair and re-run (#194) #208's 32 safety tests.

Not yet safe to start the move. Two things must happen first.

1. Quiescence. One session is still active in the Stage 2 recovery: rehearse on the development corpus, then repair and re-run (#194) #208 worktree. It has uncommitted work and is running rehearsal steps against the external scratch cluster. It must finish, commit and push. After that, stop the dev server on 4007 and its public ngrok tunnel, and the Curated opening section, Phase 1: manual fixture, Bierce-first lead, sourced highlights (#156) #202 preview on 4017.
2. The state to preserve. devils_dictionary_v2 was migrated by mistake at 13:11Z, from pre-routing to 20260927131023 (incident). No data changed; 23 empty tables were added. The owner decides whether to roll it back first; the rollback is rehearsed on a test database.

Verified destination. /Volumes/LLM Models is /dev/disk5s1, APFS, PCI-Express, with Internal = false and about 1.7 TiB free. The internal disk has about 4.6 GiB free, so every dump goes straight to the external drive. The dictionary's databases total about 27 GB logical, on a PostgreSQL 18.2 cluster on 5432 that other projects share.

Approach, in full in the doc:

1. Create a dedicated external dictionary cluster from the same Postgres.app 18.2 binaries: UTF8, en_US.UTF-8, ICU en-US, citext and pg_trgm, roles postgres and holden.
2. pg_dump -Fc each database and pg_restore it into an empty, explicitly named database. Never copy data directories, and never use mix dd.snapshot --restore: its identity guard is still under repair.
3. Verify each database: schema dump, schema_migrations, ordered per-table content digests plus counts, sequences, owners and grants, extensions, encoding and collation.
4. Cut over with DD_DATABASE_PORT, booting with Oban off first. Rebind the runtime deliberately (service start --rebind).
5. Roll back by pointing clients at 5432 again. The sources stay untouched until the cutover is accepted; destination writes must be reconciled.

Remains open after the move:

• Routing before launch: On overviews, standards-informed namespaces, and stable subject URLs #194 Stage 2: replay/materialize/resolve, legacy handling and equality coverage, repeat-run and crash/resume, reviewer and population decisions, backfill, the candidate manifest, independent acceptance;
• Local curation runtime: persistent Ollama service, pinned models and bounded Req inference #195: an independent audit of Curation runtime stage A: one private local model behind one slot (#195) #210, and the corrected instruction and fixture re-benchmark before Persona panel pilot: five versioned editors, fixed quorum and ten-page evaluation #197;
• Curated opening section: Bierce-first lead, sourced highlights and inspectable editorial choices #156: the Curated opening section, Phase 1: manual fixture, Bierce-first lead, sourced highlights (#156) #202 merge decision.

Nothing was relocated, deleted or cleaned up under this checkpoint.