Dakotaraptor steini
Bluefin built on GNOME OS, assembled entirely from source.
Alpha — filing issues is the whole point.
Dakota doesn't eat tickets, it treats them as evidence.
Every user running Dakota is part of a structured loop that flows directly back into upstream GNOME, freedesktop, and the kernel. When something breaks on your hardware, you have three commands:
| Command | What it does |
|---|---|
ujust report |
Captures your system state and opens a pre-filled issue. One command instead of a wall of "please attach logs." |
ujust confirm <issue> |
Tells the team your hardware hits the same bug. Adds a hardware fingerprint to the issue — no duplicate filing. |
ujust verify <issue> |
After a fix ships in a nightly, confirms it works on your machine. Closes the loop with evidence. |
No telemetry. No phone-home. Every report is reviewed by you before it leaves your machine, lives in a gist you own, and can be deleted anytime.
When three users independently run ujust verify on a fix, that issue closes with real confidence — not just "we think this is fixed."
Each Dakota installation is designed to run as a hardware diagnostic lab for itself. When will you find your first?
Read the full feedback loop design
Dakota is human driven with contribution workflows for agents, so if you have tokens to donate, ask it to review issues or PRs, it's useful! The humans make the final decisions. We coordinate this project via a tool called Hive from Kubestellar, a CNCF Sandbox project.
Dakota's feedback loop model is grounded in Andy Anderson's work on autonomous AI-assisted software development. The core finding: the intelligence of a system like this lives not in any single model, but in the infrastructure of instructions, tests, metrics, and feedback loops surrounding it.
- The AI Codebase Maturity Model — the arxiv paper
- When AI agents become contributors — CNCF blog
- Beyond prompting: How KubeStellar reached 81% PR acceptance — The New Stack
- KubeStellar Hive — the reference implementation Dakota draws from
These issues need human judgment before any code is written — design review, domain knowledge, or hardware context the team doesn't have yet:
Leave a comment, push back on the design, or share how your hardware is affected. When a discussion reaches consensus, a maintainer marks it status/approved and it enters the contributor queue.
Ready to build something? See the agent-ready queue for issues with clear acceptance criteria and no open questions.
These issues need human judgment before any code is written — design review, domain knowledge, or hardware context the team doesn't have yet:
Leave a comment, push back on the design, or share how your hardware is affected. When a discussion reaches consensus, a maintainer marks it status/approved and it enters the contributor queue.
Ready to build something? See the agent-ready queue for issues with clear acceptance criteria and no open questions.
dakota-live-latest.iso · Checksum
- Installation path is still being worked on
- Upgrades and rollbacks need more hardening
See the open issues for where things stand.
See AGENTS.md for the full contributor workflow, build instructions, and PR checklist.
