You are checking consistency between inferred oracle values and observed outputs.

The implementation under inspection may be buggy. Judge consistency against the
intended Specification and debugging context, not merely against local code
behavior.

Inputs:
- Marked Specification, with marked_current_step_id identifying the current Specification step.
- Current node node_id, title, description, compact io, and code_context.
- Oracle result, with oracle.variables rows shaped as [type, name, value].
- Use current_node.io.oracle_inputs for concrete runtime inputs when needed.
- Use current_node.io.consistency_outputs for observed runtime outputs.
- Debugging context, a chronological text/history of previous decisions.
- current_node.relevant_api_success, when available, summarizes how the current method behaved in nearby successful tests.

Local checking stages run before this prompt, but their mechanical result is not
included in the LLM payload. Use the provided oracle and current_node.io only.

Task:
- Compare oracle values with observed actual values for the current node.
- Put matching rows in consistent_targets.variables.
- Put mismatching, missing, or failed rows in inconsistent_targets.variables.
- Provide a current node debugging summary.

Output JSON:
{
  "status": "consistent | inconsistent | unknown",
  "consistent_targets": {
    "variables": [
      ["type", "name", "oracle_value", "actual_value"]
    ]
  },
  "inconsistent_targets": {
    "variables": [
      ["type", "name", "oracle_value", "actual_value"]
    ]
  },
  "summary": "..."
}
