Skip to content

QEP-4: Automation Registry and Label Coordination (Draft) - #8

Open
mmcky wants to merge 3 commits into
mainfrom
qep-0004
Open

QEP-4: Automation Registry and Label Coordination (Draft)#8
mmcky wants to merge 3 commits into
mainfrom
qep-0004

Conversation

@mmcky

@mmcky mmcky commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

QEP-4: Automation Registry and Label Coordination

Status: Draft · Type: standard · Discussion: grew out of the QEP-2 field reports

QEP-2 standardises the human label vocabulary and a closed set of bot diagnostics, but field use surfaced a second kind of bot label it can't describe: labels automations use to coordinateaction-translation routing the Translation-Sync rollup, status-report letting the weekly-reports workflow find its own issues. These contracts evolve with the tooling, so they shouldn't be baked into a QEP label-by-label. This QEP resolves that with a registrar model: the QEP allocates the boundary, the automation owns the interior.

What it defines

  • The registry — one entry per automation: a durable origin label (full name, e.g. action-translation, on every artifact it creates), an optional task prefix (short, capability-named, /-separated, e.g. translate/), a family grey from the #ededed#bdbdbd band, a service area, and a contract link. Registration requires a documented consumer you can point at; adding/removing an entry is a substantive amendment, while everything inside a namespace never touches a QEP.
  • Three label tiersautomated (org-wide union query) and the origin label are durable; task labels are transient. Origin marks authorship, not participation.
  • Mailbox coordination semantics — worker-owns: apply = enqueue (open to org automations and maintainers by default), owner-removes = complete, human-removes = cancel, dead-letter on can't-act, and completion is inert (the anti-loop rule). Owners provision and garbage-collect their zones.
  • The token gateGITHUB_TOKEN events don't cascade, so bot→bot enqueueing requires a deliberately provisioned App/PAT: the human decision sits exactly where coordination power is granted. Humans trigger via the UI freely, floored by triage permission.
  • Tooling rulessync never touches a registered zone; prune skips registered zones mechanically instead of relying on a human recognising a routing key.

Founding registrations

Automation Origin label Task prefix Family grey
action-translation action-translation translate/ #e5e5e5
reports-activity (weekly reports) status-report #d5d5d5

Relationship to QEP-2

QEP-2 keeps automated + the three diagnostics as core vocabulary and is now fully self-contained: under the cross-QEP convention adopted in #9, an in-review QEP is never forward-referenced by the standards it extends — instead this QEP carries the amendments to QEP-2. The draft's new Amendments to QEP-2 section preserves, verbatim, the registry hooks originally drafted inside QEP-2 during co-development (the related:/Related pairing, the origin/task-label policy sentences, the prune skip-rule, the grey-band registration clause); the acceptance PR re-applies them in their review-settled form, bumping QEP-2's version if it is Accepted by then (Rollout step 2). The machine-readable registry (qep-0004-automations.yml, following QEP-2's companion-file pattern) ships at acceptance per the Rollout — the appendix CI check needs a small extension for the registry schema first.

Decision deadline

To be set by the author once the draft has had a round of review.

🤖 Generated with Claude Code

Registry of QuantEcon automations and the label-coordination policy
designed in the QEP-2 field-report thread: registering an automation
grants a durable origin label and optionally a /-separated task
namespace whose interior is the owner's contract, free to evolve
without QEP amendment. Defines the mailbox semantics (apply=enqueue,
owner-removes=complete, human-removes=cancel), the anti-loop rule,
token mechanics, the grey-band colour allocation, and the prune/sync
skip rules. Founding registrations: action-translation (translate/)
and reports-activity's status-report.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings July 23, 2026 02:46

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds QEP-4 as a new Draft standard proposal defining a registry model for automation-owned coordination labels (origin labels + optional task namespaces), and registers it in the README index so it becomes part of the QEP registry.

Changes:

  • Add QEP-4 document (Draft, standard) describing registry fields, label tiers, and coordination semantics (“mailbox model”).
  • Add QEP-4 entry to the README index table.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
README.md Adds QEP-4 to the registry index with Draft status and unversioned .
qeps/qep-0004-automation-registry-and-label-coordination.md Introduces the QEP-4 draft content, including founding registrations and tooling implications.
Comments suppressed due to low confidence (1)

qeps/qep-0004-automation-registry-and-label-coordination.md:105

  • This reference to QEP-2 uses the same non-existent qep-0002-standard-github-labels.md relative link, which will be broken when rendered. Update it to a valid target (e.g., the QEP-2 PR) to avoid dead links in the table.
| Family marker | `automated` | "was this made by a machine?" (org-wide union query) | Durable — every bot artifact ([QEP-2](qep-0002-standard-github-labels.md)) |

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread qeps/qep-0004-automation-registry-and-label-coordination.md
…er mirror)

The parity check that keeps the related frontmatter and the Related
header-table row in lockstep lands with the qep-0002 branch's check.mjs;
this branch carries the data it will validate once both merge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per the cross-QEP convention adopted in #9, QEP-2 holds no
forward references to this in-review QEP; the registry hooks it drafted
(Related pairing, origin/task-label policy, prune skip-rule, grey-band
registration) are preserved here verbatim and re-applied to QEP-2 by
this QEP's acceptance PR, in whatever form review settles. Rollout gains
the matching amend-QEP-2 step.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants