@startsimpli/ui 0.4.133 → 0.4.135

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@startsimpli/ui",
-  "version": "0.4.133",
+  "version": "0.4.135",
   "description": "Shared UI components package for StartSimpli applications",
   "main": "./src/index.ts",
   "types": "./src/index.ts",
@@ -47,7 +47,7 @@
     "next": "^14.0.0 || ^15.0.0 || ^16.0.0",
     "react": "^18.0.0 || ^19.0.0",
     "react-dom": "^18.0.0 || ^19.0.0",
-    "@startsimpli/api": "^0.5.65",
+    "@startsimpli/api": "^0.5.66",
     "@startsimpli/auth": "^0.4.38",
     "@startsimpli/i18n": "^0.1.3"
   },

package/src/components/collection/InlineReviewActions.tsx

@@ -5,13 +5,16 @@
  * startsim-768w.18.15). Renders the (up to) three decisions from the schema as
  * compact icon buttons ✕ reject · ✓ good · ✎ edit; a click writes status AND
  * team_verdict together (the coherent pair, same as ReviewDrawer) IN PLACE —
- * optimistic, no drawer. The current verdict shows as the active button.
+ * optimistic, no drawer.
  *
  * The ✎ "edit / needs work" decision opens a small popover with a note box so the
  * reviewer says HOW it should change — saved to the note attr alongside the
  * status+verdict move. Meant to live in a table's trailing "Actions" column; it
  * stops click propagation so acting never triggers the row's drawer-open.
  *
+ * THE ACTIVE BUTTON REPORTS STATUS, NOT THE VERDICT (bd startsim-m7fdm.12) — see
+ * `activeDecisionKey` in review.ts for why, and for what that costs.
+ *
  * Generic + client-injected: pass a CollectionClient + the record; defaults match
  * the OGMC content schema but everything routes through resolveReviewConfig.
  */
