insika 0.2.0 → 0.7.0

data/docs/OUTCOMES.md

@@ -0,0 +1,137 @@
+---
+title: Outcomes and follow-ups
+parent: Improve
+nav_order: 3
+permalink: /outcomes/
+---
+
+# Outcomes and follow-ups
+
+## Outcomes — business results over real traffic
+
+The engine measures what it is told to measure. The operator or the integration
+records a conversation's business outcome after the fact — `conversion`,
+`escalation`, `deflected`, anything, optionally with a monetary `value`:
+
+```bash
+curl -X POST /v1/outcomes -H "Authorization: Bearer $TOKEN" \
+  -d '{ "agent": "store-support", "session_id": "chat-7",
+        "outcome": "conversion", "value": 129.9 }'
+```
+
+The endpoint is **additive and outside the response contract** — the turn never
+knows or cares; the engine transports the outcome and never interprets it (what
+"conversion" means is yours). Records are tenant-stamped (a tenant principal
+writes and reads only its own), and `GET /v1/outcomes?agent=` serves the last
+outcome per agent plus the per-day series — the last-outcome pill on the Studio
+agent grid, and the per-day series on the agent detail.
+
+### The outcome funnel
+
+A store's funnel is pack data on the agent — the engine folds outcomes into
+the **declared** stages, and never hard-codes one itself (the stage vocabulary
+is the forge's):
+
+```ruby
+agent = Insika.agent("store-support") do
+  instructions "…"
+  funnel stages: %w[greeted qualified cart paid],
+         advance_on: { "abandoned_cart" => "cart", "pix_paid" => "paid" },
+         primary: "paid", attribution_window: "72h"
+end
+```
+
+The fold contract:
+
+- **Tick-driven, cumulative event counts on the declared order.** An outcome of
+  kind K means the session *reached* `advance_on[K]`; the fold increments
+  `stages[0..index]` for the reached stage. A per-stage-complete integration
+  and a terminal-event integration therefore produce identical counts — a
+  session that paid also emitted the earlier events. A duplicate event
+  double-counts (the integration's defect, not the engine's); **do not declare
+  a stage off the linear path** (a "handoff" stage would be inflated by every
+  later event). Counts are **event counts, not distinct sessions** — the
+  baseline is events-based.
+- **Idempotent**: a per-pair `{at, ids}` cursor inside one transaction; a crash
+  mid-fold never double counts, and a second pass folds only what is new.
+- **The attribution window is carried data, never computed** — `72h` is
+  validated, rendered, and copied into the baseline snapshot; causal
+  attribution stays human.
+- **The baseline freeze** (Studio > Funnel, or `:freeze_funnel_baseline` on the
+  bus) sums the folded cells over a span of **≥ 28 days** (shorter spans are
+  refused) into one current snapshot per `(tenant, agent)` — the number
+  the follow-up A/B and the harvest promotion gate compare against.
+- **Malformed declarations never crash the tick**: the fold skips them, the
+  doctor names the defect, the Studio shows nothing until it is fixed.
+- Vocabulary note: in the gem this is the **outcome funnel** — the stage names
+  are the forge's, and a bare install (no `funnel:` on any agent) shows no
+  funnel and no stage names at all.
+
+## Follow-ups — the seller who comes back
+
+The agent can book a follow-up with a customer at a future time — "te chamo
+amanhã se o PIX não cair" said in-conversation and meant. The engine fires the
+synthetic turn on its own tick, with consent and without spam. Everything is
+pack data on the profile:
+
+```ruby
+agent = Insika.agent("store-support") do
+  instructions "…"
+  followup arm: "schedule",
+           policy: { quiet_hours: { timezone: "America/Sao_Paulo",
+                                    start: "21:30", end: "09:00" },
+                     max_frequency: "2/24h",       # N outbound per window, per customer
+                     cancel_keywords: ["não quero mais contato"],
+                     silence_after_sends: 3 }      # N fires without a reply -> :unavailable
+end
+```
+
+The pieces:
+
+- **`schedule(at:, reason:)`** — a built-in tool the agent calls when the
+  customer agrees to be contacted again (a product, a cart, a pending payment).
+  The call itself IS the consent record — recorded without ever lifting
+  `:unavailable` or resetting the silence counter (ONLY a customer message
+  reopens, so a re-booking inside a follow-up turn cannot clear the silence
+  protection). `cancel_followup(id:)` is the sibling. A customer who opted out
+  can never be rescheduled.
+- **Contact state per customer** — `granted | revoked | unavailable` in a
+  durable cell per `(tenant, customer)`. Only `granted` may be messaged;
+  `revoked` is immediate and permanent until the customer speaks again;
+  `unavailable` means silence ≠ refusal — the engine stops firing after
+  `silence_after_sends` unanswered sends, and ANY customer message reopens.
+  The policy's `cancel_keywords` are matched on every inbound message: a
+  match revokes the contact and cancels its pending follow-ups in one
+  transaction.
+- **Firing is the tick's third duty** — the engine claims the due records
+  (one per claim window, at-most-once across workers), applies the policy in
+  force AT FIRE TIME (contact state, quiet hours, dedup per
+  `(customer, reason)`, frequency ceiling) and either enqueues the synthetic
+  turn or marks the record `blocked` with the failing rule — auditable, never
+  silent. Blocking happens at fire time, never at schedule time: the schedule
+  is a promise made in-conversation, and only the policy in force then may
+  revoke it.
+- **The synthetic turn** — a first-class inbound turn stamped
+  `origin: "scheduled"` (a refinement read can never mistake the engine's
+  kick for the customer repeating themselves), delivered through the full
+  pipeline on the channel the conversation came in on. It skips the edge's
+  ENTRY rate/token checks like a resume does — a follow-up she agreed to must
+  not receive the rate-limit reply; its usage still lands on the ledger.
+- **The Follow-ups page** (Studio) — per agent: the pending/fired/cancelled/
+  blocked records (blocked rows carry the reason), the read-only policy
+  summary and the A/B card: per arm, `sent` vs `conversions` (against the
+  frozen baseline) vs `opt-outs`. The only mutations — cancel a pending
+  record, force-revoke a contact — go through bus commands.
+- **LGPD** — the records and cells die with the customer (`forget_customer`),
+  the tenant (`delete_tenant_data`) and age out under the same
+  `retention_days` sweep as the rest of the footprint.
+
+Absent `followup:` = the feature is off for that agent — no tools wired, no
+records, byte-identical turns. The A/B against an existing cron is an
+operator experiment: the engine only keeps the records and the read card (the
+cron arm writes through the same store class with its own `arm` label).
+
+## See also
+
+- [Evals](EVALS.md) — the cases that grade an agent before traffic does.
+- [Refinement](REFINEMENT.md) — reading an agent's own traffic back as a report.

data/docs/PLUGINS.md

@@ -1,7 +1,7 @@
 ---
 title: Plugins
-parent: Build an agent
-nav_order: 7
+parent: Integrate
+nav_order: 5
 permalink: /plugins/
 ---
 
@@ -131,16 +131,34 @@ keyword is itself an error rather than being silently ignored.
 
 ### Discovery and enabling
 
+The loader runs **at boot, in every composition root** — the server wirings and
+a DSL-run agent alike — single-threaded, before the first request is accepted.
+A plugin therefore either exists for the whole life of the process or not at
+all; there is no half-loaded state a turn can observe.
+
 Plugins come from three kinds of root, and they differ in **who has to say yes**:
 
 | Root | How it is found | Enabled by default |
 |---|---|---|
 | **Gem** | the gem calls `Insika::Plugin.announce(__dir__)` when its `lib/` loads | **yes** — installing it is the consent |
-| **Workspace** | a directory in the deployment's plugin roots | no — must be listed in `enabled:` |
-| **Bundled** | `plugins/` in this repo | no — must be listed in `enabled:` |
+| **Workspace** | the directory named by `INSIKA_PLUGIN_DIR` | no — list the id in `INSIKA_PLUGINS` |
+| **Bundled** | `plugins/` in this repo | no — list the id in `INSIKA_PLUGINS` |
+
+```sh
+INSIKA_PLUGIN_DIR=/srv/insika/plugins   # workspace root to scan
+INSIKA_PLUGINS=weather,acme             # ids to enable from workspace/bundled roots
+INSIKA_PLUGINS_DISABLED=insika-code     # ids that never load, no matter what
+```
 
-`disabled:` is an absolute veto: an id listed there never loads, even if it is
-also in `enabled:` (deny wins, the same rule as every allowlist in the engine).
+`INSIKA_PLUGINS_DISABLED` is an absolute veto: an id listed there never loads,
+even if it is enabled or shipped by an installed gem (deny wins, the same rule
+as every allowlist in the engine).
+
+When two roots ship the same `id`, precedence is workspace → gems → bundled:
+the first root wins, so an operator's local copy always overrides an installed
+one. Skills and prompts a plugin ships join the catalogs at the **lowest**
+precedence for the same reason — a workspace or Studio-authored skill beats a
+plugin's same-named one.
 
 A gem announces itself explicitly — Insika never scans the load path or your
 installed gems:
@@ -173,6 +191,33 @@ config_schema:
 The manifest is committed; the secret is not. This mirrors how data tools handle
 `{{secret.*}}`.
 
+## Why it is built this way
+
+Five decisions carry the whole design; knowing them explains every behavior
+above.
+
+1. **Data before code.** Most agent runtimes make code the unit of extension
+   and a restart the price of every integration. Insika inverts that: tier 1
+   (data tools, MCP imports, skills) covers most integrations hot, with no
+   deploy, and tier 2 exists only for what genuinely needs to run in-process.
+   A smaller code-plugin surface is a feature — less to audit, less to break.
+2. **Manifest before code.** Discovery never executes anything: the manifest is
+   read, validated, and gated first, and only then is the entry `require`d.
+   You can inventory, enable, and veto plugins without running them.
+3. **Contracts are the public API.** Anything addressable by name — tools,
+   workflows, capabilities, channels — must be declared in `contracts`, and an
+   undeclared registration is ignored with a warning. A plugin cannot quietly
+   widen its surface between versions, and a channel cannot mount a route
+   nobody asked for.
+4. **Announce, never scan.** A gem opts in with one explicit
+   `Insika::Plugin.announce` call; Insika never walks the load path or your
+   installed gems looking for candidates. What loads is exactly what was
+   announced or configured — auditable from the boot log alone.
+5. **One bad plugin never takes the deployment down.** Registration is staged
+   and committed atomically; a raise inside `register(api)` rolls back
+   everything that plugin staged and boot continues. Enablement is explicit,
+   and deny wins.
+
 ## Publishing a plugin
 
 - **Name it `insika-plugin-<thing>`.** The convention *is* the registry for now:

data/docs/POLICY.md

@@ -0,0 +1,216 @@
+---
+title: Limits and policy
+parent: Core concepts
+nav_order: 2
+permalink: /policy/
+---
+
+# Limits and policy
+
+What an agent may do is layered. Each layer is independent, opt-in where it
+matters, and editable hot — the same profile keys covered in [Agents](AGENTS.md),
+grouped here because they answer one question: what is this agent allowed to do,
+and what stops it when it tries to do more.
+
+What an agent may do is layered. Each layer is independent, opt-in where it
+matters, and editable hot.
+
+## Layer 1: Tools (what it can call)
+
+`tools_allow` / `tools_deny` / `tools_allow_groups` decide which tools enter the
+turn's tool-loop, enforced by the tool-allowlist policy. See [Tools](TOOLS.md)
+for how tools are defined and registered, and [`examples/data-tool/`](https://github.com/guizaols/insika/tree/main/examples/data-tool/).
+
+## Layer 2: Policies and approvals
+
+Policies are named entries evaluated before the turn runs. Builtins cover
+tool-, skill-, and workflow-allowlisting, plus **`ApprovalRequired`** — which
+does not allow or deny but *tags* a tool as needing human approval. Set
+`approvals_required: [tool names]`; the gate then fires when the model tries to
+call that tool, suspending the turn until an operator approves it in the Studio.
+See [Security](SECURITY.md#human-approval).
+
+## Layer 3: Guardrails (content safety)
+
+`guardrails` configures input/output content safety per agent — **opt-in**, so an
+agent that says nothing gets a conservative default (deterministic detectors on,
+LLM moderator off). See [Security](SECURITY.md#guardrails) and
+[`examples/guardrails/`](https://github.com/guizaols/insika/tree/main/examples/guardrails/).
+
+## Layer 4: Edge limits (flood and spend control)
+
+Two independent, opt-in ceilings, enforced *before* the model is ever called —
+opt-in everywhere except on a public channel, where `chat_rate_limit` is
+[required](CHANNELS.md#a-rate-limit-is-required-not-suggested) and the
+[web widget](CHANNELS.md#the-web-widget) refuses to serve without one:
+
+- **`chat_rate_limit`** — turn attempts per session per `chat_rate_window`.
+- **`agent_token_ceiling`** — total tokens per agent per `agent_token_window`.
+
+On breach the turn halts gracefully with a configurable `limit_response` and
+**zero LLM calls**. Windows are set at the platform level; the ceilings can be set
+per agent (blank inherits the platform value, `0` explicitly disables it).
+
+> ⚠️ The token window default is **86400 (daily)**. To express "500k tokens per
+> **hour**", set `agent_token_window = 3600` explicitly. A per-agent key that is
+> *present but nil* reads as OFF for that agent — leave the key **absent** to
+> inherit. See [Security](SECURITY.md#edge-limits).
+
+### Calendar budgets — the daily/monthly cost wall
+
+A third, opt-in ceiling for the *billing* shape the windows above cannot express:
+a spend cap over a CALENDAR day or month, per `(tenant, agent)` when
+multi-tenant. Data on the profile (DSL `budget` or the pack's `budget` key):
+
+```ruby
+budget daily: 100_000, monthly: 2_000_000, soft: false   # or soft: true
+```
+
+- Tokens count the **billed** spend — `input + output + cached + cache_creation`
+  (the cached prefix is the bulk of the bill, not an afterthought).
+- **Hard** (the default, `soft` absent/false): a turn that arrives with the
+  window's spend already at/over the cap **fails** with the typed
+  `Insika::BudgetExceeded` — the envelope reads `budget_exceeded` +
+  `retry_after` (seconds until the window rolls). It is NOT a customer reply; it
+  is an operator signal.
+- **Soft** (`soft: true`): the same turn RUNS — crossing the cap emits one
+  `budget_warning` event per window and injects a note into the context (the
+  model sees it, the transcript does not).
+- Either way, crossing `alert_at` (default `0.8` of the cap) fires the same
+  warning **before** the wall, once per window.
+
+> ⚠️ Unlike the ceilings above, the cap that counts is per **calendar** window —
+> a `daily` budget rolls at UTC midnight, a `monthly` one on the 1st, whatever
+> the sun. `agent_token_window` is a fixed seconds window and cannot express
+> "the day resets at midnight".
+
+### Reliability — retries, fallback, circuit breaker
+
+The provider interaction is a single attempt by default (RubyLLM's own 2
+transport retries aside). For a store that cannot have a dead model take the
+chat down, the reliability policy is DATA on the profile:
+
+```ruby
+reliability retries: 2, backoff: "exponential",
+            fallback: ["openai/gpt-4o-mini"],
+            circuit_breaker: { after: 10, within: 60, cooldown: 300 }
+```
+
+- **Retries** — transient failures (`:retryable` / `:rate_limited_*` per the
+  error classification) retry with exponential backoff, up to `retries`.
+  A `:fatal` (auth, billing, bad request) is NEVER retried or rotated. Each
+  attempt runs on a fresh chat — the customer-visible answer comes only from
+  the attempt that returns.
+- **Fallback** — after a node's retries, the turn ROTATES to the next model in
+  the chain: the profile's `fallback` refs first, then the platform
+  `fallback_models`. The turn's usage is attributed to the model that actually
+  spoke (`model_source: "fallback"`).
+- **Circuit breaker** — per `(tenant, provider/model)`: `after` failures within
+  `within` seconds open the circuit; while open, the turn fail-fasts with the
+  typed `circuit_open` + `retry_after` (remaining cooldown) and the provider is
+  never touched. After `cooldown` a half-open trial closes the circuit on
+  success or reopens it on failure.
+- **`timeout`** — per-attempt ceiling (default 30s), counted as a retryable
+  failure.
+
+Absent `reliability` = the plain single attempt, byte-for-byte today's
+behavior.
+
+### Intent routing — classify before you answer
+
+For a store that must tell "shopping" from "order" from "human" up front,
+routing is data on the profile:
+
+```ruby
+routes "shopping" => "the customer wants to browse products",
+       "order"    => { "description" => "asks about an existing order",
+                       "delegate" => "order-agent" },
+       "human"    => { "description" => "the customer asks for a person",
+                       "stuck" => true, "message" => "A person will help you." },
+       "default"  => "shopping",
+       "model"    => "deepseek-v4-flash"   # the cheap classifier (absent = the agent's own)
+```
+
+- **Classification** — when `routes:` is present, the message is classified into
+  one route with the configured model BEFORE the agent chat is assembled, from
+  a prompt auto-generated out of the descriptions (no per-route prompt file).
+  The route rides the turn: `state.route`, the `:route_classified` event, and
+  the terminal event additively.
+- **Deterministic default** — the model's answer must be a route name; prose,
+  an unknown name, or an empty answer falls back to `default`, never invents.
+  A classifier call that FAILS leaves the turn unrouted (routing is additive —
+  it must not break the turn).
+- **Cost** — the classification is an extra provider call, counted in the
+  turn's usage (the trace, the token ceiling and the budget all see it).
+- **Actions** — a route value may be a description string, or a Hash:
+  `delegate: "<agent-id>"` hands the turn to that existing agent and its
+  answer becomes the parent's; `stuck: true` ends the turn with the [stuck
+  outcome](AGENTS.md#the-stuck-signal--i-cannot-proceed) and the route's `message`
+  (or description) as the lead-in — the consumer interprets it. A route with
+  neither is just a label. A delegation counts against the same delegation
+  depth cap as a subagent (`INSIKA_SUBAGENT_DEPTH_CAP`, default 5), so a pair
+  of agents routing to each other stops instead of looping.
+
+Absent `routes` = no classification, no extra call, byte-identical turn.
+
+### Operator alerts — the webhook
+
+Three operational events — `budget_warning`, `breaker_open`, `delivery_failed` —
+can be answered per agent with a webhook:
+
+```ruby
+alerts webhook: "https://ops.example.com/insika-alerts"
+```
+
+When present, each such event is POSTed to the URL as JSON (the event's
+type/data/meta, plus the agent). Delivery rides the same outbox + claim +
+bounded-retry pipeline as channel answers — at-most-once, crashed deliveries
+recovered at boot. The engine transports the event and does not interpret it: a
+Slack/CRM adapter is the consumer's. Absent `alerts` = nothing is sent.
+
+Separately, with `INSIKA_TURN_TIMING`, the provider's **live TTFB** is carried in
+the streaming envelope: the first content chunk emits an `insika.ttft` frame
+(`ttft_ms`) on `/v1/responses`, alongside the per-turn `timing` breakdown on the
+final `response.completed`. Additive and opt-in — absent by default.
+
+## Layer 5: Reasoning (thinking)
+
+Controls the model's thinking budget, resolved by precedence
+**Chat > Agent > Model > Global** (first non-blank wins):
+
+| Scope | Where |
+|-------|-------|
+| Chat | session var `__llm__.thinking` |
+| Agent | `profile.params["thinking"]` |
+| Model | platform `model_params[<ref>].thinking` |
+| Global | platform `thinking` |
+
+Values: `off | on | low | medium | high`. `off`/`on` toggle thinking; the effort
+levels map to the provider's thinking-effort parameter. This is a control
+primitive, not a latency lever — turning reasoning off does not necessarily speed
+up a turn, because most of a turn's latency is the provider itself, not thinking.
+
+Whether the reasoning ever reaches the **customer** is a separate switch, off by
+default:
+
+```ruby
+edge_stream thinking: true, intermediate: false
+```
+
+`thinking` is the provider's reasoning; `intermediate` is the model narrating its
+own tool loop ("let me look that up"). Both are always on the event stream for the
+Studio and the trace — this decides only whether `/v1/responses` translates them,
+and each opted-in channel gets its own frame type, never the answer's. See
+[Architecture](ARCHITECTURE.md#what-crosses-the-edge).
+
+> ⚠️ Turn it on knowing your consumer. One that concatenates every text delta into
+> a single message — a WhatsApp adapter — will only be affected once it learns to
+> read the new frames, and when it does, the deliberation is what the customer
+> reads. That is the operator's call, which is why it is neither a default nor a
+> global.
+
+## See also
+
+- [Agents](AGENTS.md) — the profile these keys live on.
+- [Tools](TOOLS.md) — how a tool gets defined, registered and allowed.
+- [Security](SECURITY.md) — the deployment-side counterpart: sandbox, egress, secrets.

data/docs/REFINEMENT.md

@@ -1,7 +1,7 @@
 ---
 title: Refinement
-parent: Operate & prove it
-nav_order: 5
+parent: Improve
+nav_order: 2
 permalink: /refinement/
 ---
 
@@ -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
@@ -51,11 +51,14 @@ Or from **Studio → Refinement**: pick the agent, press Run, and the same repor
 renders with each session id linking to its transcript. Every finding is a claim
 you can go and check.
 
-There is no scheduler in the engine, by design. A run is one command
-(`run_refinement`), and the CLI and the button are the two ways to fire it. If you
-want it on a timer, point your own cron at the authenticated route the button uses
-— that keeps the engine free of a background ticker and of the single-node
-assumption one would bring.
+A run is one command (`run_refinement`), and the CLI and the button are the
+two ways to fire it. There is still no built-in timer *for the report itself*,
+but there is one for the *agent*: fine-grained recurring turns live in
+[Schedules](SCHEDULING.md), and a refinement run scheduled like any other turn
+is just a message the agent's schedule sends it. If you prefer to stay outside
+the engine, pointing your own cron at the authenticated route the button uses
+works just the same — both paths are supported, the engine's trigger is the
+built-in one.
 
 ```
 insika refine ─┐
@@ -173,7 +176,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
@@ -466,8 +469,10 @@ prompt edits have real leverage, and it is also where they do damage.
 
 ## What this is not
 
-It has no scheduler: a run happens because a person or a cron asked for one, never
-because a timer inside the engine went off. A proposal is written when you ask for
+A run happens because a person or a cron asked for one — the refinement
+pipeline has no timer of its own, and if you want one, a schedule
+([Schedules](SCHEDULING.md)) makes a run a turn any agent can be scheduled to
+send. A proposal is written when you ask for
 one, and — unless you turned on [`auto_apply`](#applying-without-a-human), which is
 off until you do and bounded when you do — applied when you approve it. And it cannot
 touch your guardrails, tools, policies, model pins or limits, and not because a prompt

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 clean-install proof
+
+For the 1.0 release the proof above is scripted and its **installed-bytes**
+half is asserted by the domain-boundary suite 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
+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: 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