v0.5: Semantic layer & second-brain enrichment: make the graph think like the engineer

Executive summary

v0.4 closed every documented debt of v0.3 and shipped a cross-editor LSP companion. v0.5 has a different shape: it changes what Synapse is, not just what it can do. The product moves from “typed Markdown store with FTS5 search and a great audit trail” to “active knowledge graph that recognises the same entity across notes the moment you write each one”.

The owner’s framing is what makes this brief different from a pure “add embeddings” cycle: do the work at insertion time, not query time. The brief codifies this as a new business rule BR-13 and structures v0.5 around it. Embeddings ship as one signal among three (FTS, vector, entity graph) combined by Reciprocal Rank Fusion. The local-first invariant is preserved: the chosen embedding backend is fastembed-rs via ONNX Runtime: ~70 MB total footprint, ~14× smaller than the equivalent Ollama setup, runs on any CPU without external services.

Twenty tickets (twelve core + four arch-debt + four stretch). Six weeks of focused execution. The benchmark suite (SYN-90..SYN-93 corpus generator + P@k / nDCG@10 / MRR / latency budget) is core, not stretch: without it the choice of every algorithm in v0.5 is folklore.

1. The premise: what Synapse is for, restated for v0.5

Synapse’s target user has been consistent since v0.1: the multi-context developer of 2026, the engineer who runs 3-7 client projects in parallel because Claude Code / Cursor / Cline let them. The product compresses context-switching cost. v0.1..v0.4 made the store correct, auditable, and scriptable. v0.5 is the cycle that makes it associative: when the user writes a note about a meeting with Carina, the workspace should already know that “Remote Config” mentioned there is the Firebase tool from the other note. The query “flag do Firebase do dia X” finds both notes because the ingestion step wired them together; the search engine is just looking up the edge that was already drawn.

1.1 The canonical query that v0.5 must answer

The owner’s concrete example, restated:

Note A: notes/2026-04-20-reuniao-carina.md, kind meeting: “Reunião com Carina sobre a flag enable_v2_checkout do Remote Config. Acordamos rebatizar para checkout-v2-eligibility antes do próximo deploy.”

Note B: notes/firebase-stack.md, kind reference: “Remote Config é a ferramenta de feature-flags do Firebase. Os valores são entregues em tempo real para os clientes mobile.”

Query (via Claude Code MCP, or syn search): “Qual o nome da flag do Firebase do dia da minha reunião com a Carina?”

What it takes to answer this:

FTS5 alone, today, scores note B (literal match for “Firebase”) and maybe finds “Carina” in the participants index, but the link Remote Config → Firebase is invisible until both notes are seen together by the generation step: that means the LLM has to do the work, which means latency, cost, and non-determinism. v0.5’s job is to draw that edge once, when the user writes note B, so every future query that touches Firebase or Remote Config sees the link without paying for it again.

1.2 The new business rule BR-13: insertion-time enrichment

BR-13 (proposed for docs/business/BUSINESS_RULES.md). Synapse processes entries at insertion time, not query time. Every CLI write (syn project add, syn person add, syn note add, capture_fact via MCP, …) hooks an enrichment pipeline that runs synchronously before the workspace transaction commits:

1. Embed the entity’s title + body + tags with the configured embedding model; write the vector to the entities_vec table.
2. Extract candidate mentions: slugs of existing entities that textually appear in the new content, dates, person names with @-prefix syntax, URLs, tag tokens, plus NER-detected spans (see §1.3 below for the language-per-workspace contract that drives the model choice).
3. Resolve mentions: every candidate is matched against the live workspace index. A hit becomes a typed link row with rel = "mentions" or rel = "concept:<lemma>"; a miss becomes a pending proposal of kind link_entity (existing) or create_entity_from_ner (new, when the NER pass discovered a span whose mapped Synapse entity type does not yet exist).
4. Latency budget: median ≤ 500 ms, p95 ≤ 800 ms on a 10k-entity workspace (M1 Pro reference). The pipeline runs the embedding and the NER passes in parallel inside the same Workspace::tx so the wall-clock cost is max(embed, ner) + heuristic + link_resolve, not the sum. Background / async enrichment is explicitly out of scope for v0.5 and tracked as the v0.6 follow-up SYN-194.
5. Fail loud: if the enrichment step errors, the entity write aborts (atomicity preserved). The user can disable enrichment per workspace via [enrichment] mode = "off" for the workspace that wants raw v0.4 semantics back.

