§4d's plain-panel ladder can never reach its third rung on an owned job #236
Labels
No labels
adr
android
area/calendar
area/design-system
area/i18n
area/jobs
area/offline
area/server
area/testing
bug
ci
duplicate
enhancement
help wanted
invalid
notifications
question
reliability
security
severity/low
severity/medium
tracking
web
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
eagraiclainne/app#236
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
JobCard.tsx's plain panel (a job with no sub-jobs) documents a three-rungfallback ladder — description → owner → repeat rule — and delivers two.
The chain is only entered when the job is not up-for-grabs, which means
ownerUid !== ""— precisely rung 2's own condition. Rung 3 can never be tried.What a household sees: a repeating chore with no description, on your own
board, shows
Who it's for: <you>— telling you something the board alreadytold you — where the repeat cadence would be the more useful thing to say when
there is nothing else.
The repeat-rule fallback does render, but only in the up-for-grabs branch, as the
second rung of a different two-rung ladder (description → repeat).
The decision
Either the comment is wrong and should describe the real ladders, or the owner
rung should defer to the repeat text when the reader already knows whose job it
is. That is a design call rather than a tidy-up, which is why the code was left
alone.
Worth noting the ladder was pinned by fixtures and goldens throughout the card
work and neither caught this: no case exercises an owned, repeating, undescribed
job with no sub-jobs, because the unreachable branch meant no expected output
ever differed.