Phase 2 — Naming Migration Implementation Plan

STATUS: COMPLETED — Wed 06 May 2026. Archived for historical reference. All three repos renamed (Plings-Backend → Plings-API, Plings-Lovable-Frontend → Plings-Web, Plings-Director → Plings-Gateway), local folders matched, docs and code references swept. Production verified intact at every step.

One follow-up deferred: the env var DIRECTOR_API_KEY (used by Plings-Gateway → Plings-API auth) is still in production under its old name. Renaming requires a coordinated cross-repo + Vercel env-var rotation; not done in Phase 2.

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Complete the rename migration started in Phase 1. Rename two repositories on GitHub (Plings-Backend → Plings-API, Plings-Lovable-Frontend → Plings-Web), rename matching local folders, remove leftover Lovable.dev artifacts from Plings-Web, resolve dual lockfile, and sweep disk-path references throughout docs and config so they match the new names.

Architecture: Phase the migration so every step is either reversible or has a tight blast radius. Pre-clean code internals first (no external impact). Rename GitHub repos one at a time with verification between (small production-risk windows). Rename local folders after GitHub stabilises. Sweep documentation and code last because it is the largest but lowest-risk batch.

Tech Stack: Git, GitHub (web UI or gh CLI), Vercel (deployment), npm/bun (Plings-Web package manager), Vite (Plings-Web build), FastAPI (Plings-API — internal naming unaffected).

Constraint: All three repos rename:

  • Plings-BackendPlings-API
  • Plings-Lovable-FrontendPlings-Web
  • Plings-DirectorPlings-Gateway (decision made post-plan-creation; “Gateway” is a clearer API-architecture term than the abstract “Director” metaphor)

Note: the s.plings.io URL stays. Only the repo and conceptual name change. The “four functions” description in docs needs prose updates from “Director Function” to “Gateway Function” but the underlying functionality is unchanged.


File Structure

This plan touches files across all three repos. Files modified per repo:

Workspace root (/Users/paul/Documents/GitHub/Plings/):

  • Modify: CLAUDE.md (repo table — remove disk-path indirection after rename, drop migration-in-progress note)

Plings-Web (currently Plings-Lovable-Frontend/):

  • Modify: package.json (name field, remove lovable-tagger)
  • Modify: vite.config.ts (remove lovable-tagger import if present)
  • Delete: one of bun.lockb / package-lock.json
  • Modify: vercel.json (audit for path refs)
  • Modify: .github/workflows/*.yml (audit for repo-name refs)
  • Modify: docs/**/*.md (sweep Plings-Lovable-Frontend/Plings-Web/ and Plings-Backend/Plings-API/)
  • Modify: README.md (cross-repo references)

