[Feature]: Add safe project-level delete and rename with complete state cleanup

[Aiden-cheng]

Problem

OpenKnowledge currently does not provide a reliable project-level operation for either:

• deleting an entire knowledge-base project, or
• renaming an entire knowledge-base project while preserving its content.

The available deinit command removes OpenKnowledge integration metadata, but it is not a complete project lifecycle operation: it does not clearly remove the project from Desktop state, invalidate every server/MCP (Model Context Protocol) reference, or provide a safe Trash-based delete workflow.

As a result, deleting or moving a project manually from Finder can leave stale state behind. In my case, after several test projects existed under the same parent, Interview-practice had a stale .ok/local/server.lock and .git/ok/config whose worktreeRoot pointed to the previous 面试 directory. The Desktop app then started or attached to the wrong content directory. Old project paths also remained in Desktop state, global skill state, thread metadata, and cached app data. This makes a removed project appear to come back and risks re-materializing files from the wrong project.

This is especially dangerous when a user only wants to clean up old test projects while keeping the Markdown files and attachments in the project they still use.

Environment

• OpenKnowledge Desktop: 0.71.13
• Platform: macOS Apple Silicon
• Install method: Desktop app
• Project layout: local Markdown knowledge bases under one parent directory

Reproduction

1. Create or open multiple local OpenKnowledge projects, for example 量化维基, 面试, 知识库, OpenKnowledge, and Interview-practice.
2. Open more than one of them in OpenKnowledge Desktop and then quit the app.
3. Rename or delete one project directory manually in Finder, or move it outside the app.
4. Reopen OpenKnowledge and open the remaining project.
5. Inspect the project server lock, Desktop state, and project API (Application Programming Interface).

Actual behavior

• There is no clear Desktop action to delete a whole project and remove all associated project state.
• There is no reliable Desktop or CLI (Command-Line Interface) action to rename a whole project and update all path references atomically.
• deinit removes project integration metadata but is not a documented “forget this project everywhere” or “move to Trash” operation.
• Stale project paths can remain in recentProjects, projectSessions, projectWindowBounds, lastOpenedProject, pending restore state, server locks, editor MCP configuration, global skill state, and thread metadata.
• A stale lock or path reference can cause a newly opened project to attach to a previous project’s content directory.
• Manual deletion can therefore leave a project that looks deleted on disk but is still present in OpenKnowledge’s internal state, and in some cases old files can be re-created or re-attached.

Related reports:

• Desktop: stale recent-project entries remain after project directory is deleted #681 — stale recent-project entries after a project directory is deleted
• [Bug]: Deleted docs re-materialize on disk within ~30-150s (both POST /api/delete-path and OS-level rm) — survives restarts and .okignore #462 — deleted documents re-materializing from internal state
• Detect nested .ok projects and make deinit ancestor resolution explicit #684 — nested projects and ambiguous project-root resolution

Expected behavior

OpenKnowledge should support explicit, project-level lifecycle operations that distinguish:

1. Rename project — preserve all Markdown files, attachments, Git history, and the project’s logical identity while updating every OpenKnowledge path reference.
2. Remove from recent projects — remove only Desktop history/state and never touch disk content.
3. Delete project — stop the project server and MCP clients, invalidate all project references, and move the selected directory to Trash by default (with a clearly labeled permanent-delete option only if explicitly chosen).
4. Deinit project — continue to remove integration metadata while clearly stating that it does not delete content or necessarily remove Desktop history unless that behavior is added.

After a rename or delete, restarting the app should not restore or reattach the old path. ok ps and /api/workspace should never report the old project after the operation completes.

Proposed implementation

• Add Desktop actions such as Rename project, Remove from recent projects, and Move project to Trash.
• Add corresponding CLI (Command-Line Interface) commands, for example ok project rename and ok project delete --trash, or document an equivalent supported workflow.
• Make the operation transactional across:
  • project root and content.dir;
  • .ok/local/server.lock;
  • .git/ok/config;
  • Desktop state.json keys (recentProjects, projectSessions, projectWindowBounds, lastOpenedProject, and pending restore state);
  • editor MCP configuration;
  • global skill state and project/thread metadata;
  • any cached project identity used by the Desktop app.
• Before destructive operations, show the resolved project root and content directory separately, especially when nested .ok projects exist.
• Add regression tests covering rename, Trash delete, app restart, stale locks, nested projects, and a project containing Markdown plus attachments.

Acceptance criteria

• Renaming a project preserves every authored Markdown file and attachment and leaves no old-path reference in active OpenKnowledge state.
• Deleting a project removes it from the Desktop project list after restart and does not re-materialize its files.
• Removing a project from recent projects never deletes or modifies its authored content.
• Operations are safe when the project has an active server, MCP client, editor integration, nested project, or stale lock.