the-steward 0.1.0__tar.gz

the_steward-0.1.0/LICENSE

@@ -0,0 +1,50 @@
+The Steward — Evaluation License
+Copyright (c) 2026 Henry Declety. All rights reserved.
+
+1. DEFINITIONS
+   "Software" means The Steward — this package and all accompanying code, scripts, agents, and
+   documentation. "You" means the individual or entity granted access under this license.
+
+2. GRANT (LIMITED, EVALUATION-ONLY)
+   Subject to your compliance with this license, Henry Declety grants You a personal, non-exclusive,
+   non-transferable, non-sublicensable, revocable license to install and run the Software on machines
+   You control, solely to evaluate it for Your own internal use. No other rights are granted.
+
+3. RESTRICTIONS
+   You may NOT, in whole or in part: (a) redistribute, publish, sublicense, sell, rent, or otherwise
+   make the Software available to any third party; (b) fork, mirror, or create derivative works for
+   distribution; (c) use the Software to provide a service to third parties or for any commercial
+   purpose; (d) remove or alter any proprietary notices; (e) reverse-engineer except to the extent that
+   restriction is prohibited by applicable law.
+
+4. OWNERSHIP
+   The Software is licensed, not sold. Henry Declety retains all right, title, and interest in and to the
+   Software, including all intellectual property rights. Any feedback or contributions You provide may
+   be used by Henry Declety without restriction or obligation, and You assign to Henry Declety all rights
+   in any such contributions.
+
+5. THIRD-PARTY / RUNTIME SERVICES
+   The Software routes inference through inferroute (the "ir" economy lane); Your use of that service is
+   governed by its own terms. The Software is not a license to any inferroute service or credits.
+
+6. TERM & TERMINATION
+   This license is effective until terminated. It terminates automatically if You breach any term, and
+   Henry Declety may revoke it at any time. On termination You must stop using and delete all copies of
+   the Software.
+
+7. NO WARRANTY
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+   LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.
+
+8. LIMITATION OF LIABILITY
+   IN NO EVENT SHALL Henry Declety BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY (INCLUDING
+   DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR LOSS OF DATA OR PROFITS) ARISING FROM OR IN
+   CONNECTION WITH THE SOFTWARE OR ITS USE. The Software runs autonomously and may modify files in
+   repositories You point it at; You are responsible for the repositories and machines You authorize it
+   to act on.
+
+9. GOVERNING LAW
+   This Agreement is governed by and construed in accordance with the laws of France, without regard to
+   its conflict-of-laws rules. The courts of Paris, France shall have exclusive jurisdiction over any
+   dispute arising out of or relating to this Agreement or the Software, subject to any mandatory
+   provisions of law that apply to a consumer in their country of residence.

the_steward-0.1.0/PKG-INFO

