What telemetry is captured
The orchestrator records structured chat telemetry events for each request:receivedmilestoneforced_plandeterministic_plan_generatedplan_attempt_failedplan_generatedplan_apply_failedrepair_attemptrepair_generatedtool_callresult
- request id
- session
- requested/effective slug
- model key/model used
- planner source (
openai,anthropic,gemini, ordemo) - prompt hash (stable fingerprint)
- prompt excerpt (short preview)
- prompt length
- intent/op types/op count (when available)
- outcome + error category (when available)
Persistence
Telemetry is persisted to NDJSON so it survives restarts.- Default file:
.data/chat-telemetry.ndjsonin the data directory - Env override:
CHAT_TELEMETRY_FILE - Disable persistence:
CHAT_TELEMETRY_PERSIST=0. It is already off underNODE_ENV=test. - In-memory buffer size:
CHAT_TELEMETRY_LIMIT(default500)
APIs for debugging
These endpoints are served by the standalone server. In library mode, read the NDJSON file or thechat_telemetry lines in the site’s server log instead. The
standalone server does not gate them, and they return prompt excerpts.
1) Raw telemetry stream (filtered)
GET /telemetry/chat
Query params:
limit(default100, max1000)sessionphaseoutcome
2) Review summary for manual test runs
GET /telemetry/chat/review
Query params:
limit(default300, max2000)session
- analyzed count
- applied/failed counts
- failure rate
- failure breakdown by outcome
- failure breakdown by reason category
- top failed prompts (grouped by prompt hash)
- automatic recommendations
UI debug mode (for screenshots)
Enable debug metadata directly in assistant response cards:- Open Settings in the editor’s top bar. On a public demo editor, add
?dev=1to the URL first. - Turn on Developer mode, then the Debug mode toggle it reveals.
- Run the prompt and capture a screenshot.
Debug panel with:
traceIdpromptHashoutcomereasoncategory, and the detail when it differsintentandplannerTier- the model and provider used
opCount,ops, and any skipped ops with the reason each was skipped- tokens and estimated cost
- the timeline of the turn
- prompt excerpt
Standard workflow after manual UI testing
- Use a dedicated session for a test batch (for example:
manual-2026-03-01-a). - Run your manual prompts in UI.
- Pull review summary:
- Inspect top failures:
- high
schema_violation: normalization/repair gaps - high
not_found: slug/block resolution gaps - high
ambiguity: clarification prompts too weak
- high
- Drill into raw events for one problematic prompt hash:
- Convert top failed prompts into regression tests in:
apps/orchestrator/src/nlp-ops.test.ts
Recommended operating rules
- Always run manual tests with an explicit session id.
- Keep a fixed prompt suite for weekly regression checks.
- Add a test for every new recurring failed prompt family.
- Track failure rate trend (
/telemetry/chat/review) before/after changes.
Quick checklist when behavior is wrong
- Did the model fail to produce valid schema?
- Did normalization repair aliases correctly?
- Was deterministic fallback expected but not triggered?
- Was the apply step blocked by not-found or no-effective-change?
- Did clarification context leak across unrelated intents?
”Chat won’t edit one prop on my custom block”
The shape of this report is specific and worth recognising, because every check you would run to diagnose it passes. Symptoms, all at once:POST /chatanswers200withstatus: "info", an emptychangesarray, and a summary that names your block but describes the failure as a styling limitation.POST /opswith the identicalupdate_propspatch applies instantly./blocks/manifestis correct, the block is selected, and the schema is right.- One prop fails and its siblings succeed.
subheadingworks;headingdoes not.
warn:
propName is what the planner asked for and allowedProps is what your block
declares. If propName is a name from Avocado’s own catalogue (title, q,
a, quote) and your block uses a different one, the planner’s output was
rewritten on the way through — see below. If propName is something visual
(backgroundColor, animation), the model genuinely promised a capability the
block does not have, which is the case that message was written for.
Two things to check on your side:
- Is the prop declared? The strip compares against the block’s registered
schema. A prop that only exists behind
.catchall()is not declared, and is stripped even thoughPOST /opswould accept it. Declare every prop you want the chat to reach. - Set
CHAT_ADAPTIVE_SCHEMA_CONTEXT=1. Without it, a single-field edit is sent to the model with no block contracts at all, so it has to guess your prop names from its priors — and its priors are the built-in catalogue. See Block schema contracts.
heading → title on every block type
not literally called Hero, and rewrote question/answer/testimonial/
review inside every list prop of every block, regardless of type. Both now ask
the registry first and only rename when the block cannot take the key the
planner used and can take the one it would be rewritten to. If you are pinned
below 0.3.2 and hit this, upgrading is the fix.