docs(rfc-0001): extend §5 with OTLP-receiver acceptance criteria

[jensholdgaard]

Summary

The §6.1 amendment (#21) and §6.2 algorithm rewrite (#23) moved the miner's contract to consume OtlpLogRecord and introduced the body.kind fork plus the (severity_number, scope_name, …) template-key tuple — but no §5 acceptance criteria covered those commitments. RFC 0003 (#24) settled the receiver side; this PR closes the corresponding gap on the miner side. Wave 3 of the OTLP-alignment sequence (#20 → #21 → #22 → #23 → #24 → this).

Changes

Added six scenarios under the existing §5 structure (no new subsection, no new ID namespace):

• §5.1 H1.4 — severity_number is part of the template key; no silent INFO/ERROR merge.
• §5.1 H1.5 — scope_name is part of the template key; no cross-scope merge; None is its own bucket.
• §5.2 §3.7.3 — Tenant derivation runs per ResourceLogs, not per export batch.
• §5.3 RFC0001.9 — body_kind = Structured short-circuits to a structured-template id (locks the §6.2 step-0 fork).
• §5.3 RFC0001.10 — time_unix_nano preserved verbatim from the wire (gates docs/benchmarks.md B1).
• §5.3 RFC0001.11 — severity_number = 0 and scope_name = None are distinct key buckets.

Scenario IDs follow the H<n>.<m> / §3.<n>.<m> / RFC0001.<m> grammar already specified in docs/rfcs/README.md.

Invariant / hazard touch

• H1 (template-merge correctness): H1.4 and H1.5 lock the new severity/scope discrimination — without them a future widening could silently coalesce across severity levels or scopes.
• §3.7 (multi-tenancy not bolted on): §3.7.3 closes the per-ResourceLogs derivation rule; previously §3.7 only had cross-tenant scenarios at the cluster level.

H3 / §3.4 (WAL-before-ack) intentionally not added to RFC 0001's hazards-in-scope: the miner crate does not enforce H3 — RFC 0003 §6.5 (receiver) and the future ourios-wal RFC do.

Test plan

• mdbook build clean locally
• CI green
• No code change — §6.x design content unchanged; only §5 normative scenarios added

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates RFC 0001’s §5 acceptance criteria to cover miner-side commitments introduced by the OTLP alignment work (severity/scope in the template key, structured-body short-circuit, per-ResourceLogs tenancy fan-out, and timestamp carry-through).

Changes:

• Add hazard scenarios ensuring severity_number and scope_name participate in the template key (preventing silent cross-bucket merges).
• Add an invariant scenario pinning tenant derivation to per-ResourceLogs semantics (not per export batch).
• Add RFC-internal scenarios for the structured-body fork, verbatim time_unix_nano preservation, and edge buckets (severity_number=0, scope_name=None).

Comments suppressed due to low confidence (1)

docs/rfcs/0001-template-miner.md:577

• Scenarios RFC0001.9–RFC0001.11 add new acceptance-criteria ids, but there are no matching test stubs yet (e.g. crates/ourios-miner/tests/rfc_internal.rs currently stops at RFC0001.8). To preserve the documented grep -R "RFC0001.9" . bidirectional mapping (RFC §5 preface / docs/verification.md §2.3), please add ignored test stubs for RFC0001.9–.11 (and update the §8 testing-strategy coverage lists accordingly).

> **Scenario RFC0001.9 — `body_kind = Structured` short-circuits to a structured-template id**
> - **Given** an `OtlpLogRecord` whose `body` is `AnyValue::Kvlist`
>   (or any non-`String` `AnyValue` variant)
> - **When** the record is ingested
> - **Then** the §6.2 algorithm skips tokenize/mask/descend per
>   step 0 and allocates or reuses the structured-template id
>   for `(severity_number, scope_name, BodyKind::Structured)`
> - **And** the emitted record has `body_kind = Structured`
> - **And** the `body` column carries the OTLP-canonical JSON
>   encoding produced upstream per RFC 0003 §6.4
> - **And** `params` and `separators` are empty

---

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