> For the complete documentation index, see [llms.txt](https://docs.kyvvu.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kyvvu.com/reference/changelog.md).

# Changelog

**Version history for the Kyvvu platform.**

For full release notes and older versions, see [GitHub Releases](https://github.com/Kyvvu/platform/releases).

***

## v0.15.0 — Claude hardening & dashboard scale (2026-06-19)

Engine 0.7.0 · SDK 0.15.0 · kyvvu-claude 0.2.0 · API 0.12.0 · Web 0.9.0.

### New: dashboard tasks-list endpoint & server-paginated trace view (#240)

* `GET /api/v1/logs/tasks` — a distinct-task summary endpoint. A SQL group-by on `task_id` returns one row per task (`task_id`, `agent_id`, `agent_name`, `environment`, `step_count`, `first_ts`, `last_ts`, `status`) with offset-based pagination (`skip` / `limit`, default 20, max 100) and a total count of distinct tasks. Status is derived in SQL via conditional aggregation over `task.end` / `task.error` steps (error > completed > running), portable across PostgreSQL and SQLite. Ownership/auth mirror `GET /logs`; the `/tasks` route is registered before `/{log_id}`. Adds `TaskSummary` / `TaskListResponse` schemas.
* Dashboard trace view now lists tasks server-side (20/page) and lazy-loads a task's steps via `GET /logs?task_id` only when a row is expanded. Replaces the previous flat 1000-log fetch + client-side grouping, which never showed more than \~2 tasks for 500+-step agents.

### Changed: shared template engine & path-containment (#239)

* The `BehaviorTemplate` loader / matcher / interpolation machinery moved into `kyvvu_engine.templates` (canonical, integration-agnostic). The name registry (`from_builtin` / `_BUILTIN_TEMPLATES`) was removed — integrations load their template by path. Per-integration `*.template.yaml` files stay with their integration.
* kyvvu-claude mapper is now template-driven (`claude-code.template.yaml`, all 29 named tools + MCP catch-all) instead of a hardcoded if-tool ladder. A Claude-side pre-pass derives a Bash write target (`>`, `>>`, `tee`, `cp`, `mv`, `dd of=`, `sed -i`) → `target.host`, and detects shell secret reads (`cat`/`cp`/… of `.env`/`.pem`/…) → `data.classification:secret`, so the scope-containment and tainted-path policies arm for Bash. Shell parsing stays in kyvvu-claude; the engine never learns shell syntax.
* New `path_within_root` rule (allowlist containment): returns true when the target resolves at/under `EvalContext.project_root`, false when it escapes. Scoped to writes (POST/PATCH/DELETE/exec), fails open when `project_root` is unset. The Claude-code-safety "No write outside project" policy now uses it instead of a hardcoded denylist. Paths are normalized lexically (`..` collapsed; symlinks not resolved — documented limit).
* kyvvu-claude `PreToolUse` hook populates `EvalContext.project_root` from the session cwd.

### Changed: claude-code-safety destructive-command policies (#238)

* The single mis-scoped "No rm -rf root" policy (which critical-blocked scoped cleanups like `rm -rf /tmp/x` while `rm -fr /`, `rm -r -f /`, and parent-traversal chains slipped through) was replaced with four per-target, force-agnostic, anchored policies: root, home, parent traversal, and system directories (`/usr`, `/var` intentionally excluded). Recursive detection tolerates flag order/splits.
* All six `exec.command` destructive policies (rm + git) gained a command-position prefix (leading separator `;`/`&&`/`||`/`|` or exec-wrapper `sudo`/`doas`/`env`/`xargs`/`time`/`nice`) so prefixed and chained dangerous commands (`sudo rm -rf /`, `cd x && rm -rf /`, `build; git reset --hard`) are caught while `echo rm -rf /` still passes (the engine matches `field_matches_regex` start-anchored).
* New stopgap shell policies: no shell write to sensitive paths (`redirect`/`tee`/`cp`/`mv`/`dd`/`install` into `/etc` `/usr` `/var` `~/.ssh` `~/.aws` …) and no shell read of secret files (`cat`/`less`/`head`/`base64`/… of `.env`/`.pem`/`.key`/`credentials`/…), mirroring the destructive-delete pattern directly on `exec.command`.
* Match/no-match + known-gap fixtures (`tests/rm_policies.py`, `tests/shell_policies.py`) load the live manifest regexes and exercise them with the engine's `re.match` / `DOTALL` semantics.

### Changed: kyvvu-claude sub-agent partial-order stamping & session concurrency (#237)

* Transcript cursor is now per-path (`transcript_cursors: dict[path -> lines_read]`) instead of a single int, so the main transcript and each sub-agent transcript (`…/subagents/agent-{id}.jsonl`) advance independently — fixes skipped / double-counted `step.model` records. Legacy scalar cursors migrate on load.
* New `mutate_session()` / `transact_session()` context manager holds the file lock across the full read-modify-write, so concurrent hook processes no longer lose a step/history entry. The post-threshold flush trims by count (not `history.clear()`) so concurrent appends survive.
* New `subagent.py`: every step is stamped with `properties["kyvvu.subagent"] = {id, depth, spawn_step}` (flat storage). Tag derives from `transcript_path` (`main` for the parent, `agent-{id}` for a sub-agent); within-sub-agent order reconstructs by `(tag, timestamp)`; the parent→child `spawn_step` back-reference comes from a new `SubagentStart` lifecycle hook. Cross-sibling order is deliberately dropped. Tags are storage-only and never scope enforcement: replay stays whole-task, so a secret read in one sub-agent still taints exec anywhere in the task.
* kyvvu-claude CLI `init` / `status` now surface the configurable incident sink (`KV_INCIDENT_LOCATION` / `KV_INCIDENT_FORMAT`, #225).

***

## v0.14.x — Standardized logging, integrations & hardening (June 2026)

Sprint 1-3. Engine 0.6.x, SDK 0.14.x, kyvvu-claude 0.1.x.

### New: kyvvu-claude (Claude Code integration)

* Hook-based Claude Code integration — policy enforcement via PreToolUse / PostToolUse / SessionStart / SessionEnd hooks.
* Claude Code tools mapped to Kyvvu behaviors (Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, Agent, MCP tools, …).
* LLM call capture from the session transcript (model name, token usage, proposed tools).
* Secret file classification: `.env`, `.pem`, `.key`, etc. tagged with `data.classification:secret` for tainted-path policies.
* Incident reporting to the API on policy blocks.
* Hooks **deny** the offending tool call but do not stop the session; a tainted path is permanent for the session.
* Published to PyPI as `kyvvu-claude` (Apache 2.0).

### New: Claude Code Safety manifest

* 9 policies (all severity `critical`): credential-exfiltration guard (no exec / no network after secret read), destructive-command protection (force push, `rm -rf /`, `git reset --hard`), scope containment (no write outside project), runaway prevention, and PII scanning in commands.
* Tainted-path policies key on `data.classification:secret`.

### New: Standardized logging & exporters (#212)

* Pluggable exporters: stdout, file (JSONL), Kyvvu HTTP API, OTLP, callback.
* Policy evaluation results embedded in the audit trail — `meta["kyvvu.eval"]` on every step (action, risk\_score, per-policy outcomes).
* OTLP shipped as a default engine dependency.

### New: LangGraph & CrewAI integrations (#213, #214, #218)

* `KyvvuLangGraphHandler` — node metadata (`langgraph.node_name`), GraphInterrupt mapped to `step.gate`, tool extraction from graph nodes. LangGraph Research example agent (port 8105).
* `KyvvuCrewAIListener` — event-bus integration, parallel tool-call pairing via `event_id` / `started_event_id`, `step.message` framing, and a circuit breaker (`listener.is_blocked`) for post-kickoff block detection. CrewAI Research example agent (port 8106).

### Changed: canonical `log_location` / `log_format` (#222)

* `log_location` (where) and `log_format` (how) are now the single canonical logging settings across engine, SDK, and kyvvu-claude. Resolvers: `effective_log_location` / `effective_log_format`.
* Legacy `log_endpoint` / `log_exporters` settings removed entirely.

### Changed: configurable incident sink (#225)

* `incident_location` / `incident_format` configure where incidents are sent and in what format. Both default to the trace sink (the incident location is derived from the log location; the Kyvvu HTTP path is `…/api/v1/incidents`).

### Changed: blocked steps in the audit trail (#219)

* Blocked steps are now always recorded with `output.status=blocked` (previously dropped). `task.error` + `end_task` fire on block so the audit trail is always flushed. `KyvvuBlockedError` propagates correctly across all integrations (decorator, LangChain, LangGraph, CrewAI, kyvvu-claude).

### New: manifest provenance in the audit trail (#217)

* Policies materialised from a manifest assignment now carry their origin. The policy-fetch response includes `manifest_id`, `manifest_name`, `manifest_repo`, `manifest_path`, `manifest_sha`, `manifest_assigned_at`, and `manifest_assigned_by` (null for hand-authored policies).
* Engine: `EvalContext.manifests` (list of `ManifestRef`), optional `manifest_id` / `manifest_name` on each loaded policy, `manifest_id` on each per-policy result. The in-effect manifest set is attached to `meta["kyvvu.manifests"]` on the `task.start` atom, and per-policy `manifest_id` appears in `meta["kyvvu.eval"]["policies"][i]`.
* No database migration: the `Assignment` model already stored these fields.
* Provenance is now also surfaced on the single-policy `GET` and standard policy-list responses (round-tripped via `PolicyResponse`), not just the policy-fetch endpoint (#217 follow-up).

### Hardening & code quality (#233, #164)

* SDK schemas ported to `(str, Enum)` enums and Pydantic v2 payloads with a byte-stable serializer.
* Regex parity: `field_matches_regex` uses `re.DOTALL` on both the pre-compiled (PolicyStore) and fallback paths, so compiled and uncompiled evaluation behave identically.
* API: full strict-mypy compliance across all modules (type annotations only, no runtime changes).

### Infrastructure

* `deploy-main.yml`: inline PyPI publish (no cross-workflow trigger dependency) and build-before-down (downtime \~2 min → \~5 s).
* kyvvu-claude test job added to `merge-dev.yml` and `deploy-main.yml`.
* `KV_LOG_LEVEL` passed to the API container in production.
* Nginx routes for the LangGraph (8105) and CrewAI (8106) demo agents.
* `bump-version.sh` includes kyvvu-claude.

***

## v0.13.0 — Manifests (2026-05-14)

### Platform

* **Manifests**: YAML policy files in GitHub repos replace server-side policy templates
* **Assignments**: Assign manifests to agents with per-agent policy materialization and risk filtering
* **Repos**: Connect GitHub repos (public or private) with encrypted token storage
* **Dashboard restyle**: Sidebar navigation (6 tabs), Settings page with sub-tabs (API Keys, Platform Events, Reports, Organization, Members)
* **Dashboard overview**: 4 stat cards, recent incidents table, recent activity feed
* **Agents page**: simplified 5-column table, last policy fetch, expandable row with assigned manifests, view policies
* **Repo delete protection**: 409 if active assignments exist
* **Policy unique constraint**: includes agent\_id to allow same manifest on multiple agents
* **Hash chain validation**: re-enabled in dashboard via `verify_either_auth`

### CLI

* `kyvvu list-manifests` — list available manifests from connected repos
* `kyvvu assign-manifest` — assign a manifest to an agent
* `kyvvu list-assignments` — list manifest assignments
* `kyvvu init` simplified — pure scaffolding, no auth required, no policy application
* `kyvvu list-policies` — new Source column showing manifest origin

### Removed

* Policy template endpoints (`/api/v1/policy-templates/*`)
* Templates and Policies dashboard tabs
* Default seeded policies (replaced by manifest assignment)
* `TemplateLoader`, template YAML files, template router, 97 template tests

***

## v0.11.0 (2026-04-29)

### Engine

* 26 built-in rule functions across six categories (field, path, count, classification, content, flow).
* Compound rules: `all_of`, `any_of`, `not` with unlimited nesting.
* `KyvvuRunner` with TTL-based policy fetch, incident webhooks, and log flush.
* `kyvvu serve` — local HTTP server for non-Python agents.
* Performance: p99 < 300 us with 100 policies and 50-step history.
* `explain()` method for human-readable evaluation traces.
* `sweep_stale_tasks()` for abandoned task cleanup.
* Payload redaction (`KV_LOG_PAYLOADS=metadata_only`).

### SDK

* `@kv.step` decorator with sync and async support.
* `KyvvuLangChainHandler` for LangChain and LangGraph.
* YAML behaviour templates with first-match-wins evaluation and deep-merge.
* `FrameworkAdapter` base class for custom integrations.
* Programmatic task API: `start_task()`, `end_task()`, `error_task()`.
* `ContextVar`-based concurrent task tracking.
* CLI: `kyvvu register`, `login`, `logout`, `whoami`, `init`, `serve`, `list-agents`, `list-policies`.

### API

* Policy templates with YAML definitions and apply/remove API.
* OWASP Top 10 for Agentic Applications default template (8 policies).
* Organization-scoped data isolation.
* Incident lifecycle: open / active / resolved / ignored.
* Hash chain for tamper-evident log ingestion.
* Registration cap with waitlisting.
* `declared_tools` field on agent registration.
* Hosted engine evaluation endpoint (`POST /api/v1/engine/evaluate`).
* Audit report generation (PDF, XML).

### Dashboard

* Policy management with dynamic forms from rule schemas.
* Template application UI.
* Incident triage workflow.
* Log viewer with hash chain validation.
* Organization member management.

***

## Next steps

* [Licensing](/reference/licensing.md) — license structure
* [Installation](/getting-started/installation.md) — get started


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kyvvu.com/reference/changelog.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.