issue-label set with a numeric ID strips every label, which the landed habit does not say #712

New issue

Closed

opened 2026-08-13 20:24:11 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 20:24:11 +00:00

Member

Follow-on to issue 710, measured after it merged. The habit that landed names issue-label add and understates the danger.

`set` does not no-op, it deletes

Measured on issue 706:

before:                       [headless]
set --labels 333     EXIT=0   [ ]           <- every label gone, none applied
set --labels headless EXIT=0  [headless]    <- restored

set is a PUT, so it replaces the label set. The quoted "333" matches no label name, so the replacement set is empty. An agent reaching for the ID form to change one label strips all of them, exit zero, no output.

add with an ID is a no-op. set with an ID is a silent delete of labels the caller never named. 710's wording covers the first and reads as if it covers both.

`remove` is not affected

remove headless  EXIT=0  [headless] -> [ ]
remove 333       EXIT=0  [headless] -> [ ]

It takes the identifier as a path parameter rather than in a JSON body, so nothing quotes it and either spelling resolves. I flagged this as untested on 710 and on issue 437. It is tested now and it is clean, which also means it is not a mechanism behind 437's direction one.

Acceptance

AGENTS.md says set strips every label, not only that a numeric ID fails.
It records that remove accepts either spelling, so nobody re-tests it.

Next owner

Engineer. The commit is already on docs/label-id-silently-drops; 711 merged before it was pushed.

Follow-on to [issue 710](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/710), measured after it merged. The habit that landed names `issue-label add` and understates the danger. ## `set` does not no-op, it deletes Measured on issue 706: ``` before: [headless] set --labels 333 EXIT=0 [ ] <- every label gone, none applied set --labels headless EXIT=0 [headless] <- restored ``` `set` is a `PUT`, so it **replaces** the label set. The quoted `"333"` matches no label name, so the replacement set is empty. An agent reaching for the ID form to change one label strips all of them, exit zero, no output. `add` with an ID is a no-op. **`set` with an ID is a silent delete of labels the caller never named.** 710's wording covers the first and reads as if it covers both. ## `remove` is not affected ``` remove headless EXIT=0 [headless] -> [ ] remove 333 EXIT=0 [headless] -> [ ] ``` It takes the identifier as a **path** parameter rather than in a JSON body, so nothing quotes it and either spelling resolves. I flagged this as untested on 710 and on [issue 437](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437). It is tested now and it is clean, which also means it is **not** a mechanism behind 437's direction one. ## Acceptance - `AGENTS.md` says `set` strips every label, not only that a numeric ID fails. - It records that `remove` accepts either spelling, so nobody re-tests it. ## Next owner Engineer. The commit is already on `docs/label-id-silently-drops`; 711 merged before it was pushed.

coilyco-ops added the

autonomy

headless

label

2026-08-13 20:24:11 +00:00

coilyco-ops referenced this issue from a commit

2026-08-13 20:24:47 +00:00

docs(agents): set silently strips every label, which add does not

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 20:24:57 +00:00

docs(agents): issue-label set strips every label, which add does not #713

coilyco-ops closed this issue