docs: professional-tone rewrite, IA cleanup, signature fixes

- Rewrite prose across all docs pages into a neutral, professional
  technical-documentation tone; remove anthropomorphizing/agent-guessing
  framing and marketing phrasing.
- Fix Java method declarations to use fully-qualified parameter types
  (e.g. addOption(org.apache.commons.cli.Option),
  parse(org.apache.commons.cli.Options, java.lang.String[])).
- Remove the reachability section from Core concepts and Common tasks
  (kept as an application-level capability in cocoa).
- Replace the broken Mermaid diagram on "What is CLDK?" and expand the
  language-coverage table.
- Merge the "Guides" and "Build with CLDK" sidebar groups.
- Remove the "Build with CLDK" overview and "COCO MCP Toolbox" pages and
  strip all inbound links.
- Replace em-dashes with parentheses/colon/comma and normalize en-dashes.

Author: rahlk

README.md

@@ -25,24 +25,22 @@
   </a>
 </p>
 
-Codellm-Devkit (CLDK) is a multilingual program analysis framework that bridges the gap between traditional static analysis tools and Large Language Models (LLMs) specialized for code (CodeLLMs). Codellm-Devkit allows developers to streamline the process of transforming raw code into actionable insights by providing a unified interface for integrating outputs from various analysis tools and preparing them for effective use by CodeLLMs.
+Codellm-Devkit (CLDK) is a multilingual program analysis framework for CodeLLM workflows. It turns source code into structured program facts such as symbols, method bodies, call graphs, and data-model objects that an LLM pipeline can query.
 
-Codellm-Devkit simplifies the complex process of analyzing codebases that span multiple programming languages, making it easier to extract meaningful insights and drive LLM-based code analysis. `CLDK` achieves this through an open-source Python library that abstracts the intricacies of program analysis and LLM interactions. With this library, developer can streamline the process of transforming raw code into actionable insights by providing a unified interface for integrating outputs from various analysis tools and preparing them for effective use by CodeLLMs.
+CLDK is an open-source Python library over language-specific analysis backends. The user calls one API; the backend handles parsing, symbol resolution, and graph construction for the selected language.
 
-**The purpose of Codellm-Devkit is to enable the development and experimentation of robust analysis pipelines that harness the power of both traditional program analysis tools and CodeLLMs.**
-By providing a consistent and extensible framework, Codellm-Devkit aims to reduce the friction associated with multi-language code analysis and ensure compatibility across different analysis tools and LLM platforms.
+**The purpose of Codellm-Devkit is to help build analysis pipelines that combine program-analysis results with CodeLLMs.**
+It gives those pipelines a consistent shape across languages and analysis tools.
 
-Codellm-Devkit is designed to integrate seamlessly with a variety of popular analysis tools, such as WALA, Tree-sitter, LLVM, and CodeQL, each implemented in different languages. Codellm-Devkit acts as a crucial intermediary layer, enabling efficient and consistent communication between these tools and the CodeLLMs.
+CLDK integrates with tools such as WALA, Tree-sitter, LLVM, and CodeQL. It normalizes their outputs into typed models that downstream code can consume.
 
-Codellm-Devkit is constantly evolving to include new tools and frameworks, ensuring it remains a versatile solution for code analysis and LLM integration.
+CLDK is an ongoing IBM Research project.
 
 Codellm-Devkit is:
 
-- **Unified**: Provides a single framework for integrating multiple analysis tools and CodeLLMs, regardless of the programming languages involved.
-- **Extensible**: Designed to support new analysis tools and LLM platforms, making it adaptable to the evolving landscape of code analysis.
-- **Streamlined**: Simplifies the process of transforming raw code into structured, LLM-ready inputs, reducing the overhead typically associated with multi-language analysis.
-
-Codellm-Devkit is an ongoing project, developed at IBM Research.
+- **Unified**: one API over language-specific analysis backends.
+- **Extensible**: new backends can add languages or analysis tools.
+- **Structured**: code becomes typed models, call graphs, and other queryable artifacts.
 
 ## Contact
 
@@ -68,7 +66,7 @@ For any questions, feedback, or suggestions, please contact the authors:
 
 ## Architectural and Design Overview
 
-Below is a very high-level overview of the architectural of CLDK:
+Below is a high-level view of CLDK's architecture:
 
 
 ```mermaid
@@ -96,17 +94,17 @@ User <--> A[CLDK]
 X[‡ Yet to be implemented]
 ```
 
-The user interacts by invoking the CLDK API. The CLDK API is responsible for handling the user requests and delegating them to the appropriate language-specific modules. 
+The user invokes the CLDK API. CLDK delegates the request to the language-specific module.
 
-Each language comprises of two key components: data models and backends.
+Each language has two main components: data models and backends.
 
-1. **Data Models:** These are high level abstractions that represent the various language constructs and componentes in a structured format using pydantic. This confers a high degree of flexibility and extensibility to the models as well as allowing for easy accees of various data components via a simple dot notation. In addition, the data models are designed to be easily serializable and deserializable, making it easy to store and retrieve data from various sources.
+1. **Data Models:** Pydantic models for language constructs such as files, classes, methods, fields, and call edges. They support attribute access and serialization.
 
