d7627d6f4c
* refactor(prompt): plain inbound context labels with a provenance marker
Replaces trust-worded inbound context labels ("(untrusted metadata)",
"(untrusted, for context)") with plain labels plus a fixed provenance
marker suffix appended to every OpenClaw-injected context header.
Detection keys on the marker, not label text, so strippers stay correct
across UI, TUI, replay, /trace segmentation, memory recall, and the Swift
chat preprocessor. Drops sanitizeInboundSystemTags in favor of the marker
boundary plus trusted system-prompt narration.
Renames the untrusted-named plugin SDK context identifiers to
channel-provenance names, keeping deprecated aliases registered for
removal after 2026-09-08.
Adds `openclaw doctor --fix` migrations that rewrite legacy inbound
labels in stored SQLite transcripts and purge legacy envelope-
contaminated LanceDB recall rows.
* fix(ci): resolve gate failures for plain inbound context labels
- doctor sqlite readers: open read-only connections via openNodeSqliteDatabase
so the Kysely connection-boundary guardrail holds; unexport the now-internal
transcript snapshot type (Knip unused-export gate).
- compat registry: split the record table into registry-records.ts and
plugin-sdk-subpath-records.ts. The new compat record pushed registry.ts past
the 700-line oxlint cap; suppressions are disallowed, so follow the existing
sibling record-module pattern. Public exports and PluginCompatCode literals
unchanged.
- acp-runtime test: assert current finalization behavior (newline normalization
only). The bracket de-fang and System: rewrite it expected were removed with
sanitizeInboundSystemTags; forged system lines are neutralized at the
system-event queue, the single chokepoint feeding the System:-per-line render.
- regenerate docs_map and the plugin SDK API baseline manifest.
* fix(prompt): harden inbound context label migration and drop in-band sanitizer
Review follow-ups on the plain-label + provenance-marker change:
- Remove src/security/system-tags.ts. Rewriting inbound text to neutralize
look-alike `System:`/`[System]` markers corrupted legitimate user text and is
not a real injection boundary; role separation plus external-content wrapping
is. Explicit product decision, recorded at the system-event queue.
- Narrow the LanceDB legacy-row purge so it cannot delete benign memories. It
now requires a complete known legacy sentinel line, a legacy label followed by
a fenced JSON body, or the complete legacy external-content header. The prior
predicates matched ordinary prose such as `Notes (untrusted metadata):`, and
deletion is irreversible.
- Make explicit-empty canonical ChannelStructuredContext win over the deprecated
alias via a present/absent result instead of collapsing `[]` to undefined.
- Keep `\r?` in the active-memory doctor rule. It is the only rule spanning the
header's line break, migrated assistant rows skip newline normalization, and
without it the marked-header replace wins and the body strips to empty. Added
a CRLF regression test.
- Fix stale comments that described removed behavior, and cover the Swift
prose-block strip path.
Claude-Session: https://claude.ai/code/session_01WNzsPddQmxy9Y7jKD4wAxH
3.5 KiB
summary, read_when, title
| summary | read_when | title | ||
|---|---|---|---|---|
| Channel location parsing and portable outbound location payloads |
|
Channel location parsing |
OpenClaw normalizes shared locations from chat channels into:
- terse coordinate text appended to the inbound body, and
- structured fields in the auto-reply context payload. Channel-provided labels, addresses, and captions/comments are rendered into the prompt by the shared untrusted metadata JSON block, not inline in the user body.
Currently supported:
- LINE (location messages with title/address)
- Matrix (
m.locationwithgeo_uri) - Telegram (location pins + venues + live locations)
- WhatsApp (
locationMessage+liveLocationMessage)
Text formatting
Locations are rendered as friendly lines without brackets. Coordinates use six decimal places; accuracy is rounded to whole meters:
- Pin:
📍 48.858844, 2.294351 ±12m
- Named place (same line; the name/address go to the metadata block only):
📍 48.858844, 2.294351 ±12m
- Live share:
🛰 Live location: 48.858844, 2.294351 ±12m
If the channel includes a label, address, or caption/comment, it is preserved in the context payload and appears in the prompt as fenced untrusted JSON (fields are omitted when absent):
Location:
```json
{
"latitude": 48.858844,
"longitude": 2.294351,
"accuracy_m": 12,
"source": "place",
"name": "Eiffel Tower",
"address": "Champ de Mars, Paris",
"caption": "Meet here"
}
```
Context fields
When a location is present, these fields are added to ctx:
LocationLat(number)LocationLon(number)LocationAccuracy(number, meters; optional)LocationName(string; optional)LocationAddress(string; optional)LocationSource(pin | place | live)LocationIsLive(boolean)LocationCaption(string; optional)
When the channel does not set an explicit source, OpenClaw infers it: live shares become live, locations with a name or address become place, everything else is pin.
The prompt renderer treats LocationName, LocationAddress, and LocationCaption as untrusted metadata and serializes them through the same bounded JSON path used for other channel context.
Outbound payloads
The message tool and Plugin SDK use the same NormalizedLocation shape for portable outbound locations. A coordinate-only payload represents a pin. Channels with native venue support may map name plus address to a venue card.
Telegram currently exposes this through message(action="send"). Its first implementation is deliberately standalone: location payloads cannot be mixed with text or media, and incomplete venue pairs fail instead of silently dropping a name or address. Unsupported channels do not advertise the location parameter.
Channel notes
- LINE: location message
title/addressmap toLocationName/LocationAddress; no live locations. - Matrix:
geo_uriis parsed as a pin location; theu(uncertainty) parameter maps toLocationAccuracy, the event body populatesLocationCaption, altitude is ignored, andLocationIsLiveis always false. - Telegram: venues map to
LocationName/LocationAddress; live locations are detected vialive_period. - WhatsApp:
locationMessage.commentandliveLocationMessage.captionpopulateLocationCaption.