Repository navigation
user-interface: onboard one account-bound design route end to end and run the offer evals #8987
Description
Problem
#6449 builds the offer logic in /user-interface:design and writes its eval cases. Every installable account-bound row in plugins/user-interface/reference/routing.json is deferred, so nothing is offerable until one row is onboarded with a real sign-in. Onboarding needs a person's account, and running the evals is a paid run.
Criteria moved from #6449
- At least one account-bound route is onboarded end to end and marked
confirmed. - Onboard one account-bound route end to end with a sign-in, flip it to
confirmedwithas_ofupdated, and run the three evals (offer, decline, accept; paid).
Blocked by: #6449
Activity
github-actions commentedon Oct 22, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: #6449
I understood this as: once #6449 lands the offer logic, onboard one account-bound route in
plugins/user-interface/reference/routing.jsonwith a real sign-in. Then flip it toconfirmed, updateas_of, and run the three evals (offer, decline, accept).The sign-in needs a person's account and the evals are a paid run, so those done-when items can't be done by an unattended lane. Admission will handle that split. The eval spend comes from prepaid credit, so I raised no cost flag.
No duplicates found among the open issues I was given.
Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 25, 2026
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add
needs-human(orstatus: needs-decision) and say why in a comment.kyle-sexton commentedon Oct 25, 2026
Hold restored: the 2026-10-25 release took
needs-humanoff, but this issue does need a person under the owner's stop rule. Reason (attended): "Onboarding needs a person's account, and running the evals is a paid run"; onboard one route "with a sign-in"kyle-sexton commentedon Oct 27, 2026
Released for re-triage under the owner's standing direction (2026-10-27): a person is involved only for "1. A change to the original intent or vision. 2. A finding during implementation ... that changes the intent, vision or primary design. 3. A real HIGH/CRITICAL security or cost risk", where cost is anything that can bill (Azure, GitHub larger runners or private-repo Actions, paid storage, plan or seat changes) and model usage under the subscriptions or API credits is not cost. None applies here. The hold label came off and intake triage runs again; an open blocked-by edge, if any, makes admission wait for that blocker.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.melodic-automation-lanes commentedon Oct 27, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 27, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.melodic-automation-lanes commentedon Oct 27, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: After #6449 lands the offer logic, one account-bound row in plugins/user-interface/reference/routing.json is onboarded with a real sign-in, set to confirmed with as_of updated, and the offer, decline and accept evals are run.
Dependencies
Related work
Open questions
RECOMMENDED: figma@claude-plugins-official (account login, deferred, listed under three concerns) Basis: plugins/user-interface/reference/routing.json:12
RECOMMENDED: No: rewrite the body as a task list with the sign-in, the row flip and the eval run as separate done-when items, so a person does the sign-in and eval run. Basis: judgment
RECOMMENDED: Yes: settle the overlap first, or state that this issue owns only the one chosen row. Basis: 6667
Sources read
To answer, post a comment that starts with this line:
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 28, 2026
Re-triage. Not an owner stop. The eval run spends model credit, which the owner's rule does not count as cost, and the sign-in is an attended host step, not an intent, design or security decision. The issue waits on #6449, which is still open and already linked as its blocker.
The refinement's open questions, settled from the repository:
figma@claude-plugins-official. It is the highest-ranked installable account-bound row,account: login,status: deferred, and it appears under three concerns (plugins/user-interface/reference/routing.json:12,:30,:42). TheArtifactrow is alreadyconfirmedbut is a built-in tool, not an installable route.host-runis added so the issue lane does not pick this up.Acceptance criteria (run once #6449 is closed):
figma@claude-plugins-officialis installed and signed in on a host through the remote MCP server on a free plan, with no seat or plan purchase (if the route turns out to need a paid seat, stop and bring that to the owner as a cost question), and/user-interface:designoffers it for a typography-color, design-systems or design-tool-handoff request.plugins/user-interface/reference/routing.jsonreadstatus: confirmed, withas_ofset to the run date.