# Audit Crate Instructions
Applies to `crates/audit/`.
`rustfs-audit` is the domain layer for audit event fan-out and observability.
It composes shared plugin/runtime abstractions from `rustfs-targets` and keeps
audit-specific dispatch semantics, state transitions, and metrics in this
crate.
## Domain Boundaries
- Keep audit-specific behavior here:
- audit event shaping and fan-out pipeline
- audit system lifecycle/state transitions
- audit metrics and reporting
- Keep shared plugin/runtime mechanics in `rustfs-targets`:
- no duplicated replay worker orchestration
- no duplicated runtime manager primitives
- no plugin install/control-plane modeling in this crate
## Runtime Layering Rules
- `pipeline.rs` hosts:
- `AuditPipeline` (dispatch and snapshot access)
- `AuditRuntimeFacade` (runtime mutation path)
- `AuditRuntimeView` (runtime read path)
- `registry.rs` should remain the single owner of runtime target container and
plugin registry composition for audit.
- `system.rs` should coordinate lifecycle by calling facade/view/registry
boundaries rather than embedding low-level runtime logic.
## Change Style
- Preserve audit delivery semantics and error handling behavior unless the task
explicitly changes them.
- Prefer extending shared abstractions in `rustfs-targets` over patching
one-off audit-only runtime flows.
- Keep logging and observability machine-meaningful; avoid noisy churn in hot
dispatch paths.
## Testing
- Keep unit tests close to changed modules.
- Keep pipeline-layer regressions in `tests/pipeline_layer_test.rs`.
- Add regression tests for:
- runtime facade activation/replace/stop/shutdown behavior
- runtime view target/snapshot access
- system reload and runtime commit/clear boundaries
- Suggested validation:
- `cargo test -p rustfs-audit`
- Focused: `cargo test -p rustfs-audit --test pipeline_layer_test`
- Focused: `cargo test -p rustfs-audit pipeline`