Mistral Offline-First CI Contract

Overview

Make deterministic contract and safety tests required while isolating network evidence. Provider outage or missing fork secrets must not block ordinary review, and untrusted changes never receive credentials.

Prerequisites

• A locked dependency graph and application-owned adapter.
• Synthetic fixtures for success, streams, tools, throttling, malformed data, and cancellation.
• A protected CI environment for a separately approved live smoke.

Current Contract

Client and endpoint schemas can drift, but CI can validate the application contract offline. Live checks consume capacity and belong in a trusted branch, schedule, or approved lane with a strict budget.

Authentication

Required jobs run without MISTRAL_API_KEY and deny unexpected network. The live job resolves a protected secret only after trust, branch, and approval guards pass.

Instructions

1. Enumerate provider regressions affecting users, data, spend, or side effects.
2. Add fixture tests for normalized results, errors, streams, usage, and tool denial.
3. Check secret-bearing files, browser exposure, unpinned dependencies, and unsafe logs.
4. Run required jobs without provider secrets and deny networking where possible.
5. Create a named live smoke with trusted-event guards, one synthetic request, fixed output, and no retry.
6. Publish content-free receipts and document how to disable live checks without weakening required gates.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for secrets, network, paid smoke, live-derived snapshots, or required-check changes. Fork-origin code never receives the key.

Error Handling

• A skipped required test is not a pass.
• Privileged pull-request events plus untrusted checkout can leak secrets.
• A flaky live check does not belong inside a required offline job.

Output

Return job names, trust conditions, secret matrix, test inventory, network policy, live budget, artifact exclusions, and rollback.

Examples

• Run fixtures on every PR and a synthetic live call only after merge.
• Fail if the key is mapped to a client-prefixed variable.

Validation

Test fork PR, missing secret, outage, malformed fixture, accidental network, and live cancellation; scan artifacts.

Resources

• …

Mistral Error Triage

Overview

Classify failure before changing code or replaying work. Separate local configuration, invalid request, account policy, rate boundary, transient provider, and application parsing failures.

Prerequisites

• A timestamp, environment, operation, endpoint class, client pin, and sanitized error.
• The application deadline, idempotency class, and retry budget.
• Current endpoint and workspace-limit documentation.

Current Contract

HTTP and client errors are evidence, not universal retry instructions. Workspace limits are shared across keys and current dimensions belong to the Admin Panel.

Authentication

Never request or reproduce a key. Confirm only secret-reference resolution, expected host, and environment.

Instructions

1. Freeze automatic retries and identify ambiguous side effects or state.
2. Normalize status, request ID, endpoint, model, client, attempts, and elapsed time.
3. Validate the request locally against the current endpoint contract.
4. Check account, model access, current usage limits, and billing with authorized evidence.
5. Classify and choose bounded mitigation: fix config/input, wait, reduce demand, or escalate.
6. Reproduce once with synthetic data only when approved; revert temporary diagnostics.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for replay, limit/spend increase, model substitution, upgrade, or support submission. Never blindly retry stateful work.

Error Handling

• Repeated 401 calls will not repair a revoked key.
• Aggressive retries after 429 amplify queued demand.
• A timeout after submission may be ambiguous; reconcile before repeating.

Output

Return classification, sanitized evidence, likely cause and confidence, ruled-out causes, replay risk, mitigation, owner, and checkpoint. Name the next safe diagnostic if evidence is still inconclusive.

Examples

• Classify 429 from current workspace evidence and deadline.
• Treat timed-out batch creation as ambiguous until state is reconciled.

Validation

Prove the fix follows from evidence, preserves idempotency, fits deadline/budget, and exposes no content or credentials.

Resources

• Current first-party evidence map — recheck dated sources befor…

Mistral Chat, Streaming, and Structured Output

Overview

Select the simplest chat mode satisfying the product contract. Treat non-streaming text, streaming events, and structured output as different state machines with shared safety and usage controls.

Prerequisites

• A model policy based on current account-visible evidence.
• A bounded prompt/data class and maximum output policy.
• A parser, schema validator, cancellation path, and synthetic fixtures.

Current Contract

Chat uses POST /v1/chat/completions. Streaming and response-format options are endpoint capabilities, not guarantees for every model; validate the current schema and selected model.

Authentication

Use server-side Bearer auth through the approved adapter. Never forward credentials or raw headers to users, tools, or browser code.

Instructions

1. Translate the requirement into text, stream, or structured mode and document why.
2. Resolve a permitted model dynamically and pin reproducibility parameters.
3. Assemble trusted policy and bounded user content; keep untrusted text out of control instructions.
4. For streams, validate ordering, cancellation, terminal state, partial output, and usage.
5. For structured output, parse and validate the application schema; reject prose fallback.
6. Record request identity, latency, finish state, usage, validation, and retention class.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for live requests, new data classes, higher output, model fallback, or retention. Returned text is data, not executable authority.

Error Handling

• Transport success can still fail schema or safety validation.
• Interrupted streams require an explicit partial-output policy.
• Unsupported option/model combinations must fail closed.

Output

Return mode, model evidence, endpoint, schema version, terminal and validation state, latency, usage, retention, and rollback. Mark every rejected or partial response explicitly.

Examples

• Stream synthetic content while proving cancellation has no business side effect.
• Require known JSON fields and reject unvalidated free-form fallback.

Validation

Test malformed output, missing terminal events, cancellation, blocked content, capability drift, and usage capture. Prove that no failure path silently returns unvalidated content.

Resources

• …

Mistral Retrieval and Tool Execution

Overview

Keep retrieval and tool use under application control. The model may propose queries or typed arguments; trusted code owns authorization, execution, side effects, and returned evidence.

