Skip to content

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

New issue
New issue
Open
Open
task: agent-maintained issue system: one label scheme, auto-labeling and a pending-decision view#284
Labels
area:processRepo-wide process, governance, privacy and security rulesbot-reviewedkind:taskBounded delivery task with a delegated slice

Description

@Dong1017
Dong1017
opened on Oct 31, 2026

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 now 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 current 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. The reviewer still asks for a link to the Issue-line delegation or confirmation that the decision owner has seen it; no formal approval is recorded. 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 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. Criterion 6 still needs verification: #303 currently names a pending maintainer scope decision, has no accepted scope reply in its comments, and lacks status:proposed, so it is absent from the specified view. No labels are changed here.
Decision needed: none. The bot-reviewed question is dispositioned in the 2026-11-04 record: the label is admitted as outside-owned rather than renamed, deleted or added to the managed manifest, and criteria 1 and 2 are read accordingly. Delivery of that disposition is PR #343, which is unmerged.
Next action: Merge #343 once it has the required approvals, then confirm a nightly safety-net run reports no drift. Criterion 5 is met: a 2026-11-04 census of all 47 open Issues finds 40 applicable and 0 status-block gaps, after #38, #315 and #320 were completed. This Issue closes when criterion 2 is delivered; no label, automation setting or acceptance criterion is changed by this update.

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

Completion and closure

Activity

  1. Dong1017
    added
    kind:taskBounded delivery task with a delegated slice
    area:processRepo-wide process, governance, privacy and security rules
    on Oct 31, 2026
  2. Dong1017
    added a parent issue on Oct 31, 2026

  3. Dong1017 commented on Oct 31, 2026

    @Dong1017
    Dong1017
    on Oct 31, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    **增量设计评审（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 关于标签不授予执行权限的既有约定。此处只评审方案，未提出新的硬门禁或执行授权。

  4. Dong1017 commented on Oct 31, 2026

    @Dong1017
    Dong1017
    on Oct 31, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    范围结论｜#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 需取舍的方案边界，不是认定当前已发生越权或授权执行任何实验。

  5. Dong1017 commented on Nov 1, 2026

    @Dong1017
    Dong1017
    on Nov 1, 2026
    CollaboratorAuthor

    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.

  6. Dong1017 commented on Nov 1, 2026

    @Dong1017
    Dong1017
    on Nov 1, 2026
    CollaboratorAuthor

    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.

  7. Dong1017 commented on Nov 1, 2026

    @Dong1017
    Dong1017
    on Nov 1, 2026
    CollaboratorAuthor

    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.

    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.

  8. Dong1017 commented on Nov 1, 2026

    @Dong1017
    Dong1017
    on Nov 1, 2026
    CollaboratorAuthor

    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.

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

    @agent-ci-infra-bot
    agent-ci-infra-botBot
    on Nov 3, 2026 – with agent-CI-Infra-bot

    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

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

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

  10. agent-ci-infra-bot
    added
    bot-reviewed
    on Nov 3, 2026

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

    @agent-ci-infra-bot
    agent-ci-infra-botBot
    on Nov 3, 2026 – with agent-CI-Infra-bot

    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

  12. Dong1017 commented on Nov 4, 2026

    @Dong1017
    Dong1017
    on Nov 4, 2026
    CollaboratorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:processRepo-wide process, governance, privacy and security rulesbot-reviewedkind:taskBounded delivery task with a delegated slice

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions