# Contributing to mps-rs

Bug reports, feature requests, and pull requests are all welcome. This document explains how to get started.

---

## Prerequisites

- **Rust stable 1.70+** — install via [rustup](https://rustup.rs/)
- **git**
- **`notify-send`** (optional) — only needed to manually test desktop notifications on Linux

---

## Clone and build

```bash
git clone https://github.com/mash-97/mps-rs
cd mps-rs
cargo build
```

Install the binary locally for manual testing:

```bash
cargo install --path .
```

---

## Running tests

```bash
cargo test --all
```

The test suite has three targets:

| Target | What it covers |
|--------|---------------|
| `src/lib.rs` (unit tests) | Parser, store, meta, time_parse, config merge |
| `tests/integration_test.rs` | Public store API, meta roundtrips, notify dry-run |
| `tests/edge_cases_test.rs` | Fixture-based tests using `.mps` files in `tests/fixtures/` |

### Adding a fixture-based test

1. Drop a `.mps` file into `tests/fixtures/` — name it anything, e.g. `my_case.mps`.
2. Add a `#[test]` function in `tests/edge_cases_test.rs` that loads the fixture via
   `Store::new(fixtures_dir())` or `parser::parse_file(...)`.
3. Run `cargo test` to verify.

---

## Code style

```bash
cargo fmt          # format before committing
cargo clippy -- -D warnings   # must be warning-free
```

CI enforces both checks on every pull request.

---

## Commit messages

Use the conventional format:

```
type: short description (imperative mood, ≤72 chars)
```

Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`.

Reference an issue number when applicable: `fix: handle empty body in edit (#42)`.

---

## Opening a pull request

1. Fork the repo and create a branch: `git checkout -b feat/my-feature`
2. Make your changes with tests.
3. Run `cargo test --all` and `cargo clippy -- -D warnings`.
4. Push and open a PR against `master`.
5. Fill in the PR template checklist.

Prefer small, focused PRs. If you're building something large, open an issue
first so we can agree on the approach before you invest the time.

---

## Reporting bugs

Use the **Bug report** issue template. Always include the output of `mps version`
and a minimal reproduction — ideally a `.mps` file snippet and the exact command
that triggers the problem.

---

## Good first issues

Look for issues labelled [`good first issue`](https://github.com/mash-97/mps-rs/labels/good%20first%20issue).
Adding test cases in `tests/fixtures/` or improving error messages are safe
starting points that don't require deep knowledge of the parser.

---

## Project layout

See the **Architecture** section in [README.md](README.md) for a map of source
files and the two sidecar files (`.mps.meta`, `.mps.local`).
