@kernhq/module-hr 0.14.1 → 0.16.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

@@ -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 ?? [])
 

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

@@ -14,18 +14,82 @@ import { summarise } from '../summary.js'
  * Acting on a row rather than linking away from it: the whole value of this card is approving three
  * leave requests without leaving the dashboard, and a card that only counts them is a link with
  * extra steps.
+ *
+ * **A button here only where the decision is certainly the reader's own.** `approvals.inbox` also
+ * returns rows the reader may decide *as somebody's delegate*, and rows resting on a step further
+ * down a chain they are named on. `approvals.decide` refuses both when the decision is filed as the
+ * reader — which is what every approve button on this card did to them — so neither gets one. Which
+ * of the two a row is, and whose name the decision would carry, is what the approvals page has the
+ * queries and the room to say; this card sends the reader there rather than guessing. See
+ * `actionFor`.
  */
-const { workspaceId, editing }: WidgetProps = $props()
+const { workspaceId, workspaceSlug, editing }: WidgetProps = $props()
 const api = getHrApi()
 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 ?? [])
 
+/**
+ * Which employee the reader is — the one fact that separates a row this card may decide from one it
+ * may only point at.
+ *
+ * No permission: `people.me` is the caller's own record, and somebody with none gets an empty inbox
+ * from the server anyway. The same key the approvals page fills, so opening one warms the other.
+ */
+const meQuery = createQuery(() => ({
+  queryKey: hrKeys.me(workspaceId),
+  enabled: Boolean(workspaceId),
+  queryFn: () => api.people.me({ workspaceId }),
+}))
+const myPersonId = $derived(meQuery.data?.id ?? null)
+
+/** What this card may offer on a row. */
+type RowAction =
+  /** The reader's own decision, on the step the request has reached. */
+  | 'decide'
+  /** Theirs, and already made — a step still collecting its other approvers. */
+  | 'decided'
+  /** Not the reader's own: whose it is, and whether it can be filed at all, belongs to the page. */
+  | 'elsewhere'
+
+/**
+ * Whether this card may file the decision on a row, and never as whom.
+ *
+ * A reduced form of `describe()` in `pages/ApprovalsPage.svelte`, which stays the authority: that
+ * one derives every identity the reader may file as — themselves, and each colleague who delegated
+ * to them — out of `people.me`, the live delegations and the step's `approverIds`, and hands them to
+ * `DecisionDialog` to be stated or chosen. This asks only the half a dashboard card can answer
+ * honestly on one line: **is this decision the reader's own?**
+ *
+ * The other half is deliberately not asked here. Naming a delegator needs the delegations list —
+ * behind the `approvals` capability *and* `hr.approval.delegate`, so a reader holding a delegation
+ * but not that key would learn nothing and be offered a decision as themselves, which is the refusal
+ * this file exists to stop — plus a directory read for the name, and then a second line to print it
+ * on, in a card whose smallest size is one 43px row. A decision filed under a person the reader was
+ * never shown is the worst thing this module can do, so a row this card cannot name is a link.
+ *
+ * The fallback is the page's, for the same reason: with no `myPersonId` yet, or against a server
+ * whose steps carry no `approverIds`, nothing is claimed and the card offers exactly what it offered
+ * before — the reader's own decision, with the server as the authority.
+ */
+function actionFor(request: ApprovalRequest): RowAction {
+  const step = request.steps.find((s) => s.stepIndex === request.currentStep) ?? null
+  const approvers = step?.approverIds ?? []
+  if (!myPersonId || approvers.length === 0) return 'decide'
+  if (!approvers.includes(myPersonId)) return 'elsewhere'
+  // The unique index on `(step_id, approver_id)` refuses a second decision from the same person, so
+  // an approve button on a step this reader has already settled is one that can only fail. It is a
+  // real row: an `all` step stays pending until everybody named on it has answered.
+  return (step?.decisions ?? []).some((d) => d.approverId === myPersonId) ? 'decided' : 'decide'
+}
+
+const rows = $derived(items.map((item) => ({ item, action: actionFor(item) })))
+
 let asked = $state<{ request: ApprovalRequest; decision: 'approve' | 'reject' } | null>(null)
 let decideError = $state<string | null>(null)
 
