A numeric label ID silently applies nothing, and the dispatch gate is a label #710

New issue

Closed

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

coilyco-ops commented

2026-08-13 20:20:04 +00:00

Member

aosguard ops forgejo issue-label add --labels 332 exits 0, prints a label object, and applies nothing. Measured on issue 706:

$ aosguard ops forgejo issue-label add coilyco-gaming sirens-echo 706 --labels 332
EXIT=0
  id: 333
  description: Agent can take it from open issue to merged change...
$ # labels afterwards: headless.  consult absent.

The printed object is the issue's existing label, so the output reads as confirmation of a write that did not happen.

--dry-run gives the mechanism: the flag is declared []string, so the ID goes over as "332", and Forgejo reads a quoted numeral as a label name. Nothing is named 332, so the request succeeds having matched nothing.

The trap is that the sibling verb works. issue create --labels 333 is []integer and applies correctly, verified on 699, 702 and 704. Same flag name, same input, opposite outcome.

Why this repository in particular

consult is the dispatch gate here. cli-guard routes on it and an unlabelled issue fails closed. A label that silently fails to apply is one mechanism behind issue 437, where answered questions kept advertising themselves and live questions reached no queue.

It is also the third silent-write failure in this tool family recorded in AGENTS.md, and the section for it already exists.

Filed upstream as agentic-os#1047. This issue is the local habit, which is worth having whether or not the tool changes.

Acceptance

AGENTS.md says to name labels rather than number them, next to the existing write-verification habit.
It says why the numeric form is easy to trust: the sibling verb accepts it.

Next owner

Engineer. Closed by the pull request that lands the change.

`aosguard ops forgejo issue-label add --labels 332` exits `0`, prints a label object, and applies nothing. Measured on issue 706: ``` $ aosguard ops forgejo issue-label add coilyco-gaming sirens-echo 706 --labels 332 EXIT=0 id: 333 description: Agent can take it from open issue to merged change... $ # labels afterwards: headless. consult absent. ``` The printed object is the issue's *existing* label, so the output reads as confirmation of a write that did not happen. `--dry-run` gives the mechanism: the flag is declared `[]string`, so the ID goes over as `"332"`, and Forgejo reads a quoted numeral as a label *name*. Nothing is named `332`, so the request succeeds having matched nothing. **The trap is that the sibling verb works.** `issue create --labels 333` is `[]integer` and applies correctly, verified on 699, 702 and 704. Same flag name, same input, opposite outcome. ## Why this repository in particular `consult` is the dispatch gate here. `cli-guard` routes on it and an unlabelled issue fails closed. A label that silently fails to apply is one mechanism behind [issue 437](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437), where answered questions kept advertising themselves and live questions reached no queue. It is also the third silent-write failure in this tool family recorded in `AGENTS.md`, and the section for it already exists. Filed upstream as [agentic-os#1047](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/1047). This issue is the local habit, which is worth having whether or not the tool changes. ## Acceptance - `AGENTS.md` says to name labels rather than number them, next to the existing write-verification habit. - It says why the numeric form is easy to trust: the sibling verb accepts it. ## Next owner Engineer. Closed by the pull request that lands the change.

coilyco-ops added the

autonomy

headless

label

2026-08-13 20:20:04 +00:00

coilyco-ops referenced this issue from a commit

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

docs(agents): name labels rather than number them

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

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

docs(agents): name labels rather than number them #711

coilyco-ops referenced this issue