iterative-works/iw-cli

Watch

Fork 0

An unquoted multi-word flag value silently fills the next unfilled operand instead of being refused #549

New issue

Closed

opened 2026-09-13 09:07:06 +00:00 by mph · 4 comments

mph commented

2026-09-13 09:07:06 +00:00

Owner

iw kanon/feedback --description a b parses with title 'b' and description 'a' and files an issue titled 'b', where the previous hand-written parser returned Left("Title is required"). consumeValue takes one token (core/model/CommandArgParser.scala:220-228) and walk then binds the leftover to a free operand slot (:161-168), so a loud refusal became a silent content swap. Bounded to the unfilled-slot case: iw kanon/feedback "Title" --description a b still reports 'Unexpected argument: b'.

Type: bug
Filed from: /home/mph/ops/kanon-DEVDOCS-246 on branch DEVDOCS-246

`iw kanon/feedback --description a b` parses with title 'b' and description 'a' and files an issue titled 'b', where the previous hand-written parser returned Left("Title is required"). consumeValue takes one token (core/model/CommandArgParser.scala:220-228) and walk then binds the leftover to a free operand slot (:161-168), so a loud refusal became a silent content swap. Bounded to the unfilled-slot case: `iw kanon/feedback "Title" --description a b` still reports 'Unexpected argument: b'. --- **Type:** bug **Filed from:** `/home/mph/ops/kanon-DEVDOCS-246` on branch `DEVDOCS-246`

mph referenced this issue

2026-09-13 09:08:18 +00:00

A flag value beginning with a double dash cannot be passed, and the refusal reports it as missing #552

claude referenced this issue

2026-09-14 23:14:29 +00:00

A dangling valued flag with no following value hard-rejects where it used to fall back to its default #550

claude commented

2026-09-14 23:44:58 +00:00

Member

Intake: needs-input

The wrong outcome this issue names is concrete, but the desired rule is not. The parser documents today's behaviour as deliberate ("a bare token binds to the next undeclared operand slot in declaration order"), and it matches GNU/POSIX and clap, so it is not obviously wrong — it only turned a loud "Title is required" into a silent content swap. The recorded IW-463 ruling does not reach this shape. One question:

1. In iw-cli, a command can declare both a positional operand and valued flags (for example iw feedback <title> --description TEXT; iw start, iw rm, iw gate and iw analyze are the same shape). Today the parser takes exactly one token as a flag's value and then lets any later bare token fill the next still-empty operand slot, so iw feedback --description a b files an issue titled "b" with description "a". Which rule should hold instead?

(a) No change — the documented rule stands and the user must quote the value; close the issue as working as designed.
(b) A bare token may not fill an operand slot once any flag has been seen, so operands must be typed before flags. This refuses iw feedback --description a b, but also refuses iw start --from main IW-1 and every other flag-before-operand invocation that works today.
(c) A bare token may not fill an operand slot when it directly follows the value a valued flag just consumed, while flag-before-operand stays legal elsewhere. Narrow, but a rule with no precedent in any other CLI.
(d) A valued flag again consumes every following bare token up to the next flag-shaped token (the pre-IW-463 behaviour), so --description a b gives description "a b" and the title is then reported missing. This reverses part of the IW-463 migration.

Options (b), (c) and (d) each change the shared parser for all 25 commands, so the answer should be the one you want applied everywhere, not only to feedback.

Intake: needs-input The wrong outcome this issue names is concrete, but the desired rule is not. The parser documents today's behaviour as deliberate ("a bare token binds to the next undeclared operand slot in declaration order"), and it matches GNU/POSIX and clap, so it is not obviously wrong — it only turned a loud "Title is required" into a silent content swap. The recorded IW-463 ruling does not reach this shape. One question: **1.** In iw-cli, a command can declare both a positional operand and valued flags (for example `iw feedback <title> --description TEXT`; `iw start`, `iw rm`, `iw gate` and `iw analyze` are the same shape). Today the parser takes exactly one token as a flag's value and then lets any later bare token fill the next still-empty operand slot, so `iw feedback --description a b` files an issue titled "b" with description "a". Which rule should hold instead? - **(a)** No change — the documented rule stands and the user must quote the value; close the issue as working as designed. - **(b)** A bare token may not fill an operand slot once any flag has been seen, so operands must be typed before flags. This refuses `iw feedback --description a b`, but also refuses `iw start --from main IW-1` and every other flag-before-operand invocation that works today. - **(c)** A bare token may not fill an operand slot when it directly follows the value a valued flag just consumed, while flag-before-operand stays legal elsewhere. Narrow, but a rule with no precedent in any other CLI. - **(d)** A valued flag again consumes every following bare token up to the next flag-shaped token (the pre-IW-463 behaviour), so `--description a b` gives description "a b" and the title is then reported missing. This reverses part of the IW-463 migration. Options (b), (c) and (d) each change the shared parser for all 25 commands, so the answer should be the one you want applied everywhere, not only to `feedback`.

claude added the

needs-input

label

2026-09-14 23:44:58 +00:00

claude referenced this issue

2026-09-15 00:16:39 +00:00

CommandArgParser: no test for a non-repeated flag given twice, and last-wins reverses the previous first-wins #548

mph commented

2026-10-10 20:14:02 +00:00

Author

Owner

1: a

claude removed the

needs-input

label

2026-10-10 22:10:18 +00:00

claude commented

2026-10-10 22:10:53 +00:00

Member

Intake: needs-human
Workflow: -
Reason: not actionable — the answer "1: a" keeps the documented operand-binding rule (users quote multi-word flag values), so no change is wanted. Intake closes an issue only against a duplicate issue or a fixing commit, and "working as designed" names neither: close it by hand if you agree.
Analysis: none (no branch)

Intake: needs-human Workflow: - Reason: not actionable — the answer "1: a" keeps the documented operand-binding rule (users quote multi-word flag values), so no change is wanted. Intake closes an issue only against a duplicate issue or a fixing commit, and "working as designed" names neither: close it by hand if you agree. Analysis: none (no branch)

claude added the

needs-human

label

2026-10-10 22:10:53 +00:00

claude commented

2026-10-15 12:55:51 +00:00

Member

Working as designed — closed by Michal in a human-review session.
The answer "1: a" keeps the documented operand-binding rule: users quote multi-word flag values. No change is wanted.

Working as designed — closed by Michal in a human-review session. The answer "1: a" keeps the documented operand-binding rule: users quote multi-word flag values. No change is wanted.

claude closed this issue

2026-10-15 12:55:51 +00:00