fix(web): show Monitoring on board cards instead of Working by omegent-app[bot] · Pull Request #356 · patroza/t3code

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

omegent-app · 2026-08-06T07:47:20Z

Answering "is Monitoring properly adopted" — almost. Three of four surfaces were fine; board
cards were not, and that was my sync resolution.

Audit

Surface	Before this PR
v1 sidebar pill (`resolveThreadStatusPill`)	✅ `label: "Monitoring"`, `pulse: false`
v2 sidebar row (`SidebarV2.tsx`)	✅ `label: "Monitoring"`, no icon, no shimmer
Board column bucketing (`Board.logic.ts`)	✅ `Monitoring` → working bucket
Board card (`resolveSidebarV2TopStatus`)	❌ rendered as Working, with the shimmer

resolveSidebarV2Status correctly returns "monitoring", and SidebarV2Status carries it — but
resolveSidebarV2TopStatus, which BoardCard reads, folded it into Working.

Why that was wrong

Not merely a cosmetic mismatch. Both other surfaces suppress motion for monitoring on purpose:

v1 pill: pulse: false for monitoring vs pulse: true for working.
v2 row: "Steady label, no duty-cycled shimmer: monitoring is calm background presence, not active
progress (monitoring-pill D6)."

A board card gave a watch loop animate-sidebar-working-text — the active-progress shimmer — which
is exactly the treatment that design note exists to prevent.

Cause

Mine, from the #345 import. The union was "Working" | "Approval" | "Input" | "Failed" | "Done" with
no Monitoring member, and I folded the case in rather than widening it, with the comment "reads as
Working rather than inventing one". Widening was the right call — the label already existed in two
other surfaces, so it was not an invention.

Change

Widen the union and give monitoring the v2 row's calm styling. Board bucketing is untouched:
Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting
review.

Validation

Sidebar.logic.test.ts: 121 tests pass, including two new ones asserting monitoring is calm
and working still animates, so the two cannot silently collapse again.
Full recursive typecheck clean — the widened union has no other unhandled consumers.

Co-authored by @patroza

opened by Patrick Roza in chat thread Discord · Discord · T3

The upstream import wired backgroundLiveness through the v1 pill and the v2 sidebar row, both of which render Monitoring as a distinct, deliberately calm state: the v1 pill sets pulse: false, and the v2 row uses a steady label with no duty-cycled shimmer per monitoring-pill D6. resolveSidebarV2TopStatus, which board cards read, was left folding monitoring into Working during that import because its label union had no Monitoring member. A watch loop therefore rendered on a board card with the active-progress shimmer -- precisely the treatment the other two surfaces avoid on purpose. Widen the union and give monitoring the same calm styling the v2 row uses. Board column bucketing is unchanged: Monitoring stays in the working bucket, since a monitoring thread is live rather than awaiting review. Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza merged commit 912340b into fork/devAug 6, 2026
5 checks passed

Conversation

omegent-appBot commented Aug 6, 2026

Audit

Why that was wrong

Cause

Change

Validation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Audit

Why that was wrong

Cause

Change

Validation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Audit

Why that was wrong

Cause

Change

Validation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Audit

Why that was wrong

Cause

Change

Validation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

omegent-appBot commented Aug 6, 2026

Audit

Why that was wrong

Cause

Change

Validation

Uh oh!

Uh oh!

Reviewers

Assignees

Labels