ai-capability-framework 1.0.0-rc.3 → 1.0.0

package/docs/controls/index.md

@@ -1,23 +1,22 @@
 # Runtime Controls
 
-AICF controls let a host application narrow or stop capability use without
-changing manifests. They are optional runtime inputs, not a production control
-plane or model gateway.
+AICF controls let a host application narrow or stop capability use without changing
+manifests. They are optional runtime inputs, not a production control plane or model
+gateway.
 
-Controls can apply to a global runtime, provider, model, capability, domain,
-risk tier, tenant, or autonomy tier. AICF evaluates them before capability
-routing, tool export, model tool execution, lifecycle commit, and supported
-provider runtime calls.
+Controls can apply to a global runtime, provider, model, capability, domain, risk tier,
+tenant, or autonomy tier. AICF evaluates them before capability routing, tool export,
+model tool execution, lifecycle commit, and supported provider runtime calls.
 
 ## Kill Switches
 
 Kill switches are the fastest control:
 
 - `deny` blocks matching capability export and execution.
-- `force_approval` keeps read and prepare paths available, but forces host
-  approval before lifecycle commit.
-- `read_only` keeps read/select paths available and blocks prepare, commit,
-  write, send, money-movement, and destructive capabilities.
+- `force_approval` keeps read and prepare paths available, but forces host approval
+  before lifecycle commit.
+- `read_only` keeps read/select paths available and blocks prepare, commit, write, send,
+  money-movement, and destructive capabilities.
 
 Example:
 
@@ -33,11 +32,10 @@ Example:
 
 ## Circuit Breakers
 
-Circuit breakers evaluate recent runtime signals such as provider error rate,
-validation failure rate, approval rejection rate, tool-loop limit hits, and
-budget failures. F4 includes deterministic evaluation and in-memory/reference
-state only. Production metrics ingestion and durable storage remain host
-responsibilities.
+Circuit breakers evaluate recent runtime signals such as provider error rate, validation
+failure rate, approval rejection rate, tool-loop limit hits, and budget failures. F4
+includes deterministic evaluation and in-memory/reference state only. Production metrics
+ingestion and durable storage remain host responsibilities.
 
 ## Budgets
 
@@ -48,13 +46,12 @@ Budgets limit one run. Defaults apply when controls are configured:
 - 60 seconds runtime per run
 - 2 retries per run
 
-Token and estimated-cost budgets are optional fields. Hard budgets fail closed;
-warn budgets return warnings without blocking.
+Token and estimated-cost budgets are optional fields. Hard budgets fail closed; warn
+budgets return warnings without blocking.
 
 ## CLI
 
-Local CLI state uses `.aicf/controls.json`, which is ignored and must not be
-tracked.
+Local CLI state uses `.aicf/controls.json`, which is ignored and must not be tracked.
 
 ```bash
 aicf controls list --format json
@@ -62,5 +59,5 @@ aicf controls check examples --capability support.refund.prepare_case --provider
 aicf controls kill-switch create --capability support.refund.prepare_case --mode force_approval --reason "incident review"
 ```
 
-The CLI is useful for local review and demos. Host applications should provide
-their own authenticated control store for production.
+The CLI is useful for local review and demos. Host applications should provide their own
+authenticated control store for production.

package/docs/core/capability-manifests.md

@@ -1,8 +1,7 @@
 # Capability Manifests
 
-Capability manifests are the core AICF contract. They describe the operation,
-input and output schemas, lifecycle, permissions, risk, policy, and eval
-coverage.
+Capability manifests are the core AICF contract. They describe the operation, input and
+output schemas, lifecycle, permissions, risk, policy, and eval coverage.
 
 Use the existing guide for the full field reference:
 
