xlab-studio rename — discovery sweep + migration playbook

Date: 2026-05-13 Driver: Dan wants a clearer separation between production org (xlab-co) and personal-experiment incubator (currently xlab-studio). Candidate new names being considered include xlab-nyc, xlab-workshop, xlab-bench, xlab-residency. Status: 🟡 Pre-rename sweep complete. Awaiting Dan’s final name choice + Phase 1 dogwood ship before executing.

TL;DR

xlab-studio is the personal-experiment GitHub org (per project_xlab_co_lifecycle_model). It holds 11 repos total, but only 3 are actively in production workflows (dogwood-house, dare-pipeline, dare-co-uk). The other 8 are historical artifacts or forks.

Renaming the org is a GitHub-supported one-click operation. The friction is in the downstream cleanup — git remotes on every clone, scripts that hardcode URLs, dev reports that reference old PR URLs, memory files Claude reads at session start. This sweep enumerates every reference so the rename day is a single find-and-replace + push, not a week of discovery.

GitHub auto-redirects old URLs for the first move (xlab-studio/repo → xlab-nyc/repo), so nothing breaks immediately. But the redirects are temporary; updating references locks in canonical names before the redirect window closes.

What’s actually in xlab-studio (11 repos)

Active production workflows — must update post-rename

Historical / inactive — low-priority for URL updates

For the historical ones, GitHub’s redirect handles all inbound traffic. No active maintenance needed.

Reference inventory — what needs updating where

Layer 1 — Git remotes on local clones (3 repos)

~/Code/dogwood-house  → https://github.com/xlab-studio/dogwood-house.git
~/Code/dare-pipeline  → https://github.com/xlab-studio/dare-pipeline.git
~/Code/dare-co-uk     → https://github.com/xlab-studio/dare-co-uk.git

Post-rename: git remote set-url origin https://github.com/<new-org>/<repo>.git per repo. ~30 sec per repo.

Layer 2 — Scripts and config files (4 files)

~/bin/README.md
~/bin/CI_NOTES.md
~/Code/mac-setup/setup.sh
~/Code/mac-setup/README.md

Mix of documentation and provisioning logic. The setup.sh reference is the one to check carefully — anything that auto-clones from xlab-studio/... will need updating to avoid breaking new-machine setups.

Layer 3 — Dev-report history (5 files)

~/Code/devreports-content/dare_session_report_2026-05-11.md     (historical)
~/Code/devreports-content/dogwood_twilio_api_key_rotation_2026-05-12.md
~/Code/dogwood-house/dev-reports/dogwood_phase01_pre_flight_2026-05-13.md
~/Code/dogwood-house/dev-reports/dogwood_session_2026-05-12_phase01_progress.md
~/Code/dogwood-house/dev-reports/dogwood_session_2026-05-13_phase01_close.md

These reference PR URLs like github.com/xlab-studio/dogwood-house/pull/3. Recommendation: leave them as historical record. GitHub redirects handle the URLs. Rewriting history-mode dev reports erases the lineage. The new org-name appears naturally in post-rename reports.

Layer 4 — Claude’s memory (9 files)

project_xlab_co_lifecycle_model.md       (PRIMARY — explains the lifecycle)
project_ccr_remote_agent_auth_gap.md
project_dogwood_service_strategy.md
project_portfolio_platform_stack.md
project_dare_pipeline_gha.md
project_dare_pipeline_r2_token.md
feedback_hover_preview_on_urls.md
README.md
MEMORY.md

Post-rename: update each to use the new org name. The primary lifecycle memory needs the most attention — it currently defines the role of xlab-studio.

Layer 5 — GitHub Actions workflows

No references found. GHA workflows in dare-pipeline use repo-relative paths and GitHub-provided env vars (GITHUB_REPOSITORY), not hardcoded org names. Workflow secrets (gh secret) are set per-repo and follow the rename automatically.

This is the cleanest layer — zero work needed. Worth noting as a portable lesson: workflows that use ${{ github.repository }} instead of hardcoded names survive org renames untouched.

The rename procedure (when ready to execute)

