"What is Mastra's defining contribution?"	Two: (1) Observability as a FIRST-CLASS PRIMITIVE — built into every component's interface from the start, not a wrapper added later. (2) Explicit read/write memory tier separation. TypeScript-first SDK.	harness-engineering::dd14::recall
"What is the wrapper pattern (Module 1.4) and what is its weakness?"	withObservability(agent, { tracer }) — observability applied externally. The component knows nothing about tracing. Weakness: the wrapper only sees boundary crossings — internal decisions are invisible — and the wrapper can drift out of sync as the component evolves.	harness-engineering::dd14::recall
"What is the native pattern (Mastra) and how does it differ from the wrapper?"	component.run(input) → { result, events[] }. The component OWNS its event emission. Every internal decision is an event the component emits as part of its contract. Observability is INSIDE the component, not applied around it.	harness-engineering::dd14::recall
"What three properties does native emission buy you?"	(1) Internal decisions visible — why a tool was chosen, what was pruned. (2) Contract cannot drift — emission is part of the interface, tracks the component or fails to compile. (3) Every consumer gets the same stream — no 'telemetry says X but logs say Y' gap.	harness-engineering::dd14::recall
"What is the cost of the native pattern?"	Native only pays off when components are native. Bring your own components (off-the-shelf LLM wrapper, custom tool) and you bring your own observability gap — the event stream shows a hole wherever your non-native component runs.	harness-engineering::dd14::analysis
"What is Mastra's explicit read/write memory boundary?"	Read memory and write memory are SEPARATE interfaces: readMemory(query) and writeMemory(entry). This makes Module 4.3's write-gating natural — restricting writes is an interface-level decision (withhold the write interface), not a policy bolt-on.	harness-engineering::dd14::recall
"Why does the read/write split make write-gating 'structural' rather than 'advisory'?"	An agent that never receives the write-memory interface cannot poison memory — not because a policy forbids it, but because there is no handle to call. The defense is in the type system, not in a policy layer that can be bypassed or misconfigured.	harness-engineering::dd14::analysis
"What is the structural parallel between Mastra (DD-14) and NemoClaw (DD-09)?"	Both make a security-relevant decision a type-level (architectural) one. NemoClaw: credentials outside the sandbox — no handle to leak. Mastra: write-memory interface withheld — no handle to poison. Different layers (sandbox vs memory), one principle: remove the handle, don't write a policy.	harness-engineering::dd14::analysis
"On which modules does Mastra score 5/5?"	Module 10 Observability (best built-in observability primitives — native event emission) and Module 4.3 Write-gating (interface-level, not policy-level — the reference). Two 5/5 peaks — the observability-and-memory shape.	harness-engineering::dd14::recall
"What is Mastra's score and what is the shape interpretation?"	34/60. The shape is observability-and-memory, NOT production-readiness. Two 5/5 peaks (Module 10, Module 4.3). Production gaps: Module 5 Sandbox 1/5, Module 9 Verification 1/5, Module 11 Security 2/5. Pair Mastra with a harness that has the security modules.	harness-engineering::dd14::analysis
"Compare Mastra's memory to CrewAI's (DD-12) crew-scoped shared memory."	CrewAI: every agent shares one store, can write what every other agent reads — write-gating unavailable by default (no separate write interface to withhold). Mastra: read and write are separate interfaces — witholding write is structural. Mastra is the cleaner abstraction.	harness-engineering::dd14::analysis
"What does 'events ARE the cross-layer contract' mean, and which two harnesses converge on it?"	DD-21 (Tau) and Mastra. Tau makes the typed event union the observability layer for a teaching harness. Mastra makes native emission the primitive for a production SDK. Different emphasis, same conclusion: events belong in the component, not around it.	harness-engineering::dd14::analysis
"What is the OpenHarness-vs-Mastra observability axis?"	OpenHarness (DD-13): inspectability-as-product, human-readable logs, research reference, Module 10 4/5. Mastra (DD-14): native event emission, machine-readable structured events, production reference, Module 10 5/5. Same goal (see what the agent did), different objective functions.	harness-engineering::dd14::analysis
"Name 3 things Mastra does better than any other harness."	(1) Observability as first-class (built-in native emission, not wrapped) — Module 10 reference. (2) Explicit read/write memory separation (cleanest abstraction) — Module 4.3 reference, only roster harness with structural write-gating. (3) TypeScript-first DX (best TS SDK experience).	harness-engineering::dd14::recall
"Name 3 things to fix in Mastra."	(1) Add a sandbox — none present (compare DD-11 Agents SDK's 7-provider abstraction). (2) Broaden integrations — fewer than OpenCode/Aider. (3) Add a SECURITY.md and threat model — the read/write split and native observability are security assets that deserve explicit framing.	harness-engineering::dd14::recall
"What is the anti-pattern of 'assuming native observability covers bring-your-own components'?"	The native pattern only pays off when components are native. Off-the-shelf LLM wrappers or custom tools do not emit Mastra's events — you inherit their observability gap. The event stream shows a hole wherever your non-native component runs. Build native or use a wrapper-based SDK.	harness-engineering::dd14::analysis
"What is the anti-pattern of 'treating the read/write split as sufficient security'?"	The split makes memory-poisoning defense structural at the MEMORY layer only. It says nothing about the sandbox layer (1/5) or verification layer (1/5). An agent without write-memory can still call bash without containment. Read the split as one structural defense, not a security model.	harness-engineering::dd14::analysis
"For MLSecOps, what two substrates does Mastra provide that are hardest to retrofit?"	(1) A structural write boundary — memory-poisoning defense in the type system, not in a policy layer. (2) An intrinsic observability stream — every internal decision is an event a SIEM/alerting layer can consume. The gap: no sandbox or threat model to frame them.	harness-engineering::dd14::analysis
"What does the convergence between Mastra and DD-21 (Tau) demonstrate?"	That events-as-contract is a convergent design. Tau (teaching harness) and Mastra (production SDK) independently arrive at 'observability belongs in the component' — Tau via a typed event union, Mastra via native emission. Convergent design is evidence the principle is load-bearing.	harness-engineering::dd14::analysis
"What is 'interface-level defense' and why is it the strongest form?"	A security-relevant decision expressed in the type system: the agent never receives the handle, so misuse cannot arise. Stronger than advisory defense (a policy that says 'do not misuse') because there is nothing to bypass, misconfigure, or forget. Mastra's write-interface-withheld and NemoClaw's credentials-outside-the-sandbox are both interface-level.	harness-engineering::dd14::analysis
"Why does Module 4.3 (write-gating) point at Mastra as the reference?"	Because Mastra makes write-gating an interface-level decision (withhold the write interface) rather than a policy-level one (intercept calls on a unified handle). The defense is structural — in the type system — which is the strongest form. No other roster harness does this.	harness-engineering::dd14::analysis
"What does it mean to read the score table, not the score number?"	Mastra is 34/60 — but that number hides two 5/5 peaks (Module 10, Module 4.3) and three 1/5 gaps (Module 5, Module 9). The shape tells you what Mastra IS (the observability-and-memory reference) and what it IS NOT (production-ready across all dimensions). Read the shape.	harness-engineering::dd14::analysis