@@ -16,5 +15,5 @@ node dist/cli.js inspect examples
 node dist/cli.js validate examples
 ```
 
-The examples are synthetic and use fake support tickets, orders, and scheduling
-data only.
+The examples are synthetic and use fake support tickets, orders, and scheduling data
+only.

package/docs/core/entity-manifests.md

@@ -1,8 +1,8 @@
 # Entity Manifests
 
-Entity manifests describe application objects that capabilities can read,
-prepare, or commit against. They help AICF explain impact, governance coverage,
-and allowed actions without exposing raw databases or broad application APIs.
+Entity manifests describe application objects that capabilities can read, prepare, or
+commit against. They help AICF explain impact, governance coverage, and allowed actions
+without exposing raw databases or broad application APIs.
 
 Public examples:
 
@@ -17,5 +17,5 @@ Validate them with:
 node dist/cli.js validate examples
 ```
 
-Entity docs stay intentionally small. Capability manifests own the callable
-schemas and lifecycle rules.
+Entity docs stay intentionally small. Capability manifests own the callable schemas and
+lifecycle rules.

package/docs/eval-runner.md

@@ -1,16 +1,16 @@
 # Eval Runner
 
-The deterministic eval runner scores AICF eval manifests against candidate
-result fixtures without calling models, executing capabilities, storing traces,
-or reading raw provider payloads.
+The deterministic eval runner scores AICF eval manifests against candidate result
+fixtures without calling models, executing capabilities, storing traces, or reading raw
+provider payloads.
 
-Host applications are responsible for producing candidate results. AICF only
-validates and scores the summarized behavior.
+Host applications are responsible for producing candidate results. AICF only validates
+and scores the summarized behavior.
 
 ## Mental Model
 
-An eval manifest says what should happen. A candidate result says what did
-happen in a mock run, live run, or host test. The eval runner compares the two.
+An eval manifest says what should happen. A candidate result says what did happen in a
+mock run, live run, or host test. The eval runner compares the two.
 
 Eval manifest excerpt:
 
@@ -43,8 +43,8 @@ Candidate result excerpt:
 }
 ```
 
-That pair passes because the expected capability was selected, the tool
-arguments match the manifest expectations, and no unapproved commit happened.
+That pair passes because the expected capability was selected, the tool arguments match
+the manifest expectations, and no unapproved commit happened.
 
 Failure example:
 
@@ -57,21 +57,20 @@ Failure example:
 }
 ```
 
-This fails because the candidate selected a commit capability and records a
-commit where the eval expected only preparation. The runner reports the failed
-scorer instead of calling a model to repair it.
+This fails because the candidate selected a commit capability and records a commit where
+the eval expected only preparation. The runner reports the failed scorer instead of
+calling a model to repair it.
 
-Sanitized replay traces can also become draft eval manifests. Use this when a
-mock or live run produced a useful public-safe behavior summary and you want to
-lock it in as a regression case. See
-[Replay and trace-to-golden](evals/replay-and-trace-to-golden.md).
+Sanitized replay traces can also become draft eval manifests. Use this when a mock or
+live run produced a useful public-safe behavior summary and you want to lock it in as a
+regression case. See [Replay and trace-to-golden](evals/replay-and-trace-to-golden.md).
 
 ## Candidate Fixture
 
-Candidate fixtures are JSON files with `schema_version: "1.0"` and a `results`
-array. Each result is keyed by `eval_id` and may include selected capabilities,
-tool calls, policy decision, action state, committed capabilities, refusal
-information, and response text.
+Candidate fixtures are JSON files with `schema_version: "1.0"` and a `results` array.
+Each result is keyed by `eval_id` and may include selected capabilities, tool calls,
+policy decision, action state, committed capabilities, refusal information, and response
+text.
 
 ```json
 {
@@ -95,9 +94,8 @@ information, and response text.
 }
 ```
 
-Keep fixtures synthetic and public-safe. Do not commit raw prompts, raw traces,
-provider payloads, customer records, secrets, internal endpoints, or private
-documents.
+Keep fixtures synthetic and public-safe. Do not commit raw prompts, raw traces, provider
+payloads, customer records, secrets, internal endpoints, or private documents.
 
 ## Scorers
 
