dazzlecmd-lib repo extraction (subtree-split + own CI + PyPI namespace)

[djdarcy]

Summary

Extract dazzlecmd-lib from the dazzlecmd monorepo (packages/dazzlecmd-lib/) into its own GitHub repository at C:/code/dazzlecmd-lib/ (and github.com/DazzleTools/dazzlecmd-lib), with subtree-split preserving full commit history. This is the primary unblocker for PyPI release of the library.

Sub-issue of #27 (parent issue covers the full library-extraction scope; this sub-issue tracks the physical repo extraction specifically).

Motivation

dazzlecmd-lib exists as a Python package inside packages/dazzlecmd-lib/ of the dazzlecmd repo. As of v0.7.28 the library is functionally usable (wtf-windows v0.1.4-alpha imports it via tarball pin), but:

• The library has no separate test suite — all tests live in dazzlecmd's tests/ directory
• No separate CI — only dazzlecmd's .github/workflows/ runs; library doesn't validate independently
• No PyPI release — wtf pins via tarball at a specific dazzlecmd commit hash, not a SemVer release
• Version coupling is ad-hoc — library _version.py exists but bumps are interleaved with dazzlecmd commits
• No separate CHANGELOG — gap noted in the closeout audit

These constraints prevent the library from being a "truly standalone project" (user's stated 0.7.x-closeout objective).

Proposed solution

Three-step extraction (per notes/meta/2026-04-18__21-00-00__both_dazzlecmd-lib-repo-extraction-pypi-release.md):

Step 1 — Scaffold

# In a clean working tree:
cd C:/code/
mkdir dazzlecmd-lib
# Use /setup-github-project or repokit to bootstrap:
#   - GPL-3.0-or-later license
#   - GitHub Actions CI matrix (Python 3.10-3.13 × Windows/Linux/macOS)
#   - pyproject.toml with name = "dazzlecmd-lib"
#   - README.md (extracted from packages/dazzlecmd-lib/README.md)
#   - CHANGELOG.md (initial entry: v0.2.0 — extracted from monorepo)
#   - tests/ directory (initially empty; populated in Step 2)

Step 2 — Subtree split

# In the dazzlecmd repo:
git subtree split --prefix=packages/dazzlecmd-lib -b dazzlecmd-lib-extracted

# In the new dazzlecmd-lib repo:
git pull C:/code/dazzlecmd/github dazzlecmd-lib-extracted

This preserves all commits that touched packages/dazzlecmd-lib/ (~30+ commits since v0.7.13). Commits that touched both library and non-library files in the same commit will be partially preserved (subtree-split attributes per-file changes).

Step 3 — Update dazzlecmd to consume via submodule

# In dazzlecmd repo, replace packages/dazzlecmd-lib/ with submodule:
git rm -r packages/dazzlecmd-lib/
git submodule add https://github.com/DazzleTools/dazzlecmd-lib.git packages/dazzlecmd-lib
git submodule update --init --recursive

packages/dazzlecmd-lib/ becomes a submodule pointing at the extracted repo. Editable install (pip install -e packages/dazzlecmd-lib/) continues to work.

Acceptance criteria

• New GitHub repo: github.com/DazzleTools/dazzlecmd-lib (private until first release; public on v0.2.0 PyPI publish)
• Local clone at C:/code/dazzlecmd-lib/
• All commits touching packages/dazzlecmd-lib/ preserved in subtree-split history (verify count matches git log --oneline packages/dazzlecmd-lib/ | wc -l in monorepo)
• PyPI namespace registered: pip search dazzlecmd-lib resolves (no release yet)
• Own CI workflow: .github/workflows/test.yml runs pytest on Python 3.10/3.11/3.12/3.13 × Windows/Linux/macOS matrix
• CHANGELOG.md initial entry covering v0.2.0 baseline (post-extraction)
• Tests migrated: tests/test_engine.py, tests/test_loader.py, tests/test_registry.py, tests/test_meta_command_registry.py, etc. — every test that imports from dazzlecmd_lib moves
• dazzlecmd consumes via git submodule (not editable-install of packages/)
• dz runs end-to-end with submodule-based dazzlecmd-lib (verified via existing 907-test suite)
• First v0.2.0 PyPI release (after wtf-windows + sysdiagnose-public both consume the library at the released version)

Decision points

• Timing: extract during 0.7.x or wait for 0.8.0? Trade-off: in-monorepo work is faster, but extraction proves the library is truly standalone.
  • Recommendation: extract during 0.7.x as part of Tier 7 of the closeout plan, before tagging v0.8.0
• Tests: split entirely (library tests move with library) or keep duplicates (library has unit tests, dazzlecmd has integration tests)?
  • Recommendation: split entirely; library-internal tests go with library; dazzlecmd's tests/ keeps only integration-level tests that cover dazzlecmd's CLI layer
• Submodule vs git subtree for dazzlecmd-side consumption?
  • Recommendation: submodule (per the extraction note); cleanest dev workflow during prealpha; switch to PyPI dependency at v1.0.0

Related issues

• Sub-issue of dazzlecmd-lib: extract AggregatorEngine as an importable library package #27 — dazzlecmd-lib: extract AggregatorEngine as an importable library package (parent)
• Refs EPIC: Phase 4 -- library extraction, polyglot dispatch, scaffolding redesign, ecosystem validation #30 — Phase 4 epic
• Blocks: wtf-windows upstream PR (4e-T1) — needs PyPI release with find_project() available
• Blocks: sysdiagnose-public adoption (sysdiagnose-public adoption: third validation of dazzlecmd-lib across a different domain #46) — third-party adoption needs PyPI release
• Blocks: first v0.8.0 / v1.0.0 release — closeout plan tags 0.8.0 only after library has at least 2 PyPI-consuming adopters

Analysis

• Extraction note: notes/meta/2026-04-18__21-00-00__both_dazzlecmd-lib-repo-extraction-pypi-release.md
• Master closeout plan: 2026-04-29__07-41-11__claude-plan__0-7-x-closeout-ultraplan.md (X-1 through X-5 in Tier 7)