v2.3.0

.claude/skills/add-pricing-field/SKILL.md

@@ -54,7 +54,7 @@ by tests.
 | Field reference docs | `docs/providers/custom-pricing.mdx` | Row in the relevant section's table |
 | Architecture excerpt | `docs/architecture/framework/model-catalog.mdx` | Optional — file says "excerpt", but keep the "Costs - Other"-style section current when touching an adjacent field |
 | UI override type | `ui/lib/types/governance.ts`, `PricingOverridePatch` | `field_name?: number;` |
-| UI override form | `ui/app/workspace/custom-pricing/overrides/pricingOverrideSheet.tsx`, `PRICING_FIELDS` | `{ key, label, group, requestTypeGroups }` entry |
+| UI override form | `ui/app/workspace/custom-pricing/overrides/pricingFields.ts`, `PRICING_FIELDS` | `{ key, label, group, requestTypeGroups }` entry |
 | Tests | `framework/modelcatalog/datasheet/cost_test.go`, `overrides_test.go` | One cost-calculation test, one `patchPricing` test |
 
 ---
@@ -166,7 +166,7 @@ in-scope for this change.
 
 1. `ui/lib/types/governance.ts` — add `field_name?: number;` to `PricingOverridePatch`, in the
    matching comment section.
-2. `ui/app/workspace/custom-pricing/overrides/pricingOverrideSheet.tsx` — add an entry to
+2. `ui/app/workspace/custom-pricing/overrides/pricingFields.ts` — add an entry to
    `PRICING_FIELDS`: `key` (exact JSON field name), a short human `label`, `group` (which visual
    section it renders under — usually matches an existing sibling field's group), and
    `requestTypeGroups` (which of `chat/embedding/rerank/audio/image/video/ocr` it applies to, per
@@ -200,7 +200,7 @@ clean run with no matching text would falsely report failure). If you want to sc
 just the touched files, capture it to a variable first and check `tsc`'s exit status separately:
 ```bash
 tsc_out=$(./node_modules/.bin/tsc --noEmit -p tsconfig.json 2>&1); tsc_status=$?
-echo "$tsc_out" | grep -i "pricingOverrideSheet\|governance.ts" || true
+echo "$tsc_out" | grep -i "pricingFields\|governance.ts" || true
 [ "$tsc_status" -eq 0 ]
 ```
 

.claude/skills/harness-test-writer/SKILL.md

@@ -103,6 +103,11 @@ Conventions (match the existing collection exactly):
   a streaming variant if the route streams, and where applicable a second route that
   pins the same invariant independently (e.g. native `/v1/responses` alongside the
   converted `/v1/chat/completions` path).
+- **Non-200 expectations**: the collection-level test script asserts HTTP 200 on every
+  request unless the request NAME carries a status tag: `[EXPECT-4XX]` (any 4xx, for
+  "the field reached the provider and it rejected it" pins) or an exact `[EXPECT-<code>]`
+  such as `[EXPECT-422]`. Put the tag in the name of every case that expects a non-200
+  reply, or the run fails on the injected "Status code is 200" assertion.
 - **Test scripts** (Postman `event[].script.exec`, plain ES5 JavaScript):
   - Never skip any error status code. Do NOT open the script with an early-return
     guard like `if ([401, 403, 429, 500, 502, 503, 504].indexOf(pm.response.code) !== -1) { return; }`
@@ -161,10 +166,13 @@ The augment script only regenerates its own "(generated)" folders, so a new top-
 folder passes through untouched - but run it anyway to catch parse breakage.
 
 Do NOT auto-run the live suite: it starts a gateway and makes paid provider calls.
-Report the run command and offer to execute it:
+Report the run command and offer to execute it. The keyword is descriptive text from the
+case or folder names, never an issue number, and the gateway port is explicit because
+worktrees run side by side (avoid 8080 and 8090, the harness viewer's port, unless free):
 
 ```bash
-make run-provider-harness-test PROVIDER=<provider> FEATURE="<distinctive keyword from your case names>"
+make dev PORT=<port> APP_DIR=$(pwd)/tests/integrations/python
+make run-provider-harness-test PROVIDER=<provider> FEATURE="<distinctive keyword from your case names>" BASE_URL=http://localhost:<port>
 ```
 
 ## Step 7 - Report

.claude/skills/investigate-issue/SKILL.md

@@ -876,10 +876,12 @@ Once all approved changes are applied:
    make dev PORT=<port> APP_DIR=$(pwd)/tests/integrations/python   # in the background; wait for /health = 200
    ```
    ```bash
-   make run-provider-harness-test PROVIDER=<provider> FEATURE="<keyword>"
+   make run-provider-harness-test PROVIDER=<provider> FEATURE="<keyword>" BASE_URL=http://localhost:<port>
    # cross-cutting change: the curated smoke set instead
-   make run-provider-harness-test SMOKE=1
+   make run-provider-harness-test SMOKE=1 BASE_URL=http://localhost:<port>
    ```
+   `<keyword>` is descriptive text that appears in the case or folder names (for example
+   `"sdk fidelity"`), never an issue or PR number; verify it with `filter-collection.mjs` first.
    Report the provider status table and `tmp/harness-failures.md` findings, and state exactly
    which scope ran. See AGENTS.md "Every wire-visible change ships with a provider-harness
    case" and "Every non-exempt wire-visible fix ends with unit tests, then a harness command

.claude/skills/security-audit/AI-AND-LLM.md

@@ -0,0 +1,83 @@
+# AI, LLM, and Agent Hunting
+
+#### When to use this file
+
+Reach for this file when a language model participates in a trust-sensitive decision: chatbots and assistants, RAG pipelines, persistent agent memory, agent/tool-calling loops, MCP servers and clients, code that builds prompts from untrusted input, or code that consumes model output and acts on it. The important data flow is *untrusted content → model or memory → capability, authority, or sink*.
+
+Use this alongside `ATTACK-CLASSES.md`, not instead of it. Transport, access control, query construction, filesystem use, and output rendering remain ordinary trust boundaries. This file covers the model-specific delegation layer. Split large targets by retrieval, memory, tool dispatch, MCP, and output handling.
+
+## Core discipline (include in every agent prompt for this domain)
+
+```
+- Prompt injection alone is not a finding. Require a code-level boundary failure: content reaches another principal's context, invokes authority the requester lacks, discloses data they cannot read, or drives a sink they cannot reach directly.
+- Model output, memory, tool descriptions, and MCP responses are untrusted inputs. Point to the code that grants authority, trusts output, writes durable state, or feeds a sink.
+- A guardrail prompt is not a security boundary. Count only deterministic checks, resource-scoped authorization, isolation, binding, and constrained credentials.
+- State the attacker, affected principal, effective execution identity, resource, exact action, authority used, and observable impact. An intentional direct request to use the requester's existing authority is not a delegation defect merely because a model executes it.
+- Authorization and action binding are separate controls. Attacker-controlled content that causes an action under an affected principal's valid authority is an action-binding failure when that principal did not intentionally request or approve the exact action.
+- Classify every candidate as `confirmed` only after source evidence and bounded local validation establish the boundary and result. Use `needs_validation` when a required provider, deployment, model, renderer, or identity behavior is not observable locally.
+```
+
+## Context, retrieval, and memory attack classes (subagent_type: `general`)
+
+**Indirect injection through retrieved or ingested content**
+An attacker can write a RAG document, indexed page, file, email, issue body, tool response, or metadata that enters a different principal's model context. Trace who can write each source, how retrieval scopes it, whose session consumes it, and what capability is enabled there. Check isolation, resource authorization, and binding to the consuming principal's intent separately. The defect is a missing deterministic control, not persuasive text by itself.
+
+**Cross-session or cross-tenant context bleed**
+Conversation history, embeddings, retrieval results, or prompt caches are keyed too broadly. Verify tenant and ACL filters in the query itself and every cache key. A tenant field stored on an object is not enforcement if an alternate query, shared cache, or batch path omits it.
+
+**Persistent memory poisoning**
+Attacker-controlled content or model summaries are written into memory that later shapes another task, user, or privileged session. Review who may create, update, merge, and delete memory; its provenance and tenant scope; whether low-trust observations become durable instructions or facts; and whether retrieval distinguishes user preferences from tool policy. Memory intentionally saved by a user and used only for that user's intentional, allowed requests is not a cross-boundary finding.
+
+**Prompt role and provenance confusion**
+Prompt assembly lets untrusted text impersonate a system message, prior turn, tool result, policy, or memory record. Look for string concatenation, untyped history, caller-controlled role fields, and serialization round trips that lose source labels. Confirm that the forged provenance changes a deterministic trust decision or reaches a meaningful capability.
+
+## Tool and action attack classes (subagent_type: `general`)
+
+**Tool-argument injection into a downstream sink**
+Model-produced arguments reach SQL, shell, file, URL-fetch, or privileged APIs without handler-side validation. Treat the tool schema as input parsing, then follow each field from decoded call to sink. Structured output narrows shape; it does not establish authorization, safe paths, safe URLs, or query semantics.
+
+**Excessive agency and confused-deputy authority**
+The agent uses a service identity or broad credential, while the tool handler does not re-check the requesting principal's permission on the named resource. Verify both the effective identity and whether the caller could perform that exact operation through the normal product interface. A shared credential with enforced per-user query scope is not a defect.
+
+**Action-confirmation and approval binding**
+A user approves one described action but execution can use changed arguments, a different resource, a different principal, or a later model turn. An action-binding defect also exists when attacker-controlled content causes a side effect under a victim's valid authority without the victim's intentional request or approval, even if generic authorization permits the victim to perform it. Review whether intent or confirmation binds the normalized tool name, complete argument object, requester, target, amount, expiry, and batch membership. Check retries and resumed sessions: an approval must not authorize a mutated or duplicate side effect.
+
+**Tool-schema and dispatcher disagreement**
+The schema accepts aliases, extra fields, duplicate keys, coercions, nested free-form objects, or out-of-range values that the dispatcher or handler interprets differently. Compare schema validation, canonicalization, generated bindings, and handler defaults. Validate again where values become resource selectors or security-relevant options.
+
+**Unbounded delegated action loops**
+A bounded request can enqueue repeated spend, send, mutation, or external API work without a per-request budget, per-action authorization, cancellation, or idempotency control. Confirm impact on shared cost, quotas, other users, or durable state. Do not test by exhausting a service; use code-level accounting and a locally bounded loop.
+
+## MCP and sub-agent trust classes (subagent_type: `general`)
+
+**Sub-agent and MCP trust inheritance**
+A delegated task receives the full session, credentials, memory, or capabilities rather than the least authority required. Check the principal and tenant carried into each call, capability narrowing, credential audience, and whether delegated results are treated as untrusted on return.
+
+**MCP server and tool identity confusion**
+Calls or results are routed by attacker-influenceable server names, tool names, request IDs, resource URIs, or model-selected aliases rather than the authenticated connection and outstanding request. Check whether two servers can claim the same tool or resource identity, whether reconnect changes the binding, and whether a response from one server can satisfy another server's pending call.
+
+**MCP metadata and schema as policy**
+Tool descriptions, resource metadata, prompts, completion hints, or schemas supplied by an MCP peer are trusted as policy or authorization. These fields can guide the model but cannot grant capability. Find the deterministic allowlist, server identity check, and handler authorization that remain authoritative when metadata conflicts.
+
+## Output and disclosure attack classes (subagent_type: `general`)
+
+**Insecure output rendering**
+Model output reaches an executing HTML, Markdown, template, URL, or command sink without the sink's required encoding and policy. For browser rendering, verify auto-loaded resources and CSP or sanitization in `CLIENT-SIDE.md`; renderer behavior outside the repository makes the candidate `needs_validation`.
+
+**Sensitive context extraction**
+The assembled context contains credentials, another user's data, private source, or policy values that themselves grant access, and user-influenced output exposes them. Read prompt assembly and data-fetch code. Disclosure of generic instructions or behavior that does not cross a data boundary is not a finding.
+
+## Universal moves (apply across the above)
+
+- Draw four maps first: each execution identity, each capability, every writable context or memory source, and each output destination. Then connect the principal at the start to the authority at the end.
+- Start at side-effecting tools and work backward through dispatcher, schema, confirmation, model context, retrieval, and ingestion. Start at durable memory reads and trace every writer.
+- Compare direct, queued, retry, resume, batch, and delegated paths for the same action. The strongest gate must apply after arguments are final and before every side effect.
+
+## Validation rules (apply before reporting ANY finding here)
+
+1. Name the crossed boundary and observable result: attacker, affected principal or shared resource, execution identity, target, and unauthorized or unrequested action or disclosure.
+2. For confused-deputy authority claims, prove the tool lacks requester-and-resource authorization and that the attacker cannot perform the same action normally. For action-binding claims, instead prove attacker-controlled content caused an action under the affected principal's authority that the principal did not intentionally request or approve. Valid generic authorization does not establish that intent.
+3. For memory or retrieval claims, cite both the attacker-controlled write and the later cross-principal read or privileged decision. A shared record without a reachable consumer is not enough.
+4. For action binding, establish the intentional request or normalized approved object, if any, and compare it with the object the handler uses. Confirm a locally observable unrequested action, mutation, duplicate, or authority change without extending the test into harmful execution. For schema disagreement, compare the normalized validated object with the handler's object.
+5. For MCP identity claims, verify the authenticated connection, request correlation, tool namespace, and effective credential. Mark `needs_validation` if external server identity or deployment routing is required.
+6. Return `confirmed` findings only with a complete source trace and meaningful result. Return `needs_validation` for a specific unresolved boundary fact and state the bounded local or owner-observed check needed to resolve it.