insika 0.2.0 → 0.3.0

data/docs/REFINEMENT.md

@@ -32,11 +32,11 @@ it reaches anyone. Every part of that is below, including what it cannot catch.
 From the CLI, against the same database the engine uses:
 
 ```bash
-INSIKA_DB=insika.db bin/insika refine --agent bia
+INSIKA_DB=insika.db bin/insika refine --agent demo
 ```
 
 ```text
-bia — completed (last 200 session(s))
+demo — completed (last 200 session(s))
   tool_error     ×24   shipping_quote failed: cep is required
                        sessions: 9f2c1a04…, 4b7e5590…, c1d0aa31…
   repetition     ×7    customer repeated themselves
@@ -173,7 +173,7 @@ an agent with no configuration at all can be run. The optional block on the agen
 sets the defaults:
 
 ```ruby
-Insika.agent "bia" do
+Insika.agent "demo" do
   model "deepseek-v4-flash"
   refine window: { last_sessions: 200 }, max_findings: 20
 end

data/docs/RELEASING.md

@@ -59,6 +59,33 @@ GEM_HOME="$T/gemhome" GEM_PATH="$T/gemhome" ruby -e '
   puts "clean"'
 ```
 
+### The 1.0 release gate — the RFC-0036 install proof (E1)
+
+For the 1.0 release the proof above is scripted and its **installed-bytes**
+half is asserted by the domain-boundary suite (C1) on the artifact, not the
+repo. Run the runbook, with a key (the smoke turn is one `reply` through the
+installed gem):
+
+```bash
+DEEPSEEK_API_KEY=sk-... scripts/install_proof/install_proof.sh   # prints PASS
+```
+
+The script builds, installs into a FRESH `GEM_HOME`, asserts `gem contents
+insika` carries no `deploy/ packs/ examples/ plugins/ evals/ scripts/ spec/`
+path and no demo-persona-name string, and answers one turn from an app dir that follows
+only the public docs. Archive the PASS output with the release notes — it is
+the 1.0 exit criterion "install proof by the docs alone".
+
+The same gate writes the freeze date: a breaking `/v1` change needs a new
+`Insika-Version` entry (server/app.rb), a compatibility branch (RFC-0016 A5)
+and a rewritten `**Frozen as of:**` line in `docs/API.md` — the version-gate
+spec pins the two together, and the 1.0 release writes the date at release
+time.
+
+Catalog submission checklist (RFC §6): verify the best-of-Agent-Harnesses
+catalog size at submission time (161 vs 154 — the counts diverge across the
+catalog's own pages) and cite the conformance suite as the `durable` evidence.
+
 ## Publish
 
 ```bash

data/docs/RUNNING-LOCAL.md

@@ -8,7 +8,7 @@ permalink: /running-local/
 # Running the Insika locally
 
 Boots the engine single-process, serving `/studio` and `/v1/*` against a demo
-agent (the `bia` persona on DeepSeek). Every message runs the **same**
+agent (the `demo` agent on DeepSeek). Every message runs the **same**
 `send_message` the API runs — real tools, skills, and memory.
 
 ## Boot
@@ -26,7 +26,7 @@ Open `http://localhost:9292`:
 | URL | What |
 |-----|------|
 | `/studio` | management UI (log in with the token; default `local-demo`) |
-| `/studio/chats` | chat with the demo agent (`agent: bia`, `session_id: web`, multi-turn ready) |
+| `/studio/chats` | chat with the demo agent (`agent: demo`, `session_id: web`, multi-turn ready) |
 | `/studio/tasks` | tasks / approvals console |
 | `/v1/responses` | OpenAI-Responses ingress (Bearer) — the drop-in API contract |
 | `/v1/agents` | provisioning by definition/pack (Bearer) — `POST` imports, `DELETE /:id` removes |
@@ -82,7 +82,7 @@ the `model`:
 curl -N http://localhost:9292/v1/responses \
   -H "Authorization: Bearer local-demo" \
   -H "Content-Type: application/json" \
