# Repository working agreements

## Repository purpose and map

- Purpose: [one sentence, grounded in README/product brief]
- Logical project / this repository's role: [stable ID and responsibility, if relevant]
- Coordination repository / canonical delivery board: [actual references, if used]
- Primary apps/services: [path -> responsibility]
- Shared contracts: [path or "none"]
- Authoritative design docs: [docs/index.md or exact path]

## Before changing code

1. Read the relevant feature/module and the closest `AGENTS.md`.
2. Check `docs/architecture/` and affected API/data contracts before modifying boundaries.
3. For changes crossing services, APIs, data schemas, auth, tenancy or deployment, first make an implementation plan under `docs/plans/` (or use the team's existing planning convention).
4. Preserve established conventions and avoid unrelated restructuring.
5. For multi-repository work, identify the owning issue, contract owner, allowed repositories and integration check. A sibling checkout or embedded repository is not automatically in scope.

## Architecture constraints

- [Allowed dependency direction; e.g. domain cannot import infrastructure]
- [Who owns which data and external API/event contracts]
- [Tenant authorization/isolation rules, if applicable]
- [Approved technology or dependency constraints]
- [Submodule/shared package version ownership, if applicable]

## Development commands

- Install: `[verified command]`
- Test: `[verified command]`
- Lint/typecheck: `[verified command]`
- Build: `[verified command]`
- Local run: `[verified command]`
- Development mode/configuration and local/test data ownership: `[actual local guide or concise rules; Docker files/profile/project identity if used]`
- Stop versus destructive reset: `[data-preserving command and separately scoped reset policy, if persistent local data exists]`

## Completion requirements

- Add/update targeted tests and document unverified behavior honestly.
- Update affected API, data, architecture diagrams, ADRs and runbooks when behavior changes.
- Review `git diff --check` where Git is available.
- Never include secrets or real private customer data in documentation or logs.
- Do not commit, push, deploy, delete or rotate credentials without authorization.
- Preserve existing uncommitted work and report actual checks and unresolved dependencies. Historical task notes do not grant new operational permissions.

## Further reading

- [Architecture index](docs/index.md) (only keep when it exists)
- [Project brief](docs/product/brief.md) (only keep when it exists)