Skip to content

queen: a task priority the Queen can apply (specs/queen/priority.t27 + tri queue) #6366

Description

@gHashTag

Problem

The Queen (trios supervisor, gHashTag/BrowserOS trios/agent-server) picks the first eligible open issue in GitHub's listing order (newest first). openIssues drops labels before the choice, so P0, priority/critical, priority/high, high-priority, priority/medium, priority/low change nothing (specs/queen/dispatch.t27, PRIORITY_RULE). specs/queen/task_analysis.t27 states an order no runtime applies.

Goal

One spec owns the priority rule; runtimes read it, nobody restates it.

Scope

  • specs/queen/priority.t27: label vocabulary per level as str consts; effective level with aging for labelled issues only (no labels = today's order, unchanged); an open blocker makes an issue ineligible; at most 3 critical per listing (extras count as high); stable tie-break by listing order; a why code; tests.
  • tri queue: read-only report of the Queen's present order vs the priority order, one why per issue, decisions through gen-c + ctypes.
  • Not here: the BrowserOS change (separate PR there, left for the owner), labelling issues.

Acceptance

  • t27c suite green for the new spec; tri queue runs against gHashTag/t27 and prints both orders.

Refs #6063

No activity

Activity on this issue will appear here.

Activity

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions