docs: sync clice

en/clice/design/compilation-context.md

@@ -98,7 +98,7 @@ When a file needs to be compiled, the compilation context is automatically deter
 
 Beyond automatic resolution, clice also provides four LSP extension requests that let users explicitly query and switch compilation contexts:
 
-**`clice/queryContext`** lists all available compilation contexts for a file. For headers, it returns the source files that can serve as hosts, ranked by relevance; for source files, it returns all CDB entries, using key flags from the compilation command (`-D`, `-std`, `-O`, etc.) as human-readable descriptions, each carrying a command hash identifying the entry. Results support pagination. For self-contained headers and source files, the context list is deduplicated by the entry's **identity hash**, computed over the frontend-relevant view of the effective command plus the input's slot position and working directory: two contexts with the same identity produce identical compilation results, so only the best-ranked representative is kept — otherwise a widely-included header like `<vector>` could list thousands of contexts. Non-self-contained headers are not merged this way: different hosts synthesize different prefixes, so every host is a distinct context. When the host's compile enters a header several times (a guard-less header), each place it does is returned as a separate entry distinguished by an occurrence number.
+**`clice/queryContext`** lists all available compilation contexts for a file. For headers, it returns the source files that can serve as hosts, ranked by relevance; for source files, it returns all CDB entries, using key flags from the compilation command (`-D`, `-std`, `-O`, etc.) as human-readable descriptions, each carrying a command hash identifying the entry. Results support pagination. For self-contained headers and source files, the context list is deduplicated by the entry's **command hash**, computed over the frontend-relevant view of the effective command plus the input's slot position and working directory: two contexts with the same identity produce identical compilation results, so only the best-ranked representative is kept — otherwise a widely-included header like `<vector>` could list thousands of contexts. Non-self-contained headers are not merged this way: different hosts synthesize different prefixes, so every host is a distinct context. When the host's compile enters a header several times (a guard-less header), each place it does is returned as a separate entry distinguished by an occurrence number.
 
 **`clice/currentContext`** returns the context the file compiles under, as the listing names it, and whether the user chose it: the selection when there is one (host + occurrence, or command hash), else the context picked automatically. It returns no context only for a file that borrows none and has no entry of its own.
 

en/clice/design/overview.md

@@ -37,8 +37,9 @@ General-purpose utilities and infrastructure shared by all other modules.
 
 Commands read from the compilation database (CDB) are raw commands generated by the build system and cannot be fed directly to the Clang frontend -- they may contain options meant only for code generation, lack system header search paths, or include parameters irrelevant to a language server. This module parses each command once into a structured form that the rest of the system consumes.
 
-- `CompilationDatabase`: Loads `compile_commands.json` and parses every entry once into an interned, classified argument structure identified by a stable `ConfigID`. On top of that it applies user configuration rules, synthesizes fallback commands for files without an entry, derives the input language, computes entry identity hashes, and renders driver or `-cc1` command lines on demand
-- `Toolchain`: Queries system compilers for implicit compilation parameters (such as system header search paths), with a two-layer cache — probe results per driver invocation shape, and synthesized flag sets per input kind
+- `CommandTable`: Every command clice knows, parsed once into an interned, classified argument structure identified by a stable `CommandID`, with what derives from one command: its input language, the precompiled headers it writes and reads, its command hash, its driver-level renders
+- `CompilationDatabase`: Loads, reloads and diffs the `compile_commands.json` files, their entries normalized (`Normalizer`) into the `CommandTable`; the rules' edits apply on top of an entry's command (`apply_edits`)
+- `Toolchain`: Queries system compilers for implicit compilation parameters (such as system header search paths), with a two-layer cache — query results per driver invocation shape, and synthesized flag sets per input kind — and renders the `-cc1` command lines; how each compiler kind is asked (GCC-style, cl, nvcc, clang's own driver) lives under `src/command/toolchains/`
 - `SearchConfig`: A four-tier model for header search paths (Quoted / Angled / System / After), matching Clang's internal search logic
 
 See [Compilation Command Resolution](command-resolve.md).

en/clice/design/symbol-index.md

@@ -160,7 +160,7 @@ The index is rebuilt from the records, on the thread pool, when the symbols merg
 
 ### Staleness Detection
 
-Staleness detection determines whether a file needs to be re-indexed. Each indexed artifact records the identity and observed content version of its inputs; validation is delegated to the master's shared file table, which performs the same two-layer check used everywhere else — a (size, mtime) stat fast path against the file's last observation, then content-hash confirmation (see [Incremental Compilation](incremental-parse.md)). Re-indexing triggers only when input content actually changed; command changes are caught separately through the entry identity hashes recorded in the manifests. At startup the writer checks every file record against the disk and queues the units depending on a file that changed, on a place a failed lookup looked at that now holds a file, or on a changed input of a module or a precompiled header, and the units whose variants a rebuild of a shared file discarded; the stored shards serve until they are indexed again.
+Staleness detection determines whether a file needs to be re-indexed. Each indexed artifact records the identity and observed content version of its inputs; validation is delegated to the master's shared file table, which performs the same two-layer check used everywhere else — a (size, mtime) stat fast path against the file's last observation, then content-hash confirmation (see [Incremental Compilation](incremental-parse.md)). Re-indexing triggers only when input content actually changed; command changes are caught separately through the command hashes recorded in the manifests. At startup the writer checks every file record against the disk and queues the units depending on a file that changed, on a place a failed lookup looked at that now holds a file, or on a changed input of a module or a precompiled header, and the units whose variants a rebuild of a shared file discarded; the stored shards serve until they are indexed again.
 
 ### Background Indexing Scheduling