@ham2k/extension-sdk 0.5.3 → 0.5.4

package/dist/index.d.ts

@@ -1,4 +1,4 @@
-// @ham2k/extension-sdk 0.5.3
+// @ham2k/extension-sdk 0.5.4
 /** Experimental v1 scene contract. All coordinates are in the scene's viewBox. */
 export interface SvgScene {
 	version: 1;
@@ -235,6 +235,7 @@ export interface HookContext {
 }
 export interface HistoryForCallOptions {
 	refType?: string | string[];
+	refPrefix?: string | string[];
 	operation?: string | string[];
 	excludeOperation?: string | string[];
 	fromDate?: string;

package/docs/distribution.md

@@ -412,6 +412,36 @@ and the offer returns next launch. Twins that did arrive stay on disk, unused
 until an upgrade completes — the built-in each one supersedes is what runs
 meanwhile.
 
+A bundle the engine will not evaluate takes the whole runtime with it, so the
+upgrade puts that one aside — the boot names the bundle it died on — and
+restarts once more. What boots then is the upgrade minus that extension, named
+in the dialog in a sentence of its own. Refused rather than
+withdrawn: the panel still lists it, badged, because the row is where an
+operator sees that something they installed is doing nothing, and updating it
+there is what lifts the refusal. Keyed by the VERSION that failed, so a fixed
+release arrives as an ordinary update and clears it. Only an INSTALLED
+extension is ever put aside; a built-in that
+will not evaluate is a defect in the app, and skipping it would ship an
+install quietly missing part of itself.
+
+A refusal is kept even when putting the bundle aside did not get a runtime
+back: it still will not evaluate, and an extension with no built-in behind it
+is in the reverted set too, so re-admitting it there would kill the boot that
+was about to give the operator everything back. Every dialog, and the notice
+that stands in for one, names what stayed out — except a downloaded copy the
+revert superseded, whose built-in is running again. Uninstalling clears the
+record, so a reinstall of the same bytes gets its chance.
+
+A refused extension is treated like a revoked one in everything else: it
+keeps its switch, and its downloaded data expires on the same clock as any
+extension the app is not loading.
+
+What this does NOT cover is a failure that names no bundle. Only a bundle
+that fails while it is being EVALUATED names itself: a kernel that will not
+load, or an extension that throws while ACTIVATING, takes the generation down
+under a name that is not a key. Those revert the whole upgrade as before, and
+it is offered again at the next launch.
+
 The upgrade restarts the extension runtime, which takes the footer items of
 the generation going down with it: a data file's import raises an error rather
 than returning into a torn-down runtime, so its progress line is cleared and

package/docs/hooks.md

@@ -64,7 +64,10 @@ hook method receives `(args, ctx)` where `ctx: HookContext` is:
   `options` (`HistoryForCallOptions` in `types.ts`) narrow the history
   before it is ordered and limited, so `{ refType: 'cwt' }` finds last
   month's CWT exchange behind a week of POTA contacts. The filters are
-  `refType` (a ref in the QSO's own `refs`), `operation`/`excludeOperation`,
+  `refType` (a ref in the QSO's own `refs`), `refPrefix` (a ref whose `ref`
+  starts with it, ignoring ASCII case; with `refType`, the same ref must pass
+  both, so `{ refType: 'potaActivation', refPrefix: 'FR-' }` finds French
+  parks), `operation`/`excludeOperation`,
   `band`/`excludeBand`, `mode`/`excludeMode` (`SSB` also matches its
   sidebands, and `CW`/`PHONE`/`DATA` match their whole family), whole UTC
   days through `fromDate`/`toDate` or `fromDateMillis`/`toDateMillis`, and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ham2k/extension-sdk",
-  "version": "0.5.3",
+  "version": "0.5.4",
   "description": "Write extensions for the Ham2K Logger: typed hook contracts and the host API",
   "keywords": [
     "ham2k",