Define the narrow lexicon interface this repo depends on, so FW Lite is one implementation rather than the only one.
Why a port instead of IEntryService
The interlinearizer must work with no FW Lite connection, so it needs to talk to whatever lexicon is available. Typing against the Lexicon extension's IEntryService directly would bake MiniLcm's model (IEntry, ISense, PartialEntry, RichMultiString, ComplexFormComponent, …) into this repo, and any other lexicon would have to implement MiniLcm's tail to be substitutable.
The model only asks four things of a lexicon, so the port is small. There is nothing to un-couple yet: grep "from 'lexicon'" across src/ returns nothing — every lexicon mention today is a comment or a type declaration.
Ask
The port, with interlinearizer-owned DTOs — just enough to render a gloss and pick a sense, not MiniLcm's shape:
The capability descriptor. Providers differ in capability, not just presence: a lexicon without FW Lite will have entries and senses but no allomorphs and no MSAs. Capabilities must be granular enough to gate per affordance — at minimum search, create, allomorphs, MSAs.
The rendering rule. An unavailable capability is not rendered, not rendered-and-disabled. This is what lets tier 0 (no lexicon at all) look exactly like today rather than like a broken version of the lexicon-enabled UI.
Provider resolution, including the null provider. One resolved signal — which provider is active, if any — behind one hook, so no component asks "is FW Lite there" directly.
Non-goals
No adapter, no lexicon calls, no UI. Types, capability model, provider resolution, and the null provider only.
Note
Not blocked on the epic's open question about tier 1's form. The port is the same whether tier 1 is embedded in this extension or a separate stand-alone extension; only createEntry's semantics depend on that answer, which is why it is specified here and implemented elsewhere.
Blocked on
#225 — the ref shape feeds the port types.
Define the narrow lexicon interface this repo depends on, so FW Lite is one implementation rather than the only one.
Why a port instead of
IEntryServiceThe interlinearizer must work with no FW Lite connection, so it needs to talk to whatever lexicon is available. Typing against the Lexicon extension's
IEntryServicedirectly would bake MiniLcm's model (IEntry,ISense,PartialEntry,RichMultiString,ComplexFormComponent, …) into this repo, and any other lexicon would have to implement MiniLcm's tail to be substitutable.The model only asks four things of a lexicon, so the port is small. There is nothing to un-couple yet:
grep "from 'lexicon'"acrosssrc/returns nothing — every lexicon mention today is a comment or a type declaration.Ask
The port, with interlinearizer-owned DTOs — just enough to render a gloss and pick a sense, not MiniLcm's shape:
resolveSense(ref)— ref to displayable glosssearchByForm(form, options)— surface form to candidate sensescreateEntry(draft)— specify now, implement later (Create a lexicon entry from an unglossed morpheme #229)capabilities— what this provider can actually doThe capability descriptor. Providers differ in capability, not just presence: a lexicon without FW Lite will have entries and senses but no allomorphs and no MSAs. Capabilities must be granular enough to gate per affordance — at minimum search, create, allomorphs, MSAs.
The rendering rule. An unavailable capability is not rendered, not rendered-and-disabled. This is what lets tier 0 (no lexicon at all) look exactly like today rather than like a broken version of the lexicon-enabled UI.
Provider resolution, including the null provider. One resolved signal — which provider is active, if any — behind one hook, so no component asks "is FW Lite there" directly.
Non-goals
No adapter, no lexicon calls, no UI. Types, capability model, provider resolution, and the null provider only.
Note
Not blocked on the epic's open question about tier 1's form. The port is the same whether tier 1 is embedded in this extension or a separate stand-alone extension; only
createEntry's semantics depend on that answer, which is why it is specified here and implemented elsewhere.Blocked on
#225 — the ref shape feeds the port types.