Record decision 32: resolve #54 (independent versioning, computed-at-cutover target)

docs/decision-log.md

@@ -72,6 +72,8 @@ Traverse (the runtime) already had an in-repo registry engine (`crates/traverse-
 
 31. **Discovery, not a decision: `traverse-registry` 0.8.1 already published from `traverse`'s own repo before this repo's spec-010 placeholder, invalidating the `0.8.0` real-publish target; resolution deferred to the repo owner via #54 (2026-07-18)**: closing out #50 (decision 29's publish-pipeline prerequisite), the `v0.0.1` tag push succeeded and `traverse-registry` 0.0.1 published to crates.io as planned. Checking the full crates.io version history immediately after turned up `0.8.1`, published **8 hours earlier** (2026-07-18T07:38 UTC vs. this repo's 15:23 UTC), from a `push v0.8.1` tag event in `traverse-framework/traverse` itself — real, functional code straight from `traverse`'s own `crates/traverse-registry/` (dependencies on `traverse-contracts`, `semver`, `serde`, `sha2`), confirmed via that repo's Actions history and entirely unrelated to this repo's spec-010 work. Root cause: `traverse-registry` has always been one of the seven crates `traverse`'s own `publish_crates.sh` ships on every release — its publish had simply never succeeded before because `traverse` itself lacked `CARGO_REGISTRY_TOKEN`, until `traverse#741` granted it that same morning. **Why this isn't just a name-squatting non-event**: the name itself was never at risk of leaving the org (same publishing account both times), but spec 010's plan (decision 29d/e/f) assumed a placeholder-then-`0.8.0` sequencing where the eventual registry-governed publish becomes the crate's *resolved default* — that assumption is now broken, because `0.8.0 < 0.8.1`, so a future `0.8.0` publish here would never outrank the `traverse`-sourced `0.8.1` for a plain `cargo add traverse-registry`. It is also not a one-time collision: `crates/traverse-registry/` still lives in `traverse` and will keep being published there on every subsequent `traverse` release, now that its token works, for as long as #9's cutover hasn't landed — the risk window spec 010 tried to close in one move is actually open-ended. **Decision**: this entry records the discovery only; it does not resolve it. Per this repo's cross-repo-and-spec-immutability guardrails (decisions 26/28's precedent — an agent scopes and surfaces a cross-repo/security-adjacent problem but doesn't execute the fix), no crates.io action was taken (`0.8.1` was left un-yanked), spec 010's approved/immutable FR-006 was not edited in place, and a new tracking issue (**#54**) was opened instead to carry the actual version-strategy decision, which needs the repo owner's explicit call and likely `traverse`-side coordination. #9's Definition of Done (`=0.8.0` / `0.8.0` targets) and `traverse#627`'s matching DoD line are both now known-stale pending #54.
 
+32. **#54 resolved: `traverse-registry` goes independently versioned; real-publish version computed at cutover time, not hardcoded; `traverse#627`'s atomic-removal staging (decision 29e) reaffirmed unchanged (2026-07-18, `/brainstorm` continuation of entry 31)**: entry 31 recorded the `0.8.1` collision discovery without resolving it. Five questions, decided one at a time, with one self-correction mid-session. (a) **stop the ongoing bleed early?** — first leaned yes (ask whoever owns `traverse`'s release process to drop `traverse-registry` from `publish_crates.sh` immediately, freezing the floor at `0.8.1`), but reading `traverse#627`'s existing body (already independently carrying this exact discovery, apparently found the same day on that side) showed the removal is already a DoD item there — scoped to land atomically with the full crate-move cutover PR, per decision 29e's explicit "not staged" call. **Corrected to: no standalone early drop.** Reopening a deliberate prior staging decision needs a stronger reason than a second session preferring it sooner; the bleed is real but bounded (#9 is still upstream-blocked, cutover isn't imminent), and decision 29e's reasoning (avoid feature-flagging complexity for a failure mode nothing new) still holds. (b) **future versioning scheme** — independent, not lockstep with `traverse`'s workspace version: this repo now owns the crate's releases and its own PR/CI gate, and tying every future registry-side patch to `traverse`'s own version bumps is an awkward fit for a separately-governed repo. (c) **target version for the real extraction publish** — first landed on a hardcoded `0.9.0` (next-minor-above-the-then-current-floor, assuming (a)'s early freeze), but (a)'s reversal reopened this: without an early freeze, `traverse` can keep shipping `traverse-registry` releases right up to cutover, so any number picked today could itself be stale by execution time, the same failure mode that just invalidated `0.8.0`. **Corrected to: computed at cutover execution time** — whoever executes #9 checks `traverse-registry`'s actual highest published version at that moment and targets the next minor above it, not a number decided in advance. `traverse`'s own consumption keeps pinning exact (decision 29f unchanged), just to whatever that computed number turns out to be instead of a stale literal. (d) **this repo's `0.0.1` placeholder** — left un-yanked; it's harmless (nothing depends on it, cargo already resolves past it), and yanking is a visible, semi-irreversible action for no practical benefit over the honest version-history record. (e) **spec 010's stale `FR-006`** — no new/amending spec drafted. Its substantive requirement (same workflow/trigger/gate sequence, zero pipeline changes at content-move time) still holds; only the illustrative `0.8.0` figure was wrong, and that figure isn't itself CI-gated (spec-alignment checks path coverage, not FR literal text) — this decision-log entry plus the DoD text in #9/`traverse#627` carry the correction, consistent with this repo's "spec wins over the log on substance, not on illustrative numbers" reading. **Consequence**: no new `traverse`-side ticket was opened (superseded by (a)'s reversal — `traverse#627` already tracks the real fix correctly); that issue's body was instead corrected in place: its "cosmetic only, no action needed" framing understated the risk (true only for `traverse`'s own exact-pinned consumption, not for a plain `cargo add traverse-registry` from any other consumer, which would silently get the un-governed `traverse`-sourced release) and its `=0.8.0` DoD lines were replaced with the compute-at-cutover instruction. #9's DoD was updated the same way. #54 is closed as resolved by this entry.
+
 ## What Was Explicitly Deferred, Not Decided
 
 - ~~The exact schema field names/types for `owner`/`namespace` (reserved conceptually, not yet finalized in code)~~ — finalized 2026-07-06 in `specs/006-public-scope-and-identity` (Draft): `namespace` = string equal to the path segment; `owner` = the `traverse-contracts` `Owner` object shape