# Repository Guidelines

## Project Structure & Module Organization
Core code lives in `src/` and public headers in `include/cvmmap_streamer/`. The main runtime is `src/main_streamer.cpp`; shared logic is split by concern under `src/config`, `src/core`, `src/ipc`, `src/pipeline`, `src/protocol`, and `src/metrics`. Test utilities are standalone binaries in `src/testers/`. Automation and release gates live in `scripts/`, while operator notes and smoke-test profiles live in `docs/`. Third-party dependencies are vendored in `lib/` and should only be changed deliberately.

## Build, Test, and Development Commands
Configure and build with:

```bash
cmake -B build -S .
cmake --build build
```

This produces `build/cvmmap_streamer`, `build/rtp_receiver_tester`, `build/rtmp_stub_tester`, and `build/ipc_snapshot_tester`.

Use `cmake --fresh -B build -S .` if CMake caches stale dependency paths. Run the mandatory acceptance matrix with `./scripts/acceptance_standalone.sh` and the baseline fault suite with `./scripts/fault_suite.sh`. For targeted manual checks, run the built testers directly against `build/cvmmap_streamer`.

## Coding Style & Naming Conventions
This project targets C++23. Follow the existing style: tabs for indentation, braces on the same line, `snake_case` for functions and variables, `PascalCase` for types and enums, and lowercase directory names by subsystem. Keep headers under `include/cvmmap_streamer/...` aligned with their implementation paths where practical. No formatter or linter config is checked in, so match the surrounding file exactly before submitting changes.

## Testing Guidelines
There is no top-level unit-test framework in this repo; verification is primarily binary- and script-driven. Add behavior checks through `src/testers/` and extend the shell suites in `scripts/` when introducing new protocol or fault scenarios. Prefer deterministic inputs such as the dummy backend (`--input-mode dummy`) and keep labels short. Review generated evidence under `.sisyphus/evidence/` when validating failures.

## Commit & Pull Request Guidelines
Recent history uses Conventional Commit prefixes such as `feat(...)`, `fix(...)`, `refactor(...)`, `test(...)`, `build(...)`, and `chore(...)`. Continue that pattern and keep scopes specific, for example `refactor(protocol): simplify wire codec setup`. PRs should explain the runtime impact, list the commands you ran, and attach relevant logs or screenshots when output behavior changes. Link any issue or task ID when one exists.