Feature request: richer review context — auto-include AGENTS.md + spec↔file mapping

## Context: we've integrated `ocr` into "devloop"

[devloop](https://github.com/qiankunli/devloop) is an agent plugin (Claude Code today) for an **aggregate-workspace dev loop** — a state bus + hard guards that drive `enter → develop → commit/MR → human merge`. We've wired **`ocr` in as a lifecycle hook**: when an MR is created, a background

```
ocr review --from origin/ --to HEAD --format json --repo
```

runs (fire-and-forget, doesn't block commit), and we post the result as an **MR comment** (so each MR accumulates a review history) plus surface it back to the agent session. `ocr` keeps its own LLM config; this has worked really well — thank you for the tool. 🙏

We're now focused on **review accuracy**, and the main lever is **giving `ocr` more context**. We already auto-pass `--background` (commit messages + MR title/description). Two further context sources would help a lot but need `ocr`-side support:

---

## 1. Auto-include the repo's `AGENTS.md` as review context

Many repos keep their conventions / architecture in an **`AGENTS.md`** (commonly at the repo root, or `server/AGENTS.md` / `backend/AGENTS.md`). These are exactly the "house rules" a reviewer must know: layering boundaries, mandatory timeouts/connection-pool config, SQL-dialect portability, naming, etc.

**Request:** if `ocr` detects an `AGENTS.md` in the repo (or the resolved code dir), automatically include its content as review context (alongside `--background` / rules), ideally with a sensible cap or summary.

Today we *can* stuff it into `--background`, but that's per-file and token-heavy, and not first-class. Native support — e.g. auto-detect `AGENTS.md`, or a config like `context_files` — would be cleaner and benefit everyone, not just our integration.

---

## 2. Spec-aware review via a spec ↔ file mapping

`ocr`'s pipeline today is `diff → changed files → per-file review`. A big accuracy win would be: for each changed file, also feed the **spec(s) that file implements**, so the review can ask *"does this change still satisfy the spec / requirement?"* — not only *"is this code locally OK?"*.

This needs two things:
1. **A spec format/ruleset** (requirements + scenarios, or a pointer to spec files).
2. **A declared spec ↔ file mapping** — which spec governs which files/paths — analogous to how `.opencodereview/rule.json` maps path globs → rules. For example a path-glob → spec-file(s) mapping, and `ocr` includes the matched specs as context for those files.

This would make `ocr` **requirement-aware**, a step beyond purely code-local review — and pairs naturally with spec-driven workflows.

---

Happy to discuss design and contribute a PR for either if you're open to it. Thanks again for `ocr`!

Start by tracing how existing --background context is handled and how .opencodereview/rule.json maps path globs to rules. Then examine where repository context and per-file review inputs are assembled; done means the design covers AGENTS.md discovery or configuration and a declared spec-to-file mapping with bounded context inclusion.

Written by the indexing model from the issue text.