refactor: rename Rule 1/Rule 2 to skip rule/prune rule

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: branchseer

crates/vite_task_plan/src/plan.rs

@@ -200,7 +200,7 @@ async fn plan_task_as_execution_node(
             let execution_item_kind: ExecutionItemKind = match plan_request {
                 // Expand task query like `vp run -r build`
                 Some(PlanRequest::Query(query_plan_request)) => {
-                    // Rule 1: skip if this nested query is the same as the parent expansion.
+                    // Skip rule: skip if this nested query is the same as the parent expansion.
                     // This handles workspace root tasks like `"build": "vp run -r build"` —
                     // re-entering the same query would just re-expand the same tasks.
                     if query_plan_request.query == *context.parent_query() {
@@ -566,7 +566,7 @@ fn plan_spawn_execution(
 /// Builds a `DiGraph` of task executions, then validates it is acyclic via
 /// `ExecutionGraph::try_from_graph`. Returns `CycleDependencyDetected` if a cycle is found.
 ///
-/// **Rule 2 (prune self):** If the expanding task (the task whose command triggered
+/// **Prune rule:** If the expanding task (the task whose command triggered
 /// this nested query) appears in the expansion result, it is pruned from the graph
 /// and its predecessors are wired directly to its successors. This prevents
 /// workspace root tasks like `"build": "vp run build"` from infinitely re-expanding
@@ -609,7 +609,7 @@ pub async fn plan_query_request(
 
     let task_node_index_graph = task_query_result.execution_graph;
 
-    // Rule 2: if the expanding task appears in the expansion, prune it.
+    // Prune rule: if the expanding task appears in the expansion, prune it.
     // This handles cases like root `"build": "vp run build"` — the root's build
     // task is in the result but expanding it would recurse, so we remove it and
     // reconnect its predecessors directly to its successors.

crates/vite_task_plan/tests/plan_snapshots/fixtures/workspace-root-depends-on-passthrough/snapshots.toml

@@ -1,6 +1,6 @@
 # Tests that dependsOn works through a passthrough root task.
 # Root build = "vp run -r build", with dependsOn: ["lint"].
-# Rule 1 skips the recursive part, but the dependsOn lint tasks still run.
+# The skip rule skips the recursive part, but the dependsOn lint tasks still run.
 
 [[plan]]
 name = "depends on through passthrough"

crates/vite_task_plan/tests/plan_snapshots/fixtures/workspace-root-multi-command/snapshots.toml

@@ -1,5 +1,5 @@
 # Tests multi-command with self-referencing: root build = "echo pre && vp run -r build"
-# Rule 1 skips the recursive `vp run -r build` part, echo pre still runs.
+# The skip rule skips the recursive `vp run -r build` part, echo pre still runs.
 
 [[plan]]
 name = "multi command skips recursive part"

crates/vite_task_plan/tests/plan_snapshots/fixtures/workspace-root-self-reference/snapshots.toml

@@ -1,14 +1,14 @@
-# Tests workspace root self-reference handling (Rule 1 and Rule 2)
+# Tests workspace root self-reference handling (skip rule and prune rule)
 
-# Rule 1: root's build command is `vp run -r build`, which is the same query
+# Skip rule: root's build command is `vp run -r build`, which is the same query
 # as the top-level `vp run -r build`. The nested `vp run -r build` is skipped,
 # so root#build becomes a passthrough (no items expand). Siblings a and b run.
 [[plan]]
 name = "recursive build skips self"
 args = ["run", "-r", "build"]
 compact = true
 
-# Rule 2: root's build command is `vp run -r build`, but top-level query is
+# Prune rule: root's build command is `vp run -r build`, but top-level query is
 # `vp run build` (current package = root, no -r). The nested query differs
 # (All vs ContainingPackage), so it expands. Root appears in the expansion
 # result and is pruned — only a and b remain in the nested graph.