@@ -112,12 +110,12 @@ The runner supports the scorer types used by the public eval examples:
 - `response_excludes_private_detail`
 
 It also enforces `expected.response.must_include` and
-`expected.response.must_not_include` whenever those fields are present. Unknown
-scorer types fail closed.
+`expected.response.must_not_include` whenever those fields are present. Unknown scorer
+types fail closed.
 
-`no_unapproved_commit` fails when a candidate has `action_state: "committed"`,
-non-empty `committed_capabilities`, or a tool call to a capability whose
-manifest is a commit capability.
+`no_unapproved_commit` fails when a candidate has `action_state: "committed"`, non-empty
+`committed_capabilities`, or a tool call to a capability whose manifest is a commit
+capability.
 
 ## CLI
 
@@ -134,6 +132,6 @@ For machine-readable output:
 node dist/cli.js eval examples --results examples/eval-results/public.results.passing.json --format json
 ```
 
-The command exits `0` only when manifests are valid, the result fixture is valid,
-every loaded eval has a candidate result, and all scorer checks pass. Failed
-checks, missing candidates, invalid fixtures, and unknown scorers exit nonzero.
+The command exits `0` only when manifests are valid, the result fixture is valid, every
+loaded eval has a candidate result, and all scorer checks pass. Failed checks, missing
+candidates, invalid fixtures, and unknown scorers exit nonzero.

package/docs/evalops.md

@@ -1,7 +1,7 @@
 # EvalOps Export Interfaces
 
-AICF EvalOps helpers convert public-safe AICF eval cases and summarized results
-into formats that host applications can send to external eval systems.
+AICF EvalOps helpers convert public-safe AICF eval cases and summarized results into
+formats that host applications can send to external eval systems.
 
 Import from:
 
@@ -14,25 +14,24 @@ import {
 } from "ai-capability-framework/evalops";
 ```
 
-The EvalOps subpath does not call Braintrust, OpenAI, Promptfoo, or any model
-provider. It does not require provider SDKs and does not upload data.
+The EvalOps subpath does not call Braintrust, OpenAI, Promptfoo, or any model provider.
+It does not require provider SDKs and does not upload data.
 
 ## What Is Exported
 
-Exports include eval IDs, user-message fixtures, expected summaries, scorer
-names, tags, and capability-under-test metadata. Raw prompts, raw provider
-payloads, traces, secrets, tokens, private diagnostics, account IDs, tenant IDs,
-and customer data are not included.
+Exports include eval IDs, user-message fixtures, expected summaries, scorer names, tags,
+and capability-under-test metadata. Raw prompts, raw provider payloads, traces, secrets,
+tokens, private diagnostics, account IDs, tenant IDs, and customer data are not
+included.
 
 ## Promptfoo
 
 Promptfoo support remains in `ai-capability-framework/promptfoo`.
-`exportPromptfooSuite()` generates files only. It includes an API-key-free echo
-provider by default plus README guidance for replacing provider placeholders in
-a host-owned test environment.
+`exportPromptfooSuite()` generates files only. It includes an API-key-free echo provider
+by default plus README guidance for replacing provider placeholders in a host-owned test
+environment.
 
 ## Host Responsibilities
 
-Host applications own external service accounts, credentials, dataset
-retention, eval execution, dashboards, alerting, and review workflows.
-
+Host applications own external service accounts, credentials, dataset retention, eval
+execution, dashboards, alerting, and review workflows.

package/docs/evals/golden-tests.md

@@ -1,8 +1,7 @@
 # Golden Tests
 
-Golden evals capture the behavior AICF should preserve: selected capabilities,
-tool call IDs, valid arguments, policy decisions, action states, and safe
-output.
+Golden evals capture the behavior AICF should preserve: selected capabilities, tool call
+IDs, valid arguments, policy decisions, action states, and safe output.
 
 Run the public passing fixture:
 