-2. **Analysis Backends:** These are the components that are responsible for interfacing with the various program analysis tools. The core backends are Treesitter, Javaparse, WALA, LLVM, and CodeQL. The backends are responsible for handling the user requests and delegating them to the appropriate analysis tools. The analysis tools perfrom the requisite analysis and return the results to the user. The user merely calls one of several high-level API functions such as `get_method_body`, `get_method_signature`, `get_call_graph`, etc. and the backend takes care of the rest. 
+2. **Analysis Backends:** Components that call program-analysis tools such as Treesitter, Javaparser, WALA, LLVM, and CodeQL. The user calls high-level methods such as `get_method_body`, `get_method_signature`, or `get_call_graph`; the backend runs the required analysis and returns the result.
 
-    Some langugages may have multiple backends. For example, Java has WALA, Javaparser, Treesitter, and CodeQL backends. The user has freedom to choose the backend that best suits their needs. 
+    Some languages may have multiple backends. For example, Java uses WALA, Javaparser, Treesitter, and CodeQL-backed analysis.
 
-We are currently working on implementing the retrieval and prompting components. The retrieval component will be responsible for retrieving the relevant code snippets from the codebase for RAG usecases. The prompting component will be responsible for generating the prompts for the CodeLLMs using popular prompting frameworks such as `PDL`, `Guidance`, or `LMQL`.  
+Retrieval and prompting components are still in progress. Retrieval will pull relevant code snippets for RAG use cases. Prompting will generate CodeLLM prompts with frameworks such as `PDL`, `Guidance`, or `LMQL`.
 
 ## Quick Start: Example Walkthrough
 

astro.config.mjs

