Fix #324: one-click label packs #333

crueber · 2026-09-11T16:02:38Z

crueber commented

2026-09-11 16:02:38 +00:00

Empty-state label-pack offer (GitHub + GitLab default sets, hex verified against live palettes) with one-click creation via sequential labels.create calls.

Final pack lists + sources (verified 2026-09-11)

GitHub pack (8 labels) — source: GET https://api.github.com/repos/albandil/Hex/labels, the 8 entries flagged "default": true on a pristine repo:

name	color	description
bug	#d73a4a	Something isn't working
duplicate	#cfd3d7	This issue or pull request already exists
enhancement	#a2eeef	New feature or request
good first issue	#7057ff	Good for newcomers
help wanted	#008672	Extra attention is needed
invalid	#e4e669	This doesn't seem right
question	#d876e3	Further information is requested
wontfix	#ffffff	This will not be worked on

Note: the issue sketch listed 9 labels incl. documentation (#0075ca), but the live API shows it is NOT among GitHub's current defaults, so the pack ships the 8 live-verified defaults rather than a stale memory.

GitLab pack (8 labels) — source: docs.gitlab.com Manage > Labels (names: bug, confirmed, critical, discussion, documentation, enhancement, suggestion, support) + colors from lib/gitlab/issues_labels.rb @ master (gitlab-org/gitlab, fetched via the public API):

name	color
bug	#d9534f
critical	#d9534f
confirmed	#d9534f
documentation	#f0ad4e
support	#f0ad4e
discussion	#428bca
suggestion	#428bca
enhancement	#5cb85c

GitLab generates no descriptions, so those entries carry none. Note: the issue sketch guessed an improvement label — the live source has suggestion instead. No scoped (::) labels, per the issue.

Creation mechanics — decision: option (a), sequential client-side POSTs

No bulk endpoint. One click fires sequential labels.create calls through the existing endpoint (8 requests, human-rate — same precedent as uploadFilesSequential). Rationale: zero backend change, triage gate enforced per request server-side, trivially correct; partial failure reports per label into the error tray and the reload shows what landed. Existing names are skipped case-insensitively (idempotent-ish re-add). A bulk POST …/labels/pack stays a follow-up if atomicity ever matters. No route-provider seam touched, so law 8 is untouched.

Gating / visibility

Chooser renders only when labels.length === 0 (a repo that deletes all labels sees it again — accepted per the issue). Buttons render for everyone exactly like the create form (no new client gating invented); the server 403s non-triage per request. Preview chips are color dots + default text (legible light/dark); cards collapse to one column under sm: (390px OK).

Tests

web/test/unit/label-packs.test.js: per-pack count (8), no case-insensitive dup names, 6-hex colors, name/description bounds per 02 §3.1, missingFromPack skip semantics.
node --test web/test/unit/*.test.js: 620/620 pass.
vite build: green. No backend touched → no go tests. No new deps.
Browser: not driven (shared obscura daemon blocks loopback per task brief) — left explicitly open for review.

Empty-state label-pack offer (GitHub + GitLab default sets, hex verified against live palettes) with one-click creation via sequential labels.create calls. ## Final pack lists + sources (verified 2026-09-11) **GitHub pack (8 labels)** — source: `GET https://api.github.com/repos/albandil/Hex/labels`, the 8 entries flagged `"default": true` on a pristine repo: | name | color | description | |---|---|---| | bug | #d73a4a | Something isn't working | | duplicate | #cfd3d7 | This issue or pull request already exists | | enhancement | #a2eeef | New feature or request | | good first issue | #7057ff | Good for newcomers | | help wanted | #008672 | Extra attention is needed | | invalid | #e4e669 | This doesn't seem right | | question | #d876e3 | Further information is requested | | wontfix | #ffffff | This will not be worked on | Note: the issue sketch listed 9 labels incl. `documentation` (#0075ca), but the live API shows it is NOT among GitHub's current defaults, so the pack ships the 8 live-verified defaults rather than a stale memory. **GitLab pack (8 labels)** — source: docs.gitlab.com Manage > Labels (names: bug, confirmed, critical, discussion, documentation, enhancement, suggestion, support) + colors from `lib/gitlab/issues_labels.rb` @ master (gitlab-org/gitlab, fetched via the public API): | name | color | |---|---| | bug | #d9534f | | critical | #d9534f | | confirmed | #d9534f | | documentation | #f0ad4e | | support | #f0ad4e | | discussion | #428bca | | suggestion | #428bca | | enhancement | #5cb85c | GitLab generates no descriptions, so those entries carry none. Note: the issue sketch guessed an `improvement` label — the live source has `suggestion` instead. No scoped (`::`) labels, per the issue. ## Creation mechanics — decision: option (a), sequential client-side POSTs No bulk endpoint. One click fires sequential `labels.create` calls through the existing endpoint (8 requests, human-rate — same precedent as uploadFilesSequential). Rationale: zero backend change, triage gate enforced per request server-side, trivially correct; partial failure reports per label into the error tray and the reload shows what landed. Existing names are skipped case-insensitively (idempotent-ish re-add). A bulk `POST …/labels/pack` stays a follow-up if atomicity ever matters. No route-provider seam touched, so law 8 is untouched. ## Gating / visibility Chooser renders only when `labels.length === 0` (a repo that deletes all labels sees it again — accepted per the issue). Buttons render for everyone exactly like the create form (no new client gating invented); the server 403s non-triage per request. Preview chips are color dots + default text (legible light/dark); cards collapse to one column under `sm:` (390px OK). ## Tests - `web/test/unit/label-packs.test.js`: per-pack count (8), no case-insensitive dup names, 6-hex colors, name/description bounds per 02 §3.1, `missingFromPack` skip semantics. - `node --test web/test/unit/*.test.js`: 620/620 pass. - `vite build`: green. No backend touched → no go tests. No new deps. - Browser: not driven (shared obscura daemon blocks loopback per task brief) — left explicitly open for review.

crueber added 1 commit

2026-09-11 16:02:39 +00:00

Fix #324 : one-click label packs on empty labels page (02 §11 UI decision) 58f182621e

Empty labels page offers GitHub + GitLab default packs (live-verified
palettes, see web/src/lib/label-packs.js header), added via sequential
labels.create calls — no backend change (option (a) from the issue).
Skips existing names; triage enforced per request server-side.

crueber referenced this pull request

2026-09-11 16:02:41 +00:00

Labels page: one-click label packs (GitHub / GitLab defaults) offered when the repo has no labels #324

crueber added 1 commit

2026-09-11 16:10:03 +00:00

Docs: record #324 label-pack chooser decision in 02 Decisions (law 12) 17f3a5bd9d

Follows the #323 precedent: pack sources, sequential-create
mechanics, empty-state-only visibility, no-new-gating stance.

crueber force-pushed fix/issue-324 from 17f3a5bd9d to f0de0e71da

2026-09-11 16:10:13 +00:00

Compare

crueber referenced this pull request

2026-09-11 16:10:21 +00:00

Labels page: one-click label packs (GitHub / GitLab defaults) offered when the repo has no labels #324

crueber merged commit 06dce2560d into main

2026-09-11 16:10:35 +00:00

crueber referenced this pull request from a commit

2026-09-11 16:10:36 +00:00

Merge pull request 'Fix #324: one-click label packs' (#333) from fix/issue-324 into main

crueber referenced this pull request

2026-09-11 16:10:36 +00:00

Labels page: one-click label packs (GitHub / GitLab defaults) offered when the repo has no labels #324

Sign in to join this conversation.

No reviewers

No labels

pr/merge protection rules

Rows
Columns