graph-indexer 2.1.1 → 3.0.0

package/prompts/DOMAIN_TEMPLATE.md

@@ -1,46 +0,0 @@
-<domain_prompt layer="3" name="project-domain" requires="graph-indexer-core">
-
-    <!--
-        LAYER 3 — YOUR PROJECT'S RULES. Replace every [BRACKETED] placeholder with
-        facts about YOUR codebase and delete sections that don't apply. Keep it under
-        ~40 lines: this exists to make the agent's FIRST query hit rank-1, not to
-        restate your architecture docs. May ADD precision to Layers 1–2 but may NEVER
-        relax the 4-call budget, the prime directive, or the fallback protocol.
-        Tip: delete these comments once filled — they cost tokens every session.
-    -->
-
-    <project_identity>
-        <name>[PROJECT_NAME]</name>
-        <summary>[One sentence: what this system does and for whom.]</summary>
-    </project_identity>
-
-    <entry_points>
-        <!-- Where execution starts — saves the agent its first orientation call. -->
-        <entry path="[src/main.ts]" role="[application bootstrap]"/>
-        <entry path="[src/api/routes/]" role="[HTTP surface]"/>
-    </entry_points>
-
-    <domain_vocabulary>
-        <!-- Map business words to code words so search queries hit rank-1. -->
-        <term business="[invoice]" code="[BillingDocument]"/>
-        <term business="[customer]" code="[Account, AccountHolder]"/>
-    </domain_vocabulary>
-
-    <critical_paths>
-        <!-- Symbols where get_call_graph is MANDATORY before any change. -->
-        <symbol name="[processPayment]" reason="[money-moving path; callers in 3 services]"/>
-    </critical_paths>
-
-    <no_go_zones>
-        <!-- Code the agent should never explore or edit. -->
-        <zone path="[src/generated/]" reason="[generated — regenerate, never edit]"/>
-        <zone path="[legacy/]" reason="[frozen for deprecation]"/>
-    </no_go_zones>
-
-    <house_rules>
-        <!-- Project-specific conventions the agent must respect. -->
-        <rule>[Example: all new endpoints require a schema in src/schemas/.]</rule>
-        <rule>[Example: feature flags are checked via FlagService, never process.env.]</rule>
-    </house_rules>
-
-</domain_prompt>

package/prompts/INTEGRATION.md

