@kernhq/module-hr 0.14.0 → 0.15.0

package/src/client/pages/ApprovalsPage.svelte

@@ -21,7 +21,7 @@ import DelegationDialog from '../components/DelegationDialog.svelte'
 import { t } from '../i18n.js'
 import type { ApprovalRequest } from '../index.js'
 import { canHr, HR_CAPABILITIES } from '../permissions.js'
-import { hrKeys } from '../query.js'
+import { hrKeys, isoDate } from '../query.js'
 import { summarise } from '../summary.js'
 
 /**
@@ -38,6 +38,13 @@ import { summarise } from '../summary.js'
  * Who signs what is not set here — `approvals.chains.*` is a workspace policy and lives in settings.
  * `approvals.get` is not called either: the inbox already returns each request with its steps and
  * decisions, so a detail fetch would re-ask a question this page has the answer to.
+ *
+ * **A delegate decides here too, and the row says whose decision it is.** `approvals.inbox` already
+ * returns what somebody's delegate may act on — the engine matches a step against the reader *and*
+ * everyone who has delegated to them — but the decision was always filed as the reader's own,
+ * which the server then refused, because the reader is not on that step. Sending `onBehalfOfId` is
+ * what makes those rows decidable, and it is the one input on this page where being wrong writes
+ * the wrong name into an audit trail. So nothing is inferred that is not certain: see `describe`.
  */
 const api = getHrApi()
 const queryClient = useQueryClient()
