mirror of
https://github.com/openclaw/openclaw.git
synced 2026-05-06 11:20:43 +00:00
docs: batch sentence-case headings across high-Title-Case offenders
- pi.md: 9 H2 + 14 H3 (Package Dependencies, File Structure, Tool Pipeline, etc.) - cli/hooks.md: 6 H2 (List All Hooks, Get Hook Information, etc.) - plugins/message-presentation.md: 8 H2 (Producer Examples, Renderer Contract, etc.) - plan/ui-channels.md: 7 H2 (Non Goals, Target Model, Refactor Steps, etc.) - install/ansible.md: 6 H2 + 1 H3 (What You Get, Quick Start, etc.) Mintlify anchor generation prefers sentence case for predictable URLs.
This commit is contained in:
@@ -91,7 +91,7 @@ Select semantics:
|
||||
select support.
|
||||
- If a channel does not support selects, fallback text lists the labels.
|
||||
|
||||
## Producer Examples
|
||||
## Producer examples
|
||||
|
||||
Simple card:
|
||||
|
||||
@@ -175,7 +175,7 @@ Pinned delivery with explicit JSON:
|
||||
}
|
||||
```
|
||||
|
||||
## Renderer Contract
|
||||
## Renderer contract
|
||||
|
||||
Channel plugins declare render support on their outbound adapter:
|
||||
|
||||
@@ -206,7 +206,7 @@ renderer can make interactive, not every native platform limit. Renderers still
|
||||
own platform-specific limits such as maximum button count, block count, and
|
||||
card size.
|
||||
|
||||
## Core Render Flow
|
||||
## Core render flow
|
||||
|
||||
When a `ReplyPayload` or message action includes `presentation`, core:
|
||||
|
||||
@@ -222,7 +222,7 @@ When a `ReplyPayload` or message action includes `presentation`, core:
|
||||
Core owns fallback behavior so producers can stay channel-agnostic. Channel
|
||||
plugins own native rendering and interaction handling.
|
||||
|
||||
## Degradation Rules
|
||||
## Degradation rules
|
||||
|
||||
Presentation must be safe to send on limited channels.
|
||||
|
||||
@@ -246,7 +246,7 @@ Examples:
|
||||
The main exception is `delivery.pin.required: true`; if pinning is requested as
|
||||
required and the channel cannot pin the sent message, delivery reports failure.
|
||||
|
||||
## Provider Mapping
|
||||
## Provider mapping
|
||||
|
||||
Current bundled renderers:
|
||||
|
||||
@@ -295,7 +295,7 @@ import {
|
||||
|
||||
New code should accept or produce `MessagePresentation` directly.
|
||||
|
||||
## Delivery Pin
|
||||
## Delivery pin
|
||||
|
||||
Pinning is delivery behavior, not presentation. Use `delivery.pin` instead of
|
||||
provider-native fields such as `channelData.telegram.pin`.
|
||||
@@ -312,7 +312,7 @@ Semantics:
|
||||
Manual `pin`, `unpin`, and `pins` message actions still exist for existing
|
||||
messages where the provider supports those operations.
|
||||
|
||||
## Plugin Author Checklist
|
||||
## Plugin author checklist
|
||||
|
||||
- Declare `presentation` from `describeMessageTool(...)` when the channel can
|
||||
render or safely degrade semantic presentation.
|
||||
@@ -328,7 +328,7 @@ messages where the provider supports those operations.
|
||||
- Do not expose new provider-native card/block/component/button fields through
|
||||
the shared message action schema.
|
||||
|
||||
## Related Docs
|
||||
## Related docs
|
||||
|
||||
- [Message CLI](/cli/message)
|
||||
- [Plugin SDK Overview](/plugins/sdk-overview)
|
||||
|
||||
Reference in New Issue
Block a user