Skip to main content

Module agent

Module agent 

Source
Expand description

The coding-agent driver: a provider, the built-in workspace tools, and the per-turn loop — the provided rhema_core::run_turn, or, with a steering source configured, the driver’s own loop with the two drain points that append finished-work notifications at step boundaries.

The agent owns one ShellTools resolver for its lifetime. Approval arrives per turn; it is installed into the resolver before stepping and cleared after (see rhema_agent_tools::approval for why the hook travels as an Arc). The session is plain data — the driver may mutate it between turns, checkpoint it, or resume it from disk. A turn entering with committed-but-unanswered calls (a crash resume) revives first: replay-safe tools re-run, the rest are reported interrupted — see revive_dangling_calls.

Structs§

CodingAgent
A coding agent: drives run_turn over the built-in tools, one turn at a time, keeping the history in a caller-visible Session.

Enums§

CodingAgentError
Why a turn or a session operation failed.

Functions§

clear_environment_stamp
Clears a session’s stamped environment report — the transition hook for rebuilds that change the facts the report carries: a machine switch (a sandbox picked mid-conversation re-reports where bash runs) or a model switch (the report names the model, and the provider’s cache is per-model regardless). Transitions that change neither — a thinking level, a resume — keep the stamp: the report is conversation state, and re-rendering it would rewrite the system prompt and break the prefix cache for nothing.
stamped_system
The system prompt an agent stamps into every request, assembled outside an agent: base — the user’s SYSTEM.md — when given, the built-in default otherwise, rendered over workspace as given, the discovered skills, and the tool specs — the built-ins plus extra, the extension resolver’s specs, so the prompt and the request’s tools array cannot drift. The one assembly point: CodingAgent::new builds every agent’s prompt here, and a driver that previews the prompt calls the same function, so what is previewed is what turns send. No optional sections: the environment report and the user preferences render empty.
stamped_system_with_sections
The full assembly: the template over workspace, the skills, the tool specs, and the two optional sections — environment (machine facts probed where commands run, see crate::environment) and user (the user’s preferences file, verbatim). The template decides whether and where the sections appear; None is the section-less render the older constructors name.
stamped_system_with_skills
stamped_system over skills collected elsewhere — the input path for frontends with no filesystem to discover from: the cloud deployment keeps skills in its durable storage, seeds them into the sandbox workspace, and feeds the list here. The model still reads a skill’s body through the shell, so each Skill::path must resolve inside the workspace the tools run on.