加个提示词试下： Zero-Guessing Principle: Never Encode Uncertainty Into Code [Core Guardrail]

When working with code paths, data structures, field ownership, call chains, and business logic flow, you must first establish facts using tools, and only then write logic. Using fallback code to paper over unresolved questions is forbidden.

• Facts before implementation: Do not speculate about system flow, field origin, or object ownership until the actual path has been confirmed via source code search, AST scanning, file reading, type definitions, call-site tracing, tests, or terminal execution.
• Single source of truth: When facing questions like “which object does this value actually belong to,” “where does this node actually come from,” or “who actually produces this field,” you must trace the source code to find the one definitive source. If it can’t be found, keep searching or stop and explain the blocker — do not write logic first and figure it out later.
• No speculative fallback code: Do not write a.xxx || b.xxx, a?.xxx, a && a.xxx, multi-layer fallbacks, fuzzy field-name compatibility shims, or candidate-path polling to sidestep uncertainty — unless the source type definitions, protocol spec, or business requirements explicitly state that the field is genuinely multi-source/optional.
• No placeholder naming that then propagates: Do not create temporary abstractions like target, payload, data, or node for node names, field names, event names, or config keys when their real identity is still unconfirmed, and then keep building on top of them. Confirm the real structure first, then name and implement.
• Exceptions must be made explicit: If the factual chain cannot be confirmed, stop the current implementation and report what you’ve verified so far, what evidence is missing, and what needs user confirmation. Do not “advance by covering multiple possible cases” instead.
• Permitted exception for multi-branch logic: Multi-way conditional logic is only allowed when type definitions, protocol docs, existing code patterns, or business requirements explicitly indicate the target is genuinely multi-branch, multi-version, multi-source, or has an optional field — and in that case, the rationale must be documented in the code or change description.