docs: restructure dev-docs sidebar and move pages into subdirectories

3 files changed, 0 insertions, 155 deletions

diff --git a/docs/dev-docs/issues/.name b/docs/dev-docs/issues/.name
deleted file mode 100644
index f99478d..0000000
--- a/docs/dev-docs/issues/.name
+++ /dev/null
@@ -1 +0,0 @@
-Issues
diff --git a/docs/dev-docs/issues/the-mod-pathfinder.md b/docs/dev-docs/issues/the-mod-pathfinder.md
deleted file mode 100644
index 5f8c902..0000000
--- a/docs/dev-docs/issues/the-mod-pathfinder.md
+++ /dev/null
@@ -1,64 +0,0 @@
-<h1 align="center">The Mod Pathfinder</h1>
-<p align="center">
-    A build-time analyzer that computes full module paths for Mingling types, resolving path ambiguity in macros.
-</p>
-
-## Background
-
-Currently, `gen_program!` requires all involved types to be `use`d within their module. Mingling lacks a complete module path analyzer — waiting for `proc-macro-span` to stabilize is clearly not practical, so a solution for obtaining module paths is needed.
-
-## Solution
-
-We plan to create an analyzer called `mingling-mod-pathf`, enabled via Mingling's `"pathf"` feature, to compute the full paths of all defined Mingling types.
-
-### Behavior When Enabled
-
-**`mingling_core`**: If the `builds` feature is enabled, introduces the `mingling::build::analyze_and_build_type_mapping()` method (analysis completed at Build-Time)
-
-**`mingling_macros`**: Modifies the behavior of the `gen_program!()` macro — automatically loads the mapping table from the analysis file generated by `mingling::build::analyze_and_build_type_mapping()`, and directly uses the full `mod::path` instead of `TypeName` (injected at Compile-Time)
-
-## Challenges
-
-`mingling-mod-pathf` needs to understand **all** Mingling syntax features.
-Fortunately, Mingling's type creation is almost always explicit:
-
-```rust
-mod sub {
-    mingling::macros::pack!(ResultMyName = String); // directly creates ..::sub::ResultMyName
-}
-```
-
-There are a few exceptions, such as the implicit Dispatcher provided by `extra_macros`, but these can be inferred from the node name:
-
-```rust
-dispatcher!("remote.add"); // although the type is unknown, we can infer CMDRemoteAdd and EntryRemoteAdd
-```
-
-And also `#[program_setup]`:
-
-```rust
-#[program_setup] // can infer CustomSetup from the function name `custom_setup`
-fn custom_setup(program: &mut Program<ThisProgram>) {
-    program.with_dispatchers((CMD1, CMD2, CMD3, CMD4, CMD5));
-}
-```
-
-## Pathf Output Format
-
-Uses TOML key-value pairs, formatted as follows:
-
-```toml
-ResultRemoteAdd = "crate::mymod::ResultRemoteAdd"
-```
-
-Recommended storage location is under the target directory:
-
-```
-/target/{target}/{crate-name}/type-mapping.toml
-```
-
-## Other Issues
-
-This solution is limited to Mingling's own syntax system. If types like `dispatcher!`, `pack!` are indirectly expanded through macros, the analyzer will not be able to discover them.
-
-However, this approach solves the current main pain points, so this issue can be set aside for now and addressed later.
diff --git a/docs/dev-docs/issues/the-shit-time.md b/docs/dev-docs/issues/the-shit-time.md
deleted file mode 100644
index 77a8af9..0000000
--- a/docs/dev-docs/issues/the-shit-time.md
+++ /dev/null
@@ -1,90 +0,0 @@
-<h1 align="center">Some Situations Where You'd Be Like "Shit!"</h1>
-<p align="center">
-    This document collects the discomforts currently experienced while using Mingling.
-</p>
-
-This document collects the discomforts currently experienced while using Mingling.
-
-Of course, you can also contribute to this document.
-
----
-
-## Why is there no fallback completion logic?
-
-(completion) (fallback)
-
-Currently, Mingling's Completion only supports providing completion logic for specific subcommands, with no way to provide global completion.
-
-For example:
-
-```
-mycmd <tab>
-completion:
---help    -h  --- Display helps
---version -V  --- Display versions
-```
-
-Currently, there is no workaround.
-
-Ideal solution:
-
-```rust
-#[completion(EntryGlobal)]
-fn complete(ctx: &ShellContext) -> Suggest {
-    // ...
-}
-```
-
----
-
-## Why can't I register descriptions for commands?
-
-(completion) (dispatcher)
-
-Currently, Mingling's Completion cannot register a description for each subcommand.
-
-For example:
-
-```
-mycmd <tab>
-completion:
-add rm list <--- You cannot register descriptions for commands
-```
-
-Expected behavior:
-
-```
-mycmd <tab>
-completion:
-add  --- Add something
-rm   --- Remove something
-list --- List something
-```
-
-Ideal solution:
-
-```rust
-// It should be able to freely integrate with crates that provide i18n functionality,
-// so the following approach cannot be used as a data source for descriptions.
-dispatcher! {
-    /// Add Something <--- How to i18n?
-    "add", CMDAdd => EntryAdd
-}
-
-// Ideally, it should satisfy the following two conditions:
-// 1. No need to use `with_dispatcher`, because `with_dispatcher` is disabled in `dispatch_tree` mode
-// 2. Must be able to accept String or &str at runtime
-
-// Current idea
-#[inline(always)]
-#[dispatcher_desc(EntryAdd)]
-fn desc_add() -> String {
-    // If using rust_i18n
-    t!("cmd.add.desc")
-}
-
-// Collected and generated by `gen_program!()`
-// Generate something like get_dispatcher_desc(id: &ThisProgram) -> String
-// Match the corresponding function using enum values inside ThisProgram
-gen_program!()
-```