@@ -24,6 +24,11 @@ are released independently from this monorepo.
 
 ### Firmware 0.6.0 source integration
 
+- Abandoned the unpublished local `firmware-v0.6.0` candidate at `719b211…`
+  after the C3 stateless-PHY/post-OI receipt and fixed performance-contract
+  amendments. Version 0.6.0 and its atomic five-profile scope are retained for
+  a source-era-routed replacement; all candidate/HIL gates restart before any
+  tag is pushed or release is published.
 - Added the `rpi-pico2-w` portable frozen-Python agent port, its isolated RP2
   build plane, and pinned Arm GNU toolchain input alongside the four existing
   ESP build variants.
 
@@ -0,0 +1,91 @@
+# ADR-0037 — Use fixed profile reset and product-wide transfer SLOs
+
+- Status: **Accepted**
+- Date: 2026-08-20
+- Supersedes: ADR-0026 decision items 1–2 for replacement-v0.6.0
+  reset qualification, and ADR-0025 decision items 4 and 6 for
+  replacement-v0.6.0 goodput qualification
+- Preserves: historical derivation revisions and immutable baseline evidence
+
+## Context
+
+The five-profile v0.6.0 baseline retained at
+`docs/validation/firmware/oi1/a8be631df46590166307aa41afaea30b39e29230.json`
+is valid engineering evidence, but it exposed two product-contract problems.
+First, Pico 2 W has a materially different reset path from the four ESP
+profiles. Its pinned upstream BTstack controller initialization normally needs
+a 5–6 second allowance; applying the ESP 3-second discovery SLO to that path is
+not a truthful cross-port requirement. Second, deriving each transfer floor as
+95% of one profile's minimum baseline sample turns a product-usability bound
+into five candidate-fitted regression thresholds.
+
+The retained baseline diagnoses feasibility without selecting either new
+value. Its ESP reset maxima are 1,828, 1,187, 1,594, and 1,167 ms, while the
+Pico maximum is 3,378 ms. Its minimum PUT values are 6,870, 13,740, 13,656,
+16,180, and 12,854 bytes/s; its minimum GET values are 13,240, 20,787, 25,654,
+28,716, and 7,181 bytes/s. The product decision must remain independent of
+those extrema so a failed qualification run can never fit or relax its own
+gate.
+
+## Decision
+
+For the replacement v0.6.0 source era defined by ADR-0038:
+
+1. Reset-to-service-advertisement remains the exact same end-to-end metric:
+   controlled reset/power release to the first fresh host scanner callback
+   containing the exact PyBLE service UUID.
+2. `reset_to_service_advertisement_max_ms` is exactly `3000` for
+   `esp32-4mb`, `esp32-s3-n16r8`, `waveshare-esp32-s3-lcd-147b`, and
+   `esp32-c3-4mb`, and exactly `7000` for `rpi-pico2-w`. The derivation
+   identifier is
+   `fixed-profile-product-slo-esp3000-pico7000-v4`.
+3. Pico's 7-second bound is independently budgeted from the pinned upstream
+   BTstack's normal 5–6 second controller-initialization allowance plus one
+   fixed second for service-advertisement acquisition and host callback
+   delivery. It is not derived from the 3,378 ms observation and MUST NOT be
+   widened again after a failure.
+4. Every profile still records exactly 10 reset samples. All 10 must pass its
+   profile ceiling; no sample is trimmed, replaced, retried, or selectively
+   rerun. The scanner-before-reset ordering, exact-service match, HELLO after
+   every sample, 15,000 ms hard health timeout, and separate physical
+   power-cycle advertisement check remain exact.
+5. Both committed PUT and verified GET use the fixed product-wide floor
+   `6600` bytes/s on all five profiles. Its derivation identifier is
+   `fixed-product-slo-64k-under-10s-6600-v3`.
+6. The arithmetic is exactly
+   `ceil_100(65536 bytes / 10 seconds) = ceil_100(6553.6) = 6600` bytes/s.
+   Because reported goodput is the integer
+   `floor(65536 * 10^9 / duration_ns)`, the largest passing duration is
+   `9,929,696,969 ns` (approximately `9.9297 s`), not a rounded 10 seconds.
+7. Exactly five PUT and five GET samples remain mandatory per profile. Every
+   sample must meet 6,600 bytes/s with no retry or replacement. The exact
+   65,536-byte unique-byte counts, duration arithmetic, byte/size/CRC and
+   offset integrity, required ATT MTU/window/chunk, settled link facts,
+   retransmit/rewind accounting, reliability totals, zero unexpected
+   disconnects, and physical check receive no allowance.
+8. Reset and transfer baseline samples remain immutable diagnostic evidence;
+   neither contributes arithmetic to these product SLOs. Static image and
+   headroom thresholds remain exact, and heap floors retain
+   `floor-min-1024-v1` baseline derivation. The retained `a8be631…` baseline
+   is rederived under the bound policy/candidate source era; its own
+   `source_commit` never selects the derivation revision.
+9. A candidate or verify run that crosses either fixed SLO fails. Its values
+   MUST NOT be used to rederive, fit, trim, or relax the policy; changing a
+   product SLO requires another spec-first ADR and fresh qualification.
+10. Historical source eras retain their exact derivation objects and
+    arithmetic. In particular, the earlier unpublished v0.6.0 source era
+    remains reproducible with `fixed-product-slo-3000-v3` and
+    `floor-95pct-min-100-v2`; it does not silently inherit this decision.
+
+## Consequences
+
+- Reset qualification reflects the real controller startup class of each port
+  while keeping one exact host-visible endpoint and strict sample discipline.
+- PUT and GET now express the minimum usable 64 KiB product transaction rather
+  than the performance of the baseline used to exercise a particular build.
+- The active five-profile policy must replace both derivation identifiers and
+  atomically set four ESP reset ceilings to 3,000, Pico's to 7,000, and all ten
+  transfer floors to 6,600 before a replacement candidate is built.
+- The immutable `a8be631…` baseline is retained unchanged. It supplies the
+  unchanged static/heap inputs and diagnostic performance samples, but is not
+  release approval and does not route its own derivation.
@@ -0,0 +1,85 @@
+# ADR-0038 — Replace the unpublished v0.6.0 candidate in place
+
+- Status: **Accepted**
+- Date: 2026-08-20
+- Builds on: ADR-0033 and ADR-0037
+- Last superseded-source commit:
+  `5620f2fdc672b440548119e3431cfa4f4ed3f5a3`
+
+## Context
+
+The local annotated tag `firmware-v0.6.0` has tag-object identity
+`d86eb6473a8d0269479061f03cd4a7b48bc8dabe` and peels to candidate source
+`719b211345028e49aee9df9b11c4b5fd110913de`. It was created before the
+stateless C3 PHY-calibration and post-OI NVS-receipt increments and before the
+fixed SLO decision in ADR-0037.
+
+A pre-publication audit on 2026-08-20 found no
+`refs/tags/firmware-v0.6.0` at `origin`, no GitHub Release for that tag, and a
+not-found response at the canonical
+`https://pyble.dev/firmware/v0.6.0/release.json` path. The local tag and its
+candidate were therefore never a public release identity. Advancing to 0.6.1
+would imply that users could possess a published 0.6.0 contract when no such
+release exists, while silently applying new derivations to every source whose
+embedded SemVer is 0.6.0 would destroy historical reproducibility.
+
+## Decision
+
+1. Keep the replacement release version and agent version exactly `0.6.0` and
+   keep the atomic ADR-0033 five-profile order. This decision changes neither
+   release schema 4, policy schema 3, baseline schema 2, nor HIL schema 5.
+2. The old local `firmware-v0.6.0` tag and candidate at `719b211…` are
+   abandoned and unpublished. They MUST NOT be pushed, mirrored, activated,
+   described as released, or used as the replacement release provenance.
+3. The superseded unpublished source era ends at and includes
+   `5620f2fdc672b440548119e3431cfa4f4ed3f5a3`. The replacement v0.6.0 source
+   era contains only strict descendants of that commit. Release tooling MUST
+   select the derivation contract from the bound policy/candidate source
+   commit's ancestry, not from SemVer alone, the baseline's `source_commit`,
+   or the validator checkout.
+4. A v0.6.0 source at or before that boundary retains the historical
+   derivation object with `fixed-product-slo-3000-v3` and
+   `floor-95pct-min-100-v2`. A replacement-era v0.6.0 source requires
+   ADR-0037's `fixed-profile-product-slo-esp3000-pico7000-v4` and
+   `fixed-product-slo-64k-under-10s-6600-v3`. Unknown, unrelated, or
+   ancestry-unprovable 0.6.0 source identity fails closed.
+5. Every old candidate bundle, artifact, protected-deployment result, and HIL
+   observation bound to `719b211…` or any other source through the boundary is
+   invalid for replacement qualification. No old pass, candidate digest,
+   artifact digest, or physical-result lineage may be relabelled or carried
+   into the replacement.
+6. Retained metadata and engineering evidence are not deleted or rewritten.
+   The old tag-object and peeled-source identities, candidate digests where
+   retained, prior derivation revision, and superseded status remain
+   auditable. The immutable
+   `docs/validation/firmware/oi1/a8be631df46590166307aa41afaea30b39e29230.json`
+   baseline remains byte-for-byte evidence. Its static/heap inputs are
+   rederived under the replacement policy/candidate source era and its
+   reset/goodput samples remain diagnostic; the baseline source identity never
+   routes the derivation and the baseline does not qualify either candidate.
+7. Source/docs/RED/GREEN work first updates the checked-in policy to ADR-0037.
+   The replacement source then passes its clean build, two-root
+   reproducibility, license, source, and audit gates before any tag or audited
+   candidate is created.
+8. Candidate provenance requires an annotated `firmware-v0.6.0` tag which
+   peels to candidate `HEAD`. After the pre-candidate gates in item 7 pass, the
+   old local unpublished tag may be replaced with that audited source identity
+   and the audited candidate may be created. Superseded tag-object/source and
+   candidate metadata MUST already be retained. The tag MUST NOT be pushed,
+   mirrored, published, or activated at this stage.
+9. The tagged candidate then requires fresh protected deployment, verify-mode
+   HIL on all five profiles, C3/Pico private gates, both-platform app HIL,
+   install/recovery, finalization, and public validation. Only after those
+   gates pass may the replacement tag and exact bytes be considered for origin
+   push, canonical website publication, optional mirror, or activation.
+
+## Consequences
+
+- Users see the intended first public 0.6.0 instead of an artificial 0.6.1
+  created solely to replace private bytes.
+- Two source eras can share SemVer without sharing qualification arithmetic;
+  retained earlier evidence remains mechanically reproducible.
+- The existing local tag cannot authorize shortcuts. The replacement is
+  release-blocking until fresh exact-byte gates pass on all five profiles.
+- No tag, candidate, build, hardware run, or publication action is performed
+  by this decision itself.
@@ -40,5 +40,7 @@ Each ADR captures one significant decision: its context, the choice, and the con
 | [0034](0034-read-waveshare-link-facts-through-run.md) | Read bounded, session-bound Waveshare qualification link facts through existing PBLE/1 RUN without a UART dependency or new wire surface | Accepted |
 | [0035](0035-read-c3-link-facts-through-run.md) | Read bounded, session-bound C3 qualification link facts through existing PBLE/1 RUN while retaining WCH only as the reset adapter | Accepted |
 | [0036](0036-read-generic-s3-link-facts-through-run.md) | Read bounded, session-bound generic S3 qualification link facts through existing PBLE/1 RUN while retaining serial only as the reset adapter | Accepted |
