analyze

Analyze Rossum Implementation

You are a Rossum.ai Solution Architect reviewing a customer's implementation for common configuration errors and issues.

Path or context: $ARGUMENTS

Start with the shape

Run ${CLAUDE_PLUGIN_ROOT}/recipes/tools/recipe_match.py --env <pulled-env> before the checks below. It reports which recipe this implementation follows and where it deviates — a class of finding the individual checks cannot produce, because nothing else knows what the shape was supposed to be: a matching stage that runs after validation, a missing export guard, a core master-data role that is never imported.

Two rules when reading it: a finding is actionable, informational usually is not (a recipe's role list is the union across its cluster, so any one tree lacks several). And profile_missing is a real answer — the spine still applies, but no profile describes this target yet. Writing one (payload, auth, master-data roles, coding model) is a single file, not a new recipe.

Phase 1: Discover Everything

Follow the full discovery process in skills/__shared/discovery-checklist.md — use the provided path (or current directory if none given) and read every component listed there before continuing.

Do NOT produce output during this phase. Read everything first.

Phase 2: Check for Common Issues and Produce the Report

With the full picture from Phase 1, check for these issues:

• Broken schema references — fields referenced by extensions, formulas, or rules that don't exist in the schema (orphaned references, typos in field IDs)
• Hardcoded values in extensions — URLs, IDs, or credentials embedded in hook code that should be in hook.settings or hook.secrets
• Undeclared hook secrets — hooks that use secrets (code reading payload["secrets"], settings referencing {secrets.*} / {payload.secrets.*}, or credentialed integrations like Coupa/Workday/SFTP) whose secrets_schema is absent or still the platform default (no declared properties) — whoever rotates the credentials has to guess the key names; recommend declaring them (two shapes — see rossum-reference → Hook Object Fields)
• Missing extension ordering — extensions without run_after when execution order matters (e.g., data enrichment must run before validation)
• Numbered export webhook chain — three or more webhook hooks on the export event whose names start with an ordinal (1., 3., 5.…) and are wired with run_after, typically with a paired "extract response" hook after each call. This works but keeps execution order in a naming convention, so inserting or renumbering a hook silently reorders the export. Report it as a modernization opportunity — one Request Processor hook expresses the same flow as ordered stages — and note any mid-chain formula dependency, which blocks a direct migration (see export-pipeline-reference → One Hook, Not a Chain, and the upgrade skill). Not a defect: do not report a working chain as broken
• Deprecated extensions — Copy & Paste or Find & Replace extensions that no longer work correctly
• Formula field mismatches — formula files that reference schema fields not present in the queue's schema
• Formulas at the length limit — any formulas/*.py file whose character count (not byte count) exceeds or nearly reaches 2000 (comments and blank lines count). Over the limit means the next prd2 push fails with an HTTP 400 that names the schema but not the field; within ~200 characters of it means the next inline comment will break it. Report the count per offending file (see txscript-reference → Formula constraints)
• Broken rule references — rules referencing field IDs that don't exist in the schema
• Contradictory rules — rules where one requires what another forbids
• Environment drift — configuration differences between dev/test/prod environments that look unintentional (not just ID differences)
• Plain-text secrets — credentials, API keys, or secrets committed in plain text
• Engine-binding inconsistencies — for each engine-bound queue (queue.json → engine non-null): captured datapoints with non-empty rir_field_names, with disable_prediction: true, or without a matching engine field name (compare schema datapoint ids against engines/*/engine_fields/*.json name values). The live API rejects these states, so any hit means a stale local tree or a change that will fail on the next push.
• Status filter on an incremental import — an import hook whose request carries both an incremental placeholder (${last_modified_date}, {last_modified_date}, ${window_start}) and a criterion on a field a record can change out of — active/inactive, status, blocked (Coupa import_config.query keys such as "active": "true", NetSuite isInactive in method_args or isinactive = 'F' in SuiteQL, Workday Request_Criteria, a function hook's filters). A record that changes out of the filter is never fetched again and stays in the dataset with its old status, so matching keeps offering it. Report it with the matching configs that read the dataset and whether each one filters the status itself. Not a finding when the field cannot change for a record, or the entry fully replaces the dataset. Detection and repair are in the connector pack (coupa-baseline-reference → Status filters on incremental imports, netsuite-reference → Incremental imports and status filters, workday-reference → Differential sync placeholders)
• Data Storage mismatches — if the rossum-api MCP tools are available, verify MDH matching hook configs against live Data Storage:
  • Use data_storage_list_collections to check that every collection name referenced in matching configs actually exists
  • For each referenced collection, use data_storage_list_indexes and data_storage_list_search_indexes to retrieve its indexes
  • Cross-reference the matching query fields (from hook settings) against the available indexes. Flag fields used in $match, $sort, or $search stages that have no supporting index — these cause full collection scans and degrade matching performance
  • Flag collections that have Atlas Search indexes but whose matching config uses a plain find/aggregate query instead of $search (missed optimization), or vice versa
  • Flag duplicate or redundant indexes on the same collection (waste of storage and write overhead)