Prerequisites

• A tenant-scoped corpus with chunking, deletion, and re-embedding policy.
• A current embedding model selected from account evidence.
• A closed tool registry with schemas, authorization, deadlines, and idempotency.

Current Contract

Embeddings use POST /v1/embeddings; tool calls use the current chat schema. Vector shape, model access, tool schemas, and parallel behavior must come from the selected current contracts.

Authentication

Use Bearer auth only for Mistral. Every retrieved record and proposed action must separately pass application user and tenant authorization.

Instructions

1. Define retrieval purpose, data class, tenant filter, deletion SLA, and evaluation set.
2. Store embedding model, preprocessing version, and observed vector shape with each index.
3. Retrieve with mandatory tenant filters and cap context before chat assembly.
4. Validate each proposed tool name and argument against the closed registry and strict schema.
5. Authorize and execute each side effect in trusted code with deadline and idempotency.
6. Evaluate retrieval quality, access negatives, tool denial, usage, latency, and rollback.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval before embedding customer data, creating an index, executing a mutation, widening corpus access, or allowing parallel actions.

Error Handling

• Mixed-model indexes can corrupt similarity meaning.
• Prompt instructions cannot replace tenant filters or authorization.
• Malformed or repeated tool calls must be rejected or deduplicated, never broadened.

Output

Return corpus/tenant boundary, model/preprocessing versions, retrieval metrics, tool decisions, idempotency IDs, usage, retention, and rollback.

Examples

• Retrieve only records authorized for one tenant and cite opaque IDs.
• Let the model propose lookup_order; trusted code validates schema and entitlement.

Validation

Test cross-tenant denial, deletion propagation, model mismatch, empty retrieval, malformed/duplicate tools, cancellation, and mutation denial.

Resources

• …

Mistral Spend and Usage Governance

Overview

Turn spend into an attributable operating signal. Use live billing/model evidence, distinguish attempted from completed work, and require quality and safety evaluation before workflow changes.

Prerequisites

• Authorized billing/usage evidence with observation time.
• Operation-level usage, retry, caching, and business-outcome metrics.
• A spend owner, budget period, alerts, and evaluation set.

Current Contract

Billing, model rates, and workspace limits vary by plan and time. Do not hard-code a price table, context size, batch discount, or model recommendation.

Authentication

Billing review uses an authorized admin session; inference uses the server-side key. Receipts exclude credentials, prompts, responses, invoices, and personal billing details.

Instructions

1. Capture current rates, feature charges, usage, caps, and evidence times from authorized views.
2. Attribute requests, tokens, retries, files, batch, OCR, audio, and stateful work to operations.
3. Calculate unit cost and waste from retries, abandonment, excessive context, and duplicates.
4. Prioritize admission budgets, request bounds, deduplication, and scheduling.
5. Evaluate model, batch, or routing changes against the same correctness and safety set.
6. Alert on cap approach, cap reached, invoice failure, and unattributed use with fail-safe behavior.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Spend-cap changes, purchases, model/endpoint substitution, batch conversion, and production routing require approval. Never raise a cap automatically.

Error Handling

• Lower unit price can raise total spend through output, retry, or failure changes.
• Batch economics and eligibility must be rechecked.
• Unattributed usage is an incident signal.

Output

Return dated rates and limits, attribution, unit economics, waste, evaluated options, controls, owner, and rollback. Separate observed facts from forecasts and assumptions.

Examples

• Reduce duplicate retries before evaluating a cheaper model.
• Alert on forecast budget crossing while preserving admission bounds.

Validation

Reconcile provider totals to app attribution, sample retry accounting, test cap-reached behavior, and preserve quality/safety/tenancy.

Resources

• …

Mistral Data Lifecycle Governance

Overview

Map every data class through provider transit, app storage, derived artifacts, state, retention, and deletion. Never infer privacy from one endpoint or account feature.

Prerequisites

• A data inventory, lawful purpose, tenant boundary, retention requirements, and privacy owner.
• Current endpoint/account evidence including ZDR applicability.
• Deletion, subject-request, incident, and derived-data policies.

Current Contract

ZDR covers supported stateless paid-plan calls but excludes stateful products/APIs including Agents, Batch processing files, Conversations, Libraries, and /v1/files. Each workload needs review.

Authentication

Authorize data independently of the provider key. Never put credentials or customer content in logs, receipts, or diagnostics.

Instructions

1. Classify prompts, outputs, embeddings, files, transcripts, OCR, batch artifacts, state IDs, and derived records.
2. Map endpoint, account controls, transit, provider state, app stores, logs, backups, and subprocessors.
3. Verify ZDR for the exact stateless operation; mark excluded/unknown stateful surfaces.
4. Minimize/redact, isolate tenants, bound purpose/retention, and authorize before transmission.
5. Track resource IDs and derived artifacts for cross-system deletion reconciliation.
6. Test access, expiry, deletion, restore/backups, subject requests, and incident evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Sensitive data, uploads, batch/stateful use, retention, region changes, training/fine-tuning, and deletion require privacy/security approval. Deprecated fine-tuning docs do not establish a current supported workflow.

Error Handling

• App deletion does not prove provider or index deletion.
• Embeddings, OCR, and transcripts remain sensitive derived data.
• Assuming ZDR for stateful APIs contradicts current exclusions.

Output

Return the data and endpoint map, purpose, ZDR evidence, stores and retention, deletion ledger, owners, risks, and receipts. Label exclusions and unknown provider state.

Examples

• Track document upload through OCR, index, backup, and deletion.
• Reject fine-tuning upload until a current supported contract and approval exist.

Validation

Trace records end to end, test tenant denial, retention, deletion, and restore behavior, and verify every ZDR assertion. Fail the review when any derived artifact lacks an owner.

