Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
14 changes: 9 additions & 5 deletions .agents/skills/beekeeper-suit/PAIRING-AUDIT.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,16 +4,20 @@ Ground truth pulled from the filesystem on 2026-08-14, after the repair pass. Th

## Totals

- Bees (`.claude/agents/*.md`): **75**
- Stinger folders (`.claude/skills/*`): **78**
- Bees (`.claude/agents/*.md`): **76**
- Stinger folders (`.claude/skills/*`): **79**
- Orchestrator-level skills with no paired Bee by design: **3** (`beekeeper-suit`, `queen-bee-stinger`, `get-started-stinger`)
- Pairable Stingers: **75**
- Pairable Stingers: **76**

## Pairing integrity

Clean. Every Bee has a matching Stinger and every pairable Stinger has a matching Bee, verified in both directions by naming convention. Zero orphans.

Every Bee also has a routing guide at `guides/<bee-name>.md`. 75 Bees, 75 guides, one-to-one.
Every Bee also has a routing guide at `guides/<bee-name>.md`. 76 Bees, 76 guides, one-to-one.

## New additions

`rust-worker-bee` / `rust-stinger` was ported in from a prior fork and registered here: Rust implementation and code review for Cargo workspaces, Tokio/Axum/Tower services, SQLx/SQLite state, Clap/Ratatui clients, tests, and local packaging evidence.

## Path integrity

Expand Down Expand Up @@ -41,7 +45,7 @@ All routing references to the renamed `deeplake-dataset-worker-bee` were repaire

## Validation

All 78 Stingers pass `per-type-validation.py --type skill --harness all` with zero errors. All 75 Bees pass `--type agent --harness claude-code` with zero errors. Remaining warnings are repo-wide patterns, not defects: descriptions above Cowork's 200 character soft cap on some legacy skills, and the `proactive` frontmatter field, which every Bee in this colony uses.
All 79 Stingers pass `per-type-validation.py --type skill --harness all` with zero errors. All 76 Bees pass `--type agent --harness claude-code` with zero errors. Remaining warnings are repo-wide patterns, not defects: descriptions above Cowork's 200 character soft cap on some legacy skills, and the `proactive` frontmatter field, which every Bee in this colony uses.

## Dead reference repair

Expand Down
5 changes: 3 additions & 2 deletions .agents/skills/beekeeper-suit/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Three skills sit above the pairing law because they are orchestrator level, not

## Roster

75 Bees registered, sorted into domain groups. The Domain column is a one-line summary of the Bee's own frontmatter description. Trigger keywords are pulled from that same description, not invented.
76 Bees registered, sorted into domain groups. The Domain column is a one-line summary of the Bee's own frontmatter description. Trigger keywords are pulled from that same description, not invented.

### Stack and frameworks