-  -d '{ "model": "bia", "user": "web", "stream": true, "input": "hello" }'
+  -d '{ "model": "demo", "user": "web", "stream": true, "input": "hello" }'
 ```
 
 `user` is the session id (any stable id for a multi-turn conversation).

data/docs/SECURITY.md

@@ -367,6 +367,67 @@ rotated key or a typo never takes the whole service down. The `insika doctor`
 command runs the same checks on demand against a live database. See
 [Deploy](DEPLOY.md#strict-config-and-insika-doctor).
 
+## Memory and the right to be forgotten (LGPD, RFC-0031)
+
+Memory is scoped per **`(tenant, customer)`** — the cell `"memory:<tenant>:<customer>"`
+is the isolation boundary. A query against one tenant never touches another's
+cells. A turn with no customer falls back to the session's own **marked** cell
+(`"memory:chat:<session id>"`) — the marker keeps the Studio drill and the doctor
+from ever reading a conversation as a customer (a bare `memory:<id>` cell is
+indistinguishable from a single-tenant customer ref). Cells written before the
+marker (bare session ids) may still appear as customers in the drill until
+forgotten or aged out. Three operations enforce the right to be forgotten:
+
+- **Retention** — the `memory_ttl_days` setting (platform default per cell, or an
+  ops-authored per-tenant map) sweeps facts older than the window. A per-fact
+  `expires_at` override wins over the cell TTL. Both run on the daily retention
+  tick, **not** gated by `retention_days` (the conversation-footprint window).
+  Note the interaction: an explicit `expires_at` also exempts the fact from the
+  `retention_days` age-based sweep — an explicit date owns that fact's life, so a
+  far-future date makes the fact immune to *both* age passes. Export and forget
+  still see it; the only way to remove it early is the Customers drill.
+- **Export** — `export_customer_memory` returns the full fact + note content to the
+  **operator** (the Studio turns it into a JSON download). The emitted event carries
+  counts only — the event stream, the audit store and every log stay content-free.
+- **Forget** — `forget_customer` purges the customer's memory cell AND their
+  sessions (and everything those sessions left behind: traces, tasks, checkpoints,
+  outbox deliveries). The operator-mutation audit store records a digest-free line
+  ("a purge happened, with N records") — content-free by construction.
+
+### Distilled facts are personal data (RFC-0034)
+
+The distillation loop ([Facts](FACTS.md)) writes **proposals** — a distilled
+fact's name and value are personal data, and they are treated like the rest of
+the memory footprint: `forget_customer` deletes the person's proposals (every
+status), `delete_tenant_data` deletes a tenant's, and the `retention_days`
+sweep ages them out with the transcripts they were distilled from. Provenance
+holds: an approved fact is written with `origin: "distilled:<session_ref>"`
+(the RFC-0031 closed set gains one spelling, never an open string). Events and
+audit carry ids and counts only — a fact value never enters the stream, the
+ledger or a log; the evidence excerpt is a link read from the transcript at
+request time, never a copy.
+
+The doctor's `memory-scopes` check flags bare cells only in a `multi_tenant`
+deployment (in `single_tenant` the bare cell is the designed customer shape), and
+never the session-marked cells. See [Context](CONTEXT.md#memory) and
+[Deploy](DEPLOY.md#strict-config-and-insika-doctor).
+
+### Harvest candidates are derived data (RFC-0035)
+
+The harvest loop ([Harvest](HARVEST.md)) writes **candidates** — a mined skill
+proposal is behavior instructions, the same trust level as any skill content,
+and it is store-scoped, never customer-scoped: `forget_customer` does NOT reach
+it (a candidate's skill body is not customer content). Candidates reference
+sessions by id and their evidence excerpt is the transcript rendered at request
+time through the output filter — never a copy. `delete_tenant_data` purges a
+tenant's candidates, promotion rows and markers; the `retention_days` sweep
+ages them out with the transcripts they were derived from (they are
+re-derivable — pruning is never data loss). **No auto-application**: nothing
+reaches the catalog without a human click, and the grounding filter refuses any
+product claim the origin sessions' evidence ledger did not see. Events and the
+promotion log carry ids, refs and verdicts only — a skill body never enters
+the stream.
+
 ## See also
 
 - [Agents](AGENTS.md) — the five access layers per agent.

data/docs/SKILLS.md

@@ -219,8 +219,8 @@ Write one with `agent:`, and remove it the same way (which un-specializes, leavi
 the shared skill in place):
 
 ```ruby