@@ -16,5 +15,5 @@ Expected output excerpt:
 Eval suite passed
 ```
 
-Golden tests do not call models. Candidate results come from mocks, examples,
-or optional live runs that the host explicitly enables.
+Golden tests do not call models. Candidate results come from mocks, examples, or
+optional live runs that the host explicitly enables.

package/docs/evals/overview.md

@@ -1,8 +1,8 @@
 # Eval Overview
 
-AICF evals are deterministic fixtures. They prove capability selection,
-expected tool calls, policy outcomes, approval behavior, and no-commit
-boundaries without calling a model.
+AICF evals are deterministic fixtures. They prove capability selection, expected tool
+calls, policy outcomes, approval behavior, and no-commit boundaries without calling a
+model.
 
 Read:
 

package/docs/evals/replay-and-trace-to-golden.md

@@ -3,9 +3,8 @@
 Replay turns a sanitized runtime trace into something you can compare later.
 Trace-to-golden turns that same trace into a draft eval case.
 
-Both features are API-key-free by default. They do not call models, import
-provider SDKs, execute handlers, store raw prompts, or keep raw provider
-payloads.
+Both features are API-key-free by default. They do not call models, import provider
+SDKs, execute handlers, store raw prompts, or keep raw provider payloads.
 
 ## What Goes In A Replay Trace
 
@@ -20,8 +19,8 @@ A replay trace is a public-safe summary, not a raw trace. It can include:
 - a redacted final response summary;
 - hashes and redaction summaries.
 
-Do not put raw prompts, raw provider payloads, raw tool outputs, secrets,
-customer records, tenant IDs, account IDs, or stack traces in replay fixtures.
+Do not put raw prompts, raw provider payloads, raw tool outputs, secrets, customer
+records, tenant IDs, account IDs, or stack traces in replay fixtures.
 
 The public example is:
 
@@ -37,21 +36,21 @@ examples/support/replay/support.refund.approval_required.trace.json
 node dist/cli.js replay run examples/support/replay/support.refund.approval_required.trace.json --mode deterministic_mock
 ```
 
-`policy_only` reruns AICF policy decisions against the current manifests and
-redacted decision context.
+`policy_only` reruns AICF policy decisions against the current manifests and redacted
+decision context.
 
 ```bash
 node dist/cli.js replay run examples/support/replay/support.refund.approval_required.trace.json --mode policy_only --manifest-root examples
 ```
 
-`router_only` reruns deterministic capability selection and checks whether the
-selected capability slice changed.
+`router_only` reruns deterministic capability selection and checks whether the selected
+capability slice changed.
 
-`tool_validation_only` validates recorded tool-call arguments against the
-current capability input schemas.
+`tool_validation_only` validates recorded tool-call arguments against the current
+capability input schemas.
 
-`provider_live` is guarded. It refuses by default unless the host explicitly
-enables live replay and provides its own runner/client.
+`provider_live` is guarded. It refuses by default unless the host explicitly enables
+live replay and provides its own runner/client.
 
 ## Create A Draft Eval
 
@@ -62,8 +61,8 @@ node dist/cli.js evals create-from-trace examples/support/replay/support.refund.
 ```
 
 The generated eval uses redacted user text by default and marks itself as
-review-required in `extensions.aicf_replay`. Review the draft before moving it
-under `examples/**/evals/`.
+review-required in `extensions.aicf_replay`. Review the draft before moving it under
+`examples/**/evals/`.
 
 ## What The Draft Proves
 
@@ -75,8 +74,8 @@ The generated eval can assert:
 - action state such as `approval_required`;
 - no unapproved commit;
 - forbidden commit tool calls;
-- response text must not expose private diagnostics, raw prompts, provider
-  payloads, tokens, or secrets.
+- response text must not expose private diagnostics, raw prompts, provider payloads,
+  tokens, or secrets.
 
 ## TypeScript API
 
@@ -88,6 +87,6 @@ import {
 } from "ai-capability-framework/replay";
 ```
 