@@ -43,6 +107,10 @@ const decide = createMutation(() => ({
       requestId: vars.requestId,
       decision: vars.decision,
       comment: vars.comment.trim() || null,
+      // Stated rather than left out. The field is nullish, so both reach the server the same way —
+      // but this card offers no other identity, and `null` is that promise written where the call
+      // is made rather than inferred from the absence of a line.
+      onBehalfOfId: null,
     }),
   onSuccess: () => {
     asked = null
@@ -79,9 +147,17 @@ const decideRefusalMessages: Record<string, string> = {}
  * those happened, so it is repeated verbatim. Everything else that can fail carries machine text in
  * English, so it falls back to this module's own string. The test is the transport's `code`, never
  * the sentence.
+ *
+ * FORBIDDEN has its own, because this card no longer offers a decision that earns one by design:
+ * `actionFor` keeps the buttons on the steps the reader is named on, so a refusal means the step
+ * moved between the card being drawn and the click. The router's words for it — "You are not an
+ * approver on this step" — are machine text in English, and the only other FORBIDDEN `decide` can
+ * raise is for a caller with no employee record, whose inbox is empty and who therefore has nothing
+ * on this card to click.
  */
 function decideFailure(error: unknown): string {
   const failure = error as { code?: unknown; message?: string; data?: { reason?: unknown } }
+  if (failure.code === 'FORBIDDEN') return t('decide_moved_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
@@ -107,25 +183,49 @@ const confirmDecision = (comment: string) => {
   while `data` is still the last good inbox — an error branch above this one would blank a working
   card, and take its approve buttons with it, on a transient failure. The error is only the whole
   card when there is nothing else to draw.
+
+  `people.me` is waited for alongside the inbox, though. It decides which rows get buttons, and
+  drawing an approve button on a colleague's row for one frame and then taking it away is worse than
+  a skeleton that lasts as long — the two queries go out together, so it costs nothing. A `me` that
+  *fails* leaves `myPersonId` null, which is the fallback `actionFor` documents rather than a card
+  stuck loading.
 -->
-{#if inboxQuery.isLoading}
+{#if inboxQuery.isLoading || meQuery.isLoading}
   <Skeleton height="96px" />
-{:else if items.length > 0}
+{:else if rows.length > 0}
   <ul>
-    {#each items as item (item.id)}
+    {#each rows as row (row.item.id)}
       <li>
-        <span class="summary">{summarise(item)}</span>
+        <span class="summary">{summarise(row.item)}</span>
         <!-- Row actions go while the grid is being rearranged: the data stays, the buttons do not. -->
         {#if editing}
           <Badge tone="upcoming">{t('leave_pending')}</Badge>
-        {:else}
+        {:else if row.action === 'decide'}
           <!--
             Never straight to `decide.mutate`: rejecting somebody's leave is irreversible from the
             interface and notifies them, and a dashboard card is the easiest place in the product to
             hit the wrong button. The dialog says what the decision does and to whom.
           -->
-          <Button size="sm" variant="ghost" onclick={() => ask(item, 'reject')}>{t('reject')}</Button>
-          <Button size="sm" onclick={() => ask(item, 'approve')}>{t('approve')}</Button>
+          <Button size="sm" variant="ghost" onclick={() => ask(row.item, 'reject')}>{t('reject')}</Button>
+          <Button size="sm" onclick={() => ask(row.item, 'approve')}>{t('approve')}</Button>
+        {:else if row.action === 'decided'}
+          <span class="note">{t('approvals_you_decided')}</span>
+        {:else}
+          <!--
+            A link, not a button. This row is either a colleague's decision the reader holds by
+            delegation or a step the request has not reached them on, and the card cannot tell which
+            without the queries the approvals page makes — so it offers the one thing that is true
+            either way. The label carries it: an icon-only arrow here would be a control a screen
+            reader announces as "link" and nothing more.
+          -->
+          <Button
+            size="sm"
+            variant="ghost"
+            href={`/${workspaceSlug}/hr/approvals`}
+            title={t('approvals_open_hint')}
+          >
+            {t('approvals_open')}
+          </Button>
         {/if}
       </li>
     {/each}
@@ -182,6 +282,17 @@ li {
   white-space: nowrap;
   font-size: 12px;
 }
+/*
+  Where a row's buttons would have been. `--kern-ink-600` rather than the `--kern-ink-500` the
+  approvals page mutes with: this sits on the card surface, which is the pair already measured for
+  `.msg` below — 9.86:1 in light, 8.96:1 in dark. Nowrap because the row is one line at every size
+  the card declares, and a wrapped word here is what pushes an `s` card past its 43px body.
+*/
+.note {
+  font-size: 12px;
+  white-space: nowrap;
+  color: var(--kern-ink-600);
+}
 .failed {
   display: flex;
   align-items: center;

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 })