+}
+```
+
+## Tasks
+
+- [ ] Identify all usages of `pack!` / `pack_structural!` / `pack_err_structural!` across the codebase, examples, and docs
+- [ ] Migrate internal usages to `#[derive(Grouped)]`
+- [ ] Remove the macro definitions and their re-exports
+- [ ] Update the docs / helpdoc examples that reference `pack!`
+- [ ] Update downstream feature docs (`structural_renderer` etc.) where `pack_structural!` was involved
+- [ ] Verify all tests pass
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t0_remove-parser-feature.md b/docs/dev/pages/issues/t0_remove-parser-feature.md
new file mode 100644
index 0000000..5c1cffd
--- /dev/null
+++ b/docs/dev/pages/issues/t0_remove-parser-feature.md
@@ -0,0 +1,36 @@
+[T0] Remove the parser Feature
+
+ Breaking: retire the legacy argument parsing in favor of picker
+
+
+> [!NOTE]
+>
+> This is a **Breaking Change** planned for Mingling 0.5.0.
+
+## Background
+
+In 0.3.0, Mingling introduced the `picker` feature, which provides more powerful parameter parsing capabilities. At that point, the original `parser` feature became inadequate.
+
+The `parser` feature was a temporary argument parsing solution created in the early stages of the project. While it can handle basic argument parsing tasks, its functionality is incomplete and has many limitations (see the [Picker2 issue](_add-picker2) for the full list).
+
+## Plan
+
+Completely remove the `parser` feature in 0.5.0. This will directly affect downstream users of the `parser` feature — they must migrate to `picker` (or handle parsing manually).
+
+## Tasks
+
+- [ ] Identify all usages of the `parser` feature across the codebase, examples, and docs
+- [ ] Migrate internal usages (tests, examples, dev-dependencies) to `picker`
+- [ ] Remove the `parser` feature from `mingling` and its dependency (`size`)
+- [ ] Remove parser-related modules and public API
+- [ ] Update docs and helpdoc examples
+- [ ] Note the downstream migration path in the changelog
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t0_remove-with-dispatcher.md b/docs/dev/pages/issues/t0_remove-with-dispatcher.md
new file mode 100644
index 0000000..8779d74
--- /dev/null
+++ b/docs/dev/pages/issues/t0_remove-with-dispatcher.md
@@ -0,0 +1,35 @@
+[T0] Remove with_dispatcher and with_dispatchers
+
+ Breaking: make Dispatcher registration compile-time collected in all modes
+
+
+> [!NOTE]
+>
+> This is a **Breaking Change** planned for Mingling 0.5.0.
+
+## Background
+
+Mingling's commands must be registered through `with_dispatcher` in order to be usable when `dispatcher_tree` is disabled. This has always been a strange semantic: `chain`, `renderer`, `help`, `completion`, and `metadata` are all collected at compile time, so why is `Dispatcher` the exception?
+
+In fact, during usage of `dispatcher` from 0.1.0 to 0.4.0, no scenario has ever been encountered where **dynamic registration** was necessary. It is considered unnecessary.
+
+## Plan
+
+Make `Dispatcher` registration also compile-time collected in non-`dispatcher_tree` states starting from 0.5.0, and remove `with_dispatcher` / `with_dispatchers` (and the related `#[program_setup]` registration path if it becomes obsolete).
+
+## Tasks
+
+- [ ] Design how dispatchers are collected at compile time when `dispatcher_tree` is disabled (consistent with how `chain` / `renderer` / `completion` / `metadata` are collected)
+- [ ] Remove `with_dispatcher` and `with_dispatchers` from the `Program` API
+- [ ] Update `gen_program!` and the macros so registration happens automatically
+- [ ] Migrate examples, tests, and docs that call `with_dispatcher` / `with_dispatchers`
+- [ ] Verify both `dispatcher_tree`-enabled and disabled modes behave identically
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t1_completion-higher-level-abstractions.md b/docs/dev/pages/issues/t1_completion-higher-level-abstractions.md
new file mode 100644
index 0000000..69adba0
--- /dev/null
+++ b/docs/dev/pages/issues/t1_completion-higher-level-abstractions.md
@@ -0,0 +1,38 @@
+[T1] Higher-Level Abstractions for the Completion System
+
+ Feature: smarter state descriptions in ShellContext and a picker_comp module
+
+
+## Background
+
+Mingling's completion system filled a number of behavioral gaps in 0.4 and fixed many edge cases. It's now time to introduce more powerful higher-level abstractions.
+
+Currently, completion logic relies on manually identifying user behavior through fields like `previous_word`, which is fragile and requires every completion function to re-derive the user's intent.
+
+## Plan
+
+### 1. Utility functions on `ShellContext`
+
+Add a set of utility functions to `ShellContext`, enabling a smarter description of user state, rather than simply relying on manually identifying user behavior through fields like `previous_word`.
+
+### 2. `picker_comp` module
+
+Additionally, when the `picker` feature (introduced in 0.3.0) is enabled together with the `comp` feature, a module named `picker_comp` will be activated to enable more completion behaviors — e.g. completing picker-style flags (`--key=value`, multi-flag forms, etc.) using knowledge of the picker parsing model.
+
+## Tasks
+
+- [ ] Design the `ShellContext` utility API (state descriptions / high-level queries over the current input state)
+- [ ] Implement the utility functions and add tests
+- [ ] Implement the `picker_comp` module, gated on `picker` + `comp`
+- [ ] Add completion behaviors specific to picker argument formats
+- [ ] Update docs and examples
+- [ ] Verify existing 0.4 completion edge-case fixes are preserved
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t1_modify-dispatcher-syntax.md b/docs/dev/pages/issues/t1_modify-dispatcher-syntax.md
new file mode 100644
index 0000000..f1a9346
--- /dev/null
+++ b/docs/dev/pages/issues/t1_modify-dispatcher-syntax.md
@@ -0,0 +1,44 @@
+[T1] Modify the dispatcher! Syntax
+
+ Breaking: drop the CMD* struct from the explicit form of dispatcher!
+
+
+> [!NOTE]
+>
+> This is a **Breaking Change** planned for Mingling 0.5.0, and it depends on [Remove with_dispatcher and with_dispatchers](t0_remove-with-dispatcher).
+
+## Background
+
+Once `Dispatcher` registration is compile-time collected (see [Remove with_dispatcher and with_dispatchers](t0_remove-with-dispatcher)), the `CMD*` struct becomes unnecessary — it only existed to give `with_dispatcher` something to register.
+
+## Plan
+
+Simplify the `dispatcher!` syntax: the explicit form no longer creates a `CMD*` struct, so only the entry type needs to be given.
+
+```rust
+// Before
+dispatcher!("command", CMDCommand => EntryCommand);
+
+// After
+dispatcher!("command", EntryCommand);
+
+// NOTE: The implicit mode is not affected
+```
+
+## Tasks
+
+- [ ] Update `dispatcher!` to accept the simplified explicit form (`"name", EntryType`)
+- [ ] Decide whether the old `CMDType => EntryType` form should error with a helpful message or be removed outright
+- [ ] Remove the generated `CMD*` struct machinery
+- [ ] Update `#[command]` macro internals that depend on `CMD*`
+- [ ] Migrate examples, tests, and docs
+- [ ] Keep the implicit mode (`dispatcher!("name")`) working unchanged
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t1_move-structural-renderer.md b/docs/dev/pages/issues/t1_move-structural-renderer.md
new file mode 100644
index 0000000..66da5c8
--- /dev/null
+++ b/docs/dev/pages/issues/t1_move-structural-renderer.md
@@ -0,0 +1,38 @@
+[T1] Move structural_renderer from mingling_core to mingling
+
+ Breaking: inject StructuralRenderer via Hook instead of hardcoding it into the core loop
+
+
+> [!NOTE]
+>
+> This is a **Breaking Change** planned for Mingling 0.5.0.
+
+## Background
+
+Mingling's Hook system is now complete, so there's no longer a need to hardcode `StructuralRenderer` into the core loop.
+
+The plan is to remove it from `exec.rs` and instead inject the Hook implementation via `StructuralRendererSetup`.
+
+## Plan
+
+- Remove the hardcoded `StructuralRenderer` from the core execution loop (`exec.rs`).
+- Implement the renderer as a Hook and inject it via `StructuralRendererSetup`.
+- `mingling_core` no longer depends on the structural renderer; the wiring moves up to the `mingling` crate level.
+
+## Tasks
+
+- [ ] Audit where `StructuralRenderer` is hardcoded in `mingling_core` (`exec.rs` and related)
+- [ ] Design `StructuralRendererSetup` as a Hook implementation
+- [ ] Move / re-implement the renderer wiring in `mingling`
+- [ ] Clean up `mingling_core`'s `structural_renderer` feature and its serde deps (if no longer needed there)
+- [ ] Migrate examples and tests
+- [ ] Verify structural renderer output is unchanged
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t1_pathf-export-macro.md b/docs/dev/pages/issues/t1_pathf-export-macro.md
new file mode 100644
index 0000000..0a98485
--- /dev/null
+++ b/docs/dev/pages/issues/t1_pathf-export-macro.md
@@ -0,0 +1,53 @@
+[T1] The pathf_export Attribute Macro
+
+ Feature: an escape hatch for pathf's path inference
+
+
+## Background
+
+`pathf` has been around since 0.2.0 and has worked well for a long time, with many edge cases resolved. However, it still lacks an escape hatch — "when certain indirect expansions cannot be recognized by `pathf`, how can we assist its inference?"
+
+For example, when a Mingling type is created through a user-defined `macro_rules!` wrapper, `pathf` cannot see through the indirect expansion:
+
+```rust
+#[macro_export]
+macro_rules! repack {
+ ($name:ident) => {
+ // Ignored! This section cannot be parsed by pathf.
+ #[mingling::macros::pathf_ignore]
+ #[derive(mingling::Grouped)]
+ pub struct $name;
+ };
+}
+
+// The expansion contains macros that need to be parsed by pathf
+#[pathf_export(MyType)] // Explicitly specified to assist pathf's inference
+repack!(MyType);
+```
+
+> [!Note]
+> Haha, hopefully we'll never have to use it.
+
+## Plan
+
+Introduce a new attribute macro, `#[pathf_export(type::TypePath)]`, to supplement `pathf`'s path inference. When applied to an item whose expansion contains Mingling types that `pathf` cannot recognize, it explicitly records the resulting type paths so the build-time analyzer can pick them up.
+
+The example above also shows `#[mingling::macros::pathf_ignore]`, which marks an item to be skipped by `pathf` (used inside macro bodies that `pathf` otherwise cannot parse).
+
+## Tasks
+
+- [ ] Design the `pathf_export` syntax and semantics (attribute position, multiple type paths, interplay with `pathf_ignore`)
+- [ ] Implement `pathf_export` in `mingling_macros`
+- [ ] Implement `pathf_ignore` support in `mingling_macros`
+- [ ] Teach `mingling-pathf` to consume the exported mappings
+- [ ] Add tests covering indirect macro expansions
+- [ ] Update docs and examples
+
+## 🕘 Progress
+
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
diff --git a/docs/dev/pages/issues/t2_automated-dispatch-tree-optimization.md b/docs/dev/pages/issues/t2_automated-dispatch-tree-optimization.md
new file mode 100644
index 0000000..691fd1a
--- /dev/null
+++ b/docs/dev/pages/issues/t2_automated-dispatch-tree-optimization.md
@@ -0,0 +1,57 @@
+[T2] Automated dispatcher_tree Optimization Decisions
+
+ Feature: let Mingling decide when dispatch_tree pays off (under consideration)
+
+
+> [!NOTE]
+>
+> This item is **under consideration**. It depends on [Remove with_dispatcher and with_dispatchers](t0_remove-with-dispatcher).
+
+## Background
+
+`dispatch_tree` provides a faster dispatch path, but it is not always a win. Currently users must manually enable the `dispatch_tree` feature and make the trade-off themselves.
+
+After dispatcher registration becomes compile-time collected (see [Remove with_dispatcher and with_dispatchers](t0_remove-with-dispatcher)), Mingling can know the full set and depth of registered commands at compile time — making automated decisions implementable.
+
+## Plan
+
+Mingling can automatically decide whether to use `dispatcher_tree` to optimize dispatch efficiency based on the current number and depth of registered commands, so users no longer need to manually enable the `dispatch_tree` feature.
+
+### Conditions
+
+`dispatch_tree` has an advantage in cases where command depth is too high and the number of commands is too large. However, if the number of commands is too small, the increased CPU prediction failure rate will inevitably make it less efficient than linear lookup; specifics need to be tuned during implementation.
+
+### Resolve the `pathf` + `dispatch_tree` build-dependency issue
+
+Additionally, the issue where `pathf` + `dispatch_tree` must be explicitly specified in `[build-dependencies]` will be resolved:
+
+```toml
+# Before
+[build-dependencies.mingling]
+version = "0.4.0"
+features = [ "build", "pathf", "dispatch_tree" ] # `dispatch_tree` must be explicitly specified for `pathf` to recognize it
+
+# After
+[build-dependencies.mingling]
+version = "0.4.0"
+features = [ "build", "pathf" ] # No `dispatch_tree` feature; `pathf` no longer needs to consider its branches
+```
+
+## Tasks
+
+- [ ] Collect statistics about registered commands (count, depth) at compile time
+- [ ] Benchmark / tune the threshold between linear lookup and `dispatch_tree`
+- [ ] Implement the automatic decision and wire it into dispatch code generation
+- [ ] Remove the manual `dispatch_tree` feature toggle (or keep it as an override?)
+- [ ] Refactor `pathf` so it no longer branches on `dispatch_tree`
+- [ ] Update examples, tests, and docs
+
+## 🕘 Progress
+
+- [ ] Under Consideration
+- [ ] In Progress
+- [ ] Complete
+
+
+ Written by @Weicao-CatilGrass
+
--
cgit