Source
Deferred non-blocking finding from the review of PR #1448 (head 7e88fbca863174649440284bb318e2cbbe9442b8), reported in the review-record comment for 771c87b6 as finding 3 (low, cosmetic).
Severity
Low. Cosmetic: exactly one diagnostic line loses its severity colour.
Location
src/core/cli/wizard/sync_now.js runSyncChild (the stderr echo loop, around line 222 at the head SHA), interacting with paintChunk in src/core/cli/style.js (the atLineStart gate, lines 173-179 and 209-217) and the confirm question written without a trailing newline by askYesNo (src/core/cli/confirm.js).
Observed evidence and behavior
The spawned hyp sync child's stderr is now a pipe, so useColor (src/core/cli/stdio.js:21-24) is false in the child and it stops painting its own lines. Colour is recovered only through the parent wizard's colorized stderr, but paintChunk classifies a chunk's first line only when atLineStart is true, and the send-confirm question ends without a newline, leaving the parent mid-line. The next line the child writes (for example hyp sync: nothing was sent - the sink driver is holding every tick at src/core/commands/sync.js:314, or the marker-clear failure near line 270) arrived red before this change and arrives unpainted after.
Why deferring is safe
Purely visual, one line, and content is intact. The small fix would require letting the piped child paint again, and useColor honours nothing but NO_COLOR and isTTY, so that means inventing a FORCE_COLOR-style config key, which the repo rules reserve for a task that calls for it. The consequence is recorded in the runSyncChild docstring at the head SHA.
Acceptance condition
The line the child writes on stderr immediately after an answered send confirm reaches the terminal with the same severity colour it had under stdio: 'inherit', verified by a test that feeds a painted-parent/piped-child stderr sequence through the echo path and asserts the SGR prefix on that line; or a recorded decision accepts the plain line and closes this issue.
Source
Deferred non-blocking finding from the review of PR #1448 (head
7e88fbca863174649440284bb318e2cbbe9442b8), reported in the review-record comment for771c87b6as finding 3 (low, cosmetic).Severity
Low. Cosmetic: exactly one diagnostic line loses its severity colour.
Location
src/core/cli/wizard/sync_now.jsrunSyncChild(the stderr echo loop, around line 222 at the head SHA), interacting withpaintChunkinsrc/core/cli/style.js(theatLineStartgate, lines 173-179 and 209-217) and the confirm question written without a trailing newline byaskYesNo(src/core/cli/confirm.js).Observed evidence and behavior
The spawned
hyp syncchild's stderr is now a pipe, souseColor(src/core/cli/stdio.js:21-24) is false in the child and it stops painting its own lines. Colour is recovered only through the parent wizard's colorized stderr, butpaintChunkclassifies a chunk's first line only whenatLineStartis true, and the send-confirm question ends without a newline, leaving the parent mid-line. The next line the child writes (for examplehyp sync: nothing was sent - the sink driver is holding every tickatsrc/core/commands/sync.js:314, or the marker-clear failure near line 270) arrived red before this change and arrives unpainted after.Why deferring is safe
Purely visual, one line, and content is intact. The small fix would require letting the piped child paint again, and
useColorhonours nothing butNO_COLORandisTTY, so that means inventing aFORCE_COLOR-style config key, which the repo rules reserve for a task that calls for it. The consequence is recorded in therunSyncChilddocstring at the head SHA.Acceptance condition
The line the child writes on stderr immediately after an answered send confirm reaches the terminal with the same severity colour it had under
stdio: 'inherit', verified by a test that feeds a painted-parent/piped-child stderr sequence through the echo path and asserts the SGR prefix on that line; or a recorded decision accepts the plain line and closes this issue.