IssueFormatter output is not terminal-safe, and a comment can fake the layout

claude commented

2026-10-03 19:32:49 +00:00

Member

Found in IW-610 (review-phase-02-20261003-055441.md, security and testing).

The issue description in IssueFormatter.format does not go through TerminalSafeText.strip, while comment text does (IW-610 analysis Risk 4) — core/output/IssueFormatter.scala
The issue title and assignee in IssueFormatter.format do not go through TerminalSafeText.strip either — core/output/IssueFormatter.scala:15-47
A comment author that holds a newline prints extra lines that look like another comment's header, because TerminalSafeText.strip keeps newlines and the author is not indented — core/output/IssueFormatter.scala:59
formatComments prints a 4-space line for an empty body or an interior blank line — core/output/IssueFormatter.scala:63

Fix: one rule per printed field (strip; how a newline is indented or flattened), applied in both format and formatComments.

Found in IW-610 (review-phase-02-20261003-055441.md, security and testing). - The issue description in IssueFormatter.format does not go through TerminalSafeText.strip, while comment text does (IW-610 analysis Risk 4) — core/output/IssueFormatter.scala - The issue title and assignee in IssueFormatter.format do not go through TerminalSafeText.strip either — core/output/IssueFormatter.scala:15-47 - A comment author that holds a newline prints extra lines that look like another comment's header, because TerminalSafeText.strip keeps newlines and the author is not indented — core/output/IssueFormatter.scala:59 - formatComments prints a 4-space line for an empty body or an interior blank line — core/output/IssueFormatter.scala:63 Fix: one rule per printed field (strip; how a newline is indented or flattened), applied in both format and formatComments.

mph referenced this issue from a commit

2026-10-06 12:49:52 +00:00

workflow: Triage lessons for IW-610

claude referenced this issue

2026-10-06 23:15:39 +00:00

IW-610: iw issue reports and prints an issue's comments #728

claude commented

2026-10-08 02:00:38 +00:00

Author

Member

Intake: needs-input
Workflow: diagnostic
Reason: G5 (4 phases)
Analysis: project-management/issues/IW-699/analysis.md on branch IW-699

1. IW-699 has 4 phases and the limit is 3. How do we split or merge the issue? (G5)

The limit is at most 3 phases for each issue. Usually the answer is to split the issue, not to raise the limit. All 4 phases change one file, IssueFormatter.scala, and its test. The total is about 3-5.5h. Phases 1 and 2 fix format (title, assignee, status and id; then the description), and the BATS case covers both. Phases 3 and 4 fix formatComments and use the same two helpers again. See the phase index.

a) Keep one issue and merge to 2 phases: 1+2 (format, both helpers, BATS case) and 3+4 (formatComments). This gives 2 PRs and has no order conflict.
b) Keep one issue and merge to 2 phases by helper: 1+3 (single-line fields) and 2+4 (multi-line fields). The BATS case must move to the second phase, because it also checks the description.
c) Split into two issues: IW-699 keeps phases 1-2 (format), and a new issue gets phases 3-4 (formatComments). This adds one more issue, analysis and review cycle for the same file. The second issue must wait until the first merges.
d) Run all 4 phases as one issue. This goes above the limit.

