# Truto Sync Job Validator

> Validate, dry-run, and debug Truto sync jobs or sync job templates with CLI and current repo rules, including runtime v4 structure, args, account capability checks, request-node reproductions, optional run creation, and rapid_bridge log review. Use for sync job review, testing, or failures.

- Skill: `yuvraj3335/truto-sync-job-validator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yuvraj3335/truto-sync-job-validator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yuvraj3335/truto-sync-job-validator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yuvraj3335 (https://skillmd.com/u/yuvraj3335)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yuvraj3335/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

```bash
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:

```bash
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:

```bash
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.