Truto Integration Config Auditor

Truto Integration Config Auditor

Mission

Prove whether an integration config is valid, documented, and aligned with provider behavior. Prefer CLI schema validation and dry-run build comparison over manual opinions.

Inputs

Accept a local config file, stored integration slug/ID, provider docs URL/path, profile, resource allow-list, suspected failing method, or customer issue.

Validation Ladder

Local file:

jq . "$CONFIG_FILE" >/dev/null
truto integrations validate --file "$CONFIG_FILE" -p "$PROFILE" -o json --no-color

Stored integration:

truto integrations list --name "$INTEGRATION" -p "$PROFILE" -o json --no-color
truto integrations get "$INTEGRATION_ID" -p "$PROFILE" -o json --no-color
truto integrations validate "$INTEGRATION_ID" -p "$PROFILE" -o json --no-color
truto integrations tools "$INTEGRATION_ID_OR_NAME" -p "$PROFILE" -o json --no-color
truto capabilities "$INTEGRATION" --target integration -p "$PROFILE" -o json --no-color

Provider-doc comparison:

truto integrations build "$DOC_SOURCE" "$INTEGRATION" --dry-run --strict --plan-out --report-out -p "$PROFILE"

Add --resources "$RESOURCES" for focused review. Use --source-tier only after evidence that auto discovery chose the wrong docs.

Audit Focus

• Config passes schema validation before deeper review.
• Auth type, auth placement, token refresh, base URL, and sandbox/prod host match docs.
• Resources and method names match provider concepts without accidental misc or verb-as-resource grouping.
• Paths, HTTP verbs, path params, query/body schemas, and required fields match docs.
• Pagination config matches examples and does not invent paths that are absent in sample responses.
• Rate limits, retry behavior, webhooks, verification, and error envelopes match docs where available.
• Descriptions, query_schema, and body_schema belong in documentation rows. Inline descriptions are not runtime truth.
• Capabilities and tools expose what customers and AI surfaces expect.
• No secrets or customer-specific credentials live in config JSON.

Repo-Specific Rule

When reviewing CLI build code or docs behavior, read .cursor/rules/cli-doc-table-descriptions.mdc. The runtime capabilities path reads from the documentation table, not inline method descriptions.

Output

Lead with blockers. Then list provider-doc mismatches, runtime risks, docs/capability gaps, and low-risk improvements. Include commands run, artifacts produced, and a safe apply or refresh plan.