P0: Execute evidence-gated public portfolio consolidation

[BunsDev]

Outcome

Turn the reviewed public repository dispositions in #7 into repository-local, evidence-backed migration and lifecycle work without breaking packages, releases, installers, links, provenance, or protected authority boundaries.

The connected organization currently exposes 30 public repositories as of 2026-09-03. The earlier audit's 44-repository inventory remains useful historical evidence, but live GitHub state and current owning-repository implementation evidence govern each action.

Safety boundary

This issue coordinates analysis and reversible migration work. It does not authorize repository deletion, transfer, archive, visibility change, publication, release, package takeover, credential revocation, or production deployment. Each such action requires explicit authorization, exact current-state revalidation, and an operation-specific receipt.

Initial disposition waves

Consolidate, then retire only after migration evidence

• claude-code-cast → non-duplicative adapter/redaction fixtures into coven-code.
• coven-codeflow → non-duplicative deterministic demos and workflow contracts into coven-code.
• coven-design-system → extract value across brand, ui, and coven-cave without retaining duplicate canonical authority.
• coven-github-webhook → private GitHub-delivery overlay, preserving the canonical delivery boundary.
• opencoven-chat-api → accurately named documentation/Cave ownership where current implementation evidence supports it.

Evaluate for private incubation, consolidation, graduation, or retirement

• coven-pocket, coven-reach, coven-scout, desktop-use, open-fable, and demo-workspace.
• opencoven-beta-august-hackathon-2026 for historical archival after its reference gate.

Retain historical archives unless evidence supports a later tombstone

• cast-codes.
• open-meow-sdk.

The list is a starting coordination set, not a substitute for inspecting each current repository.

Required per-repository procedure

1. Inspect the current default branch, scoped instructions, ADRs, packages, releases, workflows, issues, dependents, webhooks, Apps, domains, update feeds, installers, and external distribution references.
2. Identify the canonical successor and explicitly state what must not migrate because it duplicates or violates current ownership.
3. Preserve license, notices, tags, releases, issues, discussions, advisories, contributor history, and traceable extraction provenance.
4. Create repository-local migration issues/PRs with exact tests, consumer canaries, compatibility behavior, migration, and rollback.
5. Publish a successor/deprecation notice only when accurate.
6. Archive before deletion where appropriate and observe for broken downloads, inbound links, update requests, and new issues.
7. Revalidate live state immediately before any authorized lifecycle operation.
8. Update governance/repositories.json and generated views only through reviewed evidence-backed PRs.

Verification requirements

• code, docs, package, workflow, submodule, badge, domain, and webhook searches;
• npm/crates/PyPI/Maven/SwiftPM/Homebrew/container/download/update-feed checks as applicable;
• packaged-artifact and installer/update-channel tests where source checks are insufficient;
• immutable successor/canary references;
• before/after reference graph and zero-broken-reference evidence;
• rollback archive and recovery procedure;
• explicit representation of unknown, stale, unavailable, or private evidence.

Acceptance criteria

• Every targeted repository has a current repository-local evidence issue before migration begins.
• Every migration identifies one canonical destination or a bounded private incubation boundary.
• No duplicate canonical owner remains after an approved migration.
• Useful work is extracted with provenance rather than copied opaquely.
• Packages, releases, installers, update feeds, webhooks, domains, and evergreen links have explicit continuity decisions.
• Historical/security/legal records are preserved appropriately.
• Observation windows complete with no unexplained breakage.
• The public registry and live GitHub inventory reconcile after each authorized lifecycle action.
• No destructive or visibility-changing action is taken merely because the registry recommends it.
• The final portfolio review reports exact residual risks and does not use repository count alone as proof of readiness.

Sequencing

Blocked on review/merge of #7 for canonical schemas and procedure. Administrative protection in #6 should be completed before relying on registry changes as organization-level lifecycle gates.