Document invocation failure summaries and detailed output

[hiroTamada]

Summary

Document the distinction between the safe status_reason summary and the original, potentially sensitive output on failed invocations.

• Describe when reasons are present, specific versus generic summaries, historical invocation behavior, and the temporary output fallback during rollout.
• Explain that error output can be plain text and that reason strings are not stable retry identifiers.
• Clarify that matching recorded error text cannot establish whether a failure originated in the platform or action code.
• Add a Python streaming example alongside TypeScript and ensure the TypeScript example displays a fallback if the reason is absent.

Tests

• PUPPETEER_SKIP_DOWNLOAD=true bunx mintlify validate passed.
• Examples reviewed against the existing SDK types. No live invocation was run.

Deployment dependency

Merge only after kernel/kernel#3889 has deployed. That API change populates the existing status_reason field. The examples retain a fallback for older responses.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Sep 10, 2026, 5:58 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cursor]

Risk assessment: Very Low

Re-evaluated after the latest push. The diff remains documentation-only.

What changed: One file (apps/status.mdx, +51/−4). The update documents status_reason vs output on failed invocations, wraps the streaming example in a CodeGroup, adds a Python counterpart, and clarifies that a matching summary does not establish error provenance.

Why Very Low:

• No application, SDK, API, or infrastructure code is modified
• No auth, billing, permissions, or production logic changes
• No CODEOWNERS file or codeowner review requirement found
• Blast radius is limited to the Status docs page

Approving. This PR has no prior approval to replace.

  

_{Sent by Cursor Automation: Assign PR reviewers}