Extract traverse-registry crate + governing specs from traverse into this repo

[enricopiovesan]

Summary

Move crates/traverse-registry (and its governing specs 005, 007, 011, 034, 035, 036, 037, 039, 041, 043) from traverse-framework/traverse into this repo, per the migration record in traverse repo's specs/051-registry-extraction/spec.md.

Governing Spec

• traverse-framework/traverse's 051-registry-extraction (approved 2026-07-04)

Depends on

• traverse-framework/traverse PR #520 (drafts spec 051) -- merged.
• Spec 051 approval (moved into traverse's approved-specs.json) -- done, via traverse PR #529.
• Cargo scaffold + publish CI pipeline for traverse-registry crate (reserve crates.io name) #50 -- Cargo scaffold + publish CI pipeline -- done (Add Cargo scaffold + publish CI pipeline for traverse-registry crate #52, 2026-07-18): placeholder traverse-registry 0.0.1 package + tag-triggered publish pipeline landed, governed by specs/010-crate-publish-pipeline. Registry-content governance for the real move also landed (specs/011-capability-registry-adoption, 012-event-registry-adoption, 013-inherited-registry-governance -- PR spec: adopt registry-content specs (011, 012) + blanket coverage (013) #53).
• CARGO_REGISTRY_TOKEN grant + v0.0.1 publish -- done (2026-07-18).
• Version-strategy decision (#54) -- done (2026-07-18, decision-log entry 32): see "Version target" below.

Current status (2026-07-18)

Both collision-risk PRs (traverse#619, traverse#626) merged -- the resume condition from decision-log entry 26 is satisfied. The publish-pipeline prerequisite (#50) and its content-governance follow-up are both done. #54 resolved the version-collision question discovered while closing #50 (decision-log entry 31): traverse-registry 0.8.1 was already published directly from traverse's own release pipeline, invalidating the originally-planned 0.8.0 target.

Version target (decision-log entry 32, supersedes the earlier 0.8.0 plan): traverse-registry goes independently versioned going forward (not lockstep with traverse's workspace version). The real publish version is computed at execution time, not hardcoded: check traverse-registry's actual highest published version on crates.io when this cutover PR is actually opened, and target the next minor above it. traverse#627's plan to remove traverse-registry from publish_crates.sh atomically with the cutover PR (not staged/early) is unchanged.

Traverse-side execution work is tracked at traverse-framework/traverse#627. Per decision-log entry 26, execution here stays registry-scope only: spec re-adoption/governance. The traverse-side crate move/Cargo.toml rewiring/test verification is explicitly not done by the agent operating this repo.

Definition of Done

• crates/traverse-registry source moved here with a fresh-start snapshot (no imported git history -- traverse's own git log preserves it permanently; see decision-log entry 29) (tracked in traverse#627)
• Specs 005/011-capability-registry (as 011-capability-registry-adoption) and 011/event-registry (as 012-event-registry-adoption) re-adopted verbatim
• The remaining 19 traverse specs that also govern crates/traverse-registry/ are blanket-covered by 013-inherited-registry-governance rather than individually re-adopted (decision-log entry 30 -- they weren't registry-exclusive and don't split cleanly)
• traverse repo's Cargo.toml updated to depend on the externally-published traverse-registry crate, pinned exact to whatever version is computed at execution time per decision-log entry 32 (traverse#627) -- not 0.8.0, that target is stale
• traverse repo's specs/governance/approved-specs.json updated to remove now-inapplicable crates/traverse-registry/ governs entries (traverse#627)
• Existing traverse-registry test suite passes unchanged in the new location (traverse#627)
• traverse's spec-alignment and repository-checks CI both pass after the crate removal (traverse#627)
• The real crate publishes at the version computed per decision-log entry 32 (next minor above traverse-registry's highest published version at execution time), directly over the 0.0.1 placeholder

Validation

• To be defined in the implementation spec slice; must include a dry-run showing traverse's CI is green with the crate removed and the external dependency wired in

[enricopiovesan]

Status check (2026-07-15, via /registry-ops): the two live blockers named in decision-log entry 26 have both merged — traverse#619 (2026-07-12) and traverse#626 (2026-07-12).

Per decision 26(d)/(g), the next step is a new tracking issue in traverse-framework/traverse for the crate-move/Cargo.toml rewiring/test verification work, and this registry-side spec re-adoption stays sequenced behind that tracking issue's resolution (26f) — not fired just because these two PRs cleared.

Per the registry-scope-only rule, opening or acting on that traverse-side tracking issue is out of this agent's lane (writes to traverse-framework/traverse are out of scope; reading for context is fine). Leaving #9 as Blocked — needs the repo owner or the traverse-ops lane to open that tracking issue before this can resume.

[enricopiovesan]

Correction to yesterday's comment: the traverse-side tracking issue called for in decision 26(d) already exists — traverse#627 (opened 2026-07-12), still open. My prior comment saying "none currently exists" was stale; I hadn't checked Project 3's stray-item list, where it's currently sitting as Ready.

Per 26(f), #9 stays Blocked until traverse#627 resolves (crate physically present in this repo). No action needed here beyond continuing to wait — flagging for accuracy.