-Host applications own production trace collection, storage, retention, review
-workflow, and any live-provider replay runner. AICF only provides public-safe
-contracts and deterministic comparison helpers.
+Host applications own production trace collection, storage, retention, review workflow,
+and any live-provider replay runner. AICF only provides public-safe contracts and
+deterministic comparison helpers.

package/docs/evals.md

@@ -1,10 +1,10 @@
 # Evals
 
-Eval cases keep capability behavior from drifting as prompts, models, policies,
-and routing code change.
+Eval cases keep capability behavior from drifting as prompts, models, policies, and
+routing code change.
 
-Each eval should be synthetic, deterministic, and tied to a specific behavior.
-See [the 1.0 spec](spec.md) for public-safe example rules.
+Each eval should be synthetic, deterministic, and tied to a specific behavior. See
+[the 1.0 spec](spec.md) for public-safe example rules.
 
 ## Useful Eval Types
 
@@ -19,25 +19,24 @@ See [the 1.0 spec](spec.md) for public-safe example rules.
 ## Public Example Rule
 
 Public examples must use fake identifiers, fake users, fake tenants, and generic
-domains. Do not commit real traces, customer records, raw prompts, internal
-schemas, or provider payloads.
+domains. Do not commit real traces, customer records, raw prompts, internal schemas, or
+provider payloads.
 
-AICF validation checks that eval files referenced by capability manifests are
-present in the loaded manifest bundle.
+AICF validation checks that eval files referenced by capability manifests are present in
+the loaded manifest bundle.
 
-Decision behavior should be covered with synthetic request examples and tests
-for permission denial, autonomy denial, approval requirements, deny facts,
-missing facts, approval state, and idempotency keys.
+Decision behavior should be covered with synthetic request examples and tests for
+permission denial, autonomy denial, approval requirements, deny facts, missing facts,
+approval state, and idempotency keys.
 
-AICF includes a deterministic eval runner for scoring public-safe candidate
-result fixtures against eval manifests. See [the eval runner guide](eval-runner.md)
-for fixture shape, scorer behavior, and CLI usage.
+AICF includes a deterministic eval runner for scoring public-safe candidate result
+fixtures against eval manifests. See [the eval runner guide](eval-runner.md) for fixture
+shape, scorer behavior, and CLI usage.
 
-Sanitized replay traces can be converted into review-required eval drafts when
-you want to turn observed behavior into a regression case. See
+Sanitized replay traces can be converted into review-required eval drafts when you want
+to turn observed behavior into a regression case. See
 [Replay and trace-to-golden](evals/replay-and-trace-to-golden.md).
 
-Capability-aware security packs can generate synthetic eval-style cases for
-risks such as approval bypass, unsafe commit attempts, prompt injection,
-provider payload exposure, and cross-tenant access. See
-[security packs](security/security-packs.md).
+Capability-aware security packs can generate synthetic eval-style cases for risks such
+as approval bypass, unsafe commit attempts, prompt injection, provider payload exposure,
+and cross-tenant access. See [security packs](security/security-packs.md).

package/docs/evidence.md

@@ -1,13 +1,13 @@
 # Evidence Export
 
-The evidence subpath creates public-safe review packs from AICF manifests and
-supplied runtime/eval reports. Evidence packs are summaries for human review;
-they are not certification, audit opinions, legal opinions, security
-guarantees, or compliance attestations.
+The evidence subpath creates public-safe review packs from AICF manifests and supplied
+runtime/eval reports. Evidence packs are summaries for human review; they are not
+certification, audit opinions, legal opinions, security guarantees, or compliance
+attestations.
 
