You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up from PM acceptance of #190. Pre-existing defect, unrelated to that
diff (#190 touched no frontend/ or CSS file); it was simply made visible by
the first screenshot of the Docs surface with a populated corpus.
Observed
Screenshot: .tmp/screenshots/issue-190/worktree-processes.png (identical copy
at clean-worktree-processes.png), captured at #/processes.
Bold labels and their following text render with no separator, producing
run-together strings:
Processes support workUse internal Process Docs from Task or Card context first.
No findings match filtersChange filters to inspect other process quality findings.
Synthetic Characterization ScheduleSynthetic reference used only by browser characterization tests. (the document tile: title + summary)
DataOps V1 GoalPlanning referenceProject PlanPlanning referencePortal AnalysisPlanning referenceMerge PlanPlanning reference (the four static
planning-reference links run together into one wrapped paragraph)
Likely cause
renderOperationsReference() in frontend/src/surfaces/operations-overview.js (~line 499) builds each tile as:
.ops-reference-link has no CSS rule anywhere in frontend/ (grep for ops-reference-link returns only that one JS line), so strong and span are
adjacent inline boxes with no whitespace, gap, or line break between them. The
honest-state and quality-panel strings above look like the same
label-plus-description pattern.
Why it matters
This is a real operator-facing readability defect on a canonical surface, not a
test artifact: the same rendering applies to real process documents, where every
tile will read <Doc Title><Doc summary…> with no break. Document titles are
the primary scan target on this surface.
Things to settle during grooming
Whether the fix is CSS (make .ops-reference-link a block/flex stack with the
title on its own line) or markup, and whether it belongs inside the design
system convergence work in Converge canonical DataOps surfaces on one operator design system #162 or as an independent bug fix first.
Whether the same missing-rule problem affects other ops-* classes on the
surface (the honest-state and quality-empty strings suggest yes).
Confirm the four static "Planning reference" links should remain a link list
rather than tiles.
Verification hints
Screenshot #/processes before and after under .tmp/screenshots/, with a
populated content root, and read them for run-together text, overlap, and
horizontal overflow.
backend/e2e/frontend-module-characterization.spec.js already renders a
synthetic fixture document on this surface and already asserts no horizontal
overflow, so it is a convenient place to prove the tile layout.
Follow-up from PM acceptance of #190. Pre-existing defect, unrelated to that
diff (#190 touched no
frontend/or CSS file); it was simply made visible bythe first screenshot of the Docs surface with a populated corpus.
Observed
Screenshot:
.tmp/screenshots/issue-190/worktree-processes.png(identical copyat
clean-worktree-processes.png), captured at#/processes.Bold labels and their following text render with no separator, producing
run-together strings:
Processes support workUse internal Process Docs from Task or Card context first.No findings match filtersChange filters to inspect other process quality findings.Synthetic Characterization ScheduleSynthetic reference used only by browser characterization tests.(the document tile: title + summary)DataOps V1 GoalPlanning referenceProject PlanPlanning referencePortal AnalysisPlanning referenceMerge PlanPlanning reference(the four staticplanning-reference links run together into one wrapped paragraph)
Likely cause
renderOperationsReference()infrontend/src/surfaces/operations-overview.js(~line 499) builds each tile as:.ops-reference-linkhas no CSS rule anywhere infrontend/(grep forops-reference-linkreturns only that one JS line), sostrongandspanareadjacent inline boxes with no whitespace, gap, or line break between them. The
honest-state and quality-panel strings above look like the same
label-plus-description pattern.
Why it matters
This is a real operator-facing readability defect on a canonical surface, not a
test artifact: the same rendering applies to real process documents, where every
tile will read
<Doc Title><Doc summary…>with no break. Document titles arethe primary scan target on this surface.
Things to settle during grooming
.ops-reference-linka block/flex stack with thetitle on its own line) or markup, and whether it belongs inside the design
system convergence work in Converge canonical DataOps surfaces on one operator design system #162 or as an independent bug fix first.
ops-*classes on thesurface (the honest-state and quality-empty strings suggest yes).
rather than tiles.
Verification hints
#/processesbefore and after under.tmp/screenshots/, with apopulated content root, and read them for run-together text, overlap, and
horizontal overflow.
backend/e2e/frontend-module-characterization.spec.jsalready renders asynthetic fixture document on this surface and already asserts no horizontal
overflow, so it is a convenient place to prove the tile layout.
Out of scope
content/corpus; keep using syntheticfixtures.