Recommended: a) The change is small and stays in one file, so splitting the issue costs more than it gives. The format/formatComments line keeps the BATS case in the phase that it checks.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input Workflow: diagnostic Reason: G5 (4 phases) Analysis: project-management/issues/IW-699/analysis.md on branch IW-699 ### 1. IW-699 has 4 phases and the limit is 3. How do we split or merge the issue? (G5) The limit is at most 3 phases for each issue. Usually the answer is to split the issue, not to raise the limit. All 4 phases change one file, [IssueFormatter.scala](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-699/core/output/IssueFormatter.scala#L16-L69), and its test. The total is about 3-5.5h. Phases 1 and 2 fix `format` (title, assignee, status and id; then the description), and the BATS case covers both. Phases 3 and 4 fix `formatComments` and use the same two helpers again. See the [phase index](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-699/project-management/issues/IW-699/tasks.md). - **a) Keep one issue and merge to 2 phases: 1+2 (`format`, both helpers, BATS case) and 3+4 (`formatComments`).** This gives 2 PRs and has no order conflict. - **b) Keep one issue and merge to 2 phases by helper: 1+3 (single-line fields) and 2+4 (multi-line fields).** The BATS case must move to the second phase, because it also checks the description. - **c) Split into two issues: IW-699 keeps phases 1-2 (`format`), and a new issue gets phases 3-4 (`formatComments`).** This adds one more issue, analysis and review cycle for the same file. The second issue must wait until the first merges. - **d) Run all 4 phases as one issue.** This goes above the limit. **Recommended: a)** The change is small and stays in one file, so splitting the issue costs more than it gives. The `format`/`formatComments` line keeps the BATS case in the phase that it checks. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-08 02:00:38 +00:00

mph commented

2026-10-10 19:18:03 +00:00

Owner

1: a

claude commented

2026-10-11 00:13:25 +00:00

Author

Member

Intake: agent-ready
Workflow: diagnostic
Reason: all gates passed
Analysis: project-management/issues/IW-699/analysis.md on branch IW-699

Intake: agent-ready Workflow: diagnostic Reason: all gates passed Analysis: project-management/issues/IW-699/analysis.md on branch IW-699

claude added

agent-ready

and removed

needs-input

labels

2026-10-11 00:13:25 +00:00

claude commented

2026-10-15 14:47:49 +00:00

Author

Member

Implement: needs-human
Reason: batch-implement exit 143 — the kanon plugin did not compile against the iw-cli core of current main, and scala-cli then hung with no output for about 55 minutes until the loop stopped it

iw-cli main changed fetchPullRequestForBranch to return Either[TrackerError, …] (#778). The installed kanon plugin (lib/batch/ForgeCatchUp.scala:143) still expects Either[String, …]. No phase ran. This is not specific to IW-699: every batch-implement on current iw-cli main fails the same way until the plugin is updated. batch-implement.log was not written; the lines below are the command output.

[error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7
[error] Found:    Either[iw.core.model.TrackerError, Option[batch.ForgeState]]
[error] Required: Either[String, Option[batch.ForgeState]]
[E] Caught java.lang.InterruptedException
Bloop 'bsp' command exited with code 1. Something may be wrong with the current configuration.

After the plugin compiles again, release the issue to agent-ready through human-review.md. The branch already has current main merged in.

Implement: needs-human Reason: batch-implement exit 143 — the kanon plugin did not compile against the iw-cli core of current main, and scala-cli then hung with no output for about 55 minutes until the loop stopped it `iw-cli` main changed `fetchPullRequestForBranch` to return `Either[TrackerError, …]` (#778). The installed kanon plugin (`lib/batch/ForgeCatchUp.scala:143`) still expects `Either[String, …]`. No phase ran. This is not specific to IW-699: every `batch-implement` on current iw-cli main fails the same way until the plugin is updated. `batch-implement.log` was not written; the lines below are the command output. ``` [error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7 [error] Found: Either[iw.core.model.TrackerError, Option[batch.ForgeState]] [error] Required: Either[String, Option[batch.ForgeState]] [E] Caught java.lang.InterruptedException Bloop 'bsp' command exited with code 1. Something may be wrong with the current configuration. ``` After the plugin compiles again, release the issue to `agent-ready` through `human-review.md`. The branch already has current `main` merged in.

claude added

needs-human

and removed

agent-ready

labels

2026-10-15 14:47:49 +00:00

claude commented

2026-10-16 17:10:40 +00:00

Author

Member

Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.

claude added

agent-ready

and removed

needs-human

labels

2026-10-16 17:10:40 +00:00

Rows
Columns

IssueFormatter output is not terminal-safe, and a comment can fake the layout #699

1. IW-699 has 4 phases and the limit is 3. How do we split or merge the issue? (G5)