Plings-API (currently Plings-Backend/):

  • Modify: vercel.json (audit for path refs)
  • Modify: .github/workflows/*.yml if present
  • Modify: README.md (self-reference + Plings-Web reference)

Plings-Director (no rename):

  • Modify: README.md (cross-repo references only)

Phase 2.1 — Pre-clean Plings-Web internals

Goal: Remove Lovable artifacts and resolve the dual lockfile situation. All changes are local; no external impact.

Task 1.1: Decide on package manager

Files: none yet

  • Step 1: Identify which package manager is in active use locally

Run:

cd /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend
ls -la bun.lockb package-lock.json

Expected: Both files exist. The newer mtime indicates which manager was last used. From earlier inspection: package-lock.json (Jul 27 2025) is newer than bun.lockb (Jul 19 2025), suggesting npm was used most recently — but this needs confirmation from the user.

  • Step 2: User decision required

Ask the user: “bun or npm?” Default recommendation: npm, since the newer lockfile is package-lock.json and package.json scripts (vite, vite build) work identically with both.

  • Step 3: Document the decision

Note the chosen manager. The next tasks assume that choice and remove the other lockfile.

Task 1.2: Remove lovable-tagger from devDependencies

Files:

  • Modify: Plings-Lovable-Frontend/package.json
  • Modify: Plings-Lovable-Frontend/vite.config.ts (if it imports lovable-tagger)

  • Step 1: Check vite.config.ts for lovable-tagger usage

Run:

grep -n "lovable-tagger\|componentTagger" /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend/vite.config.ts

If matches found: keep results in mind for Step 3. If no matches: skip Step 3.

  • Step 2: Remove the dep from package.json

Edit package.json. Remove this line from devDependencies:

"lovable-tagger": "^1.1.7",
  • Step 3: Remove import and usage from vite.config.ts (only if Step 1 found matches)

If vite.config.ts has import { componentTagger } from "lovable-tagger" or similar, remove the import line. Then remove componentTagger() from the plugins array. Result should look like:

// Before
import { componentTagger } from "lovable-tagger";
// ...
plugins: [react(), mode === 'development' && componentTagger()].filter(Boolean),

// After
plugins: [react()],
  • Step 4: Reinstall to update lockfile

Run (with chosen package manager from Task 1.1):

# If npm:
npm install
# If bun:
bun install

Expected: lockfile updates, no lovable-tagger in resolved deps. No errors.

  • Step 5: Verify dev server still starts

Run:

npm run dev   # or bun run dev

Expected: Vite starts on http://localhost:5173 without errors. Hit Ctrl+C to stop.

  • Step 6: Verify production build still works

Run:

npm run build   # or bun run build

Expected: Build succeeds, dist/ populated, no errors mentioning lovable-tagger.

  • Step 7: Commit
git add package.json vite.config.ts package-lock.json   # or bun.lockb instead
git commit -m "chore: remove lovable-tagger devDependency and import

Lovable.dev is no longer used. The componentTagger plugin had no
runtime effect once Lovable was retired, so removing the dep removes
dead code without behaviour change."

Task 1.3: Update package.json name field

Files:

  • Modify: Plings-Lovable-Frontend/package.json

  • Step 1: Change the name

Edit package.json:

// Before
"name": "vite_react_shadcn_ts",

// After
"name": "plings-web",
  • Step 2: Verify nothing references the old name

Run:

grep -rn "vite_react_shadcn_ts" /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend/ --include="*.json" --include="*.ts" --include="*.tsx" --include="*.md" 2>/dev/null

Expected: Only matches in the lockfile (which gets regenerated next step). No other refs.

  • Step 3: Reinstall to update lockfile
npm install   # or bun install

Expected: Lockfile updates the package name. No errors.

  • Step 4: Verify build still works
npm run build

Expected: Build succeeds.

  • Step 5: Commit
git add package.json package-lock.json   # or bun.lockb
git commit -m "chore: rename package to plings-web

Was 'vite_react_shadcn_ts' (Lovable template default). Aligns with
the Plings-Web repo concept; folder rename to follow."

Task 1.4: Delete the unused lockfile

Files:

  • Delete: Plings-Lovable-Frontend/bun.lockb (or package-lock.json, depending on Task 1.1 decision)

  • Step 1: Delete the unused lockfile

If using npm:

rm /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend/bun.lockb

If using bun:

rm /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend/package-lock.json
  • Step 2: Update .gitignore to prevent reintroduction (optional but helpful)

If using npm — add to .gitignore:

bun.lockb

If using bun — add to .gitignore:

package-lock.json
  • Step 3: Commit
git add -A
git commit -m "chore: drop unused lockfile

The repo had both bun.lockb and package-lock.json. Standardising on
[npm/bun] and removing the other to avoid drift."

Phase 2.2 — Pre-rename audit

Goal: Confirm there’s no in-flight work that would be disrupted by the GitHub renames.

Task 2.1: Audit each repo for uncommitted/unpushed changes

Files: none modified

  • Step 1: Check Plings-Web
cd /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend
git status
git log @{u}..HEAD --oneline 2>/dev/null   # commits ahead of remote

Expected: clean working tree, no unpushed commits — OR if there are, decide whether to push, stash, or land them before continuing.

  • Step 2: Check Plings-API
cd /Users/paul/Documents/GitHub/Plings/Plings-Backend
git status
git log @{u}..HEAD --oneline 2>/dev/null

Expected: same as above.

  • Step 3: Check Plings-Director
cd /Users/paul/Documents/GitHub/Plings/Plings-Director
git status
git log @{u}..HEAD --oneline 2>/dev/null

Expected: same as above.

  • Step 4: Check open PRs

For each repo (substitute the actual GitHub user/org):

gh pr list --repo <user>/Plings-Backend
gh pr list --repo <user>/Plings-Lovable-Frontend
gh pr list --repo <user>/Plings-Director

Expected: empty list, OR a list to evaluate. If there are open PRs, merge or close them before renaming — open PRs against the old repo URL get auto-redirected by GitHub but it’s cleaner to clear them first.


Phase 2.3 — Rename Plings-Lovable-Frontend → Plings-Web (canary)

Goal: Rename the lower-risk frontend repo first to validate the process before doing the same for the API. If plings.io breaks for a few minutes during this phase, that is recoverable; if api.plings.io breaks, every other client breaks with it.

Risk window: ~5–10 minutes between rename and verified deploy.

Task 3.1: Open Vercel dashboard for live monitoring

Files: none modified

  • Step 1: Open Vercel project for plings.io in browser

Go to https://vercel.com/dashboard. Find the project that deploys plings.io (likely named “plings-lovable-frontend” or similar). Open it in a tab and keep it open throughout this phase.

  • Step 2: Note current production deployment URL

In Vercel project → Deployments tab → record the current production deployment ID and timestamp. This is the rollback target if the rename breaks something.

Task 3.2: Rename the GitHub repo

Files: none modified locally

  • Step 1: Rename via GitHub UI (recommended — preserves all settings)

Navigate to https://github.com//Plings-Lovable-Frontend/settings → Repository name → enter `Plings-Web` → Rename.

OR via gh CLI:

gh repo rename Plings-Web --repo <user>/Plings-Lovable-Frontend
  • Step 2: Verify the new URL responds
curl -I https://github.com/<user>/Plings-Web

Expected: HTTP 200.

  • Step 3: Verify the old URL redirects
curl -I https://github.com/<user>/Plings-Lovable-Frontend

Expected: HTTP 301 redirecting to the new URL.

Task 3.3: Verify Vercel still has its connection

Files: none modified

  • Step 1: Reload Vercel project page

In the Vercel tab from Task 3.1, refresh. The “Git Repository” section should now show <user>/Plings-Web automatically (Vercel listens for the GitHub rename event).

  • Step 2: If Vercel still shows the old name

Vercel’s git connection sometimes lags. Wait 30 seconds and refresh. If it still shows the old name after 2 minutes:

  1. Project Settings → Git → Disconnect repository
  2. Reconnect and select Plings-Web
  3. Verify deployments section is intact (don’t disconnect/reconnect if production is currently running cleanly — check first that this won’t trigger a new deploy)

Task 3.4: Trigger a verification deploy

Files:

  • Modify: a trivial file in Plings-Web to trigger redeploy

  • Step 1: Make a no-op commit to trigger Vercel

cd /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend
# Note: local folder still has old name at this point — that's fine
git commit --allow-empty -m "chore: verify Vercel build after repo rename"
git push

Expected: Vercel dashboard shows a new deployment starting within ~30 seconds.

  • Step 2: Watch the deployment in Vercel

Wait for the deployment to reach “Ready” status. Should take 1–3 minutes.

If the deploy fails: check the build logs in Vercel for clues. Most likely cause would be a webhook misfire — try re-running the deploy via Vercel’s “Redeploy” button.

Task 3.5: Smoke test plings.io

Files: none

  • Step 1: Hit the production URL
curl -I https://plings.io

Expected: HTTP 200 with valid HTML response.

  • Step 2: Open in browser

Visit https://plings.io. Should load normally. Try logging in if you have credentials at hand — full functional smoke test.

  • Step 3: Verify no certificate or DNS issues
curl -sI https://plings.io | head -5

Expected: HTTP/2 200, server: Vercel. If you see certificate warnings, DNS issues, or 5xx errors, rollback (see Rollback below).

Rollback for Phase 2.3 (if smoke test fails)

If plings.io is broken:

  1. Quickest fix: in Vercel → Deployments → find the pre-rename production deployment → “Promote to Production”. Restores service immediately.
  2. Then: rename the repo back on GitHub: gh repo rename Plings-Lovable-Frontend --repo <user>/Plings-Web.
  3. Then: investigate what went wrong before retrying. Common cause is Vercel git-link not picking up the rename — fix manually via Vercel → Settings → Git.

Phase 2.4 — Rename Plings-Backend → Plings-API

Goal: Apply the proven process from Phase 2.3 to the more critical API repo.

Risk window: ~5–10 minutes. Higher impact than 2.3 because every Plings-Web user, native app user (planned), and Director routing depends on api.plings.io. Do not start this phase if Phase 2.3 had any issues.

Task 4.1: Open Vercel dashboard for live monitoring

  • Step 1: Open the Plings-API Vercel project

Same as Task 3.1 but for the project that deploys api.plings.io. Note current production deployment.

Task 4.2: Rename the GitHub repo

  • Step 1: Rename

Via UI: https://github.com//Plings-Backend/settings → rename to `Plings-API`.

OR:

gh repo rename Plings-API --repo <user>/Plings-Backend
  • Step 2: Verify URLs
curl -I https://github.com/<user>/Plings-API
curl -I https://github.com/<user>/Plings-Backend

Expected: 200 on new URL, 301 redirect on old URL.

Task 4.3: Verify Vercel still connected

  • Step 1: Refresh Vercel project page

Should show <user>/Plings-API automatically. If not, follow the disconnect/reconnect process from Task 3.3.

Task 4.4: Trigger verification deploy

  • Step 1: No-op commit and push
cd /Users/paul/Documents/GitHub/Plings/Plings-Backend
git commit --allow-empty -m "chore: verify Vercel build after repo rename"
git push
  • Step 2: Wait for deploy to complete

Watch in Vercel. Should reach Ready in 2–5 minutes (Python/FastAPI cold-start build is slower than Vite).

Task 4.5: Smoke test api.plings.io

  • Step 1: GraphQL endpoint responds
curl -s https://api.plings.io/graphql -H "Content-Type: application/json" -d '{"query":"query { __typename }"}'

Expected:

{"data":{"__typename":"Query"}}

If you get HTML (the GraphiQL page), that also indicates the service is up — try with Accept: application/json header to force JSON response.

  • Step 2: Health endpoint (if exposed)
curl https://api.plings.io/health

Expected: {"status":"healthy",...} or similar.

  • Step 3: Verify a real authenticated query works

If you have a JWT handy, hit a real query like myObjects to confirm DB connectivity wasn’t affected.

Rollback for Phase 2.4

Same procedure as Phase 2.3 rollback, but more critical to act fast since Plings-Web depends on this. If api.plings.io is broken:

  1. Promote previous deployment in Vercel.
  2. Rename repo back: gh repo rename Plings-Backend --repo <user>/Plings-API.
  3. Investigate before retrying.

Phase 2.5 — Local folder rename

Goal: Update the local working tree to match the new GitHub names. No production impact — purely local.

Task 5.1: Rename local folders

Files:

  • Move: /Users/paul/Documents/GitHub/Plings/Plings-Lovable-Frontend//Users/paul/Documents/GitHub/Plings/Plings-Web/
  • Move: /Users/paul/Documents/GitHub/Plings/Plings-Backend//Users/paul/Documents/GitHub/Plings/Plings-API/

  • Step 1: Close any IDE windows or terminals inside these folders

Otherwise the rename may fail with “in use” errors on macOS.

  • Step 2: Rename the folders
cd /Users/paul/Documents/GitHub/Plings/
mv Plings-Lovable-Frontend Plings-Web
mv Plings-Backend Plings-API

Expected: no errors. ls should now show Plings-Web/, Plings-API/, Plings-Director/.

  • Step 3: Verify git remote URLs work via redirect
cd /Users/paul/Documents/GitHub/Plings/Plings-Web
git fetch
cd /Users/paul/Documents/GitHub/Plings/Plings-API
git fetch

Expected: git fetch completes successfully (GitHub redirects old URLs).

Task 5.2: Optionally update remote URLs to canonical new names

Files:

  • Modify: .git/config in each repo (via git remote set-url)

  • Step 1: Update Plings-Web’s remote

cd /Users/paul/Documents/GitHub/Plings/Plings-Web
git remote -v
# Note current URL — likely git@github.com:<user>/Plings-Lovable-Frontend.git
git remote set-url origin git@github.com:<user>/Plings-Web.git
git remote -v
# Verify: should now show Plings-Web
  • Step 2: Update Plings-API’s remote
cd /Users/paul/Documents/GitHub/Plings/Plings-API
git remote set-url origin git@github.com:<user>/Plings-API.git
git remote -v
  • Step 3: Verify fetch still works after URL update
cd /Users/paul/Documents/GitHub/Plings/Plings-Web && git fetch
cd /Users/paul/Documents/GitHub/Plings/Plings-API && git fetch

Expected: clean fetch, no errors.


Phase 2.6 — Update workspace-root CLAUDE.md

Goal: Update the canonical project guide to reflect the new disk paths and remove the migration-in-progress note.

Task 6.1: Update repo table

Files:

  • Modify: /Users/paul/Documents/GitHub/Plings/CLAUDE.md

  • Step 1: Update the repo-layout table

Replace this section in CLAUDE.md:

| Repository (concept) | Disk path (current) | Role | Stack | URL |
|----------------------|---------------------|------|-------|-----|
| **Plings-API** | `Plings-Backend/` | GraphQL API + business logic | Python 3.10+, FastAPI, Ariadne, Poetry | `api.plings.io` |
| **Plings-Director** | `Plings-Director/` | Universal scan-routing service | TypeScript, Vercel Edge | `s.plings.io` |
| **Plings-Web** | `Plings-Lovable-Frontend/` | Web frontend | React, TypeScript, Vite, Tailwind, shadcn/ui | `plings.io` (and subdomains) |

With:

| Repository | Disk path | Role | Stack | URL |
|-----------|-----------|------|-------|-----|
| **Plings-API** | `Plings-API/` | GraphQL API + business logic | Python 3.10+, FastAPI, Ariadne, Poetry | `api.plings.io` |
| **Plings-Director** | `Plings-Director/` | Universal scan-routing service | TypeScript, Vercel Edge | `s.plings.io` |
| **Plings-Web** | `Plings-Web/` | Web frontend | React, TypeScript, Vite, Tailwind, shadcn/ui | `plings.io` (and subdomains) |
  • Step 2: Remove the migration note

Delete this paragraph from CLAUDE.md:

> **Naming migration in progress**: Disk folders still use legacy names (`Plings-Backend`, `Plings-Lovable-Frontend`). Conceptual references in new code and documentation should use the new names (`Plings-API`, `Plings-Web`). Folder/repo renames will happen in a later phase. When writing actual file paths, use the current disk paths.
  • Step 3: Update path-anchored references in CLAUDE.md

Replace remaining paths in CLAUDE.md:

  • Plings-Backend/requirements.txtPlings-API/requirements.txt
  • Plings-Lovable-Frontend/docs/Plings-Web/docs/
  • Any other Plings-Backend/ or Plings-Lovable-Frontend/ disk-path references

Run a verification:

grep -n "Plings-Backend\|Plings-Lovable-Frontend" /Users/paul/Documents/GitHub/Plings/CLAUDE.md

Expected: no matches after edits.

  • Step 4: Update the “last updated” line

Replace the bottom of CLAUDE.md:

**CLAUDE.md last updated**: <today's date> — Phase 2 of naming migration complete: GitHub repos and local folders renamed (Plings-Backend → Plings-API, Plings-Lovable-Frontend → Plings-Web). Migration-in-progress note removed.

Use date "+%a %d %b %Y %H:%M:%S %Z" to get the timestamp.

  • Step 5: Commit (no repo — workspace root is not in git)

The workspace root has no git. CLAUDE.md sits there as-is. No commit needed.


Phase 2.7 — Sweep disk-path references in docs

Goal: Replace Plings-Lovable-Frontend/ and Plings-Backend/ with Plings-Web/ and Plings-API/ in all documentation files.

Task 7.1: Inventory all references

Files: none modified

  • Step 1: Find all matches in docs
cd /Users/paul/Documents/GitHub/Plings/Plings-Web
grep -rn "Plings-Lovable-Frontend\|Plings-Backend" docs/ --include="*.md" 2>/dev/null

Save the output. The list determines per-file edits in Task 7.2.

Expected from Phase 1 work: ~15–20 lines across ~10 files. Most are disk-path mentions in tables, kodträd (code trees), and prose.

Task 7.2: Replace systematically per file

Files:

  • Modify: every file from Task 7.1 inventory

For each file from the inventory, apply the same pattern. Example procedure for one file:

  • Step 1: Open and read the file

Use Read tool to load the full file context.

  • Step 2: Edit each match

Replace occurrences:

  • Plings-Lovable-Frontend/Plings-Web/
  • Plings-Backend/Plings-API/

In tables, also clean up phrases like “(disk: Plings-Lovable-Frontend/)” — they no longer add value since disk and concept names match.

  • Step 3: Verify no matches remain in that file
grep -n "Plings-Lovable-Frontend\|Plings-Backend" <path-to-file>

Expected: empty.

  • Step 4: Move to next file in inventory

Repeat Steps 1–3 for each file.

Task 7.3: Commit doc sweep

  • Step 1: Verify global cleanup
cd /Users/paul/Documents/GitHub/Plings/Plings-Web
grep -rn "Plings-Lovable-Frontend\|Plings-Backend" docs/ --include="*.md" 2>/dev/null

Expected: empty output.

  • Step 2: Commit
git add docs/
git commit -m "docs: sweep disk-path references to new repo names

Phase 2 of naming migration. Replaces all disk-path mentions of
Plings-Lovable-Frontend/ and Plings-Backend/ with Plings-Web/ and
Plings-API/ respectively, now that folder renames are complete."
git push

Phase 2.8 — Sweep code/config references

Goal: Update any non-doc files that reference the old paths or repo names.

Task 8.1: Audit Plings-Web config files

Files:

  • Modify: vercel.json, .github/workflows/*.yml if present

  • Step 1: Search for stale references

cd /Users/paul/Documents/GitHub/Plings/Plings-Web
grep -rn "Plings-Lovable-Frontend\|Plings-Backend\|plings-backend\|vite_react_shadcn_ts" \
  vercel.json \
  .github/ \
  --include="*.json" --include="*.yml" --include="*.yaml" --include="*.toml" 2>/dev/null
  • Step 2: Edit each match

For each match, decide:

  • Path reference → update to new path
  • Repo name reference → update
  • plings-backend.vercel.app URL → update to api.plings.io

  • Step 3: Verify

Re-run the grep from Step 1. Expected: empty.

  • Step 4: Commit
git add -A
git commit -m "chore: update config references to new repo names"
git push

Task 8.2: Audit Plings-API config files

Files:

  • Modify: vercel.json, .github/workflows/*.yml if present

  • Step 1: Same search in Plings-API

cd /Users/paul/Documents/GitHub/Plings/Plings-API
grep -rn "Plings-Lovable-Frontend\|Plings-Backend" \
  vercel.json \
  .github/ \
  --include="*.json" --include="*.yml" --include="*.yaml" --include="*.toml" \
  --include="*.py" 2>/dev/null
  • Step 2: Edit each match and commit

Same approach as Task 8.1.

git add -A
git commit -m "chore: update config references to new repo names"
git push

Task 8.3: Audit Plings-Director config files

Files:

  • Modify: vercel.json, .github/workflows/*.yml if present

  • Step 1: Same search in Plings-Director

cd /Users/paul/Documents/GitHub/Plings/Plings-Director
grep -rn "Plings-Lovable-Frontend\|Plings-Backend\|plings-backend" \
  vercel.json \
  .github/ \
  --include="*.json" --include="*.yml" --include="*.ts" --include="*.tsx" 2>/dev/null
  • Step 2: Edit each match and commit
git add -A
git commit -m "chore: update references to renamed repos"
git push

Task 8.4: Update README.md in each repo

Files:

  • Modify: Plings-Web/README.md
  • Modify: Plings-API/README.md
  • Modify: Plings-Director/README.md

  • Step 1: Update Plings-Web’s README

Read and update any references to:

  • The repo’s own old name (Plings-Lovable-Frontend)
  • The other repos’ old names
  • Lovable.dev framing if any survived Phase 1

  • Step 2: Same for Plings-API

Same approach.

  • Step 3: Same for Plings-Director

Same approach.

  • Step 4: Commit each README update in its respective repo
# In each repo:
git add README.md
git commit -m "docs: update repo cross-references to renamed repos"
git push

Phase 2.9 — Final verification and close

Goal: Confirm all three production URLs respond correctly and no stale references remain anywhere.

Task 9.1: End-to-end smoke tests

Files: none

  • Step 1: Plings-API
curl -s https://api.plings.io/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"query { __typename }"}'

Expected: {"data":{"__typename":"Query"}}

  • Step 2: Plings-Director
curl -sI "https://s.plings.io/?t=q&i=test&p=1.1.1.1.1"

Expected: HTTP 3xx (redirect — even an error redirect proves the service is up).

  • Step 3: Plings-Web
curl -sI https://plings.io

Expected: HTTP 200.

  • Step 4: Open plings.io in browser, verify it loads correctly and login works

Manual visual check.

Task 9.2: Final repo-state audit

  • Step 1: Verify all three repos clean
for d in Plings-API Plings-Director Plings-Web; do
  cd /Users/paul/Documents/GitHub/Plings/$d
  echo "=== $d ==="
  git status
  git log --oneline -3
done

Expected: clean working trees in all three; recent commits reflect Phase 2 work.

  • Step 2: Confirm no stale references survive anywhere
cd /Users/paul/Documents/GitHub/Plings
grep -rn "Plings-Lovable-Frontend\|Plings-Backend\|plings-backend.vercel.app\|vite_react_shadcn_ts\|lovable-tagger\|lovable.dev" \
  --include="*.md" --include="*.json" --include="*.ts" --include="*.tsx" --include="*.py" --include="*.yml" --include="*.yaml" \
  Plings-API/ Plings-Director/ Plings-Web/ CLAUDE.md \
  2>/dev/null \
  | grep -v "node_modules\|.venv\|__pycache__\|.git/" \
  | head -30

Expected: empty output, OR matches only in legitimate historical-marker prose (e.g., “previously known as …”).

Task 9.3: Archive or delete this plan

Files:

  • Delete or move: /Users/paul/Documents/GitHub/Plings/2026-05-06-phase-2-naming-migration.md

  • Step 1: Decide fate of plan file

Two options:

  • Deleterm /Users/paul/Documents/GitHub/Plings/2026-05-06-phase-2-naming-migration.md
  • Archivemv /Users/paul/Documents/GitHub/Plings/2026-05-06-phase-2-naming-migration.md /Users/paul/Documents/GitHub/Plings/Plings-Web/docs/development/migrations/2026-05-06-phase-2-naming-migration.md

User decides. Default recommendation: archive — historical migrations are useful reference for the next time something similar happens.

  • Step 2: If archiving, commit it to Plings-Web
cd /Users/paul/Documents/GitHub/Plings/Plings-Web
mkdir -p docs/development/migrations/
git add docs/development/migrations/2026-05-06-phase-2-naming-migration.md
git commit -m "docs: archive Phase 2 naming-migration plan as historical record"
git push

Risks summary

Risk Likelihood Impact Mitigation
Vercel git-link breaks during GitHub rename Low High (service down) Phase 2.3 done first as canary; live monitoring of Vercel during rename; documented rollback
Open PRs break Low Low Audit in Phase 2.2 before starting
GitHub Actions workflows fail Medium Low–Medium Audit and update in Phase 2.8
Local IDE configurations point to old paths High Low (manual fix) Paul updates manually; not in plan scope
External bookmarks / scripts fail Medium Low Out of scope; GitHub redirects buy time
requirements.txt not synced after Plings-API rename Low High (deploy fail) Already covered by existing CLAUDE.md guidance; not specific to Phase 2

Open questions for the user before starting

  1. Package manager for Plings-Web: bun or npm? (Task 1.1)
  2. GitHub user/org name to substitute for <user> placeholder in CLI commands (Tasks 3.2, 4.2, etc.)
  3. Tidsfönster för rename: when should Phase 2.3 and 2.4 happen? Recommend a low-traffic window (sen kväll eller helg).
  4. Are there open PRs or branches that should be merged before starting? (Task 2.1 covers detection, but advance heads-up helps.)
  5. After completion: archive or delete this plan? (Task 9.3)

Self-review notes

  • Spec coverage: every item from the chat-level Phase 2 outline is in the plan (pre-clean, GitHub renames, local renames, CLAUDE.md update, doc sweep, code/config sweep, verification).
  • Lockfile decision: deliberately gated on user input in Task 1.1 since it depends on local workflow.
  • TDD shape: this plan does not have traditional unit tests because the changes are infrastructure operations, not algorithmic code. Verification commands (smoke tests, grep audits) replace tests at the right level — each phase has explicit “verify” steps before commit.
  • Idempotency: each phase’s verification can be re-run safely. Rollback procedures are documented for the two phases (2.3, 2.4) where production is briefly at risk.