Mastra observability and the OTEL bridge remain compatible with the upgraded core runtime so execution traces continue to reach the existing telemetry backend.Degradedlow confidence
Verifier did not provide tied failure evidence for degraded, so Libra is keeping it inconclusive instead of moving the card. Original assessment: Post-deploy staging telemetry confirms Mastra execution spans are still emitted: 89 STATUS_CODE_OK spans across 6 traces, plus 14.
staging, checked Sep 20, 2026, 9:07 PM
Client-send event execution failures are emitted as structured logs containing the conversation ID, optional run ID, and normalized error text.Inconclusivelow confidence
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
prod, checked Sep 18, 2026, 2:36 PM
Nested and family-tool delegations invoke child tools through the Mastra-compatible callTool path so current execute signatures, request context, and validation behavior are preserved.Inconclusivelow confidence
Verification reached its 120s wall-clock budget before a tied verdict. Libra is keeping this intent verifying until the next check.
prod, checked Sep 18, 2026, 2:38 PM
Mastra agent, workflow, and tool executions continue exporting traces through the existing observability and OTel bridge after the package upgrade.Inconclusivelow confidence
Unable to verify the intended behavior: the available CloudWatch queries returned no concrete post-deploy Mastra agent, workflow, or tool execution operations, and OTEL/Axiom spans are unavailable or stale. Positive runtime evidence required by the contract is therefore absent.
prod, checked Sep 18, 2026, 3:17 PM
The server runs its agents, workflows, and tools on the aligned stable Mastra 1.x packages instead of the pre-1.0 beta APIs.Inconclusivelow confidence
Verification reached its 120s wall-clock budget before a tied verdict. Libra is keeping this intent verifying until the next check.
prod, checked Sep 18, 2026, 3:19 PM
Tool results that do not match their declared outputSchema fail with a Mastra ValidationError instead of being silently accepted.Inconclusivemedium confidence
Post-deploy CloudWatch telemetry shows substantial Mastra tool activity: 33,126 logged tool calls in worker-service and 2,600 in api-service, plus 69 structured operations including 8,940 agent-execution.slot.acquire events. However, there were 0 exact ValidationError logs and.
prod, checked Sep 18, 2026, 4:17 PM
Libra measured 9 of 11 production surfaces on prod. 2 surfaces had no requests at all. Libra checks hourly for 3 days after each deploy.
Summary
Upgrades Mastra from 1.0.0-beta.19 to 1.67.0 (see apps/server/docs/design/mastra-v1-upgrade.md for the full scoping/risk assessment written before starting this).
Drops @mastra/memory and @mastra/pg entirely , both confirmed to have zero import sites anywhere in the repo.
Ran npx @mastra/codemod@latest v1 , zero changes needed; this codebase's tool/agent/observability shapes were already ahead of the beta→1.0 API transition.
Real breaks found and fixed
Tool.execute became optional and its return type gained void (Output | ValidationError | void) , added a shared callTool() helper (apps/server/src/mastra/utils/call-tool.ts) for the ~110 call sites across the codebase that invoke another tool's execute directly (family-tool facades, dispatch/workflow code), rather than through Mastra's own agent-loop.
Tools with no outputSchema now type their result as unknown instead of any , cast to each tool's real return shape, read directly off its implementation.
RequestContext<T>'s generic became invariant (a new generic set()), so a specifically-typed RequestContext<Shape> and a bare RequestContext are no longer mutually assignable in either direction. Added eraseRequestContext() (apps/server/src/mastra/context/values.ts) for the specific→bare direction; switched a couple of reverse-direction sites to getRaw/setRaw.
Agent.stream()'s top-level threadId/resourceId were removed in favor of a nested memory: { thread, resource } option.
Dropped a dead resourceId param on roadmapAgent.generate() , that agent has no memory configured, so it was already inert before this upgrade.
Confirmed Agent.__registerMastra() (an undocumented private method this codebase relies on for tracing registration, flagged as the top risk in the scoping doc) is unchanged at 1.67.
Verification
Typecheck: clean (pnpm --filter @zero/server run types)
Tests: clean , full sweep across src/mastra/{tools,utils,workflows,skills,mcp,context} + src/services/playbook: 237 test files / 3,621 tests passing (only pre-existing skips)
Manual dev smoke test: ran the full local dev stack, exercised /roadmap-chat and /chat (multi-turn, multi-tool-call CRM query) against a real dev DB , correct results, no errors , and confirmed via Axiom that Mastra spans (invoke_agent, chat claude-sonnet-4-6, etc.) land correctly nested under the app's existing OTel spans with real gen_ai.* attributes (token usage, model), matching the pre-upgrade observability design.
Test plan
Scoped typecheck clean
Full mastra subtree test sweep clean
Manual dev smoke test: roadmap chat + multi-tool chat conversation against real data
Confirmed traces land correctly in Axiom post-upgrade
Deploy to staging and watch trace volume/error rates before merging further (per the design doc's verification plan , the dominant failure mode this investigation surfaced is "runs without erroring, silently wrong" rather than a crash, so staging observation matters more than usual here)