The principle: the IA is the memory co-pilot, not the real-time reranker. The work is paid once, on write.

This is the load-bearing decision of v0.5. Every other choice: vector backend, ranking algorithm, model size, benchmark target: flows from it.

1.3 Product principle: best models by default, per-workspace opt-down

Owner decision 2026-06-02: Synapse ships the strongest model in each slot by default. Smaller / English-only / faster variants are reachable through workspace config but the user does not have to know they exist to get a good first experience.

The corollary that matters for architecture: language is a per-workspace property, not a per-binary one. A single Synapse install may host one workspace where [enrichment] language = "pt-BR" and another where it is "en-US"; both must run with equivalent retrieval quality and write latency. The embedding backend and the NER model are selected per workspace from a shared ~/.cache/synapse/models/ registry: the binary itself stays language-agnostic.

The matrix this produces:

The configuration knob lives in <workspace>/.synapse/config.toml:

[enrichment]
language        = "pt-BR"            # or "en-US"
embedding_model = "bge-m3"           # or "bge-small-en-v1.5-q"
ner_model       = "gliner-multi"     # or "gliner-base-en"
mode            = "heuristic+ner"    # or "heuristic" (skip NER), "off" (raw v0.4)

Defaults match the “best by default” row. The cascade config (user-level ~/.config/synapse/config.toml → workspace) is the same as for other blocks (per ADR-011 §config policy).

2. Market scan: the four technical decisions in plain language

The brief uses the rest of the section to make the tooling choices defensible. Each subsection ends with a single line: What this means for Synapse.

2.1 Embedding backend: does it have to be Ollama?

In mid-2026 the realistic options for generating sentence embeddings from a Rust application are:

The 2026 industry baseline for fast on-device embedding in a CPU-only Rust application is fastembed-rs: Qdrant’s port of their original Python library, in production at multiple Rust shops, supports the standard embedding catalogue (BGE, Nomic, mxbai, MiniLM) including their quantised ONNX variants ([fastembed-rs on crates.io], [Qdrant article on fastembed]).

The model the brief recommends as the v0.5 default: superseding the original draft’s BGE-small-EN-v1.5 pick after the owner’s 2026-06-02 “best by default + per-workspace language” answer (§1.3): is BGE-M3 multilingual quantised: 1024-dimensional, ~570 MB on disk, MTEB multilingual top-quartile (covers en + pt-BR + es + 100 + other languages at near-state-of-the-art quality), embed latency ~80–200 ms on M1 Pro CPU. For workspaces whose [enrichment] language = "en-US" and that explicitly value binary footprint over recall, the BGE-small-EN-v1.5-Q variant (~33 MB) is the opt-down: same trait implementation, different model identifier passed to fastembed.

What this means for Synapse: Default fastembed-rs with BGE-M3 quantised, per-workspace selectable to BGE-small-EN-v1.5-Q. Ollama is a configurable alternative ([embeddings] provider = "ollama") but not the default. The local-first invariant survives. The binary itself stays small; the model lives in ~/.cache/synapse/models/ and is downloaded on first use of each workspace.

2.2 Vector storage: is sqlite-vec ready?

sqlite-vec is Alex Garcia’s loadable extension for SQLite that adds vector columns, vec0 virtual tables, and L2 / cosine / dot distance functions in ~1.5 MB of native code. It is post-1.0, used in production, and Alex Garcia maintains explicit Rust integration docs ([Using sqlite-vec in Rust]).

