@rudra-js/core 0.8.1 → 0.8.3

package/README.md

@@ -2,43 +2,67 @@
 
 This package is part of [rudra-js](https://rudrajs.com).
 
-rudra-js is an open-source TypeScript library (MIT) you install from npm. A language model designs one product-recommendation block for a page in your shop, rudra-js checks it against your catalog, and React renders it.
+rudra-js is an open-source TypeScript library (MIT) you install from npm. A
+language model designs one product-recommendation block for a page in your shop,
+rudra-js checks it against your catalog, and React renders it.
 
-It is not a hosted platform, a visual or low-code app builder, or a workspace you sign up for.
+It is not a hosted platform, a visual or low-code app builder, or a workspace
+you sign up for.
 
-You give this package one page view: the shopper and what they've been doing,
-the page they're on, and the products you're willing to show. It gives back a
-specification for the recommendations on that page, written by your model or
-built without one, and checked against those products. There's no React in it.
-`@rudra-js/react` turns the specification into markup.
+You give this package one page view:
 
-Every export of this package is documented at [rudrajs.com](https://rudrajs.com/docs).
+- the shopper and what they've been doing
+- the page they're on
+- the products you're willing to show
+
+It gives back a spec: data that describes the recommendations on that page. Your
+model writes it, or core builds it without one. Either way, it's checked against
+those products. There's no React in this package. `@rudra-js/react` turns the
+spec into markup.
+
+The guides and the API reference are at [rudrajs.com](https://rudrajs.com).
 
 ## Install
 
 ```sh
-npm install @rudra-js/core @rudra-js/attested
+npm install @rudra-js/core@latest @rudra-js/attested@latest
 ```
 
-`zod` is a dependency, so you don't need it yourself. The public API of this
-package _is_ zod schemas, and an app on any zod 4 shares one copy with it. An
-app on zod 3 gets its own copy alongside ours, and the two don't mix: build on
-the exported schemas with their own methods (`productSchema.array()`) rather
-than your zod's (`z.array(productSchema)`), and read `error.issues` rather than
-checking `instanceof ZodError`. `@rudra-js/anthropic`'s own zod writes the tool
-schema we send the model, so its wording shifts a little between releases:
-before 4.5, a nullable field is written as `anyOf` rather than a type array. It
-means the same thing either way.
-
-`@rudra-js/attested` is a peer dependency, even though none of its types cross
-this package's public surface and you never have to import it. It's a peer so
-there is exactly one denylist in your tree. As a real dependency, an app that
-pins its own copy gets two — we checked, and npm 10.9.4 installs the app's
-version at the top and quietly nests ours under `@rudra-js/core` — and the two
-would then disagree about what counts as a claim. As a peer that same pin is an
-`ERESOLVE` you can see and fix. Pin nothing and the tree is identical either
-way: one copy, at the top. One tag publishes every `@rudra-js` package on npm
-at one version, so the ranges here always move together.
+Run the same command in a new app, in an app that already uses rudra-js, and to
+upgrade.
+
+If your app also has `@rudra-js/react` or `@rudra-js/anthropic`, add them to the
+command with `@latest`. Each one's peer range on core covers only its own minor
+release. Leave one behind and npm only warns, but the next `npm install` or
+`npm ci` fails with `ERESOLVE`.
+
+If your app has `@rudra-js/a2ui`, use the install line in that package's README
+instead. It also names the two A2UI packages.
+
+Keep `@latest` on every name. For a bare name, npm stays inside the range your
+`package.json` already has, so an app on an older core never leaves the minor
+release it's on.
+
+`zod` is a dependency, so you don't need to install it yourself. The public API
+of this package _is_ zod schemas. An app on any zod 4 shares one copy of zod
+with it.
+
+An app on zod 3 gets its own copy next to ours, and the two don't mix. Build on
+the exported schemas with their own methods (`productSchema.array()`), not with
+your zod's (`z.array(productSchema)`). Read `error.issues` instead of checking
+`instanceof ZodError`.
+
+`@rudra-js/anthropic` uses its own zod to write the tool schema sent to the
+model, so the schema's wording shifts a little between zod releases. Before zod
+4.5, a nullable field is written as `anyOf` instead of a type array. Both mean
+the same thing.
+
+`@rudra-js/attested` is a peer dependency. None of its types appear in this
+package's public API, and you never have to import it. It's a peer so your app
+has exactly one copy of its phrase list. If your app pins its own version, npm
+stops with an `ERESOLVE` you can see and fix. If you pin nothing, npm installs
+one copy at the top of the tree. One tag publishes every `@rudra-js` package to
+npm at the same version, so these ranges always move together.
 
 ## Running without a model
 
@@ -50,44 +74,46 @@ const generator = createComponentGenerator({ provider: null });
 const spec = await generator.generate(input);
 ```
 
-This is a supported setting, not a stub. It's the control arm of the benchmark,
-and it's the right one until you've settled on a provider. `generate` returns a
-promise either way, so your code keeps its shape when you add one.
+This is a supported setting. The benchmark compares the models against it. It's
+the right setting until you've picked a provider. `generate` returns a promise
+either way, so your code keeps its shape when you add one.
 
-The deterministic component emits exactly one **grid** block, with a headline
-from a fixed set of four, or no blocks at all when there's nothing left to show.
-That happens when no candidate is in stock, and equally when every one of them
-is ruled out for this shopper.
-Every other block kind in the vocabulary (hero, carousel, banner, copy, bundle)
-only ever comes from a model. So if you're wiring up bundles and none of them
-appear, that's why. It isn't your catalog.
+Without a model, core builds the spec itself. The rest of this README calls that
+spec the fallback. It has exactly one **grid** block, with a headline from a
+fixed set of four. It has no blocks at all when there's nothing left to show.
+That happens when no candidate is in stock, and also when every candidate is
+ruled out for this shopper.
 
-Want to render a spec you wrote yourself, still without a model? Pass
-`createFixedSpecProvider(spec)` as the provider and it answers every request with
-that spec. It still goes through reconciliation, so it needs a headline that
-survives screening and at least one product on show, or you get the
-deterministic component.
+The other block kinds (hero, carousel, banner, copy, bundle) only ever come from
+a model. So if you're wiring up bundles and none of them appear, that's why. It
+isn't your catalog.
+
+To render a spec you wrote yourself, still without a model, pass
+`createFixedSpecProvider(spec)` as the provider. It answers every request with
+that spec. Your spec goes through the same checks as a model's, so it needs a
+headline that passes the [claim check](#what-the-host-must-supply) and at least
+one product on show. Otherwise you get the fallback.
 
 ## Options
 
 Everything `createComponentGenerator` takes, and what you get if you leave it
 out.
 
-| Option           | What it does                                                                                    | Default                   |
-| ---------------- | ----------------------------------------------------------------------------------------------- | ------------------------- |
-| `provider`       | The model adapter. `null` runs without a model and bills nothing.                               | `null`                    |
-| `cache`          | Where generated specs live between requests. Pass `createNullSpecCache()` to keep none.         | `createMemorySpecCache()` |
-| `generation`     | `'cohort'` shares one component between shoppers who look alike; `'per-shopper'` does each one. | `'cohort'`                |
-| `rank`           | `'signals'` orders products by the shopper's signals; `'given'` keeps the order you sent.       | `'signals'`               |
-| `modelTimeoutMs` | How long the model gets. Past that, we abort the request and render the deterministic one.      | `1500`                    |
-| `cacheTimeoutMs` | How long a cache read gets. Past that, the request generates as if the store had nothing.       | `50`                      |
-| `onEvent`        | Called once per `generate` with a `GenerationEvent`. If your hook throws, we swallow it.        | none                      |
+| Option           | What it does                                                                                            | Default                   |
+| ---------------- | ------------------------------------------------------------------------------------------------------- | ------------------------- |
+| `provider`       | The model adapter. `null` runs without a model and bills nothing.                                       | `null`                    |
+| `cache`          | Where generated specs live between requests. Pass `createNullSpecCache()` to keep none.                 | `createMemorySpecCache()` |
+| `generation`     | `'cohort'` shares one spec between shoppers who look alike. `'per-shopper'` generates for each shopper. | `'cohort'`                |
+| `rank`           | `'signals'` orders products by the shopper's signals. `'given'` keeps the order you sent.               | `'signals'`               |
+| `modelTimeoutMs` | How long the model gets. After that, core aborts the request and renders the fallback.                  | `1500`                    |
+| `cacheTimeoutMs` | How long a cache read gets. After that, the request generates as if the cache had nothing.              | `50`                      |
+| `onEvent`        | Called once per `generate` with a `GenerationEvent`. If your function throws, core ignores the error.   | none                      |
 
 ## `tracking-input`
 
-The boundary between your application and rudra-js. We collect nothing, store
-nothing, aggregate nothing. You own your tracking pipeline and hand us one JSON
-object per render.
+This is the boundary between your app and rudra-js. You own your tracking
+pipeline and pass one JSON object per render. rudra-js collects nothing and
+stores nothing. It doesn't aggregate anything either.
 
 ```ts
 import { parseTrackingInput } from '@rudra-js/core';
@@ -112,118 +138,128 @@ const input = parseTrackingInput({
 ```
 
 `parseTrackingInput` throws a `ZodError`. If you'd rather not catch,
-`safeParseTrackingInput` hands you a `TrackingInputResult` instead, so you can
+`safeParseTrackingInput` returns a `TrackingInputResult` instead. Then you can
 read `result.error.issues` without importing zod yourself.
 
 ### Cold start is not an error
 
-A payload with no `signals` block is a first-time visitor, not a malformed
-request. Every category defaults to `[]`, so you don't need a special case for
-it.
+A payload with no `signals` block is a first-time visitor. Every signal list
+defaults to `[]`, so you don't need a special case for it.
 
 ### What the host must supply
 
-`user.id`, `context.surface`, and at least one entry in `candidates`. SKUs must
-be unique.
-
-`candidates` is the merchandising boundary. Every SKU the model writes gets
-looked up in that list, and one that isn't on it is dropped by reconciliation
-before anything renders. A product you left out doesn't reach the page.
-
-`bundles` is optional. These are the sets you sell together, each with your own
-price for the set, the currency that price is in, and, if you want one, your own
-name for it. Every product in a set has to be a candidate as well. That's what
-lets the checks that pass a single product run over a whole set, and what lets
-the renderer look the members up in the catalog it already has. Ids must be
-unique, and one set must not name the same product twice.
-
-A set is placed whole, so one check runs differently: a set may hold something
-the shopper already bought or has in the basket, where a grid or a carousel
-would drop it. A thumbs-down on a member still blocks the whole set, and so does
-a member that is out of stock, already on the page, or the product being looked
-at right now.
-
-That last one has a cost. A "frequently bought together, including this item"
-set names the product whose page it sits on, so it is refused on exactly the
-page you wrote it for. Leave the item out and sell the companions as the set —
-that rejection goes away, and the rest of the checks still apply. And when a
-bundle block is the only block the model asked for, refusing the set leaves
-nothing to render, so the deterministic component takes over.
-
-The model _never_ picks a set and is never told a price. All it does is ask for a
-bundle block and write the words around it. We pick which set when the page is
-served, going on what the shopper has in their basket, has looked at, or is
-browsing right now.
-
-Every word the model writes is read for claims: the headline, the subheadline, a
-hero, a banner, a block title, the copy block, the reason under a product, and
-the words around the set. Text you supplied is never read this way. A product
-title, a category and a bundle `label` are your words, not the model's.
-
-We drop text that makes a claim we can't check, in three passes. The first looks
-for money, a customer score, a delivery date and a count of what's left. The
-second asks whether every numeral in the sentence is one you supplied. The third
-is `@rudra-js/attested`'s phrase list, for claims with no number in them to
-check — "top pick", "customer favourite".
-
-That second pass changed what happens to a specification. "a comfort rating of
--5C" used to be kept on the strength of the words around the number. It is kept
-now only when a `5` turns up in a `tag` or a `category` name you sent us — the
-number, not the string, so a tag reading `5-pocket` keeps it as surely as one
-reading `-5C comfort`. Those are the strings we hand the model and let it repeat.
-A `title` and a `rating` we also show it, and the prompt tells it never to
-restate either, so neither stands behind a number. Put your spec sheet in `tags`
-and the model can quote it; leave it out and a number in that field is one the
-model made up, and it goes.
-
-Which strings, exactly:
-
-- Only candidates we showed the model. Out of stock, or past the 60 we send,
-  means a product the model never saw, and its tags stand behind nothing.
-- The `currentCategory` on the request is not one of them. It's a string from
-  this request rather than a row of your catalog, and plenty of sites pass a URL
-  segment straight into it.
+Send `user.id`, `context.surface` and at least one entry in `candidates`. SKUs
+must be unique.
+
+`candidates` sets which products can reach the page. Core looks up every SKU the
+model writes in that list. A SKU that isn't on it is dropped before anything
+renders.
+
+`bundles` is optional. These are the sets you sell together. Each one has your
+own price for the set and the currency that price is in. It can also have your
+own name for the set, its `label`. Every product in a set has to be a candidate
+as well. Bundle ids must be unique, and one set must not name the same product
+twice.
+
+A set is placed whole, so one check works differently. A set may hold something
+the shopper already bought or has in the basket. A grid or a carousel would drop
+that product. The whole set is still blocked when any member is:
+
+- disliked by the shopper
+- out of stock
+- already on the page
+- the product being looked at right now
+
+That last rule has a cost. A "frequently bought together, including this item"
+set names the product whose page it sits on, so it's refused on exactly the page
+you wrote it for. Leave that item out and sell its companions as the set. That
+rejection goes away, and the other checks still apply.
+
+When a bundle block is the only block the model asked for, refusing the set
+leaves nothing to render. Then the fallback takes over.
+
+The model _never_ picks a set and is never told a price. All it does is ask for
+a bundle block and write the words around it. Core picks which set when the page
+is served. It bases the choice on what the shopper has in their basket, has
+looked at, or is browsing right now.
+
+The prompt tells the model to write about the offer, not the products in it. It
+also tells the model never to say the set saves money, or by how much. Your
+`label`, when you pass one, renders ahead of the model's words.
+
+Core reads every word the model writes for claims:
+
+- the headline and the subheadline
+- a hero
+- a banner
+- a block title
+- the copy block
+- the reason under a product
+- the words around the set
+
+Text you supplied is never read this way. A product title, a category and a
+bundle `label` are your words.
+
+Core drops text that makes a claim it can't check. This README calls that the
+claim check. It runs in three passes:
+
+1. The first looks for money, a customer score, a delivery date and a count of
+   what's left.
+2. The second asks whether every numeral in the sentence is one you supplied.
+3. The third is `@rudra-js/attested`'s phrase list. It catches claims with no
+   number in them to check, like "top pick" and "customer favourite".
+
+For example, the second pass keeps "a comfort rating of -5C" only when a `5`
+turns up in a `tag` or a `category` name you sent. The pass compares the number,
+not the string, so a tag reading `5-pocket` keeps it as surely as one reading
+`-5C comfort`.
+
+Tags and category names count because they're the strings core hands the model
+and lets it repeat. The model is also shown each product's `title` and `rating`.
+Neither one backs a number, because the prompt tells it never to restate either.
+Put your product's figures in `tags` and the model can quote them. Leave them
+out, and any figure the model writes about them is made up, so it's dropped.
+
+Which strings count, exactly:
+
+- Only candidates the model was shown. A product that's out of stock, or past
+  the 60 core sends, is one the model never saw. Its tags back nothing.
+- Not the `currentCategory` on the request. It's a string from this request, not
+  a row of your catalog, and plenty of sites pass a URL segment straight into
+  it.
 - A `reason` or a `badge` sits under a named product, so it's read against that
-  product's own tags and category. Every other field reads all the candidates'
-  pooled.
-
-Two caveats worth saying out loud, because they're the shape of the check rather
-than bugs in it. Pooled means pooled: one product's `40 litre` tag stands behind
-"take 40 off" written in a headline about another. And nothing in the pass knows
-which quantity a tag was about, so a tag holding a weight stands behind a price
-with the same digits in it. It proves the digits came from you. It doesn't prove
-the sentence is true.
-
-The first and third passes are word lists, so spotting a claim isn't a
-guarantee, not the way checking a price against your catalog is. The second is a
-proof of something narrower than it sounds: every digit was one of yours. A
-number written as a word isn't a number to it, so "four and a half stars" is not
-a rating it can see — while a ½ or the K in "10K" is a numeral it can't read,
-which it drops rather than waves through.
+  product's own tags and category. Every other field is read against all the
+  candidates' tags and categories, pooled.
+
+Two things to know about the second pass. Pooled means pooled: one product's
+`40 litre` tag backs "take 40 off" written in a headline about another. And
+nothing in the pass knows which quantity a tag was about, so a tag holding a
+weight backs a price with the same digits in it. The pass proves the digits came
+from you. It doesn't prove the sentence is true.
+
+The first and third passes are word lists. A word list can miss a claim, so it
+isn't a guarantee the way checking a price against your catalog is. The second
+pass proves something narrower than it sounds: every digit was one of yours. A
+number written as a word isn't a number to it, so it can't see "four and a half
+stars" as a rating. A ½, or the K in "10K", is a numeral it can't read. It drops
+those instead of letting them through.
 
 The model isn't told any of this. The prompt bans prices, ratings, discounts,
-delivery dates and stock levels, and says nothing about digits, so it can't tell
-`3-season` — a tag you sent, and fine — from `2 litres`, which is not. Whatever
-the over-rejection rate is on your catalog, nothing in the prompt is steering it
-down yet.
-
-Some fields can't be empty, like a headline or a banner's text. Those get emptied
-instead of nulled, so the block drops the way any block with no text drops. And
-an emptied page headline makes the whole generation unusable.
-
-That last one is the expensive edge of the digit check, so it's worth being
-concrete: if the model writes "Our 3 favourites for wet weather" and no candidate
-carries a 3, the headline empties, the generation is unusable, and the
-deterministic component renders — a model call paid for and thrown away. In
-cohort mode the spec is cached before reconciliation, so every cache hit for the
-rest of the TTL runs the same screen and reaches the same fallback. The reason a
-`reason` under a card is exempt is the same idea from the other side: in cohort
-mode we wrote that sentence, so reading it back would only ever cost us.
-
-For the set, the prompt also tells the model to write about the offer rather than
-the products in it, and never to say the set saves money or by how much. Pass a
-`label` on the bundle to put your own words on the set. A label is text you
-wrote, not text the model wrote, so it renders ahead of the model's words.
+delivery dates and stock levels. It says nothing about digits. So the model
+can't tell `3-season`, a tag you sent and fine to use, from `2 litres`, which
+isn't. However much good text the check drops on your catalog, nothing in the
+prompt brings that down.
+
+Some fields can't be null, like a headline or a banner's text. When the check
+drops text from one of those, it empties the field instead. The block then
+drops, as any block with no text does. An empty page headline makes the whole
+generation unusable.
+
+That's the costly case. Say the model writes "Our 3 favourites for wet weather"
+and no candidate carries a 3. The headline empties, so the generation is
+unusable and the fallback renders. You paid for a model call and threw it away.
+In cohort mode the spec is cached before it's checked, so every cache hit runs
+the same check and gets the same fallback until the entry expires.
 
 ### Defaults
 
@@ -242,52 +278,70 @@ wrote, not text the model wrote, so it renders ahead of the model's words.
 | `mostViewed[].views`       | `1`                 |
 | `lastPurchased[].quantity` | `1`                 |
 
-`context.locale` has to be a single language tag, such as `en-US`. One tag. Not a
-list, and not an `Accept-Language` header.
+`context.locale` has to be one language tag, such as `en-US`. Not a list, and
+not an `Accept-Language` header.
 
 ### Cohorts
 
-By default one generated component is shared between shoppers who look alike,
-and each shopper's own products are filled in per request. A cohort is the
-shopper's segment, the surface and slot, the locale, the item count, whether
-they have any history, the category being browsed, and the category they lean
-towards. Who they are, what they searched for and the products they liked or
-viewed stay out of it. For the shared cohort we work out only two things from
-their own data: the category they lean towards and whether they have any
-history. That's what lets many page views reuse one call.
+By default, shoppers who look alike share one generated spec. Each shopper's own
+products are filled in per request. A group of look-alike shoppers is a cohort.
+A cohort is set by:
+
+- the shopper's segment
+- the surface and the slot
+- the locale
+- the item count
+- whether they have any history
+- the category being browsed
+- the category they lean towards
+
+Only two of these come from the shopper's own data: whether they have any
+history, and the category they lean towards. Who they are, what they searched
+for and the products they liked or viewed stay out. That's what lets many page
+views reuse one model call.
 
-The candidate list is part of the cohort too, since the model is shown those
+The candidate list is part of the cohort too, because the model is shown those
 products and writes about them. In most shops candidates come from the page, so
-everyone looking at it shares them. If you pick candidates per shopper you'll get
-smaller cohorts. That's the honest outcome, because your prompt really is
-personal.
-
-What goes in the key is the _set_ of candidate SKUs. Not the order you sent them
-in, not which ones were in stock, and not where the 60-product cut fell. So two
-requests carrying the same SKUs in a different order share one component, and the
-one generated first is the one both get. If your ranking is personal, order your
-candidates and the products in the copy won't be the ones you put at the top.
-Prices, titles and stock are always read from your catalog at render time, so
-nothing stale is ever shown — a product that sold out is dropped as the page is
-served, and any sentence written about it stays.
+everyone looking at it shares them. If you pick candidates per shopper, you'll
+get smaller cohorts, because each prompt really is personal.
+
+The cache key for a cohort holds the _set_ of candidate SKUs. It ignores the
+order you sent them in, which ones were in stock, and where the 60-product cut
+fell. So two requests with the same SKUs in a different order share one spec,
+and both get the one generated first. If your ranking is personal and you order
+your candidates per shopper, the products the copy talks about won't be the ones
+you put at the top.
+
+Prices, titles and stock are always read from your catalog at render time, so a
+stale one never shows. A product that sold out is dropped as the page is served.
+Any sentence the model wrote about it stays.
 
 #### Who can create a cohort
 
-Every field above is one you supply, and each distinct value is a cohort of its
-own — a fresh model call, and a slot in the cache. If a visitor can choose one of
-them, a visitor can choose how many calls you pay for. A `locale` copied straight
-out of `Accept-Language`, a `currentCategory` read off a URL slug and a `segment`
-built from a query parameter are the three that go wrong. The shipped cache holds
-10,000 entries and drops the oldest, so enough made-up values also evict the
-cohorts your real shoppers were being served from.
+Every cohort field above is one you supply, and each distinct value makes a
+cohort of its own. That's a fresh model call, and a slot in the cache. If a
+visitor can choose one of these values, a visitor can choose how many calls you
+pay for. These are the three that go wrong:
+
+- a `locale` copied straight out of `Accept-Language`
+- a `currentCategory` read off a URL slug
+- a `segment` built from a query parameter
 
-Draw those fields from sets you control: your own locale list, your own category
-ids, your own segment labels. Nothing leaks either way — a cohort prompt carries
-no shopper text at all — the cost is the bill and the model round trip on a page
-that was being served from cache.
+The built-in cache holds 10,000 entries, so once it's full, made-up values push
+out the cohorts your real shoppers were being served from.
 
-Pass `generation: 'per-shopper'` to generate for the individual instead. The
-model then chooses the products too, and every shopper pays for their own call.
+Draw those fields from sets you control:
+
+- your own locale list
+- your own category ids
+- your own segment labels
+
+Nothing leaks either way, because a cohort prompt carries no shopper text at
+all. The cost is the bill, plus a model round trip on a page that was being
+served from cache.
+
+Pass `generation: 'per-shopper'` to generate for each shopper instead. The model
+then picks the products too, and every shopper costs their own call.
 
 ```ts
 createComponentGenerator({ provider, generation: 'per-shopper' });
@@ -295,23 +349,30 @@ createComponentGenerator({ provider, generation: 'per-shopper' });
 
 #### What you put in `segment`
 
-`segment` is sent to the model exactly as you wrote it, in both modes, and the
-contract takes any string up to 128 characters. Stick to plain merchandising
-labels like `lapsed`, `high-value`, `trial`, `wholesale`. Keep out anything that
-says something protected about a person: health, race, ethnic origin, religion or
-belief, sex life or sexual orientation, politics, union membership, biometric or
-genetic data.
+`segment` goes to the model exactly as you wrote it, in both modes. The schema
+takes any string up to 128 characters. Stick to plain merchandising labels like
+`lapsed`, `high-value`, `trial` or `wholesale`. Keep out anything that says
+something protected about a person:
+
+- health
+- race
+- ethnic origin
+- religion or belief
+- sex life or sexual orientation
+- politics
+- union membership
+- biometric or genetic data
 
 The same goes for `recentSearches`, `context.searchQuery` and `interaction.type`
-in per-shopper mode. Those three are shopper text and they're sent as written.
-What a shopper types is theirs. What you label them with is your choice.
+in per-shopper mode. Those three are shopper text, and they're sent as written.
+What a shopper types belongs to them. The label you give them is your choice.
 
 ### Limits
 
-Every free-text field and every array is capped, because your strings end up
-inside a model prompt and a model is billed per token. The caps live in
-`FIELD_LIMITS` and we export them, so you can validate against the same numbers
-instead of finding them out from a rejection.
+Every free-text field and every array has a cap, because your strings end up
+inside a model prompt and you pay for a model per token. The caps live in
+`FIELD_LIMITS`, which is exported. Validate against the same numbers instead of
+finding them out from a rejection.
 
 | Limit                | Value | Applies to                                                          |
 | -------------------- | ----- | ------------------------------------------------------------------- |
@@ -329,46 +390,64 @@ instead of finding them out from a rejection.
 | `maxItems`           | 12    | `context.maxItems`, which also needs at least 1                     |
 | `reason`             | 120   | `candidates[].reason`, your own phrase for a product                |
 
-These bound each field on its own. They aren't an aggregate prompt budget.
-Fitting a payload into a context window is `digest`'s job, and it trims rather
-than throws.
+Each cap bounds one field on its own. Together they aren't a budget for the
+whole prompt. Fitting a payload into a context window is the digest's job. The
+digest is core's short summary of the shopper and the page, which goes into the
+prompt. It trims instead of throwing.
 
 ### Unknown fields are rejected
 
-Every fixed-shape object is a `strictObject`. Misspell `recentSearches` and
-you'll get an error, not a shopper who quietly looks like a first-time visitor.
-`interaction.meta` is the one dynamic shape: an open record, minus the keys that
-would mutate a prototype instead of the object.
+Every fixed-shape object is a `strictObject`. Misspell `recentSearches` and you
+get an error, instead of a shopper who quietly looks like a first-time visitor.
+`interaction.meta` is the one open shape. It takes any key, except the keys that
+would change a prototype instead of the object.
 
 ## Bringing your own ranking
 
-By default we order the products for you, scoring each candidate against the
-shopper's signals. But you might already have a recommender you trust: bought
-together, an engine trained on your own orders, or a merchandiser's hand-picked
-row. Pass `rank: 'given'` and the order you sent is the order that renders.
+By default core orders the products for you. It scores each candidate against
+the shopper's signals. You might already have a recommender you trust:
+
+- bought-together data
+- an engine trained on your own orders
+- a merchandiser's hand-picked row
+
+Pass `rank: 'given'` and the order you sent is the order that renders.
 
 ```ts
 const generator = createComponentGenerator({ provider, rank: 'given' });
 ```
 
-You keep the rest either way. We still drop anything the shopper shouldn't be
-shown, whether it's out of stock, already bought, in the basket, disliked, or
-the product they're looking at right now — read from the payload you sent, not
-from the shortened history the model was shown, so a shopper with a long order
-book is covered too. Every product still carries a basis we check against their
-real signals, and everything the model writes is still screened.
-
-How much each basis proves is worth knowing, because two of the six prove less
-than they read. `most_viewed` is checked against the SKUs they viewed,
-`similar_to_current` against the category being browsed, `liked_category`
-against the categories they bought, liked, carted or viewed in — standing on a
-category page is not one of those — and `popular` claims nothing.
-`complements_cart` and `complements_purchase` check only that the basket, or the
-order history, isn't empty: nothing here can know that one product goes with
-another. A basis that fails takes the sentence and the badge stating it with it.
+You keep the other checks either way. Core still drops anything the shopper
+shouldn't be shown:
+
+- out of stock
+- already bought
+- in the basket
+- disliked
+- the product they're looking at right now
+
+Core reads these from the payload you sent, not from the shorter history the
+model was shown. So a shopper with a long order history is covered too. Every
+product still carries a basis, a code like `most_viewed` that says why it's
+shown, and core checks it against the shopper's real signals. Everything the
+model writes still goes through the claim check.
+
+There are six bases, and two of them prove less than their names suggest:
+
+- `most_viewed` is checked against the SKUs they viewed.
+- `similar_to_current` is checked against the category being browsed.
+- `liked_category` is checked against the categories they bought, liked, carted
+  or viewed in. Standing on a category page isn't one of those.
+- `popular` claims nothing.
+- `complements_cart` checks only that the basket isn't empty.
+- `complements_purchase` checks only that the order history isn't empty.
+
+The two `complements_` bases are the weak ones, because nothing here can know
+that one product goes with another. A basis that fails takes the sentence and
+the badge stating it with it.
 
 Each candidate can carry its own `reason`, the phrase shown under the product.
-Reach for it when your ranking knows something the signals don't:
+Use it when your ranking knows something the signals don't:
 
 ```ts
 candidates: [
@@ -382,18 +461,16 @@ candidates: [
 ];
 ```
 
-A reason you supply is your own words, like the title, so it is rendered as
-written and not screened. That only applies where this request actually used it,
-which is the default `cohort` mode. In `per-shopper` mode the model writes the
-reasons itself, so every one of them is screened, including one that happens to
-read the same as yours.
+A reason you supply is your own words, like the title, so it renders as written
+and skips the claim check. That only applies where this request actually used
+it, which is the default `cohort` mode. In `per-shopper` mode the model writes
+the reasons itself. Every one of them goes through the claim check, even one
+that reads the same as yours.
 
-Without a reason of your own, the basis is stated for you from the shopper's
-signals — "More in Backpacks", "Goes with what is in your cart". Those are our
-words, not the model's, so in `cohort` mode they aren't screened either. They
-used to be, and a shop with a category called Clearance or Last Chance would
-have watched the phrase list delete the reason under every card while the
-deterministic component printed the same sentence untouched.
+Without a reason of your own, core states the basis for you from the shopper's
+signals, like "More in Backpacks" or "Goes with what is in your cart". Those are
+core's words, not the model's, so in `cohort` mode they skip the claim check
+too.
 
 ## What the model sees
 
@@ -405,13 +482,12 @@ The two generation modes send different things. Cohort is the default.
 - the locale
 - the segment, when you set one
 - the category being browsed (`context.currentCategory`)
-- the name of the category the shopper leans towards most. Just the name, the
-  score stays behind
+- the name of the category the shopper leans towards most, without its score
 - whether this shopper has no history at all, meaning no likes, dislikes,
   purchases, basket items or views. Searches and other interactions don't count
-- how many products the component may place (`context.maxItems`)
-- the candidate list: one line per product, with its SKU, title, category, rating
-  and tags
+- how many products the spec may place (`context.maxItems`)
+- the candidate list: one line per product, with its SKU, title, category,
+  rating and tags
 
 ### Per-shopper mode
 
@@ -430,25 +506,24 @@ Everything above, and:
 ### Left out of both
 
 - `user.id`
-- every timestamp (`at`), which we use to sort signals and then drop
-- dwell time (`dwellMs`), added up in the digest and left out of the prompt
+- every timestamp (`at`). Core uses them to sort signals, then drops them
+- dwell time (`dwellMs`). It's added up in the digest and left out of the prompt
 - every price, and every currency
 - `imageUrl`
 - `interaction.value` and `interaction.meta`. The model is told which kinds of
   interaction happened and how often, and no more
 
-The candidate list is trimmed on the way out. An out-of-stock product is dropped,
-and at most 60 products go, in the order you supplied them.
+The candidate list is trimmed before it's sent. Out-of-stock products are
+dropped, and at most 60 products go, in the order you supplied them.
 
-`spec-cache.test.ts` walks every field of the digest and checks that each one is
-either in the cohort key or scrubbed from the cohort prompt. A field the key
-leaves out that still changes the prompt fails that test. Adding a field to the
-digest fails it too, until someone says which side the field is on.
+`spec-cache.test.ts` walks every field of the digest. It checks that each one is
+either in the cache key or removed from the cohort prompt. A field the key
+leaves out that still changes the prompt fails that test. A new field added to
+the digest fails it too, until someone says which side the field is on.
 
 ## What the model decides, by mode
 
-What the model wrote, and what we replace before the page is served. Cohort is
-the default.
+What the model wrote, and what core replaces before the page is served.
 
 | Decision                           | Cohort, the default                     | Per-shopper                            |
 | ---------------------------------- | --------------------------------------- | -------------------------------------- |
@@ -461,15 +536,16 @@ the default.
 | Which bundle, of the ones you pass | Chosen per request, not by the model    | Chosen per request, not by the model   |
 
 In cohort mode the grid and carousel items are filled in per request, best pick
-first, so a component written for one shopper still fits the next.
+first, so a spec written for one shopper still fits the next.
 
 The hero is the exception. It keeps the product the model named, because its
-headline and body were written about that product, and swapping it would leave
-copy about something else. When that product can't be placed, reconciliation
-drops the link and keeps the words. It can't be placed if this
-shopper can't see it (out of stock, not a candidate, disliked, already bought, in
-the basket, or the one being looked at), an earlier block already placed it, or
-the item budget ran out before the hero was reached.
+headline and body were written about that product. When that product can't be
+placed, core drops the link and keeps the words. It can't be placed when:
+
+- this shopper can't see it: it's out of stock, not a candidate, disliked,
+  already bought, in the basket, or the one being looked at
+- an earlier block already placed it
+- the item budget ran out before the hero was reached
 
 ## Any provider
 
@@ -485,33 +561,36 @@ export interface ComponentProvider {
 }
 ```
 
-`createComponentGenerator({ provider })` takes any object of that shape: a hosted
-API, a model you run yourself, a deployment inside your own tenancy, or a
-recorded fixture. `@rudra-js/core` depends on no vendor SDK.
-`@rudra-js/anthropic` is one adapter, not a requirement, and `provider: null` is
-the default that costs nothing.
+`createComponentGenerator({ provider })` takes any object of that shape. That
+can be a hosted API, a model you run yourself, a deployment inside your own
+tenancy, or a recorded fixture. `@rudra-js/core` depends on no vendor SDK.
+`@rudra-js/anthropic` is one adapter, and you don't need it.
 
 An adapter takes its API key as an option, so you choose where the key comes
-from. `ANTHROPIC_API_KEY` is just the name the example shop uses for its own
-convenience. No package here reads the environment.
+from. `ANTHROPIC_API_KEY` is just the name the example shop uses. No package
+here reads the environment.
 
 ## The cache
 
-`cache` defaults to an in-process store. `createMemorySpecCache()` keeps an entry
-for `ttlMs`, 60,000 milliseconds by default, so one minute. It holds up to
-`maxEntries`, 10,000 by default. Once it's full, the entry read longest ago is
-the first to go.
-
-An entry holds the generated spec, as the model returned it before screening,
-and `generatedAt`, the epoch milliseconds when the model produced it. No payload
-and no prompt. In cohort mode it holds no shopper id and everyone in the cohort
-shares it, unless its segment or candidates were picked for one shopper. In
-per-shopper mode the model wrote it from that shopper's signals, so its text can
-repeat them, a search term for instance, and the entry is personal data until it
-goes. Expiry is checked when an entry is read, so an expired one stays in memory
+By default `cache` is an in-process store. `createMemorySpecCache()` keeps an
+entry for `ttlMs`, which defaults to 60,000 milliseconds, so one minute. It
+holds up to `maxEntries`, which defaults to 10,000. Once it's full, the entry
+read longest ago is the first to go.
+
+An entry holds the generated spec, as the model returned it before any checks.
+It also holds `generatedAt`, the epoch milliseconds when the model produced it.
+It holds no payload and no prompt.
+
+In cohort mode an entry holds no shopper id, and everyone in the cohort shares
+it. The exception is an entry whose segment or candidates were picked for one
+shopper. In per-shopper mode the model wrote the entry from that shopper's
+signals. So its text can repeat them, a search term for instance, and the entry
+is personal data until it's gone.
+
+Expiry is checked when an entry is read, so an expired entry stays in memory
 until it's read again or pushed out by a newer one.
 
-The port is two methods, and an optional third:
+The cache interface is two methods, and an optional third:
 
 ```ts
 export interface SpecCache {
@@ -521,125 +600,139 @@ export interface SpecCache {
 }
 ```
 
-Pass your own store, whether that's Redis, Memcached or whatever you already run,
-and it keeps entries on its own terms. Just keep in mind that what that store
-holds, and for how long, is yours to declare to your users. This package doesn't
-set it. Pass `createNullSpecCache()` to store nothing at all.
+Pass your own store, whether that's Redis, Memcached or whatever you already
+run, and it keeps entries on its own terms. What that store holds, and for how
+long, is yours to declare to your users. This package doesn't set it. Pass
+`createNullSpecCache()` to store nothing at all.
 
 ### When a generation is wrong
 
-Pass `provider: null` and nothing new is generated, so every page renders the
-deterministic component. Shorten `ttlMs` and a bad entry ends sooner. A store
-with `delete` can drop one entry by the `key` on its `GenerationEvent`, and the
-next request generates again. Per-shopper entries only end by TTL, because
-nothing maps a shopper to their keys.
+- Pass `provider: null` and nothing new is generated, so every page renders the
+  fallback.
+- Shorten `ttlMs` and a bad entry ends sooner.
+- If your store has `delete`, drop one entry by the `key` on its
+  `GenerationEvent`. The next request generates again.
+
+Per-shopper entries only end when they expire, because nothing maps a shopper to
+their keys.
 
 ## Watching it in production
 
 The generator never fails a render, so a provider that's been down for a week
-only shows as plainer pages. The way to know is `onEvent`: every call to
-`generate` that gets past input validation reports exactly one `GenerationEvent`.
-A payload that fails `parseTrackingInput` throws instead, and reports nothing.
+only shows up as plainer pages. Watch `onEvent` to find out. Every call to
+`generate` that gets past input validation reports exactly one
+`GenerationEvent`. A payload that fails `parseTrackingInput` throws instead, and
+reports nothing.
 
-These are the numbers worth keeping:
+Keep these numbers:
 
-- **Fallback share** — the share of events with `source: 'fallback'`. Alert when
-  it climbs. `degradedReason` tells you which way the call failed, and `error`
-  carries what was thrown when the reason is `'provider-error'` or `'timeout'`.
-- **Cache hit rate** — `cache: 'hit'` over the events that have a `cache` field.
+- **Fallback share.** The share of events with `source: 'fallback'`. Alert when
+  it climbs. `degradedReason` tells you which way the call failed. When the
+  reason is `'provider-error'` or `'timeout'`, `error` carries what was thrown.
+- **Cache hit rate.** `cache: 'hit'` over the events that have a `cache` field.
   A store that's down shows as `cache: 'error'`, and a slow one as
-  `cache: 'timeout'`, rather than as a rising bill.
-- **Spend** — sum `usage` over the events where `calledModel` is true. Requests
-  that joined an in-flight generation carry the same `usage`, so summing over
-  every event counts one call many times. A call the model answered but the
-  adapter turned down (a `max_tokens` stop, a refusal, no tool call, or a reply
-  that doesn't fit the schema) was billed too, and arrives as a
+  `cache: 'timeout'`. So a broken store shows up here, not only as a rising
+  bill.
+- **Spend.** Sum `usage` over the events where `calledModel` is true. Requests
+  that joined a generation already in flight carry the same `usage`, so summing
+  over every event counts one call many times. Some calls the model answered are
+  turned down by the adapter: a `max_tokens` stop, a refusal, no tool call, or a
+  reply that doesn't fit the schema. Those were billed too. They arrive as a
   `'provider-error'` with no `usage`, so this sum is lower than your bill.
 
 ## Running it in a regulated shop
 
-This isn't legal advice, and which rules apply depends on where you sell. It's
-what the package does, so you can answer what a privacy or consumer-law review
-will ask.
+This isn't legal advice, and which rules apply depends on where you sell. It
+describes what the package does, so you can answer what a privacy or
+consumer-law review will ask.
 
 **What leaves your server.** Nothing, unless you pass a `provider`, or a `cache`
 whose store lives somewhere else. With a provider, cohort mode sends the page
 and locale, the category, the segment you set, the shopper's strongest category,
-whether they have any history, and the candidate products. There's no shopper id
-in it, but it can still be personal data: the strongest category and the history
-flag come from that shopper's data, the segment goes exactly as you wrote it,
-and the candidate list is about them too if you pick or order it per shopper.
-Per-shopper mode adds the shopper's own signals. Both lists are under [What the
-model sees](#what-the-model-sees). `user.id` is never sent in either mode. The
-provider should be your processor, under a contract that says so; for Anthropic,
-see the `@rudra-js/anthropic` README.
+whether they have any history, and the candidate products. That has no shopper
+id, but it can still be personal data. The strongest category and the history
+flag come from that shopper's data. The segment goes exactly as you wrote it.
+The candidate list is about them too if you pick or order it per shopper.
+Per-shopper mode adds the shopper's own signals. Both lists are under
+[What the model sees](#what-the-model-sees). `user.id` is never sent in either
+mode. The provider should be your processor, under a contract that says so. For
+Anthropic, see the `@rudra-js/anthropic` README.
 
 **A shopper who objects to profiling.** Leave `signals` and `user.segment` out
-of their payload, and in per-shopper mode `context.searchQuery` and
-`user.isReturning` too. They get the cold-start component, built from the page
-and the catalog, not from them. With those left out, `generateDeterministic(input)`
-gives the same kind of component without calling the model or the cache. Called
-with signals, it still personalises.
+of their payload. In per-shopper mode, leave out `context.searchQuery` and
+`user.isReturning` too. They get what a first-time visitor gets, built from the
+page and the catalog, not from them. With those left out,
+`generateDeterministic(input)` gives the same kind of spec without calling the
+model or the cache. Called with signals, it still personalises.
 
 **Deleting a shopper's data.** The package keeps nothing about a shopper except
 the cache. In cohort mode an entry holds no shopper id and everyone in the
 cohort shares it, so usually there's no one shopper's entry to delete. The
 exception is a cohort entry whose segment or candidate list was picked for one
-shopper: like every per-shopper entry, it's about that shopper. Nothing maps a
+shopper. Like every per-shopper entry, it's about that shopper. Nothing maps a
 shopper to their entries, so keep `ttlMs` short or pass `createNullSpecCache()`.
-`onEvent` sends no shopper id, but in per-shopper mode its `key` is derived from
-one, and `violations` can name SKUs from a shopper's basket or purchases, so
+`onEvent` sends no shopper id. But in per-shopper mode its `key` is derived from
+one, and `violations` can name SKUs from a shopper's basket or purchases. So
 treat logs of it as personal data.
 
-**Caching pages.** A personalised page says things like "Goes with your cart" and
-"You looked at this recently" in its HTML. Serve those pages with
+**Caching pages.** A personalised page says things like "Goes with your cart"
+and "You looked at this recently" in its HTML. Serve those pages with
 `Cache-Control: private` or `no-store`, so a shared cache never hands one
 shopper's page to another.
 
 **Telling shoppers a model wrote the copy.** The wrapper's `data-rudra-source`
-says `llm` or `cache` when a model wrote the copy and `fallback` when it didn't,
-so it's a machine-readable marker you can build on, for example to show a note.
-Whether you must label AI-written copy, and how, depends on where you sell; in
-the EU, Article 50 of the AI Act is the rule to ask about.
+says `llm` or `cache` when a model wrote the copy, and `fallback` when it
+didn't. That makes it a machine-readable marker you can build on, for example
+to show a note. Whether you must label AI-written copy, and how, depends on
+where you sell. In the EU, Article 50 of the AI Act is the rule to ask about.
 
 **Claims.** The copy on your page is your own advertising, whoever wrote it. The
-screen catches prices, discounts, stock, ratings, delivery, urgency and generic
-environmental claims, but it's a list, and rewordings get through (SECURITY.md
-explains why, and the tests list the known ones). Anything it misses is still
-yours to stand behind.
+claim check catches prices, discounts, stock, ratings, delivery, urgency and
+generic environmental claims. But it's a list, and rewordings get through.
+SECURITY.md explains why, and the tests list the known ones. Anything it misses
+is still yours to stand behind.
 
 **Children.** In the UK, the ICO's Children's Code covers any shop that
 under-18s are more likely than not to use, not only one aimed at them. Its
 standard 12 asks for profiling to be off by default unless you can show a
-compelling reason, judged by the child's best interests, and for safeguards when
-it's on. For a shop like that, don't use per-shopper mode. For a shopper under
-18, leave `signals` and `user.segment` out of their payload unless they've
-switched personalisation on, as for a shopper who objects to profiling. If you
-can't tell a shopper's age with confidence that fits the risk, treat every
-shopper as under 18. Cohort mode alone doesn't turn profiling off: the default
-`rank: 'signals'` still orders products by the shopper's signals in cohort mode
-and in the fallback component, even with no provider, and cohort mode still
-sends their strongest category, whether they have any history, and any segment
-to the model.
+compelling reason, judged by the child's best interests. It also asks for
+safeguards when profiling is on. For a shop like that, don't use per-shopper
+mode. For a shopper under 18, leave `signals` and `user.segment` out of their
+payload unless they've switched personalisation on, as for a shopper who objects
+to profiling. If you can't tell a shopper's age with confidence that fits the
+risk, treat every shopper as under 18. Cohort mode alone doesn't turn profiling
+off. The default `rank: 'signals'` still orders products by the shopper's
+signals in cohort mode and in the fallback, even with no provider. And cohort
+mode still sends their strongest category, whether they have any history, and
+any segment to the model.
 
 **Marketplaces.** If other sellers list products on your site, EU platform rules
-(Article 27 of the Digital Services Act) ask you, unless you're a micro or small
-business, to set out in your terms your recommender's main parameters, why they
-weigh as they do, and any options shoppers have to change them. If shoppers can
-pick between options, such as switching personalisation off, the control has to
-sit where the products are shown. Which parameters apply depends on your mode
-and your `rank` setting. `rank` sets the order in cohort mode and in the
-fallback component. With `rank: 'given'` that's the order you sent, so describe
-your own ranking. With `rank: 'signals'` it comes from the shopper's category
-interest (the category they're browsing counts too), how often they've viewed a
-product, its rating, and tags it shares with products they've engaged with.
-Category weighs most. In per-shopper mode the model picks which candidates to
-show and in what order, from what's under
-[What the model sees](#what-the-model-sees). In cohort mode the model picks the
-hero's product, from the cohort list there. In every mode, anything out of stock, disliked or
-being looked at right now is left out, and so is anything bought or in the
-basket, except as part of a bundle. A bundle is picked by what's in the basket,
-then what they viewed, then the category being browsed.
+(Article 27 of the Digital Services Act) ask you to set out in your terms:
+
+- your recommender's main parameters
+- why they weigh as they do
+- any options shoppers have to change them
+
+This doesn't apply if you're a micro or small business. If shoppers can pick
+between options, such as switching personalisation off, the control has to sit
+where the products are shown.
+
+Which parameters apply depends on your mode and your `rank` setting:
+
+- `rank` sets the order in cohort mode and in the fallback. With `rank: 'given'`
+  that's the order you sent, so describe your own ranking.
+- With `rank: 'signals'` the order comes from the shopper's category interest
+  (the category they're browsing counts too), how often they've viewed a
+  product, its rating, and tags it shares with products they've engaged with.
+  Category weighs most.
+- In per-shopper mode the model picks which candidates to show and in what
+  order, from what's under [What the model sees](#what-the-model-sees).
+- In cohort mode the model picks the hero's product, from the cohort list in
+  that section.
+- In every mode, anything out of stock, disliked or being looked at right now is
+  left out. So is anything bought or in the basket, except as part of a bundle.
+- A bundle is picked by what's in the basket, then what they viewed, then the
+  category being browsed.
 
 **Accessibility.** Every card is one link with a readable name, and headings
 only render when they have text. Contrast, focus styles and layout come from

package/dist/claim-screening.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"claim-screening.d.ts","sourceRoot":"","sources":["../src/claim-screening.ts"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AA4EzD,eAAO,MAAM,eAAe,UAK3B,CAAC;AAKF,eAAO,MAAM,QAAQ,EAAE,SAAS,MAAM,EAAO,CAAC;AAE9C,MAAM,WAAW,SAAS;IACxB,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,KAAK,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;CAC9B;AAED,wBAAgB,SAAS,CAAC,KAAK,EAAE,aAAa,GAAG,SAAS,CAWzD;AAaD,wBAAgB,aAAa,CAC3B,GAAG,EAAE,MAAM,EACX,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,SAAS,MAAM,EAAE,GACvB,MAAM,GAAG,IAAI,CASf"}
+{"version":3,"file":"claim-screening.d.ts","sourceRoot":"","sources":["../src/claim-screening.ts"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AA4EzD,eAAO,MAAM,eAAe,UAK3B,CAAC;AAKF,eAAO,MAAM,QAAQ,EAAE,SAAS,MAAM,EAAO,CAAC;AAE9C,MAAM,WAAW,SAAS;IACxB,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,KAAK,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;CAC9B;AAED,wBAAgB,SAAS,CAAC,KAAK,EAAE,aAAa,GAAG,SAAS,CAWzD;AAqBD,wBAAgB,aAAa,CAC3B,GAAG,EAAE,MAAM,EACX,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,SAAS,MAAM,EAAE,GACvB,MAAM,GAAG,IAAI,CASf"}

package/dist/claim-screening.js

@@ -101,7 +101,16 @@ function kindIn(reading) {
     return null;
 }
 function claimIn(text) {
-    return kindIn(foldLookalikes(text)) ?? kindIn(foldLookalikes(text, true));
+    const readings = new Set([foldLookalikes(text), foldLookalikes(text, true)]);
+    if (text.includes('\u04C0')) {
+        readings.add(foldLookalikes(text.replaceAll('\u04C0', '\u04CF'), true));
+    }
+    for (const reading of readings) {
+        const kind = kindIn(reading);
+        if (kind !== null)
+            return kind;
+    }
+    return null;
 }
 export function unbackedClaim(raw, clamped, facts) {
     const kind = claimIn(raw) ?? claimIn(clamped);

package/dist/claim-screening.js.map

@@ -1 +1 @@
-{"version":3,"file":"claim-screening.js","sourceRoot":"","sources":["../src/claim-screening.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,MAAM,EAAE,MAAM,oBAAoB,CAAC;AAC5D,OAAO,EAAE,iBAAiB,EAAE,MAAM,mBAAmB,CAAC;AAGtD,MAAM,cAAc,GAA2C;IAC7D;QACE,IAAI,EAAE,QAAQ;QACd,QAAQ,EAAE;YACR,2BAA2B;YAC3B,mDAAmD;YACnD,0BAA0B;YAC1B,kEAAkE;YAClE,+BAA+B;YAC/B,0CAA0C;YAC1C,yDAAyD;YACzD,uBAAuB;YACvB,2DAA2D;YAC3D,kCAAkC;YAClC,6DAA6D;YAC7D,+CAA+C;SAChD;KACF;IACD;QACE,IAAI,EAAE,OAAO;QACb,QAAQ,EAAE;YACR,SAAS;YACT,6DAA6D;YAC7D,yBAAyB;YACzB,wBAAwB;YACxB,qBAAqB;YACrB,yBAAyB;YACzB,6DAA6D;YAC7D,qBAAqB;YACrB,4BAA4B;YAC5B,2DAA2D;YAC3D,yBAAyB;YACzB,kDAAkD;SACnD;KACF;IACD;QACE,IAAI,EAAE,UAAU;QAChB,QAAQ,EAAE;YACR,qEAAqE;YACrE,iGAAiG;YACjG,uBAAuB;YACvB,sCAAsC;YACtC,6BAA6B;YAC7B,8BAA8B;YAC9B,4DAA4D;YAC5D,mBAAmB;YACnB,mBAAmB;YACnB,kCAAkC;YAClC,yCAAyC;SAC1C;KACF;IACD;QACE,IAAI,EAAE,UAAU;QAChB,QAAQ,EAAE;YACR,2BAA2B;YAC3B,iDAAiD;YACjD,kMAAkM;YAClM,qDAAqD;YACrD,iBAAiB;SAClB;KACF;IACD;QACE,IAAI,EAAE,OAAO;QACb,QAAQ,EAAE;YACR,gCAAgC;YAChC,mBAAmB;YACnB,6BAA6B;YAC7B,sFAAsF;YACtF,yFAAyF;YACzF,mEAAmE;SACpE;KACF;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,eAAe,GAAG;IAC7B,qBAAqB;IACrB,oBAAoB;IACpB,gBAAgB;IAChB,kBAAkB;CACnB,CAAC;AAEF,MAAM,UAAU,GAAG,SAAS,CAAC;AAC7B,MAAM,OAAO,GAAG,uBAAuB,CAAC;AAExC,MAAM,CAAC,MAAM,QAAQ,GAAsB,EAAE,CAAC;AAO9C,MAAM,UAAU,SAAS,CAAC,KAAoB;IAC5C,MAAM,MAAM,GAAG,IAAI,GAAG,EAAU,CAAC;IACjC,MAAM,KAAK,GAAG,IAAI,GAAG,EAAoB,CAAC;IAE1C,KAAK,MAAM,OAAO,IAAI,iBAAiB,CAAC,KAAK,CAAC,EAAE,CAAC;QAC/C,MAAM,GAAG,GAAG,CAAC,OAAO,CAAC,QAAQ,EAAE,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;QACxF,KAAK,CAAC,GAAG,CAAC,OAAO,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC;QAC5B,KAAK,MAAM,IAAI,IAAI,GAAG;YAAE,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;IAC3C,CAAC;IAED,OAAO,EAAE,MAAM,EAAE,CAAC,GAAG,MAAM,CAAC,EAAE,KAAK,EAAE,CAAC;AACxC,CAAC;AAED,SAAS,MAAM,CAAC,OAAe;IAC7B,KAAK,MAAM,KAAK,IAAI,cAAc,EAAE,CAAC;QACnC,IAAI,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAAE,OAAO,KAAK,CAAC,IAAI,CAAC;IACjF,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED,SAAS,OAAO,CAAC,IAAY;IAC3B,OAAO,MAAM,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,IAAI,MAAM,CAAC,cAAc,CAAC,IAAI,EAAE,IAAI,CAAC,CAAC,CAAC;AAC5E,CAAC;AAED,MAAM,UAAU,aAAa,CAC3B,GAAW,EACX,OAAe,EACf,KAAwB;IAExB,MAAM,IAAI,GAAG,OAAO,CAAC,GAAG,CAAC,IAAI,OAAO,CAAC,OAAO,CAAC,CAAC;IAC9C,IAAI,IAAI,KAAK,IAAI;QAAE,OAAO,IAAI,CAAC;IAE/B,MAAM,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,QAAQ,CAAC;IACxD,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,EAAE,EAAE,MAAM,EAAE,cAAc,EAAE,eAAe,EAAE,CAAC,CAAC;IAC5E,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,SAAS;QAAE,OAAO,UAAU,CAAC;IAClD,IAAI,CAAC,MAAM,CAAC,OAAO,CAAC,SAAS;QAAE,OAAO,SAAS,CAAC;IAChD,OAAO,IAAI,CAAC;AACd,CAAC"}
+{"version":3,"file":"claim-screening.js","sourceRoot":"","sources":["../src/claim-screening.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,MAAM,EAAE,MAAM,oBAAoB,CAAC;AAC5D,OAAO,EAAE,iBAAiB,EAAE,MAAM,mBAAmB,CAAC;AAGtD,MAAM,cAAc,GAA2C;IAC7D;QACE,IAAI,EAAE,QAAQ;QACd,QAAQ,EAAE;YACR,2BAA2B;YAC3B,mDAAmD;YACnD,0BAA0B;YAC1B,kEAAkE;YAClE,+BAA+B;YAC/B,0CAA0C;YAC1C,yDAAyD;YACzD,uBAAuB;YACvB,2DAA2D;YAC3D,kCAAkC;YAClC,6DAA6D;YAC7D,+CAA+C;SAChD;KACF;IACD;QACE,IAAI,EAAE,OAAO;QACb,QAAQ,EAAE;YACR,SAAS;YACT,6DAA6D;YAC7D,yBAAyB;YACzB,wBAAwB;YACxB,qBAAqB;YACrB,yBAAyB;YACzB,6DAA6D;YAC7D,qBAAqB;YACrB,4BAA4B;YAC5B,2DAA2D;YAC3D,yBAAyB;YACzB,kDAAkD;SACnD;KACF;IACD;QACE,IAAI,EAAE,UAAU;QAChB,QAAQ,EAAE;YACR,qEAAqE;YACrE,iGAAiG;YACjG,uBAAuB;YACvB,sCAAsC;YACtC,6BAA6B;YAC7B,8BAA8B;YAC9B,4DAA4D;YAC5D,mBAAmB;YACnB,mBAAmB;YACnB,kCAAkC;YAClC,yCAAyC;SAC1C;KACF;IACD;QACE,IAAI,EAAE,UAAU;QAChB,QAAQ,EAAE;YACR,2BAA2B;YAC3B,iDAAiD;YACjD,kMAAkM;YAClM,qDAAqD;YACrD,iBAAiB;SAClB;KACF;IACD;QACE,IAAI,EAAE,OAAO;QACb,QAAQ,EAAE;YACR,gCAAgC;YAChC,mBAAmB;YACnB,6BAA6B;YAC7B,sFAAsF;YACtF,yFAAyF;YACzF,mEAAmE;SACpE;KACF;CACF,CAAC;AAEF,MAAM,CAAC,MAAM,eAAe,GAAG;IAC7B,qBAAqB;IACrB,oBAAoB;IACpB,gBAAgB;IAChB,kBAAkB;CACnB,CAAC;AAEF,MAAM,UAAU,GAAG,SAAS,CAAC;AAC7B,MAAM,OAAO,GAAG,uBAAuB,CAAC;AAExC,MAAM,CAAC,MAAM,QAAQ,GAAsB,EAAE,CAAC;AAO9C,MAAM,UAAU,SAAS,CAAC,KAAoB;IAC5C,MAAM,MAAM,GAAG,IAAI,GAAG,EAAU,CAAC;IACjC,MAAM,KAAK,GAAG,IAAI,GAAG,EAAoB,CAAC;IAE1C,KAAK,MAAM,OAAO,IAAI,iBAAiB,CAAC,KAAK,CAAC,EAAE,CAAC;QAC/C,MAAM,GAAG,GAAG,CAAC,OAAO,CAAC,QAAQ,EAAE,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,UAAU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;QACxF,KAAK,CAAC,GAAG,CAAC,OAAO,CAAC,GAAG,EAAE,GAAG,CAAC,CAAC;QAC5B,KAAK,MAAM,IAAI,IAAI,GAAG;YAAE,MAAM,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;IAC3C,CAAC;IAED,OAAO,EAAE,MAAM,EAAE,CAAC,GAAG,MAAM,CAAC,EAAE,KAAK,EAAE,CAAC;AACxC,CAAC;AAED,SAAS,MAAM,CAAC,OAAe;IAC7B,KAAK,MAAM,KAAK,IAAI,cAAc,EAAE,CAAC;QACnC,IAAI,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAAE,OAAO,KAAK,CAAC,IAAI,CAAC;IACjF,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED,SAAS,OAAO,CAAC,IAAY;IAC3B,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,CAAC,cAAc,CAAC,IAAI,CAAC,EAAE,cAAc,CAAC,IAAI,EAAE,IAAI,CAAC,CAAC,CAAC,CAAC;IAC7E,IAAI,IAAI,CAAC,QAAQ,CAAC,QAAQ,CAAC,EAAE,CAAC;QAC5B,QAAQ,CAAC,GAAG,CAAC,cAAc,CAAC,IAAI,CAAC,UAAU,CAAC,QAAQ,EAAE,QAAQ,CAAC,EAAE,IAAI,CAAC,CAAC,CAAC;IAC1E,CAAC;IACD,KAAK,MAAM,OAAO,IAAI,QAAQ,EAAE,CAAC;QAC/B,MAAM,IAAI,GAAG,MAAM,CAAC,OAAO,CAAC,CAAC;QAC7B,IAAI,IAAI,KAAK,IAAI;YAAE,OAAO,IAAI,CAAC;IACjC,CAAC;IACD,OAAO,IAAI,CAAC;AACd,CAAC;AAED,MAAM,UAAU,aAAa,CAC3B,GAAW,EACX,OAAe,EACf,KAAwB;IAExB,MAAM,IAAI,GAAG,OAAO,CAAC,GAAG,CAAC,IAAI,OAAO,CAAC,OAAO,CAAC,CAAC;IAC9C,IAAI,IAAI,KAAK,IAAI;QAAE,OAAO,IAAI,CAAC;IAE/B,MAAM,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,QAAQ,CAAC;IACxD,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,EAAE,EAAE,MAAM,EAAE,cAAc,EAAE,eAAe,EAAE,CAAC,CAAC;IAC5E,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,SAAS;QAAE,OAAO,UAAU,CAAC;IAClD,IAAI,CAAC,MAAM,CAAC,OAAO,CAAC,SAAS;QAAE,OAAO,SAAS,CAAC;IAChD,OAAO,IAAI,CAAC;AACd,CAAC"}

package/dist/spec-cache.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"spec-cache.d.ts","sourceRoot":"","sources":["../src/spec-cache.ts"],"names":[],"mappings":"AACA,OAAO,EAAgB,KAAK,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAEvE,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,oBAAoB,CAAC;AAEvD,MAAM,WAAW,UAAU;IACzB,IAAI,EAAE,aAAa,CAAC;IACpB,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,MAAM,WAAW,SAAS;IACxB,GAAG,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,UAAU,GAAG,SAAS,CAAC,CAAC;IAClD,GAAG,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,UAAU,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IACpD,MAAM,CAAC,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;CACrC;AAED,MAAM,WAAW,sBAAsB;IACrC,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;CACpB;AAgBD,wBAAgB,qBAAqB,CAAC,OAAO,GAAE,sBAA2B,GAAG,SAAS,CAuCrF;AAED,wBAAgB,mBAAmB,IAAI,SAAS,CAE/C;AAmBD,wBAAgB,YAAY,CAC1B,MAAM,EAAE,YAAY,EACpB,aAAa,EAAE,SAAS,MAAM,EAAE,EAChC,QAAQ,EAAE;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,GACxC,MAAM,CAUR"}
+{"version":3,"file":"spec-cache.d.ts","sourceRoot":"","sources":["../src/spec-cache.ts"],"names":[],"mappings":"AACA,OAAO,EAAgB,KAAK,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAEvE,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,oBAAoB,CAAC;AAEvD,MAAM,WAAW,UAAU;IACzB,IAAI,EAAE,aAAa,CAAC;IACpB,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,MAAM,WAAW,SAAS;IACxB,GAAG,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,UAAU,GAAG,SAAS,CAAC,CAAC;IAClD,GAAG,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,UAAU,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IACpD,MAAM,CAAC,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;CACrC;AAED,MAAM,WAAW,sBAAsB;IACrC,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,GAAG,CAAC,EAAE,MAAM,MAAM,CAAC;CACpB;AAgBD,wBAAgB,qBAAqB,CAAC,OAAO,GAAE,sBAA2B,GAAG,SAAS,CAuCrF;AAED,wBAAgB,mBAAmB,IAAI,SAAS,CAE/C;AA2BD,wBAAgB,YAAY,CAC1B,MAAM,EAAE,YAAY,EACpB,aAAa,EAAE,SAAS,MAAM,EAAE,EAChC,QAAQ,EAAE;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,GACxC,MAAM,CAUR"}

package/dist/spec-cache.js

@@ -63,12 +63,19 @@ function canonicalise(value) {
     return `{${fields.join(',')}}`;
 }
 const PROMPT_FINGERPRINT = createHash('sha256').update(SYSTEM_PROMPT).digest('hex').slice(0, 16);
+function withoutDwellAndScores(digest) {
+    return {
+        ...digest,
+        topViewed: digest.topViewed.map(({ dwellMs: _dwellMs, ...view }) => view),
+        categoryAffinity: digest.categoryAffinity.map(({ score: _score, ...affinity }) => affinity),
+    };
+}
 export function specCacheKey(digest, candidateSkus, provider) {
     const material = canonicalise({
         specVersion: SPEC_VERSION,
         prompt: PROMPT_FINGERPRINT,
         provider,
-        digest,
+        digest: withoutDwellAndScores(digest),
         candidates: candidateSkus.toSorted(),
     });
     return createHash('sha256').update(material).digest('hex').slice(0, 32);

package/dist/spec-cache.js.map

@@ -1 +1 @@
-{"version":3,"file":"spec-cache.js","sourceRoot":"","sources":["../src/spec-cache.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AACzC,OAAO,EAAE,YAAY,EAAsB,MAAM,qBAAqB,CAAC;AACvE,OAAO,EAAE,aAAa,EAAE,MAAM,mBAAmB,CAAC;AAoBlD,SAAS,uBAAuB,CAAC,IAAY,EAAE,KAAa;IAC1D,IAAI,MAAM,CAAC,QAAQ,CAAC,KAAK,CAAC,IAAI,KAAK,IAAI,CAAC;QAAE,OAAO;IAEjD,MAAM,IAAI,GAAG,MAAM,CAAC,KAAK,CAAC,KAAK,CAAC;QAC9B,CAAC,CAAC,0EAA0E;QAC5E,CAAC,CAAC,EAAE,CAAC;IACP,MAAM,IAAI,UAAU,CAAC,GAAG,IAAI,oDAAoD,KAAK,GAAG,IAAI,EAAE,CAAC,CAAC;AAClG,CAAC;AAOD,MAAM,UAAU,qBAAqB,CAAC,OAAO,GAA2B,EAAE;IACxE,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,IAAI,MAAM,CAAC;IACtC,MAAM,UAAU,GAAG,OAAO,CAAC,UAAU,IAAI,MAAM,CAAC;IAEhD,uBAAuB,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;IACxC,uBAAuB,CAAC,YAAY,EAAE,UAAU,CAAC,CAAC;IAClD,IAAI,CAAC,MAAM,CAAC,aAAa,CAAC,UAAU,CAAC,EAAE,CAAC;QACtC,MAAM,IAAI,UAAU,CAAC,+CAA+C,UAAU,EAAE,CAAC,CAAC;IACpF,CAAC;IAED,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,IAAI,IAAI,CAAC,GAAG,CAAC;IACpC,MAAM,OAAO,GAAG,IAAI,GAAG,EAAsB,CAAC;IAE9C,OAAO;QACL,KAAK,CAAC,GAAG,CAAC,GAAG;YACX,MAAM,KAAK,GAAG,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;YAC/B,IAAI,CAAC,KAAK;gBAAE,OAAO,SAAS,CAAC;YAE7B,MAAM,SAAS,GAAG,KAAK,CAAC,SAAS,IAAI,GAAG,EAAE,CAAC;YAC3C,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;YACpB,IAAI,SAAS;gBAAE,OAAO,SAAS,CAAC;YAChC,OAAO,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;YACxB,OAAO,KAAK,CAAC,MAAM,CAAC;QACtB,CAAC;QAED,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,MAAM;YACnB,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;YACpB,OAAO,CAAC,GAAG,CAAC,GAAG,EAAE,EAAE,MAAM,EAAE,SAAS,EAAE,GAAG,EAAE,GAAG,KAAK,EAAE,CAAC,CAAC;YAEvD,KAAK,MAAM,MAAM,IAAI,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC;gBACpC,IAAI,OAAO,CAAC,IAAI,IAAI,UAAU;oBAAE,MAAM;gBACtC,OAAO,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;YACzB,CAAC;QACH,CAAC;QAED,KAAK,CAAC,MAAM,CAAC,GAAG;YACd,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;QACtB,CAAC;KACF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB;IACjC,OAAO,EAAE,GAAG,EAAE,KAAK,IAAI,EAAE,CAAC,SAAS,EAAE,GAAG,EAAE,KAAK,IAAI,EAAE,GAAE,CAAC,EAAE,CAAC;AAC7D,CAAC;AAED,SAAS,YAAY,CAAC,KAAc;IAClC,IAAI,KAAK,KAAK,IAAI,IAAI,OAAO,KAAK,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,IAAI,MAAM,CAAC;IACxF,IAAI,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;QAAE,OAAO,IAAI,KAAK,CAAC,GAAG,CAAC,YAAY,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC;IAE1E,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,CAAC,KAAgC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,EAAE,CAAC,KAAK,CAAC,EAAE,EAAE,CAC3F,IAAI,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CACtB,CAAC;IACF,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,KAAK,MAAM,CAAC,IAAI,EAAE,UAAU,CAAC,IAAI,MAAM,EAAE,CAAC;QACxC,IAAI,UAAU,KAAK,SAAS;YAAE,SAAS;QACvC,MAAM,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC,IAAI,YAAY,CAAC,UAAU,CAAC,EAAE,CAAC,CAAC;IACrE,CAAC;IACD,OAAO,IAAI,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC;AACjC,CAAC;AAED,MAAM,kBAAkB,GAAG,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,aAAa,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;AAEjG,MAAM,UAAU,YAAY,CAC1B,MAAoB,EACpB,aAAgC,EAChC,QAAyC;IAEzC,MAAM,QAAQ,GAAG,YAAY,CAAC;QAC5B,WAAW,EAAE,YAAY;QACzB,MAAM,EAAE,kBAAkB;QAC1B,QAAQ;QACR,MAAM;QACN,UAAU,EAAE,aAAa,CAAC,QAAQ,EAAE;KACrC,CAAC,CAAC;IAEH,OAAO,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;AAC1E,CAAC"}
+{"version":3,"file":"spec-cache.js","sourceRoot":"","sources":["../src/spec-cache.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AACzC,OAAO,EAAE,YAAY,EAAsB,MAAM,qBAAqB,CAAC;AACvE,OAAO,EAAE,aAAa,EAAE,MAAM,mBAAmB,CAAC;AAoBlD,SAAS,uBAAuB,CAAC,IAAY,EAAE,KAAa;IAC1D,IAAI,MAAM,CAAC,QAAQ,CAAC,KAAK,CAAC,IAAI,KAAK,IAAI,CAAC;QAAE,OAAO;IAEjD,MAAM,IAAI,GAAG,MAAM,CAAC,KAAK,CAAC,KAAK,CAAC;QAC9B,CAAC,CAAC,0EAA0E;QAC5E,CAAC,CAAC,EAAE,CAAC;IACP,MAAM,IAAI,UAAU,CAAC,GAAG,IAAI,oDAAoD,KAAK,GAAG,IAAI,EAAE,CAAC,CAAC;AAClG,CAAC;AAOD,MAAM,UAAU,qBAAqB,CAAC,OAAO,GAA2B,EAAE;IACxE,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,IAAI,MAAM,CAAC;IACtC,MAAM,UAAU,GAAG,OAAO,CAAC,UAAU,IAAI,MAAM,CAAC;IAEhD,uBAAuB,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;IACxC,uBAAuB,CAAC,YAAY,EAAE,UAAU,CAAC,CAAC;IAClD,IAAI,CAAC,MAAM,CAAC,aAAa,CAAC,UAAU,CAAC,EAAE,CAAC;QACtC,MAAM,IAAI,UAAU,CAAC,+CAA+C,UAAU,EAAE,CAAC,CAAC;IACpF,CAAC;IAED,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,IAAI,IAAI,CAAC,GAAG,CAAC;IACpC,MAAM,OAAO,GAAG,IAAI,GAAG,EAAsB,CAAC;IAE9C,OAAO;QACL,KAAK,CAAC,GAAG,CAAC,GAAG;YACX,MAAM,KAAK,GAAG,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;YAC/B,IAAI,CAAC,KAAK;gBAAE,OAAO,SAAS,CAAC;YAE7B,MAAM,SAAS,GAAG,KAAK,CAAC,SAAS,IAAI,GAAG,EAAE,CAAC;YAC3C,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;YACpB,IAAI,SAAS;gBAAE,OAAO,SAAS,CAAC;YAChC,OAAO,CAAC,GAAG,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC;YACxB,OAAO,KAAK,CAAC,MAAM,CAAC;QACtB,CAAC;QAED,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,MAAM;YACnB,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;YACpB,OAAO,CAAC,GAAG,CAAC,GAAG,EAAE,EAAE,MAAM,EAAE,SAAS,EAAE,GAAG,EAAE,GAAG,KAAK,EAAE,CAAC,CAAC;YAEvD,KAAK,MAAM,MAAM,IAAI,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC;gBACpC,IAAI,OAAO,CAAC,IAAI,IAAI,UAAU;oBAAE,MAAM;gBACtC,OAAO,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;YACzB,CAAC;QACH,CAAC;QAED,KAAK,CAAC,MAAM,CAAC,GAAG;YACd,OAAO,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;QACtB,CAAC;KACF,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB;IACjC,OAAO,EAAE,GAAG,EAAE,KAAK,IAAI,EAAE,CAAC,SAAS,EAAE,GAAG,EAAE,KAAK,IAAI,EAAE,GAAE,CAAC,EAAE,CAAC;AAC7D,CAAC;AAED,SAAS,YAAY,CAAC,KAAc;IAClC,IAAI,KAAK,KAAK,IAAI,IAAI,OAAO,KAAK,KAAK,QAAQ;QAAE,OAAO,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,IAAI,MAAM,CAAC;IACxF,IAAI,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;QAAE,OAAO,IAAI,KAAK,CAAC,GAAG,CAAC,YAAY,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC;IAE1E,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,CAAC,KAAgC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC,EAAE,CAAC,KAAK,CAAC,EAAE,EAAE,CAC3F,IAAI,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CACtB,CAAC;IACF,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,KAAK,MAAM,CAAC,IAAI,EAAE,UAAU,CAAC,IAAI,MAAM,EAAE,CAAC;QACxC,IAAI,UAAU,KAAK,SAAS;YAAE,SAAS;QACvC,MAAM,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,SAAS,CAAC,IAAI,CAAC,IAAI,YAAY,CAAC,UAAU,CAAC,EAAE,CAAC,CAAC;IACrE,CAAC;IACD,OAAO,IAAI,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC;AACjC,CAAC;AAED,MAAM,kBAAkB,GAAG,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,aAAa,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;AAEjG,SAAS,qBAAqB,CAAC,MAAoB;IACjD,OAAO;QACL,GAAG,MAAM;QACT,SAAS,EAAE,MAAM,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,EAAE,OAAO,EAAE,QAAQ,EAAE,GAAG,IAAI,EAAE,EAAE,EAAE,CAAC,IAAI,CAAC;QACzE,gBAAgB,EAAE,MAAM,CAAC,gBAAgB,CAAC,GAAG,CAAC,CAAC,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,QAAQ,EAAE,EAAE,EAAE,CAAC,QAAQ,CAAC;KAC5F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,YAAY,CAC1B,MAAoB,EACpB,aAAgC,EAChC,QAAyC;IAEzC,MAAM,QAAQ,GAAG,YAAY,CAAC;QAC5B,WAAW,EAAE,YAAY;QACzB,MAAM,EAAE,kBAAkB;QAC1B,QAAQ;QACR,MAAM,EAAE,qBAAqB,CAAC,MAAM,CAAC;QACrC,UAAU,EAAE,aAAa,CAAC,QAAQ,EAAE;KACrC,CAAC,CAAC;IAEH,OAAO,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;AAC1E,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rudra-js/core",
-  "version": "0.8.1",
+  "version": "0.8.3",
   "description": "Core of rudra-js, a TypeScript library for LLM-designed product recommendations: turns one page view into a recommendation spec checked against your catalog",
   "keywords": [
     "rudra-js",
@@ -60,10 +60,10 @@
     "zod": "^4.6.7"
   },
   "peerDependencies": {
-    "@rudra-js/attested": "^0.8.1"
+    "@rudra-js/attested": "^0.8.3"
   },
   "devDependencies": {
-    "@rudra-js/attested": "0.8.1",
+    "@rudra-js/attested": "0.8.3",
     "@types/node": "^26.4.1"
   }
 }

package/src/claim-screening.ts

@@ -114,7 +114,15 @@ function kindIn(reading: string): string | null {
 }
 
 function claimIn(text: string): string | null {
-  return kindIn(foldLookalikes(text)) ?? kindIn(foldLookalikes(text, true));
+  const readings = new Set([foldLookalikes(text), foldLookalikes(text, true)]);
+  if (text.includes('\u04C0')) {
+    readings.add(foldLookalikes(text.replaceAll('\u04C0', '\u04CF'), true));
+  }
+  for (const reading of readings) {
+    const kind = kindIn(reading);
+    if (kind !== null) return kind;
+  }
+  return null;
 }
 
 export function unbackedClaim(

package/src/spec-cache.ts

@@ -96,6 +96,14 @@ function canonicalise(value: unknown): string {
 
 const PROMPT_FINGERPRINT = createHash('sha256').update(SYSTEM_PROMPT).digest('hex').slice(0, 16);
 
+function withoutDwellAndScores(digest: SignalDigest) {
+  return {
+    ...digest,
+    topViewed: digest.topViewed.map(({ dwellMs: _dwellMs, ...view }) => view),
+    categoryAffinity: digest.categoryAffinity.map(({ score: _score, ...affinity }) => affinity),
+  };
+}
+
 export function specCacheKey(
   digest: SignalDigest,
   candidateSkus: readonly string[],
@@ -105,7 +113,7 @@ export function specCacheKey(
     specVersion: SPEC_VERSION,
     prompt: PROMPT_FINGERPRINT,
     provider,
-    digest,
+    digest: withoutDwellAndScores(digest),
     candidates: candidateSkus.toSorted(),
   });