Closes #126018

What Problem This Solves

Slack silently discarded everything after 3,000 characters in legacy interactive replies. The current shared presentation renderer also truncated modern text and context blocks, and its capability check incorrectly rejected content that could have been rendered losslessly. The existing Slack mrkdwn chunker additionally removed whitespace at chunk boundaries and exploded short inline-code spans into separate chunks.

Why This Change Was Made

The fix keeps the current canonical legacyInteractiveReplyToPresentation → buildSlackPresentationBlocks flow. That shared owner now splits both section and context text with the existing Slack-aware mrkdwn chunker, while the capability check recognizes both as natively renderable. Slack's existing reply resolver still owns its 50-block message boundary, and its existing send/accessibility planner still owns complete, bounded screen-reader fallbacks and actual provider posts.

The existing mrkdwn chunker now preserves ordinary boundary whitespace and keeps inline/fenced code together until an actual size boundary; protected Slack entities, links, Unicode surrogate pairs, wrapper-ineligible configured limits, and controls retain their existing contracts. Actual provider-boundary testing also exposed a second owner bug: Slack's outbound payload adapter returned only the final segment's receipt, silently forgetting earlier attachments and provider posts. Its existing media callback and the existing Plugin SDK receipt aggregator now retain every nested physical delivery in order, globally reindex receipt parts, and preserve an earlier question card's exact finalization identity.

Sending a new message can split oversized presentation blocks; editing an existing message cannot. The edit action owner therefore preserves its existing single-message contract: oversized presentation text/context uses the existing complete fallback, and the existing Slack-rendered UTF-8 byte guard rejects updates over 4,000 bytes without silently truncating them. Safe complete edits below that limit still succeed, while send-side native block segmentation remains lossless. No duplicate renderer, new configuration, public API, dependency, or fallback path is introduced.

Production LOC: +68/-40 (net +28). Tests: +323/-30. The positive production delta is necessary to retain every delivered attachment/platform message and its question-card lifecycle metadata at the payload owner, while preserving the distinct unsplittable edit action contract; no new helper, compatibility layer, or alternate transport path is added.

User Impact

Legacy Slack interactive replies and modern Slack presentation text/context no longer lose authored content after 3,000 characters. Long replies keep their order, styling, complete screen-reader text, and exactly one copy of every trailing control. Existing Slack API section, Block Kit message, and accessible fallback limits remain enforced.

Evidence

• Before the production fix, seven focused regressions failed: legacy 3,000-character truncation; modern text/context rejected as unrenderable; both legacy and modern 150,001-character replies failing the 50-block logical boundary; ordinary whitespace disappearing at a section boundary; and 750 short inline-code spans incorrectly expanding into 1,501 chunks.
• Initial renderer fix: node scripts/run-vitest.mjs extensions/slack/src/shared-interactive.test.ts extensions/slack/src/reply-blocks.test.ts extensions/slack/src/format.test.ts extensions/slack/src/channel.test.ts --run — 4 files, 150 tests passed.
• After the additional provider-receipt root cause was exposed: OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/slack/src/channel.test.ts extensions/slack/src/question-finalization.test.ts extensions/slack/src/send.blocks.test.ts --run — 3 files, 126 tests passed, including a new failing-before-fix regression covering media receipt + earlier question receipt + final text receipt, globally indexed parts, preserved final message identity, and original question-card finalization.
• Full hosted Slack suite surfaced four additional sibling-contract regressions before landing. The corrected owner paths were then verified with OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/slack/src/channel.test.ts extensions/slack/src/format.test.ts extensions/slack/src/shared-interactive.test.ts extensions/slack/src/reply-blocks.test.ts extensions/slack/src/message-action-dispatch.test.ts extensions/slack/src/outbound-adapter.test.ts extensions/slack/src/outbound-payload.test.ts extensions/slack/src/question-finalization.test.ts extensions/slack/src/send.blocks.test.ts extensions/slack/src/actions.blocks.test.ts --run — 10 files, 325 tests passed, including 3,001-character text/context edits that remain complete, markup-expanded and multibyte updates that correctly reject above the 4,000-byte edit boundary, all attachment receipt IDs, and bounded native text/context sends.
• The exact hosted extension-test type gate passes locally: node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.extensions.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/extensions-test.tsbuildinfo. Slack SDK's generic Block.type: string is narrowed structurally before reading section/context properties; no casts or any are introduced.
• Independent focused outbound verification: node scripts/run-vitest.mjs extensions/slack/src/channel.test.ts -t 'delivers oversized .* in order across the real Slack outbound adapter' --run — 3 cases passed, covering legacy interactive text, modern presentation text, and modern presentation context.
• Real production Slack WebClient → ephemeral localhost Slack HTTP API, without injected send mocks or live credentials:

{"surface":"interactive","type":"text","inputCharacters":150001,"httpPostCount":51,"receiptPlatformMessageIds":51,"receiptOrderPreserved":true,"receiptIndicesSequential":true,"exactContentPreserved":true,"maximumAccessibilityFallbackCharacters":3000,"privateCallbackExposed":false,"actionCount":1}
{"surface":"presentation","type":"text","inputCharacters":150001,"httpPostCount":51,"receiptPlatformMessageIds":51,"receiptOrderPreserved":true,"receiptIndicesSequential":true,"exactContentPreserved":true,"maximumAccessibilityFallbackCharacters":3000,"privateCallbackExposed":false,"actionCount":1}
{"surface":"presentation","type":"context","inputCharacters":150001,"httpPostCount":51,"receiptPlatformMessageIds":51,"receiptOrderPreserved":true,"receiptIndicesSequential":true,"exactContentPreserved":true,"maximumAccessibilityFallbackCharacters":3000,"privateCallbackExposed":false,"actionCount":1}
{"surface":"actual-provider-50-block-boundary","inputCharacters":3001,"httpPostCount":2,"receiptPlatformMessageIds":2,"blocksPerMessage":[50,2],"exactContentPreserved":true,"maximumAccessibilityFallbackCharacters":3000,"privateCallbackExposed":false,"actionCount":1}

The 51 HTTP posts for 150,001 characters are intentional: Slack screen readers consume complete top-level text, Slack recommends 4,000 characters, and its documented truncation boundary is 40,000. Existing native-data/accessibility planning therefore subdivides logical 50-block batches when the 40,000-character hard boundary is crossed, without losing accessible content or private callback isolation. Existing covered behavior below the hard boundary, including complete fallbacks above 8,000 characters, remains unchanged. The independent 49-divider + 3,001-character case confirms the actual Slack HTTP provider still receives exactly two messages with 50 and 2 blocks at the Block Kit boundary. Official Slack limits: 3,000 characters per section and 50 blocks per message.

• Targeted formatting and 12 changed-file guards passed, including conflict markers, max-lines ratchet, assertion safety, doctor closure tests, dependency pins, coercion helpers, and extension boundary guards. The broad remaining changed gate was intentionally stopped to reserve shared host capacity; exact-head hosted CI owns full extension typechecking and lint.
• Fresh structured autoreview: clean. Independent maintainer verification personally reran both real localhost Slack HTTP proofs and confirmed canonical ownership, private callback isolation, accessibility, all sibling presentation surfaces, and primary contributor attribution.
• No external Slack workspace or real Slack credentials were used.

Original contribution by @original4422 (Daniel Peng), preserved as the primary Git author.