Migrate

• Every committed chunk lands in a LifeOS destination that fits it and carries provenance: an HTML comment naming source file, section and timestamp.
• The principal sees the whole routing proposal (chunks per target, average confidence, UNCLEAR and under-40% counts) before anything is written, and picks how to approve it.
• Each chunk under 60% confidence is approved one at a time, each UNCLEAR chunk is routed by the principal's own call, and each chunk under 40% is walked through with them first (a conversational rule; the tool does not enforce the 40% line).
• Every AI collaboration rule reaches a constitutional surface (a CLAUDE.md operational rule, a hook, a settings.json permission, or the relevant skill's Gotchas), and every knowledge chunk becomes a new typed note with source metadata.
• The run closes with what was committed per target, what is still UNCLEAR, and whether /interview should fill what the migration left sparse.

Each of these is refused in code by LIFEOS/TOOLS/MigrateApprove.ts; the parenthesis names the mechanism. MigrateApprove.test.ts covers the threshold, UNCLEAR, protected-target and duplicate refusals.

• A chunk lands in PRINCIPAL_IDENTITY.md or under IDEAL_STATE/ without the principal's yes on that exact chunk. Identity is load-bearing, and IDEAL_STATE is fully private and curated, so each dimension is the principal's call. (Refused unless the single-item command carries --confirm-protected <id>; every bulk command rejects that flag.)
• A chunk under 60% confidence, or an UNCLEAR chunk, is committed by a bulk command. (--approve-all takes only chunks at or above BULK_MIN_CONFIDENCE and leaves the rest pending; UNCLEAR is refused until --modify retargets it.)
• A rule chunk is written to the harness memory/feedback_*.md directory. Every feedback memo is a missed system patch (LIFEOS/RULES/SelfHealing.md § Self-Healing Infrastructure, the "Override of harness auto-memory" paragraph), so rule chunks are walked through one by one to a constitutional surface. (A memory/feedback target is refused until --modify retargets it.)
• A chunk is committed to a target that already holds its text. (Text is compared lowercased with whitespace collapsed against the target file or knowledge dir; a match is reported and left pending, and --reject <id> drops it.)

MigrateScan classifies into a routing table; MigrateApprove commits per the user's chosen path.

Sources supported in V1

• Files: .md, .markdown, .txt (single file or directory recursion)
• Stdin: piped content or pasted directly
• Other LifeOS installs: point at their USER/TELOS/ or MEMORY/KNOWLEDGE/ directories
• Agent-harness rule files: CLAUDE.md, .cursorrules, OpenAI Custom Instructions export
• Exports: Obsidian vaults (markdown), Notion exports (markdown), Apple Notes exports (.txt), raw journal dumps

Collect the source path from the user; pasted content goes in through --stdin.

Run the scanner:

bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source <path>
# or
echo "$CONTENT" | bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --stdin
# preview the routing without writing the approval queue
bun ~/.claude/LIFEOS/TOOLS/MigrateScan.ts --source <path> --dry-run

Scanner output includes total chunks found, the proposed routing table (how many chunks per target), average classification confidence, the count of UNCLEAR chunks, and the count of low-confidence (<40%) chunks.

Then approve along the path the user picks:

Fast path (they say "approve all trusted"):

bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-all

Commits pending chunks at ≥60% confidence. The tool itself skips, reports, and leaves pending: anything under 60%, UNCLEAR, any PRINCIPAL_IDENTITY.md or IDEAL_STATE/ target, and any chunk whose text already appears in its target. Then walk through what it skipped conversationally.

Category path (they say "approve goals and wisdom, skip knowledge"; the tool refuses a protected target here and skips duplicates):

bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-target TELOS/GOALS.md
bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve-target TELOS/WISDOM.md

Walk-through path (they want careful review):

bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --review

For each pending chunk, show preview + proposed target + confidence + alternatives, and commit the user's decision: approve (--approve <id>), modify target (--modify <id> --target <new_target>), or reject (--reject <id>).

Protected targets (PRINCIPAL_IDENTITY.md, anything under IDEAL_STATE/): show the full chunk, get the user's yes on that one chunk, then:

bun ~/.claude/LIFEOS/TOOLS/MigrateApprove.ts --approve <id> --confirm-protected <id>

The confirm value must equal the id; bulk commands reject the flag.

UNCLEAR chunks are ones where no classification rule matched strongly. Display each one's full content (not just the preview), offer the likely destinations plus Knowledge/Ideas as a catch-all, and commit the user's choice via --modify <id> --target <chosen>.

• TELOS and preference targets are refused on current installs. The scanner proposes TELOS/<NAME>.md targets (GOALS, WISDOM, BOOKS and the rest), which MigrateApprove resolves under LIFEOS/TELOS/ (not in the public release). TELOS now lives in one USER/TELOS/TELOS.md with H2 sections, so each such approval is refused as a missing target file (verified 2026-10-11 against the MigrateScan.ts target list and the missing-target refusal in MigrateApprove.ts). Until the tools retarget, add those chunks to the matching TELOS.md section through /Telos, then --reject <id> them here. Do not --modify them to USER/TELOS/TELOS.md: the tool appends at end of file, under whatever section is last.
• Low average confidence (<40%): the source is probably genre-mismatched (e.g., code comments, logs, raw data). Consider pre-filtering to remove non-prose chunks before scanning.
• Everything goes to UNCLEAR: the source probably has no recognizable LifeOS-taxonomy patterns. Either add the content manually via /Telos or write it as general Knowledge notes.
• Duplicates are caught at approve time, not scan time. The scanner does not compare against existing files, so its routing table can count chunks that MigrateApprove will then skip as already present in their target (MigrateApprove.ts, duplicate skip; corrected 2026-10-10 from an older note saying nothing deduped). --dry-run is a MigrateScan flag; MigrateApprove has none.

User: /migrate ~/old-claude/TELOS/
→ Routing summary for every chunk in the old TELOS directory, then the fast-path vs. walk-through choice

User: /migrate, then pastes CLAUDE.md content
→ Read from stdin; most chunks classify as AI collaboration rules and are walked through to CLAUDE.md / hooks / skill Gotchas, plus PRINCIPAL_IDENTITY if identity lines are mixed in

User: "migrate my Cursor rules at ~/.cursor/rules"
→ Each rule walked through to its constitutional destination with extra care: Cursor rules often have tool-specific stuff that doesn't translate to LifeOS

User: "import the stuff I dumped in /tmp/journal.md"
→ Expect a lot of UNCLEAR + WISDOM; each section walked through

What it classifies chunks into

• /interview — fills gaps by asking questions (not by intaking existing content)
• /Telos Update intent — edit a single TELOS file directly
• /Cortex — manage the Knowledge Archive the knowledge chunks land in
• PRINCIPAL_IDENTITY.md edits outside a migration go to the install's profile skill when it has one; Migrate writes there only through --confirm-protected

Migrate has no config file. Both tools resolve every path under the LifeOS directory (LIFEOS_DIR, LIFEOS/ by default):

• Approval queue: LIFEOS/MEMORY/MIGRATION/migration-proposals.jsonl. MigrateScan writes it, MigrateApprove works through it, and --reset clears it.
• Commit log: LIFEOS/MEMORY/MIGRATION/committed.jsonl. MigrateApprove appends one line per approved chunk, with its target path and time.
• Identity target: LIFEOS/USER/PRINCIPAL/PRINCIPAL_IDENTITY.md, protected.
• Knowledge targets: LIFEOS/MEMORY/KNOWLEDGE/{Ideas,People,Companies,Research}/, one new note per chunk.
• TELOS and preference targets: TELOS/<NAME>.md and TELOS/IDEAL_STATE/, which resolve under LIFEOS/TELOS/ (not in the public release) and are refused today (see Gotchas).
• LIFEOS/USER/ and LIFEOS/MEMORY/ are symlinks into the private user-data repo, so a migration's writes are reviewed and reverted in that repo.