io-harness 0.6.0

A Rust agent harness: run an AI agent from a typed task contract to a verified result. Provider-agnostic (OpenRouter, Anthropic, OpenAI), multi-file edits with grep/find over a workspace, budgets, retry, full trace, resumable runs, execution-based verification, a layered permission policy with a human-approval gate, contained sub-agent composition, and an OS-native/OS-neutral execution sandbox (macOS sandbox-exec, Linux namespaces, Windows Job Objects, portable floor) that isolates model-produced code per run. Embeddable in-process.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

# Contributing to IO Harness

Thanks for your interest. This guide keeps contributions consistent across every
[initorigin](https://github.com/initorigin) repo.

## Ground rules

- Be respectful — see [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
- By contributing you agree your work is licensed under Apache-2.0.
- Keep changes small and focused. One concern per PR.

## Branch and PR flow

- The integration branch is **`develop`**. `main` holds released versions only.
- Branch from `develop` using **`feat/<version>`** (for example `feat/0.1.0`).
- Open a **pull request into `develop`**. Do not push directly to `develop` or
  `main`. A maintainer reviews and merges.
- When a version is ready to release, a **`develop` → `main`** PR is opened; that
  merge is the release. See [docs/RELEASE_PROCESS.md](docs/RELEASE_PROCESS.md).

## Commits

Use [Conventional Commits](https://www.conventionalcommits.org/):

```
<type>(<optional scope>): <subject>
```

Types: `feat`, `fix`, `docs`, `refactor`, `perf`, `test`, `build`, `ci`,
`chore`. Keep the subject under ~50 characters and in the imperative mood. Do not
add signatures, "Co-Authored-By", or generated-by trailers.

## Changelog is required

Every user-facing change updates [CHANGELOG.md](CHANGELOG.md) under
`## [Unreleased]`, in the correct category, following
[docs/CHANGELOG_STRUCTURE.md](docs/CHANGELOG_STRUCTURE.md). Release notes are
generated from the CHANGELOG, so an entry that is unclear ships as unclear notes.

## Before you open a PR

- Code is formatted and lints clean (`cargo fmt` and `cargo clippy`).
- Tests pass where they exist.
- The CHANGELOG is updated.
- The PR description follows the template.