@@ -26,6 +29,7 @@ import { cn } from '../../lib/utils';
 import type { CollectionClient, EntityRecord, EntityTypeDef } from './types';
 import { writeData } from './data';
 import {
+  activeDecisionKey,
   applyDecisionToData,
   fieldStr,
   resolveReviewConfig,
@@ -69,26 +73,37 @@ export function InlineReviewActions({ client, type, record, config, onSaved }: I
     () => [...reviewDecisions(cfg)].sort((a, b) => ORDER.indexOf(a.key) - ORDER.indexOf(b.key)),
     [cfg],
   );
-  // Which decision the record currently reflects — by verdict when the type has
-  // one (topics), else by status (news: acceptable→approve, rejected→reject). The
-  // matching button shows active. Optimistically updated on click.
-  const initialKey = useMemo(() => {
-    const v = fieldStr(record.data, cfg.verdictAttr);
-    const s = fieldStr(record.data, cfg.statusName);
-    return (
-      decisions.find((d) => (d.verdict ? d.verdict === v : d.status ? d.status === s : false))?.key ??
-      null
-    );
-  }, [record.data, cfg, decisions]);
-  const [appliedKey, setAppliedKey] = useState<string | null>(initialKey);
+  /**
+   * Which decision the record's STATE reflects — the button that renders active.
+   * Resolved by the shared `activeDecisionKey`, which answers off STATUS wherever
+   * the type has a status pipeline, so the AI's `team_verdict` can no longer
+   * render as a human's approval (bd startsim-m7fdm.12).
+   */
+  const storedKey = useMemo(
+    () => activeDecisionKey(record.data, cfg, decisions),
+    [record.data, cfg, decisions],
+  );
+  /**
+   * Optimistic override, remembered against the exact record snapshot it was made
+   * on, so it DROPS the moment a refetch hands this row a new one and the buttons
+   * go back to reporting stored state.
+   *
+   * It used to be `useState(initialKey)` — an initialiser that runs once per
+   * mounted component. A table cell's component instance outlives the record in
+   * it (a refetch, a re-sort, a page change hands the same cell a different row),
+   * and the old state then showed the PREVIOUS row's decision with nothing to
+   * correct it. Deriving from the record and overlaying the click is what makes
+   * the active state follow the data it claims to describe.
+   */
+  const [override, setOverride] = useState<{ on: unknown; key: string } | null>(null);
+  const appliedKey = override && override.on === record.data ? override.key : storedKey;
   const [busy, setBusy] = useState<string | null>(null);
   const [noteOpen, setNoteOpen] = useState(false);
   const [note, setNote] = useState('');
 
   /** Apply a decision (status + verdict), optionally attaching a note. Optimistic. */
   async function apply(d: ReviewDecision, noteText?: string) {
-    const prev = appliedKey;
-    setAppliedKey(d.key); // optimistic
+    setOverride({ on: record.data, key: d.key }); // optimistic
     setBusy(d.key);
     try {
       // Declared names re-key the whole outgoing blob, so a decision here cannot
@@ -99,7 +114,7 @@ export function InlineReviewActions({ client, type, record, config, onSaved }: I
       onSaved?.();
       return true;
     } catch (err) {
-      setAppliedKey(prev); // roll back
+      setOverride(null); // roll back to what is stored
       notify.error(err instanceof Error ? err.message : 'Could not save.');
       return false;
     } finally {

package/src/components/collection/ReviewDrawer.tsx

@@ -45,6 +45,7 @@ import type { CollectionClient, EntityRecord, EntityTypeDef } from './types';
 import { declaredBlob, readData, writeData } from './data';
 import { parseSources } from './drafts';
 import {
+  activeDecisionKey,
   resolveReviewConfig,
   reviewDecisions,
   shouldIgnoreShortcut,
@@ -125,7 +126,19 @@ function ReviewDrawerInner({
   const next = index >= 0 && index + 1 < records.length ? records[index + 1] : null;
 
   const status = fieldStr(data, cfg.statusName);
-  const verdict = fieldStr(data, cfg.verdictAttr);
+  /**
+   * Which decision the record's STATE reflects — the ringed button in the sticky
+   * bar. Off STATUS, not the verdict, for the reason `activeDecisionKey` sets out
+   * (bd startsim-m7fdm.12): the drawer's ring had the same defect as the table's
+   * tick, so a reviewer opening one of the twenty topics the re-rank agent had
+   * marked `good` saw Approve ringed over a record still sitting at `suggested`.
+   *
+   * Fed the drawer's own optimistic `data`, so a decision rings instantly; and
+   * because it reads status, the manual state override below (`overrideStatus`
+   * writes status alone, no verdict) now rings the decision it amounts to
+   * instead of ringing nothing.
+   */
+  const activeKey = useMemo(() => activeDecisionKey(data, cfg, decisions), [data, cfg, decisions]);
   const title = fieldStr(data, cfg.titleAttr) || record.name || `#${record.id}`;
   const summary = fieldStr(data, cfg.summaryAttr);
   const rank = fieldStr(data, cfg.rankAttr);
@@ -339,7 +352,7 @@ function ReviewDrawerInner({
                     <DecisionButton
                       key={d.key}
                       decision={d}
-                      active={verdict !== '' && d.verdict === verdict}
+                      active={d.key === activeKey}
                       busy={busy === `decision:${d.key}`}
                       onClick={() => applyDecision(d)}
                     />

package/src/components/collection/__tests__/review.test.ts

@@ -1,4 +1,6 @@
 import {
+  activeDecisionKey,
+  isTerminalStatus,
   deriveReviewTransitions,
   resolveReviewConfig,
   reviewDecisions,
@@ -10,6 +12,7 @@ import {
   fieldStr,
   DEFAULT_VERDICTS,
 } from '../review';
+import type { ReviewDecision } from '../review';
 import type { AttributeDef, EntityTypeDef } from '../types';
 
 function enumAttr(name: string, choices: string[]): AttributeDef {
@@ -343,3 +346,149 @@ describe('holdAfter — decisions that stay on the record', () => {
     expect(resolveReviewConfig(type, { holdAfter: ['approve'] }).holdAfter).toEqual(['approve']);
   });
 });
+
+/**
+ * The green tick must report the HUMAN's decision, not the AI's verdict (bd
+ * startsim-m7fdm.12).
+ *
+ * The cases are the live OGMC distribution, measured on 171 topics: suggested/-
+ * 100, written/good 31, **suggested/good 20**, rejected/bad 16, written/bad 2,
+ * written/- 1, suggested/edit 1, and ZERO at `ready`. The twenty at
+ * suggested/good are the defect — the n8n re-rank agent wrote `team_verdict`
+ * without touching status, and the table drew a darkened green tick over every
+ * one of them.
+ */
+describe('activeDecisionKey', () => {
+  const topicType = type([
+    enumAttr('status', ['suggested', 'ready', 'rejected', 'written']),
+    textAttr('team_verdict'),
+    textAttr('team_notes'),
+  ]);
+  const topicCfg = resolveReviewConfig(topicType);
+  const topicDecisions = reviewDecisions(topicCfg);
+  const key = (data: Record<string, unknown>) => activeDecisionKey(data, topicCfg, topicDecisions);
+
+  it('a machine-set verdict alone lights NOTHING — the defect, 20 live rows', () => {
+    expect(key({ status: 'suggested', team_verdict: 'good' })).toBeNull();
+  });
+
+  it('and nothing lights on the amber one either — the agent writes `edit` too', () => {
+    // The same lie one button over: "RESOLVED from edit -> good" is the agent's
+    // own prose. Needs work writes status BACK to the entry stage, so it leaves
+    // no trace status can tell apart from untouched.
+    expect(key({ status: 'suggested', team_verdict: 'edit' })).toBeNull();
+  });
+
+  it('an untouched topic lights nothing — 100 live rows, unchanged', () => {
+    expect(key({ status: 'suggested' })).toBeNull();
+  });
+
+  it('approved lights Approve — the state the fix makes reachable', () => {
+    expect(key({ status: 'ready' })).toBe('approve');
+    // and it does NOT depend on the verdict agreeing, or being present at all.
+    expect(key({ status: 'ready', team_verdict: 'bad' })).toBe('approve');
+  });
+
+  it('rejected lights Reject — 16 live rows, unchanged', () => {
+    expect(key({ status: 'rejected', team_verdict: 'bad' })).toBe('reject');
+  });
+
+  it('written still lights Approve — forward past approval, 34 live rows', () => {
+    // A written topic was approved; rendering it undecided would be the same lie
+    // pointing the other way, and with the State column off by default the tick
+    // is the only state a row shows.
+    expect(key({ status: 'written', team_verdict: 'good' })).toBe('approve');
+    expect(key({ status: 'written' })).toBe('approve');
+  });
+
+  it('written/bad lights GREEN where it used to light red — 2 live rows', () => {
+    // A DELIBERATE, surprising-direction change. The agent re-marked two
+    // already-written topics `bad` ("RE-MARKED (was unset, and it was
+    // WRITTEN)"); status says a human approved them and the writer wrote them,
+    // and status is the fact the tick reports.
+    expect(key({ status: 'written', team_verdict: 'bad' })).toBe('approve');
+  });
+
+  it('is independent of the order the caller holds its decisions in', () => {
+    const shuffled = [...topicDecisions].reverse();
+    for (const data of [
+      { status: 'suggested', team_verdict: 'good' },
+      { status: 'ready' },
+      { status: 'rejected' },
+      { status: 'written' },
+    ]) {
+      expect(activeDecisionKey(data, topicCfg, shuffled)).toBe(key(data));
+    }
+  });
+
+  it('ignores an undeclared status rather than guessing', () => {
+    expect(key({ status: 'queued_for_mars' })).toBeNull();
+    expect(key({})).toBeNull();
+  });
+
+  /**
+   * News Item is the path this must not break: it declares NO team_verdict and
+   * passes `verdicts: []`, so it has always resolved by status and must go on
+   * doing exactly that. Its enum runs past `acceptable` into outcomes that are
+   * NOT consequences of accepting — which is why only TERMINAL stages count
+   * forward.
+   */
+  describe('news_item (no verdict vocabulary) is untouched', () => {
+    const newsType = type([
+      enumAttr('status', [
+        'new', 'surfaced', 'acceptable', 'cited', 'ignored', 'rejected', 'preview_only',
+      ]),
+    ]);
+    const newsCfg = resolveReviewConfig(newsType, {
+      approveStatus: 'acceptable',
+      rejectStatus: 'rejected',
+      verdicts: [],
+      omitNeedsWork: true,
+    });
+    const newsDecisions = reviewDecisions(newsCfg);
+    const nk = (status: string) => activeDecisionKey({ status }, newsCfg, newsDecisions);
+
+    it('acceptable → Accept, rejected → Reject', () => {
+      expect(nk('acceptable')).toBe('approve');
+      expect(nk('rejected')).toBe('reject');
+    });
+
+    it('the entry stage and the pre-decision stages light nothing', () => {
+      expect(nk('new')).toBeNull();
+      expect(nk('surfaced')).toBeNull();
+    });
+
+    it('`ignored` / `preview_only` sit AFTER acceptable and still light nothing', () => {
+      // The forward rule is gated on a TERMINAL-reading status for exactly this:
+      // being ignored is a different outcome, not a consequence of accepting.
+      expect(nk('ignored')).toBeNull();
+      expect(nk('preview_only')).toBeNull();
+      expect(nk('cited')).toBeNull();
+    });
+  });
+
+  it('a type with no status enum at all still resolves by verdict', () => {
+    // There, nothing but the buttons themselves writes a verdict, so the verdict
+    // IS the decision. `reviewDecisions` yields none without a status pipeline,
+    // so this asserts the branch directly.
+    const cfg = resolveReviewConfig(type([textAttr('team_verdict')]));
+    const decisions: ReviewDecision[] = [
+      { key: 'approve', label: 'Approve', status: null, verdict: 'good', tone: 'good', advance: true, shortcut: 'a', promptNote: false },
+      { key: 'reject', label: 'Reject', status: null, verdict: 'bad', tone: 'bad', advance: true, shortcut: 'x', promptNote: false },
+    ];
+    expect(activeDecisionKey({ team_verdict: 'good' }, cfg, decisions)).toBe('approve');
+    expect(activeDecisionKey({ team_verdict: 'bad' }, cfg, decisions)).toBe('reject');
+    expect(activeDecisionKey({}, cfg, decisions)).toBeNull();
+  });
+});
+
+describe('isTerminalStatus', () => {
+  it('names the end-of-pipeline stages the forward rule keys off', () => {
+    for (const s of ['written', 'published', 'sent', 'live', 'closed']) {
+      expect(isTerminalStatus(s)).toBe(true);
+    }
+    for (const s of ['suggested', 'ready', 'rejected', 'ignored', 'preview_only', 'cited']) {
+      expect(isTerminalStatus(s)).toBe(false);
+    }
+  });
+});

package/src/components/collection/index.ts

@@ -13,6 +13,8 @@ export {
   resolveReviewConfig,
   deriveReviewTransitions,
   reviewDecisions,
+  activeDecisionKey,
+  isTerminalStatus,
   decisionLabel,
   DEFAULT_DECISION_LABELS,
   applyDecisionToData,

package/src/components/collection/review.ts

@@ -387,6 +387,94 @@ export function applyDecisionToData(
   return declaredBlob(next, declaredNames);
 }
 
+/** True when a status name reads like the END of a pipeline (published/written/sent). */
+export function isTerminalStatus(status: string): boolean {
+  return TERMINAL_RE.test(status);
+}
+
+/**
+ * Which review decision a record's STATE currently reflects — the key of the
+ * button that should render as active, or null when nobody has decided yet.
+ *
+ * STATUS IS THE DECISION; THE VERDICT IS NOT (bd startsim-m7fdm.12). This used
+ * to resolve by verdict first wherever a type declared one, and on OGMC's topics
+ * that made the machine's opinion render as the human's: the n8n re-rank agent
+ * writes `team_verdict` WITHOUT writing status — deliberately, because
+ * startsim-ozpjw.8 stopped an LLM being able to push a record to `ready` on its
+ * own say-so — so 20 of 171 live topics sat at `suggested` while the table drew
+ * a darkened green tick over them. A reviewer reads that as "I approved this".
+ * Nothing had been approved, and a topic at `suggested` is invisible to the
+ * auto-write poll, so those twenty looked done and would never be written.
+ *
+ * The rule, therefore: WHERE A TYPE HAS A STATUS PIPELINE, ONLY STATUS DECIDES
+ * what renders as in force. Status is the one field a human's click writes that
+ * the pipeline agents do not, so it is the only honest record of a human
+ * decision — and that invariant is what guarantees no machine-set verdict can
+ * light any button. `team_verdict` keeps being written (it is the re-rank
+ * agent's input) and keeps being READABLE as its own column; it just stops
+ * impersonating an approval.
+ *
+ * Three cases, resolved in this order so the answer never depends on the order a
+ * caller happens to hold its decisions in:
+ *
+ *  1. EXACT, past the entry stage — the record's status is where some decision
+ *     puts it, and that status exists only because a decision wrote it.
+ *  2. BACK AT THE ENTRY STAGE — a "Needs work" writes status back to the stage
+ *     every record starts on, so it leaves nothing status can tell apart from
+ *     "untouched". On a verdict-bearing type that is rendered as NO decision:
+ *     the agent writes the `edit` verdict too ("RESOLVED from edit -> good"), so
+ *     trusting it here would just move the same lie from the green tick to the
+ *     amber one. On a type with no verdict vocabulary at all (news_item, which
+ *     passes `verdicts: []`) the status match is all there is, and stands.
+ *  3. FORWARD, PAST APPROVAL, TO A TERMINAL STAGE — `ready → written`. The
+ *     approval is still the decision in force; a written topic rendering as
+ *     undecided would be the same lie pointing the other way, and with the State
+ *     column off by default (bd startsim-m7fdm.11) the tick is the only state a
+ *     row shows. Only TERMINAL stages count: news_item declares `ignored` and
+ *     `preview_only` after `acceptable`, and neither is a consequence of
+ *     accepting anything.
+ *
+ * A type with no status enum at all keeps resolving by verdict — there, nothing
+ * but the buttons themselves writes one, so the verdict IS the decision.
+ */
+export function activeDecisionKey(
+  data: Record<string, unknown> | undefined,
+  r: ResolvedReview,
+  decisions: ReviewDecision[] = reviewDecisions(r),
+): string | null {
+  const choices = r.statusChoices;
+
+  // No status pipeline → the verdict is the only place a decision is recorded.
+  if (choices.length === 0) {
+    const v = fieldStr(data, r.verdictAttr);
+    return v ? decisions.find((d) => d.verdict && d.verdict === v)?.key ?? null : null;
+  }
+
+  const status = fieldStr(data, r.statusName);
+  const entry = choices[0];
+
+  // (1) a status past the entry stage is there because a decision wrote it.
+  const exact = decisions.find((d) => !!d.status && d.status !== entry && d.status === status);
+  if (exact) return exact.key;
+
+  // (2) back at the entry stage — indistinguishable from untouched, unless the
+  // type carries no verdict vocabulary and the status match is all there is.
+  const sentBack = decisions.find((d) => !!d.status && d.status === entry);
+  if (sentBack && status === entry) return sentBack.verdict ? null : sentBack.key;
+
+  // (3) forward, past approval, to a terminal stage: still approved.
+  const approve = r.transitions.approve
+    ? decisions.find((d) => d.status === r.transitions.approve)
+    : undefined;
+  if (approve) {
+    const at = choices.indexOf(status);
+    const approveAt = choices.indexOf(r.transitions.approve as string);
+    const rejectAt = r.transitions.reject ? choices.indexOf(r.transitions.reject) : -1;
+    if (at > approveAt && at !== rejectAt && isTerminalStatus(status)) return approve.key;
+  }
+  return null;
+}
+
 // ---- small read helpers used by the component (kept here so they're tested) ----
 
 /** String read of an attr off a record's data blob ('' when missing). */