+| [0037](0037-fixed-profile-reset-and-transfer-product-slos.md) | Use fixed ESP/Pico reset ceilings and one product-wide 64 KiB PUT/GET floor for replacement-v0.6.0 qualification | Accepted |
+| [0038](0038-replace-unpublished-v060-candidate-in-place.md) | Replace the unpublished local v0.6.0 candidate in place while routing qualification by source era rather than SemVer alone | Accepted |
 
-Decided 2026-06-30 (0001–0005); 0006 accepted 2026-07-01; 0007, 0008, 0009 and 0010 accepted 2026-07-02; 0011 accepted 2026-07-03; 0012 accepted 2026-07-25; 0013 accepted 2026-07-27; 0014, 0015, 0016, and 0017 accepted 2026-07-28; 0018–0022 accepted 2026-07-29; 0023 and 0024 accepted 2026-08-01; 0025 and 0026 accepted 2026-08-02; 0027–0029 accepted 2026-08-03; 0030 accepted 2026-08-11; 0031–0033 accepted 2026-08-12; 0034 accepted 2026-08-13; 0035 and 0036 accepted 2026-08-16.
+Decided 2026-06-30 (0001–0005); 0006 accepted 2026-07-01; 0007, 0008, 0009 and 0010 accepted 2026-07-02; 0011 accepted 2026-07-03; 0012 accepted 2026-07-25; 0013 accepted 2026-07-27; 0014, 0015, 0016, and 0017 accepted 2026-07-28; 0018–0022 accepted 2026-07-29; 0023 and 0024 accepted 2026-08-01; 0025 and 0026 accepted 2026-08-02; 0027–0029 accepted 2026-08-03; 0030 accepted 2026-08-11; 0031–0033 accepted 2026-08-12; 0034 accepted 2026-08-13; 0035 and 0036 accepted 2026-08-16; 0037 and 0038 accepted 2026-08-20.
@@ -1,6 +1,6 @@
 # PyBLE — Agent Firmware
 
