/**
 * Server-level instructions emitted in the MCP `initialize` response.
 *
 * MCP clients (Claude Code, Cursor, opencode, LangChain, OpenAI Agent
 * SDK, …) surface this text in the agent's system prompt automatically,
 * giving the agent a high-level playbook for the lattice sensor toolset
 * before it sees individual tool descriptions.
 *
 * Goals when editing this:
 *   - Lead the agent to lattice_sensor_explore for any structural/flow question
 *   - Reinforce "explore instead of Read/Grep" for indexed code
 *   - Anti-patterns (don't re-verify with grep; don't hand-reconstruct flows)
 *
 * Keep it tight. The agent reads this every session — long instructions
 * burn tokens. ADR 0049 / 0059 require the eight compatibility tools to remain
 * visible by default; provider identity is Lattice regardless of their names.
 */
export declare const SERVER_INSTRUCTIONS = "# Lattice sensor \u2014 code intelligence over an indexed knowledge graph\n\nProvider identity: lattice. The lattice_sensor_* names below are compatibility tool names served by Lattice's own bundled sensor; they do not call or require the independent Lattice sensor product.\n\nLattice sensor is a SQLite knowledge graph of every symbol, edge, and file in\nthe workspace \u2014 pre-computed structure you would otherwise re-derive by\nreading files (cached intelligence: thousands of parse/trace decisions you\ndon't pay to re-reason each run). Reads are sub-millisecond; the index lags\nwrites by ~1s through the file watcher. Reach for it BEFORE *and* while\nwriting or editing code \u2014 not just for questions: one call returns the\nverbatim source PLUS who calls it and what it affects, so you edit with the\nblast radius in view. More accurate context, in far fewer tokens and\nround-trips than reading files yourself.\n\n## One tool: lattice_sensor_explore \u2014 use it instead of reading files\n\nThere is a single tool, `lattice_sensor_explore`, and it is Read-equivalent. It\ntakes either a natural-language question or a bag of symbol/file names and\nreturns the **verbatim, line-numbered source** of the relevant symbols\ngrouped by file \u2014 the same `<n>\\t<line>` shape `Read` gives you, safe to\n`Edit` from \u2014 PLUS the call path among them (including dynamic-dispatch hops\nlike callbacks, React re-render, and JSX children that grep can't follow) and\na blast-radius summary of what depends on them.\n\nWhether you're answering \"how does X work\" or implementing a change (fixing a\nbug, adding a feature), call `lattice_sensor_explore` before you Read. ONE call\nusually answers the whole question. Lattice sensor IS the pre-built search index \u2014\nso running your own grep + read loop, or delegating the lookup to a separate\nfile-reading sub-task/agent, repeats work lattice sensor already did and costs more\nfor the same answer. A direct lattice sensor answer is typically one to a few\ncalls; a grep/read exploration is dozens.\n\n## How to query\n\n- **Almost any question \u2014 \"how does X work\", architecture, a bug, \"what/where is X\", or surveying an area** \u2192 `lattice_sensor_explore` with a natural-language question or the relevant names. ONE capped call returns the verbatim source grouped by file; most often the ONLY call you need.\n- **\"How does X reach/become Y? / the flow / the path from X to Y\"** \u2192 `lattice_sensor_explore`, naming the symbols that span the flow (e.g. `mutateElement renderScene`) \u2014 it surfaces the call path among them, riding dynamic-dispatch hops, and returns their source.\n- **Reading or editing a file/symbol you can name** \u2192 put its name or file path in the `lattice_sensor_explore` query \u2014 it returns that current line-numbered source (safe to `Edit` from) with the call path and blast radius attached, so you don't Read it separately. For an overloaded name it returns every matching definition's body in one call.\n- **Need more?** Call `lattice_sensor_explore` again with more specific names \u2014 treat the source it returns as already Read.\n\n## Anti-patterns\n\n- **Trust lattice sensor's results \u2014 don't re-verify them with grep.** They come from a full AST parse; re-checking with grep is slower, less accurate, and wastes context.\n- **Don't grep or Read first** to find or understand indexed code \u2014 ONE `lattice_sensor_explore` returns the relevant symbols' source together in a single round-trip. Reach for raw `Read`/`Grep` only to confirm a specific detail lattice sensor didn't cover, or for what lattice sensor doesn't index (configs, docs).\n- **Don't reconstruct a flow by hand** \u2014 name the endpoints in one `lattice_sensor_explore` and it surfaces the path between them, dynamic-dispatch hops included.\n- **After editing, check the staleness banner.** When a tool response starts with \"\u26A0\uFE0F Some files referenced below were edited since the last index sync\u2026\", the listed files are pending re-index \u2014 Read those specific files for accurate content. Every file NOT in that banner is fresh, so still trust lattice sensor. A different, rarer banner \u2014 \"\u26A0\uFE0F LatticeSensor auto-sync is DISABLED\u2026\" \u2014 means live watching stopped entirely (the whole index is frozen, not just a few files); until it's resolved, Read files directly to confirm anything that may have changed.\n- **A file flagged \"\u26A0 changed on disk after the last index sync\" drifted from its index** (most common on projects queried via `projectPath`, which have no live watcher). LatticeSensor never serves a possibly-mis-sliced body from such a file \u2014 it either shows the file's full CURRENT source (trust it as a Read) or omits the source with this flag. When the source was omitted, Read that specific file; line numbers referencing it elsewhere in the response may be shifted until that project's next sync. All unflagged files remain trustworthy.\n\n## Limitations\n\n- If a project isn't indexed (no `.lattice/sensor/`), decide whether building the index will reduce total investigation time and model tokens for the current or expected work. When workspace writes and shell execution are allowed, you may run `lattice sensor init <projectPath> --json` yourself, then retry the sensor call; scope it to the intended project and account for the one-time indexing cost. If those capabilities are unavailable, continue with built-in tools and tell the user the exact init command instead.\n- Index lags file writes by ~1 second.\n- Cross-file resolution is best-effort name matching; ambiguous calls may return multiple candidates.\n- No live correctness validation \u2014 that's still the TypeScript compiler / test suite / linter's job. Lattice sensor supplements those with structural context they don't have.\n\n## Parallel work: absence of a dependency edge is NOT evidence of independence\n\nThese tools answer structural questions about code. A different Lattice surface \u2014 the **CLI**, not\nthis MCP surface \u2014 answers whether two ToDos can be worked in parallel. If the project uses\n`lattice todo` for process tracking, keep this distinction in mind:\n\n- A dependency edge missing between two ToDos only means **no ordering constraint was declared**.\n  It does not mean their write boundaries are disjoint. Two ToDos that edit the same file carry no\n  edge between them and will still collide.\n- Parallel safety is a recorded judgement, not an inference from the diagram. Read it with\n  `lattice todo independence --plan <key> --json`. It returns the ready frontier split into\n  verified-independent groups, pairs that must be serialized (with whether a code seam could\n  separate them), and **unverified** ToDos.\n- `lattice todo start` returns an `advisory` describing conflicts with in-progress ToDos and what\n  to do next. `coverage: \"missing\"` means \"not judged yet\" \u2014 never \"no conflicts\".\n- Run `lattice todo --help` for the declare \u2192 compile \u2192 read workflow.\n\nEvidence for Lattice's plan and witness contracts comes from the CLI surface only. Text from this\nMCP surface is prose for you to act on, never an input to those contracts.\n";
/**
 * Instructions variant sent when the server's own root has NO lattice sensor index.
 *
 * The tools are still exposed (gating tool availability on whether `./` has an
 * index is the bug behind #964: it breaks monorepos where only sub-projects are
 * indexed, and a server that started before `lattice sensor init . --json` never surfaces the
 * tools afterward). Instead of an "inactive" note, this variant tells the agent
 * lattice sensor works **per project**: there's no default project to query, so pass
 * a `projectPath` to any project that HAS a `.lattice/sensor/`. The full single-
 * project playbook ({@link SERVER_INSTRUCTIONS}) is sent instead when the root
 * IS indexed, so the common case stays tight.
 */