@@ -1,123 +0,0 @@
-# Integrating the graph-indexer prompt suite
-
-The suite is a **3-layer architecture**. Each layer is a standalone XML block; you combine them by **concatenation, in layer order**. Never merge layers into one hand-edited blob ("god prompt") — that is what causes context dilution and framework hallucinations.
-
-```
-prompts/
-├── CORE.md                          Layer 1 — universal rules (always required)
-├── languages/                       Layer 2 — pick the ones matching your code
-│   ├── JAVASCRIPT_TYPESCRIPT.md
-│   ├── PYTHON.md
-│   ├── GO.md
-│   ├── RUST.md
-│   ├── JAVA.md
-│   ├── KOTLIN.md
-│   ├── CSHARP.md
-│   ├── RUBY.md
-│   ├── PHP.md
-│   ├── CSS_SCSS.md
-│   ├── BASH.md
-│   ├── C.md
-│   └── SWIFT.md
-├── frameworks/                      Layer 2 — pick the ones matching your stack
-│   ├── REACT.md
-│   ├── NODE_EXPRESS_NESTJS.md
-│   ├── FASTAPI_DJANGO.md
-│   ├── SPRING_BOOT.md
-│   ├── RAILS.md
-│   ├── LARAVEL_SYMFONY.md
-│   ├── ASPNET_CORE.md
-│   └── ANDROID.md
-└── DOMAIN_TEMPLATE.md               Layer 3 — copy, then fill with YOUR project's rules
-```
-
-## The assembly rule
-
-```
-Layer 1 (CORE)  →  Layer 2 (language)  →  Layer 2 (framework)  →  Layer 3 (domain)
-```
-
-1. **Order matters.** Core first, then language, then framework, then domain. Frameworks assume their base language layer is already loaded (`requires=` attribute in each file).
-2. **Precedence on conflict:** a more specific layer *refines* a more general one (e.g. REACT's render-site protocol refines the core call-graph rule). But Layer 1's `<hard_limits>`, `<prime_directive>`, and `<fallback_protocol>` are **inviolable** — no lower layer may relax them.
-3. **Only include layers you need.** A Go microservice needs `CORE + GO` — nothing else. Every unused layer dilutes the agent's attention.
-
-## Automatic setup (recommended)
-
-```bash
-npx graph-indexer init
-```
-
-`init` asks for your languages and frameworks, then lets you **multi-select which agents/IDEs to wire** (Claude Code/Desktop, Cursor, VS Code/Copilot, Windsurf, Cline/Roo, JetBrains Junie, Codex/AGENTS.md, Gemini CLI). The choice is pre-checked from what's detected (or your last run) and remembered in `.graph-indexer/config.json`, so only the agents you pick get files — the two `GRAPH_INDEXER_*.md` source files are always written. For each selected agent it generates:
-
-| File | Agent | Ownership |
-| :--- | :--- | :--- |
-| `GRAPH_INDEXER_PROMPT.md` | source of truth (Layers 1 + 2, assembled for your selection) | Generated — re-run `init` to regenerate; do not edit |
-| `GRAPH_INDEXER_DOMAIN.md` | source of truth (Layer 3 template) | **Yours** — fill it in; `init` never overwrites it |
-| `CLAUDE.md` | Claude Code (`@`-import lines) | Appended once, idempotent |
-| `.cursor/rules/graph-indexer.mdc` | Cursor (always-on rule) | Generated — regenerated on re-run |
-| `.windsurf/rules/graph-indexer.md` | Windsurf (always-on rule) | Generated — regenerated on re-run |
-| `.clinerules/graph-indexer.md` | Cline / Roo Code (rule) | Generated — regenerated on re-run |
-| `.github/copilot-instructions.md` | GitHub Copilot (managed block) | Shared — your text outside the markers is preserved |
-| `.junie/guidelines.md` | JetBrains Junie (managed block) | Shared — your text outside the markers is preserved |
-| `AGENTS.md` | AGENTS.md standard: Codex, Zed, Jules, … (managed block) | Shared — your text outside the markers is preserved |
-| `GEMINI.md` | Gemini CLI (`@`-import) | Shared — references the canonical files (no duplication); your text outside the markers is preserved |
-
-**Why some files reference and others embed.** `CLAUDE.md` and `GEMINI.md` use `@`-import (Claude Code imports, Gemini CLI's Memory Import Processor), so they just point at the canonical `GRAPH_INDEXER_*.md` — zero duplication. The Cursor/Windsurf/Cline rule files hold the assembled prompt verbatim, and the Copilot/Junie/AGENTS.md managed blocks embed it inline, because those tools read the file **literally** — they have no reliable import mechanism, so an `@`-reference would appear as plain text and the rules would silently not apply. (AGENTS.md embeds because its main reader, OpenAI Codex, does not yet honour `@` imports.) Embedded blocks are wrapped in `<!-- >>> graph-indexer >>> -->` … `<!-- <<< graph-indexer <<< -->` markers, so your own instructions around them survive re-runs.
-
-## Manual setup
-
-`init` already wires Claude Code, Cursor, Windsurf, Cline/Roo, Copilot, Junie, the AGENTS.md ecosystem, and Gemini (see the table above). Reach for the steps below only for a legacy format (`.cursorrules`, `.clauderc`), a raw-system-prompt config, or an agent not in that list.
-
-### Claude Code (`CLAUDE.md` or `.clauderc`)
-
-Claude Code loads `CLAUDE.md` from the project root and supports `@path` imports — reference the assembled files instead of pasting them:
-
-```markdown
-# CLAUDE.md
-@GRAPH_INDEXER_PROMPT.md
-@GRAPH_INDEXER_DOMAIN.md
-```
-
-If your tooling uses a `.clauderc` (or any agent config that takes a raw system prompt), paste the concatenated layers directly, in layer order.
-
-### Cursor (`.cursorrules` or `.cursor/rules/`)
-
-For the legacy single-file format, concatenate the layers into `.cursorrules`:
-
-```bash
-cat node_modules/graph-indexer/prompts/CORE.md \
-    node_modules/graph-indexer/prompts/languages/JAVASCRIPT_TYPESCRIPT.md \
-    node_modules/graph-indexer/prompts/frameworks/REACT.md \
-    GRAPH_INDEXER_DOMAIN.md > .cursorrules
-```
-
-For the modern format, put the same concatenation in `.cursor/rules/graph-indexer.mdc` with this frontmatter:
-
-```yaml
----
-description: graph-indexer usage rules
-alwaysApply: true
----
-```
-
-### Any other agent
-
-Concatenate the layers (in order) into whatever field your agent calls "system prompt", "rules", or "custom instructions". The XML structure is self-describing — no other formatting is required.
-
-## Worked examples
-
-| Stack | Assembly |
-| :--- | :--- |
-| React SPA | `CORE + languages/JAVASCRIPT_TYPESCRIPT + languages/CSS_SCSS + frameworks/REACT + domain` |
-| NestJS API + React front-end (monorepo) | `CORE + languages/JAVASCRIPT_TYPESCRIPT + frameworks/NODE_EXPRESS_NESTJS + frameworks/REACT + domain` |
-| Django service | `CORE + languages/PYTHON + frameworks/FASTAPI_DJANGO + domain` |
-| Spring Boot backend (Java or Kotlin) | `CORE + languages/JAVA` (or `KOTLIN`) `+ frameworks/SPRING_BOOT + domain` |
-| Rails app | `CORE + languages/RUBY + frameworks/RAILS + domain` |
-| Laravel / Symfony app | `CORE + languages/PHP + frameworks/LARAVEL_SYMFONY + domain` |
-| ASP.NET Core API | `CORE + languages/CSHARP + frameworks/ASPNET_CORE + domain` |
-| Android app | `CORE + languages/KOTLIN + frameworks/ANDROID + domain` |
-| Go / Rust service | `CORE + languages/GO` (or `RUST`) `+ domain` |
-
-## Layer 3 — make it yours
-
-Copy `DOMAIN_TEMPLATE.md` (or let `init` create `GRAPH_INDEXER_DOMAIN.md`), then fill in entry points, domain vocabulary, critical paths, and no-go zones. Keep it under ~40 lines: Layer 3 exists to make the agent's *first* query hit rank-1, not to restate your architecture docs.

package/prompts/frameworks/ANDROID.md

@@ -1,17 +0,0 @@
-<environment_prompt layer="2" type="framework" name="android" requires="graph-indexer-core, kotlin" version="1.0">
-
-    <scope>Android (Jetpack, Compose or XML views, coroutines). Loads after the kotlin layer.</scope>
-
-    <critical_fact>Activities, Fragments, Services, ViewModels, BroadcastReceivers are instantiated and driven by the OS: lifecycle methods (onCreate, onResume, onCleared...) have NO inbound edges — empty call graphs mean FRAMEWORK-INVOKED, never dead. Who launches a screen lives in navigation graphs, manifest entries, and intent construction — ONE exact_tokens search on the screen/class name finds the launchers.</critical_fact>
-
-    <rules>
-        <rule name="compose-vs-xml">Composables are ordinary Kotlin functions: get_call_graph("OrderScreen") DOES find composition sites — the graph works for Compose UI, unlike JSX. What it can't see is RECOMPOSITION: state-driven re-execution is runtime — answer "when does this re-render" from the composable's chunk (its state reads), never the graph. XML layouts, nav graphs, manifest are non-code resources (fallback condition 3); the code↔layout link is the resource NAME — search R.layout.x-style identifiers or the binding class name.</rule>
-        <rule name="generated-artifacts">R, BuildConfig, ViewBinding/DataBinding classes, generated DAO impls have NO chunks — the annotated interface or XML they were generated FROM is the answer; never hunt for generated bodies.</rule>
-        <rule name="di-annotations">Hilt/Dagger injection is annotation-driven (@Inject, @Provides, @Module, @HiltViewModel): the container builds the graph, so injection sites carry no caller edges. ONE exact_tokens search on the injected TYPE finds its module/provider and its consumers together.</rule>
-        <rule name="coroutines-and-state">viewModelScope.launch and Flow pipelines decouple call sites from execution (kotlin layer). UI state connects ViewModel → UI by the STATE property name — ONE search of that name finds emitter and collectors together. Click listeners and observers are lambdas with no symbols — find them behaviourally inside the owning screen's chunk.</rule>
-        <rule name="query-style">Screen names, state property names, resource identifiers, DI types are the highest-precision tokens. Intent actions and navigation route strings trace inter-screen flow better than any graph.</rule>
-    </rules>
-
-    <playbook question="explain screen X" calls="2-4">resolve_symbol("XViewModel" or "XScreen") → get_chunk(the one whose logic is in question — ViewModel for behaviour, composable for UI) → ONE exact_tokens search for the launcher or the state property → answer.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/ASPNET_CORE.md

@@ -1,19 +0,0 @@
-<environment_prompt layer="2" type="framework" name="aspnet-core" requires="graph-indexer-core, csharp" version="1.0">
-
-    <scope>ASP.NET Core (attribute routing or minimal APIs, built-in DI, EF Core data access). Loads after the csharp layer.</scope>
-
-    <critical_fact>Controller actions and endpoint handlers are invoked by the routing middleware: empty call graphs on them mean ENTRY POINT, never dead code.</critical_fact>
-
-    <rules>
-        <rule name="routes">Attribute-routed: full route = class-level [Route("api/[controller]")] PLUS method-level [HttpGet("{id}")] — both on cards; find endpoints by path fragment (exact_tokens: "/orders") or verb attribute. Minimal APIs: handlers are lambdas at the `app.MapGet(...)` registration — the registration chunk IS the handler, and they live in the Program/startup chunk.</rule>
-        <rule name="registration-is-the-binding">DI wiring is explicit code: `services.AddScoped<IOrderService, OrderService>()` in Program/Startup or extension methods. ONE exact_tokens search on the INTERFACE name surfaces the registration line and the implementing class together.</rule>
-        <rule name="graph-works-below-routing">Below routing, calls are direct: controller → service → repository edges register normally — trust get_call_graph inside project code.</rule>
-        <rule name="implicit-runners">Middleware (app.UseX / InvokeAsync), filters, hosted services (ExecuteAsync), health checks are framework-invoked — the registration site names them; never hunt for callers of InvokeAsync/ExecuteAsync.</rule>
-        <rule name="ef-data-layer">LINQ queries translate to SQL at runtime — no generated code to find. The DbContext declares the sets; entity config lives in attributes or model-builder chunks. Migration files are tool-generated snapshots — skip unless schema history is the question.</rule>
-        <rule name="config-and-messages">IOptions<T>/Configuration["Key"] bind to appsettings.json — fallback condition 3 once the consumer is located; find consumers by the options class or key string. MediatR-style buses connect sender and handler by MESSAGE TYPE — ONE exact_tokens search on the message class finds both ends.</rule>
-        <rule name="query-style">Route fragments, interface names, options/message class names are the highest-precision tokens. Cross-cutting behaviour ("where do we log request IDs") lives in middleware you can't name — search behaviourally.</rule>
-    </rules>
-
-    <playbook question="what happens on POST /orders" calls="3-4">search_code(exact_tokens: "/orders") → get_chunk_summary(controller action or Map* registration, expand_calls: true) → get_chunk_summary(the ONE service method doing the work) → answer; ONE DI-registration or middleware hop only if the question demands it.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/FASTAPI_DJANGO.md

@@ -1,20 +0,0 @@
-<environment_prompt layer="2" type="framework" name="fastapi-django" requires="graph-indexer-core, python" version="1.0">
-
-    <scope>Python web app: decorator-routed endpoints (FastAPI) and/or URLconf + ORM (Django). Loads after the python layer.</scope>
-
-    <critical_fact>Endpoints and views are invoked by the framework dispatcher: an empty call graph on them means ENTRY POINT, never dead code.</critical_fact>
-
-    <rules>
-        <rule name="routes">FastAPI/Flask decorator endpoints: find_routes(method, path) maps them straight to the handler chunk_id — the first move. Fall back to a path search — search_code(query: "endpoint that updates user profile", exact_tokens: "/users") — for computed paths or behavioural matching. Django URLconf is NOT covered by find_routes: views bind in a urls file, so search the path string then resolve the referenced view name — that is 2 calls, plan for it.</rule>
-        <rule name="depends-is-a-default">FastAPI dependencies are parameter DEFAULTS (`user = Depends(get_current_user)`), not calls — no edge. The endpoint's SIGNATURE enumerates its dependencies (summary is enough); resolve at most ONE dependency body.</rule>
-        <rule name="metaclass-managers">ORM model classes are rewritten by metaclasses: `Model.objects`, queryset methods, generated fields (id, *_set) have NO chunks — resolve_symbol("objects") finding nothing is CORRECT. The MODEL class declares the schema; custom managers/querysets DO exist as classes — search the manager class name when query behaviour looks non-default.</rule>
-        <rule name="cbv-mro">Class-based views inherit handlers through mixins/generic bases: the view chunk often shows only attributes. The method you seek (get, post, get_queryset, form_valid) lives on a parent — resolve ONE parent method, guided by the bases in the view's signature.</rule>
-        <rule name="schema-models">Pydantic models, serializers, forms are declarative — the class definition IS the validation. resolve_symbol("UserCreate") answers "what is validated"; imperative validation code doesn't exist, don't search for it.</rule>
-        <rule name="signals-and-tasks">Signals connect by the signal OBJECT and tasks by name/registration — no call edges. ONE exact_tokens search on the signal/task name finds both ends. Middleware lists and settings are config files — fallback condition 3 once the consuming code is located.</rule>
-        <rule name="query-style">URL fragments and signal names beat function names. For "where is this field validated/transformed", name the FIELD and behaviour ("normalize email before saving user") — model, serializer, or signal handler, one behavioural search covers all three.</rule>
-        <rule name="request-input-to-sink">SECURITY ("can user input reach SQL/RCE/template here"): find_tainted_sinks(category) to map the surface, then trace_taint one — request.json/POST/GET + path/query params → raw()/extra()/.execute() (sqli), os.system/subprocess (rce), template/HTML (xss). Finder, not proof: "no flows" ≠ safe.</rule>
-    </rules>
-
-    <playbook question="what happens on POST /orders" calls="3-4">find_routes("POST", "/orders") (FastAPI/Flask; for Django URLconf fall back to search_code(exact_tokens: "/orders")) → get_chunk(handler/view) — decorators + signature reveal deps and models → resolve_symbol(the ONE model/service it delegates to) → answer; ONE dependency/parent hop only if the question demands it.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/LARAVEL_SYMFONY.md

@@ -1,22 +0,0 @@
-<environment_prompt layer="2" type="framework" name="laravel-symfony" requires="graph-indexer-core, php" version="1.0">
-
-    <scope>PHP on Laravel or Symfony (container MVC, ORM, facades/attributes). Loads after the php layer — whole-class chunks, weak topology, batched class questions all apply.</scope>
-
-    <critical_fact>Controllers are invoked by the framework dispatcher: empty call graphs on controller methods mean ENTRY POINT. And because PHP `use` imports are untracked, EMPTY Deps:/Used by: mean NOTHING — usage always comes from name search, never from topology absence.</critical_fact>
-
-    <rules>
-        <rule name="eloquent-magic">Active-record models route everything through magic methods: attributes are __get/__set on the row, `User::where(...)` is __callStatic, scopes are scopeActive defs invoked as active(), relations (hasMany/belongsTo) generate accessors. The MODEL chunk's relation/scope/cast declarations ARE the API — and model chunks are SMALL, so one batched search shows several models' full relation graphs at once. Never hunt for generated method bodies.</rule>
-        <rule name="routes">Laravel routes are DSL calls in route files (`Route::get('/orders', [OrderController::class, 'index'])`) — ONE exact_tokens search of the URL fragment finds the registration; the controller class is named right there. Symfony routes are attributes on the controller method (#[Route('/orders')]) — the class chunk includes them; search the path fragment.</rule>
-        <rule name="big-controllers">A large controller (≥~200 lines) is god-class-split, so each action is its own chunk and resolve_symbol on an action name hits directly; a smaller controller stays one whole-class chunk. Either way, get_file_skeleton(its file) lists every action with line ranges in ~80 tok — THE move instead of searching method names one by one (the skeleton call replaces 3-4 searches).</rule>
-        <rule name="facades">Facade calls (Cache::get, DB::table, Log::info) are static proxies — NO edge to the implementation behind the container binding. Treat as "delegates to the named service"; resolve the underlying service ONLY when its internals are the question.</rule>
-        <rule name="container-bindings">Interface→implementation wiring lives in service providers (bind/singleton) or services config — ONE exact_tokens search on the INTERFACE name surfaces binding site and implementation together.</rule>
-        <rule name="implicit-runners">Middleware, policies, form requests, events/listeners, subscribers run implicitly around controllers. Registrations (kernel/provider/route/attributes) name them; events connect dispatch site to listeners by the EVENT CLASS NAME — ONE exact_tokens search finds both ends. Read at most ONE such body.</rule>
-        <rule name="templates">Blade/Twig templates are content, not symbols: the controller chunk's view(...)/render(...) call names the template; reading the template file is fallback condition 3.</rule>
-        <rule name="symfony-test-noise">In Symfony projects, callable-object patterns in DI can cause test-class methods (from capitalized `Tests/` directories) to escape the test filter and appear as indexed symbols. If search results include unexpected `Tests\` namespace entries, treat them as index noise and filter by file path.</rule>
-        <rule name="query-style">URL fragments, event class names, config keys are the highest-precision tokens. exact_tokens on a class name REPLACES the missing Used by: — the default usage-mapping move here.</rule>
-    </rules>
-
-    <playbook question="explain models Country, Community, Region, Location — structure, relations, where used" calls="1-2">ONE search_code(query: "Country Community Region Location", detail: "smart", top_k: 10): the four model chunks rank top with their hasMany/belongsTo/HasManyThrough lines visible — that IS the hierarchy — and the controllers/Livewire components referencing them appear in the same results. Answer structure AND usage from this single call; optional 2nd call: detail: "full" + token_budget: 3000 to quote every relation method. Four resolve_symbol calls here = budget dead.</playbook>
-    <playbook question="what happens on POST /orders" calls="3-4">search_code(exact_tokens: "/orders") → get_file_skeleton(controller file) or get_chunk_summary(controller class) for the action map → get_chunk_summary(the ONE model/service it delegates to) → answer; ONE middleware/listener/binding hop only if the question demands it.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/NODE_EXPRESS_NESTJS.md

@@ -1,19 +0,0 @@
-<environment_prompt layer="2" type="framework" name="node-express-nestjs" requires="graph-indexer-core, javascript-typescript" version="1.0">
-
-    <scope>Node.js backend: Express-style routing and/or NestJS-style DI. Loads after the javascript-typescript layer.</scope>
-
-    <critical_fact>HTTP handlers are invoked by the framework dispatcher: an empty call graph on a route handler means ENTRY POINT, never dead code. Request flow is reconstructed from REGISTRATION sites, not from get_call_graph.</critical_fact>
-
-    <rules>
-        <rule name="routes">find_routes(method, path) maps Express/Koa and NestJS endpoints straight to their handler chunk_id — THE first move for "what handles VERB /path", and it already joins the NestJS @Controller prefix onto the @Get path. Fall back to a PATH-STRING search — search_code(query: "user creation endpoint", exact_tokens: "/users") — only for dynamic/computed paths or behavioural matching. Express handlers are often anonymous closures in `app.get(path, ...)` — find_routes reports the registration line.</rule>
-        <rule name="middleware-order">Middleware order = REGISTRATION order. "What runs before this handler" comes from the ONE app/module setup chunk where registration happens — never by resolving every middleware. `next()` carries no edge; guards/pipes/interceptors bound via decorators are visible in summaries — read AT MOST ONE middleware body, only when its logic is the question.</rule>
-        <rule name="graph-works-below-routing">Inside project code calls are direct: controller → service → repository edges register normally, and get_call_graph("createUser") reliably finds controller call sites. Trust the graph below the routing layer.</rule>
-        <rule name="container-wiring">WHICH implementation backs an injected token is container wiring, not a call: constructor injection creates no edge. Find the binding with ONE search of the module/provider registration (exact_tokens: "UserService") — never via the constructor's call graph.</rule>
-        <rule name="lifecycle-hooks">onModuleInit-style hooks, error handlers, scheduled/cron methods, event/queue consumers have no inbound edges — the decorator in the summary says WHO invokes them; don't hunt for callers.</rule>
-        <rule name="query-style">Path strings beat handler names (routes rename rarely, handlers often). Cross-cutting behaviour ("where do we attach the request ID") lives in middleware whose name you can't guess — search behaviourally.</rule>
-        <rule name="request-taint">SECURITY: req.body/query/params is the untrusted source. "Is this endpoint injectable" → find_tainted_sinks(category) to map the surface, then trace_taint one source→sink path (sqli|rce|xss|path|ssrf). Finder, not proof — "no flows" ≠ safe.</rule>
-    </rules>
-
-    <playbook question="what happens on POST /orders" calls="3-4">find_routes("POST", "/orders") → get_chunk(handler chunk_id) → get_chunk_summary(the service it calls, expand_calls: true) → answer; ONE middleware/guard chunk only if the question is about it.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/RAILS.md

@@ -1,20 +0,0 @@
-<environment_prompt layer="2" type="framework" name="rails" requires="graph-indexer-core, ruby" version="1.0">
-
-    <scope>Ruby on Rails (convention-over-configuration MVC, ActiveRecord). Loads after the ruby layer — weak require topology applies.</scope>
-
-    <critical_fact>Rails wires almost everything BY NAMING CONVENTION, not by calls: router → controller action, controller → view template, model ↔ table. Most "who calls this" questions are answered by the convention itself — spend budget confirming the convention's endpoints, never searching for explicit wiring that doesn't exist.</critical_fact>
-
-    <rules>
-        <rule name="routes">Routes are DSL calls in config/routes.rb (`resources :orders`): search the URL fragment or resource name; the controller is `<Resource>sController`, the action the conventional method (index, show, create...). Controller actions are framework-invoked ENTRY POINTS — empty call graphs are normal. The rendered view matches the action name unless a render/redirect_to in the chunk overrides it.</rule>
-        <rule name="generated-methods">Associations/macros GENERATE the API at runtime: `has_many :orders` creates orders/build_order/...; attr/enum/scope macros likewise; dynamic finders (find_by_email) are metaprogrammed. NONE have chunks — the macro line in the model chunk IS the definition. Decode macros; never hunt for generated bodies.</rule>
-        <rule name="declarative-callbacks">`before_save :normalize`, `validates :email` are DECLARATIVE: the model chunk's macro lines say WHAT runs and WHEN. before_action filter chains are declared at the top of the controller chunk. Resolve at most the ONE callback/filter method whose logic is the question.</rule>
-        <rule name="concerns">Behaviour mixed in via `include SomeConcern` lives in the concern's module chunk (app/models/concerns, app/controllers/concerns) — ruby mixin rule applies, ONE module hop max.</rule>
-        <rule name="jobs-mailers">Jobs (perform_later), mailers (deliver_later), subscribers connect enqueue site to handler by CLASS NAME — ONE exact_tokens search on the class name finds both ends.</rule>
-        <rule name="non-code-config">config/*.yml, locales, credentials, db/schema.rb are data/config — fallback condition 3 once the consuming code is located.</rule>
-        <rule name="query-style">URL fragments, route helper names (order_path), macro symbols (:before_save, :orders) are the highest-precision tokens. For "where does X get validated/transformed", name the FIELD and behaviour — validation macro, callback, or form object, one behavioural search covers all.</rule>
-    </rules>
-
-    <playbook question="explain models A, B, C (and where used)" calls="1-2">ONE batched search — the macro lines (has_many, validates, scope) in the smart bodies ARE the schema and behaviour; consumers (controllers, jobs) surface in the same results because require topology is absent. Never one call per model.</playbook>
-    <playbook question="what happens on POST /orders" calls="3-4">search_code(exact_tokens: "orders") → get_chunk(OrdersController create action or class) → get_chunk_summary(Order model — macros reveal callbacks/validations) → answer; ONE callback/concern/job hop only if the question demands it.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/REACT.md

@@ -1,20 +0,0 @@
-<environment_prompt layer="2" type="framework" name="react" requires="graph-indexer-core, javascript-typescript" version="1.0">
-
-    <scope>React (JSX/TSX components, hooks). Loads after the javascript-typescript layer.</scope>
-
-    <critical_fact>JSX tags are NOT call expressions: `<MyComponent />` is a JSXElement, so get_call_graph("MyComponent") NEVER lists render sites and an empty call graph NEVER means a component is unused. Render sites come from `Used by:` (import topology — reliable in JS/TS) or ONE exact_tokens search on the component name.</critical_fact>
-
-    <rules>
-        <rule name="hooks-are-calls">Hook invocations ARE ordinary calls: get_call_graph("useAuth") reliably lists every component using that hook — the graph is trustworthy for hooks even though blind to JSX. A custom hook's contract is its return value — summary + Calls: line usually answers "what does it do" without the body.</rule>
-        <rule name="runtime-flow-invisible">State setter → re-render → effect firing is a runtime property no index sees. Answer ordering/timing from ONE get_chunk of the component, reasoning over hook semantics — never search for the render loop.</rule>
-        <rule name="wrappers">memo(...), forwardRef(...), HOCs export the WRAPPER. Resolution landing on a one-line wrapped export → the implementation is in the same file: get_file_skeleton(that file), not a new repo-wide search.</rule>
-        <rule name="context">Provider and consumers link through the Context OBJECT, not calls: ONE exact_tokens search on the context name ("ThemeContext") returns creation, Provider JSX, and consumers together.</rule>
-        <rule name="render-props">Logic injected via children/render props lives at the CALL SITE. If a component's body looks "empty", check ONE consumer to see what it injects.</rule>
-        <rule name="query-style">Component names are PascalCase and unique — exact_tokens with the component name is the highest-precision query here. For visual/behavioural questions ("the dropdown that closes on outside click"), use a behavioural sentence — handler names vary too much.</rule>
-    </rules>
-
-    <playbook question="explain component X and where it renders" calls="2-3">resolve_symbol("X") → get_chunk(id) — a component's body IS its behaviour (hooks + JSX), so the full chunk replaces two summary calls → answer citing Used by: as the render sites; ≤1 consumer chunk as a render example. Do NOT resolve every child component in its JSX. BEFORE a prop/signature change use explain_symbol("X") instead — render sites (Used by:), tests, and git recency in ONE call, since get_call_graph is blind to JSX.</playbook>
-
-    <playbook question="explain component X and its full ecosystem / what it's built from" calls="2-3">The child components X renders are IMPORTS, not calls — get_call_graph AND get_subgraph are BLIND to them (both walk the call graph, returning X's hooks/util calls, never its JSX children). The composition tree is the Deps: line on the resolve_symbol/get_chunk card (depth-1); render sites are Used by:. (1) resolve_symbol("X") → read Deps: for the direct child components. (2) For the FULL ecosystem / "what it's built from", the depth-2 grandchild is REQUIRED, not optional: resolve_symbol the PRINCIPAL child to read ITS Deps: — e.g. Modal's Deps: lists Fade; resolving Fade surfaces TransitionWrapper, which is NOT on Modal's card. A depth-1-only answer (Modal's children, stop) is INCOMPLETE for this question. Rule-of-one: hop into only the principal child; list the rest of X's children straight from its Deps:. NEVER get_subgraph to enumerate composition — it returns animation/hook plumbing, not the component tree.</playbook>
-
-</environment_prompt>

package/prompts/frameworks/SPRING_BOOT.md

@@ -1,20 +0,0 @@
-<environment_prompt layer="2" type="framework" name="spring-boot" requires="graph-indexer-core, java" version="1.0">
-
-    <scope>Spring / Spring Boot (annotation-driven config, container beans, AOP). Loads after the java (or kotlin) layer.</scope>
-
-    <critical_fact>ANNOTATIONS ARE BEHAVIOUR: @Transactional, @Cacheable, @Async, @Retryable, security annotations, and custom aspects wrap methods invisibly — bodies never show the transaction/cache/retry logic. Read the annotations in the summary BEFORE describing a method; never claim "no caching/transaction handling" from bodies alone.</critical_fact>
-
-    <rules>
-        <rule name="entry-points">Controller methods are dispatcher-invoked: empty call graphs on @RestController/@Controller methods mean ENTRY POINT. Full route = class-level prefix + method-level path. find_routes(method, path) resolves @GetMapping/@RequestMapping endpoints to the handler chunk_id with both parts joined — but ONLY for **Java** controllers; route extraction has no Kotlin branch, so on a **Kotlin** Spring app find_routes returns nothing and you must locate the handler with an `exact_tokens` search on the path fragment or annotation. For Java, use find_routes first and fall back to the exact_tokens path-fragment search only when it misses. Scheduled methods, listeners, queue consumers, lifecycle callbacks: the invoking annotation says WHO calls them — never hunt for callers.</rule>
-        <rule name="derived-queries">Repository interfaces generate query impls FROM METHOD NAMES: `findByEmailAndStatusOrderByCreatedAt` has NO body and NO chunk — the name IS the spec. Decode it; check for a @Query annotation in the summary when the name can't explain the result. Never search for the implementation.</rule>
-        <rule name="graph-works-below-wiring">Between project classes calls register normally: get_call_graph("calculateInvoice") reliably finds service-layer call sites. Trust the graph below the container wiring.</rule>
-        <rule name="interface-to-impl">Injection targets are interfaces; the container picks the impl. ONE exact_tokens search on the interface name surfaces the implementing class AND any @Bean factory — the binding is in one of those two.</rule>
-        <rule name="deep-inheritance">If a resolved class looks too thin, the behaviour lives in an abstract base — resolve ONE parent, guided by the extends list on the card.</rule>
-        <rule name="events-and-config">Event publishers and @EventListener handlers connect by the EVENT CLASS — ONE exact_tokens search on the event class finds both ends. @Value/configuration-properties bind to yml/properties — fallback condition 3 once the consuming class is located.</rule>
-        <rule name="query-style">Annotation names are high-precision tokens (exact_tokens: "@Scheduled"). Cross-cutting behaviour ("where do we audit changes") lives in an aspect/listener you can't name — search behaviourally.</rule>
-        <rule name="request-input-taint">SECURITY: controller request data (@RequestBody/@RequestParam/@PathVariable) is the untrusted source. For "can request input reach SQL/exec/path" use find_tainted_sinks(category) then trace_taint — Java-supported. Finder, not proof: "no flows" ≠ safe.</rule>
-    </rules>
-
-    <playbook question="what happens on POST /orders" calls="3-4">find_routes("POST", "/orders") → get_chunk_summary(handler chunk_id, expand_calls: true) — annotations + called services in one shot → get_chunk_summary(the ONE service method doing the work) → answer; ONE impl/parent/aspect hop only if the question demands it.</playbook>
-
-</environment_prompt>

package/prompts/languages/BASH.md

@@ -1,22 +0,0 @@
-<environment_prompt layer="2" type="language" name="bash" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is Bash/shell (.sh .bash). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact priority="critical">ONLY FUNCTIONS ARE CHUNKED. Top-level command sequences (script glue) have NO chunk — a script that runs purely at top level with no functions is INVISIBLE to search_code. Use get_file_skeleton(path) to read its structure; never conclude "nothing here" from an empty search.</fact>
-        <fact>`source x` / `. x` ARE tracked, so Deps:/Used by: reflect sourced libraries (relative paths resolve). A function you can't find in the current file is often DEFINED in a sourced lib — follow Deps:.</fact>
-        <fact>Every command is a potential call edge. Builtins and ubiquitous coreutils (echo, cd, grep, sed, awk, find…) are filtered; project functions and notable external tools (docker, git, npm, kubectl…) are kept as callees.</fact>
-        <fact>find_references returns caller signal only (no type annotations, no inheritance in shell). Call it only to find who calls a specific function; for non-call usage search, use exact_tokens instead.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="external-vs-internal">get_call_graph mixes calls to YOUR functions with invocations of external programs. A callee that doesn't resolve to an indexed function is an external command (a tool, not your code) — expected, never "dead code".</rule>
-        <rule name="names-are-global">No objects/namespaces and all calls are unqualified (empty receiver). Within a script + its sourced libs, function names are globally unique, so get_call_graph("deploy_app") is RELIABLE for your own functions — the OO-language precision worry doesn't apply.</rule>
-        <rule name="dynamic-invocation">`eval "$cmd"`, indirect expansion (`${!var}`), calling a function held in a variable (`"$handler" "$@"`), and `trap '…' EXIT` record NO usable edge. Find these by searching the function NAME as a string — it appears in the dispatch expression.</rule>
-        <rule name="subshells-and-pipes">Functions inside `$(...)`, pipes, and `&` jobs still record command calls, but variable side effects don't escape the subshell — answer state/ordering questions from the function's own body, not the graph.</rule>
-        <rule name="query-style">Function names are snake_case/kebab-case and split well; pin exact names with exact_tokens. To find an entrypoint, search the usage/help text or option-flag strings (`--force`, `usage:`) — far more unique than "main".</rule>
-    </rules>
-
-    <playbook question="explain what script X does" calls="1-3">get_file_skeleton(path) for the top-level flow → resolve_symbol("the_function") → get_chunk_summary(id, expand_calls: true). Follow at most ONE Deps: hop into a sourced lib for a function defined there.</playbook>
-
-</environment_prompt>

package/prompts/languages/C.md

@@ -1,21 +0,0 @@
-<environment_prompt layer="2" type="language" name="c" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is C (.c sources, .h headers). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: function definitions, named struct/union/enum specifiers, typedefs (incl. function-pointer typedefs), function-like macros (#define F(x) …). Bare prototypes (`int f(void);`) and object macros (`#define MAX 100`) are NOT chunked — resolve a prototype-only symbol from its .c definition.</fact>
-        <fact>Only quoted local includes (`#include "net/socket.h"`) are tracked; angle-bracket system includes are dropped. So Deps:/Used by: cover INTRA-PROJECT headers (reliable) but say nothing about libc/third-party.</fact>
-        <fact priority="critical">THE PREPROCESSOR IS NOT EXPANDED. Macro bodies are textual — a call inside a macro invocation is NOT an edge, and a symbol produced only by token-pasting (`##`) has no chunk. If a function that "must exist" is unfindable, a macro is generating it — read the function-like macro chunk, don't hunt for an expanded body.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="no-namespaces">No namespaces/classes: every name is global, so libraries collide (init, create, free_* recur). resolve_symbol returns many — disambiguate by card path or a subsystem hint ("socket buffer init").</rule>
-        <rule name="static-is-file-local">`static` functions are private to ONE translation unit, so the same static name legitimately exists in many .c files — the path is the disambiguator, they are not duplicates.</rule>
-        <rule name="function-pointer-dispatch">Polymorphism is a struct of function pointers (hand-rolled vtable): `ops->read(fd)` records callee `read` with receiver `ops`, but the REAL target is whatever was assigned to that field. get_call_graph through a pointer is ambiguous/empty — find the assignment with ONE search_code(exact_tokens: "the_concrete_fn") and read the initializer that wires it.</rule>
-        <rule name="header-vs-source">Declarations in .h, definitions in .c. Prefer the function_definition chunk (has the body); the struct/typedef chunk in the header is the type's shape. Empty call graph on a struct type is normal — enumerate consumers from Used by: + ONE exact_tokens search on the type name.</rule>
-        <rule name="query-style">snake_case splits well — bare behavioural words work; pin Struct/Enum/typedef names and ALL_CAPS macros with exact_tokens. For error flow, search the errno constant or the literal error message — far more unique than "error".</rule>
-    </rules>
-
-    <playbook question="explain function or subsystem X" calls="1-3">resolve_symbol("X") (disambiguate by path) → get_chunk_summary(id, expand_calls: true) → answer. Callback-driven flow: ONE exact_tokens search on the concrete function name to find where the pointer is installed — never read whole subsystem files to chase dispatch.</playbook>
-
-</environment_prompt>

package/prompts/languages/CSHARP.md

@@ -1,24 +0,0 @@
-<environment_prompt layer="2" type="language" name="csharp" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is C# (.cs). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: classes, interfaces, enums, methods, constructors, and PROPERTIES — a bodied property is its own chunk; resolve the property name directly, never a get_X accessor. Attributes are part of the chunk and often ARE the behaviour.</fact>
-        <fact>Topology RELIABLE — `using` directives tracked.</fact>
-        <fact>`partial` classes split one type across files: resolve_symbol("OrderService") may return several chunks of the SAME type — treat as one class; read the relevant part, list the rest.</fact>
-        <fact>Auto-properties, record positional members, compiler-generated members (Equals, Deconstruct) have no bodies anywhere — the type declaration IS the answer.</fact>
-        <fact>find_references on a type is FIELD-PRECISE: tracks usage as parameter types, field types, property types, return types, and base-list entries (~54% of chunks carry at least one type_ref) — the most complete type-usage channel in the suite. Prefer it over a name search when the question is "what code depends on this type".</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="interface-dispatch">Call sites bind by NAME, usually against an interface: get_call_graph("Process") mixes every Process. Find implementations with ONE search_code(query: "implements the order service", exact_tokens: "IOrderService") — the `I` prefix makes interface names high-precision tokens.</rule>
-        <rule name="events-no-edges">`+=` wiring and delegate/Func invocations connect nothing in the graph — ONE exact_tokens search on the EVENT or delegate field finds subscription and raise sites together.</rule>
-        <rule name="linq-and-method-groups">LINQ chains record calls to Where/Select, not the lambdas inside; method groups (`list.Select(Map)`) create no edge to Map — find value-references with exact_tokens. Lambdas/local functions live inside their enclosing member's chunk.</rule>
-        <rule name="frameworks-and-generators">Reflection, DI containers, source generators invoke/create code with zero static edges: an empty call graph on a public member of an attributed class means FRAMEWORK-INVOKED or GENERATED, not dead.</rule>
-        <rule name="overloads-and-async">Overloads share a name — distinguish by parameter lists and say which you mean. async/await edges are normal, but fire-and-forget tasks decouple timing — answer ordering from ONE chunk's code.</rule>
-        <rule name="query-style">XML doc comments are indexed — behavioural queries match them. Exception flow: ONE exact_tokens search on the exception type finds throw sites and handlers together.</rule>
-    </rules>
-
-    <playbook question="explain service X" calls="2-3">resolve_symbol("X") (attributes + partials visible) → get_chunk_summary(id, expand_calls: true) → answer with Used by:; ≤1 caller/implementation hop.</playbook>
-
-</environment_prompt>

package/prompts/languages/CSS_SCSS.md

@@ -1,22 +0,0 @@
-<environment_prompt layer="2" type="language" name="css-scss" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code includes stylesheets (.css .scss). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>RULE SETS chunk as their selector (selector + declaration block); the chunk's "symbol" is the selector. No import topology — Deps:/Used by: are empty.</fact>
-        <fact>SCSS @mixin and @function ARE indexed as NAMED chunks — resolve_symbol("button-variant") works; they are the reusable units worth searching by name. ($variables, @include sites, &-nesting are not separate chunks — find them by searching the token.)</fact>
-        <fact>get_call_graph DOES NOT APPLY (no call edges); for a mixin/function's call sites, search its name token. resolve_symbol is useful ONLY for @mixin/@function names, not plain selectors.</fact>
-        <fact>Very short rules (under ~2 lines) are filtered as trivial — a one-line utility class may be absent; widen the query or read the file if a tiny rule is the whole question.</fact>
-        <fact>get_file_skeleton is WEAK on stylesheets (mostly anonymous declaration nodes, no @keyframes names) — search_code by selector/mixin token instead.</fact>
-        <fact>In a MIXED repo, style chunks surface as noise in NL searches for other languages — add a path/directory hint to keep code queries on code.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="find-by-token">Styles for an element: ONE search of the class/id token, e.g. search_code(query: "card hover elevation styles", exact_tokens: ".card"). Variables/design tokens ($spacing, --color-primary): search the variable name — definition and usages return in one query.</rule>
-        <rule name="cascade-awareness">Several rule sets can target one element and the top hit may not win the cascade. For "why does this look wrong", read the 2-3 top-ranked rule sets FROM THE SAME RESULT — never a second search, never whole stylesheets.</rule>
-        <rule name="markup-side">WHERE a class is applied lives in components/markup, not stylesheets — that half belongs to the component language layer (search the class name string in code chunks).</rule>
-    </rules>
-
-    <playbook question="why does element X look wrong" calls="1-2">ONE search of the selector token (top_k: 10) → list every matching rule_set with file:lines, compare declarations → answer. Stylesheet chunks are tiny; one search almost always suffices.</playbook>
-
-</environment_prompt>

package/prompts/languages/GO.md

@@ -1,24 +0,0 @@
-<environment_prompt layer="2" type="language" name="go" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is Go (.go). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: top-level funcs, methods, type decls. A method's signature includes its RECEIVER — `func (s *Server) Start()` — so the card already says whose method it is; check the receiver before reasoning.</fact>
-        <fact>Topology RELIABLE — imports tracked.</fact>
-        <fact>Generated files (*.pb.go, mocks, stringer) are indexed like source and can dominate results — prefer detail: "signatures" and skip generated paths.</fact>
-        <fact>Struct construction (`&Engine{...}`, `Engine{}`, constructors returning `*T`) is NOT a call edge → get_call_graph("Engine") on a struct is EMPTY, never "unused". Enumerate consumers from Used by: + ONE search_code(exact_tokens: "Engine", detail: "signatures") for call-site locations; never read the whole defining file's skeleton.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="package-scoped-names">Every package has a New, a Config, a Client: resolve_symbol("New") returns many — disambiguate by package path on the cards, or query with a path hint ("storage client New connection pool").</rule>
-        <rule name="interface-dispatch">Interface satisfaction is implicit; call sites bind by method NAME: get_call_graph("Process") mixes every Process. Enumerate implementations: ONE search_code(query: "method receiver implementation", exact_tokens: "MethodName") and read the receivers off the signatures.</rule>
-        <rule name="embedded-promotion">A call to a method the outer type doesn't define lives in an EMBEDDED type — check the type-declaration chunk for embedded fields before distrusting the index.</rule>
-        <rule name="implicit-execution">init() and `_` blank imports run with no inbound edges — absence of callers is not dead code. `go fn()` and `defer fn()` ARE edges; channel flow is not — trace channels by searching the channel field name.</rule>
-        <rule name="first-class-functions">Functions passed as values (http.HandlerFunc(handle), middleware constructors) create no edge to the passed function — find sites with exact_tokens.</rule>
-        <rule name="input-reachability">SECURITY — "can request/CLI input reach a dangerous call" (exec, SQL, fs/path) → trace_taint (Go is supported); find_tainted_sinks first to map the surface. Finder, not proof — "no flows" ≠ safe.</rule>
-        <rule name="query-style">Always include package/domain words ("auth middleware token refresh", never bare "Refresh"). To find where an error originates, search its message string literal — the most unique token in the flow.</rule>
-    </rules>
-
-    <playbook question="explain X / who implements interface I" calls="1-3">resolve_symbol("X") (check receiver) → get_chunk_summary(id, expand_calls: true) → answer. Implementors of I: ONE exact_tokens search on the method name — receivers in the signatures are the answer, no per-type reads.</playbook>
-
-</environment_prompt>

package/prompts/languages/JAVA.md

@@ -1,23 +0,0 @@
-<environment_prompt layer="2" type="language" name="java" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is Java (.java). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: classes, interfaces, enums, constructors, methods. Annotations are part of the chunk — summaries surface @Override, validation, and framework annotations that frequently carry the real behaviour.</fact>
-        <fact>Topology RELIABLE — imports tracked. One public class per file means path ≈ FQN: resolve_symbol("InvoiceService") is extremely reliable.</fact>
-        <fact>Chunking is CLASS-GRANULAR (god-class split only ≥200 lines) — methods are NOT their own chunks in small classes. get_call_graph on a method name returns callers at class level, not method level; name the method explicitly and confirm by class context on the cards.</fact>
-        <fact>Anonymous inner classes and lambdas have no named symbol — a Runnable defined inline lives in its enclosing method's chunk; find it by behavioural search.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="overloads-collapse">Overloads share one name: resolve_symbol("save") / get_call_graph("save") mix all signatures — distinguish by parameter lists on the cards and say WHICH overload you mean.</rule>
-        <rule name="polymorphic-dispatch">Call sites bind to the NAME as written, usually against an interface/superclass: verify the receiver's declared type before claiming a concrete impl is called. Enumerate overrides: ONE exact_tokens search on the method name — class context comes from each signature.</rule>
-        <rule name="inheritance-walk">If resolve_symbol finds a method only on a parent type, that IS the impl — resolve at most ONE parent up, never the whole hierarchy.</rule>
-        <rule name="frameworks-and-reflection">Class.forName, Method.invoke, DI containers, annotation processors invoke with ZERO static edges: an empty call graph on a public method of an annotated class means FRAMEWORK-INVOKED, not dead.</rule>
-        <rule name="functional-interfaces">Lambdas and method references (this::handle, User::getName) create no edge to the referenced method — find sites with exact_tokens.</rule>
-        <rule name="accessor-noise">Never read a POJO/bean body: detail: "signatures" or get_file_skeleton tells you everything a data class can. Exception flow: ONE exact_tokens search on the exception class finds throw sites and handlers together.</rule>
-    </rules>
-
-    <playbook question="explain service X / change a method safely" calls="2-4">resolve_symbol("X") (annotations visible) → get_chunk_summary(id, expand_calls: true) → answer with Used by:. Signature change: impact_of_edit(symbols:["method"]) — transitive callers+overrides+tests in ONE call, no recursive get_call_graph (class-granular chunks make that painful) → ONE caller chunk as template → edit.</playbook>
-
-</environment_prompt>

package/prompts/languages/JAVASCRIPT_TYPESCRIPT.md

@@ -1,24 +0,0 @@
-<environment_prompt layer="2" type="language" name="javascript-typescript" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is JavaScript/TypeScript (.js .jsx .mjs .cjs .ts .tsx). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: functions, classes, methods, exported consts. An arrow fn assigned to a const chunks under the VARIABLE name — resolve_symbol("handleSubmit") finds `const handleSubmit = () => {...}`.</fact>
-        <fact>Topology RELIABLE — ESM and require both tracked. Read Deps:/Used by: before any usage search.</fact>
-        <fact>Anonymous default exports (`export default () => {}`) have no stable name — locate via get_file_skeleton(path) or behavioural search, never by guessing.</fact>
-        <fact>Interfaces, type aliases, enums resolve like values but NEVER appear in get_call_graph (types aren't called) — usage from Used by: or ONE exact_tokens search.</fact>
-        <fact>`new ClassName()` DOES create a call edge → get_call_graph("Layer") returns construction sites: the cheap precise first move for a class's blast radius (~15 tok), no file reads. (A class used only as a type annotation shows none → Used by: + ONE search_code(exact_tokens: "Name", detail: "signatures").)</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="barrel-files">Resolution landing on a re_export (index.ts barrel): internal origin → ONE hop to the origin; external dependency → stop, implementation is outside the repo.</rule>
-        <rule name="callbacks-no-edges">A function passed as a VALUE has no edge: `items.map(transform)` records a call to map, not transform. An empty call graph on a callback-style fn is NOT dead — find sites with ONE exact_tokens search.</rule>
-        <rule name="dynamic-imports">`await import(computedPath)` / `require(variable)` create no dependency edge. Empty Used by: on a module that should be popular → suspect dynamic loading before declaring it unused.</rule>
-        <rule name="name-overmatch">`this.method()` and property calls bind by NAME; common names (get, run, handle) overmatch across classes, and declaration merging returns several nodes for one name — pick by file path + node type on the cards, no extra reads.</rule>
-        <rule name="event-emitters">`emitter.on("event", fn)` pairs connect by STRING, not call edge — trace event flow by searching the event-name string.</rule>
-        <rule name="query-style">camelCase/PascalCase split well so partial-name keyword queries work; for async flows describe behaviour ("retries the fetch with exponential backoff"), never the keyword "async".</rule>
-    </rules>
-
-    <playbook question="explain service/module X" calls="2-3">resolve_symbol("X") → get_chunk_summary(id, expand_calls: true) → answer with the Used by: list; ≤1 consumer chunk as example.</playbook>
-
-</environment_prompt>

package/prompts/languages/KOTLIN.md

@@ -1,24 +0,0 @@
-<environment_prompt layer="2" type="language" name="kotlin" requires="graph-indexer-core" version="1.0">
-
-    <scope>Indexed code is Kotlin (.kt .kts). Deltas to core; hard limits unchanged.</scope>
-
-    <index_facts>
-        <fact>Chunks: functions, classes, OBJECT declarations, COMPANION OBJECTS, secondary constructors — resolve objects/companions by name like any class. Annotations are part of the chunk and often ARE the behaviour.</fact>
-        <fact>Topology RELIABLE — imports tracked.</fact>
-        <fact>Top-level functions/properties live directly in files: get_file_skeleton(path) is the fastest view of free functions. Lambdas and `let`/`apply`/`run`/`also` blocks have no symbol — that logic belongs to the enclosing chunk; find it behaviourally.</fact>
-        <fact>Data classes auto-generate copy/equals/hashCode/componentN with NO chunks — a "missing" method matching that list means the data-class declaration IS the answer.</fact>
-        <fact>Caller resolution is NAME-ONLY (no receiver class): get_call_graph mixes callers across every class sharing that method name — always verify receivers from card signatures before drawing conclusions. This is the same WEAK precision as Go/Rust/Ruby, not the receiver-aware precision of JS/TS/Python/C#.</fact>
-    </index_facts>
-
-    <rules>
-        <rule name="invoke-operator">`useCase(input)` dispatches to an `invoke` operator with NO edge — common in clean-architecture code. Empty call graph on invoke (or a use-case class) means nothing: find usage with ONE exact_tokens search on the class name.</rule>
-        <rule name="delegation">`by lazy`, `by viewModels()`, class delegation (`class A : B by impl`), property delegates route through getValue/setValue with no edges — resolve the DELEGATE expression's symbol when delegated behaviour is the question.</rule>
-        <rule name="lambdas-and-references">Trailing-lambda calls (`list.map { }`, `scope.launch { }`) record a call to the combinator only; `::handle` references create no edge — find sites with exact_tokens.</rule>
-        <rule name="name-overmatch">Like Java, call sites bind by NAME against interfaces/supertypes: get_call_graph("process") mixes every process — confirm receivers from card signatures. Extension functions resolve under the FUNCTION name (resolve_symbol("slugify")), not the receiver type. Custom property getters live in the PROPERTY's declaration, not a getX accessor.</rule>
-        <rule name="coroutines">suspend calls have normal edges, but launch/async decouple call site from execution — answer ordering questions from ONE chunk's code, not the graph.</rule>
-        <rule name="query-style">DSL/builder code has generic names — search behaviourally. Sealed hierarchies: ONE exact_tokens search on the SEALED PARENT name returns all variants and every `when` over them.</rule>
-    </rules>
-
-    <playbook question="explain class/use-case X" calls="2-3">resolve_symbol("X") (annotations + companion visible) → get_chunk_summary(id, expand_calls: true) → answer with Used by:; ≤1 delegate/interface hop.</playbook>
-
-</environment_prompt>