@@ -154,22 +154,11 @@ export default defineConfig({
           items: [
             { label: "Core concepts", slug: "guides/concepts", attrs: { "data-cldk-icon": "learning-16" } },
             { label: "Common tasks", slug: "guides/common-tasks", attrs: { "data-cldk-icon": "workflow-16" } },
-          ],
-        },
-        {
-          label: "Build with CLDK",
-          items: [
-            { label: "Overview", slug: "build", attrs: { "data-cldk-icon": "manual-16" } },
             {
               label: "Code Context Agent",
               slug: "cocoa",
               attrs: { "data-cldk-icon": "chat-16" },
             },
-            {
-              label: "COCO MCP Toolbox",
-              slug: "cocoa-mcp",
-              attrs: { "data-cldk-icon": "globe-network-16" },
-            },
           ],
         },
         {

src/components/HomeCards.astro

@@ -20,19 +20,19 @@ type Card = {
 const cards: Card[] = [
   {
     title: "Examples",
-    description: "Worked Python and Java snippets, straight from the test suite.",
+    description: "Runnable Python and Java snippets pulled from SDK tests.",
     href: "/examples/",
     icon: "workflow",
   },
   {
     title: "cocoa",
-    description: "Build a Code Context Agent plugin that drives CLDK from a coding agent's Bash tool.",
+    description: "Claude Code plugin for callers, reachability, and change impact.",
     href: "/cocoa/",
     icon: "chat",
   },
   {
     title: "API reference",
-    description: "The CLDK factory and the per-language analysis facades.",
+    description: "The CLDK factory, language APIs, and typed models.",
     href: "/reference/python-api/",
     icon: "manual",
   },

src/content/docs/backends.mdx

@@ -1,26 +1,26 @@
 ---
 title: The codeanalyzer backends
-description: "CLDK is a thin Python frontend over a family of standalone language analyzers: the codeanalyzer-* backends. Here's how that split works and where each one lives."
+description: "CLDK is a Python frontend over standalone per-language analyzers, the codeanalyzer-* backends. This page describes the frontend/backend split and where each backend lives."
 ---
 
 import { Badge, CardGrid, LinkCard, Aside } from "@astrojs/starlight/components";
 
-The Python SDK you call is deliberately thin. The heavy lifting (parsing source, resolving symbols, building call graphs) happens in a family of **standalone language analyzers**, one per language, collectively the `codeanalyzer-*` backends. Each one emits the same shape of typed JSON, and the SDK facade deserializes it into the models you query.
+Source parsing, symbol resolution, and call-graph construction are performed by **standalone language analyzers**, one per language, collectively the `codeanalyzer-*` backends. Each backend emits typed JSON, and the SDK deserializes it into queryable models.
 
 ```mermaid
 flowchart LR
-    SDK["CLDK Python SDK<br/>(analysis facade)"] -->|invokes| CAJ["codeanalyzer-java<br/>(JVM · WALA)"]
+    SDK["CLDK Python SDK<br/>(analysis API)"] -->|invokes| CAJ["codeanalyzer-java<br/>(JVM · WALA)"]
     SDK -->|invokes| CAP["codeanalyzer-python<br/>(Jedi · CodeQL)"]
-    SDK -.->|coming soon| CAT["codeanalyzer-ts<br/>(TS compiler)"]
+    SDK -->|invokes| CAT["codeanalyzer-ts<br/>(TS compiler)"]
     CAJ -->|canonical JSON| SDK
     CAP -->|canonical JSON| SDK
-    CAT -.->|canonical JSON| SDK
+    CAT -->|canonical JSON| SDK
 ```
 
-This separation is what lets one `analysis` API span languages: the facade never parses code itself, it shells out to the right backend, then maps the backend's JSON onto typed models (`JApplication`, `PyModule`, …). Add a backend that speaks the canonical JSON and the SDK can analyze a new language with almost no new frontend logic: see [Add a language backend](/contributing/add-language-backend/).
+This separation lets a single `analysis` API span languages. The SDK does not parse code itself; it invokes the appropriate backend, then maps the backend JSON onto typed models (`JApplication`, `PyModule`, and others). A backend that emits the canonical JSON makes its language available to the SDK with only binding work required. See [Add a language backend](/contributing/add-language-backend/).
 
-<Aside type="note" title="You usually don't run these directly">
-The SDK manages the backend for you: auto-downloading the Java JAR, provisioning the Python analyzer in a virtualenv. These pages are for when you want to understand (or contribute to) what's happening underneath.
+<Aside type="note" title="Backends are managed by the SDK">
+The SDK manages the backend automatically: it downloads the Java JAR and provisions the Python analyzer in a virtualenv. These pages document the backend layer for readers who want to understand or contribute to it.
 </Aside>
 
 This is the **backend** layer. For the SDKs that consume it, see the [SDKs overview](/reference/sdks/).
@@ -31,13 +31,13 @@ This is the **backend** layer. For the SDKs that consume it, see the [SDKs overv
 
 ## Backends (analyzers)
 
-The `codeanalyzer-*` tools that parse a language and serialize the canonical symbol-table and call-graph schema every frontend reads.
+The `codeanalyzer-*` tools parse a language and serialize the canonical symbol-table and call-graph schema that every frontend reads.
 
 | Language | Analyzer | Maturity |
 | --- | --- | --- |
 | **Java** | [codeanalyzer-java](/backends/codeanalyzer-java/) | <Badge text="Mature" variant="success" /> |
 | **Python** | [codeanalyzer-python](/backends/codeanalyzer-python/) | <Badge text="Mature" variant="success" /> |
-| **TypeScript** | [codeanalyzer-ts](/backends/codeanalyzer-ts/) | <Badge text="Medium" variant="tip" /> |
+| **TypeScript** | [codeanalyzer-ts](/backends/codeanalyzer-ts/) | <Badge text="Mature" variant="success" /> |
 | **JavaScript** | via [codeanalyzer-ts](/backends/codeanalyzer-ts/) | <Badge text="Medium" variant="tip" /> |
 | **Go** | Not started | <Badge text="Help wanted" variant="danger" /> <Badge text="Stub" variant="default" /> |
 | **Rust** | Not started | <Badge text="Help wanted" variant="danger" /> <Badge text="Stub" variant="default" /> |
@@ -48,8 +48,8 @@ The `codeanalyzer-*` tools that parse a language and serialize the canonical sym
 ## Built backends
 
 <CardGrid>
-  <LinkCard title="codeanalyzer-python" description="Jedi-based semantic analysis with optional CodeQL call-graph augmentation; ships the canonical Py* schema." href="/backends/codeanalyzer-python/" />
-  <LinkCard title="codeanalyzer-java" description="The deepest backend: WALA + Javaparser, producing symbol tables, call graphs, hierarchy, and CRUD analysis." href="/backends/codeanalyzer-java/" />
-  <LinkCard title="codeanalyzer-ts" description="The TypeScript analyzer: the backend exists today; Python SDK support is on the way." href="/backends/codeanalyzer-ts/" />
-  <LinkCard title="Add a backend" description="Help wanted. Go, Rust, C, C++, and C# are unbuilt. A backend that speaks the canonical JSON lights the language up across every SDK." href="/contributing/add-language-backend/" />
+  <LinkCard title="codeanalyzer-python" description="Jedi-based semantic analysis with optional CodeQL call-graph augmentation; emits the canonical Py* schema." href="/backends/codeanalyzer-python/" />
+  <LinkCard title="codeanalyzer-java" description="WALA and Javaparser; produces symbol tables, call graphs, type hierarchy, and CRUD analysis." href="/backends/codeanalyzer-java/" />
+  <LinkCard title="codeanalyzer-ts" description="Stable. The TypeScript/TSX analyzer, emitting the canonical symbol-table and call-graph schema." href="/backends/codeanalyzer-ts/" />
+  <LinkCard title="Add a backend" description="Help wanted. Go, Rust, C, C++, and C# are not yet built. A backend that emits the canonical JSON makes that language available to every SDK." href="/contributing/add-language-backend/" />
 </CardGrid>