Use Boundary With AI Coding Agents

Use these Boundary docs resources before editing:
- https://docs.withboundary.com/skill.md
- https://docs.withboundary.com/llms.txt
- https://docs.withboundary.com/llms-full.txt

You are integrating Boundary into an existing codebase.

Do not scan or rewrite the entire repository. First identify the minimal LLM output path:
1. the provider or model call
2. parsing or schema validation
3. where parsed output is trusted by application code
4. existing retry or repair behavior
5. existing logging or telemetry

Then propose the smallest Boundary integration that:
- validates model output before application use
- adds semantic rules beyond schema validation
- repairs only when safe
- rejects invalid output deterministically
- logs pass, repair, rejection, empty output, and provider/runtime failure outcomes

Use current Boundary APIs:
- @withboundary/contract
- defineContract
- structured rules
- contract.accept()
- result.ok
- createBoundaryLogger from @withboundary/sdk only when analytics are requested

Do not replace the model provider.
Do not rewrite unrelated architecture.
Do not continue execution after Boundary rejects output.
Return the files to change, the contract to add, and a verification checklist before editing.

Create a new Boundary-protected LLM flow.

The flow should:
- call the existing or chosen model provider
- return the raw provider text from the Boundary run function
- parse structured output through Boundary
- validate it with a Boundary contract
- apply named semantic rules beyond schema validation
- attempt repair when safe
- reject invalid output deterministically
- log the outcome when analytics are configured
- expose enough metadata for analytics without logging raw sensitive data by default

Keep provider code, contract code, and application-use code separate.
Application code may only trust result.data when result.ok is true.

Include tests or fixtures for:
- clean pass
- repaired pass
- contract rejection
- empty response
- provider/runtime failure

Write a Boundary contract for this LLM output.

First identify:
- the output schema
- the product decision this output controls
- domain rules that must be true
- fields that are safe to repair
- fields that must never be guessed
- rejection conditions
- logging fields needed for debugging

Then produce:
- a Zod schema
- a defineContract() call
- named structured rules with name, description, fields, and check
- repair-friendly rule messages
- tests or fixtures for pass, repair, and rejection

Do not rely on schema validation alone.
Do not repair values that require external truth, such as prices, permissions, account limits, balances, or eligibility.

Debug this Boundary failure.

Classify the failure as one of:
- schema failure
- semantic rule failure
- repair failure
- empty response
- provider/runtime failure
- logging or analytics classification issue

Then identify:
- the rule that blocked the output
- whether repair should have been attempted
- whether the candidate should be preserved for review
- whether the run should count toward contract pass rate
- whether empty output or provider/runtime failure was classified separately from contract rejection
- the smallest code, contract, prompt, or logging change needed

Do not hide provider/runtime failures inside generic validation errors.
Do not write rejected output to application state.

Add Boundary logging and analytics to this contract.

Use createBoundaryLogger from @withboundary/sdk.
Keep raw inputs and outputs off by default.
Capture repair messages and failure metadata.
Configure environment from the runtime environment when available.
Use redaction before enabling raw payload capture.
Ensure missing API keys do not break local contract execution.

Verify logs include:
- contract name
- environment when configured
- outcome
- attempts and max attempts
- failure category
- rule blockers
- repairs when capture.repairs is enabled

Provider calls:
- openai.responses.create
- openai.chat.completions.create
- anthropic.messages.create
- generateObject
- generateText
- model.invoke
- fetch calls to model gateways

Parsing and validation:
- JSON.parse
- z.parse
- safeParse
- response_format
- json_schema
- output_text
- message.content

Trusted use:
- database writes
- queue jobs
- tool execution
- workflow status updates
- outbound webhooks
- user-visible rendering

Existing controls:
- retry loops
- repair prompts
- fallback values
- review queues
- app logging and telemetry