Two gotchas to plan for, both flagged in upstream issues and the rusqlite discussion threads ([rusqlite discussion #1423]):

1. rusqlite bundled + load_extension interaction. Bundled SQLite does not enable run-time loadable extensions by default, the user has to call conn.load_extension_enable() before load_extension(…), and on older SQLite versions the vtab feature has to be enabled at the rusqlite Cargo level. The crate exposes the flag; documenting it in ADR-008 prevents a wasted afternoon.
2. No HNSW yet: flat scan only. sqlite-vec currently does brute-force scan; an HNSW-style index is on the roadmap but not landed. For a personal workspace of < 10k entities the linear scan is fast enough (~5 ms on a modern CPU). The v0.5 ceiling is set by this: if a user workspace exceeds ~50k entities, the recommendation is to chunk by workspace via federation rather than wait for sqlite-vec HNSW.

The cheap alternative is flat scan in pure Rust (Vec<f32> columns + SIMD cosine): same time complexity, fewer abstractions, but reinvents the storage layer. The expensive alternative is lance (Apache Arrow-based columnar vector DB): full HNSW + ANN, but ~50 MB of code and a different mental model from “everything lives in .synapse/index.db”.

What this means for Synapse: Adopt sqlite-vec. It keeps the single-database invariant from BR-1. Document the load_extension setup in ADR-008. Accept the flat-scan ceiling; revisit in v0.7 if a real user hits it.

2.3 Hybrid ranking: RRF or convex combination, didactically

Once Synapse has three retrieval signals (FTS5, embeddings, entity-graph neighbourhood), the search command needs to fuse their results into a single ranked list. Two algorithms dominate the 2026 literature:

Reciprocal Rank Fusion (RRF)

The intuition. Each retrieval system independently ranks the documents. RRF ignores the scores (which are on incompatible scales: BM25 returns 0..∞ while cosine similarity returns -1..1) and uses only the ranks:

RRF_score(doc) = Σ_i  1 / (k + rank_i(doc))

rank_i(doc) is doc’s position in retriever i (1 if it’s the top hit, 2 if second, …). k = 60 is the standard tuning constant. A document that is top-3 in BM25 and top-3 in vector search gets a high combined score; a document that is top-1 in only one retriever still scores well but loses to documents that show up in multiple.

Worked example: the Carina/Firebase query.

Both target notes surface in the top-3, even though FTS5 never saw note A and the random Firebase note ranked higher in literal text. RRF is safe out of the box and is the default of every major hybrid system shipped in 2026 (Elasticsearch, OpenSearch, Weaviate, Qdrant, [Hybrid search reference 2026]).

Convex Combination (a.k.a. score blending)

The intuition. Normalise each retriever’s score to [0,1], then take a weighted average:

score(doc) = α · vector_sim_normalised(doc)  +  (1-α) · bm25_normalised(doc)

α = 0.5 is the cold-start guess. The 2026 papers ([An Analysis of Fusion Functions for Hybrid Retrieval]) report convex combination outperforms RRF when you have at least ~40 labelled query → relevant-document pairs to tune α; below that, RRF wins because normalisation breaks across queries.

The trade-off, sharply. RRF is the right cold-start default. Convex combination is a polish step that requires the user to grade some search results. A personal workspace owner can generate those labels (syn search foo --grade), and v0.6 should ship that. v0.5 does not.

What this means for Synapse: RRF with k = 60 for v0.5. Convex combination becomes a v0.6 ticket gated on syn search --grade being shipped first.

2.4 Entity linking at ingestion: small models, big payoff

The 2026 emerging best practice in retrieval pipelines is adaptive RAG: classify the query first, route simple factual queries to vector RAG and relationship queries to a knowledge-graph traversal ([GraphRAG vs Vector RAG 2026]). The Synapse twist, per BR-13, is to do the graph-building at ingestion time rather than wait for the query.

The choice of how the graph gets built drives binary size and latency:

What this means for Synapse: updated 2026-06-02 after owner decision: v0.5 ships heuristic + GLiNER together as core. The original brief had GLiNER as stretch; the owner promoted it on the rationale that (a) pt-BR-grammatical content embeds proper nouns inside articles ("reunião com a Carina") which the heuristic-only path systematically misses, and (b) the per-workspace language contract from §1.3 makes GLiNER’s multilingual coverage a first-class need, not an optional one.

The promotion comes with three design specs that lock the budget:

1. Model is GLiNER-multi-base quantised (~150 MB) by default; GLiNER-base-en quantised (~70 MB) as the workspace opt-down per §1.3.
2. Embedding and NER run on parallel threads inside the same Workspace::tx. Wall-clock cost ≈ max(embed, ner). This is what keeps the BR-13 500 ms median budget reachable.
3. NER entity types are hard-coded by Synapse, not configured by the user: ["person", "organization", "product", "feature_flag", "api_endpoint", "framework", "tool", "decision_topic"]. The mapping from NER type → Synapse entity type lives in the linker (SYN-91): person → person, api_endpoint → api, product | tool | framework | feature_flag | organization | decision_topic → entity. A surprise NER type out of this set is dropped; a new type requires a minor brief amendment, not a workspace config change.

The Carina case is now solved without any user discipline: even if the user wrote "reunião com a Carina sobre a flag enable_v2_checkout do Remote Config" in raw pt-BR, NER tags Carina as person, Remote Config as product, enable_v2_checkout as feature_flag, and the linker either creates the typed links or emits create_entity_from_ner proposals to the pending queue.

The full-fledged GraphRAG with community summaries ([GraphRAG vs Vector RAG 2026]): 3–5× ingestion cost, requires LLM calls: remains out of scope. v0.5’s NER pass is the lightweight substitute; v0.6+ can evaluate whether the cost of community summaries pays off against the ingestion latency tax.

3. Cross-check vs the pre-research v0.5 backlog

The eleven issues already filed in milestone #7 are evaluated against the brief’s recommendation:

4. Architectural debt cleanup: non-negotiable, lands first

These four tickets close the debts the v0.4 closure doc surfaced. They are core, not stretch. They lock the architecture before the semantic layer piles new modules on top:

• SYN-151: mcp/server.rs dispatcher refactor. Move every #[tool] handler to a thin shim (3–8 lines) that delegates to a use-case module under src/core/mcp/ (or src/mcp/handlers/). Acceptance: file drops below 500 lines and stays there; a CI lint rejects regrowth above 600 lines. ADR-015 §Playbook updated with the dispatcher pattern.
• SYN-152: cli/at.rs split. Break the 620-line file into cli/at/{mod,search,show,list,info,graph}.rs. Pure code move, no behaviour change.
• SYN-153: cli/audit.rs split. Same pattern: cli/audit/{listing,verify,replay,stale,prune}.rs.
• SYN-154: file-size CI lint. A 30-line script in .githooks/pre-push or a GitHub Actions step: walk src/, fail when any file exceeds 800 lines, warn at 600. ADR-015 enforcement.

5. The semantic layer: execution plan

The semantic layer ships as a sequenced track. Order matters because each ticket depends on a primitive established by the previous one.

SYN-89 (ADR-008)
  ↓
SYN-80 (feature flag vector + migrations_vec/)
  ↓
SYN-81 (sqlite-vec wired; entities_vec table; bundled+vtab+load_extension)
  ↓
SYN-82 (trait EmbeddingBackend)
  ↓
SYN-84 (deterministic stub)  ← unblocks unit tests
  ↓
SYN-83 (fastembed-rs impl; Ollama impl behind config)
  ↓
SYN-85 (syn embed --all / --check / <slug>)
  ↓                              ↓
SYN-86 (hybrid RRF)         SYN-90 (BR-13 enrichment pipeline)  ← writes hook this
  ↓                              ↓
SYN-87 (syn search          SYN-91 (heuristic entity-linker:
        modes & flags)              slugs + dates + @mentions + URLs)
  ↓                              ↓
SYN-92 (benchmark suite: corpus generator + queries + metrics)
  ↓
SYN-93 (results report + thresholds for nDCG/P@k/MRR/latency)

Six new tickets join the eleven already-filed:

• SYN-90: pipeline: core::enrichment::run_on_write(ws, entity) called by every write helper before tx.commit(). Honours [enrichment] mode = "off" | "heuristic" | "ner". BR-13 codified.
• SYN-91: heuristic linker module. No model dep. Documented detection patterns. Emits pending proposals when a candidate is ambiguous (two slugs share a basename).
• SYN-92: benchmark corpus + query bank. Generator produces a synthetic workspace of 1k / 5k / 10k entities with planted cross-note relations (the Carina/Firebase template generalised). Query bank with ground-truth relevant_slugs per query.
• SYN-93: benchmark runner + results doc. CI artifact: bench/results-<date>.json.

Stretch (lands if window allows, otherwise v0.6):

• SYN-94: GLiNER NER backend behind --features ner. Comparable to the heuristic on the bench corpus.
• SYN-95: EmbeddingBackend::OpenAI and Voyage impls (network-based, behind explicit opt-in).
• SYN-96: syn search --grade to label query→relevant pairs for the v0.6 convex-combination polish.
• SYN-97: MCP semantic_search tool, only if SYN-88 finds a client use case the unified search_knowledge cannot serve.

6. The benchmark suite: what “strong” means here, concretely

A benchmark suite for v0.5 has to do three things at once: produce a corpus that is representative of a Synapse user’s data, encode queries that are hard in the way the Carina example is hard, and report metrics that force a decision when algorithms compete.

6.1 Corpus generator (SYN-92)

The generator outputs a workspace as .synapse/index.db + notes/, projects/, people/, apis/, entities/, tasks/. Three sizes (1k / 5k / 10k entities). Each generated workspace has a planted entity backbone:

• 5 fake “stacks” (e.g. firebase-stack, aws-stack, vercel-stack, notion-stack, langchain-stack): each represented by a notes/<stack>.md reference note that names 3–5 sub-tools (Firebase: Remote Config, Firestore, Auth, Functions, Storage).
• 30–60 fake “meetings” with participants drawn from a pool of 12 fake people. Each meeting note mentions a sub-tool by name (without naming the parent stack) and proposes a flag rename / config change / API call / decision.
• 20–40 fake “decisions” (note kind decision) referring back to a meeting and a stack sub-tool.

The cross-reference pattern is the Carina/Firebase pattern at scale. A query like “flag do Firebase do dia da reunião com Maria-Eduarda” has exactly one correct answer in the planted corpus; the benchmark measures whether the retrieval system finds it.

6.2 Query bank

50 queries per corpus, three difficulty tiers:

• T1: literal. “Carina” with no concept bridging: should be P@1 = 1.0 for everything (sanity check the FTS5 fallback).
• T2: single-hop concept (the Carina/Firebase case). The query names one concept (Firebase) and one anchor (a meeting participant or date); the correct answer is in a note that does not contain the concept word literally, only the sub-tool word. This is where RRF + embeddings + heuristic linking must beat plain FTS.
• T3: multi-hop / temporal. “What did we decide about retention in any AWS service in Q2?”: combines a temporal anchor with a parent-stack bridge with a decision-kind filter. RRF + embedding should surface the AWS-stack note + the relevant decision note; full GraphRAG would do better but is out of scope.

6.3 Metrics & thresholds

Thresholds are codified in SYN-93’s acceptance: if a metric is missed, the v0.5 brief gets reopened.

7. Footprint, honestly: what the user installs

Sizes measured on aarch64-apple-darwin static release builds, refreshed 2026-06-02 after the BGE-M3 + GLiNER-multi defaults were locked.

The deal the user signs up for by accepting the default install:

• Binary itself stays ≤ 60 MB (versus 14 MB today, +46 MB for the ONNX Runtime statically linked plus the fastembed glue plus GLiNER plumbing).
• First syn invocation in a fresh workspace fetches ~720 MB of models to ~/.cache/synapse/models/. The cache is shared across workspaces of the same language config, so a user with three pt-BR workspaces pays the 720 MB once, not three times.
• The English-only opt-down (target: low-resource laptops, CI workers) drops the cache to ~100 MB at the cost of multilingual coverage.

The Ollama-equivalent still costs 14× more on disk and adds a daemon dependency the user has to manage. The local-first invariant remains.

8. Risk register

9. Ticket sketch: provisional numbering

This is the proposed full v0.5 milestone after the brief lands. Provisional numbers in SYN-150 range expand into the unused SYN-151..199 block; existing SYN-80..89 + SYN-93b are kept with the retitles from §3. The new tickets fill the v0.2-adjacent free slots SYN-94..98 plus the expansion block.

9.1 Architecture-debt cleanup (lands first)

9.2 Semantic layer: core (must land)

9.3 Stretch (lands if window allows; otherwise rolls to v0.6)

9.4 Network freshness Phase 2: parallel track

9.5 New BR + ADR

• BR-13: insertion-time enrichment principle. Landing in docs/business/BUSINESS_RULES.md as part of SYN-90.
• ADR-008: embedding backend choice + sqlite-vec setup notes. Landing as part of SYN-89 before SYN-81 code starts.

10. Cuts assumed (registered explicitly)

• syn agent autonomous loop with batch approval: kept at v0.6, owner decision from 2026-05-25 carried.
• Microsoft-style GraphRAG with community summaries: too expensive (3–5× ingestion cost); v0.6+ or v0.7. Lightweight heuristic + optional GLiNER is the v0.5 substitute.
• syn cv export --as pdf: already cut from v0.4; still v0.5+1 stretch or later.
• Web UI / TUI: backlog.
• Cross-bundle merge of identity bundles: kept at v0.6+, ADR-014/016 cuts carried.
• Sigstore transparency log for identity: kept at v0.5+ per ADR-016 §Alternatives considered, lands when there is a public exchange to protect.

11. Decisions log

Decided 2026-06-02

1. ✅ Default embedding model: BGE-M3 multilingual. Owner answered the §2.1 question explicitly: ship the strongest model by default; BGE-small-EN-v1.5-Q is the per-workspace opt-down. Combined with the new product principle from §1.3, the binary itself stays language-agnostic; the model is selected per workspace.
2. ✅ GLiNER promoted from stretch to core. Owner answered the §2.4 question with option B: GLiNER-multi-base-Q default, GLiNER-base-en-Q opt-down per workspace. Hard-coded entity types, parallel embed+NER pipeline inside Workspace::tx, three mitigations from §2.4 locked as design specs. SYN-94 moved from §9.3 to §9.2; was retitled accordingly.

• ✅ BR-13 latency budget: write median ≤ 500 ms, p95 ≤ 800 ms. Owner raised the original 200 ms ceiling explicitly to make room for the GLiNER pass; async / background enrichment registered as the v0.6 follow-up (SYN-194) so the trade-off is not lost.
• ✅ Per-workspace language contract: owner declared the product is not pt-BR-primary; each workspace’s .synapse/config.toml picks its language = "pt-BR" | "en-US", and both must perform equivalently. Codified as §1.3 product principle; benchmark mandates pt-BR + en-US query variants in SYN-92.

Decided 2026-06-02 (second pass)

2. ✅ syn search syntax confirmed. Default = hybrid (FTS + vector + graph via RRF). --semantic = vector-only mode. --no-vector = FTS + graph only. Codified in §2.3, §3 (SYN-87 retitle), §9.2.
3. ✅ Ticket numbering: SYN-160..167 expansion block. Owner picked the safer remapping over reusing the v0.2-adjacent slots. Final allocation:
   • SYN-160 enrichment pipeline (BR-13)
   • SYN-161 heuristic + NER linker
   • SYN-162 benchmark corpus + queries
   • SYN-163 benchmark runner + report
   • SYN-164 NerBackend impl (GLiNER multi default + en-only opt-down)
   • SYN-165 (stretch) OpenAI + Voyage EmbeddingBackend impls
   • SYN-166 (stretch) syn search --grade
   • SYN-167 README §Editor integration adoption section
   • Plus the architecture-debt block already at SYN-151..154.
4. ✅ README §Editor integration lands inside v0.5 as SYN-167. Owner explicitly rejected the v0.4.1 parallel-cycle idea. Homebrew tap is out of v0.5 entirely (decision carried to v1.0 backlog SYN-102). Asciinema demo of syn lsp registered for v0.5.1, not in this cycle but mapped.
5. ✅ Six-week window accepted as the upper bound, owner expects earlier delivery.

12. References

• fastembed-rs on crates.io: Rust embedding generation, ONNX-backed.
• Qdrant’s FastEmbed article: design rationale and CPU-first benchmarks.
• Using sqlite-vec in Rust: Alex Garcia: the integration walkthrough.
• Hybrid Search: BM25, Vector & Reranking Reference 2026: 2026 industry baseline.
• An Analysis of Fusion Functions for Hybrid Retrieval, the original convex-combination vs RRF analysis carried forward in 2026 work.
• GraphRAG vs Vector RAG: Knowledge Graph AI Guide 2026, the adaptive RAG framing the brief borrows.
• Best Embedding Model for RAG 2026: Milvus blog: model size + MTEB comparison feeding §2.1.
• Entity Linking and Relationship Extraction With Relik in LlamaIndex: Neo4j Developer blog: small-model NER at ingestion baseline.
• rusqlite discussion #1423: modern_sqlite + vtab with loadable extensions: the sqlite-vec gotcha called out in §2.2.
• v0.4 closure read: docs/researchs/2026-06-02-v0.4-closure-and-roadmap-review.md.
• v0.4 brief: docs/researchs/2026-05-25-v0.4-refinement-and-extensibility.md: pattern this brief follows.
• ADR-013: audit trail (still binds the insertion-time pipeline).
• ADR-015: modular files policy (enforced by SYN-154 lint).
• ADR-018: tower-lsp-server choice (precedent for picking active forks over abandoned upstreams).