todero-dev-workspace-run-verify-fix

Run, verify, reseed, and repair Todero isolated dev workspace runtime services.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/nabitllc/todero --skill todero-dev-workspace-run-verify-fix-nabitllc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: todero-dev-workspace-run-verify-fix
Source: https://github.com/nabitllc/todero/tree/main/.agents/skills/todero-dev-workspace-run-verify-fix
Command: npx skills add https://github.com/nabitllc/todero --skill todero-dev-workspace-run-verify-fix-nabitllc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Todero dev workspaces started through managed runtime services can silently break: a sibling workspace squats the pinned port, the cloned database is incomplete, the setup gate reappears, or the control plane reports healthy while the URL serves the wrong worktree. This Skill provides a disciplined run-verify-fix loop that proves real health instead of trusting a single passing probe. ## Core Features & Use Cases - Managed runtime start/stop/restart: Uses the control-plane runtime-service API with run-id headers instead of detached pnpm dev processes. - Port-owner identity verification: Confirms via /proc/<pid>/cwd that the process owning the pinned service port actually belongs to the target worktree, and resolves sibling-workspace port squats by stopping the true owner first. - Full database reseed: Runs npx todero worktree reseed --from-instance default --seed-mode full to restore a complete isolated clone when login or data is missing. - End-to-end verification: Checks /api/health bootstrap status, login readiness, populated cloned data, and runtime visibility from both the main control plane and the served workspace app. - Use Case: An agent is asked to fix a todero-dev workspace whose URL loads but shows another branch's data; the Skill walks through identifying the squatting sibling process, stopping its supervisor, restarting the target service, and verifying identity before closing the issue. ## Quick Start Ask the agent to start and verify the todero-dev workspace service for the current issue, fixing any port conflicts or database problems until health, login, and cloned data all check out.

Frequently Asked Questions about todero-dev-workspace-run-verify-fix

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix a Todero dev workspace that shows the wrong worktree's app?

This is a port squat: the pinned service port is owned by a sibling workspace's process. Identify the real owner with readlink /proc/<pid>/cwd, stop that sibling through its own managed runtime path, verify the port stays free, then restart the target service and re-check identity.

How do I reseed a Todero worktree database from the primary instance?

Run npx todero worktree reseed --from-instance default --seed-mode full --yes, then restart through the managed runtime API. Verify the served app has both working auth and populated product data, not just a copied user row.

Why does /api/health pass but the workspace still serves the wrong data?

Service adoption can attach a sibling workspace's healthy process to this workspace's runtime row, recording the requested cwd instead of the real one. Only /proc/<pid>/cwd of the port owner is authoritative for workspace identity.

Can I repair the workspace by copying auth user rows directly into the database?

No. Manually copying only Better Auth user/account rows proves login but not a full bootstrapped database. The correct fix is a full worktree reseed from the primary instance followed by a managed restart.

What should I check when the workspace shows the first-admin setup gate?

A setup gate means bootstrapStatus is not ready, usually because the isolated database is incomplete. Run a full reseed from the primary instance, restart the managed service, and confirm /api/health reports bootstrapStatus ready with login working.

When is a code change required instead of an operational repair?

Code changes are needed only when the normal repair exposes a product bug, such as adoption trusting root 200 over /api/health or reseeded runtime-service ids not reconciling with the local process registry. Add focused tests and link the commit in the issue comment.