Re-sync Schema Only

When the user's source platform (Base44 / Lovable / Manus) added a new column or table and they want to apply the new ALTER migration without running a full redeploy, use this skill. It runs ONLY the migration pass against the currently-deployed code - no tarball download, no build, no PM2 restart.

A pre-resync database snapshot is taken automatically.

Step 1: Resolve API token

echo "$NOMETRIA_API_KEY"
echo "$NOMETRIA_TOKEN"
grep -s 'NOMETRIA_API_KEY\|NOMETRIA_TOKEN' .env .env.local 2>/dev/null
cat ~/.nometria/credentials.json 2>/dev/null

If no token: tell the user to run /login. Stop.

Store: TOKEN="<the token>"

Step 2: Identify the app

cat nometria.json 2>/dev/null

If absent, use $ARGUMENTS or list migrations:

curl -s -X POST https://app.nometria.com/listUserMigrations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{}'

Store: APP_ID="<app_id>".

Step 3: Confirm with the user

Before dispatching, explain what's about to happen:

Re-syncing the database schema for <APP_NAME>. This applies any new ALTER migrations from your source platform to the live database. It does NOT rebuild the app or restart services. A safety snapshot is taken first. Already-applied migrations are skipped automatically (idempotent).

Confirm: "Proceed?"

Step 4: Dispatch

curl -s -X POST https://app.nometria.com/resyncSchema \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d "{\"app_id\": \"$APP_ID\"}"

Response:

{ "dispatched": true, "command_id": "<ssm-id>" }

If dispatched === false and error === "instance_not_running" - tell the user they need to deploy the app first.

Step 5: Watch progress

Tell the user:

Schema resync dispatched. Run /logs to watch the migration log, or /status to see when the instance is back to running. Migrations usually complete in 5-30 seconds depending on data size.

If they want, use /logs right now to tail the migration output.

Do all of the above. Execute the curl call and report results to the user.