-Status: **DRAFT** · Last updated: 2026-08-12
+Status: **DRAFT** · Last updated: 2026-08-20
 
 The PyBLE agent is small board-side firmware that turns a compatible
 MicroPython target into a PyBLE-speaking board: it advertises the BLE service,
@@ -108,6 +108,18 @@ two-clean-build reproducibility, license audit, resource policy, exact-byte
 HIL, both-platform app HIL, install/recovery, and copy-on-write finalization
 remain required for all five profiles before activation.
 
+ADR-0038 replaces the unpublished local candidate tagged at `719b211…` in
+place: no origin tag, GitHub Release, or canonical v0.6.0 website release ever
+existed, so the first public version remains `0.6.0`. The predecessor source
+era ends at inclusive commit `5620f2f…`; only strict descendants use the
+ADR-0037 fixed-SLO contract. All old candidate bytes and HIL are invalid for
+the replacement, while superseded metadata and immutable baseline evidence
+remain retained. After source/docs/RED/GREEN, build, reproducibility, license,
+source, and audit gates pass, the local tag may be replaced so it peels to
+candidate `HEAD`; audited candidate creation then precedes fresh HIL and
+finalization. Push, publication, and activation remain forbidden until those
+later gates pass.
+
 The ESP32-C3-MINI-1-N4 v0.4/4 MiB/no-PSRAM reference and its still-pending
 C3-G0…C3-G6 gates remain frozen in
 [firmware/ports/esp32-c3-4mb.md](firmware/ports/esp32-c3-4mb.md). C3 enters
