fix(views): a resolved case is not at risk — sla_at_risk selects on live work

[os-trump]

Fixes #1325

Description

The ⏰ SLA at Risk tab selected on is_closed == false. That flag is derived by
case_sla_defaults as effStatus === 'closed' (src/objects/case.hook.ts) and never
flips on resolved — while case_sla_monitor, the flow that owns SLA breach
detection, has always filtered status: { $nin: ['resolved', 'closed'] }
(src/flows/case-sla-monitor.flow.ts).

So the two surfaces disagreed about the same case: the sweep would not flag a resolved
case as breached, and the tab still listed that case for a service agent to pick up. An
agent working the queue could be handed work the automation that owns SLA had already
decided was finished. That is the surface a human reads contradicting the surface that
acts — a defect, not an untidiness, and this is the distinction that separates it from
the sibling views.

The view now carries the predicate the producer already answered with, spelled in the
view layer as operator: 'not_in'. $nin is the lowered AST form and is not
authorable in a view filter[]; parseFilterAST(['status','not_in',[...]]) lowers to
exactly { status: { $nin: [...] } }.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Related Issues

• A resolved unowned case sits in Unassigned — triage forever: the tab filters is_closed, which only flips on closed #1145 / fix(service): the triage tab and its sharing rule mean live work, not not-yet-closed #1323 — the ruling, the shape, and the parity guard this change extends.
• [Decision] Which of the three remaining is_closed == false consumers should follow #1145 — one is a view label question, two hand a manager and a director standing access to resolved cases #1328 — the decision card for my_open_cases and the two critical-escalation sharing
  rules. Deliberately untouched here and still open; this PR is not part of that
  decision.

Changes Made

• src/views/case.view.ts — sla_at_risk selects on
  { field: 'status', operator: 'not_in', value: ['resolved', 'closed'] }. The priority
  half (high / critical) is unchanged.
• test/live-work-predicate-parity.test.ts — the two-sided edit the guard requires.
  sla_at_risk moves out of the boundary roster (NOT_LIVE_WORK) and into the consumer
  roster (LIVE_WORK_CONSUMERS), and is added to the is_closed offender sweep. The
  boundary roster's header records why this one entry left it and why the remaining three
  must not follow it on the strength of this PR.
• test/sla-at-risk-live-work.test.ts — new behavioural half.
• .changeset/sla-at-risk-is-live-work.md — a real changeset: this narrows what an
  author-visible tab shows.

Testing

Gate chain pnpm verify green on cd5620a (the commit this PR is opened at):
validate, typecheck, lint, lint:i18n-gate, hygiene, hygiene:tokens, build,
test — 142 test files passed, 2993 passed / 1 skipped.

pnpm hygiene:tokens is green and the interaction layer is unmoved in the way that
matters to #1321: interaction layer ~37,431 tokens (ceiling ~40,000; headroom ~2,569).

The behavioural pin runs the SHIPPED view filter, lowered through the platform's own
parseFilterAST, against a real engine on both drivers (driver-memory, which stores
only written columns, and sqlite-wasm, which materialises every declared column — the
absent-vs-NULL axis a boolean gets wrong). Its fixture does not assert is_closed — it
runs the shipped case_sla_defaults handler through test/helpers/hook-harness.ts and
stores what the app itself derives, so "would otherwise qualify" is a measurement rather
than a fiction of the test. A dedicated case then proves that claim by running the OLD
is_closed == false spelling over the same rows and showing the resolved case coming
back.

Reverse-verification. The filter was reverted on a committed tree, the mutation was
proven to have reached disk before any verdict was read (git hash-object moved
52e5c65 → b1e6140; the anchor matched exactly once; the on-disk line counts moved as
predicted), and the guard went red naming this consumer in three separate assertions
rather than merely red:

• every named consumer resolves — sla_at_risk (view filter[] — src/views/case.view.ts)
• sla_at_risk excludes exactly CLOSED_CASE_STATUSES — expected [] to deeply equal [ 'closed', 'resolved' ]
• no live-work consumer keys the concept on is_closed — sla_at_risk (view filter)

plus both driver blocks of the behavioural half:
expected [ 'live-critical', 'resolved-high' ] to not include 'resolved-high'.

The tree was then restored with git checkout HEAD -- PATH (the bare form restores from
the index, which is the mutation) and the restore proven byte-identical: git diff HEAD
empty and the blob hash back to 52e5c65.

One earlier run of that same procedure stopped rather than reporting, because the
predicted on-disk line count did not match. The mutation had in fact landed; the
expectation was miscalibrated (one of the three is_closed filters is written on a single
line and never matched the indented pattern). Recorded because the stop is the reason the
reading above can be trusted.

• Unit tests pass
• Linting passes
• Build succeeds
• New tests added

Checklist

• I have added a changeset
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective
• New and existing unit tests pass locally with my changes

Additional Notes

Deliberately out of scope, each for a different reason:

• case_workflow — measured on fix(service): the triage tab and its sharing rule mean live work, not not-yet-closed #1323 and ruled a deliberate non-consumer. Its columns come
  from the status field's own options, so resolved is a real column on that kanban and
  is where a card lands when an agent drags one across. Excluding it would turn the resolve
  gesture's destination into a hole. Not re-opened here.
• my_open_cases, src/sharing/case.sharing.ts:15 and :32 — the open decision card
  [Decision] Which of the three remaining is_closed == false consumers should follow #1145 — one is a view label question, two hand a manager and a director standing access to resolved cases #1328. Not touched, and the parity guard still pins their current shape by name, so a
  later change to them stays visible instead of arriving as a silent widening.

The scope of this PR is one view. It is the one entry on that boundary roster that turned
out not to be a judgement call, because a producer had already answered the same question.

Generated by Claude Code

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 26, 2026 7:53am