Remove stale phase/spec references from code comments

Strip "Phase N", "SPEC §X.Y", and "v1.x" planning labels from comments
across the Rust crates and editor layers now that those tracking
artifacts are gone. Comments only — no logic, strings, or test names
touched.

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

crates/nuwiki-lsp/tests/commands_colorize.rs

@@ -1,9 +1,9 @@
-//! §13.1 §13.3 — `color_dic` → `HtmlRenderer` integration.
+//! `color_dic` → `HtmlRenderer` integration.
 //!
 //! Drives the renderer directly so we don't have to spin up the full
 //! export pipeline. The end-to-end path (export command → renderer
 //! with `cfg.color_dic` plumbed through) is integration-tested via the
-//! Phase 17 export tests.
+//! export tests.
 
 use std::collections::HashMap;
 

crates/nuwiki-lsp/tests/commands_coverage.rs

@@ -1,6 +1,6 @@
 //! Command-coverage suite: at least one behavioural test for every
-//! documented `:Nuwiki*` / `:Vimwiki*` command (see `doc/nuwiki.txt`
-//! §5 COMMANDS).
+//! documented `:Nuwiki*` / `:Vimwiki*` command (see the COMMANDS section
+//! of `doc/nuwiki.txt`).
 //!
 //! The user-facing commands funnel through `workspace/executeCommand`
 //! into the Backend dispatcher, or — for follow/backlinks/rename — through

crates/nuwiki-lsp/tests/commands_files.rs

@@ -1,6 +1,6 @@
-//! Phase 13: pure-function tests for the rename helper + the file-delete
+//! Pure-function tests for the rename helper + the file-delete
 //! command. The async `Backend::rename` end-to-end (with `read_or_open`
-//! hitting disk) is exercised by Phase 14+ integration but covered here
+//! hitting disk) is exercised by integration tests but covered here
 //! at the building-block level — same logic, no async client.
 
 use std::path::PathBuf;
@@ -95,7 +95,7 @@ async fn file_delete_returns_workspace_edit_with_delete_op() {
     //
     // Easier: shape the test as an integration test over the public
     // module surface — call `commands::execute` once we expose a thin
-    // builder. For Phase 13 we test the JSON-shaped contract using the
+    // builder. We test the JSON-shaped contract using the
     // edits module directly, since that's what `file_delete` returns.
     let uri = Url::parse("file:///tmp/note.wiki").unwrap();
     let mut b = nuwiki_lsp::edits::WorkspaceEditBuilder::new();

crates/nuwiki-lsp/tests/commands_lists.rs

@@ -1,4 +1,4 @@
-//! §13.1 Cluster A — list rewriters: `removeDone`, `renumber`,
+//! Cluster A — list rewriters: `removeDone`, `renumber`,
 //! `changeSymbol`, `changeLevel`.
 
 use nuwiki_core::ast::ListSymbol;

crates/nuwiki-lsp/tests/commands_tables.rs

@@ -1,4 +1,4 @@
-//! §13.1 Cluster B — table rewriters: `insert`, `align`, `moveColumn`.
+//! Cluster B — table rewriters: `insert`, `align`, `moveColumn`.
 
 use nuwiki_core::syntax::vimwiki::VimwikiSyntax;
 use nuwiki_core::syntax::SyntaxPlugin;

crates/nuwiki-lsp/tests/folding.rs

@@ -1,4 +1,4 @@
-//! Phase 19: LSP folding-range provider.
+//! LSP folding-range provider.
 //!
 //! Drives `folding::folding_ranges` directly. The handler wiring is
 //! shallow — it just calls into this function — so we verify the

crates/nuwiki-lsp/tests/helpers.rs

@@ -1,7 +1,7 @@
 //! Tests for the pure helpers that the LSP backend uses to translate
 //! between `nuwiki-core` ASTs and the LSP wire format. The async
-//! request-handling loop is exercised at integration time in Phase 8+
-//! (navigation), so this file stays focused on conversion correctness.
+//! request-handling loop is exercised at integration time by the
+//! navigation tests, so this file stays focused on conversion correctness.
 
 use nuwiki_core::ast::{
     inline::InlineNode, BlockNode, BlockquoteNode, DocumentNode, ErrorNode, ParagraphNode,

crates/nuwiki-lsp/tests/html_export.rs

@@ -1,4 +1,4 @@
-//! Phase 17: HTML export commands.
+//! HTML export commands.
 //!
 //! Drives the pure `export::*` helpers directly. The side-effecting
 //! `export_ops::write_page` / `write_rss` paths get exercised via a

crates/nuwiki-lsp/tests/link_health.rs

@@ -1,4 +1,4 @@
-//! Phase 15: link-health diagnostics + TOC/links/orphans queries.
+//! Link-health diagnostics + TOC/links/orphans queries.
 
 use std::path::PathBuf;
 

crates/nuwiki-lsp/tests/multi_wiki.rs

@@ -1,8 +1,8 @@
-//! Phase 18: multi-wiki — interwiki resolution + picker commands.
+//! Multi-wiki — interwiki resolution + picker commands.
 //!
 //! The cross-wiki resolver methods on `Backend` are exercised indirectly
 //! through `tower_lsp::LspService`'s test harness via a synthetic
-//! `Backend` (the same pattern Phase 13 used). To keep this test suite
+//! `Backend`. To keep this test suite
 //! lightweight we drive the *pure* resolution primitives — the parser
 //! producing `LinkKind::Interwiki` targets, then the `WorkspaceIndex`
 //! lookup-by-name — and verify the multi-wiki config shape end-to-end.
@@ -80,7 +80,7 @@ fn multi_wiki_config_loads_two_entries() {
 
 #[test]
 fn v1_0_single_root_still_works_alongside_multi_wiki_shape() {
-    // Single-wiki shorthand is the v1.0 form; ensure it still desugars.
+    // Single-wiki shorthand is the legacy form; ensure it still desugars.
     let cfg = config_from_json(serde_json::json!({
         "wiki_root": "/tmp/legacy",
     }));
@@ -135,7 +135,7 @@ fn nested_root_picks_longest_prefix_match() {
 
 // ===== Cross-wiki resolution (uses WorkspaceIndex per wiki) =====
 
-/// Verify that the cross-wiki resolution semantics match the SPEC:
+/// Verify the cross-wiki resolution semantics:
 /// `[[wiki1:Page]]` looks up `Page` in the *second* wiki's index, not
 /// the source wiki's. The pure-data check here mirrors what
 /// `Backend::resolve_target_uri` does.

crates/nuwiki-lsp/tests/navigation.rs

@@ -1,7 +1,7 @@
-//! Tests for the Phase 8 navigation pieces: WorkspaceIndex queries,
+//! Tests for the navigation pieces: WorkspaceIndex queries,
 //! page-name derivation, anchor slugify, position lookup, and link
 //! resolution. The async LSP handlers are exercised through these
-//! helpers; end-to-end JSON-RPC drive lives in a follow-up phase.
+//! helpers; end-to-end JSON-RPC drive lives elsewhere.
 
 use std::path::PathBuf;