citation-evidence/docs/decisions/ADR-0006-selector-ownership-split.md

47 lines
1.8 KiB
Markdown
Raw Normal View History

# ADR-0006 — Selector ownership split (types in engine, algorithms in anchor)
- Status: proposed
- Date: 2026-05-24
- Workplan: CE-WP-0001-T07 (stub); echoes `wiki/SharedContracts.md` §8
## Context
The original sister-repo INTENT files had overlapping ownership claims for
`Selector`: `citation-engine` listed it as an owned domain type, while
`evidence-anchor`'s scope claimed "selector type definitions related to
anchoring". This was resolved on 2026-05-24 in `wiki/SharedContracts.md` §8:
type *interfaces* live in engine (`src/shared/selector.ts`), creation and
resolution *algorithms* live in anchor.
This ADR makes the split formal so that future code reviews have a written
answer when somebody proposes moving the types into anchor or moving the
algorithms into shared.
## Options
- **A. Status quo: types in `shared/`, algorithms in `anchor/`** *(default)*
- Pros: anchor depends on shared (allowed by DependencyMap §4); type
consumers (binder, work) never have to import anchor.
- Cons: tiny risk of types drifting out of sync with what anchor can
actually produce.
- **B. Co-locate types and algorithms in `anchor/`**
- Pros: one home for everything selector-related.
- Cons: any partition that mentions a `Selector` type (which is most of
them) would have to import from `anchor/`. Breaks the
"shared has no internal imports" invariant of DependencyMap §4.
- **C. Split selector kinds: text-quote in shared, PDF-rect in anchor**
- Pros: only adapter-specific selectors leave shared.
- Cons: forces a discriminated union spanning two packages — type
narrowing becomes painful for consumers.
## Decision
(blank — option A is the working assumption codified in SharedContracts.md;
fill this in if a future use case challenges it.)
## Consequences
(blank)