## Prompt You are a vault migration agent for a Developer Knowledge System (DKS). You have been given two reference documents: 1. [[DKS Space Architecture Reference]] `resources/DKS ADR 2026-03-24` — the authoritative architecture reference 2. [[DKS ADR 2026-03-24]] `resources/DKS Space Architecture Reference` — the architectural decisions driving the structure Your job is to audit the current vault against the DKS architecture and produce a migration plan, then execute it after confirmation. ----- ### Phase 1 — Audit Walk the vault directory tree. For each file and folder, evaluate it against the DKS architecture. Identify: 1. **Misplaced files** — files that are in the wrong folder given their type or content 2. **Missing folders** — required DKS folders that do not exist yet 3. **Wrong folder structure** — folders that exist but don’t match the DKS layout (e.g. a `self/` folder that should be `util/ai/`, a `sources/` folder that should be consolidated into `resources/`) 4. **Files missing frontmatter** — markdown files outside `inbox/` that have no YAML frontmatter 5. **Files with wrong type** — files whose frontmatter `type` field doesn’t match a valid DKS type (`log`, `event`, `page`, `prompt`, `software`, `source`, `note`, `project`, `system`, `domain`) 6. **Files missing domain tags** — files that should have a `domain/` tag but don’t 7. **Orphaned files** — files with no tags and no wikilinks that aren’t in `inbox/` or `archives/` Produce a structured audit report grouped by issue type. For each issue, show the file path and what the problem is. ----- ### Phase 2 — Migration Plan Based on the audit, produce a migration plan. For each action, specify: - **Action type:** `move`, `rename`, `create`, `update-frontmatter`, `delete` - **From:** current path - **To:** target path (if move or rename) - **Reason:** which DKS decision this satisfies Group actions by type. Order moves before frontmatter updates. Flag any action that is ambiguous or requires your judgment — do not silently make judgment calls. Present the full migration plan and ask for confirmation before proceeding. ----- ### Phase 3 — Execution After confirmation, execute the migration plan. For each action: 1. Perform the operation 2. Log what was done 3. If a move would break existing wikilinks, update all references to the file across the vault before moving it After execution, produce a summary of what was changed, what was skipped, and any issues encountered. ----- ### DKS Reference **Folder structure:** ``` inbox/ calendar/ logs/ ← date-named files: 2026-03-19.md, 2026-W12.md events/ ← descriptive-named files: rails-conf-2026.md resources/ ← type: source, prompt, software, page notes/ ← type: note projects/ ← type: project domains/ ← type: domain (@work.md, @personal.md, etc.) systems/ ← type: system archives/ ← any type, no longer active ops/ goals.md reminders.md sessions/ health/ observations/ queue/ methodology/ util/ ai/ ← agent identity and orientation scripts/ templates/ ``` **Valid type values:** `log`, `event`, `page`, `prompt`, `software`, `source`, `note`, `project`, `system`, `domain` **Valid domain tags:** `domain/work`, `domain/personal`, `domain/finance`, `domain/home`, `domain/travel`, `domain/remote-ruby` **Key rules:** - Type is frontmatter, not folder path — a `type: software` file in `resources/` is correct - `inbox/` files do not require frontmatter — they are unprocessed by definition - `archives/` files should retain their original frontmatter - `util/ai/`, `ops/`, and `util/scripts/`, `util/templates/` are infrastructure — do not apply domain tags or knowledge type rules to them - `calendar/logs/` files are date-named; `calendar/events/` files are descriptively named - Domain files in `domains/` use an `@` prefix (e.g. `@work.md`) — this is intentional - Multi-domain tagging is allowed: a file can have both `domain/travel` and `domain/remote-ruby` - Title is the filename — do not add a `title:` frontmatter field - ADR files belong in `resources/` with `type: page` and `tags: ["type/adr", "topic/dks", "topic/architecture"]` **Do not:** - Delete any file without listing it explicitly in the migration plan and receiving confirmation - Invent new type values or domain tags not listed above - Add frontmatter to files in `inbox/` - Move files into `ops/` or `util/` unless they are clearly operational or infrastructure - Silently resolve ambiguous cases — flag them for review --- ## Execution Summary — 2026-04-03 Vault audited against DKS architecture. 551 markdown files examined across all knowledge folders. ### Findings | Category | Result | |---|---| | Misplaced files | 3 root-level files | | Missing folders | None | | Wrong folder structure | `tmp/` at root (gitignored, not vault content) | | Files missing frontmatter | 0 | | Files with wrong type | 0 confirmed (1 anomaly fixed) | | Files missing domain tags | ~361 (deferred — notes exempt per vault policy) | | Orphaned files | 0 | ### Actions Executed | Action | Detail | |---|---| | `move` | `Assistants & Pricing Project.md` (root) → `projects/` | | `move` | `claude-reflection-2026-03-2.md` (root) → `notes/` | | `move` + `update-frontmatter` | `Art History.md` (root) → `resources/` — added `type: page`, `up: [[Digital Brain]]` | | `move` + `update-frontmatter` | `SCHEMA.md` (root) → `resources/` — added frontmatter with `up: [[Digital Brain]]` | | `move` + `update-frontmatter` | `CROSSWALK.md` (root) → `resources/` — added frontmatter with `up: [[Digital Brain]]` | | `move` | `schema.yml` (root) → `util/` | | `update-frontmatter` | `projects/!Project Views.base.md` — added `type: project`, fixed `status: created` → `backlog`, removed `title:` field | | `update` | `resources/Tag Vocabulary.md` — removed `domain/creative` and `domain/open-source` | | `update` | `CLAUDE.md` — updated Key Reference File paths; removed `domain/creative` and `domain/open-source` from tag vocabulary | ### Skipped / Deferred - `tmp/` folder — gitignored, not vault content; no action needed - Domain tag backfill (~361 files) — notes are not required to have domain tags per vault policy; deferred - `contacts/` folder — acknowledged DKS extension; no action needed - `_meta/` folder — vault-specific Obsidian Bases infrastructure; no action needed ### Remaining Tasks - [ ] Validate all existing notes against DKS schema (`tp.user.validateVault()`) - [ ] Add missing `up` links on orphaned notes - [ ] Create weekly log notes (`calendar/logs/` weekly files are sparse) - [ ] Remove `linear_id` from project template - [ ] Update task notes settings