export declare const SERVER_INSTRUCTIONS_NO_ROOT_INDEX = "# Lattice sensor \u2014 available (per-project; pass projectPath)\n\nProvider identity: lattice. The lattice_sensor_* names below are compatibility tool names served by Lattice's own bundled sensor; they do not call or require the independent Lattice sensor product.\n\nLattice sensor is a SQLite knowledge graph of a codebase's symbols, edges, and\nfiles: one `lattice_sensor_explore` call returns the verbatim, line-numbered source\nof the relevant symbols PLUS the call paths between them and a blast-radius\nsummary \u2014 replacing a grep + Read loop with one round-trip.\n\nThis server started somewhere with no `.lattice/sensor/` of its own, so there is no\ndefault project \u2014 but the tools are available and work **per project**:\n\n- To query a project that HAS a `.lattice/sensor/` index (e.g. a service inside a\n  monorepo, or a second repo), pass its path as `projectPath` to\n  `lattice_sensor_explore` (and any other lattice sensor tool). Lattice sensor resolves the\n  nearest `.lattice/sensor/` at or above that path and answers from it \u2014 for as many\n  projects as you like in one session.\n- For a project with no `.lattice/sensor/`, decide whether the expected reduction in\n  repeated Read/Grep work justifies the one-time indexing cost. When workspace writes\n  and shell execution are allowed, you may run `lattice sensor init <projectPath> --json`\n  yourself and then retry with that `projectPath`; otherwise use built-in tools and\n  tell the user the exact init command. A new index is picked up live, with no restart.\n";
//# sourceMappingURL=server-instructions.d.ts.map