docs(vision,agents): layer calibration, interface-on-demand, telemetry opt-in, whole-document guidance rules

AGENTS.md

@@ -132,6 +132,7 @@ Skills own workflows; root owns hard policy and routing. Product direction and m
 - Prompt cache: deterministic ordering for maps/sets/registries/plugin lists/files/network results before model/tool payloads. Preserve old transcript bytes when possible.
 - Model-context budget: every injected prompt/tool-schema/context item is bounded with a hard cap; no unbounded items. New model-visible text that can cross ~1K tokens is a P0 review flag needing explicit justification. Context builds incrementally; only compaction rewrites history.
 - Tool/prompt descriptions never statically name tools from other toolsets/plugins; gating turns the reference into hallucination bait. Needed cross-references are injected at definition-build time from what is actually available. Descriptions state capability, not implementation; no marketing words.
+- Guidance the model must apply in full (skills, playbooks, prompt instructions) is served whole: no offset/limit or windowed-read parameters on those tools. Given a window, the model treats the first window as the whole document.
 - Prompt-state mutations (skills/tools/memory) default to deferred cache invalidation — effect next session; immediate invalidation is an explicit opt-in.
 - Agent tool schema cleanup: remove stale args cleanly; no hidden compat for model-facing params just to avoid churn.
 

VISION.md

@@ -58,6 +58,10 @@ Canonical security policy and reporting:
 
 We prioritize secure defaults, but also expose clear knobs for trusted high-power workflows.
 
+Privacy follows the same default rule.
+OpenClaw sends no usage analytics, tracking identifiers, or attribution tags unless the operator turned that on themselves.
+A change that needs such signals waits until an explicit user-facing opt-in exists for them.
+
 ## Plugins & Memory
 
 OpenClaw has an extensive plugin API.
@@ -65,6 +69,14 @@ Core stays lean; optional capabilities should usually ship as plugins.
 We are generally slimming down core while expanding what plugins can do.
 If a useful feature cannot be built as a plugin yet, we welcome PRs and design discussions that extend the plugin API instead of adding one-off core behavior.
 
+Two layers, two bars.
+The core carries a per-call tax: each core tool, prompt line, and config key reaches every operator on every model request, so additions there face the strictest scrutiny.
+Plugins, skills, channels, and apps carry no such tax, and we want that surface to keep growing.
+When our contribution rules read as hostile to a feature, re-check the layer: usually they object to where it plugs in, not to the feature existing.
+
+Recurring demand defines interfaces.
+Once several independent PRs or requests wire in the same kind of capability, the right response is a contract, not a queue of merges: land the seam in core or the SDK, port the bundled implementation onto it, and let the remaining candidates ship as plugins against it.
+
 There are two broad plugin styles:
 
 - Code plugins run OpenClaw plugin code and are appropriate for deeper runtime extension.