Outcome

Implement separate Scala 2 and Scala 3 typed compiler exporters, driven by the
repository's BSP/Zinc build. Use direct SemanticDB ingestion for declarations,
types, annotations, overrides, diagnostics and source hashes, but collect
calls/accesses/construction from the same typed compiler pass rather than
starting a second TASTy analysis.

Current master baseline

No strict Scala provider is registered on current master. scip-java 0.13
removed Scala and Zinc support; the current registry correctly limits it to
Java and Kotlin. Scala therefore uses the ordinary language-server/static lane,
and PR #147 has no strict index-time cell to cite.

Do not resurrect the old scip-java Scala route. The last Scala-capable release
is a historical fallback and would pin the product to a removed pipeline.

What SemanticDB provides—and does not

The SemanticDB specification
is a strong per-source artifact:

• document text/md5, URI, language and build target;
• symbol kinds/properties, structured signatures, annotations and access;
• occurrences, diagnostics and synthetics;
• direct parent declarations and overridden symbols.

Direct protobuf ingestion retains more information than converting to SCIP.
It can prove declarations, containment, types, annotations, direct
extends/implements, overrides, source hashes and diagnostics.

Occurrences do not carry a call/read/write role. SemanticDB alone cannot prove
calls, accesses or instantiates. TASTy can fill Scala 3 after compilation,
but a separate TASTy pass duplicates semantic work and has no Scala 2
equivalent. The fastest common architecture is therefore a typed compiler
plugin that emits those facts during the compilation already producing
SemanticDB.

Decision: two typed plugins, one BSP/Zinc transaction

Scala 2

Build a scalac Global plugin with a phase immediately after typer and before
lowerings erase source-level intent. Walk typed trees once, resolve symbols and
types, and write per-source shards.

Scala 3

Build a Dotty StandardPlugin/PluginPhase after typer, following the official
Scala 3 compiler plugin model.
Walk typed trees before later transformations obscure givens, extension
methods, inline/macro origins and source spans.

Build orchestration

Use BSP to discover exact build targets, sources, scalac options, class
directories and dependency graph, then request compilation. Let Zinc/sbt/Bloop/
Mill determine affected targets and source recompilation. The exporter writes
changed shards into a target-scoped output and an atomic target manifest.

Enable SemanticDB in the same compile as a cross-check and source/diagnostic
input:

• Scala 3: compiler -Xsemanticdb;
• Scala 2: matching semanticdb-scalac, source root/range/text/diagnostic
  options; and
• never run clean merely to force files to re-emit. Existing validated shards
  cover sources Zinc decides are unchanged.

Facts and source semantics

The typed plugins emit:

• packages, classes, traits, objects, enums, opaque/type aliases, methods,
  constructors, fields, parameters, locals, extension methods, givens and
  generated definitions with origin;
• imports, exports and visibility;
• resolved Apply, Select, New, eta-expansion and extension calls;
• read/write accesses and type references;
• direct parents, trait implementations and overridden symbols;
• annotations;
• implicit/given resolution and inline/macro expansion as source-linked
  evidence/unresolved facts; and
• compiler diagnostics from the same target generation.

Do not invent an explicit source span for a synthetic implicit/given insertion.
Use SemanticDB synthetics and compiler origin trees to link the source site and
selected symbol.

Framework tests use a named ScalaTest/MUnit/specs2 enricher. renders is
unsupported unless a framework-specific producer is added.

Identity and target universes

SemanticDB symbols are useful interoperability keys but overload disambiguators
are source-order based. The final graph identity must use:

• BSP build target and module/artifact coordinate;
• fully qualified owner and symbol kind;
• structural signature, including receiver, parameter/type parameter lists and
  result where needed;
• Scala language/compiler major and relevant encoding; and
• source owner/lexical structure for locals and anonymous functions.

Exact fixtures insert/reorder overloads and constructors and compare Scala 2/3
encodings. Same-named symbols in main/test/cross-built targets must not collide.

The universe includes BSP target, Scala compiler and plugin version, platform
and Scala binary version, scalac options, classpath order/content, source roots,
SemanticDB options, compiler plugins, macro/inline dependencies, Zinc analysis
and generated sources. Cross builds are separate universes.

Incremental and performance behavior

• no-op: BSP/build-tool null compile plus manifest validation, or manifest load
  without a producer invocation when inputs prove unchanged;
• body edit: Zinc recompiles affected sources; replace only emitted shards;
• public signature/macro/inline edit: accept Zinc's dependent closure and record
  it;
• target/classpath/scalac/plugin change: invalidate that target universe;
• create/delete/rename: reconcile target source list and delete stale shards;
  and
• failed compile/cancel/crash: retain the prior committed target generation.

Do not call SemanticDB per symbol, do not inspect TASTy in a second cold process,
and do not hold compiler tree/symbol objects after the plugin phase.
Cold overhead is measured against the identical native BSP compile. Resident
latency is bounded by the build server's null/incremental compile plus shard
merge.

Implementation map

1. Add [Bulk index] Replace symbol-by-symbol LSP scans with compiler-owned snapshots #63's protocol and target-scoped shard store.
2. Implement direct SemanticDB protobuf parsing and conformance fixtures.
3. Implement the Scala 2 plugin and exact fixture.
4. Implement the Scala 3 plugin with the same normalized schema.
5. Add BSP discovery/compile/diagnostic integration and Zinc invalidation
   traces.
6. Register the strict provider only when the target's compiler/plugin pair is
   compatible; otherwise decline to Metals/static.

Acceptance

• Scala 2 and Scala 3 have separate fixtures and compatibility matrices.
• Typed-tree extraction proves calls/accesses/construction without a second
  semantic pass.
• SemanticDB md5/build-target/kinds/signatures/annotations/overrides/
  diagnostics are retained and cross-checked.
• Givens/implicits, extensions, inline/macros, opaque types, enums,
  overloads, constructors, generics, locals and tests have exact fixtures.
• Overload insertion/reorder and cross-target twins keep stable identities.
• All 15 fact families have explicit coverage/unresolved rows.
• No-op, body/API/macro edit, create/delete/rename, target/classpath/
  compiler-option/plugin change, diagnostic, cancel, crash and retry are
  atomic.
• Cold overhead is measured against the native BSP compile; no-op/edit
  phases and Zinc invalidation are reported separately.
• Metals/static remain truthful fallbacks; scip-java is not presented as
  Scala-capable.
• Focused tests, Scala experiments, pnpm build, pnpm test, and
  pnpm coverage pass.

Primary references

• SemanticDB specification
• Build Server Protocol
• Scala 2 compiler plugins
• Scala 3 compiler plugins
• Zinc incremental compilation