Truto Sync Job Validator

Truto Sync Job Validator

Mission

Review whether a sync job is structurally valid, runnable against a specific account, and likely to produce the expected destination output. Keep "dry run" read-only unless the user explicitly asks to create a sync-job run.

Required Context

Use any of: sync job ID, sync job template ID, local JSON file, profile, account ID, args JSON, webhook ID, datastore ID, super_query region, failing run ID, or log window.

When in this repo, read .cursor/rules/sync-job-v4.mdc before making v4 claims. Cross-check schema edge cases in src/sync-job/syncJobSchema.ts and src/sync-job-run/syncJobRunSchema.ts.

Fetch

truto whoami -p "$PROFILE" -o json --no-color
truto sync-jobs get "$SYNC_JOB_ID" -p "$PROFILE" -o json --no-color
truto sync-job-templates get "$TEMPLATE_ID" -p "$PROFILE" -o json --no-color
truto sync-job-runs get "$RUN_ID" -p "$PROFILE" -o json --no-color
truto accounts get "$ACCOUNT_ID" -p "$PROFILE" -o json --no-color
truto accounts tools "$ACCOUNT_ID" -p "$PROFILE" -o json --no-color

For local JSON, first run jq . "$FILE" >/dev/null.

Structural Review

Check these in order:

• default_runtime_version is 4 for v4 jobs.
• Top-level label, resources, and intentional integration_name exist.
• args_schema contains runtime values used by placeholders, especially account, webhook, datastore, start date, tenant, company, and destination IDs.
• args_validation returns null on success or an object with a useful message on failure.
• Every referenced node has a unique name; every depends_on targets one existing node name.
• request.resource is an explicit unified path like ticketing/tickets unless proxy/native behavior is intentional.
• Request query, body, id, loop_on, recurse, and run_if paths refer to available args, resources, payload, or sync_job_run state.
• Incremental filters match the integration's unified query_mapping.
• Destination resources_to_persist references transform/request names, not resource paths.
• Optional destinations have run_if guards.
• mutex_key and state_key are stable per account/customer.

Read-Only Dry Run

Reproduce each request node as a small data-plane read. Substitute args and loop values manually:

truto unified "$MODEL" "$RESOURCE" -m "$METHOD" -a "$ACCOUNT_ID" --query-json "$QUERY_JSON" -p "$PROFILE" -o json --no-color -v
truto proxy "$RESOURCE" -m "$METHOD" -a "$ACCOUNT_ID" --query-json "$QUERY_JSON" -p "$PROFILE" -o json --no-color -v

For transforms, capture a representative raw response and use mapping or JSONata review. For datastore outputs, verify only the generated config unless the user authorizes an actual run.

Actual Run

Only create a run after explicit approval:

truto sync-job-runs create -p "$PROFILE" -o json --no-color -b "$RUN_BODY_JSON"
truto sync-job-runs get "$RUN_ID" -p "$PROFILE" -o json --no-color
truto logs --log-type rapid_bridge --sync-job-run-id "$RUN_ID" -p "$PROFILE" -o json --no-color

Poll sparingly until completed, failed, or stopped. Also query --sync-job-id and --integrated-account-id when the run ID is not known.

Output

Return a verdict grouped as blockers, likely runtime failures, destination risks, and improvements. Include exact request-node reproductions, run/log evidence if executed, and the smallest safe fix.