@@ -47,12 +54,15 @@ const workspace = $derived(session.workspaces.find((w) => w.slug === workspaceSl
 const workspaceId = $derived(workspace?.id ?? '')
 
 let tab = $state('waiting')
-const includeDecided = $derived(tab === 'decided')
+const inboxStatus = $derived(tab === 'decided' ? ('decided' as const) : ('pending' as const))
 
 let deciding = $state<{ request: ApprovalRequest; decision: 'approve' | 'reject' } | null>(null)
 let delegating = $state(false)
 let decideError = $state<string | null>(null)
 
+/** One person this reader may file a decision as: themselves (`null`), or somebody who delegated. */
+type Identity = { onBehalfOfId: string | null; label: string }
+
 /**
  * `submitting` rather than `decide.isPending`: the disabled attribute only reaches the confirm
  * button on the next render, so two quick clicks both fire and one request is decided twice. This
@@ -73,19 +83,183 @@ const hasChains = $derived(session.hasCapability('hr', HR_CAPABILITIES.approvals
 const showDelegation = $derived(hasChains && canHr('approvalDelegate'))
 
 const inboxQuery = createQuery(() => ({
-  queryKey: hrKeys.approvalInbox(workspaceId, includeDecided),
+  queryKey: hrKeys.approvalInbox(workspaceId, inboxStatus),
   enabled: Boolean(workspaceId),
-  queryFn: () => api.approvals.inbox({ workspaceId, limit: 50, includeDecided }),
+  queryFn: () => api.approvals.inbox({ workspaceId, limit: 50, status: inboxStatus }),
 }))
 const items = $derived(inboxQuery.data?.items ?? [])
 
+/**
+ * Which employee the reader is. No permission — `people.me` is the caller's own record, and a
+ * member who has none gets an empty inbox from the server anyway.
+ *
+ * Without it a delegated row cannot be told from one that has not reached the reader's step yet,
+ * which is why every claim below is conditional on it having arrived.
+ */
+const meQuery = createQuery(() => ({
+  queryKey: hrKeys.me(workspaceId),
+  enabled: Boolean(workspaceId),
+  queryFn: () => api.people.me({ workspaceId }),
+}))
+const myPersonId = $derived(meQuery.data?.id ?? null)
+
+/**
+ * The delegations in play, from the same key `DelegationDialog` fills — revoking one there moves
+ * this page without a second request.
+ *
+ * Both halves of `showDelegation` are load-bearing: the procedure sits behind the `approvals`
+ * capability *and* `hr.approval.delegate`, and a delegation cannot exist without the capability, so
+ * a workspace with it off has nothing here to miss.
+ */
+const delegationsQuery = createQuery(() => ({
+  queryKey: hrKeys.delegations(workspaceId),
+  enabled: showDelegation && Boolean(workspaceId),
+  queryFn: () => api.approvals.delegations({ workspaceId }),
+}))
+
+/**
+ * Delegations the reader holds *today*, in the reader's own zone.
+ *
+ * The server asks the same question in its zone, so the two disagree for a few hours at either end
+ * of a delegation's last day. Erring towards offering it is the right way round: the server refuses
+ * what it will not accept, and the refusal says so, whereas hiding the control leaves somebody
+ * covering a colleague with no way to act and nothing on screen to explain it.
+ */
+const heldToday = $derived.by(() => {
+  if (!myPersonId) return []
+  const today = isoDate()
+  return (delegationsQuery.data ?? []).filter(
+    (d) => d.toPersonId === myPersonId && d.startsOn <= today && today <= d.endsOn,
+  )
+})
+
+/** Only once the list has actually arrived is silence about a delegation evidence of anything. */
+const knowsDelegations = $derived(showDelegation && delegationsQuery.isSuccess)
+
+/**
+ * Names for the people behind the ids, and only where a name is needed.
+ *
+ * Steps and decisions carry person ids alone — `hydrateApproval` resolves the requester and nobody
+ * else — so a directory read is what turns "on behalf of 0192…" into a sentence. It is skipped
+ * entirely in the ordinary case of a reader who holds no delegation and is looking at no delegated
+ * decision, which is almost everybody, almost always.
+ *
+ * Not filtered to `active`: the colleague who handed their approvals over is exactly the one likely
+ * to be on leave, and a status filter would drop the one name this page must be able to print.
+ */
+const hasDelegatedDecision = $derived(
+  items.some((r) => r.steps.some((s) => (s.decisions ?? []).some((d) => d.onBehalfOfId))),
+)
+const needsNames = $derived(
+  canHr('personView') && Boolean(workspaceId) && (heldToday.length > 0 || hasDelegatedDecision),
+)
+const peopleQuery = createQuery(() => ({
+  queryKey: hrKeys.people(workspaceId, { forApprovalNames: true }),
+  enabled: needsNames,
+  queryFn: () => api.people.list({ workspaceId, limit: 200 }),
+}))
+const peopleById = $derived(
+  new Map((peopleQuery.data?.items ?? []).map((p) => [p.id, p.displayName] as const)),
+)
+/** A name, or an honest stand-in — never a raw id, which names nobody. */
+const personName = (id: string) => peopleById.get(id) ?? t('approvals_behalf_someone')
+
+/**
+ * Who the reader may decide as on the step this request is actually on, and why they may not.
+ *
+ * The rule is that nothing is claimed without the facts a claim needs: the reader's own person id,
+ * a delegation list that has arrived, and a step that came back with its approvers. Missing any of
+ * them, the page offers exactly what it offered before delegation worked — one decision, the
+ * reader's own — and lets the server be the authority. That fallback is also what keeps the mock
+ * and any older server, whose steps carry no `approverIds`, working unchanged.
+ *
+ * Two things are deliberately excluded rather than offered and refused:
+ * - an identity that has already decided on this step, which the unique index refuses;
+ * - a delegation scoped to another subject type. The contract says `subjectType: null` delegates
+ *   everything and a value delegates that one kind — **`ApprovalService.mayActFor` does not check
+ *   it**, so a leave-only delegate can decide a correction today. This is the narrower of the two
+ *   readings and the one the contract states; the server is where it has to be fixed.
+ */
+function describe(request: ApprovalRequest) {
+  const step = request.steps.find((s) => s.stepIndex === request.currentStep) ?? null
+  const approvers = step?.approverIds ?? []
+  const decisions = step?.decisions ?? []
+  const self: Identity = { onBehalfOfId: null, label: t('approvals_as_self') }
+
+  let identities: Identity[]
+  if (!myPersonId || !knowsDelegations || approvers.length === 0) identities = [self]
+  else {
+    const settled = new Set(decisions.map((d) => d.approverId))
+    identities = approvers.includes(myPersonId) && !settled.has(myPersonId) ? [self] : []
+    const delegators = new Set(
+      heldToday
+        .filter((d) => d.subjectType === null || d.subjectType === request.subjectType)
+        .map((d) => d.fromPersonId),
+    )
+    for (const id of delegators)
+      if (id !== myPersonId && approvers.includes(id) && !settled.has(id))
+        identities.push({ onBehalfOfId: id, label: personName(id) })
+  }
+
+  const only = identities.length === 1 ? identities[0]! : null
+  return {
+    identities,
+    /** The one delegation this row would be decided under, when there is exactly one and no choice. */
+    behalf: only?.onBehalfOfId ? only : null,
+    choice: identities.length > 1,
+    /**
+     * Why a pending row has no buttons. Both were an approve button that always failed: the server
+     * refuses a second decision from the same approver, and refuses anybody who is not on the step
+     * the request has reached.
+     */
+    waiting:
+      request.status === 'pending' && identities.length === 0
+        ? decisions.some((d) => d.approverId === myPersonId)
+          ? ('decided' as const)
+          : ('later' as const)
+        : null,
+    /**
+     * Delegated decisions already recorded. `approverId` is whose decision it is and
+     * `onBehalfOfId` is whose hands it was — the field is named for the *input* to `decide`, which
+     * means the opposite thing, so read them from the schema rather than from the name.
+     */
+    recorded: request.steps.flatMap((s) =>
+      (s.decisions ?? [])
+        .filter((d) => d.onBehalfOfId)
+        .map((d) => ({ actor: personName(d.onBehalfOfId as string), person: personName(d.approverId) })),
+    ),
+  }
+}
+
+const rows = $derived(items.map((item) => ({ item, ...describe(item) })))
+
+/**
+ * The open dialog's view of the request, from the live row where there still is one.
+ *
+ * Derived rather than captured at the click, so a name or a delegation arriving while the dialog is
+ * open reaches it. It falls back to the snapshot the click carried because a refused decision
+ * re-reads the inbox on purpose, and a row that came back decided by somebody else must not take
+ * the refusal's sentence off the screen with it.
+ */
+const decidingView = $derived.by(() => {
+  if (!deciding) return null
+  const open = deciding.request
+  return rows.find((r) => r.item.id === open.id) ?? describe(open)
+})
+
 const decide = createMutation(() => ({
-  mutationFn: (vars: { requestId: string; decision: 'approve' | 'reject'; comment: string }) =>
+  mutationFn: (vars: {
+    requestId: string
+    decision: 'approve' | 'reject'
+    comment: string
+    onBehalfOfId: string | null
+  }) =>
     api.approvals.decide({
       workspaceId,
       requestId: vars.requestId,
       decision: vars.decision,
       comment: vars.comment.trim() || null,
+      onBehalfOfId: vars.onBehalfOfId,
     }),
   onSuccess: () => {
     deciding = null
@@ -94,8 +268,8 @@ const decide = createMutation(() => ({
     // is invalidated rather than guessing which keys moved.
     void queryClient.invalidateQueries({ queryKey: ['hr'] })
   },
-  onError: (error) => {
-    decideError = decideFailure(error)
+  onError: (error, vars) => {
+    decideError = decideFailure(error, vars.onBehalfOfId !== null)
     // A refusal is the server saying its inbox is not the one on screen, so the row behind the
     // dialog is stale as well as the decision. Re-read all of HR exactly as a decision that landed
     // does — without this the same dead row sits in the table and every retry earns the same
@@ -132,9 +306,16 @@ const decideRefusalMessages: Record<string, string> = {}
  * The test is the transport's `code`, never the sentence: `KernError.conflict` is what arrives as
  * CONFLICT, so a refusal added to `decide()` later reaches the reader without anyone editing this
  * file. The same shape as `ClockControls.svelte` and the approvals widget.
+ *
+ * A delegated decision has one refusal worth naming, and it is a FORBIDDEN rather than a conflict:
+ * the delegation the reader was acting under is not one the server can see — usually because it
+ * ended between the page loading and the click. `delegated` is what this client *sent*, not a
+ * sentence parsed back out of the server, so the reader gets a translated instruction instead of
+ * "The decision could not be recorded", which tells somebody covering a colleague nothing.
  */
-function decideFailure(error: unknown): string {
+function decideFailure(error: unknown, delegated: boolean): string {
   const failure = error as { code?: unknown; message?: string; data?: { reason?: unknown } }
+  if (delegated && failure.code === 'FORBIDDEN') return t('decide_behalf_error')
   if (failure.code !== 'CONFLICT') return t('decide_error')
   const reason = typeof failure.data?.reason === 'string' ? failure.data.reason : null
   const key = reason ? decideRefusalMessages[reason] : undefined
@@ -150,10 +331,15 @@ const ask = (request: ApprovalRequest, decision: 'approve' | 'reject') => {
   deciding = { request, decision }
 }
 
-const confirmDecision = (comment: string) => {
+/**
+ * `onBehalfOfId` comes from the dialog, which will not confirm until it has one it can name. A
+ * decision filed against the wrong person is the worst thing this screen can do, so the identity
+ * travels with the click rather than being read back out of state here.
+ */
+const confirmDecision = (comment: string, onBehalfOfId: string | null) => {
   if (!deciding || submitting) return
   submitting = true
-  decide.mutate({ requestId: deciding.request.id, decision: deciding.decision, comment })
+  decide.mutate({ requestId: deciding.request.id, decision: deciding.decision, comment, onBehalfOfId })
 }
 
 const SUBJECT_LABELS: Record<string, () => string> = {
@@ -209,7 +395,7 @@ const stepOf = (request: ApprovalRequest) =>
   </div>
 
   <SectionLabel
-    label={includeDecided ? t('approvals_decided') : t('approvals_waiting')}
+    label={inboxStatus === 'decided' ? t('approvals_decided') : t('approvals_waiting')}
     count={formatCount(items.length, 999)}
   />
 
@@ -229,32 +415,55 @@ const stepOf = (request: ApprovalRequest) =>
         <span role="columnheader">{t('approvals_request')}</span>
         <span role="columnheader">{t('approvals_requested_by')}</span>
         <span role="columnheader">{t('approvals_requested')}</span>
-        <span role="columnheader">{includeDecided ? t('status') : t('approvals_step')}</span>
+        <span role="columnheader">{inboxStatus === 'decided' ? t('status') : t('approvals_step')}</span>
         <span class="sr-only" role="columnheader">{t('approvals_actions')}</span>
       </div>
-      {#each items as item (item.id)}
+      {#each rows as row (row.item.id)}
         <div class="trow" role="row">
           <span class="cell what" role="cell">
-            <Badge tone="grey">{subjectLabel(item.subjectType)}</Badge>
-            <span class="summary">{summarise(item)}</span>
+            <span class="line">
+              <Badge tone="grey">{subjectLabel(row.item.subjectType)}</Badge>
+              <span class="summary">{summarise(row.item)}</span>
+            </span>
+            <!--
+              Whose decision this is, on the row rather than only in the dialog: somebody clearing an
+              inbox of six rows should not have to open one to find out that two of them are a
+              colleague's. A pending row says what the click would file; a decided one says what was
+              filed, which is the other half of the same promise.
+            -->
+            {#if row.behalf}
+              <Badge tone="info">{t('approvals_on_behalf', { name: row.behalf.label })}</Badge>
+            {:else if row.choice}
+              <Badge tone="info">{t('approvals_behalf_pick')}</Badge>
+            {:else if row.recorded.length > 0}
+              {#each row.recorded as entry, i (i)}
+                <span class="behalf">
+                  {t('approvals_decided_behalf', { actor: entry.actor, person: entry.person })}
+                </span>
+              {/each}
+            {/if}
           </span>
-          <span class="cell muted" role="cell">{item.requesterName ?? '—'}</span>
-          <span class="cell muted" role="cell">{formatDateTime(item.requestedAt)}</span>
+          <span class="cell muted" role="cell">{row.item.requesterName ?? '—'}</span>
+          <span class="cell muted" role="cell">{formatDateTime(row.item.requestedAt)}</span>
           <span class="cell" role="cell">
-            {#if includeDecided}
-              <Badge tone={STATUS_TONES[item.status] ?? 'grey'}>
-                {STATUS_LABELS[item.status]?.() ?? item.status}
+            {#if inboxStatus === 'decided'}
+              <Badge tone={STATUS_TONES[row.item.status] ?? 'grey'}>
+                {STATUS_LABELS[row.item.status]?.() ?? row.item.status}
               </Badge>
-            {:else if item.steps.length > 1}
-              <span class="muted">{stepOf(item)}</span>
+            {:else if row.item.steps.length > 1}
+              <span class="muted">{stepOf(row.item)}</span>
             {/if}
           </span>
           <span class="cell actions" role="cell">
-            {#if item.status === 'pending'}
-              <Button size="sm" variant="secondary" onclick={() => ask(item, 'reject')}>
+            {#if row.item.status === 'pending' && row.identities.length > 0}
+              <Button size="sm" variant="secondary" onclick={() => ask(row.item, 'reject')}>
                 {t('reject')}
               </Button>
-              <Button size="sm" onclick={() => ask(item, 'approve')}>{t('approve')}</Button>
+              <Button size="sm" onclick={() => ask(row.item, 'approve')}>{t('approve')}</Button>
+            {:else if row.waiting}
+              <span class="muted">
+                {row.waiting === 'decided' ? t('approvals_you_decided') : t('approvals_later_step')}
+              </span>
             {/if}
           </span>
         </div>
@@ -269,8 +478,8 @@ const stepOf = (request: ApprovalRequest) =>
   {:else}
     <EmptyState
       icon="check-check"
-      title={includeDecided ? t('approvals_decided_none') : t('approvals_none')}
-      description={includeDecided ? t('approvals_decided_none_desc') : t('approvals_none_desc')}
+      title={inboxStatus === 'decided' ? t('approvals_decided_none') : t('approvals_none')}
+      description={inboxStatus === 'decided' ? t('approvals_decided_none_desc') : t('approvals_none_desc')}
     />
   {/if}
 
@@ -287,6 +496,7 @@ const stepOf = (request: ApprovalRequest) =>
 <DecisionDialog
   request={deciding?.request ?? null}
   decision={deciding?.decision ?? 'approve'}
+  identities={decidingView?.identities ?? []}
   pending={submitting}
   error={decideError}
   onConfirm={confirmDecision}
@@ -349,10 +559,29 @@ const stepOf = (request: ApprovalRequest) =>
   text-overflow: ellipsis;
   white-space: nowrap;
 }
+/*
+  A column, not a row: the subject and its sentence sit on one line and the delegation note under
+  it, so a name long enough to matter cannot push the summary out of the cell.
+*/
 .what {
+  display: flex;
+  flex-direction: column;
+  justify-content: center;
+  align-items: flex-start;
+  gap: 4px;
+}
+.line {
   display: flex;
   align-items: center;
   gap: 8px;
+  min-width: 0;
+  max-width: 100%;
+  overflow: hidden;
+}
+.behalf {
+  font-size: 12px;
+  /* A colour, not opacity — this line names a person and has to stay readable. */
+  color: var(--kern-ink-500);
 }
 .summary {
   min-width: 0;

package/src/client/pages/DirectoryPage.svelte

@@ -25,7 +25,7 @@ import { getHrApi } from '../api-instance.js'
 import DecisionDialog from '../components/DecisionDialog.svelte'
 import PersonFormDialog from '../components/PersonFormDialog.svelte'
 import PersonPanel from '../components/PersonPanel.svelte'
-import { personnelVisibility } from '../components/redaction.js'
+import { personnelWithheld } from '../components/redaction.js'
 import { t } from '../i18n.js'
 import type { ApprovalRequest } from '../index.js'
 import { canHr, HR_CAPABILITIES } from '../permissions.js'
@@ -276,7 +276,7 @@ const balancesQuery = createQuery(() => ({
 const inboxQuery = createQuery(() => ({
   queryKey: hrKeys.approvalInbox(workspaceId),
   enabled: Boolean(workspaceId),
-  queryFn: () => api.approvals.inbox({ workspaceId, limit: 6, includeDecided: false }),
+  queryFn: () => api.approvals.inbox({ workspaceId, limit: 6, status: 'pending' }),
 }))
 const waiting = $derived(inboxQuery.data?.items ?? [])
 
@@ -434,12 +434,15 @@ const started = (iso: string | null) =>
  * and it arrives here as a null like any other — so the em dash this column drew for it said
  * "never started", about everybody in the company, to every colleague without a widening key.
  *
- * `personnelVisibility` answers `unknown` for a reader whose scope only the server can resolve, and
- * an unknown row keeps the dash: a dash over an empty field is imprecise, and "Hidden" over one is
- * a lie. Both are marked once, under the table, rather than per row.
+ * The record says which it is — `personnelHidden`, set at the one place that does the nulling — so
+ * a row is marked only when the server actually withheld it, and a genuinely empty hire date keeps
+ * its dash. Marked once, under the table, rather than per row.
+ *
+ * The `!person.hiredOn` half stays deliberately: the mark only ever goes over a value that is
+ * absent, so a stale or unrecognised payload can never paint "Hidden" across data on screen.
  */
-const startWithheld = (person: { userId: string | null; hiredOn: string | null }) =>
-  !person.hiredOn && personnelVisibility(person) === 'withheld'
+const startWithheld = (person: { hiredOn: string | null; personnelHidden?: boolean }) =>
+  !person.hiredOn && personnelWithheld(person)
 
 /** Whether anything on the page is actually marked — the sentence must not outlive the marks. */
 const anyWithheld = $derived(people.some(startWithheld))

package/src/client/permissions.ts

@@ -22,19 +22,9 @@ export function canHr(permission: HrPermission): boolean {
   return session.can(HR_PERMISSIONS[permission])
 }
 
-/**
- * Whether the viewer reads the personnel record behind a directory card, for anybody but themselves.
- *
- * Not "can they open somebody else's page" — everybody can, and should. `hr.person.view` is a
- * `member` default and the directory is meant to be read. What the three widening keys decide is
- * how much of each person comes back: personal email, phone, hire date and termination date are the
- * personnel record, and the server nulls all four for anybody outside the reader's scope.
- *
- * The three do not imply one another — a country HR manager must not silently become a global one —
- * so a screen asks the union once, here. It is only a hint: which *people* fall inside a team or an
- * office is resolved on the server from the org chart, so a screen may not conclude from `true`
- * that a particular person's record is readable. Render what came back; use this to decide whether
- * a "personal details" section is worth offering at all.
- */
-export const canSeeFullRecords = (): boolean =>
-  canHr('personViewTeam') || canHr('personViewOffice') || canHr('personViewAll')
+// No union helper over the three person-visibility keys. There has been one here twice —
+// `canSeeOthers`, then `canSeeFullRecords` — and both were dead the whole time, because the question
+// a screen actually has is "was *this* record withheld", and the answer to that is on the record:
+// `Person.personnelHidden`, set by the server at the one place that does the nulling. A client-side
+// union can only say "the reader holds one of three keys somewhere", which is never enough to decide
+// what to draw over one person's phone number. See `components/redaction.ts`.

package/src/client/query.ts

@@ -35,8 +35,8 @@ export const hrKeys = {
    * pending on, the decided one is history — so sharing a key would show one tab the other's
    * contents for as long as the refetch takes.
    */
-  approvalInbox: (ws: string, includeDecided = false) =>
-    ['hr', 'approvals', ws, includeDecided ? 'decided' : 'waiting'] as const,
+  approvalInbox: (ws: string, status: 'pending' | 'decided' = 'pending') =>
+    ['hr', 'approvals', ws, status] as const,
   delegations: (ws: string) => ['hr', 'delegations', ws] as const,
   calendar: (ws: string, id: string) => ['hr', 'calendar', ws, id] as const,
   calendarWorkingDays: (ws: string, calendarId: string, from: string, to: string) =>

package/src/client/widgets/ApprovalsWidget.svelte

@@ -22,7 +22,7 @@ const queryClient = useQueryClient()
 const inboxQuery = createQuery(() => ({
   queryKey: hrKeys.approvalInbox(workspaceId),
   enabled: Boolean(workspaceId),
-  queryFn: () => api.approvals.inbox({ workspaceId, limit: 5, includeDecided: false }),
+  queryFn: () => api.approvals.inbox({ workspaceId, limit: 5, status: 'pending' }),
 }))
 const items = $derived(inboxQuery.data?.items ?? [])
 

package/src/contract/router.ts

@@ -1132,10 +1132,19 @@ export const hrContract = {
 
   // ---------------------------------------------------------------- approvals
   approvals: {
-    /** Everything waiting on the caller, across every subject type. */
+    /**
+     * Everything waiting on the caller, across every subject type — or everything they have
+     * already settled.
+     *
+     * `status` rather than the `includeDecided` boolean it replaces. That flag was *inclusive*
+     * ("also give me the decided ones") while every caller used it as an exclusive two-tab switch,
+     * so the screen's "Decided" tab asked for decided-as-well and got pending rows listed under a
+     * heading that said somebody had decided them. Both halves read correctly on their own, which
+     * is why it survived: an enum makes the two tabs exactly what they say.
+     */
     inbox: baseContract
       .route({ method: 'GET', path: '/approvals/inbox', tags: t })
-      .input(ws.extend({ ...PageInput.shape, includeDecided: z.boolean().default(false) }))
+      .input(ws.extend({ ...PageInput.shape, status: z.enum(['pending', 'decided']).default('pending') }))
       .output(page(ApprovalRequest)),
     get: baseContract
       .route({ method: 'GET', path: '/approvals/{requestId}', tags: t })