peat-lite 0.2.5

Lightweight CRDT primitives for resource-constrained Peat nodes
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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

# Contributing to peat-lite

Thank you for your interest in contributing to peat-lite! This document provides guidelines and workflows for contributing.

## Getting Started

1. Fork the repository and clone your fork
2. Create a feature branch from `main`
3. Make your changes
4. Submit a pull request

## Development Setup

### Prerequisites

- Rust stable toolchain (install via [rustup](https://rustup.rs))

### Feature Flags

| Feature | Description |
|---------|-------------|
| `std` (default) | Standard library support |
| (no default features) | `no_std` embedded build |

### Building

```bash
cargo build                     # std (default)
cargo build --no-default-features  # no_std (embedded)
```

## Testing

```bash
# Unit tests
cargo test

# Verify no_std builds
cargo build --no-default-features

# Integration tests (wire protocol edge cases)
cargo test --test wire_edge_cases
```

## Pre-Commit Checks

Before submitting a PR, ensure all of the following pass locally:

```bash
cargo fmt --check
cargo clippy -- -D warnings
cargo test
cargo build --no-default-features
```

The CI pipeline runs these same checks on every PR.

## Branching Strategy

We use **trunk-based development** on `main` with short-lived feature branches:

- Branch from `main` for all changes
- Keep branches small and focused (prefer multiple small PRs over one large one)
- Squash-and-merge to `main`

## Commit Requirements

- **GPG-signed commits are required.** Configure commit signing per [GitHub's documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification).
- Write clear, descriptive commit messages

## Pull Request Access

Submitting pull requests requires contributor access to the repository. If you're interested in contributing, please open an issue to introduce yourself and discuss the change you'd like to make. A maintainer will grant PR access to active contributors.

## Pull Request Process

1. Open a PR against `main` with a clear description of the change
2. Fill out the PR template
3. Ensure CI passes (fmt, clippy, tests, no_std build)
4. PRs require **1 approving review** from a CODEOWNERS member
5. External contributors require **2 approving reviews**
6. PRs are squash-merged to maintain a clean history

## Architectural Changes

For significant architectural changes, open an issue first to discuss the approach. Reference the relevant ADR (Architecture Decision Record) if one exists, or propose a new one.

## Reporting Issues

Use GitHub Issues to report bugs or request features. Please use the provided issue templates.

## Code of Conduct

All contributors are expected to follow our [Code of Conduct](CODE_OF_CONDUCT.md).

## License

By contributing, you agree that your contributions will be licensed under the [Apache License 2.0](LICENSE).