Phase 2 — Naming Migration Implementation Plan
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-Backend→Plings-APIPlings-Lovable-Frontend→Plings-WebPlings-Director→Plings-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(sweepPlings-Lovable-Frontend/→Plings-Web/andPlings-Backend/→Plings-API/) - Modify:
README.md(cross-repo references)
Plings-API (currently Plings-Backend/):
- Modify:
vercel.json(audit for path refs) - Modify:
.github/workflows/*.ymlif 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(orpackage-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/
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:
- Project Settings → Git → Disconnect repository
- Reconnect and select
Plings-Web - 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-Webto 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:
- Quickest fix: in Vercel → Deployments → find the pre-rename production deployment → “Promote to Production”. Restores service immediately.
- Then: rename the repo back on GitHub:
gh repo rename Plings-Lovable-Frontend --repo <user>/Plings-Web. - 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/
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:
- Promote previous deployment in Vercel.
- Rename repo back:
gh repo rename Plings-Backend --repo <user>/Plings-API. - 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/configin each repo (viagit 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.txt→Plings-API/requirements.txtPlings-Lovable-Frontend/docs/→Plings-Web/docs/- Any other
Plings-Backend/orPlings-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/*.ymlif 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.appURL → update toapi.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/*.ymlif 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/*.ymlif 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:
- Delete —
rm /Users/paul/Documents/GitHub/Plings/2026-05-06-phase-2-naming-migration.md - Archive —
mv /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
- Package manager for Plings-Web: bun or npm? (Task 1.1)
- GitHub user/org name to substitute for
<user>placeholder in CLI commands (Tasks 3.2, 4.2, etc.) - Tidsfönster för rename: when should Phase 2.3 and 2.4 happen? Recommend a low-traffic window (sen kväll eller helg).
- Are there open PRs or branches that should be merged before starting? (Task 2.1 covers detection, but advance heads-up helps.)
- 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.