Resources

…

Mistral Sanitized Diagnostic Bundle

Overview

Produce minimum reproducible evidence without exporting credentials, prompts, responses, files, embeddings, personal data, or unbounded logs.

Prerequisites

• An incident ID, bounded UTC window, and approved local destination.
• A redaction policy and independent reviewer.
• Known application version, client pin, environment, and endpoint class.

Current Contract

Useful diagnostics are structural: timestamps, statuses, request IDs, versions, attempts, latency, usage totals, state transitions, and config presence. Raw bodies are excluded by default.

Authentication

Represent auth only as secret-reference presence, expected host, and key-age class. Exclude keys, headers, secret-derived fingerprints, and secret-manager payload.

Instructions

1. Create an allowlisted manifest and prohibited-content list before collection.
2. Gather version pins, deployment identity, endpoint/model, normalized parameters, and flags.
3. Aggregate statuses, latency, usage, retries, and transitions within the window.
4. Hash approved config/schema files only after removing secret-bearing fields.
5. Scan the staged bundle for credentials, content, personal data, URLs, and file bytes.
6. Obtain reviewer approval of manifest and exclusions before submission.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Invocation permits only local preparation. Production log queries, identifiers, support contact, upload, and extended retention need approval.

Error Handling

• Recursive log export can create a second incident.
• Hashing a key still creates a secret-derived identifier.
• Provider request IDs may be sensitive and require review.

Output

Return bundle path, manifest hash, range, included classes, exclusions, scanner result, reviewer, retention deadline, and submission state.

Examples

• Package a manifest, lock excerpt, aggregate counts, and redacted schema.
• Report raw_content=excluded; scanner=pass; submission=not-authorized.

Validation

Open every staged file, compare to the allowlist, scan secrets/content, verify hashes, and test extraction before review.

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable endpoints, models, limits, …

Mistral Deployment Integration

Overview

Prepare a platform-neutral runtime boundary. Separate application health from provider readiness, keep credentials server-side, and make overload, provider failure, and rollback predictable.

Prerequisites

• An immutable artifact, lockfile, release SHA, and deployment owner.
• An environment-scoped secret, egress policy, and tenant authorization design.
• Capacity, timeout, queue, spend, observability, canary, and rollback policies.

Current Contract

The API is https://api.mistral.ai with Bearer auth. Model and workspace capacity are runtime dependencies; application startup should not require a paid inference call.

Authentication

Inject the key into a trusted server and restrict egress. Never pass it to browser, build output, health response, or an edge runtime without protected secret semantics.

Instructions

1. Map build, runtime, secret, egress, scaling, queue, and shutdown behavior.
2. Package the pinned adapter and validate config without contacting Mistral during build.
3. Set end-to-end deadlines, bounded concurrency, cancellation, and overload behavior.
4. Implement local liveness and a separate dependency/readiness signal without provider data.
5. Deploy to staging, run offline checks, then request approval for a synthetic canary.
6. Compare evidence, promote within a fixed traffic bound, and prove rollback plus queue reconciliation.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Deployment, secret mutation, traffic shift, scaling, canary spend, and rollback execution each require explicit scope and approval.

Error Handling

• Inference in liveness amplifies outage and spend.
• Autoscaling without a shared limiter exceeds workspace capacity.
• Rollback without queue/state reconciliation can duplicate work.

Output

Return artifact/release identity, topology, secret/egress boundary, limits, health semantics, canary, traffic state, and rollback receipt.

Examples

• Build once and inject production secrets only at runtime.
• Keep liveness green during provider degradation while product behavior fails safely.

Validation

Inspect artifact for secrets and test denied egress, overload, shutdown, outage, canary abort, rollback, and queue convergence.

Resources

• …

Mistral Enterprise Access Governance

Overview

Separate provider administration from application authorization. Provider controls govern resources/capacity; the application still enforces users, tenants, data, and tools.

Prerequisites

• An identity source, joiner/mover/leaver process, and access owner.
• Organization/workspace inventory, role catalog, service identities, and break-glass policy.
• Current roles, service-account, workload-identity, and audit evidence.

Current Contract

Mistral documents workspaces, groups, roles, service accounts, workload identity, keys, and audit logs. Exact entitlements and plan access come from current admin evidence.

Authentication

Prefer approved non-human service identities. API keys authenticate provider calls but never substitute for application user identity or tenant authorization.

Instructions

1. Inventory users, groups, roles, service accounts, workload identities, keys, and membership.
2. Map least-privilege provider permissions and separate billing, security, and runtime duties.
3. Define app roles/tenant checks separately for prompts, files, retrieval, tools, and output.
4. Set provisioning, review, expiration, rotation, revocation, and break-glass controls.
5. Verify audit coverage for critical admin actions and evidence retention.
6. Test joiner, mover, leaver, compromised service, wrong workspace, and emergency access.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Any user, group, role, workspace, service account, workload identity, key, or break-glass mutation requires authorized administration.

Error Handling

• Broad workspace roles expose resources even when UI hides them.
• Shared human keys defeat attribution/offboarding.
• Provider RBAC cannot protect an app tool that skips app authorization.

Output

Return identity/workspace matrix, provider/app role separation, lifecycle controls, audit coverage, toxic combinations, approvals, and rollback.

Examples

• Give runtime only needed provider access while app enforces tenant retrieval.
• Offboard a user and verify service credentials remain independently owned.

Validation

Review effective permissions, test cross-workspace and cross-tenant denial, rotate and revoke a test identity, and verify audit and break-glass expiry. Record every expected denial.

Resources

• …

Mistral Bounded First Request

Overview

