Add language-agnostic StaticAnalysisAgent

.gitignore

@@ -68,3 +68,11 @@ Thumbs.db
 # LLM Cache
 .ollama_cache/
 *.cache
+
+# CodeQL: per-run databases and temporary query packs.
+# The framework writes/removes these at run time. Never commit them.
+codeql-db/
+codeql-db-aco/
+codeql-aco-results-*/
+codeql-queries-aco-*/
+.codeql-build.lock

CLAUDE.md

@@ -359,6 +359,21 @@ config = ConfigParser.get(OllamaConfig)
 
 ## Recent Changes
 
+### 2026-04-26: StaticAnalysisAgent (feature/static-analysis-agent)
+- ✅ New `agents/static_analyzer.py` — language-agnostic CodeQL agent
+- ✅ New `tools/codeql/` package: fingerprint + taxonomy + template renderer
+  + generic runner (Docker fallback to local CLI)
+- ✅ Per-language adapters for Java, C++, Python; 21 vetted query templates
+- ✅ Performance anti-pattern taxonomy with framework gates (e.g. DB queries
+  skipped automatically when no DB framework is detected)
+- ✅ Inserted as Phase 2 of `complete_pipeline.py` between summarization and
+  analysis; AnalyzerAgent prompt updated to consume `static_analysis_source`
+- ✅ See `docs/STATIC_ANALYSIS.md` for the full systematic workflow and
+  extension guide
+- ⚠️ `tools/codeql.py` (TeaStore-Java) and `tools/codeql_cpp.py`
+  (DeathStarBench-C++) remain as backwards-compat shims; summarizer agents
+  still import them. Removable once summarizers are migrated.
+
 ### 2025-01-22: Middleware Support
 - ✅ Added 7 built-in middleware from LangChain for enhanced agent capabilities
 - ✅ Configuration-driven middleware via `config.ini` [agents] section

README.md

@@ -15,7 +15,9 @@ PHASE 1: SUMMARIZATION (Parallel)
 └─ Component Summary Agent    → Structure, interfaces, dependencies
     ↓
 PHASE 2: STATIC ANALYSIS
-└─ CodeQL Analysis → Hotspots, patterns, architectural signals
+└─ Static Analysis Agent (NEW) → Language-agnostic CodeQL via taxonomy +
+   fingerprint. Replaces hardcoded TeaStore/DeathStarBench tools with a
+   pluggable framework: see `docs/STATIC_ANALYSIS.md`.
     ↓
 PHASE 3: ANALYSIS
 └─ Analyzer Agent → Identifies optimization opportunities

agents/__init__.py

@@ -3,6 +3,7 @@
 from .correctness import (AnalysisResult, CorrectnessVerdict,
                           orchestrate_code_correctness)
 from .optimizer import OptimizationReport, OptimizerAgent
+from .static_analyzer import StaticAnalysisAgent
 from .summarizers.behavior import BehaviorSummarizerAgent
 from .summarizers.component import ComponentSummarizerAgent
 from .summarizers.environment import EnvironmentSummarizerAgent

agents/analyzer.py

@@ -79,17 +79,32 @@ class AnalyzerAgent(BaseAgent):
 actionable optimization guidance for a downstream optimizer agent.
 
 Input is JSON with:
-- summary_source: path to summary text (includes static signals like call graphs, hotspots, dependencies)
+- summary_source: path to summary text (architecture / behaviour / environment)
+- static_analysis_source: path to a StaticAnalysisReport JSON produced by the
+  StaticAnalysisAgent. Contains `taxonomy_findings` (structural + anti-pattern
+  probes), `hypothesis_findings` (LLM-authored follow-up queries),
+  `coverage` (which categories actually ran vs were skipped, with reasons),
+  and `notes`. Treat skipped categories as "we did not look", not "absent".
 - root_path: repository root to use for analysis and snippet/search tools
 
 ## Analysis Approach
 IMPORTANT: First build a comprehensive analysis plan before executing any optimizations.
 
