aviso-server 0.5.0

Notification service for data-driven workflows with live and replay APIs.
# Backend Development Guide

This guide explains how to add a new notification backend in Aviso.

## Required Contract

A backend must implement `NotificationBackend` in `src/notification_backend/mod.rs`.

Core requirements:

- Implement publish/replay/subscribe/admin methods.
- Implement `capabilities()` and return a stable `BackendCapabilities` map.
- Keep startup/shutdown behavior explicit and logged.

## Storage Policy Compatibility

Per-schema storage policy is validated at startup before backend initialization.

Validation entry point:

- `configuration::validate_schema_storage_policy_support(...)`

Capability source:

- `notification_backend::capabilities_for_backend_kind(...)`

If a schema requests unsupported fields, startup fails fast with a clear error.
Do not silently ignore unsupported storage policy fields.

## Capability Checklist

When adding backend `<new_backend>`:

1. Add backend kind support in `capabilities_for_backend_kind`.
2. Add `NotificationBackend::capabilities()` implementation.
3. Ensure capability values match real backend behavior.
4. Add tests for:
   - capability map values
   - accepted storage-policy fields
   - rejected storage-policy fields
5. Add backend docs page and update summary links.

## Minimal Capability Example

```rust
BackendCapabilities {
    retention_time: true,
    max_messages: true,
    max_size: false,
    allow_duplicates: false,
    compression: false,
}
```

Meaning:

- `retention_time` and `max_messages` can be used in schema storage policy.
- `max_size`, `allow_duplicates`, and `compression` must be rejected at startup.

## Testing Expectations

- Unit tests should verify capability flags are stable.
- Validation tests should verify fail-fast messages for unsupported fields.
- Integration tests should use test-local config/schema fixtures, not developer-local YAML files.