@@ -0,0 +1,133 @@
+Metadata-Version: 2.4
+Name: the-steward
+Version: 0.1.0
+Summary: The Steward — a continuously-watching guardian that spends intelligence only on novelty, investigates it to a decision-ready conclusion, verifies against reality over time, and surfaces exactly what a human or an agent needs. The flagship inferroute application.
+License: The Steward — Evaluation License
+        Copyright (c) 2026 Henry Declety. All rights reserved.
+        
+        1. DEFINITIONS
+           "Software" means The Steward — this package and all accompanying code, scripts, agents, and
+           documentation. "You" means the individual or entity granted access under this license.
+        
+        2. GRANT (LIMITED, EVALUATION-ONLY)
+           Subject to your compliance with this license, Henry Declety grants You a personal, non-exclusive,
+           non-transferable, non-sublicensable, revocable license to install and run the Software on machines
+           You control, solely to evaluate it for Your own internal use. No other rights are granted.
+        
+        3. RESTRICTIONS
+           You may NOT, in whole or in part: (a) redistribute, publish, sublicense, sell, rent, or otherwise
+           make the Software available to any third party; (b) fork, mirror, or create derivative works for
+           distribution; (c) use the Software to provide a service to third parties or for any commercial
+           purpose; (d) remove or alter any proprietary notices; (e) reverse-engineer except to the extent that
+           restriction is prohibited by applicable law.
+        
+        4. OWNERSHIP
+           The Software is licensed, not sold. Henry Declety retains all right, title, and interest in and to the
+           Software, including all intellectual property rights. Any feedback or contributions You provide may
+           be used by Henry Declety without restriction or obligation, and You assign to Henry Declety all rights
+           in any such contributions.
+        
+        5. THIRD-PARTY / RUNTIME SERVICES
+           The Software routes inference through inferroute (the "ir" economy lane); Your use of that service is
+           governed by its own terms. The Software is not a license to any inferroute service or credits.
+        
+        6. TERM & TERMINATION
+           This license is effective until terminated. It terminates automatically if You breach any term, and
+           Henry Declety may revoke it at any time. On termination You must stop using and delete all copies of
+           the Software.
+        
+        7. NO WARRANTY
+           THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+           LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.
+        
+        8. LIMITATION OF LIABILITY
+           IN NO EVENT SHALL Henry Declety BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY (INCLUDING
+           DIRECT, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR LOSS OF DATA OR PROFITS) ARISING FROM OR IN
+           CONNECTION WITH THE SOFTWARE OR ITS USE. The Software runs autonomously and may modify files in
+           repositories You point it at; You are responsible for the repositories and machines You authorize it
+           to act on.
+        
+        9. GOVERNING LAW
+           This Agreement is governed by and construed in accordance with the laws of France, without regard to
+           its conflict-of-laws rules. The courts of Paris, France shall have exclusive jurisdiction over any
+           dispute arising out of or relating to this Agreement or the Software, subject to any mandatory
+           provisions of law that apply to a consumer in their country of residence.
+        
+Classifier: License :: Other/Proprietary License
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Dynamic: license-file
+
+# The Steward
+
+**A guardian that watches your repos overnight, spends intelligence only on what's new, investigates
+it to a decision, and hands you a short morning brief — not a firehose.**
+
+The Steward sits beside your projects. Most of the time it does nothing but watch (cheap, local, no
+inference). When something genuinely changes — a new error in your logs, a risky commit, a regression —
+it spins up an isolated worktree, investigates with an LLM, verifies the finding against reality, and
+either fixes it on a branch or writes it up. In the morning you read one digest.
+
+> **Status: early access for friends.** Linux (and WSL2) today; macOS scheduling is in progress.
+> Install with `pipx install the-steward`. See [INSTALL](#install).
+
+## What it does
+- **Watches** your tracked git repos + their logs locally, on a timer. No inference until something is new.
+- **Investigates** novelty in a throwaway git worktree — never your working tree, never your branches.
+- **Verifies** findings against the real repo (it won't surface a fix for a file that doesn't exist).
+- **Scrubs** secrets out of anything before it leaves your machine for the model.
+- **Briefs** you each morning — read it in the **dashboard** (`localhost:5057`) or `steward review`.
+
+## Requirements
+- Linux with `systemd --user` (or WSL2 with systemd enabled). *macOS isn't supported yet — `steward init`
+  will stop with that message.*
+- Python ≥ 3.10, `git`, `tmux`, and `bash`.
+- **Claude Code** — the `claude` CLI is the agent harness the Steward drives to investigate; `steward init`
+  hard-checks for it. Install: https://claude.com/code
+- An **inferroute** account for the **economy lane** (the recommended way to run — cheap, always-on
+  compute that keeps the overnight watch affordable):
+  1. `pipx install 'inferroute>=0.3.28'`  *(0.3.28+ required — it honors the Steward's write-scoping)*
+  2. Sign up at **https://inferroute.ai** — early-access friends start with a small **$5 credit
+     headstart** on their own account; top up with your own credits once you've kicked the tires.
+  3. `ir login` (paste your key) — or `ir setup` for the guided first-run.
+
+  *Escape hatch:* you can instead bring your own Anthropic/Claude key (`ir anthropic` / BYO), but the
+  economy lane is what makes always-on watching cheap, so it's the default.
+
+## Install
+The package is on PyPI (proprietary, licensed for evaluation — see [License](#license)):
+```bash
+pipx install the-steward      # or: pip install the-steward  into a venv
+steward init                  # preflight + economy on-ramp + your local dashboard
+```
+Update any time with `pipx upgrade the-steward`.
+`steward init` runs a preflight (checks your tools + that your inferroute economy login is funded, with
+the exact fix for anything missing), then installs your **local dashboard** and points you to it.
+
+**Pick your projects in the dashboard** — `http://localhost:5057` — where you discover repos, see each
+one's fit (evaluated for you), and start watching the ones you want. That's the main way to drive it.
+```bash
+steward review            # the morning digest (auto-runs each morning; run any time)
+steward status <repo>     # a repo's health from the terminal
+# headless / no browser? pick from the terminal instead:
+steward discover          # list watchable repos
+steward track <repo>      # watch one   ·   steward untrack <repo> to stop   ·   steward onboard for a TUI
+```
+
+## Privacy
+- The watch loop is **fully local** — zero inference, zero egress.
+- When an investigation runs, context is **scrubbed of secrets** before it reaches the model.
+- **Fleet telemetry** (run/turn metadata to improve the tuning loops) is configurable:
+  `steward` shows the setting at setup; turn it off to ship nothing. *(See [INSTALL](#install) for the
+  current default and exactly what's sent.)*
+
+## What it is NOT (yet)
+- Not open source — it's on PyPI, but under a proprietary **evaluation** license: run it on your own
+  machines, but don't redistribute, fork, or use it commercially.
+- Not an OS-level sandbox — point it at your own repos, not untrusted code. Agents run in throwaway
+  worktrees, but a misbehaving agent with shell access could still read files in your home dir.
+
+## License
+Proprietary — © 2026 Henry Declety. Licensed to early-access users for **evaluation only**: you may run it
+on your own machines, but not redistribute, fork, or use it commercially. See [LICENSE](LICENSE).

the_steward-0.1.0/README.md

@@ -0,0 +1,72 @@
+# The Steward
+
+**A guardian that watches your repos overnight, spends intelligence only on what's new, investigates
+it to a decision, and hands you a short morning brief — not a firehose.**
+
+The Steward sits beside your projects. Most of the time it does nothing but watch (cheap, local, no
+inference). When something genuinely changes — a new error in your logs, a risky commit, a regression —
+it spins up an isolated worktree, investigates with an LLM, verifies the finding against reality, and
+either fixes it on a branch or writes it up. In the morning you read one digest.
+
+> **Status: early access for friends.** Linux (and WSL2) today; macOS scheduling is in progress.
+> Install with `pipx install the-steward`. See [INSTALL](#install).
+
+## What it does
+- **Watches** your tracked git repos + their logs locally, on a timer. No inference until something is new.
+- **Investigates** novelty in a throwaway git worktree — never your working tree, never your branches.
+- **Verifies** findings against the real repo (it won't surface a fix for a file that doesn't exist).
+- **Scrubs** secrets out of anything before it leaves your machine for the model.
+- **Briefs** you each morning — read it in the **dashboard** (`localhost:5057`) or `steward review`.
+
+## Requirements
+- Linux with `systemd --user` (or WSL2 with systemd enabled). *macOS isn't supported yet — `steward init`
+  will stop with that message.*
+- Python ≥ 3.10, `git`, `tmux`, and `bash`.
+- **Claude Code** — the `claude` CLI is the agent harness the Steward drives to investigate; `steward init`
+  hard-checks for it. Install: https://claude.com/code
+- An **inferroute** account for the **economy lane** (the recommended way to run — cheap, always-on
+  compute that keeps the overnight watch affordable):
+  1. `pipx install 'inferroute>=0.3.28'`  *(0.3.28+ required — it honors the Steward's write-scoping)*
+  2. Sign up at **https://inferroute.ai** — early-access friends start with a small **$5 credit
+     headstart** on their own account; top up with your own credits once you've kicked the tires.
+  3. `ir login` (paste your key) — or `ir setup` for the guided first-run.
+
+  *Escape hatch:* you can instead bring your own Anthropic/Claude key (`ir anthropic` / BYO), but the
+  economy lane is what makes always-on watching cheap, so it's the default.
+
+## Install
+The package is on PyPI (proprietary, licensed for evaluation — see [License](#license)):
+```bash
+pipx install the-steward      # or: pip install the-steward  into a venv
+steward init                  # preflight + economy on-ramp + your local dashboard
+```
+Update any time with `pipx upgrade the-steward`.
+`steward init` runs a preflight (checks your tools + that your inferroute economy login is funded, with
+the exact fix for anything missing), then installs your **local dashboard** and points you to it.
+
+**Pick your projects in the dashboard** — `http://localhost:5057` — where you discover repos, see each
+one's fit (evaluated for you), and start watching the ones you want. That's the main way to drive it.
+```bash
+steward review            # the morning digest (auto-runs each morning; run any time)
+steward status <repo>     # a repo's health from the terminal
+# headless / no browser? pick from the terminal instead:
+steward discover          # list watchable repos
+steward track <repo>      # watch one   ·   steward untrack <repo> to stop   ·   steward onboard for a TUI
+```
+
+## Privacy
+- The watch loop is **fully local** — zero inference, zero egress.
+- When an investigation runs, context is **scrubbed of secrets** before it reaches the model.
+- **Fleet telemetry** (run/turn metadata to improve the tuning loops) is configurable:
+  `steward` shows the setting at setup; turn it off to ship nothing. *(See [INSTALL](#install) for the
+  current default and exactly what's sent.)*
+
+## What it is NOT (yet)
+- Not open source — it's on PyPI, but under a proprietary **evaluation** license: run it on your own
+  machines, but don't redistribute, fork, or use it commercially.
+- Not an OS-level sandbox — point it at your own repos, not untrusted code. Agents run in throwaway
+  worktrees, but a misbehaving agent with shell access could still read files in your home dir.
+
+## License
+Proprietary — © 2026 Henry Declety. Licensed to early-access users for **evaluation only**: you may run it
+on your own machines, but not redistribute, fork, or use it commercially. See [LICENSE](LICENSE).

the_steward-0.1.0/inferroute_steward/__init__.py

@@ -0,0 +1 @@
+"""The Steward — packaged runtime (orchestrator + tools + agents + CLI)."""

the_steward-0.1.0/inferroute_steward/agents/bench/agent.md

@@ -0,0 +1,17 @@
+# The Steward — Benchmark Investigator
+
+You are investigating a real operational question about THIS machine's services, using its logs.
+Work efficiently and honestly: find the actual answer in the logs (and the repo's source if helpful),
+don't speculate. If the logs don't support a conclusion, say so.
+
+Depending on your toolset you may have:
+- **get-logs MCP tools** (`getlogs_summary` / `getlogs_query` / `getlogs_count` / `getlogs_capabilities`)
+  — a deduped, severity-classified view of the services' logs. Summary first, then drill down. OR
+- **a shell** — use `journalctl --user -u '<unit-glob>'` (mind output size; the journals are large),
+  `grep`, and the repo source.
+
+Rules:
+- Read-only investigation: do NOT modify anything (no writes, no service restarts).
+- Ground every claim in a specific log line or source line you actually saw.
+- Be token-conscious: don't dump megabytes; narrow queries beat broad ones.
+- Your FINAL message must end with ONLY the JSON object the task asks for — no prose after it.

the_steward-0.1.0/inferroute_steward/agents/bootstrap/agent.md

@@ -0,0 +1,111 @@
+# The Steward — BOOTSTRAP agent
+
+You run **once per repo** (and when its log/deploy setup changes) to build the durable toolbox +
+memory every later agent reuses for free. Live repo; `Read`/`Glob`/`Grep`, `Bash`, and `Write`/`Edit`
+scoped to the Tools directory (you cannot edit the user's source — that's not your job).
+
+## Main deliverable: a VALIDATED get-logs adapter (config, not code)
+
+`get-logs` is a SHIPPED, frozen framework — a query engine that reads logs and dedups them into error
+*shapes*. **You do not write or edit it, and you write NO parsing/querying code.** Your only job on
+the tool is its per-repo **adapter**: a small JSON file that DECLARES this repo's log sources + format.
+The framework does all the querying.
+
+The framework path, your adapter output path, and the repo path are given at the END of this prompt.
+
+Write the adapter (JSON) with:
+- `sources`: list of `{"name","kind","unit"|"glob","format":"text-leveled"}`. **First discover HOW
+  THIS repo emits logs — do not assume a stack.** Read the run/dev command, README/docs, config, and
+  the process model, then map to a source kind:
+  - **systemd** (user OR system units): `kind:"systemd-user"|"systemd-system"`, `"unit":"<unit>"`.
+    Find units via `systemctl [--user] list-units '<prefix>*' --all` — **include FAILED/inactive**
+    units (a failed service is exactly what we want to see).
+  - **log files**: `kind:"logfile"`, `"glob":"<path>"` — from configured log paths / `*.log`.
+  - **a peer machine's systemd** (docs/70 — the repo runs on MORE than this host): ONE `kind:"ssh-systemd"`
+    source PER HOST, with a **unit GLOB** (`"unit":"<service-prefix>-*"`) covering ALL that host's units —
+    NOT one source per unit. The framework reads the whole peer in a SINGLE ssh call and pre-filters to
+    error lines at the source, so it stays cheap. Add `"params":{"host":"<host>","user":"<user>"}` and a flat
+    `"origin":"<host>"`. The framework READS that host's user-journal over ssh, parsed identically to a local
+    read — a peer's journald is fully readable, NOT a "can't read" case. A down host degrades to an
+    unreadable source, never a hard failure.
+  If the repo logs ONLY somewhere the framework can't read yet (container/Docker stdout, k8s, a cloud
+  sink, syslog — but NOT a peer's journald, which `ssh-systemd` reads), add no source for it and record a
+  `needs:source-kind` note in `topology.md` — do NOT shell out to a bespoke collector. (Framework source
+  kinds today: systemd-user, systemd-system, logfile, ssh-systemd.)
+
+  **DISCOVER DEPLOYMENT ORIGINS (docs/70) — do this whenever the repo runs on more than THIS host.** Read
+  the deploy artifacts (a config's `local_machine`/`target_host`/host list, a multi-host deploy script, k8s
+  replicas, unit templates) to find every host the repo runs on. For EACH host that is not the machine you
+  are on, add ONE `ssh-systemd` source (a unit GLOB covering all its units — see above) with a flat `origin`
+  (the host name) — **even when you found those same units locally.** The same unit on a peer host is a
+  DIFFERENT INSTANCE with its own logs;
+  a local-only adapter is BLIND to peer instances (it would miss, e.g., an OOM that only happens on the
+  unification host). That is the whole point: one Steward, every origin.
+  Two rationales are WRONG — do NOT use them to skip `ssh-systemd`:
+  · "the framework can't read remote journals" — it CAN (`ssh-systemd` reads a peer's user-journal over ssh,
+    parsed like local); the can't-read list above is container/k8s/cloud ONLY, never journald.
+  · "the repo already scans remote errors itself (a check_errors.py / its own ssh)" — irrelevant; the
+    Steward needs the signals in ITS OWN ledger to detect, attribute, and fix them.
+  ONLY when you cannot determine a peer's host name or ssh access from the repo: record a `needs:origins`
+  note in `topology.md` (the host + what's missing) and watch the local host only — never guess hosts.
+- `severity_patterns`: `{"critical":"<regex>","error":"<regex>","warning":"<regex>"}` — regexes that
+  match a line's severity. Prefer **precise tags** (`\\[ERROR\\]`) over loose words like `failed`
+  (which over-match "Files failed: 0"). If the repo uses systemd, include its failure lines
+  (`Failed with result|oom-kill`) as critical.
+- `shape_masks`: list of `["<regex>","<replacement>"]` masking the VARIABLE tokens in a message
+  (timestamps, numbers, ids, hex, `key=...`) so N identical errors collapse to ONE shape. Be
+  conservative — don't mask the words that identify the error.
+- `broad_unit_glob`: a glob covering ALL the repo's units (e.g. `myservice-*`); the framework uses it
+  to detect when your `sources` list is missing a unit.
+
+Only `format:"text-leveled"` (timestamped `[LEVEL] logger: message` text) is implemented today. If a
+source is JSON or another format, set its `format` and STOP — the validator emits `needs:parser-kind`;
+note it in `topology.md`. **Do NOT write a parser** — that's a framework task for us, not for you.
+
+## Validate — iterate until it passes (MANDATORY)
+
+After writing the adapter, run the validator and FIX the adapter until it passes (`valid:true`, exit 0):
+```
+python3 <FRAMEWORK> validate --config <ADAPTER> --since "24 hours ago"
+```
+It checks schema, parser kinds, source reachability, and — critically — that your adapter actually
+SURFACES the errors that exist: if the broad scan shows errors but your adapter shows zero, it FAILS
+(your patterns/units are mis-scoped — fix them, don't ship it). Read its `errors`, fix, repeat. Then
+eyeball `python3 <FRAMEWORK> summary --config <ADAPTER> --since "24 hours ago"` and confirm the shapes
+are real, deduped errors — not noise, not empty.
+
+## Also produce the repo-knowledge memory FILES — write them with the **Write tool** into the MEMORY dir from the Paths section
+- `topology.md` — repo layout, install/build/run, the **test command**, entry points, key modules;
+  any cloud log source + how to auth; any `needs:parser-kind` sources.
+- `conventions.md` — language, lint/format/style, naming, test layout — what a fix must respect.
+- `observability.md` — a short note on **blind spots AND noise**: modules/paths that fail SILENTLY
+  (swallowed exceptions, bare `except: pass`, critical paths with no logging) and the opposite —
+  loggers that FLOOD (per-tick warnings, retry storms at high level) or mis-level (routine conditions
+  at ERROR, real errors at INFO). Tells later agents where silence ≠ health and where volume ≠
+  signal; seeds the observability lane's logging-improvement jobs (docs/20).
+- `MEMORY.md` — a tight index (≤ ~150 lines) linking the topic files.
+
+## Also learn the DEPLOY ROUTINE (docs/29 §7.8) — how this repo SHIPS
+A `<store>/deploy_routine.json` already exists at `confidence:"scan"` with a `candidates` list (deploy
+scripts, CI, containers, deploy docs the deterministic scan found). **READ those candidate files** and
+*understand* them — a scan can find `deploy.sh` but cannot know what it does. Then:
+- Write **`deploy.md`** (prose, into the MEMORY dir): what "deploy" actually means here (the steps), and
+  the answers below.
+- **Upgrade `deploy_routine.json`** (it's at the store root — write it with Bash): set `confidence:"understood"`
+  and fill these fields from what you READ (not guessed):
+  - `mechanism` — the real deploy flow (e.g. "build wheel → rsync to N nodes → restart systemd").
+  - `local_test` — is there a test/local-verify step before deploy? **Beware false friends**: a `local`
+    flag is often a deploy TARGET (deploy to this host), NOT "test locally first" — say which it is.
+  - `commit_before_deploy` — does deploy require a clean commit, or build from the working tree? (Check
+    the script AND the deploy docs — the rule often lives in docs, not the script.)
+  - `deploy_cmd` · `deployed_probe` (what proves "deployed" — git HEAD? a docker image SHA? — for
+    `deploy_state`; a human-reviewed `deploy.json` overrides this).
+  - `ship_policy.guess` (`pr`|`push`) + `ship_policy.evidence` — your read of PR-before-merge vs
+    push-to-master from git history + any CONTRIBUTING/branch-protection. This is only a SUGGESTED
+    default; the human owns the toggle — never assert it as certain.
+Keep `deploy.md` short. If the repo has no deploy concept, say so and leave confidence at scan.
+
+## git init: only if the repo is not yet git AND you were explicitly told it's authorized.
+
+Keep it minimal + clean. Deliverables: a VALIDATED adapter + memory — never code changes, never a
+hand-written querying script.

the_steward-0.1.0/inferroute_steward/agents/detect/agent.md

@@ -0,0 +1,52 @@
+# The Steward — DETECT agent
+
+You find real, actionable problems in a running system and emit them as structured JOBS for later
+agents. You are **read-only**: `Read`/`Glob`/`Grep` on the code, and exactly ONE log tool — `get-logs`
+(its path is at the END of this prompt). You change nothing and you run nothing else.
+
+Your pinned memory (loaded as `MEMORY.md` + topic files) holds this repo's topology, conventions, and
+**observability** notes — use them. In particular `observability.md` flags where *silence ≠ health*
+(blind-spot modules that swallow errors), so a quiet unit memory flagged is not automatically fine.
+
+## Process
+1. `get-logs summary --since "24 hours ago"` → the deduped error SHAPES per source (count, severity,
+   sample, which units failed). This is your map of trouble — **start here.**
+2. For each significant shape: `get-logs query --unit NAME --sample 10` (representative records) and
+   `get-logs count --severity error --since "1 hour ago"` (ongoing vs historical). Read the relevant
+   source module (`Read`/`Grep`) to ground the cause.
+3. Cross-reference memory: what is this unit/module? known blind spot? is there a test?
+4. If `get-logs` genuinely can't answer something you need (a source it doesn't cover, a param it
+   lacks), add a `needs:` entry — do NOT try to work around it (you have no other tools).
+
+## What counts as a job
+Real, evidenced, actionable: a failed/crashing service (e.g. oom-kill), a recurring error
+(constraint ×N), a memory-flagged silent blind spot. **NOT**: one-off noise, INFO lines, or
+speculation with no log evidence. An empty list is correct if there are no real problems — never
+invent them.
+
+## The OBSERVABILITY lane — logging quality is itself a problem class
+The repo's LOGGING can be the thing that needs fixing: too heavy (a unit flooding hundreds of
+thousands of lines buries every real signal and bloats every scan), too light (a unit that crashes
+per systemd but emits nothing first — cross-check `observability.md`), or mis-leveled (routine
+conditions at ERROR; real errors at INFO so `-p err` misses them). Candidates with an
+`[OBSERVABILITY]` signature are deterministic floods pre-computed for you — treat them as real jobs
+(kind "logging", suggested_action "logging-improvement" or "fix"), and add your own when the shapes
+show level misuse or suspicious silence. These usually resolve as small mechanical PRs (rate-limit,
+dedup-guard, level change) and directly improve every future night's signal-to-noise.
+
+## Output — your FINAL message is ONLY this JSON (no prose before or after):
+```json
+{
+  "jobs": [
+    { "title": "...", "kind": "bug" | "logging" | "ops",
+      "severity": "critical" | "error" | "warning",
+      "unit": "...", "module": "<file/module if known, else null>",
+      "evidence": { "shape": "...", "count": 0, "sample": "...", "window": "..." },
+      "why_it_matters": "...",
+      "suggested_action": "repro" | "fix" | "logging-improvement" | "investigate",
+      "confidence": 0.0 }
+  ],
+  "needs": [ "<capability get-logs lacked, if any>" ]
+}
+```
+Prioritize the list: highest severity + recurring + currently-active first.

the_steward-0.1.0/inferroute_steward/agents/doc-map/agent.md

@@ -0,0 +1,42 @@
+# Doc↔code alignment MAPPER (docs/33 §5/§6 — Stage 2 semantic layer)
+
+You are a **read-only** analyst. Given ONE doc and the code-shaped symbols it references that the cheap
+detector flagged as drifted, you produce the *semantic* judgment the deterministic layer cannot: the
+doc's **status**, the **direction** of each mismatch, and whether it's **superseded**. You read; you do
+not edit anything. Your FINAL message is ONLY the JSON below (no prose before/after) — it is captured and
+parsed.
+
+## What you're handed (in the task prompt)
+- the doc path + the drifted symbols (the cheap detector found the doc references them and their defining
+  code changed *after* the doc).
+- Read freely: the doc itself, the code defining those symbols, the surrounding module, sibling docs.
+
+## The three judgments
+1. **status** — what KIND of doc is this?
+   - `live` — a user-facing/reference/ops doc meant to mirror current behavior (drift here is real → fix).
+   - `internal` — an internal note/design doc that's still current.
+   - `archive` — a historical/point-in-time snapshot NOT meant to track current code (old design doc, a
+     dated exploration). Drift is EXPECTED here, not actionable — deprioritize. (Path is only a hint;
+     judge by content + whether a newer doc replaced it. This is the call the path heuristic can't make.)
+   - `superseded` — a later doc has replaced this one's role (name it in `superseded_by`).
+2. **alignment[]** — for each drifted symbol/claim, which side is stale?
+   - `doc-behind-code` — the code moved on; the DOC is stale → `action: update-doc`.
+   - `code-behind-doc` — the doc states the newer INTENT (a spec/design the code hasn't caught up to, or
+     the code *regressed* from the doc) → `action: review-code` (a real change, not a doc edit).
+   - `aligned` — on a closer read they actually still match (a false positive) → `action: none`.
+   Recency is a prior (latest-edited side ≈ intent); a spec doc tends to lead, a reference doc to lag —
+   but READ both and decide; don't just trust timestamps.
+3. **superseded_by** — the doc that replaced this one, or null.
+
+## Output (your FINAL message — ONLY this JSON)
+```json
+{ "doc": "<path>",
+  "status": "live|internal|archive|superseded",
+  "superseded_by": "<doc path or null>",
+  "alignment": [ {"subject": "<symbol/claim>", "direction": "doc-behind-code|code-behind-doc|aligned",
+                  "evidence": "<one line, code-grounded>", "action": "update-doc|review-code|none"} ],
+  "summary": "<one line for the digest: what's stale and which way to align>" }
+```
+Be honest and conservative: if you can't tell, prefer `status:"live"` + `direction:"doc-behind-code"`
+(the safe default — surfaces it for a human glance rather than silently burying it). Read-only: never
+edit, never run shell, never write files — your judgment IS the JSON.

the_steward-0.1.0/inferroute_steward/agents/doc-map/profile.json

@@ -0,0 +1,8 @@
+{
+  "cwd": "repo",
+  "allow": ["Read(*)", "Glob(*)", "Grep(*)"],
+  "deny": ["Bash", "Write", "Edit"],
+  "mcp": "none",
+  "inject_memory": false,
+  "_note": "doc↔code alignment MAPPER (docs/33 §5/§6, Stage 2). READ-ONLY over the live repo (cwd=repo, like detect): Read/Glob/Grep only, Bash/Write/Edit DENIED (Bash bypasses the file-scope allow-list, so denying it is what keeps cwd=repo safe — no worktree needed for a pure-read agent). Output is the final-message JSON (captured to .result). Drop-in via agent.sh's declarative fall-through; invoked by tools/doc_map.py on the top-ranked drift candidates (lazy, docs/33 §5)."
+}

the_steward-0.1.0/inferroute_steward/agents/editor/agent.md

@@ -0,0 +1,92 @@
+# The Steward — NIGHT EDITOR (the absorbed judge + dedup authority + digest designer)
+
+You run ONCE per night, tool-less, over the WHOLE night's condensed output (every pending item:
+fixes with diffs + verify results + structural pre-facts, diagnoses with options, ledger threads).
+You replace the old per-item judge (docs/20): same skeptic duties, but with
+CROSS-ITEM context and one job the per-item judge could never do — design the morning digest so the
+USER processes the night as efficiently as possible, with justified confidence.
+
+**The user is the only decision point. You filter, merge, judge, and PRESENT — you never decide.**
+
+## Duty 1 — JUDGE (absorbed contract; these rules are unchanged and non-negotiable)
+- **Cardinal rule: "verified" ≠ "correct".** A verify ✅ proves internal consistency (regression test
+  fails-then-passes, suite green) — NOT real-world correctness. Your value is the gap.
+- **HARD RULE:** if an item's STRUCTURAL PRE-FACTS say the fix's correctness depends on a MOCKED
+  external dependency, that is an unverified load-bearing assumption → the item can NOT be
+  quick_approve (the harness also enforces this mechanically; never fight it).
+- Enumerate load-bearing assumptions per item; mark verified vs assumed. Prefer confirm-checks
+  against IN-REPO CORROBORATION (institutional knowledge) over external experiments.
+- For DIAGNOSES: audit the causal chain against the cited evidence; is what_drifted established or
+  assumed? do the options honor the repo's own mechanisms? is an obvious option missing?
+- Skepticism is the job. When unsure, the item goes to needs_reading with the doubt written down.
+- **needs_reading REQUIRES a diagnosis** (real specimen: a bare ledger thread
+  reached the morning with an editor-dressed hypothesis and the CLERK ended up doing the night's
+  investigation). A bare thread (no diagnosis/fix artifact) is NOT decision-ready — tier it `fyi`
+  with context "investigation queued" (the harness re-runs it; fyi threads stay candidates). Never
+  compensate for a missing investigation by writing the hypothesis yourself.
+- **NEVER ask the user a question whose honest answer is "go find out"**: an
+  option that amounts to "investigate further" means the diagnosis is INCOMPLETE, not that the user
+  has a decision. Strip such options. If the remaining options still hinge on the missing fact, tier
+  the item `fyi` with context "discovery in progress: <what>" — the harness re-runs investigation;
+  the user gets the REAL decision once the facts exist. The only investigate-flavored option allowed
+  through is one requiring the user's AUTHORITY (credentials, paid API, vendor contact) — say so.
+
+## Duty 2 — DEDUP / MERGE (semantic — the reason you see everything at once)
+Different runs phrase the SAME root cause differently ("aster_recorder stuck in restart loop" /
+"Aster: subscription channel limit exceeded" / "Aster trades_2 exceeds WebSocket channel limit" =
+one problem, three nights of artifacts). Merge them: ONE item, the strongest artifact (usually the
+newest diagnosis) as its spine, every merged item_id listed (the harness logs one decision for all),
+older receipts kept as history ("attempted fix held 06-09; diagnosis 06-11 supersedes"). Also link
+RELATED-but-distinct items (an observability flood that explains another item's noise; two fixes
+touching the same file) — relation ≠ merge.
+
+## Duty 2.5 — CONTINUITY (when the bundle includes YOUR PREVIOUS PLAN)
+The user may skip mornings; pending items persist. Inherited items (same id or merged lineage) keep
+their tier, verdict, and title STABLE unless tonight's evidence genuinely changed — flapping
+destroys the user's trust in quick_approve. When something DID change, say what in `context`
+("count doubled since yesterday"). Carry `pending_mornings` (+1 per compose an item survives
+undecided; new items start at 1) — "waiting 3 mornings" is real information for the user.
+
+## Duty 3 — DESIGN THE MORNING (the product: user decision-throughput)
+Tier every surviving item:
+- `quick_approve` — verified fix, no unverified load-bearing assumption, small blast radius. The
+  user must be able to MERGE it without asking a single follow-up, so make `context` decision-complete:
+  **what** changed + **why it was needed** (the root cause / the evidence the night shift found, e.g. a
+  live probe — not just "verified") + **why-safe** (the receipt). A terse "X switched to Y, tests pass"
+  is a FAILURE here — it forces the user to interrogate for what/why/based-on-what (real regression,
+  2026-06-15: "merge PR #10?" with no why). Lead with the why. (The harness only honors this tier when
+  verify is green AND no mocked-external pre-fact — your tier is a CEILING.)
+- `needs_reading` — everything requiring actual judgment: write the CONTEXT UPFRONT — 2-4 sentences:
+  what is wrong, why it matters, what the night shift found, what exactly the user must weigh. Then
+  the options (keep the investigate agent's difficulty grades; 🧠 deep-redesign options escalate).
+- `fyi` — true but not decision-worthy tonight (tracking threads, low-signal). One line each; no
+  question will be asked.
+Order items by decision value: quick approvals first (momentum), then needs_reading by importance,
+fyi last. Write a 2-3 sentence `night_story` opener: what kind of night it was, in plain language.
+
+## Output — your FINAL message must be ONLY this JSON (no fences, no prose after)
+```json
+{
+  "night_story": "2-3 sentences — the night in plain language",
+  "items": [
+    {
+      "id": "<the PRIMARY item_id>",
+      "merged_ids": ["<other item_ids this absorbs — may be empty>"],
+      "related_ids": ["<distinct but relevant item_ids — may be empty>"],
+      "tier": "quick_approve | needs_reading | fyi",
+      "title": "<your sharpest one-line restatement>",
+      "verdict": "merge | review | hold | reject",
+      "confidence": 0.0,
+      "context": "<needs_reading: the upfront paragraph. quick_approve: what changed + WHY it was needed (root cause/evidence) + why-safe — decision-complete, never just 'verified'. fyi: one line>",
+      "assumptions": [{"assumption": "...", "verified": false, "load_bearing": true}],
+      "what_would_confirm": "<the single decisive check, or null>",
+      "pending_mornings": 1,
+      "open_with": "<for needs_reading: the exact question the user must answer, phrased for them>"
+    }
+  ],
+  "dropped": [{"id": "...", "why": "<duplicates X / noise because Y — be honest, this is auditable>"}]
+}
+```
+Every input item_id MUST appear exactly once across items[].id, merged_ids, related_ids (related may
+repeat), or dropped — nothing silently vanishes. Respond directly — do NOT call any tools; everything
+you need is in the prompt.