Early version v0.1.0 · Native agents, one terminal workflow.Current status

Navigation

Browse documentation

Contribution guidelines

Ground rules, checks, and how to add a provider or documentation.

On this page

Ground rules

  • uuldana-cli supervises other agents. It does not become one. Changes that add an agent loop, a generic model wrapper, or simulated provider responses will not be accepted.
  • Do not claim more than you verified. A capability that was not proven against the real provider is Unknown, not Supported. Tests that need a provider that is not installed must skip and say so.
  • uuldana-core stays synchronous, free of I/O, and free of third-party dependencies. The workspace forbids unsafe_code.

Setup and checks

You need a current stable Rust toolchain. On Windows, follow Development environment.

sh
cargo fmt --all
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo test --workspace --locked

CI is configured to run the same on Linux, macOS, and Windows (GNU and MSVC).

Tests

Prefer real child processes in real pseudo terminals over mocks of the process layer. Tests that talk to an installed provider only open its interface and leave, and must not send a prompt. Tests must not leave data behind: use temporary directories and remove them, and use realistic names and text.

Adding a provider

See Adding provider integrations. A manifest is enough for a provider that flags can describe.

Commits and pull requests

Keep a change focused. Describe what changed and how you verified it, including what you could not verify. Do not reformat unrelated code.

Reporting a vulnerability

Do not open a public issue for a security problem. The repository does not yet have a published contact address or hosting page, so contact the maintainer directly until one is added. See the security policy for what uuldana-cli does with your data.

Documentation

Write each guide around a developer’s task. State the prerequisites, give the steps in order, and explain the result of each command. Link to a relevant guide when the reader needs more detail.

Keep first-session instructions, day-to-day guides, architecture explanations, and API reference focused on their own purpose. Verify commands and configuration against the implementation before publishing them. Clearly label behavior that is planned or has not been verified.

Search documentation

Start typing to search all articles.

↑ ↓ navigate · Enter openEsc close