Detect nested `.ok` projects and make `deinit` ancestor resolution explicit

[kinpoe-ray]

Summary

OpenKnowledge can end up with nested projects when a child project is initialized first and an ancestor is initialized later. ok init detects an existing .ok only by walking upward from the requested directory; initializing an ancestor does not detect descendant .ok projects inside its content scope.

This creates ambiguous project resolution and makes ok deinit <path> potentially surprising because it may resolve upward and remove an ancestor project rather than the directory the user believes they selected.

Environment

• OpenKnowledge CLI: 0.29.1
• macOS
• OK Desktop

Reproduction / observed layout

The machine ended up with this structure:

/Users/example/.ok                         # ancestor OK project
/Users/example/Project/
└── kpr-oppo-knowledge-base/
    └── .ok                                # independent child OK project

The ancestor project's content.dir pointed into Project (the Desktop UI opened/displayed the child knowledge content), while kpr-oppo-knowledge-base also retained a complete independent OK setup (.ok, .okignore, MCP configs, project skills, and .git/ok).

This can happen with the following ordering:

1. Initialize Project/kpr-oppo-knowledge-base as an OK project.
2. Later initialize /Users/example as another OK project and set its content.dir to Project or a descendant.
3. The ancestor initialization succeeds because it does not scan the selected content scope for descendant .ok directories.

Surprising deinit behavior

Running:

ok deinit /Users/example/Project --dry-run --json

reported:

[ok] Using OpenKnowledge project at /Users/example

and planned removal of /Users/example/.ok plus its project-level MCP entries and skills. The requested path and resolved project root were different. With --yes, the ancestor project was removed while the nested child project remained.

The resolver behavior is internally consistent (nearest ancestor .ok), but it is easy for a user to misunderstand—especially when OK Desktop displays an opened folder/content directory rather than clearly distinguishing the project root and content.dir.

Risks

• The same Markdown tree may be watched/indexed by both ancestor and child projects.
• Project identity differs depending on the current working directory.
• Desktop project name/opened folder, project root, and content directory can appear to be the same concept when they are not.
• deinit <path> can remove configuration above the requested path without an explicit mismatch confirmation.

Suggested safeguards

1. During ok init, scan the proposed content.dir for descendant .ok directories and warn or refuse unless explicitly overridden.

2. Reject or warn when changing content.dir to a tree containing another OK project.

3. Make parent watchers automatically exclude nested OK project roots.

4. Before deinit, always show both:

   Requested path: /Users/example/Project
   Resolved project root: /Users/example
   

5. When those paths differ, require an explicit confirmation or a flag such as --project-root /Users/example; consider not allowing --yes alone to bypass this mismatch protection.

6. In OK Desktop, display the project root and content directory separately.

Expected behavior

OpenKnowledge should either prevent nested project configurations or handle them as an explicit, well-defined feature. Destructive project operations should make ancestor resolution unmistakable before applying changes.

[kinpoe-ray]

Additional Desktop reproduction: stale lastOpenedProject guides the user into creating a nested parent project

I encountered a second, closely related path that makes the nested-project state especially easy to create through OK Desktop.

Sequence

1. A folder was previously an OK project.
2. It was intentionally converted into a plain container, with independent OK projects beneath it.
3. OK Desktop still retained the old container path as its most recent project.
4. On the next launch, Desktop automatically restored that path.
5. Because the container no longer had .ok/config.yml, Desktop immediately displayed “Setup OpenKnowledge in this folder?”, reporting Markdown files found below it.
6. The natural user action is to click Setup. Doing so would recreate .ok at the container root and produce nested parent/child OK projects again.

The local Desktop state confirmed the stale restoration target:

{
  "lastOpenedProject": "/Users/example/Desktop/kpr-knowledge-folder"
}

That folder was intentionally a plain container containing multiple independent child OK projects. The setup modal did not show enough context to distinguish “restored historical path” from a folder the user had just selected.

Why this is risky

The current flow effectively becomes:

Deinit / convert project to plain container
→ Desktop retains lastOpenedProject
→ next launch restores the stale path
→ no .ok found, Markdown descendants found
→ Desktop prompts Setup
→ user clicks the primary action
→ parent .ok is recreated above child projects

This means Desktop's automatic restore can actively guide a user into the nested state described in the original issue.

Suggested Desktop safeguards

1. On deinit, remove or invalidate matching entries in Desktop recentProjects, lastOpenedProject, session state, and saved window state.
2. If an automatically restored path no longer contains a valid project marker, return to Project Navigator instead of immediately showing the setup modal.
3. Before Setup, scan the proposed content tree for descendant .ok/config.yml project roots. Warn or refuse if any are found.
4. Show the absolute target path prominently in the setup modal.
5. Explicitly say that the path was restored from recent-project history rather than newly selected by the user.
6. Offer actions such as:
   • Open an existing child project
   • Remove from recent projects
   • Keep this folder as a container
   • Initialize anyway (advanced/explicit override)
7. Consider changing the primary action when descendant projects exist; Setup should not remain the easy/default path.

A useful warning would be:

This folder contains 8 existing OpenKnowledge projects.
Initializing it would create a parent project above them.
Open a child project instead?

This is reproducible with OK Desktop 0.35.0-beta.4 and is complementary to the CLI behavior originally reported with CLI 0.29.1.