coilyco-gaming/sirens-echo

Watch

allow adding multiple labels on issue creation #756

New issue

Closed

opened 2026-08-14 00:23:31 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-08-14 00:23:31 +00:00

Owner

I added a set of labels like so

move-to-repo/coilysiren-inbox
move-to-repo/coilyco-gaming-eco-app
move-to-repo/???

The ??? state should be applied be default - to signal to agents that we don't know if this issue is in its proper home

the SANDBOXED label already does this, we just need to add another label it

Resolved spec (design pass, 2026-08-15)

Label name, decided by Kai - move-to-repo/unknown.

The literal move-to-repo/??? was considered and rejected. Punctuation in a label name is awkward for tooling and URLs, and unknown reads as clearly in a label list while still sorting with the other move-to-repo/* destinations. needs-triage was rejected for dropping the prefix, and move-to-repo/unsorted for being softer than the state warrants.

Build

Create the move-to-repo/unknown label in the coilyco-gaming org label set, matching the colour and description convention of the existing move-to-repo/* labels.
Allow multiple labels to be set at issue creation. Today the creation path takes one, which is the actual defect in the title.
Apply move-to-repo/unknown by default at creation when no destination label is supplied, alongside whatever else is being set. It is a default, not a replacement, so an agent that does know the home sets that label and unknown is not added.
SANDBOXED already applies at creation. Add move-to-repo/unknown to that same path rather than building a second defaulting mechanism.

What the label means to a reader - the issue may not be in its proper home, and no agent has determined where it belongs. It is a triage state, not a claim that the current repo is wrong.

Acceptance

An issue created with two or more labels carries all of them. A test asserts the multi-label path, since single-label was the working behaviour.
An issue created with no destination label carries move-to-repo/unknown.
An issue created with an explicit move-to-repo/<repo> label does not also carry unknown.
Removing move-to-repo/unknown and adding a real destination is the ordinary triage action and needs no special handling.

Interaction with #235 - proactive filing now triggers on any unanswerable in-scope question, so the default-unknown label lands on a higher volume of issues than it would have. That is the intended behaviour, and it is what makes the label worth having.

I added a set of labels like so - `move-to-repo/coilysiren-inbox` - `move-to-repo/coilyco-gaming-eco-app` - `move-to-repo/???` The `???` state should be applied be default - to signal to agents that we don't know if this issue is in its proper home the `SANDBOXED` label already does this, we just need to add another label it --- ## Resolved spec (design pass, 2026-08-15) **Label name, decided by Kai** - `move-to-repo/unknown`. The literal `move-to-repo/???` was considered and rejected. Punctuation in a label name is awkward for tooling and URLs, and `unknown` reads as clearly in a label list while still sorting with the other `move-to-repo/*` destinations. `needs-triage` was rejected for dropping the prefix, and `move-to-repo/unsorted` for being softer than the state warrants. **Build** 1. Create the `move-to-repo/unknown` label in the `coilyco-gaming` org label set, matching the colour and description convention of the existing `move-to-repo/*` labels. 2. Allow multiple labels to be set at issue creation. Today the creation path takes one, which is the actual defect in the title. 3. Apply `move-to-repo/unknown` **by default** at creation when no destination label is supplied, alongside whatever else is being set. It is a default, not a replacement, so an agent that does know the home sets that label and `unknown` is not added. 4. `SANDBOXED` already applies at creation. Add `move-to-repo/unknown` to that same path rather than building a second defaulting mechanism. **What the label means to a reader** - the issue may not be in its proper home, and no agent has determined where it belongs. It is a triage state, not a claim that the current repo is wrong. **Acceptance** * An issue created with two or more labels carries all of them. A test asserts the multi-label path, since single-label was the working behaviour. * An issue created with no destination label carries `move-to-repo/unknown`. * An issue created with an explicit `move-to-repo/<repo>` label does **not** also carry `unknown`. * Removing `move-to-repo/unknown` and adding a real destination is the ordinary triage action and needs no special handling. **Interaction with #235** - proactive filing now triggers on any unanswerable in-scope question, so the default-unknown label lands on a higher volume of issues than it would have. That is the intended behaviour, and it is what makes the label worth having.

coilyco-ops added the

priority

autonomy

headless

labels

2026-08-15 15:18:10 +00:00

coilyco-ops referenced this issue from a commit

2026-08-15 17:16:05 +00:00

feat(labels): a filed issue carries its destination as well as the sandbox mark

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

2026-08-15 17:16:27 +00:00

A filed issue carries its destination as well as the sandbox mark #828

coilyco-ops commented

2026-08-15 17:18:13 +00:00

Member

Built, with one correction to the spec: step 1 was already done and not where it says. Angie (ENG, claude seat). #828, CI green, ward exec gate PASS on all six.

The label exists, at repo scope

The spec's step 1 is to create move-to-repo/unknown in the coilyco-gaming org label set, matching the convention of the existing move-to-repo/* labels.

It already exists as id 358, and it is a repo-level label on coilyco-gaming/sirens-echo rather than an org label. So are the other four move-to-repo/* labels and SANDBOXED. The org set holds ten labels and none of them are these.

id	label
353	`🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒`
354-357	`move-to-repo/<destination>`
358	`move-to-repo/unknown`, "we have yet to confirm if this issue belong in this repo"

I checked the org set first, found nothing matching, and only then found them at repo level. Following step 1 as written would have put a duplicate label in the wrong scope on a tracker four agents read. Nothing was created and no live mutation was needed.

The defect in the title

One line. The creation path set the field to exactly one id, so a second label was unreachable:

labelled[sandboxLabelField] = []int{p.LabelID}

The policy now carries a set: a sandbox id and a destination id, each independently optional, applied in a fixed order.

What it deliberately does not do

It does not let the model's labels through. docs/sirens-echo-sandbox-label.md records that setting rather than merging is the control, chosen over three rejected layers, because an issue body carries member-influenced text. That survives whole. A model that could name its own destination could route its own issue away from the people who read this tracker, so TestAModelCannotChooseItsOwnLabels pins it.

One acceptance case needed no code

An issue created with an explicit move-to-repo/<repo> label does not also carry unknown.

The move-to-repo/* labels are exclusive: true, so Forgejo keeps one destination per issue on its own and an ordinary triage label displaces unknown with nothing from this service. That is a property of the label scope rather than of this policy, and it also settles the fourth acceptance line: removing unknown and adding a real destination is a tracker-side edit this service never reads back.

The rest of acceptance

Two or more labels at creation carry all of them - TestCreationCarriesEveryConfiguredLabel.
Each label independently optional - TestEitherLabelAloneStillApplies.
A configured destination is the one applied - TestTheDestinationIsWhicheverOneIsConfigured.

SIRENS_ECHO_DESTINATION_LABEL names the id. The deployment sets the unknown one unless it knows the home, which is where the id-to-name mapping already lives and how SIRENS_ECHO_SANDBOX_LABEL already works.

Deployment half

Unchanged in shape from the sandbox label's, and the labels field is already granted on create-issue. Until SIRENS_ECHO_DESTINATION_LABEL is set to 358, behaviour is exactly today's, so this lands safely ahead of the deploy change rather than needing to be simultaneous.

On the #235 interaction

The note that the widened filing trigger puts this label on a higher volume of issues holds, and the volume arrives only once both this and the deploy-side id are live.

**Built, with one correction to the spec: step 1 was already done and not where it says. Angie (ENG, `claude` seat).** #828, CI green, `ward exec gate` PASS on all six. ## The label exists, at repo scope The spec's step 1 is to create `move-to-repo/unknown` in the **coilyco-gaming org** label set, matching the convention of the existing `move-to-repo/*` labels. It already exists as **id 358**, and it is a **repo-level** label on `coilyco-gaming/sirens-echo` rather than an org label. So are the other four `move-to-repo/*` labels and `SANDBOXED`. The org set holds ten labels and none of them are these. | id | label | | --- | --- | | 353 | `🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒` | | 354-357 | `move-to-repo/<destination>` | | 358 | `move-to-repo/unknown`, "we have yet to confirm if this issue belong in this repo" | I checked the org set first, found nothing matching, and only then found them at repo level. Following step 1 as written would have put a duplicate label in the wrong scope on a tracker four agents read. Nothing was created and no live mutation was needed. ## The defect in the title One line. The creation path set the field to exactly one id, so a second label was unreachable: ```go labelled[sandboxLabelField] = []int{p.LabelID} ``` The policy now carries a set: a sandbox id and a destination id, each independently optional, applied in a fixed order. ## What it deliberately does not do It does not let the model's labels through. `docs/sirens-echo-sandbox-label.md` records that setting rather than merging is the control, chosen over three rejected layers, because an issue body carries member-influenced text. That survives whole. A model that could name its own destination could route its own issue away from the people who read this tracker, so `TestAModelCannotChooseItsOwnLabels` pins it. ## One acceptance case needed no code > An issue created with an explicit `move-to-repo/<repo>` label does not also carry `unknown`. The `move-to-repo/*` labels are `exclusive: true`, so Forgejo keeps one destination per issue on its own and an ordinary triage label displaces `unknown` with nothing from this service. That is a property of the label scope rather than of this policy, and it also settles the fourth acceptance line: removing `unknown` and adding a real destination is a tracker-side edit this service never reads back. ## The rest of acceptance * Two or more labels at creation carry all of them - `TestCreationCarriesEveryConfiguredLabel`. * Each label independently optional - `TestEitherLabelAloneStillApplies`. * A configured destination is the one applied - `TestTheDestinationIsWhicheverOneIsConfigured`. `SIRENS_ECHO_DESTINATION_LABEL` names the id. The deployment sets the unknown one unless it knows the home, which is where the id-to-name mapping already lives and how `SIRENS_ECHO_SANDBOX_LABEL` already works. ## Deployment half Unchanged in shape from the sandbox label's, and the `labels` field is already granted on create-issue. **Until `SIRENS_ECHO_DESTINATION_LABEL` is set to 358, behaviour is exactly today's**, so this lands safely ahead of the deploy change rather than needing to be simultaneous. ## On the #235 interaction The note that the widened filing trigger puts this label on a higher volume of issues holds, and the volume arrives only once both this and the deploy-side id are live.

coilysiren closed this issue

2026-08-15 20:12:37 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#756

No description provided.

Rows
Columns