@@ -452,27 +464,29 @@ internal-heap gate. Total application-image size is the normative flash
 quantity; an “agent-only overhead” requires a matched no-agent control build
 and is supplemental only.
 
-Thresholds are never fitted to a candidate run: heap floors round the minimum
-of the frozen sample set outward to 1 KiB; reset-to-advertisement uses the
-fixed 3,000 ms end-to-end product SLO; and goodput floors apply the exact
-integer 5% host/radio repeatability allowance before rounding outward to 100
-bytes/s. The reset metric ends at a host scanner callback, so it is a
-user-visible discovery SLO rather than a tight firmware boot-regression
-statistic. Static image/headroom quantities remain exact, and
-integrity/reliability assertions receive no allowance. The engineering
-baseline derives the remaining committed policy values; only hash-locked
-final-candidate HIL qualifies a release. The v0.6.0 policy derives five
-independent rows; C3 and Pico remain pending rather than deferred or inferred
-from another target.
-
-The sole permitted cross-commit physical-fact lineage is specified by
-[browser-flashing.md](firmware/browser-flashing.md): it may reuse only the
+Thresholds are never fitted to a candidate run. For replacement v0.6.0, heap
+floors alone round the minimum of the frozen sample set outward to 1 KiB;
+static image/headroom remains exact. Reset-to-advertisement is fixed at 3,000
+ms for each ESP profile and 7,000 ms for Pico, and both PUT and GET are fixed
+at 6,600 bytes/s for every profile. The reset metric ends at the same fresh
+exact-service host scanner callback. Exactly 10 reset and five PUT/five GET
+samples must all pass their fixed SLO with no trim or retry; the 15-second
+health timeout, physical cycle, integrity, reliability, duration arithmetic,
+and link facts remain exact. The engineering baseline retains reset/goodput
+samples diagnostically but derives only static and heap values. Only fresh
+hash-locked final-candidate HIL qualifies the replacement. Historical source
+eras retain their V3/V2 derivation arithmetic.
+
+The predecessor source-era cross-commit physical-fact lineage is specified by
+[browser-flashing.md](firmware/browser-flashing.md): it could reuse only the
 retained baseline's passed physical-power-cycle boolean when all shipped bytes
 are identical. Every quantitative and automatic OI field still comes from a
 fresh hash-bound final-candidate run, the record explicitly claims no new
 physical observation, and every app, operator, private, and profile gate
 remains mandatory. No complete baseline row may be relabelled as final-candidate
 verification.
+ADR-0038 invalidates that predecessor lineage for replacement v0.6.0; every
+replacement profile requires a fresh exact physical power-cycle check.
 
 Fresh Waveshare and Pico reset arrays use PBLE RUN of `machine.reset()`, the
 expected link drop, and the following fresh advertisement. That automatic
@@ -481,7 +495,9 @@ not enlarge the one-field lineage scope.
 
 Published v0.4.2 metadata and HIL evidence retain their historical exact
 two-profile contract. The unqualified v0.5.1 source candidate retains its
-three-profile source-era contract. Neither is expanded or reinterpreted as the
-v0.6.0 five-profile matrix.
+three-profile source-era contract. The predecessor unpublished v0.6.0 source
+also retains its V3/V2 derivation for replay, but its candidate/HIL cannot
+qualify the replacement. None is expanded or reinterpreted as replacement
+v0.6.0 evidence.
 
 <!-- SPDX-License-Identifier: MIT -->