Expand All @@ -42,6 +42,7 @@ Three skills sit above the pairing law because they are orchestrator level, not
| `react-worker-bee` | React 18/19 architecture: bulletproof-react patterns, Server Components, Suspense, Actions, Compiler, state layering | "review React architecture", "state management decision", "Server Components boundary", "React 19 patterns" | `react-stinger` |
| `typescript-node-worker-bee` | TypeScript/Node code review and conventions: strict config, module resolution, test suites, boundary validation (body still cites a legacy package's specifics; see PAIRING-AUDIT.md) | "review this TypeScript code", "audit this Node code", "write a Vitest suite", "tighten the tsconfig" | `typescript-node-stinger` |
| `python-worker-bee` | Python architecture: Django + Django Ninja + FastAPI + Celery + Channels + pytest + uv, ORM discipline, migrations, typed adoption | "review this Django code", "audit ORM patterns", "migrate DRF to Django Ninja", "set up Celery" | `python-stinger` |
| `rust-worker-bee` | Rust implementation and code review for production Cargo workspaces, Tokio/Axum/Tower services, SQLx/SQLite state, Clap/Ratatui clients, Rust tests, and local packaging evidence | "implement this in Rust", "review this Cargo workspace", "fix this Tokio or SQLx service", "audit this SQLx transaction", "build the approved Rust PRD slice" | `rust-stinger` |
| `ux-ui-svelte-worker-bee` | Enforces this repo's SvelteKit UI standard: shadcn-svelte on Bits UI plus Melt UI, Tailwind v4 token bridge, white-label brand contract | "add a Button", "copy in this shadcn-svelte component", "convert this bespoke style to Tailwind", "does the white-label still work" | `ux-ui-svelte-stinger` |
| `dark-mode-theming-worker-bee` | Dark-mode theming: CSS variable token architecture, theme-provider wiring, FOWT prevention, SSR hydration safety, Tailwind v4 dark variant | "set up dark mode", "dark mode on SSR", "multi-brand theming", "FOWT fix" | `dark-mode-theming-stinger` |
| `modal-toast-dialog-worker-bee` | Accessible overlay primitives: dialog, alert dialog, drawer, toast, command menu; focus trap, escape, scroll lock, aria contract | "choosing between overlay primitives", "debugging focus trap regressions", "building a command palette" | `modal-toast-dialog-stinger` |
Expand Down Expand Up @@ -251,7 +252,7 @@ Don't hand-roll a new Bee. Walk [`../queen-bee-stinger/guides/beekeeper-registra

---

**75 Bees registered.** Every Bee has a spawnable agent in `.claude/agents/` and a paired Stinger in `../`. See [`PAIRING-AUDIT.md`](./PAIRING-AUDIT.md) for the full pairing audit, including the handful of Bees whose body content still needs a rewrite pass to match this repo's actual stack.
**76 Bees registered.** Every Bee has a spawnable agent in `.claude/agents/` and a paired Stinger in `../`. See [`PAIRING-AUDIT.md`](./PAIRING-AUDIT.md) for the full pairing audit, including the handful of Bees whose body content still needs a rewrite pass to match this repo's actual stack.

---

Expand Down
52 changes: 52 additions & 0 deletions .agents/skills/beekeeper-suit/guides/rust-worker-bee.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# rust-worker-bee

## Domain
This Bee owns bounded implementation and code review for production Rust systems. It handles Cargo workspace and crate changes, Tokio/Axum/Tower runtime behavior, SQLx/SQLite persistence mechanics, Clap/Ratatui operator clients, Rust tests, and local packaging evidence against approved contracts. It preserves the exact PRD, ADR, ledger, repository instructions, gates, and concurrent-work boundaries. It does not invent protocol or product policy, accept security risk, decide dependency or release policy, issue final Quality acceptance, or authorize external effects.

## Paired Stinger
[rust-stinger](../../rust-stinger) - the authority reconstruction, workspace inspection, bounded-slice implementation, async/persistence proof, adapter, CLI/TUI, verification, and close-the-loop procedures plus the acceptance, handoff, release-evidence, and decision-log templates.

## Trigger phrases
- "Implement this in Rust."
- "Review this Cargo workspace."
- "Fix this Tokio or SQLx service."
- "Audit this SQLx transaction."
- "Build the approved Rust PRD slice."

Also route proactively when a requested change or review touches Rust source, Cargo manifests or workspaces, Tokio/Axum/Tower services, SQLx/SQLite state, Clap/Ratatui clients, Rust tests, or local Rust packaging evidence.

## Do NOT route when
- The ask is HTTP/REST or MCP semantic and compatibility decisions: that is `http-rest-fundamentals-worker-bee` or `mcp-protocol-worker-bee`; Rust implements their approved contracts.
- The ask is product, model, and provider policy: that is `ai-tools-platform-worker-bee` or the named product owner.
- The ask is schema architecture: that is `db-worker-bee`; this Bee owns approved SQLx/SQLite mechanics and proof.
- The ask is Security acceptance: that is `security-worker-bee`.
- The ask is dependency/license/advisory disposition: that is `dependency-audit-worker-bee`.
- The ask is final implementation-to-PRD acceptance: that is `quality-worker-bee`.
- The ask is CI/CD topology, signing, publication, or release operations: that is the appropriate DevOps or release specialist; do not use this Bee for unauthorized live credentials, paid traffic, publishing, or global installation.

If a request straddles two Bees' domains, let the policy or protocol owner approve the contract first, then route the bounded Rust implementation to `rust-worker-bee`.

## Inputs the Bee needs
- The exact repository or worktree, owned paths, branch/change boundary, and concurrent-work constraints.
- The authorizing PRD, ADR, ledger rows, acceptance criteria, gates, and repository instructions.
- The current Cargo graph, Rust source, features and targets, migrations, tests, and release configuration.
- Approved protocol, provider, persistence, security, CLI, platform, and operational contracts, including data-integrity and cancellation requirements.
- The required verification commands and explicit authorization for any external effect.

If a missing input controls safety, public compatibility, money, credentials, signing, publication, or destructive behavior, invoke only to record the fail-closed blocker and smallest safe checkpoint; do not ask the Bee to guess.

## Outputs
- Rust/Cargo changes in the explicitly owned workspace, with focused tests and local implementation or packaging evidence required by the accepted slice.
- An acceptance-linked Rust implementation handoff using `templates/implementation-handoff.md`, including changed paths, exact verification commands and results, safety evidence, rollback/recovery notes, and remaining gates.
- When release evidence is explicitly in scope, a populated local `templates/release-evidence-manifest.yaml`; signing and publication remain closed unless separately authorized.
- A precise blocker record instead of a completion claim when an owning decision, tool, gate, or required proof is missing.

## Commonly sequenced with
- Plan execution loop: `rust-worker-bee` is the implementation Bee for Rust/Cargo work; it hands the final implemented state to `security-worker-bee`, reruns affected checks after security fixes, and only then hands it to `quality-worker-bee`.
- Schema-touching work: `db-worker-bee` owns schema architecture first; `rust-worker-bee` implements approved SQLx/SQLite mechanics and proof; Security and Quality close out in their mandatory order.
- Protocol or provider work: the HTTP/MCP/platform owner establishes the contract or policy; `rust-worker-bee` implements the bounded adapter; Security and Quality close out afterward.

## Critical directives the orchestrator should respect
- Never start blocked or deferred work: the named PRD, ADR, ledger, repository instructions, and gate state are authority.
- Keep harness agency and external effects fail-closed while requiring provable bounded concurrency, cancellation/replay behavior, transactions, crash recovery, redaction, and a default of no `unsafe`; no live credentials, paid traffic, global installation, signing, publication, or auto-update execution without explicit authorization.
- Preserve the verification order: implementation checks, Security, affected-check reruns, then Quality; partial or stale evidence is not shipped evidence.
16 changes: 16 additions & 0 deletions .agents/skills/rust-stinger/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Rust Stinger

Rust Stinger equips `rust-worker-bee` to implement and review production Cargo workspaces, async services, durable local state, operator surfaces, tests, and release evidence. It operationalizes the approved Command Brief while preserving protocol, Security, dependency, release, and Quality peer ownership. Its technical rules are traceable to [`research/research-summary.md`](research/research-summary.md) and the underlying primary-source notes.

## Layout

- `SKILL.md` — trigger, procedure, directives, outputs, and decision boundaries.
- `guides/` — numbered procedures matching every Command Brief action.
- `examples/` — worked happy-path and failure-boundary handoffs.
- `templates/` — reusable implementation, decision, and release-evidence stubs.
- `reports/` — report-shape template and future run archive.
- `research/` — immutable scripture-historian evidence packet.

## Maintenance

Update the research packet before changing version-sensitive guidance. The current packet marks Rust/Cargo, Tokio, SQLx, rustls, cargo-dist, platform support, and RustSec as explicit revalidation points; current-at-retrieval values are evidence snapshots, not defaults.
83 changes: 83 additions & 0 deletions .agents/skills/rust-stinger/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
---
name: "rust-stinger"
description: "Implements and reviews production Rust systems across Cargo workspaces, Tokio/Axum/Tower services, SQLx/SQLite state, Clap/Ratatui operator surfaces, tests, and release evidence. Use when the user says \"implement this in Rust\", \"review this Cargo workspace\", \"fix this Tokio or SQLx service\", or invokes rust-worker-bee. Do not use it to invent protocol semantics, approve security or dependency policy, author the final Quality report, or publish a release."
license: MIT
---

# Rust Stinger

Equip `rust-worker-bee` to own bounded Rust implementation while preserving the authority of the exact PRD, ADR, ledger, and peer specialists. Make async ownership, durability, state transitions, redaction, and release evidence mechanically reviewable. Stop at a recorded fail-closed boundary whenever a missing decision affects safety, compatibility, money, credentials, signing, publication, or another external effect.

## Required inputs

Before editing, obtain:

- the exact repository or worktree, owned paths, and concurrent-work boundaries;
- the authorizing PRD/ADR/ledger rows, acceptance criteria, gates, and repository instructions;
- the existing Cargo graph, toolchain files, feature/target matrix, migrations, code, tests, and release configuration;
- approved protocol, provider, persistence, security, CLI, platform, and operational contracts;
- the required verification commands and explicit authorization for any external effect.

If a missing input determines safety, public compatibility, monetary behavior, credentials, publication, or destructive behavior, return a blocker rather than choosing silently.

## Procedure

1. Reconstruct authority, scope, gate state, and worktree ownership using `guides/00-authority-and-principles.md`.
2. Inventory the Rust system and record revalidation points using `guides/01-inspect-workspace.md`.
3. Establish the smallest coherent crate, feature, type, and error design using `guides/02-design-workspace-and-types.md`.
4. Implement a test-first acceptance slice using `guides/03-implement-bounded-slices.md`.
5. Prove task, cancellation, stream, backpressure, timeout, retry, and shutdown behavior using `guides/04-prove-async-streams.md`.
6. Prove SQLite/SQLx transactions, migrations, crash recovery, and typed state transitions using `guides/05-prove-persistence-and-state.md`.
7. Implement provider and harness edges only behind approved contracts using `guides/06-implement-adapters.md`.
8. Build scriptable CLI and optional TUI surfaces using `guides/07-build-cli-and-tui.md`.
9. Run the complete owned verification and generate release evidence without publishing using `guides/08-verify-and-package-evidence.md`.
10. Produce the acceptance-linked handoff, route Security before Quality, and leave unresolved gates explicit using `guides/09-close-the-loop.md`.

## Critical directives

- Treat the named PRD, ADR, ledger, gate state, and repository instructions as authority. Never start blocked or deferred work.
- Keep provider code subordinate to the host harness: it may route inference but never acquire tools, approvals, repository access, memory, or user interaction.
- Default to bounded queues, explicit task owners, operation-level cancellation review, and no transparent replay after visible output or a harness-visible tool call.
- Put monetary/quota checks, reservations, reconciliation, idempotency, and aggregate updates in explicit transactions with concurrency and crash evidence.
- Keep credentials in approved secret references and start sensitive instrumentation with `skip_all`; allowlist only non-sensitive correlation and state fields.
- Keep prompts, generated code, raw headers/tokens, and unsalted account identifiers out of default logs, crashes, state, metrics, diagnostics, and support exports. Enforce approved egress allowlists and never bypass redirect, DNS, or SSRF checks.
- Default to no `unsafe`. Any exception needs a minimal scope, written invariant, targeted tests, and independent review.
- Use fake providers and fixtures by default. Do not use live credentials, paid traffic, subscriptions, signing identities, publishing, auto-update, Git initialization, or destructive controls without explicit authorization.
- Never promote retrieval-time crate/tool versions, OS targets, durability settings, timeout values, signing systems, or soak thresholds into timeless defaults. Revalidate them at the decision point.
- Preserve peer authority: protocol semantics, product/provider policy, security acceptance, schema review, dependency/license disposition, CI topology, signing/publication, and final PRD Quality remain separate handoffs.
- Preserve verification order: implementation checks, Security, affected-check reruns, then Quality. Partial or stale evidence is not shipped evidence.

See `guides/00-authority-and-principles.md` for the rationale and fail-closed decision table.

## Output contract

Produce a Rust implementation handoff from `templates/implementation-handoff.md`, backed by exact commands and artifacts. When release work is in scope, also populate `templates/release-evidence-manifest.yaml` without signing or publishing unless independently authorized. Past execution reports belong in `reports/`; see `reports/README.md`.

## Examples

- `examples/01-happy-path-bounded-service-slice.md` — Cargo/Axum/SQLx acceptance slice with deterministic evidence.
- `examples/02-edge-visible-output-cancellation.md` — cancellation after visible output, where replay must remain disabled.
- `examples/03-edge-concurrent-budget-reservation.md` — concurrent SQLite reservation and crash boundary.
- `examples/04-release-evidence-with-closed-gates.md` — package evidence generation with signing/publication held closed.

## Research and refresh points

Read `research/research-summary.md` and `research/evidence-synthesis.md` before making architecture or version-sensitive claims. Use `research/index.md` to locate primary notes. Re-fetch the Rust release/platform matrix, Tokio support policy, the selected SQLx transaction API, stable rustls APIs, cargo-dist behavior, and RustSec data at the point of use; the research packet records a 2026-07-24 snapshot, not permanent defaults.

## Human decisions that remain open

Do not resolve these from the Stinger alone:

- supported OS/architecture/install matrix and minimum OS baselines;
- actual MSRV after the resolved graph and public features exist;
- SQLite power-loss durability and contended-writer behavior;
- durable replay/promotion event schema;
- first-milestone TUI scope;
- signing identity, attestation platform, installer formats, and publication authorization;
- quantitative soak pass/fail thresholds.

Record the missing owner/decision, affected acceptance criteria, and first authorized next action in the handoff.

## Paired owner

This Stinger is paired with `rust-worker-bee`.
Loading