Server code: keep each rule in one place (jar argv, cause message, wildcard check) #676

New issue

Open

opened 2026-10-02 08:45:11 +00:00 by claude · 2 comments

claude commented

2026-10-02 08:45:11 +00:00

Member

Three small duplications in the server code; each should be one pure function.

Found during IW-652 (per-user dashboard, service links, Claude session links). Follow-ups, verbatim:

The java -jar <jar> <statePath> <port> <hosts> argv is built in three places (core/commands/Server.scala runServer, core/adapters/ProcessManager.scala:111, core/commands/Dashboard.scala:209); one pure DashboardJar.command would keep the server's argument contract in one place.
The "exception message or class name" rule exists three times: messageOf (core/adapters/ServerClient.scala), causeOf (core/commands/LiveCommandEnv.scala), shortCause (core/model/ServerStatus.scala).
ServerConfig.validateHost (core/model/ServerConfig.scala:36) and analyzeHostsSecurity (:118) still test the wildcards 0.0.0.0 and :: inline; IW-652 Phase 2 added ServerConfig.isWildcard and changed only answersOnLoopback.

Three small duplications in the server code; each should be one pure function. Found during IW-652 (per-user dashboard, service links, Claude session links). Follow-ups, verbatim: - [ ] The `java -jar <jar> <statePath> <port> <hosts>` argv is built in three places (`core/commands/Server.scala` `runServer`, `core/adapters/ProcessManager.scala:111`, `core/commands/Dashboard.scala:209`); one pure `DashboardJar.command` would keep the server's argument contract in one place. - [ ] The "exception message or class name" rule exists three times: `messageOf` (`core/adapters/ServerClient.scala`), `causeOf` (`core/commands/LiveCommandEnv.scala`), `shortCause` (`core/model/ServerStatus.scala`). - [ ] `ServerConfig.validateHost` (`core/model/ServerConfig.scala:36`) and `analyzeHostsSecurity` (`:118`) still test the wildcards `0.0.0.0` and `::` inline; IW-652 Phase 2 added `ServerConfig.isWildcard` and changed only `answersOnLoopback`.

mph referenced this issue from a commit

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

workflow: Triage lessons for IW-652

claude added the

needs-human

label

2026-10-03 04:20:52 +00:00

claude commented

2026-10-03 04:20:53 +00:00

Author

Member

Intake: needs-human
Workflow: waterfall
Reason: G7 — scope: the analysis also unifies two cause-message copies outside the server code (Rm.scala:313, BuildToolCleanupRunner.scala:74) and changes user-visible error text at all copies; keep that, or record the two copies in FOLLOW-UPS.md
Analysis: project-management/issues/IW-676/analysis.md on branch IW-676

Intake: needs-human Workflow: waterfall Reason: G7 — scope: the analysis also unifies two cause-message copies outside the server code (Rm.scala:313, BuildToolCleanupRunner.scala:74) and changes user-visible error text at all copies; keep that, or record the two copies in FOLLOW-UPS.md Analysis: project-management/issues/IW-676/analysis.md on branch IW-676

claude commented

2026-10-06 18:16:56 +00:00

Author

Member

Intake: needs-input
Workflow: waterfall
Reason: G7 (1 [human] finding)
Analysis: project-management/issues/IW-676/analysis.md on branch IW-676

[G7] The issue names three copies of a rule in "the server code" (the jar argv, the cause message, the wildcard check). The analysis also unifies two more copies of the cause message outside the server code, core/commands/Rm.scala:313 and core/commands/BuildToolCleanupRunner.scala:74, and the shared rule changes what users see at every copy: a multi-line message is cut to its first line, and an empty or blank message shows the exception's class name. The choice is stated in the analysis ("Decision on scope") and is reversible, but the issue does not ask for it. Which scope should IW-676 have? Options: a) keep the wider scope: all five copies use the one rule, with the changed error text b) only the copies in the server code; record the Rm.scala and BuildToolCleanupRunner.scala copies as one line in FOLLOW-UPS.md c) the wider scope, but keep each copy's current text for multi-line and blank messages Recommended: b)

Answer in a comment on this issue; intake reads it on its next iteration.

Intake: needs-input Workflow: waterfall Reason: G7 (1 [human] finding) Analysis: project-management/issues/IW-676/analysis.md on branch IW-676 1. [G7] The issue names three copies of a rule in "the server code" (the jar argv, the cause message, the wildcard check). The analysis also unifies two more copies of the cause message outside the server code, `core/commands/Rm.scala:313` and `core/commands/BuildToolCleanupRunner.scala:74`, and the shared rule changes what users see at every copy: a multi-line message is cut to its first line, and an empty or blank message shows the exception's class name. The choice is stated in the analysis ("Decision on scope") and is reversible, but the issue does not ask for it. Which scope should IW-676 have? Options: a) keep the wider scope: all five copies use the one rule, with the changed error text b) only the copies in the server code; record the `Rm.scala` and `BuildToolCleanupRunner.scala` copies as one line in FOLLOW-UPS.md c) the wider scope, but keep each copy's current text for multi-line and blank messages Recommended: b) Answer in a comment on this issue; intake reads it on its next iteration.

claude added

needs-input

and removed

needs-human

labels

2026-10-06 18:16:56 +00:00