Step 0 — Pre-flight (do NOT execute yet)

Step 1 — Rename the org at GitHub (one-click)

1. Go to github.com/organizations/xlab-studio/settings/profile
2. Edit "Organization name" → new value (e.g., xlab-nyc)
3. Confirm via password prompt
4. GitHub propagates the rename + sets up auto-redirects

This is a ~30-second operation. All 11 repos move with the org. Auto-redirects mean nothing breaks immediately.

Step 2 — Update local git remotes (3 repos)

NEW_ORG="xlab-nyc"  # or chosen name

for repo in dogwood-house dare-pipeline dare-co-uk; do
  cd ~/Code/$repo
  git remote set-url origin "https://github.com/${NEW_ORG}/${repo}.git"
  echo "✓ $repo → ${NEW_ORG}"
done

Step 3 — Update local scripts and configs

Use the toolkit at ~/bin/org-rename-sweep (see Toolkit section below):

org-rename-sweep --from xlab-studio --to xlab-nyc --execute

The toolkit handles ~/bin/, ~/Code/mac-setup/, and any other configured locations. Dev-report history is excluded by default (historical record stays as-is).

Step 4 — Update Claude’s memory files

The memory directory is in scope for the sweep but worth doing as a separate, deliberate pass:

org-rename-sweep --from xlab-studio --to xlab-nyc \
                 --include ~/.claude/projects/-Users-dansellars/memory \
                 --exclude '**/2026-05-*.md' \
                 --execute

The --exclude here preserves dated historical references (which should record what the org was called at the time, like dev reports do).

Step 5 — Commit + push the local updates

cd ~/Code/mac-setup && git add -A && git commit -m "rename: xlab-studio → xlab-nyc across canonical configs"
git push

Step 6 — Verify

# Confirm GitHub redirects work
gh repo view xlab-studio/dogwood-house  # should auto-redirect

# Confirm local remotes point at new org
for repo in dogwood-house dare-pipeline dare-co-uk; do
  echo -n "$repo: " && cd ~/Code/$repo && git remote get-url origin
done

# Confirm no stale xlab-studio references in active locations
org-rename-sweep --from xlab-studio --to xlab-nyc --check

The toolkit — ~/bin/org-rename-sweep

Created today as part of this work. Source at ~/Code/mac-setup/bin/org-rename-sweep. Reusable for any future org rename (xlab-co → something, client work, etc.). See the script’s --help for full options.

Key flags: - --from <old-org> / --to <new-org> — required - --check — discovery only, no writes (default) - --execute — apply the find-and-replace - --include <path> / --exclude <pattern> — scope control - Default exclude: historical dev reports, dated files

What this earns the portfolio

• A repeatable rename procedure. xlab-co is unlikely to ever rename (it’s the canonical production name), but client engagements may have their own org renames over time. Same toolkit applies.
• A pattern for “documents in repo as knowledge base.” Sweep findings + toolkit + procedure all committed to GitHub means the org lineage is discoverable forever, even after the rename.
• Confirmation that the workflow-uses-repo-relative-paths pattern is the right default. GHA workflows that survived this sweep untouched are doing it right. Worth banking.

Open questions for Dan

1. Final name choice. Recommend xlab-nyc; runners-up xlab-workshop or xlab-bench.
2. Timing. Wait for tomorrow’s Phase 1 dogwood smoke-test + PR merge before pulling the trigger? My recommendation: yes — avoid mid-flight URL changes.
3. Historical dev reports. Confirm we leave them as-is (recording the name at the time of writing).
4. Memory files. Confirm we update all current-state memories but leave dated/historical ones alone.
5. Should xlab-co rename too to match the new xlab-nyc pattern (e.g., xlab-co-nyc)? My read: no — xlab-co is doing its job as the production-canonical name and shouldn’t take on geographic flavour.

Memories worth banking after rename ships

• feedback_org_rename_runbook.md — the procedure above, generalised
• Update project_xlab_co_lifecycle_model.md with the new org name throughout

Discovery before action is the discipline. The rename itself takes 5 minutes once the sweep is done.