Skip to content

feat(queen): XP for the lanes people lend, and a public leaderboard - #510

Merged
gHashTag merged 2 commits into
feat/queen-supervisorfrom
feat/queen-leaderboard
Sep 23, 2026
Merged

gHashTag merged 2 commits into
feat/queen-supervisorfrom
feat/queen-leaderboard

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

The owner, 2026-09-23: people who lend the swarm a provider token of their own should earn XP for it, and there should be a leaderboard.

The score is a reading, not a bookkeeping entry

XP is not a count of keys lent: a key added and never used carries nothing, and paying for the adding would pay for ten dead keys. Every bee runs on exactly one credential, and the dispatch already records which (key_index), how long it ran and what the review said. So:

  • 100 XP per issue the Queen accepted on that lane
  • 10 XP per hour a bee spent on it (a send-back earns its hours and nothing more)

Nothing is stored. The numbers are summed on every read from rows that already exist, so anyone can recompute them - a score nobody can check is a score nobody should trust.

Whose lane is whose

The credentials come from the operator's environment, so the mapping does too: TRIOS_KEY_OWNERS="0=Dmitrii,1=@alex". A lane nobody claimed shows as key #N rather than being dropped: the work is real, and the board must not imply the swarm ran on four keys when it ran on fourteen. No key is read here and none can be - only its index is in the database.

GET /queen/public-leaderboard is public on the same terms as /queen/public-board: no issue titles, no worker text, no credential. It takes ?days= (1-90, default 30).

Checks

  • 6 tests: the operator map (including what it refuses), an unclaimed lane, the score, gathering several lanes into one person, and the ranking's tie-breaks.
  • The query was run against the live database over 30 days: lane 0 at 176 accepted / 169 hours, lane 1 at 154 / 186, down to lanes that have never been chosen. It reads the archive as well as the live rows, because a retry overwrites its dispatch row.

Next, and not in this PR: letting a person add their own token from the app's profile page, so the lane is claimed by them rather than by an operator's variable.

🤖 Generated with Claude Code

Owner, 2026-09-23: people who lend the swarm a provider token of their own
should earn XP for it, and there should be a leaderboard.

XP is NOT a count of keys lent: a key added and never used carries nothing,
and paying for the adding would pay for ten dead keys. Every bee runs on one
credential and the dispatch records which (key_index), how long it ran and
what the review said, so the score is a reading of work that happened: 100 XP
per accepted issue on that lane, 10 XP per hour a bee spent on it. Nothing is
stored - the numbers are summed from rows that already exist on every read,
so anyone can recompute them.

Whose lane is which comes from the operator's environment, because the
credentials do: TRIOS_KEY_OWNERS="0=Dmitrii,1=@alex". A lane nobody claimed
shows as "key #N" rather than being dropped: the work is real, and the board
must not imply the swarm ran on four keys when it ran on fourteen. No key is
read here and none can be - only its index is in the database.

GET /queen/public-leaderboard is public on the same terms as the board: no
titles, no worker text, no credential.

Measured against the live database over 30 days: lane 0 at 176 accepted and
169 hours, lane 1 at 154 and 186, down to lanes never chosen. Tests: 6.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Sep 23, 2026 •

Copy link
Copy Markdown

✅ Tests passed — 2400/2460

Suite Passed Failed Skipped
✅ agent 87/87 0 0
✅ build 9/9 0 0
✅ cdp-protocol 5/5 0 0
✅ eval 93/93 0 0
✅ server-agent 272/272 0 0
✅ server-api 1279/1338 0 59
✅ server-browser 6/6 0 0
✅ server-integration 10/11 0 1
✅ server-lib 279/279 0 0
✅ server-pglive 3/3 0 0
✅ server-root 68/68 0 0
✅ server-skills 31/31 0 0
✅ server-tools 244/244 0 0
✅ shared 14/14 0 0

View workflow run

The route-guard gate pins the shape of the route table, and its own note says
why: a pinned count is a restated list, and it goes stale either because
something was added on purpose or because a hole opened -- the pin cannot tell
them apart, so whoever updates it has to look.

Looked. The audit moves by exactly one mount, `/queen/public-leaderboard`,
classified `public-read` via an explicit `publicReadCorsMiddleware()` -- which
is where a route with `public` in its name belongs. prefixGuardCount stays 18
and guardedSubAppCount stays 15: no guarded route lost its guard to make room.

  totalMounts     44 -> 45
  publicReadCount  7 -> 8
  /queen mounts   21 -> 22 (public-read 7 -> 8; wrapper 8 and shells 6 as before)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag
gHashTag merged commit fee103d into feat/queen-supervisor Sep 23, 2026
15 of 16 checks passed
@github-actions
github-actions Bot deleted the feat/queen-leaderboard branch September 27, 2026 04:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant