@pie-players/pie-assessment-toolkit 0.3.62 → 0.3.64

package/README.md

@@ -1047,6 +1047,40 @@ const alternative = resolver.getAlternative('prompt-001', {
 resolver.clearItemCatalogs();
 ```
 
+A resolved card carries either a string `content` (SSML for `spoken`, text for
+`braille`) or a structured `payload`, decided by its `catalog` type — never both.
+Consumers select by type and then validate the form they expect; a card with no
+string form is not text content, and treating it as such would speak or render an
+empty string.
+
+Catalogs registered for a rendered item or passage are filed under a
+`CatalogOwnerContext`, which the resolver matches field by field. Build lookup
+contexts with `catalogOwnerContextFor` rather than as a literal — it is the same
+function the runtime registers with, so the two cannot drift:
+
+```typescript
+import {
+  catalogOwnerContextFor,
+  collectEntityCatalogRegistrations,
+} from '@pie-players/pie-assessment-toolkit';
+
+const context = catalogOwnerContextFor({
+  kind: 'item',
+  itemId: item.id,
+  canonicalItemId,
+  assessmentId,
+  sectionId,
+});
+
+// Every catalog an entity carries, paired with the scope it belongs in:
+// entity-level `accessibilityCatalogs`, `config.extractedCatalogs`, and each
+// model's own catalogs (filed under that `modelId`).
+const registrations = collectEntityCatalogRegistrations(item, {
+  kind: 'item',
+  itemId: item.id,
+});
+```
+
 ### SSMLExtractor
 
 ```typescript
@@ -1063,6 +1097,35 @@ item.config.extractedCatalogs = result.catalogs;
 catalogResolver.addItemCatalogs(result.catalogs);
 ```
 
+### Sign-language cards
+
+Signed alternates have no extractor and deliberately so: a `sign-language` card is
+authored or written by an importer, never lifted out of item markup at render
+time. One such lift existed and was removed — nothing produced the inline form,
+and a runtime that could not parse the markup left the video in the visible
+content, showing the accommodation to every learner regardless of eligibility.
+
+Whether a card describes a playable signed alternate is decided in one place,
+`resolveSignLanguageMedia` — a payload with no usable source resolves to `null`
+rather than rendering an empty player, and source URLs are restricted to schemes
+a media element can actually fetch. `matchesRequestedSignLanguage` holds the
+deliberate strictness: there is no cross-sign-language substitution, since
+handing an ASL learner a BSL recording is worse than handing them nothing.
+
+### Feature policy without a placement
+
+`ToolPolicyEngine.decideFeature(featureId)` (and
+`ToolkitCoordinator.decideFeaturePolicy(featureId)`) resolve one feature id
+through `PnpPolicySource`'s six-level precedence, independent of any toolbar
+placement. Use it for capabilities that are not toolbar surfaces — signing is the
+first — where a placement-scoped `decide(...)` would answer the wrong question:
+absent because it was never placed, rather than absent because policy said no.
+
+`computeDefaultSupports()` excludes `ACCOMMODATION_ONLY_SUPPORT_IDS`, which lists
+`signLanguage`. The computed default profile derives from every registered tool's
+`pnpSupportIds`, which is right for universal features and wrong for an
+accommodation requiring a documented need.
+
 ## Integration with Section Player
 
 The section player provides automatic ToolkitCoordinator integration:

package/dist/components/ItemToolBar.custom-element.js

@@ -1 +1 @@
-import{a}from"./chunks/ItemToolBar-84nv78dy.js";import"./chunks/ItemToolBar-843902tp.js";export{a as default};
+import{a}from"./chunks/ItemToolBar-7rq2gj8b.js";import"./chunks/ItemToolBar-3cppre9r.js";export{a as default};