-1) Start by reading the summary report and identifying key components, architecture patterns, and system boundaries.
-2) Understand system context from the summaries (architecture, services, dependencies, infra), which include static signals.
-3) Review embedded static signals (coverage, hotspots, client usage, dependencies, database calls, call graph cues).
-4) Identify optimization opportunities with clear evidence and expected impact.
-5) Prioritize by impact and confidence; note assumptions and gaps.
+1) Read the summary report. Identify key components, architecture patterns,
+   and system boundaries.
+2) Read the static_analysis_source. Group findings by `category` and
+   `taxonomy_entry`. The structural backbone (services, endpoints, call_graph)
+   is what to anchor every priority to.
+3) Cross-reference summary signals with static analysis findings. A finding
+   in a class that the summary calls a "hot service" outranks one in a
+   utility module.
+4) Inspect coverage: any `skipped` entries with framework-gate reasons are
+   informative gaps — note them under `risks_and_gaps` if they could matter
+   (e.g. "DB analysis skipped: no JDBC dependency found").
+5) Identify optimization opportunities with clear evidence and expected
+   impact. Prefer priorities backed by both summary context AND a static
+   finding (or hypothesis_finding) — these are the highest-confidence picks.
+6) Prioritize by impact and confidence; note assumptions and gaps.
 
 ## Tool Usage Strategy
 - Call build_analysis_bundle(summary_source, max_items=12) to normalize the summaries.

agents/static_analyzer.py