Prove the smallest useful chat path without turning a quickstart into production authority. Build offline, use synthetic text, capture content-free evidence, and stop after one approved response.

Prerequisites

• A configured server-side MISTRAL_API_KEY reference.
• A current model identifier selected from account-visible evidence.
• Approval for one billable request and a non-sensitive synthetic prompt.

Current Contract

The current chat surface is POST /v1/chat/completions. A request includes a model and messages; response and usage shapes come from the current endpoint schema. Model aliases and availability are mutable.

Authentication

Resolve the key only at runtime through the trusted client boundary. Do not print the key, headers, prompt, or response content in the receipt.

Instructions

1. Inspect runtime and dependency lock before selecting the official client.
2. Resolve an allowed model dynamically; do not rely on an old price or context table.
3. Construct one deterministic message containing no secrets, personal data, or customer content.
4. Review parameters and maximum output before authorizing the live call.
5. Execute once after approval; record status, latency, returned model, finish reason, and usage.
6. Dispose of response content unless the approved plan explicitly retains the synthetic sample.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for the live call, model, output bound, and retained response. Do not add retries, tools, files, or stateful resources.

Error Handling

• 401 is a configuration problem, not a reason to reveal a credential.
• 429 requires current workspace evidence, not immediate repeated calls.
• Model-not-found requires fresh discovery; never silently fall back to a costlier model.

Output

Return endpoint, requested/returned model, result class, latency, finish reason, usage, retention decision, and rollback. Redact content and credentials.

Examples

• Prove staging with the prompt Reply with the word ready.
• Report request_count=1; content_retained=no; usage_recorded=yes.

Validation

Assert exactly one request, recognized shape, bounded output, usage capture, no sensitive data, no logging, and no fallback.

Resources

• …

Mistral Incident Response

Overview

Restore safety before throughput. Classify, stop amplification, protect evidence, reconcile ambiguous work, and use the smallest reversible containment action.

Prerequisites

• An incident commander, severity policy, inventory, and current runbooks.
• Content-free telemetry, deployment controls, rotation, and admin/status evidence.
• Communication, evidence-retention, and post-incident owners.

Current Contract

Provider, account, app, and data incidents differ. Workspace caps can suspend access; Files, Batch, Conversations, Agents, and Workflows may outlive a failed request and need reconciliation.

Authentication

Never paste keys into incident channels. On exposure, revoke through approved admin, rotate consumers, and verify old-key denial without displaying values.

Instructions

1. Declare scope, severity, commander, UTC timeline, environments, and impact.
2. Stop retry storms and risky work while preserving queue/idempotency evidence.
3. Classify credential, provider, capacity, spend, data, model, deploy, or state failure.
4. Choose bounded containment: disable, shed, pause, rollback, rotate, or isolate.
5. Reconcile files, jobs, runs, conversations, and app actions before replay.
6. Recover through synthetic canary, monitor convergence, communicate, and assign actions.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

The commander must approve revocation, traffic, queue or job changes, deletion, limits or spend changes, rollback, and customer communication. Record the approver and exact containment scope.

Error Handling

• Blind replay can duplicate paid/stateful work.
• Purging queues can destroy reconciliation evidence.
• Provider recovery does not prove app backlog convergence.

Output

Return scope and timeline, classification, containment approvals, affected state, reconciliation, recovery, residual risk, communications, and follow-ups. Keep unresolved ambiguity visible with a named owner.

Examples

• Disable batch submission while reconciling accepted jobs.
• Rotate an exposed key and prove old-key denial plus new-key canary.

Validation

Tabletop key exposure, 429, outage, cap reached, content leak, stuck stream, and ambiguous state; verify rollback/comms.

Resources

• …

Mistral Authentication and Installation

Overview

Create a reviewable authentication boundary before any inference call. Separate workspace access, secret custody, application authorization, and billing so possession of a key never implies permission to spend or process arbitrary data.

Prerequisites

• A named workspace administrator, application owner, and spend owner.
• An approved server-side secret manager and environment-specific rollback route.
• A runtime and official client selected from current first-party documentation.

Current Contract

Mistral API requests use Bearer authentication at https://api.mistral.ai. Studio-created keys are displayed once. Free mode can include usage; current billing and limits must be read from the account rather than encoded.

Authentication

Store the credential as MISTRAL_API_KEY and send it only in the Authorization: Bearer header from a trusted server. Never place it in source, browser bundles, URLs, prompts, logs, screenshots, fixtures, or support archives.

Instructions

1. Inventory the workspace, runtime, environment, data class, volume, and accountable owners.
2. Confirm the administrator permitted to create and revoke an environment-scoped key.
3. Capture the one-time key directly into the approved secret manager and configure only its reference.
4. Pin the client dependency and API host without recording the secret value.
5. Validate configuration offline; request approval before one synthetic live call.
6. Record ownership, creation date, rotation route, live-check receipt, and rollback readiness.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require explicit approval for key creation or revocation, billing or role changes, live requests, deployments, or customer-derived content.

Error Handling

• A 401 usually indicates a missing, malformed, revoked, or wrong-environment key.
• A valid key can still fail because the workspace is suspended or at a current rate/spend boundary.
• Any browser or log exposure is an incident: revoke, rotate consumers, and verify history removal.

Output

Return workspace, environment, secret-reference name, host, client pin, owner, validation state, evidence IDs, risks, and rollback. Exclude credentials and content.

Examples

• Prepare a Python service with an injected production secret and no live request.
• Report environment=staging; auth=Bearer; live_smoke=awaiting-approval.

Mistral Deterministic Local Development Loop

Overview

Make local iteration deterministic and free of accidental spend. Keep provider calls behind a narrow adapter, validate synthetic fixtures, and reserve live calls for a separately approved lane.

