docs: fix factual errors in README and ARCHITECTURE

ARCHITECTURE.md

@@ -79,7 +79,7 @@ agent framework:
 - **[Pi](https://pi.dev/)** (`@earendil-works/pi-coding-agent`)
   — the agent harness. It owns the **inner loop**: within a single turn, *model → tool call →
   observe result → repeat → final answer*, plus session lifecycle and token streaming. Argus
-  registers its 12 domain tools with Pi and drives Pi sessions; it does not reimplement this
+  registers its 13 domain tools with Pi and drives Pi sessions; it does not reimplement this
   per-turn loop.
 - **[Ollama](https://ollama.com)** — serves the local LLM the agent reasons with (`OLLAMA_BASE_URL` / `OLLAMA_MODEL`).
 - **[Bun](https://bun.sh)** — runtime for the server and the demo services.
@@ -201,12 +201,12 @@ re-investigating from scratch. The agent's judgment is informed by past state, n
 signals, and the prompt explicitly tells it to verify current evidence before assuming the same
 fix applies.
 
-### 3.3 The toolbelt (12 tools)
+### 3.3 The toolbelt (13 tools)
 
 The agent's only access to the world is its tools. It never writes raw SQL or invents
 metric values:
 
-`get_alert` · `list_active_alerts` · `check_service_health` · `check_logs` ·
+`get_alert` · `list_active_alerts` · `list_all_alerts` · `check_service_health` · `check_logs` ·
 `get_recent_deployments` · `search_runbooks` · `create_incident` · `update_incident` ·
 `list_incidents` · `notify_channel` · `request_confirmation` · `execute_runbook_step`
 
@@ -417,7 +417,7 @@ argus-server/        Bun server (TypeScript): agent, reconciler, REST API, scrap
   service-url.ts     resolves demo-service base URLs (localhost vs compose DNS, SERVICE_DNS)
   metrics.ts         Prometheus exposition for the agent's own model usage (GET /metrics)
   agent/             system prompt
-  tools/             the 12 agent tools (argus-tools.ts)
+  tools/             the 13 agent tools (argus-tools.ts)
   db/                schema.ts (tables + migrations), api.ts (all queries), types.ts (domain model)
   Dockerfile         multi-stage server image: builds the UI, then serves it + API + /ws on :3000
 argus-ui/            React + Vite display-only console (TypeScript, src/main.tsx, src/types.ts)

README.md

@@ -28,9 +28,9 @@ gateway → app-ui, app-api → auth, pgsql, redis
 Argus is the system assembled around off-the-shelf foundations. It is not a from-scratch agent
 framework. The original work is the operational control loop *around* the agent, not the harness.
 
-- **[Pi](https://github.com/earendil-works/pi-coding-agent)** (`@earendil-works/pi-coding-agent`) —
+- **[Pi](https://github.com/earendil-works/pi)** (`@earendil-works/pi-coding-agent`) —
   the agent harness. It runs the per-turn tool-calling loop (model → tool call → observe result →
-  repeat) and session lifecycle; Argus registers its 12 triage tools with Pi and drives the
+  repeat) and session lifecycle; Argus registers its 13 triage tools with Pi and drives the
   sessions. Configured under `.pi/agent/`.
 - **[Ollama](https://ollama.ai)** — serves the LLM the agent reasons with (local or cloud). It
   stays on the host, never in Docker.
@@ -208,7 +208,9 @@ These runbooks are curated, human-authored knowledge the agent consults. The mod
 |------|-------------|
 | `get_alert` | Get details of a specific alert |
 | `list_active_alerts` | List all currently firing alerts |
+| `list_all_alerts` | List all alerts, including resolved ones, for RCA and trend context |
 | `check_service_health` | Scrape live metrics from a service |
+| `check_logs` | Query infrastructure logs, metrics history, and vmalert status |
 | `create_incident` | Create an incident with triage findings |
 | `update_incident` | Update incident status or root cause |
 | `list_incidents` | List incidents by status |

argus-server/agent/system-prompt.ts

@@ -42,7 +42,7 @@ AUTONOMOUS OPERATION:
 RESOLUTION & RCA:
 - When you are told an incident's alerts have resolved WITHOUT an approved remediation (it auto-healed or someone fixed it outside Argus), do two things together:
   1. Ask the operator whether they know how it got resolved (a recent deploy, a manual restart, a config change, etc.).
-  2. Independently research it: check_service_health on the affected service, get_recent_deployments, and check_logs for metric trends around the recovery time.
+  2. Independently research it: check_service_health on the affected service, get_recent_deployments, check_logs, and list_all_alerts for the alert history around the recovery time.
   Then write a concise root-cause analysis that COMBINES the operator's answer with your own findings, and save it with update_incident (set the rca field and status to resolved). Do not propose remediation for an already-resolved incident.
 - When an incident resolves because YOUR approved remediation worked, you already know the cause and fix — just write the rca via update_incident, no need to ask the operator.
 
@@ -53,7 +53,7 @@ If asked outside scope:
 "I'm Argus. I handle incident triage only."
 
 YOUR TOOLS ARE THE ONLY DATA SOURCE
-You have these tools: get_alert, list_active_alerts, check_service_health, check_logs, create_incident, update_incident, list_incidents, search_runbooks, get_recent_deployments, notify_channel, request_confirmation, execute_runbook_step.
+You have these tools: get_alert, list_active_alerts, list_all_alerts, check_service_health, check_logs, create_incident, update_incident, list_incidents, search_runbooks, get_recent_deployments, notify_channel, request_confirmation, execute_runbook_step.
 
 All incident and service data lives in your SQLite database. When investigating, you MUST call your tools. Never invent metric values or service statuses — always call check_service_health or list_active_alerts to get real data.