@aastrika/ai-elements 0.5.0 → 0.6.1

package/CHANGELOG.md

@@ -6,6 +6,75 @@ see at a glance what to expect when they upgrade.
 Versions follow semver: a **minor** adds something, a **patch** fixes something,
 and neither removes anything a host was using.
 
+## 0.6.1
+
+**Fixed**
+- The usage report showed one person's figures instead of the whole
+  organisation's — and nothing at all when the signed-in name did not match the
+  name recorded on their content. Every request body was given the signed-in
+  `creator`, including the report, where that field means "filter to this
+  person" rather than "this is who I am". The report is no longer given one; the
+  dashboard's own picker still filters as before
+
+**Added**
+- `creatorName` in `configure()` — the signed-in person's display name, shown in
+  the report while `creator` stays what it groups by. A host can now use a
+  stable handle as `creator` and let people rename themselves without splitting
+  their history across two creators. Optional: omit it and the report shows
+  `creator`, exactly as today
+
+Needs the service to be on a build that stores `creator_name`; on an older one
+the field is ignored and nothing changes.
+
+## 0.6.0
+
+Adds behaviour rather than API: the tags, attributes and events are exactly
+those of 0.5.0, so a host upgrades without touching a line. What changed is what
+the elements do while someone is using them.
+
+**Added**
+- A run survives leaving the screen. The work already happened server-side; the
+  job id is now remembered, so coming back to Content Studio or Assessment picks
+  the run up again instead of showing an empty form beside a job that is still
+  producing
+- Drop a file on the Content Studio upload zone. It said "choose a file" and
+  accepted nothing else; it now takes a drop, and says so
+- Steps you have finished collapse to one line naming what you chose, with a way
+  back in that reopens the step as it stands. Five open forms made you hunt for
+  the one you were on
+- Reports opens with a shimmer skeleton shaped like the page it is loading,
+  rather than the word "Loading"
+- Reports pages its tables, ten rows at a time, and switches between videos and
+  assessments with a filter instead of stacking both
+- `--aastrika-accent-2` and `--aastrika-accent-3` name the second and third
+  hues. A spend split drawn in one hue at two darknesses reads as one bar; two
+  hues read as a comparison
+
+**Changed**
+- Reports is one screen rather than four stacked tables: the figures carry their
+  own context, spend carries its own breakdown, and picking a person is a
+  control in the header rather than a table whose job was to be clicked
+- A column appears only when it has something to say — an empty "Feedback
+  rounds" column took width from the titles, which need it
+- "Production" is now "Creating your video", and "Your video" is "Finished
+  video"
+
+**Fixed**
+- A focused field drew two borders. `:focus` and `:focus-visible` both applied,
+  because a text field matches `:focus-visible` on a plain click
+- Resting the cursor on the field you just clicked reset its edge to grey:
+  `:hover` outranked `:focus`
+- The actions column in Reports collapsed to nothing. `width: 1%` is taken
+  literally under `table-layout: fixed`, so View, Export and Delete were clipped
+  out of sight; the buttons also sat above their row's centre line
+- The confirmation dialog's buttons were unstyled — a bare red rectangle and a
+  line of plain text — because that component never had the shared stylesheet
+  in scope
+- Content Studio's progress panel had no styling at all: it lived in
+  Assessment's stylesheet while both screens used it
+- Colour fallbacks carried the palette from before 0.4.2, so a token that failed
+  to resolve would have rendered in a dead colour scheme
+
 ## 0.5.0
 
 A visual pass over all three elements. Nothing a host calls has changed — same

package/aastrika-elements.d.ts

@@ -43,8 +43,20 @@ export interface AastrikaConfig {
   apiBase: string;
   /** Headers proving the caller may use the service. Called before every request. */
   getAuthHeaders?: () => Record<string, string> | Promise<Record<string, string>>;
-  /** The username signed into YOUR application. Attribution, never verified. */
+  /**
+   * A STABLE key for whoever is signed into YOUR application — a login handle
+   * or an id, never a display name. The usage report groups and filters by it,
+   * so renaming somebody must not change it. Attribution, never verified.
+   */
   creator?: () => string | null;
+  /**
+   * The same person's display name, e.g. "Prince Gupta". Shown in the usage
+   * report; `creator` remains what it groups by, so people can rename
+   * themselves without splitting their history. Optional — omit it and the
+   * report shows `creator`, so send one whenever `creator` is an opaque id,
+   * or the report fills with UUIDs.
+   */
+  creatorName?: () => string | null;
   /** Called whenever a request fails, so your monitoring hears about it. */
   onError?: (error: AastrikaError) => void;
 }