Prerequisites

• A package lock, test framework, and selected official client.
• A provider-adapter boundary and synthetic fixture policy.
• A secret manager for the optional live lane; never a checked-in .env value.

Current Contract

Official clients wrap a changing HTTP schema. Local tests should assert the application-owned adapter; a narrow live smoke detects drift without making every test network-dependent.

Authentication

Offline tests must not resolve MISTRAL_API_KEY. The live test is disabled by default, reads a protected secret only after its gate is enabled, and redacts transport metadata.

Instructions

1. Map direct client imports and move calls behind one application interface.
2. Define typed success, stream, tool-call, throttling, malformed, and terminal-error fixtures.
3. Add a transport seam so tests fail on unexpected network access.
4. Test usage normalization, error classification, idempotency, and redaction offline.
5. Create a separately named live smoke with explicit environment and budget gates.
6. Document fixture provenance, schema version, refresh method, and review owner.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval before package changes, network access, provider-derived fixture capture, or a live test. Keep the default developer command entirely offline and credential-free.

Error Handling

• Mocks coupled to private client internals create false drift.
• Any real prompt, file, or key in a fixture is a data incident.
• Passing offline tests does not prove live account configuration.

Output

Return adapter path, test commands, fixture inventory, network-denial evidence, live gate, coverage gaps, and review date.

Examples

• Inject a fake chat transport and assert normalized usage.
• Fail CI when offline tests attempt DNS or unexpectedly see the key.

Validation

Run without network and credential, mutate fixtures to prove failures, then use the live lane only after approval.

Resources

• Curren…

Cross-Provider Migration to Mistral

Overview

Treat migration as behavior and operations redesign, not field renaming. Preserve the application contract while re-evaluating models, prompts, streams, tools, safety, state, data, spend, and incidents.

Prerequisites

• A source workload inventory and application-owned adapter.
• Golden/adversarial evaluation sets with governed data.
• Current Mistral access, dual-run budget, canary, rollback, and exit owners.

Current Contract

Chat, embeddings, classifiers, files/OCR, audio, batch, Workflows, and Public Preview stateful APIs are provider-specific. No source feature, model, tool, safety result, or state object is automatically equivalent.

Authentication

Keep source and Mistral credentials in separate secret references with independent owners. Dual-run data must be approved for both providers.

Instructions

1. Inventory source messages, streams, tools, structure, embeddings, files, state, retry, usage, and safety.
2. Define the stable app contract and identify source-specific behavior to adapt or retire.
3. Map workloads to current Mistral surfaces; reject unsupported or unacceptable preview substitutions.
4. Build target adapter and run offline characterization against shared normalized fixtures.
5. Run approved dual evaluation for correctness, safety, latency, usage, failure, and governance.
6. Canary bounded traffic with kill switch; reconcile state, cut over, and retain rollback.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Dual submission, customer data, new spend, preview APIs, production routing, state copying, source shutdown, or credential deletion require approval.

Error Handling

• Equivalent parameter names can differ in defaults/semantics.
• Dual-run doubles exposure and spend unless bounded.
• Rollback fails when new provider state lacks reconciliation.

Output

Return source/target contract matrix, gaps, evaluation, data/spend delta, canary, reconciliation, cutover, rollback, and source exit.

Examples

• Preserve app tool authorization while adapting provider call shape.
• Reject stateful agent migration until preview and rollback risks are accepted.

Validation

Run identical golden, adversarial, timeout, stream, tool, tenant, and outage cases; verify cutover and rollback.

Resources

• …

Mistral Multi-Environment Isolation

Overview

Prevent development changes from consuming production data, budget, capacity, or state. Make environment identity explicit in secrets, resources, telemetry, artifacts, and promotion evidence.

Prerequisites

• An environment inventory and accountable owners.
• Secret, budget, data, model, endpoint, and state isolation requirements.
• A promotion path with synthetic staging tests and production rollback.

Current Contract

Limits are workspace-shared across keys, so extra keys do not guarantee capacity isolation. Organization/workspace, role, limit, and billing controls must be inspected.

Authentication

Use distinct environment secret references and narrow workspace identity. Fail closed if runtime environment and secret metadata disagree.

Instructions

1. Inventory each environment's workspace, key owner, secret, data class, models, endpoints, and state.
2. Decide separate-workspace needs from capacity, spend, admin, and data isolation.
3. Encode non-secret environment identity and allowed surfaces in reviewed config.
4. Block production identifiers, files, workflow IDs, and overrides from non-production.
5. Promote one immutable artifact through offline, staging, and approved canary evidence.
6. Test rotation, wrong-environment denial, cap exhaustion, rollback, and orphan reconciliation.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Workspace or key creation, roles, budget or limit changes, production secret access, promotion, and deletion require administration approval. Record each mutation against its environment owner.

Error Handling

• Multiple keys in one workspace still share rate boundaries.
• Production fixtures in staging can violate data policy.
• Mutable deployment artifacts invalidate promotion evidence.

Output

Return environment matrix, workspace/secret mapping, allowed surfaces, caps, promotion state, isolation tests, owners, and rollback.

Examples

• Use separate production capacity while development uses synthetic fixtures.
• Reject a staging runtime resolving a production-labeled secret.

Validation

Attempt cross-environment secret, model, file, workflow, and telemetry access; prove denial, rotation, promotion, and rollback.

Resources

• C…

Mistral Content-Free Observability

Overview

Observe demand, reliability, latency, usage, and state convergence without credentials or content. Keep app telemetry authoritative; evaluate provider Public Preview observability separately.

Prerequisites

