✨ feat(glossary): expose exactMatch on glossary types - #72
Merged
Conversation
## Features - Add `exactMatch` to `GlossaryRecord` (required) and to `GlossaryCreateRequest` / `GlossaryUpdateRequest` (optional; the public API defaults it to `true` when omitted) ## Tests - Assert `exactMatch` is read back in `api.glossary.list` - Cover the provided-on-write path in `api.glossary.update` The public glossary endpoint (server-publicapi / PubApiGlossary) always returns exactMatch and accepts it on write; the client was missing it. `lang` is intentionally left as a locale string — that matches the public payload (the numeric langId belongs to the internal API). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
honzabubenik
approved these changes
Aug 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds the
exactMatchfield to the glossary types, which the public API returns and accepts but the client didn't expose:GlossaryRecord.exactMatch: boolean— required (always present in responses)GlossaryCreateRequest.exactMatch?: boolean/GlossaryUpdateRequest.exactMatch?: boolean— optional (the public API defaults it totruewhen omitted)Purely additive — no runtime change, no breaking change (ships as a minor).
Why
Tracked in the in-context-editor's
external-items-and-missing-endpoints.md§10. Verified against the backend source of truth (server-backend/server-publicapi→PubApiGlossary), which carriesexactMatch: Boolean = true.Note on
lang(intentionally unchanged)§10 also claimed
GlossaryRecordTerm.langshould be a numericlangId. That's wrong for this client and was not applied. This client targets the public API (api.localazy.com→server-publicapi/PubApiGlossary), whereterm.langis aString(locale code) — matching the current typing and the public docs. The numeric shape belongs to the internal app API (server-api/Glossary) that product-spa consumes. Changinglangto a number here would break the client against the real payload. The plugin doc has been corrected separately.Tests
api.glossary.listnow assertsexactMatchis read backapi.glossary.updatecovers the provided-on-write serialization pathpnpm run check): format, lint, typecheck, build, test🤖 Generated with Claude Code