-Evidence export does not call models, run providers, execute handlers, store
-records, or inspect raw traces. It only summarizes the registry and optional
-reports that the host supplies.
+Evidence export does not call models, run providers, execute handlers, store records, or
+inspect raw traces. It only summarizes the registry and optional reports that the host
+supplies.
 
 ## CLI
 
@@ -38,8 +38,8 @@ node dist/cli.js evidence export examples \
   --security-report security-report.json
 ```
 
-If optional reports are missing, the pack records that as a coverage gap instead
-of implying evidence exists.
+If optional reports are missing, the pack records that as a coverage gap instead of
+implying evidence exists.
 
 ## TypeScript
 
@@ -68,23 +68,22 @@ const markdown = formatEvidencePackMarkdown(pack);
 An evidence pack includes:
 
 - capability, risk, provider, and policy inventories;
-- eval, security-pack, provider-conformance, approval, retention, and human
-  review summaries;
+- eval, security-pack, provider-conformance, approval, retention, and human review
+  summaries;
 - optional incident and model-upgrade summaries supplied by the host;
 - explicit coverage gaps;
 - required disclaimers;
 - redaction metadata describing what was omitted.
 
-The pack includes hashes, redacted refs, statuses, counts, reasons, and
-coverage metadata only. It must not include raw prompts, raw provider payloads,
-raw transcripts, secrets, stack traces, unredacted tenant/account/user IDs, or
-sensitive tool output.
+The pack includes hashes, redacted refs, statuses, counts, reasons, and coverage
+metadata only. It must not include raw prompts, raw provider payloads, raw transcripts,
+secrets, stack traces, unredacted tenant/account/user IDs, or sensitive tool output.
 
 For customer-facing generated documents or media, use
-`ai-capability-framework/provenance` to create a separate sidecar record that
-links content to provider, model, capability, source, approval, and trace refs.
-Evidence packs summarize review posture; provenance records describe a specific
-generated content artifact.
+`ai-capability-framework/provenance` to create a separate sidecar record that links
+content to provider, model, capability, source, approval, and trace refs. Evidence packs
+summarize review posture; provenance records describe a specific generated content
+artifact.
 
 ## Control Plane
 
@@ -94,11 +93,11 @@ The control-plane evidence endpoint remains available:
 POST /api/aicf/evidence/export
 ```
 
-It preserves its existing response shape and also exposes a canonical F13
-evidence pack under `canonicalEvidence`.
+It preserves its existing response shape and also exposes a canonical F13 evidence pack
+under `canonicalEvidence`.
 
 ## Host Responsibilities
 
 Your app owns production evidence collection, approval identity, retention,
-legal/compliance review, external audit workflow, and any regulated reporting.
-AICF only creates a structured, public-safe summary from the data you provide.
+legal/compliance review, external audit workflow, and any regulated reporting. AICF only
+creates a structured, public-safe summary from the data you provide.

package/docs/gemini-runtime.md

@@ -1,19 +1,19 @@
 # Google Gemini Runtime
 
-The Gemini runtime is an optional provider adapter for GenerateContent function
-calling. It translates a routed AICF capability slice into Gemini function
-declarations, runs a bounded `models.generateContent` loop with a
-caller-provided client, executes function calls through `AicfToolExecutor`, and
-returns Gemini-compatible `functionResponse` parts.
+The Gemini runtime is an optional provider adapter for GenerateContent function calling.
+It translates a routed AICF capability slice into Gemini function declarations, runs a
+bounded `models.generateContent` loop with a caller-provided client, executes function
+calls through `AicfToolExecutor`, and returns Gemini-compatible `functionResponse`
+parts.
 
 It does not expose commit tools, enable Gemini built-in tools, use automatic
-provider-side execution, persist state, log raw provider payloads, or make
-root/runtime imports depend on the Google GenAI SDK.
+provider-side execution, persist state, log raw provider payloads, or make root/runtime
+imports depend on the Google GenAI SDK.
 
 ## Import
 