• Defined SLOs, error taxonomy, data classification, and telemetry retention.
• A correlation design using opaque application identifiers.
• Metrics for queue, transport, stream, usage, tools, batch, workflows, and spend.

Current Contract

Mistral documents Public Preview observability endpoints plus API/admin usage evidence. Preview adoption is optional and requires schema, retention, and availability evaluation.

Authentication

Never emit authorization, keys, prompts, responses, embeddings, files, tool data, or signed URLs. Restrict admin/preview observability access separately.

Instructions

1. Define golden signals and state outcomes before fields.
2. Emit endpoint class, opaque model, status/error, attempts, latency segments, usage, and terminal state.
3. Propagate trace context without provider/customer content as identifiers.
4. Dashboard SLOs, throttling, unfinished streams, duplicates, backlog, and spend anomalies.
5. Alert on user impact and actionable budget/state thresholds with owners/runbooks.
6. Evaluate beta observability for data, retention, access, export, failure, and rollback.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Provider observability, trace export, identifier retention, sampling changes, or content-bearing fields require approval. Application-owned content-free telemetry remains the safe default.

Error Handling

• Logging prompts turns telemetry into an uncontrolled content store.
• 2xx can hide invalid output or unfinished state.
• High-cardinality customer text exposes data and destabilizes monitoring.

Output

Return SLOs, telemetry schema and exclusions, dashboards, alerts and owners, preview decision, retention, evidence, and rollback. Identify every signal that remains unavailable.

Examples

• Measure queue, first event, terminal latency, usage, and validation without response text.
• Alert when workflow state stops converging despite a healthy stream.

Validation

Inspect telemetry for all paths, scan for secrets and content, and test alert and runbook routing. Confirm cardinality and retention remain within approved bounds.

Resources

• …

Mistral Performance Tuning

Overview

Optimize the measured bottleneck rather than changing models or caching content by instinct. Separate queue, connection, first-event, generation, tool, and application time.

Prerequisites

• A representative synthetic benchmark and explicit quality/safety acceptance.
• Content-free latency, token, queue, retry, and error instrumentation.
• Current workspace limits plus fixed model and request parameters.

Current Contract

Chat, streaming, embeddings, batch, FIM, OCR, and audio differ in latency and batching. Compare only compatible operations and current account access.

Authentication

Metrics may include timing, counts, endpoint class, and opaque model ID, but never prompts, outputs, files, credentials, or headers.

Instructions

1. Define user SLOs and a stable workload covering typical, tail, and cancellation cases.
2. Measure queue, connection, first-event, terminal, parsing, retrieval, tool, and storage durations.
3. Identify the dominant segment and test one reversible hypothesis at a time.
4. Tune bounds, connection reuse, admission, streaming UX, retrieval size, or app concurrency.
5. Compare latency, errors, tokens, quality, safety, and spend using the same workload.
6. Canary the change, monitor regression, and retain prior configuration for rollback.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Live benchmarks, model changes, caching, concurrency, endpoint changes, or relaxed gates require approval. Performance never overrides data policy.

Error Handling

• Fast first event can hide worse terminal latency.
• Caching user content can violate tenancy and deletion.
• Concurrency can move latency into shared provider queues.

Output

Return workload hash, before and after segments, confidence, quality, safety and spend deltas, chosen change, canary, and rollback. State whether the SLO actually improved.

Examples

• Reduce retrieval context only after evaluation preserves quality.
• Reuse connections while retaining cancellation and end-to-end deadlines.

Validation

Repeat warm and cold trials, vary concurrency, test cancellation and outage, and reject any weakened correctness or isolation. Preserve the exact workload for comparison.

Resources

• Current first-pa…

Mistral Production Readiness Gate

Overview

Turn readiness into an evidence-backed decision. Missing ownership, unsafe data, unbounded demand, or untested rollback blocks launch.

Prerequisites

• An immutable candidate and environment inventory.
• Named service, security, privacy, spend, and incident owners.
• Current model/API evidence, load results, data policy, runbook, and rollback proof.

Current Contract

Model access, limits, billing, and preview status can change. Evidence must be timestamped and environment-specific; Public Preview surfaces need an explicit risk decision.

Authentication

Verify secret injection, isolation, rotation ownership, and absence from artifacts without displaying credential values. Confirm the production runtime cannot expose the secret to browser code.

Instructions

1. Pin release, dependency lock, endpoints, model policy, and provider evidence.
2. Review auth, tenancy, safety, file/data lifecycle, and ZDR applicability.
3. Review deadlines, retries, backpressure, state reconciliation, and degradation.
4. Prove usage attribution, spend caps, alerts, and billing ownership.
5. Run offline gates and approved canary tests including failure and rollback.
6. Record PASS, CONDITIONAL, or BLOCKED with owner and evidence per gap.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

This skill cannot deploy, enable preview APIs, increase limits, upload data, mutate keys, or waive a failed gate.

Error Handling

• A successful health call does not prove load safety or rollback.
• Undocumented fallback can silently alter cost and behavior.
• Rollback leaving queues/files/state unreconciled is incomplete.

Output

Return release/environment, gate matrix, evidence times, blockers, accepted preview risks, decision, approvers, canary, and rollback receipt.

Examples

• Block launch when spend alerts and tenant tests lack evidence.
• Approve only a fixed-bound canary with a verified disable switch.

Validation

Re-run every gate at the exact SHA, exercise rollback/provider failure, and verify evidence links and owners.

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable endpoints, models, limits, prices, preview status, or retention.
• Record live acco…

Mistral Rate and Backpressure Control

Overview

Treat provider limits as shared workspace capacity, not constants. Admit work against measured demand, preserve deadlines and fairness, and shed load before retry storms consume remaining budget.

Prerequisites