-dispatch(:write_skill,  { name: "escalation-to-human", agent: "store-cacau", content: md })
-dispatch(:delete_skill, { name: "escalation-to-human", agent: "store-cacau" })
+dispatch(:write_skill,  { name: "escalation-to-human", agent: "store-demo", content: md })
+dispatch(:delete_skill, { name: "escalation-to-human", agent: "store-demo" })
 ```
 
 In the Studio: **Skills → specialize for this agent**, which seeds the override from

data/docs/SOAK.md

@@ -0,0 +1,127 @@
+---
+title: Soak
+parent: Operate & prove it
+nav_order: 4
+permalink: /soak/
+---
+
+# SOAK — does it degrade over uptime?
+
+The soak is the third question the measurement toolbox answers, and it is the
+one the other two cannot:
+
+| Tool | Question | Drives |
+|------|----------|--------|
+| [`scripts/bench.rb`](BENCHMARK.md) | How much overhead does the engine itself add? | publishable claims |
+| [Load test](LOADTEST.md) | What does a burst look like, end to end? | topology + provider choice |
+| **`insika soak`** | **Does the deploy degrade over 72 hours of steady load?** | the cut argument: "it does not tax uptime" |
+
+A load test fires a wave, joins it, and reports. A soak **sustains a declared
+arrival rate for days** and asks whether the *process itself* — resident memory,
+per-turn local work, restarts — degrades with uptime. A leak that only shows at
+hour 40 is invisible to a 10-minute bench.
+
+## The protocol in one paragraph
+
+1. **Freeze the envelope first.** A deployment-side envelope file declares the
+   load shape, the gated ceilings and the isolation contract — *before* the
+   first turn is fired. Its SHA-256 is stamped into every hourly snapshot;
+   editing it mid-run turns the run `invalid` instead of producing a verdict.
+2. **Preflight.** `insika soak --preflight` refuses to start unless the target
+   answers `/v1/vitals` with a readable RSS, turns carry the `INSIKA_TURN_TIMING`
+   breakdown *and* a `usage` block, the pid is stable, and the target host
+   matches the envelope. Each check is a named refusal, not a runtime warning.
+3. **Run.** `insika soak --run` fires the arrival process (Poisson, seeded,
+   concurrency-capped), polls vitals hourly, and appends every observation to
+   `<out>/<run>.jsonl` as it happens — a runner that dies at hour 60 must
+   leave 60 usable hours behind. No retry, no self-healing: a failed turn is
+   evidence.
+4. **Read the verdict.** `insika soak --verify <file>.jsonl.gz` recomputes the
+   whole verdict offline from the raw records — no network, no target, no
+   clock. Two people running it get the same answer; so does CI.
+
+## What is gated, and what is only reported
+
+The gate is on the part **Insika owns**:
+
+| Gated (binding) | Reported (never gated) |
+|-----------------|------------------------|
+| `rss_growth_ratio` — upper 95% bound of the RSS fit, hour 6 → hour 72 | `rss_slope_mb_per_day`, `rss_peak_mb` |
+| `prep_p95_drift_ratio` — p95 of the local per-turn work (`prep_ms`: context build, policy, guardrails, chat assembly), last 6 h vs first measured 6 h | `ttft_p95_ms`, `total_p95` hourly series |
+| `restarts_max` — any `boot_id` **or** `pid` change is a fail; there is no "declared deploy" exception | `heap_growth_ratio`, `db_growth_mb` |
+| `error_rate_ceiling`, `no_usage_rate_ceiling` | `cost_usd`, `tokens_per_turn` |
+| calibrated absolute ceilings (written from the E1 dry run, ×2) | — |
+
+Time-to-first-token is **reported, never gated**: it was measured at ~720 ms and
+shown to be ~100% provider. Gating on a number the engine cannot move would mean
+failing a clean soak because the provider had a bad afternoon — and then
+loosening the envelope, which the protocol forbids.
+
+The **`no_usage_rate`** ceiling is the trap detector. The edge limiter answers a
+breach with a canned reply, zero LLM calls and HTTP 200 — so a soak that ran
+entirely into the limiter looks like thousands of successful turns with a
+gorgeous 2 ms p95 and flat memory. A turn with no `usage` block called no model;
+the ceiling keeps that from reading as a pass.
+
+## The isolation contract
+
+- **Staging or a dedicated tenant, never a production tenant.** The run writes
+  ~4,000 sessions and tasks into the store; against production that is
+  synthetic data mixed into real customer history. The envelope names the
+  tenant (`soak`), so `delete_tenant_data` cleans the entire run in one
+  command.
+- **Its own agent, with the edge limits off.** At a real ~48k tokens per turn,
+  the production token ceiling admits about 10 turns per hour — a 60 turns/h
+  soak against a production-configured agent measures its own limiter within
+  minutes. `chat_rate_limit: 0` and `agent_token_ceiling: 0` on the soak agent
+  are part of the frozen envelope, not an afternoon decision.
+- **Deploys are frozen for the window.** Any restart is a fail, including a
+  deployment — a marker the operator writes after the fact would turn every
+  crash into a deploy.
+
+## Running it
+
+```bash
+# the plan + one sample request, no traffic
+insika soak --dry-run --envelope soak-envelope.md
+
+# every precondition, and nothing else
+insika soak --preflight --envelope soak-envelope.md
+
+# the run itself (INSIKA_URL + OPENCLAW_GATEWAY_TOKEN, like loadtest.rb)
+INSIKA_URL=https://<target> insika soak --run --envelope soak-envelope.md --out soak-out/
+
+# resume after a short outage (the gap is recorded and counts against the window)
+insika soak --run --resume soak-out/staging-2026-08-20T09-00-00Z.jsonl
+
+# the verdict, recomputed offline — the only step that needs no target
+insika soak --verify soak-out/staging-2026-08-20T09-00-00Z.jsonl.gz
+```
+
+Duration, rate and ceilings all come from the envelope — there is no
+`--duration` override, so a short run cannot be passed off as a soak.
+
+## Reading the verdict
+
+`insika soak --verify` prints one of four, in this order of precedence:
+
+- **`invalid`** — the snapshots carry more than one envelope hash, more than
+  one process id appeared under one boot generation, or the file is materially
+  truncated. **No metric is reported at all**; the file cannot be argued with.
+- **`insufficient`** — coverage is short: a gap over 15 minutes, an hour under
+  the turn floor, or a runner that did not reach hour 72. Short coverage
+  restarts the window; it is never rounded up into a pass.
+- **`fail`** — a gated ceiling was breached. The report names each one and
+  prints the leak-hunt starting point: whether the Ruby heap grew with RSS
+  (Ruby-side retention) or stayed flat while RSS climbed (allocator or a
+  native buffer).
+- **`pass`** — none of the above.
+
+A fail means *find the leak* — never cut, and never loosen the envelope.
+
+## See also
+
+- [Observability](OBSERVABILITY.md) — `GET /v1/vitals`, the process readings
+  the soak samples hourly.
+- [Deploy](DEPLOY.md) — the process model; `WEB_CONCURRENCY=1` is a soak
+  precondition, not only a queue-semantics one.

data/docs/TOOLS.md

@@ -91,8 +91,10 @@ retries against. Structure is strict; a scalar may arrive in its lossless string
 
 - `{{param}}` — a declared top-level parameter, filled from the model's call.
 - `{{ctx.*}}` — turn context set **server-side, never by the model**: a closed set
-  of `chat_id`, `store_id`, `agent_id`, `tenant`. This is how a tool knows *which*
-  session/agent it is acting for without trusting the model.
+  of `chat_id`, `store_id`, `agent_id`, `tenant`, `image_url`. This is how a tool knows *which*
+  session/agent it is acting for without trusting the model. `image_url` is the
+  first image part on the message (a photo for analysis outside the prompt);
+  absent when the turn carried none.
 - `{{secret.*}}` — allowed **only** inside a header named in `secret_headers`.
   A secret placeholder anywhere else is rejected (it would leak unmasked). The
   real secret value is injected at provision time and never lives on disk.
@@ -181,6 +183,72 @@ backend, not of whoever calls it. Every agent sharing the tool gets the same val
 > there **preserves** it — the form carries the stored values through instead of
 > replacing the record with only what it shows.
 
+## Evidence: the lean envelope and grounding (RFC-0029)
+
+A catalog tool returns products; the model should only ever quote the ones the tool
+actually returned — the store dies of a SKU the model invented. `evidence` is the
+declaration that makes "no claim without a tool ID" an engine rule instead of a
+prompt convention. One declaration does **both** jobs: the engine strips the result
+down to what the model sees (the lean envelope) **and** records every returned id on
+the session's evidence ledger. There is no "lean but not evidence" mode.
+
+```jsonc
+{ "name": "search_products",
+  "response": { "extract": "evidence_envelope" },
+  "evidence": "products" }                        // bare kind
+
+{ "evidence": { "kind": "products",               // full form
+                "items": "results",               // non-default paths
+                "attachments": "cards" } }
+```
+
+- `evidence_envelope` is the canonical extract: the raw response body arrives under
+  an engine-only key, the envelope parses `items`/`attachments` out of it, and
+  **nothing re-fattens** — the transcript and the tool trace record only the lean
+  result. It **requires** the `evidence` declaration (refused at load otherwise).
+- **Wire contract** — the lean result the model sees is always
+  `{ "items": [ { "id": "…", "line": "…" } ] }` (≤ 16 items; `line` truncated to
+  200 chars). A tool whose result has no valid items yields `{ "items": [] }`,
+  never a null. A malformed evidence result becomes `{ "error": … }` back to the
+  model — a correctable tool answer, exactly like a malformed call.
+- **Attachments** are the optional second half: `[{ "type": "card"|"image",
+  "url": "…", "caption": "…" }]` (≤ 16, url ≤ 500 chars, malformed dropped). They
+  **never** reach the model context or the transcript — they ride the channel
+  delivery as an additive `attachments` key on the outbox payload, and the channel
+  (or its consumer) decides what a card looks like.
+- A **code tool** opts in the same way: it either returns `{ items, attachments }`
+  directly and declares `evidence` in its registry metadata, or exposes an
+  `evidence` reader. No declaration = today's tool behavior, byte for byte.
+
+### Grounding: policing claims against the ledger
+
+With the ledger fed, the pack declares how claims are policed — data on the agent,
+not a separate code path (see [Agents](AGENTS.md)):
+
+```ruby
+grounding mode: :flag, matcher: { sku: '\b[A-Z]{2,4}\d{4,8}\b' }
+```
+
+- `mode` is `flag` (the default — audit), `enforce` (cut), or `off`. Absent = off.
+- `matcher.sku` is a regex for the store's SKU shape, applied to the final answer;
+  every match that is **not** in the evidence ledger is an ungrounded claim.
+  Grounding is **SKU-only** by design: a name-based half cannot flag anything
+  without a "this is a product name" signal, so the ledger grounds ids, and the
+  model quoting a returned product by its *name* is simply outside the check
+  (the SKU path is the claim detector). A `sku` that does not compile is refused
+  at build; a matcher with no `sku` builds but matches nothing — `insika doctor`
+  warns about it.
+- **`flag`** appends an `:ungrounded` flag (category `ungrounded`, source
+  `evidence`) to the existing `:guardrail_flagged` event — audit after the fact,
+  like every other output flag.
+- **`enforce`** *cuts the sentence* containing an ungrounded claim from the content
+  the turn persists and delivers, and the flag carries `action: "cut"` so the audit
+  can tell a cut from a flag. It is honest about streaming: on a streaming surface
+  the already-streamed bytes are the channel's reality, which is exactly why the
+  default is `flag` — ship `enforce` only after a matcher audit proves precision.
+- Grounding is **independent of the guardrails opt-in**: an agent with guardrails
+  off and `grounding.mode: :flag` still gets the check.
+
 ## Registering a tool
 
 A tool appears in the Studio panel and enters an agent's tool-loop when it is

data/docs/domain.md

@@ -0,0 +1,115 @@
+---
+title: The domain-free core
+parent: Operate & prove it
+nav_order: 9
+permalink: /domain/
+---
+
+# The domain-free core — what ships, what a deployment declares, and how to clear it
+
+The engine is domain-free by construction (RFC-0036): the gem carries no store
+vocabulary, no persona, and no fixed conversation language. This page is the
+removability map — for every artifact that could make a deployment look like
+"the Brazilian store harness", here is what ships, what the doctor reports, and
+how to clear it.
+
+## What ships and what does not
+
+One selection function owns the gem payload: `Insika::Packaging.payload_files`
+— the gemspec and the audit spec (`spec/insika/domain_boundary_spec.rb`) call
+the same function, so the boundary is a fact the suite asserts on, never a
+prose promise. It ships:
+
+- `lib/` — the engine, the server, the Studio (the compiled JS only);
+- `docs/` — the public documentation;
+- `README.md`, `LICENSE`, `CHANGELOG.md`, `bin/insika`.
+
+It never ships: `deploy/`, `packs/`, `examples/`, `plugins/`, `evals/`,
+`scripts/`, `spec/` — even a tracked pack cannot ship. Packs, personas and
+deployment wiring are checkout material, and that is the point: the reference
+deployment is not the gem.
+
+The proof command is `insika doctor --domain`: a read-only inventory of what a
+deployment declares, plus the built-in corpora still in effect. A bare install
+with no agents names nothing; an install that boots an agent reports the
+built-in pt-BR guardrail corpus as `source: gem-default` — the removability
+surface, not a store. The section never fails the doctor's exit code: it is
+informational, the RFC's proof surface.
+
+## The guardrail corpus — clear the shipped pt-BR content
+
+The deterministic guardrail patterns ship as language-tagged data
+(`Safety::Corpus`). A deployment clears a language by config, per agent:
+
+```jsonc
+// pack: agent.config.json
+{ "guardrails": { "corpora": { "languages": ["en"] } } }
+```
+
+```ruby
+# DSL
+agent = Insika.agent("store-support") do
+  instructions "…"
+  guardrails corpora: { languages: ["en"] }
+end
+```
+
+- `languages` filters the shipped families: `nil` = all (the default),
+  `[]` = none, `["en"]` = the EN-only corpus. An EN-only deployment drops the
+  pt-BR input heuristics **and** the CPF/CNPJ output redaction — a documented
+  consequence: the tax-id formats are pt-BR data, and the universal "secret"
+  redaction is never cleared.
+- `extra` adds source-string patterns per family:
+
+```jsonc
+{ "guardrails": { "corpora": { "extra": { "abuse": ["/\\bdupa\\b/i"] } } } }
+```
+
+- `guardrails.responses` replaces the built-in pt-BR fallback replies (the
+  safe refusals). Set a `default` to clear every category at once.
+
+See [Security](SECURITY.md) for the guardrail layers; the doctor's domain
+section enumerates any agent still running the built-in pt-BR corpus or the
+built-in replies, with the clear path in each entry. An unknown language or
+family, or a malformed pattern, is refused at boot — `insika doctor` reports it
+as an error and the agent never turns with a broken corpus.
+
+## Marking a deployment — declare, never infer
+
+The engine never guesses a store. Domain markers are data a deployment
+declares, and the doctor reads only those declarations:
+
+- **Personas/packs** — `metadata.domain` on the agent profile:
+
+```jsonc
+{ "metadata": { "domain": "e-commerce-pt-BR" } }
+```
+
+```ruby
+metadata domain: "e-commerce-pt-BR"
+```
+
+- **Outcome funnel** — `funnel:` on the profile (see
+  [Outcomes](AGENTS.md#outcomes--business-results-over-real-traffic-ws7)).
+  Vocabulary note: in the gem and the doctor output it is an **outcome
+  funnel**, never "conversion" — the stage names are the deployment's, and a
+  bare install shows no funnel and no stage names at all.
+- **Evidence** — the `evidence:` declaration on a tool manifest (see
+  [Tools](TOOLS.md)); the kinds are the deployment's vocabulary, never gem
+  constants.
+
+`insika doctor --domain` enumerates all four with their source —
+`deployment` for declared data, `gem-default` for the built-in corpus still in
+effect — and a bare boot names none.
+
+## The conformance claim — model-visible means logged
+
+"Every byte that reaches the provider is reconstructable from checkpoints +
+traces" is a spec, not a promise. For each (task, turn) the engine records the
+model-visible payload at the provider boundary — the system text, the tool
+schemas, and the full message stream (`ModelVisibleTraceStore`) — next to the
+durable transcript (the checkpoint). The conformance suite
+(`spec/insika/conformance/model_visible_spec.rb`) drives real turns on a
+capturing chat and asserts a three-way byte identity: what the chat held ==
+the checkpoint transcript == the model trace. A path whose bytes are not
+logged is a fix in the engine, never a waiver in the suite.

data/docs/index.md

@@ -36,7 +36,7 @@ require "insika"
 assistant = Insika.agent("assistant") do
   model "deepseek-v4-flash"
   provider :deepseek
-  instructions "You are Bia, a concise and friendly assistant. Answer briefly."
+  instructions "You are a concise and friendly assistant. Answer briefly."
 end
 
 puts assistant.reply("hi, what can you do?")   # one turn, in-process