📥 Bring Your Work

Bring conversations as history and projects as files. A transcript is not a repository backup, and an imported session is not a resumed process on its original host.

Preparation, not completed migration

In the historical blocked import-preparation round, no private exports had been supplied or imported. The selected importer was source-blocked against the prepared rc.2 core and was not installed; that round retained the then-live release. This does not identify a current owner’s release or establish new import readiness. No synthetic import runtime acceptance is claimed. The format matrix distinguishes source support from verified fidelity; Preview Before Import owns the gated procedure.

Choose what you are bringing

You haveDeliberate actionWhat does not come along
A conversation exportKeep the original archive; select an explicit supported transcript file; preview before importRepositories, attachments, cloud project files, live processes, authentication
A project repository or folderExport/download the actual assets separately, review them, then land a selected copy in a real project directoryConversation history unless separately imported
Project instructionsReview as untrusted reference text before deliberately adopting any instructionNo automatic skills, hooks, permissions, MCP, or provider-settings migration
A provider subscriptionFollow Subscription Provider Sign-in: approved onboarding remains DeepSeek, ChatGPT/Codex, and Claude with independent provider-specific permission; shared access requires no extra provider login. Do not repeat a completed login.No reuse of another application’s tokens or operator wallet
An already-running OMP/Hermes sessionKeep using its owning host and native interfaceThe new ACP child providers do not take it over

cwd in a transcript is a historical path string. It proves neither that a directory exists on this server nor that the transcript contains its files. An attachment reference is not the attachment’s bytes.

Two separate lanes

flowchart LR
  E[Selected source export] --> A[Intact private archive]
  A --> P[Native explicit-path preview]
  P --> I[Approved session import]
  I --> V[Persistence and fidelity checks]
  F[Selected project files] --> D[Real server project directory]
  D --> W[Existing workspace picker]
  V --> C[Choose a valid registered workspace]
  W --> C

The diagram is an operator workflow, not an automatic pipeline. Nothing scans an operator home, copies a token, starts a model request, or executes exported content merely because an archive was supplied.

Private directory plan

Every name below is synthetic. These are proposed service-owned locations, not an inventory of the user’s data and not proof that roots or batches already exist.

/var/lib/deek/
├── workspace/
│   ├── projects/
│   │   └── sample-project/          actual reviewed project assets
│   └── imports/
│       └── chatgpt/
│           └── sample-batch/
│               ├── conversations.json
│               └── receipts/      private import results and checks
└── agent-home/
    ├── omp/                       separate child-agent home
    └── hermes/                    separate child-agent home
  • The private backing state is /var/lib/private/deek; /var/lib/deek is the systemd service alias. Do not create a competing state tree.
  • The deployment owner refreshes the ownership gate, recording disk ownership separately from runtime identity. On this systemd257 Debian host, private backing state/data stay numeric65534:65534 (nobody/nogroup) on disk and systemd maps them to the per-start DynamicUser UID. Do not chown uploaded files or private state to that runtime UID: the systemd ownership branch can otherwise fall back to legacy recursive chown instead of idmapping. Root archives/restores use tar --numeric-owner; do not blindly “repair” correct nobody ownership.
  • Private directories use mode 0700; selected files and receipts use 0600 where appropriate. Root performs only the bounded inspection/copy/ownership operation, never package lifecycle or uploaded-code execution.
  • Importer registry and DSH session persistence remain in their native private state locations. The per-batch receipts/ folder stores selected native results; it is not a new import engine or approval database.
  • A prepared staging proof uses /var/lib/deek-stage instead. Its synthetic state never receives live credentials or private export copies.

Move project assets deliberately

  1. In the original product, export or download the repository, documents, attachments, and project instructions you actually need. Cloud project attachments may need separate downloads.
  2. Preserve the original export. Review file types, archive entries, symlinks, executable files, and embedded configuration before the admin copies a selected set into projects/<slug>/.
  3. Register that existing, service-visible absolute directory through Deek’s supported workspace picker. Do not create a workspace merely from a historical cwd.
  4. Check that the session’s recorded directory and real registered workspace agree. Missing, moved, or out-of-bound directories must stay ungrouped or await a deliberate workspace choice; never loosen ProtectHome to make an old path work.
  5. Start any new task only after reviewing what that task may read or change. Imported tool results are stale evidence, not proof of the server’s current files.

The selected upstream workspace contract validates real directories and groups sessions by their recorded canonical path. Removing a workspace registration does not delete its files or histories; re-adding a removed directory does not automatically restore prior membership. A cosmetic grouping operation does not recreate a project.

Keep the import small

Start with one selected, non-sensitive conversation and one real project directory. Use explicit paths, leave bidirectional sync and the Claude context bridge off, and do not invoke import_agents, import_mcp, or import_settings as part of conversation migration. Do not run global /attach-workspaces to repair a single batch.