coilyco-flight-deck/agent-compose

Watch

Label namespaces outside the org sync: coilysiren repo labels and inbox's unprefixed taxonomy #343

New issue

Closed

opened 2026-08-25 17:35:01 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-25 17:35:01 +00:00

Member

What this carries

#342 scopes its work to the three orgs the sync script covers. Two namespaces sit outside it, and this issue is the deferral record so they are not lost.

`coilysiren` repo-level labels

coilysiren is a user rather than an org, so its repositories carry repo-level labels instead of inheriting an org set. coilysiren/coilysiren carries the full prefixed taxonomy, ids 339 through 414, including all nine retired role/* values.

forgejo-label-taxonomy-sync.py cannot reach these. Its TARGETS are coilyco-bridge and coilyco-flight-deck, sourced from coilyco-gaming, and it calls an org-label verb throughout. coilyco-bridge/agentic-os-kai/scripts/backfill-personal-labels.sh appears to be the separate path for user-owned repositories, and it carries its own copy of the old-to-new rename map.

Two copies of the same mapping in two scripts is the drift shape #342 is fixing one layer up. Worth folding both onto the declarative taxonomy file rather than renaming in two places.

`coilysiren/inbox`

Uses a different scheme entirely. Per coilyco-bridge/deploy/services/forgejo-mcp/docs/tool-surface.md:29, inbox "uses an unprefixed taxonomy that a prefixed rule would lock out entirely." That same line records it as a live constraint on deploy#580, which wants create_issue to require labels and cannot express the rule because of it.

So converting inbox is not only a relabeling job. It would unblock a wanted constraint in the MCP tool surface, which is worth weighing when this is scheduled.

Unverified

coilysiren/inbox and coilysiren/lore are private and returned "target couldn't be found" unauthenticated, so their label state was not inspected. Everything above about inbox comes from the deploy documentation rather than from reading its labels. Confirm before planning.

What to do

Decide whether user-owned repository labels fold onto the same declarative taxonomy file from #342, or keep a separate path.
Reconcile backfill-personal-labels.sh with the sync script so one mapping exists rather than two.
Inspect the actual label state of coilysiren/inbox and coilysiren/lore with credentials.
Decide whether inbox converts to the prefixed taxonomy, and weigh deploy#580 in that decision.
Apply the current roster's role/* values wherever the retired ones survive.

Blocked by

Blocked by #342, which settles the taxonomy and the declarative source these would adopt.

## What this carries #342 scopes its work to the three orgs the sync script covers. Two namespaces sit outside it, and this issue is the deferral record so they are not lost. ### `coilysiren` repo-level labels `coilysiren` is a user rather than an org, so its repositories carry repo-level labels instead of inheriting an org set. `coilysiren/coilysiren` carries the full prefixed taxonomy, ids 339 through 414, including all nine retired `role/*` values. `forgejo-label-taxonomy-sync.py` cannot reach these. Its `TARGETS` are `coilyco-bridge` and `coilyco-flight-deck`, sourced from `coilyco-gaming`, and it calls an `org-label` verb throughout. `coilyco-bridge/agentic-os-kai/scripts/backfill-personal-labels.sh` appears to be the separate path for user-owned repositories, and it carries its own copy of the old-to-new rename map. Two copies of the same mapping in two scripts is the drift shape #342 is fixing one layer up. Worth folding both onto the declarative taxonomy file rather than renaming in two places. ### `coilysiren/inbox` Uses a different scheme entirely. Per `coilyco-bridge/deploy/services/forgejo-mcp/docs/tool-surface.md:29`, inbox "uses an unprefixed taxonomy that a prefixed rule would lock out entirely." That same line records it as a live constraint on `deploy#580`, which wants `create_issue` to require labels and cannot express the rule because of it. So converting inbox is not only a relabeling job. It would unblock a wanted constraint in the MCP tool surface, which is worth weighing when this is scheduled. ### Unverified `coilysiren/inbox` and `coilysiren/lore` are private and returned "target couldn't be found" unauthenticated, so their label state was not inspected. Everything above about inbox comes from the deploy documentation rather than from reading its labels. Confirm before planning. ## What to do - [ ] Decide whether user-owned repository labels fold onto the same declarative taxonomy file from #342, or keep a separate path. - [ ] Reconcile `backfill-personal-labels.sh` with the sync script so one mapping exists rather than two. - [ ] Inspect the actual label state of `coilysiren/inbox` and `coilysiren/lore` with credentials. - [ ] Decide whether inbox converts to the prefixed taxonomy, and weigh `deploy#580` in that decision. - [ ] Apply the current roster's `role/*` values wherever the retired ones survive. ## Blocked by - Blocked by #342, which settles the taxonomy and the declarative source these would adopt.

coilyco-ops added the

priority

autonomy

async-consult

labels

2026-08-25 17:35:06 +00:00

coilyco-ops referenced this issue

2026-08-25 20:38:13 +00:00

Make the label taxonomy declarative, then rename role/* onto the current roster #342

coilyco-ops commented

2026-08-25 20:38:30 +00:00

Author

Member

Now measured: 18 issues stranded on retired label names

#342 step 2 applied, so the split this issue describes is no longer hypothetical. The three orgs carry the Core Roster v2 names. The coilysiren user-owned repositories carry their own repo-level labels, were out of scope, and still hold the retired ones.

Counted after the rename, by querying the old names globally. Every one of these is now unreachable from the seat that owns the work:

role/engineer - 8
role/design - 4
role/creator - 4
role/ops - 1
role/ai - 1
role/director - 0
role/exec, role/qa - still live in the orgs too, pending #342 steps 3 and 4

18 issues. These reconcile exactly against the shortfall between the pre-rename and post-rename counts, which is how they surfaced: verifying that no issue lost its label during the rename turned up a population that had never been in scope to begin with.

What this changes about the plan

The rename mapping is now settled and proven, so the work here is no longer a design question. It is applying the same six mappings plus the two retirements to a different namespace, using a path the org sync cannot reach.

The mapping, for the record:

role/engineer to role/platform
role/ops to role/sysadmin
role/ai to role/eval
role/director to role/tpm
role/creator to role/devrel
role/design to role/frontend
role/gamedev created, no predecessor
role/exec folded into role/tpm, role/qa retired, role/human unchanged

Two things worth carrying into the fix

Repo-level labels are a different API surface. forgejo-label-taxonomy-sync.py calls org-label throughout and its targets are org names. Reaching coilysiren/* means the repo label endpoints, and agentic-os-kai/scripts/backfill-personal-labels.sh is the existing path. Folding both onto the one declarative taxonomy file is the point of doing this at all, rather than renaming in a second place.

A rename must stay an edit in place. The org converge preserved every label id, which is why no issue lost anything. Whatever touches the repo-level labels has to hold the same property, or 18 issues lose their labels instead of keeping them.

Still unverified

coilysiren/inbox and coilysiren/lore are private and were not readable unauthenticated. The 18 above are from a global issue search, so they include those repos, but the label inventory of each was not inspected. Confirm with credentials before planning the fix.

## Now measured: 18 issues stranded on retired label names #342 step 2 applied, so the split this issue describes is no longer hypothetical. The three orgs carry the Core Roster v2 names. The `coilysiren` user-owned repositories carry their own repo-level labels, were out of scope, and still hold the retired ones. Counted after the rename, by querying the old names globally. Every one of these is now unreachable from the seat that owns the work: * `role/engineer` - 8 * `role/design` - 4 * `role/creator` - 4 * `role/ops` - 1 * `role/ai` - 1 * `role/director` - 0 * `role/exec`, `role/qa` - still live in the orgs too, pending #342 steps 3 and 4 **18 issues.** These reconcile exactly against the shortfall between the pre-rename and post-rename counts, which is how they surfaced: verifying that no issue lost its label during the rename turned up a population that had never been in scope to begin with. ## What this changes about the plan The rename mapping is now settled and proven, so the work here is no longer a design question. It is applying the same six mappings plus the two retirements to a different namespace, using a path the org sync cannot reach. The mapping, for the record: * `role/engineer` to `role/platform` * `role/ops` to `role/sysadmin` * `role/ai` to `role/eval` * `role/director` to `role/tpm` * `role/creator` to `role/devrel` * `role/design` to `role/frontend` * `role/gamedev` created, no predecessor * `role/exec` folded into `role/tpm`, `role/qa` retired, `role/human` unchanged ## Two things worth carrying into the fix **Repo-level labels are a different API surface.** `forgejo-label-taxonomy-sync.py` calls `org-label` throughout and its targets are org names. Reaching `coilysiren/*` means the repo label endpoints, and `agentic-os-kai/scripts/backfill-personal-labels.sh` is the existing path. Folding both onto the one declarative taxonomy file is the point of doing this at all, rather than renaming in a second place. **A rename must stay an edit in place.** The org converge preserved every label id, which is why no issue lost anything. Whatever touches the repo-level labels has to hold the same property, or 18 issues lose their labels instead of keeping them. ## Still unverified `coilysiren/inbox` and `coilysiren/lore` are private and were not readable unauthenticated. The 18 above are from a global issue search, so they include those repos, but the label inventory of each was not inspected. Confirm with credentials before planning the fix.

coilyco-ops referenced this issue

2026-08-26 02:45:37 +00:00

Eval prep: the measured gap on the seven-seat board, and every eval, prose, and content ticket folded into one ordering #357

coilyco-ops commented

2026-08-27 02:57:26 +00:00

Author

Member

Closed in the 2026-08-26 backlog burn-down (coilyco-bridge/agentic-os-kai#901).

This issue carried priority/P4, the icebox tier, meaning it had already been judged parked rather than planned. The burn-down changed what an open issue means: the tracker now holds work that is actually on the list, and the icebox lives in closed state instead of at the bottom of open.

Nothing here was judged wrong or worthless. If this becomes live work, reopen it. The whole set is recoverable with state:closed label:burndown-2026-08.

Closed in the 2026-08-26 backlog burn-down (coilyco-bridge/agentic-os-kai#901). This issue carried `priority/P4`, the icebox tier, meaning it had already been judged parked rather than planned. The burn-down changed what an open issue means: the tracker now holds work that is actually on the list, and the icebox lives in closed state instead of at the bottom of open. Nothing here was judged wrong or worthless. If this becomes live work, reopen it. The whole set is recoverable with `state:closed label:burndown-2026-08`.

coilyco-ops

2026-08-27 02:57:27 +00:00

closed this issue
added the
burndown-2026-08
label

No milestone

No project

No assignees

1 participant

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-flight-deck/agent-compose#343

No description provided.

Rows
Columns

Label namespaces outside the org sync: coilysiren repo labels and inbox's unprefixed taxonomy #343

What this carries

coilysiren repo-level labels

coilysiren/inbox

Unverified

What to do

Blocked by

Now measured: 18 issues stranded on retired label names

What this changes about the plan

Two things worth carrying into the fix

Still unverified

`coilysiren` repo-level labels

`coilysiren/inbox`