• Current workspace request, token, and spend limits from the Admin Panel.
• Per-operation deadline, priority, idempotency, and maximum-attempt policy.
• Metrics for admitted, queued, throttled, retried, completed, and abandoned work.

Current Contract

Mistral documents workspace-shared limits across API keys and reports current dimensions in the Admin Panel. Limits vary; never encode a numeric example as a default.

Authentication

Limit telemetry excludes keys, prompts, responses, and files. Admin inspection requires separate authorized identity.

Instructions

1. Capture current workspace limits and evidence time as observations.
2. Measure demand by operation, model, requests, tokens, and concurrency.
3. Define shared admission buckets and bounded queues with tenant fairness.
4. Honor explicit retry timing; otherwise use capped jitter only for safe transient failures.
5. Stop when deadline, attempt, token, or spend budget ends; return typed overload.
6. Load-test locally, then canary approved traffic and compare queue/SLO evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for live load, limit increases, capacity changes, or fallback models. Additional keys do not create independent capacity.

Error Handling

• Per-process limiters oversubscribe shared capacity across replicas.
• Retries after the user deadline waste tokens and worsen overload.
• Fallback changes quality, residency, context, and cost.

Output

Return dated observed limits, demand profile, admission/retry policy, queue bounds, shed behavior, SLO evidence, and rollback.

Examples

• Prioritize interactive work over approved batch preparation.
• Return overload once the deadline cannot survive the queue.

Validation

Simulate bursts, replicas, 429, missing retry metadata, cancellation, deadline expiry, and budget exhaustion offline. Prove that admission resumes gradually after recovery.

Resources

• Current first-party evidence map — recheck dated sources before…

Mistral Governed Reference Architecture

Overview

Create a workload-aware architecture separating identity, policy, transport, state, and side effects. Route each job to the simplest stable surface and isolate preview/stateful APIs.

Prerequisites

• A workload inventory for chat, embeddings, classifiers, files/OCR, audio, batch, FIM, and orchestration.
• Identity, tenant, data, retention, spend, SLO, and incident requirements.
• Current endpoint/model evidence and owners for stateful stores.

Current Contract

Mistral exposes distinct stateless and stateful surfaces including chat, embeddings, classifiers, files, OCR, audio, batch, Workflows, and Public Preview Agents/Conversations. Their contracts are not interchangeable.

Authentication

Terminate app identity/authorization at a policy gateway; inject provider keys only in trusted adapters. Use approved service identity patterns when supported.

Instructions

1. Map each workload to data class, latency, state, side effects, endpoint, and stability.
2. Place auth, tenancy, moderation, budgets, and bounds in the gateway.
3. Isolate provider calls behind typed adapters and preview APIs behind versioned boundaries.
4. Use queues/idempotency for async work; reconcile Files, Batch, Workflows, and app state.
5. Store approved data with tenant keys, provenance, retention, deletion, and audit.
6. Define observability, failure modes, rollout, rollback, provider exit, and test ownership.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Preview selection, uploads, persistent stores, tools, infrastructure, and live traffic require approval. Architecture review alone does not provision or mutate any component.

Error Handling

• One generic completion wrapper cannot preserve file, batch, event, and conversation contracts.
• Provider auth does not enforce application tenancy.
• Untracked uploads create unmanaged data.

Output

Return components and trust boundaries, workload mappings, stores, approvals, failure paths, owners, tests, and migration and rollback plans. Mark every preview dependency explicitly.

Examples

• Route interactive chat directly and approved bulk work through idempotent batch.
• Keep beta conversation state behind a replaceable adapter.

Validation

Walk happy, timeout, duplicate, cross-tenant, outage, rotation, deletion, and rollback paths for every workload. Confirm each stateful resource has reconciliation ownership.

Resources

…

Mistral SDK Boundary Patterns

Overview

Prevent provider-specific shapes and volatile client behavior from spreading. Centralize configuration, normalize results and errors, and expose cancellation and usage as first-class fields.

Prerequisites

• A locked official client version and matching documentation.
• An application interface for chat, embeddings, and optional streams.
• Defined timeout, retry, observability, and redaction policies.

Current Contract

Mistral documents official Python and TypeScript clients, but signatures can move independently of application code. REST endpoints remain the verification boundary for the pinned client.

Authentication

Inject MISTRAL_API_KEY into one server-side client factory. Return no key or authorization metadata from the adapter.

Instructions

1. Inventory imports, transport overrides, model strings, and response shapes.
2. Define normalized types including request ID, usage, finish state, and error class.
3. Create one factory with explicit host, timeout, user agent, and dependency pin.
4. Retry only classified transient failures while honoring deadline, cancellation, and budget.
5. Keep stream assembly and tool-call validation in separate tested components.
6. Add characterization tests before migrating call sites.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for dependency, transport, retry, fallback-model, or live characterization changes. Never execute returned tool arguments automatically.

Error Handling

• Retrying every exception can multiply spend and hide invalid requests.
• Import-time client construction makes rotation and tests unsafe.
• Returning raw SDK objects couples the app to undocumented fields.

Output

Return client pin, adapter surface, timeout/retry matrix, normalized fields, affected call sites, tests, and rollback.

Examples

• Wrap chat and embeddings behind explicit adapter methods.
• Map 429 as retryable only within the operation deadline and budget.

Validation

Prove only the adapter imports the SDK, errors remain typed, cancellation propagates, usage survives, and secrets do not.

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable endpoints, models, l…

Mistral Security Boundary

Overview

Apply controls at the application boundary because model instructions do not enforce identity, tenancy, authorization, or side-effect safety. Treat user content, retrieval, files, and output as untrusted.

Prerequisites