-Install AICF plus the optional Google GenAI SDK only in applications that use
-this subpath:
+Install AICF plus the optional Google GenAI SDK only in applications that use this
+subpath:
 
 ```bash
 npm install ai-capability-framework @google/genai
@@ -27,8 +27,8 @@ import {
 } from "ai-capability-framework/providers/gemini";
 ```
 
-`createDefaultGeminiClient()` dynamically imports the optional `@google/genai`
-package. Host applications may instead pass any compatible client with
+`createDefaultGeminiClient()` dynamically imports the optional `@google/genai` package.
+Host applications may instead pass any compatible client with
 `models.generateContent(input)`.
 
 ## Runtime Shape
@@ -37,43 +37,41 @@ Minimal usage is: validate manifests, build a routed runtime slice, register
 read/prepare handlers, create or pass a Gemini-compatible client, then call
 `runGeminiGenerateContent()` with host-owned contents and runtime context.
 
-The host application is responsible for building runtime context, routing
-capabilities, registering handlers, and providing initial Gemini contents.
+The host application is responsible for building runtime context, routing capabilities,
+registering handlers, and providing initial Gemini contents.
 
 `runGeminiGenerateContent()` sends `model`, `contents`, and `config` to
-`client.models.generateContent()`. AICF places routed read/prepare capabilities
-under `config.tools: [{ functionDeclarations }]` and can pass optional
+`client.models.generateContent()`. AICF places routed read/prepare capabilities under
+`config.tools: [{ functionDeclarations }]` and can pass optional
 `toolConfig.functionCallingConfig.mode` plus `allowedFunctionNames`.
 
-When Gemini returns function calls, AICF parses both `response.functionCalls`
-and candidate content parts. Calls are mapped through the generated binding map,
-arguments are validated against the original AICF schema, and only read or
-prepare execution is delegated to the runtime executor.
+When Gemini returns function calls, AICF parses both `response.functionCalls` and
+candidate content parts. Calls are mapped through the generated binding map, arguments
+are validated against the original AICF schema, and only read or prepare execution is
+delegated to the runtime executor.
 
 Tool results are appended as user content parts shaped as
-`{ functionResponse: { id, name, response: { result } } }`. The `id` is
-preserved when Gemini provides one. Approval-required prepare results are
-returned as model-safe envelopes without committing the action.
+`{ functionResponse: { id, name, response: { result } } }`. The `id` is preserved when
+Gemini provides one. Approval-required prepare results are returned as model-safe
+envelopes without committing the action.
 
 ## Boundary
 
 The Gemini runtime follows the same provider-neutral boundary as the OpenAI and
 Anthropic runtimes:
 
-- AICF capability manifests, policy, lifecycle, and runtime envelopes remain the
-  source of truth.
-- Gemini function declarations are provider descriptors, not trusted execution
-  policy.
-- Commit, destructive, money-moving, and external-send capabilities are not
-  exported by default and are not executable through provider tool calls.
-- Raw prompts, provider request/response payloads, traces, credentials, and
-  private diagnostics are not captured by default.
+- AICF capability manifests, policy, lifecycle, and runtime envelopes remain the source
+  of truth.
+- Gemini function declarations are provider descriptors, not trusted execution policy.
+- Commit, destructive, money-moving, and external-send capabilities are not exported by
+  default and are not executable through provider tool calls.
+- Raw prompts, provider request/response payloads, traces, credentials, and private
+  diagnostics are not captured by default.
 - Live tests are opt-in with `RUN_LIVE_GEMINI=1`, `GEMINI_API_KEY`, and
   `AICF_GEMINI_MODEL`.
 
-Known limitations: no streaming, no Gemini built-in tools, no automatic
-provider-side function execution, no production storage, and no model-exposed
-commit path.
+Known limitations: no streaming, no Gemini built-in tools, no automatic provider-side
+function execution, no production storage, and no model-exposed commit path.
 
 ## Checks