move-issue is a second path to an unlabelled issue, and its "deferred (array flow)" note is now stale #1317

New issue

Closed

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

coilyco-ops commented

2026-08-27 04:20:37 +00:00

Owner

Found while landing #1105. Out of scope there rather than forgotten.

The gap

#1105 closes the issue create path: a filed issue must carry a priority and an autonomy label, refused before the write. move-issue is the other verb in this guardfile that creates an issue, and it carries no labels at all:

// move-issue: copy title/body to a target repo, back-link, then CLOSE the
// source (never delete). Carrying labels/milestone is deferred (array flow).
action move-issue {
    ...
    call create issue {
        args {
            owner-repo $target
            title $src.title
            body $src.body
        }
        as dst
    }

So every move produces an unlabelled issue in the target repo, which is the fail-closed default that reaches no queue - coilyco-gaming/sirens-echo#437's subject, and the thing #1105 exists to prevent. Closing one path and leaving the other open is worth naming rather than leaving to be rediscovered.

It is not a regression from #1105. A shadow replaces the CLI leaf and not the grant, so move-issue's own call create issue still targets the generated leaf and is unaffected by the new guard. Verified by dry-run while checking #1105 for regressions. The hole predates the guard, it just becomes conspicuous next to it.

The stated reason no longer holds

The comment says carrying labels is deferred for "array flow". That was true when it was written. umbra#319 shipped array on an action input in v0.168.0, and #1105 now pins v0.173.0, so an action can carry a label list today. The note is stale rather than current.

Two shapes, and they are not equivalent

Carry the source issue's own labels. A move preserves the tier the issue already had, which is what a human expects "move" to mean. Needs the source's label names projected from the view issue step into the create call, and that is blocked: stepflow.SliceRefs documents that a step-output reference is never a list, only a declared array input is. So this shape needs an umbra change before it can be built, in the same family as umbra#317.

Require them from the caller, exactly like #1105: a required --labels with matches constraints, applied by a second call to the labels sub-collection. Buildable today, and consistent with the verb it sits beside. It loses the source's labels unless the caller retypes them, which on a cross-repo move is arguably right anyway, since a tier in one repo's backlog is not obviously the tier in another's.

I have not picked one. The first is what a reader expects move to do and needs upstream work; the second is available now and is the same control #1105 shipped. Worth deciding deliberately rather than defaulting to whichever is easier to write.

#1105 - the issue create guard this mirrors.
umbra#322, umbra#324 - the matches constraint and its alternation fix.
coilyco-gaming/sirens-echo#437 - unlabelled issues failing closed and reaching no queue.

Found while landing #1105. Out of scope there rather than forgotten. ## The gap #1105 closes the `issue create` path: a filed issue must carry a priority and an autonomy label, refused before the write. `move-issue` is the other verb in this guardfile that creates an issue, and it carries no labels at all: ```kdl // move-issue: copy title/body to a target repo, back-link, then CLOSE the // source (never delete). Carrying labels/milestone is deferred (array flow). action move-issue { ... call create issue { args { owner-repo $target title $src.title body $src.body } as dst } ``` So every move produces an unlabelled issue in the target repo, which is the fail-closed default that reaches no queue - `coilyco-gaming/sirens-echo#437`'s subject, and the thing #1105 exists to prevent. Closing one path and leaving the other open is worth naming rather than leaving to be rediscovered. It is not a regression from #1105. A shadow replaces the CLI leaf and not the grant, so `move-issue`'s own `call create issue` still targets the generated leaf and is unaffected by the new guard. Verified by dry-run while checking #1105 for regressions. The hole predates the guard, it just becomes conspicuous next to it. ## The stated reason no longer holds The comment says carrying labels is deferred for "array flow". That was true when it was written. umbra#319 shipped `array` on an action input in v0.168.0, and #1105 now pins v0.173.0, so an action can carry a label list today. The note is stale rather than current. ## Two shapes, and they are not equivalent **Carry the source issue's own labels.** A move preserves the tier the issue already had, which is what a human expects "move" to mean. Needs the source's label names projected from the `view issue` step into the create call, and that is blocked: `stepflow.SliceRefs` documents that a step-output reference is never a list, only a declared `array` input is. So this shape needs an umbra change before it can be built, in the same family as umbra#317. **Require them from the caller,** exactly like #1105: a required `--labels` with `matches` constraints, applied by a second call to the labels sub-collection. Buildable today, and consistent with the verb it sits beside. It loses the source's labels unless the caller retypes them, which on a cross-repo move is arguably right anyway, since a tier in one repo's backlog is not obviously the tier in another's. I have not picked one. The first is what a reader expects `move` to do and needs upstream work; the second is available now and is the same control #1105 shipped. Worth deciding deliberately rather than defaulting to whichever is easier to write. ## Related * #1105 - the `issue create` guard this mirrors. * umbra#322, umbra#324 - the `matches` constraint and its alternation fix. * `coilyco-gaming/sirens-echo#437` - unlabelled issues failing closed and reaching no queue.

coilyco-ops added the

labels

2026-08-27 04:20:37 +00:00

coilyco-ops referenced this issue

2026-08-27 04:26:47 +00:00

feat(aosguard): refuse an issue filed with no priority or autonomy label #1318

coilyco-ops referenced this issue

2026-08-27 05:05:11 +00:00