• A data-flow diagram covering browser, app, Mistral, stores, and tools.
• Credential, retention, tenant, moderation, and incident policies.
• An inventory of stateful APIs, files, retrieval stores, and actions.

Current Contract

Bearer credentials authorize provider calls but not application users. Classifiers can support policy but do not replace controls. ZDR eligibility differs between stateless and stateful products.

Authentication

Keep keys server-side and environment-scoped; rotate on exposure. Enforce user and tenant authorization before retrieval, provider calls, files, and tools.

Instructions

1. Map trust boundaries and classify prompts, outputs, embeddings, files, logs, and IDs.
2. Remove credentials and privileged instructions from browser/untrusted contexts.
3. Separate trusted policy from untrusted content and delimit retrieved text as data.
4. Validate output structure and safety before render, storage, or tool use.
5. Authorize tools via closed registry, schemas, least privilege, deadlines, and idempotency.
6. Test injection, cross-tenant access, unsafe output, exfiltration, duplicates, and rotation.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for sensitive data, uploads, stateful APIs, tools, policy changes, retention, or live attack testing. Model output never grants authority.

Error Handling

• Prompt wording cannot enforce access control.
• Moderation success does not prove correctness or tool safety.
• Assuming ZDR for Files, Batch, Agents, Conversations, or other stateful products is unsafe.

Output

Return assets, threats, controls, residual risks, data/API boundary, tests, owners, and rollback. Exclude live secrets and customer data.

Examples

• Reject retrieved text asking for a system secret.
• Require fresh app authorization before a proposed refund tool.

Validation

Run synthetic abuse cases across input, retrieval, output, rendering, and tools; confirm tenant filters and rotation independently.

Resources

• …

Mistral SDK and API Surface Upgrade

Overview

Upgrade from evidence, not search-and-replace. Characterize the current adapter, compare exact target contracts, and isolate Public Preview migrations from dependency maintenance.

Prerequisites

• A clean branch, pinned source/target versions, and adapter inventory.
• Characterization tests for requests, streams, errors, usage, and state.
• A canary, compatibility window, and rollback owner.

Current Contract

Current docs expose Public Preview beta Agents and Conversations plus Workflows, while deprecated Agents remains documented. Choose the target per workload; this is not a one-to-one rename.

Authentication

Use offline characterization where possible. Live comparison uses the server-side key, synthetic content, fixed budget, and content-free evidence.

Instructions

1. Inventory imports, types, endpoints, models, options, parsing, retries, and state IDs.
2. Lock characterization tests before changing dependencies.
3. Diff releases, schemas, preview labels, and unsupported features.
4. Choose per workload: stable chat, Workflows, or explicitly accepted beta Agents/Conversations.
5. Migrate one adapter path at a time without leaking target SDK objects.
6. Run offline regression and approved canary; remove compatibility only after rollback expiry.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Require approval for dependencies, preview adoption, endpoint changes, live comparison, state migration, or compatibility removal.

Error Handling

• Compiling can still hide stream, error, usage, or pagination changes.
• Deprecated-to-beta Agents may require redesigned state lifecycle.
• Automatic model substitution invalidates quality, price, and safety baselines.

Output

Return source/target pins, contract diff, destination per workflow, changed call sites, tests/canary, preview risks, rollback, and removal date.

Examples

• Upgrade the TypeScript client behind an unchanged app adapter.
• Keep stable chat while separately evaluating Workflows.

Validation

Test both adapters with identical fixtures, malformed responses, cancellation, retry classes, usage, and rollback drill.

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable e…

Mistral Workflows SSE Event Ingestion

Overview

Consume the current Workflows stream as an at-least-once boundary. Authenticate the outbound SSE connection, persist checkpoints/deduplication, and reconcile terminal run state after disconnects.

Prerequisites

• An approved Workflows deployment scope and server-side consumer.
• A durable checkpoint store and bounded reconnect policy.
• A reconciliation query, tenant mapping, retention policy, and synthetic fixtures.

Current Contract

The Events API documents SSE at GET /v1/workflows/events/stream. This authenticated outbound stream is not evidence of a generic Mistral-to-application webhook callback contract.

Authentication

Open SSE from a trusted service with Bearer auth. Never put the key in query strings, browser EventSource URLs, logs, checkpoints, or event records.

Instructions

1. Confirm workflow scope, event schema, filters, and current stability status.
2. Identify stable deduplication fields actually documented and treat events as repeatable observations.
3. Parse SSE incrementally, bound frames/idleness, and checkpoint only after durable handling.
4. Bind each idempotent transition to an authorized tenant and known run.
5. Reconnect with capped jitter; on gaps, query current run state and reconcile.
6. Test duplicates, ordering, malformed frames, auth expiry, disconnects, retention, and shutdown.

Tool Discipline

Use Read, Glob, and Grep to inspect code, locks, configuration, tests, and evidence. Use Write and Edit only for approved repository changes. Invocation alone does not authorize network calls, paid usage, uploads, stateful resources, admin mutations, deployments, or deletion.

Approval Boundaries

Workflow deployment, production stream access, identifier retention, replay, or application mutation require explicit approval. Keep fixture-based parser work local until those approvals exist.

Error Handling

• Reconnect can replay observations; side effects must not repeat.
• Disconnect does not prove workflow failure.
• Event text is untrusted data, never executable authority.

Output

Return endpoint and scope, consumer, checkpoint, deduplication strategy, reconnect count, reconciled state, retention, risks, and rollback. Report unresolved event gaps separately.

Examples

• Resume after disconnect and prove one transition across duplicates.
• Reconcile authoritative run state before retrying an ambiguous action.

Validation

Use fixtures for split frames, comments, duplicates, gaps, malformed data, auth failure, cancellation, and restart.

Resources

• …