<:robot:> DM-4 and DM-6 were scoped by reading [`gitlab-org/labkit` v2](https://gitlab.com/gitlab-org/labkit/-/tree/df307e038980743f2e50a83cf718b1de2b50f352/v2) and checking what bench's schema could and couldn't express against it. Every gap, acceptance criterion, and "LabKit already covers this" judgment in both epics rests on the Go implementation. bench is **language-matched**: a Go chassis over labkit-go, a Rust chassis over [labkit-rs](https://gitlab.com/gitlab-org/rust/labkit-rs). Per [Theseus ADR 007](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19702) library capabilities are native to LabKit in both languages, and bench composes rather than reimplements. So "LabKit covers this" is only true if it's true in both. An audit at labkit-rs `c5358299` found it isn't, in both directions. ## The asymmetry runs both ways **Rust is behind on the chassis data layer.** No Postgres, Redis, object storage, secret-provider, or infrastructure-contract module exists — verified by reading the tree, with zero hits for `/etc/labkit`. There is also no application lifecycle model: no `app.Component` equivalent, no ordered startup or shutdown, no graceful drain. A generated Rust service hand-rolls its own `main()` orchestration, which is the opposite of what a chassis is for. **Rust is ahead on observability, including things Go lacks entirely.** `labkit/src/http/metrics_layer.rs` (`HttpMetricsLayer`) and `labkit/src/grpc/metrics_layer.rs` (`GrpcMetricsLayer`) emit OTel semantic-convention RED instruments — `http.server.request.duration`, `http.server.active_requests`, `rpc.server.duration`, and more — with configurable histogram buckets. Go emits request metrics for **neither** direction, which is what [bench#73](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/73) and [bench#79](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/79) exist to fix. That inverts an assumption in bench#73. It was written as "build Go inbound RED metrics." It should be "adopt the instrument contract Rust already ships," or the two chassis will emit differently-named measurements for the same thing and no dashboard will overlay them. Rust also has an outbound gRPC client with correlation propagation (`GrpcClientCorrelationLayer`), where Go's `v2/grpcserver` is four files of interceptors with no client at all — directly relevant to [bench#77](https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/77). ## One finding that shouldn't wait for a scoping decision `labkit/src/access_log_layer.rs` logs `request.uri()` verbatim. Go's `v2/httpserver/mask.go` replaces sensitive query parameters with `[FILTERED]`. The generated cross-language field contract (`labkit-fields/src/lib.rs`) documents `HTTP_URI` as masked. So a Rust chassis service writes `?private_token=` and `?password=` into its access logs today, and the shared spec says it doesn't. The port is pre-specified in labkit-rs's own plan doc, pattern list included. This is an upstream labkit-rs bug rather than bench work, but bench would be generating services that hit it. **Worth filing upstream immediately rather than carrying as a parity line item.** ## Scope Establish a Rust verification path so Phase 1's gap analysis is known-good in both languages, and record what it finds. - Re-check each DM-4 and DM-6 "LabKit covers this" claim against labkit-rs, not just labkit-go - For each Phase 1 acceptance criterion naming a LabKit module, confirm a Rust counterpart exists or mark the criterion Go-only with a filed Rust gap - File the access-log redaction finding upstream in labkit-rs - Reconcile bench#73's instrument naming with labkit-rs's existing layers before Go implementation starts - Decide, for each capability Rust lacks, whether bench blocks on upstream, generates a shim, or declares the Rust chassis unsupported for that backend ### On labkit-spec [labkit-spec](https://gitlab.com/gitlab-org/quality/tooling/labkit-spec) is the right mechanism with the wrong coverage today. Its `conformance/` harness runs three SDK servers against identical requests and asserts three-way parity, and `serverConfigs[].capabilities` in `conformance/aspects.go` is a genuine machine-readable capability matrix — it already records Rust missing `ratelimit`, and its own comments independently confirm the lifecycle gap. But it covers only logging, lifecycle, and rate limiting. There is no aspect for postgres, secret, TLS, metrics, or HTTP client; the README lists those as planned. **A green conformance run is not evidence of chassis parity.** Adding an aspect is three steps by design, so the cheaper long-term play is contributing aspects for the capabilities bench depends on rather than maintaining a bench-side parity matrix that drifts. Worth deciding which. ## Acceptance criteria - [ ] Every DM-4 and DM-6 acceptance criterion referencing a LabKit module is marked verified-both, Go-only, or Rust-only - [ ] Each Rust gap blocking a Phase 1 criterion has an upstream labkit-rs issue - [ ] The access-log redaction finding is filed upstream in labkit-rs, with the plan-doc reference - [ ] bench#73's instrument names, units, and label keys are reconciled against `HttpMetricsLayer` and `GrpcMetricsLayer`, or the divergence is recorded with a reason - [ ] A decision exists on whether bench contributes conformance aspects to labkit-spec or maintains its own matrix - [ ] The audit is re-runnable: whatever produced it is written down, not re-derived by hand next time Part of [DM-6: Phase 1 Outbound](https://gitlab.com/groups/gitlab-org/lab-bench/-/epics/3), though the findings affect [DM-4](https://gitlab.com/groups/gitlab-org/lab-bench/-/epics/4) equally. </:robot:>