A Kubernetes ops agent that answers with tools and evidence—not vibes.
Ask in natural language. The agent reasons, calls cluster tools for real evidence, forms hypotheses, and—when you need root cause—runs a forced evidence-adjudication chain so every conclusion is traceable.
| Layer | What it does |
|---|---|
| Always-on baseline | Observe → think → call tools → observe → answer. Grounded in live cluster data for “what’s installed?”, “how is this service configured?”, and similar questions. |
| Diagnostic specialty | On root-cause asks, escalate into a formal pipeline: hypothesis → tasks → Evidence → Verdict (must cite Evidence) → Report. No “I think it’s X” without a tool trail. |
| Multi-turn chat | Same session follow-ups; prior formal runs can be re-read by RunID for deeper explanation without inventing evidence. |
Tools go through a shared Registry / Dispatcher (shell-less kubectl backend, policy for auth). Model output never pretends to be Evidence.
Version 0.1.0 — askable diagnostic assistant (in progress). Milestone 0.1.0-beta7 (post-compaction range rehydrate) closed; 0.1.0-beta6 (deep follow-up by run) closed.
aruing run— single-shot diagnosis via linear Orchestratoraruing chat— multi-turn Session + Tower (LLM required); escalate when root cause is needed; successful escalate writesRunLedger; follow-ups injectprior_run_details(explain via reply by default); after compact, range rehydrate restores Store text intorehydrated_messageswhen needed
Details: docs/project-state.md.
Run → Query → Target → Hypothesis → Task → Evidence → Verdict → Report
- Run — one diagnosis unit
- Query / Node / Edge — unverified clues from the question
- Target — objects confirmed in the real cluster
- Hypothesis — candidate causes awaiting evidence
- Evidence — records from actual tool execution (only trusted fact source)
- Verdict — only from Evidence
- Report — cites Verdict + Evidence; does not invent
make build # build cmd/aruing
make test # all tests
make check # full CI (test-ci + vet + lint + fmt + tidy + vuln)
./bin/aruing run why is demo-api in default unreachable
./bin/aruing run --format json why is demo-api in default unreachable
./bin/aruing chat hello # multi-turn (LLM required; session id on stderr)
./bin/aruing chat --session sess_xxx check redis againRepo ignores .env. Copy the template; Make loads it:
cp .env.example .env # BaseURL / APIKey / Model
make print-env
make run-llm
make run-llm QUESTION='why is demo-api in default unreachable'
# make run-llm ENV_FILE=.env.ollamaAll three LLM vars set → real agent roles; any missing → fakes (same as no .env).
aruing chat / make chat require all three; no silent fake path.
make chat
make chat CHAT_MSG='hello'- Flat entities linked by
RunID—no nestedRun - Clues are not Targets until the environment confirms them
- Model output ≠ Evidence; Verdicts must cite Evidence
- No enumerating user ops / resource types; no artificial N-item amputations of normal capability (over budget → compact, don’t silently drop)
- Tools are not inherently R/O; policy gates execution. Read tools registered now; write tools later with approval
run→ Orchestrator;chat→ Session.Turn + Tower; same Dispatcher
Full list: docs/architecture.md (incl. #15–#18).
| Path | Content |
|---|---|
docs/architecture.md |
Architecture facts: modules, data model, trust boundary, hard constraints |
docs/project-state.md |
Stage, work units, next step |
docs/skills/ |
Project skills (comments, tests, docs) |
AGENTS.md |
AI tooling / skill install |
Longer design notes live in a private arui-note/aruing/ notebook (maintainer only).