@@ -0,0 +1,134 @@
+"""StaticAnalysisAgent — drives systematic, language-agnostic CodeQL analysis.
+
+This is the agent introduced in feature/static-analysis-agent. It replaces
+the benchmark-specific hardcoded tools (`teastore_component_analysis`,
+`teastore_behavior_analysis`, `deathstar_*`) with a generic two-stage
+workflow:
+
+  Stage 1 — Discovery + Taxonomy:
+    fingerprint_benchmark → list_taxonomy → run_taxonomy_pass
+
+  Stage 2 — Hypothesis (optional):
+    For findings worth investigating, render_taxonomy_query (to start
+    from a known-valid template) → adapt → author_custom_codeql_query.
+
+The agent's structured output is the same `StaticAnalysisReport` defined
+in `tools/codeql/report.py`; downstream agents (AnalyzerAgent) consume it.
+"""
+
+from __future__ import annotations
+
+from agents.base import BaseAgent
+from tools.codeql import (StaticAnalysisReport, author_custom_codeql_query,
+                           fingerprint_benchmark, list_taxonomy,
+                           render_taxonomy_query, run_taxonomy_pass)
+
+
+class StaticAnalysisAgent(BaseAgent):
+    """Language-agnostic CodeQL static-analysis agent.
+
+    Workflow (enforced via the prompt):
+      1. Fingerprint the repository.
+      2. Read the taxonomy and pick the categories worth running given
+         the fingerprint (skip rationally — record skips in the report).
+      3. Run the taxonomy pass.
+      4. Review findings; for at most a handful of high-value follow-ups,
+         render the relevant template, adapt it to a sharper hypothesis,
+         and run as a custom query.
+      5. Emit a `StaticAnalysisReport`.
+    """
+
+    prompt = """You are a static-analysis specialist. Your job is to produce a structured
+StaticAnalysisReport for a benchmark repository using CodeQL — systematically, not
+randomly.
+
+## Inputs
+You receive JSON: { "repo_path": "<absolute path>" }.
+
+## Workflow
+
+You MUST follow this order. Do not skip steps.
+
+### Stage 1 — Fingerprint and plan
+
+1. Call `fingerprint_benchmark(repo_path)`. The result tells you:
+   - which language(s) are present
+   - the per-language `package_filters` placeholder used by templates
+   - which frameworks are detected (e.g. jdbc, jackson, spring, sqlalchemy)
+   - notes about anything ambiguous (low-confidence package prefix, etc.)
+   If `languages` is empty, stop and emit a report whose `notes` explain
+   the failure.
+
+2. Call `list_taxonomy()` to read the catalogue. Decide which categories
+   to run:
+   - Always run `structural` entries — they anchor every other finding.
+   - For each `antipattern.*` entry, check its `framework_gates` against
+     the fingerprint's `frameworks`. If gates exist and none match, do
+     NOT add the category to your pass — let the runner skip it and
+     record the skip in coverage. (Don't fight the framework gates.)
+
+### Stage 2 — Taxonomy pass
+
+3. Call `run_taxonomy_pass(repo_path, only_categories=[...])`. Pass the
+   list of categories you decided to keep. The result is a
+   `StaticAnalysisReport` with `taxonomy_findings` and `coverage`.
+   - If a category errored (`status=error`), DO NOT retry blindly. Read
+     the error; if it's a build failure, surface it in the report's
+     `notes` and continue.
+   - If `taxonomy_findings` is empty for a language, mention that in the
+     final report's notes. It is information, not a failure.
+
+### Stage 3 — Hypothesis follow-ups (only if warranted)
+
+4. Look at `taxonomy_findings`. Pick AT MOST 2 follow-up hypotheses, each
+   of which should be:
+   - Anchored to existing findings (e.g. "many sync_methods on
+     `BaseRegistry` — are they actually contended via the call graph?").
+   - Answerable with a single targeted query.
+   For each, call `render_taxonomy_query(entry_id, language, repo_path)`
+   to start from a known-valid template, adapt the body, and run via
+   `author_custom_codeql_query(...)` with a unique `rule_id`. If the
+   custom query fails to compile (`compiled: false`), record the
+   failure and move on — DO NOT retry more than once.
+
+   You may skip Stage 3 entirely if the taxonomy pass already produced
+   sufficient evidence — over-querying is worse than under-querying.
+
+### Stage 4 — Emit the report
+
+5. Combine everything into a single `StaticAnalysisReport`:
+   - `benchmark`: from the fingerprint.
+   - `taxonomy_findings`: from `run_taxonomy_pass`.
+   - `hypothesis_findings`: from any custom queries you ran.
+   - `coverage`: from `run_taxonomy_pass` plus implicit (categories you
+     chose not to add).
+   - `custom_queries`: one record per `author_custom_codeql_query` call.
+   - `notes`: caveats — low-confidence fingerprint, runner errors,
+     skipped languages, anything the analyzer agent should know.
+
+## Constraints
+
+- You MUST call `fingerprint_benchmark` exactly once, first.
+- You MUST call `run_taxonomy_pass` at least once.
+- You MAY skip `author_custom_codeql_query` entirely — it is optional.
+- DO NOT fabricate findings. Every Finding in the output must come from
+  a tool call. If a tool returns no results, the report shows none.
+- DO NOT loop forever. After the taxonomy pass and at most two custom
+  queries, emit the report.
+
+## Output
+
+After the tool calls, respond with a single JSON object that conforms to
+the `StaticAnalysisReport` Pydantic schema. No prose before or after.
+"""
+
+    structured_output_type = StaticAnalysisReport
+    return_state_field = "static_analysis_report"
+
+    tools = [
+        fingerprint_benchmark,
+        list_taxonomy,
+        render_taxonomy_query,
+        run_taxonomy_pass,
+        author_custom_codeql_query,
+    ]

codeql-db/codeql-database.yml

@@ -0,0 +1,13 @@
+---
+sourceLocationPrefix: /Users/peng397/Desktop/agentic-code-optimization/TeaStore
+baselineLinesOfCode: 12317
+unicodeNewlines: false
+columnKind: utf16
+primaryLanguage: java
+creationMetadata:
+  sha: 34b37f7e7be433ce72d5f9455e66922a13116749
+  cliVersion: 2.23.9
+  creationTime: 2026-01-18T22:35:31.946849Z
+overlayBaseDatabase: false
+overlayDatabase: false
+finalised: true

codeql-db/db-java/default/cache/version

@@ -0,0 +1 @@
+20190805:20220702:20240828:20241116