docs: add 5 architecture decision records

[Pomdapis]

Summary

• Adds docs/adr/ directory with MADR-format ADRs documenting Compendium's structural choices
• Five accepted ADRs: Result pattern, hexagonal architecture, zero-dep Core, multi-tenancy, event sourcing
• Includes index (README.md) and reusable template (0000-template.md)

ADRs added

#	Title
0001	Result pattern over exceptions for business errors
0002	Hexagonal architecture (strict)
0003	Zero-dependency Core
0004	Multi-tenancy strategy
0005	Event sourcing over state-stored persistence

Each ADR is < 60 lines and follows MADR sections: Status, Date, Context, Decision, Consequences (Positive / Negative-Trade-offs), Alternatives considered.

Notes

• docs/toc.yml integration intentionally skipped — POM-180 (docs scaffolding) lands separately and will wire ADRs into the TOC there.
• ADRs are written as honest snapshots of the situation at decision time, not post-hoc justification: each Context section names the concrete forces, each Alternatives section names what was rejected and why.

Test plan

• Reviewer reads each ADR and confirms factual accuracy against the codebase (Core has zero NuGet deps, Multitenancy has the named components, etc.)
• Reviewer confirms tone and content match the project's strategic position
• CI green

[Copilot]

Pull request overview

Adds a new docs/adr/ documentation area to capture Compendium’s key architectural decisions using the MADR format, intended to serve as a durable reference for contributors and consumers.

Changes:

• Introduces an ADR index (docs/adr/README.md) and a reusable MADR template (docs/adr/0000-template.md).
• Adds five “Accepted” ADRs documenting major architectural decisions (Result pattern, strict hexagonal architecture, zero-dependency Core, multi-tenancy, event sourcing).

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
docs/adr/README.md	ADR landing page and index table for quick navigation.
docs/adr/0000-template.md	MADR template for consistent future ADR submissions.
docs/adr/0001-result-pattern.md	Documents the decision to prefer Result<T> for business errors.
docs/adr/0002-hexagonal-architecture.md	Documents strict ports/adapters boundaries and dependency direction.
docs/adr/0003-zero-dep-core.md	Documents “Core has zero NuGet dependencies” constraint.
docs/adr/0004-multi-tenancy-strategy.md	Documents tenant resolution/consistency/isolation approach.
docs/adr/0005-event-sourcing-vs-state.md	Documents event sourcing as the source-of-truth persistence model.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The ADR states an Outbox pattern is part of the decision, but there doesn't appear to be any Outbox implementation/types in the repository (no Outbox* classes or infrastructure). If Outbox is not implemented yet, consider rewording this as a planned follow-up (or changing status), or link to the actual component name if it exists under a different term.

[Copilot]

This claims Result.Success(...) / Result.Failure(...) are the only sanctioned construction paths, but the current Result API also provides implicit conversions (e.g. TValue -> Result<TValue> and Error -> Result<T>). Either document these implicit conversions as sanctioned, or tighten the API if you want to enforce only factory usage.

Suggested change

	- `Result.Failure(...)` and `Result.Success(...)` are the only sanctioned construction paths. No `null` for "absent value" — use `Result.Failure(Error.NotFound(...))`.
	- Prefer `Result.Failure(...)` and `Result.Success(...)` as the explicit construction paths. Where the API provides implicit conversions (for example `TValue -> Result<TValue>` and `Error -> Result<T>`), those are also sanctioned convenience forms. No `null` for "absent value" — use `Result.Failure(Error.NotFound(...))`.

[Copilot]

The index uses quarter-style dates (e.g. 2026-Q2) while the ADRs themselves and the template use YYYY-MM-DD. This inconsistency makes it harder to sort/filter ADRs and can confuse readers; consider using the same ISO date format in the README (or explicitly document why the index uses quarters).

[Copilot]

This describes TenantContext as an immutable record with provenance and as a scoped "one per request" service. In the current codebase, TenantContext is a mutable class backed by AsyncLocal, and DI registers tenant context/accessor as singletons (per-async-flow isolation rather than per-request scope). Please update the ADR to match the actual types/lifetimes (or adjust the implementation to match the ADR).

[Copilot]

These bullets imply the tenant-scoping guarantees come from TenantContext being request-scoped. Given TenantContextAccessor/ITenantContext are registered as singletons and rely on AsyncLocal, the guarantee is different (async-context scoping). The ADR should describe the actual isolation mechanism so readers don't assume ASP.NET Core DI scoping is the enforcement point.