Edit Template Questionnaire vs ContractData / Intake Key Card

What This Skill Debugs

On template contracts, questionnaire answers can be written to ContractData (driving the Intake Form Responses key card and contract document) while "Edit Template Questionnaire" pre-fills from QuestionnaireResponse via a separate read path. If the initial submission flow creates or updates completed ContractData but does not create or upsert a matching QuestionnaireResponse row for that contract + frozen questionnaire mapping, the edit modal shows stale, empty, or template-default values even though the rest of the product shows the correct answers.

This fails silently — no error logs; the GET path simply returns missing or old QuestionnaireResponse data.

Secondary pattern (partial save): The Intake Form Responses key card is driven by the latest fully completed ContractData (is_completed = true). Partial saves (source such as partial-save, is_completed = false) may not appear on the key card until the user fully completes and submits the questionnaire. Do not confuse that with the ContractData vs QuestionnaireResponse split — confirm which case applies using ContractData ordering and completion flags.

Not the same as integration hidden-question data loss on edit (questionnaire-hidden-variable-data-loss), which wipes ContractData after a questionnaire edit due to visibility rules.

Available MCP Tools

BigQuery — ContractData rows (primary signal)

Run BQ queries one at a time — parallel execute_sql calls often return 500 errors.