feat: transition cc-peer to session-peer and release 0.6.0 #48

Motivation

Rename the existing repository to abruption/session-peer and publish session-peer 0.6.0 with the Codex adapter in #44, preserving Git history and issues. Retire the old PyPI project through an explicit migration rather than silently replacing its CLI.

Does the official path already cover it?

GitHub repository rename preserves history and redirects. PyPI distributions and Trusted Publishers need separate configuration. Use those native mechanisms; retain the native Codex queue backend described in #44.

Proposed behaviour

• Prepare cc-peer 0.5.1 as a final standalone Claude-compatible migration release on maintenance/cc-peer.
• Rename the package/CLI to session-peer, use a neutral standalone installation directory, and retain a frozen cc_peer.py for old self-update URLs.
• Add local/SSH Codex discovery and queueing per feat: v0.6 roadmap — Codex discovery, addressing, queueing, and submission status #44; keep feat: v0.7 roadmap — doctor, reply waiting, reply URIs, and SSH return-route diagnostics #45–feat: post-v0.8 roadmap — extensible agent adapters and execution transports #47 for later releases.
• After tests and PRs, rename the repository, configure both PyPI publishers, publish session-peer 0.6.0, then cc-peer 0.5.1 with GitHub latest=false.
• Archive only the old PyPI project after verifying the new installation. Never archive the renamed GitHub repository or recreate its old name.

Acceptance criteria

• Legacy transition PR merged and maintenance branch preserved.
• Rebranding PR merged; standalone/pip installation, update and explicit migration tested.
• Codex feat: v0.6 roadmap — Codex discovery, addressing, queueing, and submission status #44 implemented and verified locally and over SSH; queued is not acknowledged.
• CI and distribution checks pass; no implicit wake, automatic migration or approval bypass.
• Repository renamed; session-peer publisher configured and publication verified.
• Existing cc-peer project publisher updated and final legacy PyPI upload verified.
• New and final legacy releases verified; old package archived only afterward.

Follow issue → branch → PR with Conventional Commits. Preserve existing user configuration and installations.

Execution status

• feat: prepare final cc-peer migration release #49, feat: rebrand distribution and standalone tooling as session-peer #50 and feat: add local and SSH Codex discovery and queueing #51 merged; 134 tests and all feature CI checks passed.
• Repository renamed to abruption/session-peer; history/issues preserved. maintenance/cc-peer retained.
• docs: prepare session-peer publication and legacy retirement #52 merged with publication instructions. session-peer 0.6.0 is published on GitHub and PyPI; clean registry installation, Codex list/dry-run and package-manager update handling passed.
• cc-peer v0.5.1 is published on GitHub and PyPI. After the owner re-registered the existing project's Publisher with environment=pypi, attempt 3 of run 34452732980 succeeded. The actual PyPI wheel was installed in the isolated verification environment alongside session-peer 0.6.0; both CLI versions and the legacy retirement/migration JSON passed. The earlier 403 is resolved.
• The owner archived the old PyPI cc-peer project after release verification. On 2026-09-10, a cache-busted PyPI Simple JSON response confirmed project-status=archived, with all six distributions (0.4.1, 0.5.0, 0.5.1 wheel/sdist) retained and not yanked. GitHub abruption/session-peer remains active (isArchived=false). Transition complete; feat: v0.7 roadmap — doctor, reply waiting, reply URIs, and SSH return-route diagnostics #45–feat: post-v0.8 roadmap — extensible agent adapters and execution transports #47 remain future work.
• GitHub latest remains v0.6.0; old raw update URL resolves to the exact frozen compatibility file. Installing both products in an isolated environment, then uninstalling cc-peer, preserved session-peer.
• Live Codex submissions were checked in both local and remote queues. Claude writes succeeded, but the user's weekly limit now prevents further receiving-turn/acknowledgement tests. Ontology document completion is not claimed.