[{"slug":"ZV-2026-1556","server_name":"api.flowcastle.ai","severity":"breaking","title":"api.flowcastle.ai: Enum value DEBUG removed from level on query_flow_logs.","summary":"[safe] Tool get_survey_results was added. [safe] Description of apply_actions changed (13% word delta). [risky] Optional field includeCore was added to get_action_schema; may shift model behaviour. [risky] Description of get_design_guidelines changed (36% word delta). [risky] Optional field sections was added to get_design_guidelines; may shift model behaviour. [breaking] Enum value DEBUG removed from level on query_flow_logs.","changes":[{"kind":"tool_added","tool":"get_survey_results","detail":"Tool `get_survey_results` was added.","severity":"safe"},{"kind":"description_changed","tool":"apply_actions","after":"Validate and apply a batch of flow-builder actions — the single write path for editing flows, blocks, variables, broadcasts, sequences, and folders. Call this directly; a separate validate_actions call beforehand is unnecessary. Broadcasts have no dedicated tool and are managed here: create_broadcast makes a DRAFT (it owns its flow via data.flowId — add the message blocks in the same batch, no separate create_flow), optionally with create_recurrence_schedule + attach_recurrence_to_broadcast for recurring; a later update_broadcast with status SCHEDULED (and scheduledAt for one-shots) is what actually schedules/sends it. The full recipe is in get_action_schema under `broadcasts`. DESTRUCTIVE: the batch may include delete_block, delete_link, delete_flow, delete_variable, delete_operation, and delete_broadcast. Confirm with the user before applying deletions. delete_operation also removes the operation's hidden graph flow and run history; delete_broadcast also removes the broadcast's delivery history and its content flow, and neither can be undone. IRREVERSIBLE SIDE EFFECTS: run_operation starts a real operation run, which may send broadcasts to real contacts and write application variables. It cannot be undone or recalled, is not idempotent, and is available only through this tool — confirm with the user before applying a batch containing one, and never blindly retry a timed-out call that did. Validation always runs first and an invalid batch applies nothing. If an action fails mid-batch, execution stops and the server tries to undo the steps already applied: `reverted: true` means nothing from the batch remains (fix the reported error and resend); `reverted: false` on a failure means part of it may still be applied (`errorClass: \"partial_write\"`) — re-read state with get_flow_context before retrying rather than blindly resending the batch. `errorClass` is one of validation | rule | conflict | permission | partial_write | unknown. Not idempotent — resending a batch of create_* actions creates duplicates. Read get_action_schema for the action contract and get_design_guidelines before any structural edit. Returns { success, validated, reverted, errorClass (on failure), changes, errors, warnings, actionId } plus an idRemap mapping placeholder ids to the real ids that were created. Applying does NOT publish. Edits land on the draft graph and connected bots keep serving the previously published version until deploy_application runs — finish a round of edits, then deploy.","before":"Validate and apply a batch of flow-builder actions — the single write path for editing flows, blocks, variables, broadcasts, sequences, and folders. Call this directly; a separate validate_actions call beforehand is unnecessary. Broadcasts have no dedicated tool and are managed here: create_broadcast makes a DRAFT (it owns its flow via data.flowId — add the message blocks in the same batch, no separate create_flow), optionally with create_recurrence_schedule + attach_recurrence_to_broadcast for recurring; a later update_broadcast with status SCHEDULED (and scheduledAt for one-shots) is what actually schedules/sends it. The full recipe is in get_action_schema under `broadcasts`. DESTRUCTIVE: the batch may include delete_block, delete_link, delete_flow, delete_variable, delete_operation, and delete_broadcast. Confirm with the user before applying deletions. delete_operation also removes the operation's hidden graph flow and run history; delete_broadcast also removes the broadcast's delivery history and its content flow, and neither can be undone. IRREVERSIBLE SIDE EFFECTS: run_operation starts a real operation run, which may send broadcasts to real contacts and write application variables. It cannot be undone or recalled, is not idempotent, and is available only through this tool — confirm with the user before applying a batch containing one, and never blindly retry a timed-out call that did. Validation always runs first and an invalid batch applies nothing. Execution is NOT atomic, however: if an action fails mid-batch, the actions before it stay applied and execution stops — re-read state with get_flow_context before retrying rather than blindly resending the batch. Not idempotent — resending a batch of create_* actions creates duplicates. Read get_action_schema for the action contract and get_design_guidelines before any structural edit. Returns { success, changes, errors, warnings, actionId } plus an idRemap mapping placeholder ids to the real ids that were created. Applying does NOT publish. Edits land on the draft graph and connected bots keep serving the previously published version until deploy_application runs — finish a round of edits, then deploy.","detail":"Description of `apply_actions` changed (13% word delta).","severity":"safe","descriptionDelta":0.12962962962962965},{"kind":"input_property_added","path":"inputSchema.properties.includeCore","tool":"get_action_schema","after":{"type":"boolean","description":"Leave this out on your FIRST detail call: that call must return the batch contract, placeholder rules and always-on invariants (~9k characters), and the index does not contain them. Pass false only on LATER detail calls in the same session, to avoid receiving them again."},"detail":"Optional field `includeCore` was added to `get_action_schema`; may shift model behaviour.","severity":"risky"},{"kind":"description_changed","tool":"get_design_guidelines","after":"Return the flow-design rules that validation does NOT enforce: when to split a branch into its own flow, how navigation and menus must be wired, and worked examples. Read-only, needs no API key. Called with NO arguments it returns a compact INDEX: the short rules every batch needs, in full, plus every other section and example with one line saying when you need it. Call it a second time naming only the ones this change touches — { sections: [\"flow-link-navigation\",\"example-flow-link-navigation\"] } — to get them in full. Read this before any structural edit (new blocks, new branches, new flows) — a batch can pass validate_actions and still be badly structured, and these rules are what catch that.","before":"Return the flow-design rules that validation does NOT enforce: when to split a branch into its own flow, how navigation and menus must be wired, and worked examples. Read-only, takes no arguments, and needs no API key. Read this before any structural edit (new blocks, new branches, new flows) — a batch can pass validate_actions and still be badly structured, and these rules are what catch that.","detail":"Description of `get_design_guidelines` changed (36% word delta).","severity":"risky","descriptionDelta":0.3647058823529412},{"kind":"input_property_added","path":"inputSchema.properties.sections","tool":"get_design_guidelines","after":{"type":"array","items":{"type":"string"},"description":"Section and example ids from the index whose full text you need (e.g. [\"input-collection\",\"example-explicit-listener\"])."},"detail":"Optional field `sections` was added to `get_design_guidelines`; may shift model behaviour.","severity":"risky"},{"kind":"enum_value_removed","path":"inputSchema.properties.level","tool":"query_flow_logs","before":"DEBUG","detail":"Enum value `DEBUG` removed from `level` on `query_flow_logs`.","severity":"breaking"}],"published_at":"2026-09-28T20:58:19.468Z"}]