Skip to content

fix(hold): no stale 'Lane held' alert when a ruling is already queued; prose ruling claims require affirmative language - #643

Open
HenryLach wants to merge 2 commits into
mainfrom
fix/hold-alert-and-trailer
Open

fix(hold): no stale 'Lane held' alert when a ruling is already queued; prose ruling claims require affirmative language#643
HenryLach wants to merge 2 commits into
mainfrom
fix/hold-alert-and-trailer

Conversation

@HenryLach

@HenryLach HenryLach commented Sep 9, 2026

Copy link
Copy Markdown
Owner

Both from the first live exercise of the held state (penster 20260909T000015,
two holds, both chains intact end to end):

  1. The escalation reaches the supervisor live (mail recognition), so a fast
    ruling is often in the inbox before the worker exits. awaitHoldResolution
    published the held alert on entry and consumed the ruling one poll later —
    a stale-looking alert after the release. Peek once: if every open hold has
    a valid queued ruling, log 'Ruling already queued' and skip the publication.

  2. isProseRulingClaim: 'hold(TP-1919): record HARD HOLD … pending operator
    ruling' is bookkeeping, not a claim. Claims must be affirmative (R###,
    verdict token, per/apply/implement/as-ruled language); pending/awaiting/
    requesting/hold language is exempt unless a verdict token is present.
    The TP-2037 commit still flags.

Tests: runner regression (queued ruling → release with no 'Lane held' alert),
11-case claim/bookkeeping matrix. 4118 pass.

Also covers penster 20260911T234647 field-report items B (stale Lane held alerts replayed after release, incl. the post-resume EXPIRED one — the queued-ruling peek suppresses them) and the prose-claim half of F (ruling-independent hold-time vocabulary no longer flags).

…; prose ruling claims require affirmative language

Both from the first live exercise of the held state (penster 20260909T000015,
two holds, both chains intact end to end):

1. The escalation reaches the supervisor live (mail recognition), so a fast
   ruling is often in the inbox before the worker exits. awaitHoldResolution
   published the held alert on entry and consumed the ruling one poll later —
   a stale-looking alert after the release. Peek once: if every open hold has
   a valid queued ruling, log 'Ruling already queued' and skip the publication.

2. isProseRulingClaim: 'hold(TP-1919): record HARD HOLD … pending operator
   ruling' is bookkeeping, not a claim. Claims must be affirmative (R###,
   verdict token, per/apply/implement/as-ruled language); pending/awaiting/
   requesting/hold language is exempt unless a verdict token is present.
   The TP-2037 commit still flags.

Tests: runner regression (queued ruling → release with no 'Lane held' alert),
11-case claim/bookkeeping matrix. 4118 pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant