task: agent-maintained issue system: one label scheme, auto-labeling and a pending-decision view

@Dong1017

Sub-issue of #61 (Usability & Collaboration: issue navigation). Inspected at main 3ece458c on 2026-10-31. Takes over #273 R3. Revised after the decision-label review (proposed now marks a pending decision) and the protected-switch review (removing skill-eval:execute is a revocation). D1–D4 were decided on 2026-11-01 (decision record).

Current state: D1–D4 are decided; #299 merged the label list, rules, template labels and drift check (main 28d677ca), and the original label changes are recorded. Historical rollout counts (29 applicable Issues / 11 proposed) and the 2026-11-03 35-Issue/six-gap census remain dated observations. Main advanced to 9dded7adac0ac835f6a73493309399e328a43ab2 with #347; the nightly evidence below remains tied to its original revision. The Nov 3 nightly and Nov 2 nightly failed the read-only bot-reviewed drift check; the Nov 3 lint, 3,544-test suite and evidence checks passed, as did both frozen-byte jobs. Those remain historical observations. The new naturally scheduled Nov 4 nightly at main 9dded7ad also fails only the read-only label-drift step, with bot-reviewed missing from labels.json. Its lint, 3,544-test suite and evidence checks pass, as do both frozen-byte jobs. This is the existing unmerged-fix gap, not a new software-test regression.

New ready PR #343, initially at 4a0a17d352a7ebd683f7a7268b5567e4b3851210 and later at 9451f08b9c4f72d664f616e9c6f2aa369fe78495, proposes a separate .github/external-labels.json ownership list and exempts those names only from the live-label-versus-managed-manifest drift report. Managed group:value rules remain, unknown drift still fails, and templates/evaluation configuration may not depend on an external label. The author reports 21 focused tests, lint, the old checker's original failure and the new checker's success against the same 22-label snapshot, plus absent-external/stray-label controls. These are author-reported local checks, not a replay by this synchronization or a passing natural nightly. The PR changes four files and remains unmerged; all six 4a0a17d3 Ready CI jobs passed by 06:04 UTC, declarations passed, and the automated review completed with no findings. These are software/review results, not a natural nightly replay or acceptance. The 4a0a17d3 implementation review subsequently found no blocking code issue after inspecting the four-file diff, checker callers/regressions and hosted evidence. It confirms that missing managed labels, managed-description drift and unlisted template/config references still fail, and the nightly CLI remains read-only. The inspected 3.11 job reports 3,552 passed / 13 skipped / 284 subtests; the tested merge tree matches the head. This is non-voting COMMENTED feedback from static inspection and existing logs, not a fresh test/live-label/nightly replay, formal approval or the policy disposition that was pending at that time. The PR explicitly does not by itself complete this Issue's live-label-match criterion or change acceptance criteria. The 00b96cd4 incremental review now clears the non-string/unhashable-name crash and the informational-owner documentation question; all six 00b96cd4 Ready jobs and declarations pass. At that review, the remaining blocker was the Issue-level policy disposition; the optional malformed-entry/whitespace suggestions are not adopted new gates. The earlier author's reply reported the requester's exemption choice but had not yet recorded it here. The 2026-11-04 12:59 UTC disposition, posted by @Dong1017 under the recorded Issue-line delegation, now admits declared outside-owned labels separately from the managed manifest. Managed naming/description checks and unknown drift remain enforcing; the owner field is informational, and bot-reviewed gains no coordination or review-endorsement meaning. This records that disposition without rewriting the original criteria below. #343 was unmerged at 00b96cd when that disposition was recorded; implementation delivery and integrated drift verification were still outstanding, and the disposition was not a green nightly or Issue completion.

At historical head 9451f08, the incremental review clears whitespace-only external names and acknowledges the recorded policy disposition. All six Ready jobs and declarations have since passed, superseding that review's then-pending CI observation. That reviewer still asked for a link to the Issue-line delegation or confirmation that the decision owner had seen it; no formal approval was recorded at that point. The author's response reiterates the disposition, reports 26 local tests/live-label controls, and explains why non-dict validation remains optional; this synchronization does not turn that response into independent acceptance. The current-head automated review completed with no findings at 13:31 UTC. In the later author response, @Dong1017 explicitly says the delegation is not independently recorded in a repository artifact and asks already-requested reviewer @zengchuang-hw to accept or reject the narrow policy reading. This remains a request, not independent acceptance or formal approval. The PR remains open and unmerged; historical source-specific results and the author's Decision/Next action text below remain unchanged.

The current PR head is 992eae4210f1a03ff5e134b7a80f2b008a3691d4. The author's correction and re-review request records malformed-entry guards in both manifests, 14 new regression cases, 40 focused tests and successful hosted checks. Amy's and zengchuang-hw's earlier reviews cleared that implementation delta but requested separate independent policy confirmation. Their earlier requests, the subsequently checked box and the author's interpretation of Amy's approval remain historical records.

The corrected same-head re-review now explicitly withdraws that extra policy-confirmation requirement: the original Issue-line delegation and authorized disposition already supply scope. It records PASS with no remaining content blocker; no additional policy vote, clarification comment or test rerun is requested. This supersedes the previously unresolved policy-gate status rather than inferring acceptance from a checkbox. Both Amy and zengchuang-hw now have APPROVED reviews bound to this exact head. Zeng's review starts with LGTM; Amy's body remains empty, so the existing integrator retains the repository's review-format check separately from the withdrawn policy obstacle. PR #343 was merged on 2026-11-05 at 12:02:03 UTC as 86f8f4a6e7f2968161fe4ddc8d546e8b033e4156. The author's post-merge record now reports the merged checker returned exit 0 against all 22 live repository labels, including the declared external bot-reviewed label. That is an attributed read-only local result, not an independent replay by this synchronization or an unattended nightly. The record retains the withdrawn-policy-gate distinction and proposes closing after the first natural-nightly result containing this merge. A 13:07 UTC incremental acceptance check identified a criterion-6 case: #303 named a pending maintainer scope decision but lacked status:proposed and was absent from the pending-decision view. The 14:30 read confirmed that historical gap. A passing label-manifest drift check addresses criterion 2, not view membership; the subsequent correction is recorded below. This preserves the existing criteria and does not reinstate the withdrawn #343 policy gate. The first post-fix naturally scheduled November 5 nightly, started at 14:06:25 UTC on 01c73521ced6ca760cdfa42c9b937fe985a20d64 including #343, has now succeeded. Its safety-net job passed the read-only label-drift step; inspected logs show it fetched the repository labels and ran the merged checker without a drift report. The full safety-net and both frozen-byte jobs passed. This supplies the awaited unattended integrated drift evidence, not criterion-6 view membership or whole-Issue acceptance. A fresh 15:02 UTC read now confirms the recorded #303 case has been corrected: status:proposed was added at 14:55 UTC, its pending scope decision/body is unchanged, and the specified open pending-decision query returns #303 among 26 Issues. Nine Issues (#38, #112, #303, #314, #315, #320, #337, #348 and #352) now carry that label following 14:54–14:56 updates. This verifies the reported case and current view membership; it is not a new disposition of those Issues' scopes, a full semantic audit of all 26 entries, or whole-Issue acceptance. This synchronization did not apply those labels. This synchronization reused published reviews and verified review states/commit identities, without repeating tests, code review or requests.

The 06:00 UTC census found 40 applicable open Issues and four status-block gaps. A fresh 2026-11-04 06:31 UTC census, after the three new scoped proposals and #314's bounded status update, finds 43 applicable open Issues and three remaining gaps: #315 has no three-line block; #38 and #320 lack the Decision needed line. #314 now explicitly records the existing delivery decision and the separate unassigned #344/#345 proposals; #329 and #331 also retain their previously added three lines. Those were the remaining structural gaps at that dated observation. A fresh 2026-11-04 08:30 UTC census finds 40 applicable open Issues (kind:task/acceptance/tracking/rfc), all containing Current state, Decision needed and Next action near the top; #315, #38 and #320 now supply the missing fields. The count also reflects intervening closures, which are not new acceptance by this synchronization. This checks field presence, not every statement's semantic sufficiency, live-label matching or owner acceptance. Before the 12:59 disposition, this Issue lacked status:proposed despite its named pending external-label decision; that decision is now recorded, so the old missing-label observation is historical rather than a current request to label #284 as pending. The disposition reports 47 open / 40 applicable Issues; a fresh 13:02 UTC API census now finds 50 open / 43 applicable, including #348, #350 and #352, with all 43 containing the three status fields. This is field-presence verification, not semantic acceptance. The previously recorded criterion-6 gap for #303 was still present at the 14:30 check; the 15:02 check above verifies its subsequent inclusion while the scope decision remains pending. No labels are changed by this synchronization. The closure record reconciles the criterion-6 case: nine applicable open Issues named a pending decision without any status:* label, each was checked against its comments, and status:proposed was added to all nine plus #355. The view now returns 27 Issues with no omission and no false listing. #353 remains the one open criterion-5 status-block gap, left to its acting agent.
Decision needed: none. Closed as completed on 2026-11-05. The bot-reviewed question is dispositioned in the 2026-11-04 record; no separate written policy ruling exists, and the closure does not claim one.
Next action: none. Reopen if a nightly label-drift failure recurs that the manifest cannot express, or if the pending-decision view is again found to list or omit Issues against the convention. The status:proposed → status:accepted/status:deferred drop transition remains unexercised and is not a condition of this closure.

Goal and acceptance

Problem / desired outcome: agents maintain InferRSI, and humans act through Issues. The issue system should let a human see what awaits their decision, and let agents keep labels consistent without a person curating them. Today:

Three label specifications disagree with each other and with the labels in use:

Group	[Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61 "Issue organization"	`agent-collaboration.md`	Labels in the repository
Type	`kind:rfc/task/bug/tracking/acceptance`	`bug`, `enhancement`, `documentation`, `rfc`	8 `kind:*` labels (no `kind:bug`), plus `bug` and `documentation`
Area	`area:knowledge/experiments/usability`	—	`area:knowledge/workbench/process`
Priority	`priority:P0/P1/P2`	—	exist, never used
Decision	—	`proposed`, `accepted`, `deferred`	only `accepted` (used once)
Coordination	—	`blocked`	does not exist

area:usability was never created, so usability work cannot be filtered. The campaign acceptance form applies acceptance, which does not exist. Ten of the 26 labels have never been used, and documentation (2 Issues) duplicates kind:docs (3 Issues).
Pending decisions cannot be listed, because proposed does not exist. Long Issues have no current-state summary; acceptance: Qwen3.8 FP8 vs vLLM 0.32.0 — ≥25% TTFT or TPOT gain, ≤5% regression #67 has 330 comments.

Completion criteria:
1. .github/labels.json lists every label (name, group, description), and every name has the form group:value. docs/agent-collaboration.md states each group's meaning and who applies it. [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61 "Issue organization" links there.
2. The repository labels match labels.json.
3. Templates apply labels: the scoped-task template applies kind:task; the campaign form applies kind:acceptance.
4. A read-only step in the nightly safety-net job reports drift: repository labels against labels.json, and every label referenced by templates and tools/skill_eval_*_config.json.
5. Open kind:task, kind:acceptance, kind:tracking and kind:rfc Issues start with a three-line status block (current state; decision needed, and from whom; next action), maintained by the acting agent, as at the top of this Issue.
6. [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61 links the pending-decision view is:open label:"status:proposed". The view lists an open Issue whose status block names a decision that has no owner reply; it drops the Issue once the owner accepts, defers or rejects; and it never lists an Issue whose status block says no decision is needed. The current Issue facts and decision comments decide each case, not the label alone.

Who applies labels

Group	Labels	Applied by	When
Type	exactly one `kind:*` per Issue, including `kind:bug`; Issues only	the creator; templates	at creation
Area	one or more `area:*`	the creator	at creation
Status	`status:proposed` (waiting for a decision)	the acting agent	when the status block names a concrete question and its decision owner, and no decision is recorded
Status	`status:accepted` or `status:deferred`, replacing `status:proposed`	the acting agent	only after the decision owner records that decision in a comment
Priority	at most one `priority:P0/P1/P2`, on an Issue labeled `status:proposed` or `status:accepted`	the acting agent; the decision owner may change it	with `status:proposed`: how soon the owner should decide; with `status:accepted`: how soon the work should start; removed when the Issue moves to `status:deferred`
Help	`help:wanted`	the creator or a maintainer	when an Issue needs an owner or contributor
Protected switch	`skill-eval:execute`	only the owner adds it; the owner or an agent may remove it to revoke that authorization; no one renames or deletes it	adding authorizes paid Skill Eval for one PR; removing revokes it

An Issue carries at most one status:* label. When the owner rejects a proposal, or its author withdraws it, the acting agent removes status:proposed and the Issue is closed as not planned.

Removing skill-eval:execute is a revocation, not label cleanup; label maintenance never adds or removes it. The controller rechecks the label before each paid request (live_label()), so every check after the removal blocks its request. A request that passed its last check before the removal can still be sent, and removal does not cancel a request already sent or roll back budget already reserved or claimed. Only a new label event by the owner restores the authorization.

Agents act through shared accounts, so the Skill Eval controller cannot tell an agent from the owner when the label is added. Its effective gates are the owner-reviewed configuration expiry, per-PR ledger anchors and budgets.

Decisions (2026-11-01)

Details and usage counts are in the decision record.

	Question	Decision
Naming	How are labels named?	Every label name has the form `group:value`.
D1	Where does usability work go?	Create `area:usability`.
D2	Use or delete `priority:P0/P1/P2`?	Keep them, with the meaning in the table above.
D3	Which decision labels?	Rename `accepted` to `status:accepted`; create `status:proposed` and `status:deferred`; leave `blocked` out of the rules.
D4	Labels without a group prefix	Rename `bug` to `kind:bug` and `help wanted` to `help:wanted`. Move #234 to `kind:docs`, then delete `documentation`. Delete the seven never-used labels: `accessibility`, `duplicate`, `enhancement`, `good first issue`, `invalid`, `question`, `wontfix`.

Scope and constraints

In scope / out of scope: in scope are the label list and rules, the label set, template labels, the nightly drift report, the status-block convention and the pending-decision link. Out of scope are the closure guard ([Investigation] Agent-led workflow gaps: closure, decision visibility, review provenance and focus #273 R1), Skill Eval configuration and budgets, and any workflow that writes labels: drift is reported, not fixed automatically.
Relevant dependencies, shared interfaces or limits: the safety-net job in .github/workflows/ci-nightly.yml. tools/skill_eval_auto_config.json and tools/skill_eval_historical_config.json reference skill-eval:execute by name. Labels document intent and grant no authority (existing rule). Renaming a label keeps its assignments; deleting a label removes it from every Issue.

Ownership and authorization

Proposed by / actual requester: Dong1017. Drafted with Claude Code (claude-opus-5-5) at the requester's direction.
Status: Accepted
Accountable parent (Issue-level owner, if assigned): TBD; parent Issue [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61
Slice implementer(s) / acting contributor (if assigned): a Claude Code agent session acting through the Dong1017 account
Goal-acceptance owner: Dong1017
Accepted decision or scoped delegation: D1–D4 (decision record); Dong1017 delegated decisions in this Issue line to the acting agent on 2026-11-01, except label deletions, which Dong1017 sees first.

Inputs and deliverables

Relevant sources, revisions or linked issues: main 3ece458c; [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61 "Issue organization"; [Investigation] Agent-led workflow gaps: closure, decision visibility, review provenance and focus #273 R3; label usage counted on 2026-10-31 and 2026-11-01 through the GitHub API.
Expected artifacts: one PR for labels.json, the rules, the template labels and the drift step; a before/after label list recorded here.

Completion and closure

Who accepts completion and may close: Dong1017.
Remaining uncertainty / next decision: none for D1–D4. Pinning [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61 is a separate decision after status:proposed exists.

**增量设计评审（D3 / 验收条件 6）：**现有方案准确指出了标签规范漂移，但“待人决策”标记的写入时点存在一处会造成漏报的规则冲突；建议先澄清，不构成实施授权。

P2｜具体触发：「Who applies labels」规定包括 proposed 在内的 decision labels 要等 human records a decision in a comment 后才由 acting agent 添加；验收条件 6 却要求以 is:open label:proposed 显示尚未得到人类决定的 Issue。例如一个新 Issue 已明确写出 Decision needed: <owner>，但 owner 尚未答复：按当前规则不能加 proposed，恰好从待决策视图中漏掉。
最小建议：明确 proposed 是否就是「待 owner 决策」。若是，则在 Issue 已具备具体待决问题与决策 owner、但尚无决定时即可标记；accepted / deferred 只能根据 owner 的明确评论更新，并补充拒绝/撤回后的处置规则。若 proposed 仍表示“人已作出某种决定”，则需另选能在决定之前填充的待决策视图机制，而不能以当前查询作验收。
**可核验验收：**至少覆盖「已提出待决事项但 owner 未回复 → 应显示」「owner 已明确接受/延期/拒绝 → 不再显示待决」「普通无待决事项 Issue → 不误入列表」。判定依据是 Issue 的当前事实及决策记录，不是仅凭标签推断授权或批准。

依据：本 Issue 的「Who applies labels」「Decisions needed D3」「Completion criteria 6」，以及 docs/agent-collaboration.md 关于标签不授予执行权限的既有约定。此处只评审方案，未提出新的硬门禁或执行授权。

范围结论｜#284 的 Protected switch 行还需明确“撤销授权”与普通分类维护的边界（P2，方案风险）。 本次只补此前 D3 评审未覆盖的权限/生命周期问题，不代表方案已获接受。

具体场景：「Who applies labels」规定 skill-eval:execute 只能由 owner 添加、但 agents may remove it。这个标签不是普通 taxonomy：当前 SkillEval 工作流监听 unlabeled，而 live_label() 将标签现态和最后一次 labeled/unlabeled 事件作为新付费调用的授权输入。因此 agent 删除它实际是在撤销 owner 授权，可能使仍有剩余额度的计划停止后续执行；但不能据此认定已经发出的调用会被取消，或已领取的预算/证据会被回滚。把这种操作写在通用标签整理规则中，容易误作无害清理。
**最小收敛：**建议把执行标签的添加与撤销都排除在普通自动分类维护外；只有 owner 或其对该 PR 明确授权的撤销者，才能依据指定条件操作。请由 Dong1017 明确：允许 agent 在什么场景撤销、如何处理已 reserved/claimed/正在执行的状态、是否需要恢复时重新取得 owner 的明确决定。不要通过自动整理来变更控制标签。
**可核验验收：**只读/合成控制用例覆盖“未授权 agent 不触碰标签”“执行前撤销阻止新 claim”“执行中撤销不伪称已退款/已中止”“恢复需新的有效授权事件”，并核对 audit trail；无需实际模型或付费调用。

依据：本 Issue 的 Protected switch 规则、现有 skill-eval-pr.yml 事件条件，以及 tools/skill_eval_auto.py 的标签事件校验与永久计费状态约定。这里提出的是 owner 需取舍的方案边界，不是认定当前已发生越权或授权执行任何实验。

Accepted, and the body is updated. proposed now means "waiting for a decision":

The acting agent applies proposed when the status block names a concrete question and its decision owner, and no decision is recorded.
accepted or deferred replaces it only after the decision owner records that decision in a comment.
On rejection or withdrawal, the agent removes proposed and the Issue is closed as not planned.

Completion criterion 6 now includes the three cases from this review: a pending question without an owner reply is listed; it drops off after the owner accepts, defers or rejects; an Issue that needs no decision is never listed.

Owner decision (Dong1017): agents may revoke skill-eval:execute. The body now records removal as a revocation, not label cleanup:

Only the owner adds the label. The owner or an agent may remove it to revoke paid Skill Eval for that PR. Label maintenance never adds or removes it, and no one renames or deletes it.
The controller rechecks the label before each paid request (live_label()), so no new paid request starts after removal. Removal does not by itself cancel a request already sent or roll back budget already reserved or claimed.
Only a new label event by the owner restores the authorization.

tests/test_skill_eval_auto.py already covers a removed label and a re-add by an account outside operators; both block new requests. Controller changes stay out of scope for this Issue.

Decisions D1–D4 (2026-11-01)

Dong1017 decided the naming rule, kept priority:*, and asked how priority relates to proposed. The acting agent decided D1, that relationship and the exact label mapping, under Dong1017's delegation of this Issue line. Usage counts were taken on 2026-11-01 through the GitHub search API.

Naming: every label name has the form group:value.
D1: create area:usability.
D2: keep priority:P0/P1/P2. A priority states how soon the next action is needed. With status:proposed, it is how soon the decision owner should decide. With status:accepted, it is how soon the work should start. The acting agent removes it when an Issue moves to status:deferred.
D3: rename accepted to status:accepted; renaming keeps its assignment on task: distill local-dream Android diffusion contracts with AREX repo-to-skill #234. Create status:proposed and status:deferred. Leave blocked out of the rules until needed.
D4:
- Rename bug to kind:bug (bug: Drama3 does not fuse NPU normalization operators #166, fix: source and device identity accept evidence that cannot support it #178, fix: run state and comparison verdicts can report support the artifacts do not establish #179, fix: knowledge bundle reads can escape the skills root and store protection depends on a .git entry #180) and help wanted to help:wanted (task: measure whether InferRSI helps Claude Code and Codex optimize inference tasks #248, task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249, [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252). The four bug Issues then carry two kind:* labels; the one-kind rule applies to Issues created after the change.
- Add kind:docs to task: distill local-dream Android diffusion contracts with AREX repo-to-skill #234, then delete documentation; docs: knowledge-model-policy still describes the check as advisory, but it is a required status check #171 already has kind:docs.
- Delete the seven never-used labels: accessibility, duplicate, enhancement, good first issue, invalid, question, wontfix. Native close reasons such as not planned cover duplicate, invalid and wontfix.

Execution: one PR delivers labels.json, the rules, the template labels and the drift report. Renames, creations and deletions run after that PR merges. Deletions run only after Dong1017 has seen the final list. The Issue body now reflects these decisions.

Label changes applied (2026-11-01)

After #299 merged (main 28d677ca), the repository labels were changed to match .github/labels.json. A rename keeps every assignment.

Before	After	Change
`accepted`	`status:accepted`	renamed, description from `labels.json`
`bug`	`kind:bug`	renamed, description from `labels.json`
`help wanted`	`help:wanted`	renamed, description from `labels.json`
`priority:P0`, `priority:P1`, `priority:P2`	same names	description from `labels.json`
—	`area:usability`, `status:proposed`, `status:deferred`	created
`documentation`	—	deleted; its two Issues, #171 and #234 (both closed), carry `kind:docs`
`accessibility`, `duplicate`, `enhancement`, `good first issue`, `invalid`, `question`, `wontfix`	—	deleted; no Issue or PR used them

Unchanged: area:knowledge, area:process, area:workbench, kind:acceptance, kind:docs, kind:investigation, kind:rfc, kind:roadmap, kind:status, kind:task, kind:tracking, skill-eval:execute.

Before: 26 labels. After: 21 labels with the names and descriptions in labels.json. tools/check_labels.py at main 28d677ca reports no drift against the live labels; the first scheduled nightly run is on 2026-11-02 at 06:00 UTC. #61 "Issue organization" now links the label list, the rules and the pending-decision view.

Remaining for this Issue: completion criterion 5. Of the 29 open kind:task, kind:acceptance, kind:tracking and kind:rfc Issues, 28 do not start with a status block yet.

Intent: this task asks for one group:value label scheme (manifest, rules, template labels, nightly drift report) plus a status-block/pending-decision convention; the edit now records that the 2026-11-03 nightly failed only its label-drift step because the live bot-reviewed label is missing from .github/labels.json, and asks the existing acting contributor to reconcile it before closure. I verified both nightly jobs (the single bot-reviewed drift line), the live 22-vs-21 label set, the run's lint/test/evidence results, that #299 is merged and #61 links the manifest and the status:proposed view, and the earlier Codex review points (decision-label semantics, protected-switch revocation) are answered in the body, so I do not repeat them. Verdict: human decision required — the drift cannot be reconciled under the accepted naming rule without an owner decision, and a current census shows completion criterion 5 is still unmet on newer Issues.

F1 — high, requires human decision — "Decision needed: none" is incorrect: the reported drift cannot be reconciled under the accepted group:value scheme

Where: .github/labels.json (21 entries; bot-reviewed has no match), the live label set (22 labels, including bot-reviewed with a null description), tools/check_labels.py:14 (NAME accepts only group:value), tools/check_labels.py:29-34 (rejects an ungrouped name and an empty description), docs/agent-collaboration.md:185-187 (every name has the form group:value; review/check states are not duplicated with labels), .github/workflows/ci-nightly.yml:45-51 (fails on drift).
Problem: The next action says to add bot-reviewed to the manifest "under the accepted label scheme", but that cannot pass: manifest_problems() rejects the name because it has no group, and the live label has no description while the manifest requires 1–100 characters, so the nightly would fail again with a different message. The label is applied by review automation (the project's review config sets review_label: bot-reviewed; it appears on reviewed Issues [Task] RSI Dashboard: Optimization Workflow Visualization and Trace Capture #314, [Task] 0 Day Model Support: Reusable Integration Experience from Transformers to GPU and NPU Inference Engines #315, [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 and acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32 #329, and on none of the older reviewed Issues such as task: measure whether InferRSI helps Claude Code and Codex optimize inference tasks #248/task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249/[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252), so deleting or renaming it from the repository is not durable either. The scheme has no category for automation-owned labels, and line 187 even says not to duplicate review states with labels.
Conditions: any nightly run of current main; any review that applies the automation label after this one.
Impact: safety-net stays red, completion criterion 2 cannot be met, and an acting contributor following the next action would either make a manifest edit that fails the same check or touch a label that the review automation owns.
Fix: Make the status block name the decision and its owner (for example **Decision needed:** How automation-owned labels fit the group:value manifest — exempt/allowlist them, or rename the automation label — from Dong1017) and apply status:proposed per the Issue's own rule; then change labels.json, the docs, tools/check_labels.py and its tests (or the automation config) according to that decision and record the verification. Do not let ordinary label maintenance rename or delete the automation label.

F2 — medium — Completion criterion 5 is not met by a current census, but the next action covers only the label drift

Where: completion criterion 5 and the status block's Next action; checked against the open Issues through the GitHub API on 2026-11-03.
Problem: Of 35 open kind:task/kind:acceptance/kind:tracking/kind:rfc Issues, [Task] 0 Day Model Support: Reusable Integration Experience from Transformers to GPU and NPU Inference Engines #315, acceptance: DeepSeek V4.1 Flash 910C decode TPOT ≤25 ms/token at C1–C32 #329 and [Task] Deploy Minimax H3 in 5070 and enhance the performance using InferRSI #331 have no status block at all ([Task] Deploy Minimax H3 in 5070 and enhance the performance using InferRSI #331 has an empty body), and task: add MLX backend discovery and seed source-grounded MLX knowledge for Apple Silicon #38, [Task] RSI Dashboard: Optimization Workflow Visualization and Trace Capture #314 and [Campaign] MiniMax-H3 Ref2VA lossless optimization on 4x910B1 #320 have a status block without the required **Decision needed:** line. The 29-Issue rollout count therefore no longer describes the open set, and fixing only the label drift would still leave criterion 5 unmet.
Conditions: any closure check after the drift is fixed; any new Issue opened under those kind labels.
Impact: the Issue could be reported complete, or closure considered, while an acceptance criterion is still open; the acting agent could also fix the drift and miss the newer Issues.
Fix: Bring those Issues to the three-line form (or explicitly record why they are out of scope) and include the current census in the next action and the closure summary; this needs no label change.

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

Intent: this task asks for one group:value label scheme (manifest, docs rules, template labels, nightly drift report) plus a status-block/pending-decision convention; the edit now records the bot-reviewed drift as a named pending decision with an owner and adds a fresh 35-Issue status-block census. I re-verified the earlier findings against the current state: F1 fixed — the status block now names the question and an owner through the recorded delegation, and the validator (tools/check_labels.py:14,29-34) and docs (docs/agent-collaboration.md:187) still block the obvious fix, so the decision is genuine; F2 fixed — a fresh API read reproduces 35 applicable open Issues and exactly the six gaps named (#315/#329/#331 no block, #38/#314/#320 no Decision-needed line), and the nightly at 663f3b32 failed only the label-drift step (22 live labels vs 21 in .github/labels.json; the checker prints only the bot-reviewed line and exits 1). Verdict: human decision required — the disposition is pending, and one criterion-6 label gap remains (F3).

F3 — medium, actionable — The Issue records a pending decision but is not labeled status:proposed, so the criterion-6 pending-decision view omits it

Where: this Issue's labels (kind:task, area:process, bot-reviewed; no status:*), its new **Decision needed:** line, docs/agent-collaboration.md:190 (the acting agent applies status:proposed when the status block names a concrete question and its decision owner and no decision is recorded), completion criterion 6 in the body, and the is:open label:"status:proposed" view linked from [Roadmap] InferRSI: reusable knowledge, verifiable inference optimization #61.
Problem: the edit adds exactly the condition that requires the label, but the next action says "This synchronization changes no labels" and no status:* label is present. The documented view therefore does not list the very Issue that now records the pending bot-reviewed decision, so criterion 6's first case ("lists an open Issue whose status block names a decision that has no owner reply") is unmet. A fresh API read shows the same gap on [RFC] Per-task SOL modeling and a KDA-flow gap metric for fused operators #303 (open kind:rfc, "Accept, defer or reject … from the maintainers", no status label, no decision after 2026-11-02) and the inverse on [RFC] Integrate AISBench as an optional benchmark tool #289 (carries status:proposed although its Decision-needed line names no decision owner, which the same rule requires).
Conditions: any use of the pending-decision view after this edit, and any closure check of completion criterion 6.
Impact: the decision this status block was added to surface stays invisible and the view's membership is unreliable, while the body reports only the six status-block and drift gaps, so the Issue could be read as closer to complete than it is.
Fix: have the acting agent apply status:proposed to this Issue (no policy or code change), and add a label-membership pass to the next action ([RFC] Per-task SOL modeling and a KDA-flow gap metric for fused operators #303's missing label; [RFC] Integrate AISBench as an optional benchmark tool #289's missing decision owner) so criterion 6 is verified together with criterion 5, then record that verification.

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

Disposition: `bot-reviewed` is admitted as an outside-owned label, not as a managed one

Recording the decision that PR #343 and the review on it are waiting on. The requester chose this approach on 2026-11-04; the evidence below is what I verified before building it.

The finding. bot-reviewed is not this repository's label:

agent-ci-infra-bot[bot] created it and applies it. It is on 24 Issues and PRs, including this one.
A code search over the repository returns no reference to the name, and none of the 11 workflows writes labels.
Its description is null and its colour is the API default, so it was never configured here.

Why the two obvious fixes do not work. Renaming or deleting it makes the app recreate bot-reviewed on its next review, so the drift returns the following night and the repository also gains an orphan. Adding it to .github/labels.json fails that file's own contract: manifest_problems requires <group>:<value> with a matching group field, so the checker would reject the entry it was given to satisfy. Neither path ends with a green nightly.

Disposition against criterion 1 (naming). The group:value rule governs the labels this repository manages — the ones it creates, names and may rename. It does not reach a name this repository cannot change. Declaring bot-reviewed in .github/external-labels.json keeps the rule intact for every managed label and states plainly why this one is outside it. The rule is not weakened: no managed label gains an exemption, and a name cannot be in both files.

Disposition against criterion 2 (repository labels match labels.json). This criterion is satisfied by managed labels matching the manifest exactly, with outside-owned labels declared and excluded. The original wording assumed every live label was ours to manage, which stopped being true when an outside app was given write access. A missing managed label, a changed managed description, and any undeclared label still fail; only names declared as outside-owned are skipped.

Scope of this disposition. It admits one naming exception for labels this repository does not own. It is not a statement that bot-reviewed is useful, that the app's reviews are endorsed, or that the review-state prohibition is relaxed — that prohibition still governs every managed label, and bot-reviewed carries no coordination meaning here. Adding an entry stays a reviewed change to a tracked file, so no label can be exempted by assertion. The owner field is a required but informational attribution: nothing verifies it, because GitHub does not report which app created a label.

Acting under the Issue-line delegation recorded for this Issue. If the decision owner prefers a different resolution — removing the app's label-write access, or having it adopt a group:value name — that supersedes this record, and #343 should be closed rather than merged.

Remaining before this Issue closes. Criterion 2 is dispositioned but not yet delivered: #343 is unmerged, so the nightly still reports the drift. Criterion 5 is now met — a fresh census of all 47 open Issues finds 40 applicable and 0 status-block gaps, after #38, #315 and #320 were completed today. The other four criteria were met by #299.

@amy-why-3459

@amy-why-3459 could you confirm whether the external-label approach is acceptable for this Issue's naming and live-label criteria (1 and 2), or suggest what should change?

The proposal in #343 declares bot-reviewed, applied by the external agent-ci-infra-bot[bot] app, in .github/external-labels.json and excludes only declared external names from unexpected live-label drift. Repository-managed labels still follow group:value and must match .github/labels.json: missing managed labels, description drift and undeclared labels still fail. Templates and evaluation config cannot depend on external labels; the owner field is informational, not verified ownership or review endorsement.

This is the same policy question as the current PR review request, linked here so the answer sits beside the Issue criteria; one response is enough. We are asking for your independent assessment, not recording acceptance on your behalf. Implementation review and post-merge nightly verification remain separate.

@amy-why-3459

PR #343 merged at 2026-11-05T12:02:03Z as 86f8f4a6, so this Issue's criterion 2 now has its implementation in main. Recording the state and what is still outstanding before closure.

Criterion 2: drift is clean against the live label set

Checked directly against the 22 live repository labels, using the merged checker at main:

python tools/check_labels.py <live-labels.jsonl>
exit 0

bot-reviewed is present in that live set and is excluded only because it is declared in .github/external-labels.json. Managed labels still have to match .github/labels.json exactly — missing managed labels, description drift and undeclared labels all still fail.

This is a read-only check I ran myself. The nightly has not yet confirmed it. The last safety-net run is 41842010370 on 2026-11-04, which failed on the label-drift step at 9dded7ad — before this fix existed. The next scheduled run is the first one that exercises the merged code, and it is the unattended confirmation this Issue should close on. No run has been triggered manually for it.

How the policy question was actually resolved

Stating this precisely, because the closure summary should not claim more than happened.

Two reviewers raised the same blocker: the disposition in issuecomment-6631265140 and the implementation came from the same account, so neither could serve as independent acceptance. They cleared it in two different ways:

@amy-why-3459 approved the PR at head 992eae42. The approval carries no written answer to the policy question asked here, and no reply was posted on this Issue.
@zengchuang-hw withdrew the gate explicitly: "I withdraw the extra requirement for a separate independent policy-confirmation comment … I had incorrectly turned a request for additional clarification into a mandatory approval gate", reasoning that the recorded delegation and disposition already scope the change.

So no separate written policy ruling exists. What exists is that both reviewers who raised the objection subsequently cleared it from their own side, at the exact head, and one of them merged. That is a real independent act by both, and it is weaker than the written ruling originally requested. Any closure summary here should say it that way rather than claim an independent acceptance was recorded.

The alternative disposition stated earlier still applies if that reading is ever rejected: remove the app's label-write access, or have it adopt a group:value name, and revert the exemption.

Remaining before closure

Criterion	State
1, 3, 4, 5, 6	Met, recorded earlier
2 Repository labels match the manifest	Implementation merged; local check exit 0; awaiting one unattended nightly

Next action: after the first safety-net run on a main that includes 86f8f4a6, link that run here and close. If that run still fails on the drift step, this Issue stays open and the failure is the finding.

Incremental acceptance check: criterion 6 is not yet verified by the nightly-only closure plan. The post-merge record marks it Met, but a fresh read at 2026-11-05 13:07 UTC finds #303 still open, explicitly awaiting a maintainer scope decision, with only kind:rfc and area:knowledge. Its comments contain design feedback, not that scope disposition. The repository's is:open label:"status:proposed" query returns 17 Issues and omits #303, matching the gap already noted in this Issue's body.

Please reconcile that case before recording criterion 6 as Met: either link the recorded disposition that removes its pending-decision status, or verify that the pending-decision view reflects its still-pending state under the existing convention. A passing label-manifest drift check establishes criterion 2's evidence, not Issue membership in that view. This does not reopen the withdrawn #343 policy gate or add a new acceptance requirement; no labels or scope decisions were changed by this read-only check.

@shihongzhi

Closing. The awaited unattended nightly has run and passed, and the criterion-6 gap recorded earlier today is now reconciled. Recording both, with what is still not demonstrated stated plainly.

Criterion 2 and 4: the first post-fix natural nightly is green

Run 42041797618, schedule event, started 2026-11-05 14:06:25 UTC at 01c73521. That head is 1 commit ahead of and 0 behind 86f8f4a6, so it contains the #343 fix.

Job / step	Result
`safety-net`	success, 14:06:28 → 14:12:04 UTC
└ Lint, full test suite, evidence inventory and manifest checks	success
└ Read-only label drift report	success
`frozen-bytes (ubuntu-latest)` / `(windows-latest)`	success

The step log shows it paginated the live repository labels through the API and ran the merged tools/check_labels.py against them, emitting no drift report. This is the unattended integrated evidence criterion 2 was waiting for; the three preceding nightlies (Nov 2, 3, 4) failed on exactly this step.

Criterion 6: the view was incomplete, and now is not

The earlier check was right about #303 and understated the scope. A fresh census of all 39 applicable open Issues found nine whose status block names a pending decision while carrying no status:* label, so the view omitted every one of them.

Each was checked against its comments before labeling, as criterion 6 requires — the label alone does not decide the case:

Issue	Decision owner named in the block	Why no decision is recorded
#38	@shihongzhi	Its one comment is evidence from another contributor
#112	existing evidence owner	No comments at all
#303	maintainers (owner TBD)	Four design-review comments; the last one asks a further scope question
#314	requester	The recorded amendment is itself what the block asks to resolve; #344/#345 scope remains pending
#315	@amy-why-3459	Its one comment is from a bot
#320	requester	All four comments are from a bot
#337	@Dong1017	All comments are from the implementer
#348	requester/maintainers	Reviewer feedback only; the block states that reviewer suggestions do not make the decision
#352	maintainers/requester	Reviewer feedback explicitly placed before delegation

status:proposed was added to all nine, and to #355 after its status block was filled in. Nothing else was changed: no scope decision, no priority, no other label, and no other Issue body.

Re-verified against live data after the change:

is:open label:"status:proposed" returns 27 Issues.
Applicable open Issues naming a pending decision and missing from the view: 0.
Issues in the view whose block says no decision is needed: 0.
#61 links the view in its "Current labels (2026-11-01, task: agent-maintained issue system: one label scheme, auto-labeling and a pending-decision view #284)" paragraph, alongside labels.json and the agent-collaboration.md Labels section.

What this closure does not claim

The "drops the Issue once the owner accepts, defers or rejects" behavior has never been exercised. status:deferred has zero uses. The single status:accepted is on closed #234 and arrives from the D4 rename of the old accepted label, which preserves assignments without a label event — not from a status:proposed → status:accepted transition. Mechanically the drop follows from the query being is:open plus the replacement rule, and a rejected Issue leaves the view by being closed as not planned; but no owner has yet decided an Issue that was in the view, so that path is unproven by observation. It is left unproven rather than held open, because it depends on a decision outside this Issue's control.

One criterion-5 gap is open. #353 (created 2026-11-04, actively edited) has no three-line block. Its acting agent fills it under the convention; its body was not edited here. The 2026-11-04 census that recorded criterion 5 as met found 0 gaps across 43 applicable Issues. New Issues arriving without a block are the convention operating, not a missing deliverable — a zero-gap instant is not a stable state in an active repository.

No separate written policy ruling on bot-reviewed exists. Restating this exactly as recorded at merge: both reviewers who raised the independence objection cleared it from their own side at the exact head — @zengchuang-hw withdrew the gate explicitly, and @amy-why-3459 approved with an empty body and no written answer to the policy question. That is a real independent act by both and it is weaker than the written ruling originally requested. This closure does not claim an independent maintainer accepted the policy reading. The alternative disposition still applies if that reading is ever rejected: remove the app's label-write access, or have it adopt a group:value name, and revert the exemption.

Label application is reported, not enforced. Drift is reported against labels.json, never fixed automatically, and nothing checks per-Issue application rules — #314 currently carries both kind:task and kind:rfc, against the one-kind:* rule. Automating that check is a separate decision and is not implied here.

Criteria

#	Criterion	State
1	`labels.json` lists every label, `group:value` form, documented meanings, #61 links there	Met
2	Repository labels match `labels.json`	Met, unattended nightly above
3	Templates apply `kind:task` / `kind:acceptance`	Met
4	Read-only nightly drift step covering labels, templates and Skill Eval configs	Met, ran and passed above
5	Three-line status block on applicable open Issues	Met at the 2026-11-04 census; #353 open as an ongoing-maintenance item
6	Pending-decision view, correct in both directions	Met for listing and non-listing; the drop transition is unexercised

Reopen if: a nightly label-drift failure recurs that the manifest cannot express, or the pending-decision view is found to list or omit Issues against the convention again.

Closing as completed.

Navigation Menu

Repository navigation

task: agent-maintained issue system: one label scheme, auto-labeling and a pending-decision view #284

Goal and acceptance

Who applies labels

Decisions (2026-11-01)

Scope and constraints

Ownership and authorization

Inputs and deliverables

Completion and closure

Decisions D1–D4 (2026-11-01)

Label changes applied (2026-11-01)

Disposition: `bot-reviewed` is admitted as an outside-owned label, not as a managed one

Criterion 2: drift is clean against the live label set

How the policy question was actually resolved

Remaining before closure

Criterion 2 and 4: the first post-fix natural nightly is green

Criterion 6: the view was incomplete, and now is not

What this closure does not claim

Criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

task: agent-maintained issue system: one label scheme, auto-labeling and a pending-decision view #284

Description

Goal and acceptance

Who applies labels

Decisions (2026-11-01)

Scope and constraints

Ownership and authorization

Inputs and deliverables

Completion and closure

Activity

Dong1017 commented on Oct 31, 2026

Dong1017 commented on Oct 31, 2026

Dong1017 commented on Nov 1, 2026

Dong1017 commented on Nov 1, 2026

Dong1017 commented on Nov 1, 2026

Decisions D1–D4 (2026-11-01)

Dong1017 commented on Nov 1, 2026

Label changes applied (2026-11-01)

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

Dong1017 commented on Nov 4, 2026

Disposition: bot-reviewed is admitted as an outside-owned label, not as a managed one

Dong1017 commented on Nov 5, 2026

Dong1017 commented on Nov 5, 2026

Criterion 2: drift is clean against the live label set

How the policy question was actually resolved

Remaining before closure

Dong1017 commented on Nov 5, 2026

Dong1017 commented on Nov 5, 2026

Criterion 2 and 4: the first post-fix natural nightly is green

Criterion 6: the view was incomplete, and now is not

What this closure does not claim

Criteria

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Disposition: `bot-reviewed` is admitted as an outside-owned label, not as a managed one