codna 0.1.0__py3-none-any.whl

codna/agent-core/vendor/cline/sdk/ARCHITECTURE.md

@@ -0,0 +1,525 @@
+# Cline SDK Architecture
+
+This document is the architecture source of truth for the Cline SDK repository. It describes how the system is organized, how components interact, and the design principles that guide development decisions.
+
+**Who should read this?**
+- SDK contributors working across multiple packages
+- Developers building integrations or host applications using `@cline/core`
+- Plugin authors understanding the runtime and extension systems
+
+**What this covers:**
+- Package boundaries and responsibilities
+- Dependency direction and layering rules
+- Runtime flows (local, hub-backed, remote-config managed)
+- Design seams (repeated patterns instead of one-off integrations)
+- Architectural constraints and why they exist
+
+**What this is NOT:**
+- An onboarding guide for new contributors (see README.md and CONTRIBUTING.md)
+- A detailed API reference (see package READMEs and inline JSDoc)
+- A user guide (see the main documentation)
+
+## Layered Model
+
+The workspace is organized as a layered runtime stack.
+
+```mermaid
+flowchart LR
+  shared["@cline/shared"]
+  llms["@cline/llms"]
+  agents["@cline/agents"]
+  core["@cline/core"]
+  apps["Host Apps"]
+
+  llms --> shared
+  agents --> llms
+  agents --> shared
+  core --> agents
+  core --> llms
+  core --> shared
+  apps --> core
+```
+
+## Package Responsibilities
+
+### `@cline/shared`
+
+Owns reusable low-level contracts and infrastructure:
+
+- shared types and schemas
+- path resolution
+- hook contracts/engine
+- extension registry contracts
+- prompt and parsing helpers
+- storage path helpers
+- remote-config schemas, managed instruction materialization, telemetry normalization, and blob upload primitives
+
+Design rule:
+
+- `shared` should not depend on higher-level runtime packages.
+
+### `@cline/llms`
+
+Owns model/provider runtime concerns:
+
+- provider settings/config resolution
+- model catalogs and manifests
+- shared gateway-style provider contracts
+- handler creation via an internal gateway registry
+- AI SDK-backed provider execution code
+
+Design rule:
+
+- provider-specific behavior should be isolated here, not spread across `core` or apps.
+
+### `@cline/agents`
+
+Owns the stateless runtime loop:
+
+- agent iteration loop
+- tool orchestration
+- runtime event emission
+- hook/extension execution
+- turn preparation before provider calls
+- in-memory team/runtime primitives
+
+Design rule:
+
+- `agents` should not own persistent storage or host lifecycle concerns.
+
+### `@cline/core`
+
+Owns stateful orchestration:
+
+- runtime composition
+- session lifecycle
+- storage and persistence
+- config watching/loading and watcher projections
+- settings listing and mutation orchestration
+- default host tool assembly
+- plugin discovery/loading
+- default context compaction policy
+- telemetry integration
+- hub server and scheduled-runtime services under `src/hub/`
+- hub discovery, the detached hub daemon, and the `@cline/core/hub/daemon-entry` subpath
+- host-side hub client adapters (`NodeHubClient`, `HubSessionClient`, `HubUIClient`, `connectToHub`) exported from `@cline/core/hub`
+
+Design rules:
+
+- `core` is the app-facing orchestration layer over `agents`.
+- hub-related modules live under `packages/core/src/hub/`, grouped by service:
+  - `client/` contains host-facing hub clients and browser connection helpers
+  - `daemon/` contains detached daemon startup, entrypoint, and local runtime handler wiring
+  - `discovery/` contains endpoint defaults, discovery records, and workspace owner resolution
+  - `server/` contains WebSocket server startup, native/browser socket adapters, server transport, server helpers, and `handlers/` for hub command dispatch
+- settings mutations belong in core services and hub commands, not in host-specific file writes. Hosts should call the core settings facade or the `settings.*` hub command family and react to `settings.changed`.
+
+## Runtime Flows
+
+### Local In-Process Runtime
+
+1. Host constructs a `RuntimeHost` through `@cline/core`.
+2. `@cline/core` selects `LocalRuntimeHost` through `packages/core/src/runtime/host.ts`.
+3. Hosts normalize broad local config into `RuntimeSessionConfig` plus `localRuntime` overrides before calling `RuntimeHost.start(...)`.
+4. `@cline/core` prepares a local bootstrap artifact from `localRuntime`, then builds the runtime from it.
+5. `@cline/core` creates an `Agent` from `@cline/agents`.
+6. `@cline/agents` runs the loop using `@cline/llms` handlers.
+7. `@cline/core` persists state, artifacts, and metadata.
+
+Completion telemetry is anchored to the assistant's explicit completion
+declaration, not session shutdown. After each agent turn, the local
+runtime inspects `AgentResult.toolCalls` and emits `task.completed` the
+moment a successful `submit_and_exit` (the SDK analog of original
+Cline's `attempt_completion`) is observed. `shutdownSession(...)`
+retains a fallback emission for completed sessions that finished
+without an explicit completion-tool observation, so non-interactive
+runs not using the yolo preset still produce a `task.completed` signal.
+Each session emits at most one `task.completed`. See `DOC.md` for the
+event payload and `source` field.
+
+### Hub-Backed Runtime
+
+1. Host constructs a `RuntimeHost` through `@cline/core`.
+2. `@cline/core` selects `HubRuntimeHost` or `RemoteRuntimeHost` through `packages/core/src/runtime/host.ts`.
+3. When no compatible local hub is already discovered, `@cline/core` can spawn a detached hub daemon and reconnect through discovery.
+4. Hosts attach and detach from shared sessions without stopping the authority runtime, so another client can keep streaming or resume the same session later.
+5. The hub-hosted runtime executes the agent loop using `@cline/agents` and `@cline/llms`.
+6. `@cline/core` hub services broker sessions, events, approvals, schedules, and client-owned runtime capabilities such as session-local tool executors.
+7. Hub event forwarding preserves structured streaming lifecycle boundaries: text/reasoning deltas, final text/reasoning completion, tool start/finish, and agent done events are translated across the hub transport so host UIs can reliably close loading/streaming state.
+8. Hub client adapters exported from `@cline/core/hub` (`NodeHubClient`, `HubSessionClient`, `HubUIClient`, `connectToHub`) translate command/reply and event streams into host-facing APIs.
+9. Hub `session.get` records include both canonical root-session usage and explicit aggregate usage from the hub-owned `RuntimeHost`, so attached clients can intentionally render either root-only or root-plus-teammate costs without replaying event streams.
+
+Detached daemon startup retries transient `ETXTBSY` spawn failures before
+polling discovery. This covers package-manager updates that replace the CLI
+binary immediately before a command restarts the shared hub.
+
+Local hub discovery also carries the authentication contract for the shared
+daemon. On startup, the hub server generates a cryptographically random
+per-process auth token, stores it in the owner discovery record, and writes that
+record with owner-only file permissions. Local clients resolve the token from
+the discovery file at connection time rather than embedding it in endpoint URLs.
+The server validates the token with a constant-time comparison before accepting
+`/hub` WebSocket upgrades or `/shutdown` requests; WebSocket clients send it via
+the `Sec-WebSocket-Protocol` header and shutdown requests use an
+`Authorization: Bearer` header. Unauthenticated local processes can still probe
+public health/build metadata, but they cannot attach to sessions, issue
+commands, or stop the daemon.
+
+Local hub rediscovery is limited to managed shared-daemon endpoints obtained
+through discovery or `ensure*HubServer(...)` startup paths. Explicit endpoints,
+including loopback URLs such as `ws://127.0.0.1:<port>/hub`, are sticky exact
+targets: reconnects may retry the same socket URL, but command recovery and
+startup-deadlock recovery must not replace them with the workspace-discovered
+hub. This keeps custom local hubs and remote hubs from silently drifting to a
+different process.
+
+### Interactive CLI Startup
+
+1. `apps/cli` owns OpenTUI startup and must render the first frame without waiting for detached hub startup.
+2. Interactive sessions use `backendMode: "auto"` so an already-compatible hub can be reused immediately, while a missing hub is only prewarmed in the background and the TUI falls back to a local runtime for responsiveness.
+3. Hub-required flows such as `cline hub`, schedules, connectors, and `--zen` may still call the explicit ensure path because those commands require a live hub before proceeding.
+4. Resume hydration is deferred until after `renderOpenTui()` so loading previous messages cannot block initial TUI paint.
+5. Any future CLI/TUI startup work should follow the same rule: daemon startup, discovery polling, provider catalog refreshes, file indexing, and resume reads must be background or user-action gated unless a command explicitly requires their result before output.
+
+### Remote-Config Managed Runtime
+
+1. A host or core wrapper fetches a normalized `RemoteConfigBundle`.
+2. `@cline/shared/remote-config` caches the bundle when configured.
+3. Shared remote-config materializes managed rules/workflows/skills under workspace-local `.cline/<plugin>/`.
+4. Shared remote-config derives generic OpenTelemetry config and session blob upload metadata from the bundle.
+5. `@cline/core` exposes the app-facing integration wrapper that applies extensions, telemetry, and session metadata to `StartSessionInput`.
+6. `@cline/core` consumes the prepared local overrides during local bootstrap.
+
+This keeps reusable remote-config behavior in `shared` while the session-specific bridge remains in `core`.
+
+## Design Seams
+
+The codebase relies on a few repeated seams instead of one-off integration paths.
+
+### 1. Config Watchers
+
+Core uses file-based discovery and watchers for:
+
+- rules
+- workflows
+- skills
+- agents
+- hooks
+- plugins
+
+Design implication:
+
+- new instruction sources should usually materialize into files and reuse watcher-based loading instead of inventing parallel in-memory execution paths.
+- in `packages/core`, config-facing discovery, parsing, watching, and slash-command projection live under `src/extensions/config`
+
+### 2. Runtime Builder Inputs
+
+`DefaultRuntimeBuilder` composes a runtime from generic inputs:
+
+- tools
+- hooks
+- extensions
+- user instruction watcher
+- telemetry
+
+Design implication:
+
+- higher-level integrations should prefer feeding those seams rather than patching agent internals directly.
+- the local runtime bootstrap lives in `packages/core/src/services/local-runtime-bootstrap.ts` and feeds the builder rather than bypassing it
+
+### 3. Runtime Host Boundary
+
+Core exposes one shared execution boundary: `RuntimeHost`.
+
+Concrete implementations:
+
+- `LocalRuntimeHost` for in-process execution
+- `HubRuntimeHost` for shared local hub execution
+- `RemoteRuntimeHost` for explicit remote hub endpoints
+
+Design implication:
+
+- host selection happens in `packages/core/src/runtime/host.ts`
+- `ClineCore` delegates uniformly to `RuntimeHost` and does not branch on local vs hub behavior
+- transport-specific translation belongs inside concrete hosts, not in top-level orchestration
+- `RuntimeHost` inputs stay transport-safe, while `ClineCore.start(...)` is the app-facing facade that normalizes broad local config before delegation
+- `RuntimeSessionConfig` is transport-neutral across local, shared hub, and remote hub modes; host-local bootstrap concerns stay under `localRuntime`
+- client-local runtime behaviors that must survive hub mode, such as `defaultToolExecutors`, are attached at session start and proxied through hub capability requests instead of changing host selection
+- pending prompt list/update/delete are exposed through the grouped
+  `ClineCore.pendingPrompts` service. Usage summary lookup and active-session
+  model switching are also service-style capabilities exposed through
+  `ClineCore` when the concrete transport implements them. These service APIs
+  are intentionally outside the minimal `RuntimeHost` primitive vocabulary.
+- The usage service's `getAccumulatedUsage(sessionId)` method returns a summary
+  with two explicit buckets: `usage` for the root/lead agent and
+  `aggregateUsage` for root plus teammates/subagents. Local execution tracks
+  root usage and teammate usage as separate buckets, then derives aggregate
+  totals from those buckets while telemetry remains scoped to the primary
+  lead/root agent.
+
+### 4. Settings Mutation Boundary
+
+Core owns settings snapshots and mutations through `packages/core/src/settings`.
+The hub exposes the same path through `settings.list` and `settings.toggle`.
+
+Design implication:
+
+- hosts should not mutate skill, tool, MCP, provider, or other settings files directly
+- domain-specific persistence helpers, such as skill markdown frontmatter writes, stay internal to the owning settings provider/service
+- successful hub-backed mutations return an updated settings snapshot and publish `settings.changed` with the changed settings types
+- CLI settings surfaces may keep local snapshot rendering for startup responsiveness, but mutation flow must refresh the relevant watcher before reloading UI data
+
+### 5. Session Startup Bootstrap
+
+`ClineCore.create(...)` exposes a generic `prepare(input)` hook.
+
+Design implication:
+
+- higher-level packages can prepare workspace-scoped runtime state before a session starts
+- core stays unaware of enterprise-specific contracts
+- cleanup stays at the host boundary rather than inside the agent loop
+
+### 6. Logging
+
+Cross-package logging uses a small injected interface exported from `@cline/shared`:
+
+- **`BasicLogger`** — required `debug` and `log`; optional `error`. Hosts map these to their backend (Pino, VS Code `OutputChannel`, etc.). Many runtime options take `logger?: BasicLogger`; when omitted, components skip logging or use `noopBasicLogger` where a full object is required.
+- **`BasicLogMetadata`** — optional structured fields (`sessionId`, `runId`, `providerId`, `toolName`, `durationMs`, …) plus `severity` on `log` when a single method must represent both informational and warning-style messages (for example the CLI Pino bridge maps `severity: "warn"` to Pino `warn`).
+
+Naming clarity:
+
+- **`CliLoggerAdapter` (CLI)** — a **host bundle**: holds the raw `pino` logger (for file paths, rotation, and CLI-only concerns) and exposes `.core: BasicLogger` for anything that consumes the SDK contract. It is not an `ITelemetryAdapter`.
+- **`TelemetryLoggerSink` (`@cline/core`)** — an **`ITelemetryAdapter`** that mirrors telemetry events and metrics into a `BasicLogger`. It is a telemetry sink, not a host logging implementation.
+
+The agent and other call sites route former `info` / `warn` semantics through `log` (warnings include `severity: "warn"` in metadata). Errors prefer `error` when implemented; otherwise `log` with `severity: "error"` is used as a fallback.
+
+Design implication:
+
+- logging is injectable and transport-agnostic, allowing host environments (CLI, VS Code, browser) to wire their own backends
+- do not hardcode logging calls; accept a `logger?: BasicLogger` parameter instead
+
+### 7. Storage Adapters
+
+Stateful persistence should be isolated behind adapter/service layers.
+
+Design implication:
+
+- file-backed, SQLite-backed, RPC-backed, and enterprise-specific persistence should share service logic where possible and isolate backend differences in adapters.
+
+### 8. Extension and Hook System
+
+Extensibility is split deliberately:
+
+- extensions register runtime contributions
+- hooks intercept lifecycle stages
+
+Design implication:
+
+- additive runtime behavior should usually enter through these extension points instead of bespoke special-case host code.
+
+### 9. Context Compaction
+
+Context compaction is owned by `core`.
+
+- `@cline/agents` owns the generic turn-preparation seam:
+  - run normal lifecycle hooks
+  - allow hosts to rewrite message history or system prompt before the provider call
+- `@cline/core` owns compaction policy:
+  - inject a prepare-turn pipeline for root sessions
+  - choose between built-in strategies through a registry map
+  - keep compaction logic out of the low-level agent message builder
+
+Design implications:
+
+- compaction is a context-pipeline concern owned by `core`
+- `agents` stays focused on the stateless loop and provider/tool orchestration
+- delegated/subagent flows should inherit compaction behavior through core session config, not through a separate agent-level compaction hook surface
+
+### 10. Extension Layering Inside Core
+
+`packages/core/src/extensions` is split by concern:
+
+- `extensions/config`: config loaders, parsers, watchers, and watcher projections such as runtime slash-command expansion
+- `extensions/plugin`: runtime plugin discovery, loading, and sandboxing
+- `extensions/context`: core-owned context/message pipeline concerns such as compaction
+
+Design implications:
+
+- avoid mixing config discovery code into runtime/plugin code
+- avoid creating thin runtime wrapper files when a helper is fundamentally projecting watcher state
+
+## Architectural Constraints
+
+### Keep `agents` Stateless
+
+Do not move these concerns into `@cline/agents`:
+
+- session persistence
+- provider settings storage
+- RPC lifecycle
+- host-specific approvals
+- remote-config policy caching
+
+### Keep `core` Generic
+
+Do not make `@cline/core` organization- or provider-specific.
+
+If a capability is truly generic and app-facing, add a generic core seam. Reusable remote-config parsing, materialization, and upload primitives belong in `@cline/shared/remote-config`.
+
+### Use One-Way Optional Layers
+
+Optional higher-level integrations may depend on lower layers.
+Lower layers should not depend on optional feature packages.
+
+For remote config, that means shared owns the reusable bundle/materialization/blob primitives and core owns only the session-oriented wrapper exported to apps.
+
+## File-Based And Event-Driven Automation (`ClineCore` / `CronService`)
+
+`@cline/core` ships a file-based automation subsystem under
+`packages/core/src/cron/`. It lets operators author recurring and one-off
+tasks as Markdown files under global `~/.cline/cron/` by default, and
+event-driven tasks as `events/*.event.md` specs. All trigger kinds run
+through the same durable queue and runtime handlers. `ClineCore` exposes the
+SDK-facing `cline.automation.*` entry points; `CronService` is the internal
+orchestrator used by core and hub layers.
+
+### Layers
+
+1. **Spec parser** (`cron/specs/cron-spec-parser.ts`): parses YAML frontmatter + body
+   into a `CronSpec` discriminated union (`one_off | schedule | event`).
+   Types live in `@cline/shared` under `src/cron/cron-spec-types.ts`
+   so other packages can consume them without the YAML parser. Schedule
+   expressions and timezones are validated before a spec can become
+   runnable.
+2. **Store** (`cron/store/sqlite-cron-store.ts`): owns `cron.db` at
+   `resolveCronDbPath()` (default `.cline/data/db/cron.db`). Schema is
+   bootstrapped from `cron/store/cron-schema.ts` — sessions and cron live in separate
+   DBs so their lifecycles stay decoupled.
+3. **Reconciler** (`cron/specs/cron-reconciler.ts`): scans the configured cron specs
+   directory (global `~/.cline/cron/` by default, or workspace-scoped when
+   configured), parses each file independently, and upserts spec state.
+   Invalid specs are recorded
+   with `parse_status='invalid'` so state is durable rather than silently
+   dropped. Files that disappear between scans get `removed=1` and their
+   queued runs are cancelled.
+4. **Watcher** (`cron/specs/cron-watcher.ts`): `node:fs watch({ recursive: true })`
+   with a ~250ms per-path debounce. Watcher events always trigger a
+   re-reconcile — the reconciler is always the source of truth, not the
+   watcher stream.
+5. **Materializer** (`cron/runner/cron-materializer.ts`): turns file-triggered specs into
+   queued `cron_runs`. One-off: at most one run record per `(spec_id,
+   revision)`, including failed runs so specs do not retry accidentally.
+   Schedule: "one overdue catch-up on startup then advance" using
+   timezone-aware `getNextCronTime`.
+6. **Event ingress** (`cron/events/cron-event-ingress.ts`): accepts already-normalized
+   `AutomationEventEnvelope` values, persists them into `cron_event_log`,
+   matches enabled event specs by `event_type` plus declarative filters,
+   applies dedupe/debounce/cooldown policy, and enqueues `cron_runs` with
+   `trigger_kind='event'`. It never executes agents directly. Plugins can
+   declare `automationEvents` and submit normalized events through
+   `ctx.automation.ingestEvent(...)`; sandboxed plugins forward those events
+   through the core plugin event bridge.
+7. **Runner** (`cron/runner/cron-runner.ts`): polls `cron.db`, atomically claims
+   queued runs, executes them via the existing `HubScheduleRuntimeHandlers`
+   (`startSession` → `sendSession` → `stopSession` / `abortSession`),
+   renews the run claim while execution is active, writes a markdown report
+   per run, and transactionally updates status. File specs can constrain
+   tool availability, config extension loading (`rules`, `skills`,
+   `plugins`), session source, and a notes directory that is injected into
+   the system prompt. Event runs include the normalized trigger event context
+   in the prompt.
+8. **Reports** (`cron/reports/cron-report-writer.ts`): writes
+   `.cline/cron/reports/<run-id>.md` with run frontmatter plus
+   `## Summary`, `## Usage`, `## Tool Calls`, and, for event runs,
+   `## Trigger Event` sections.
+9. **Service** (`cron/service/cron-service.ts`): orchestrates all of the above.
+   `ClineCore.create({ automation })` owns the SDK-facing lifecycle and exposes
+   `cline.automation.*` methods. Hub-side callers can submit normalized events
+   through the `cron.event.ingest` command.
+
+The detached hub daemon passes its workspace root as `cronOptions`, so
+normal CLI/hub startup watches `${workspaceRoot}/.cline/cron/` without a
+custom host needing to opt in.
+
+Programmatic hub schedules are stored as `cron_specs` with source
+`hub-schedule` and execute through the same `cron_runs`
+claim/requeue/report flow as file-backed one-off, recurring, and
+event-driven specs. The hub schedule command surface remains a thin adapter;
+there is no separate schedules table, schedule store, or schedule runner.
+
+## Navigating the Codebase
+
+### Starting Points by Task
+
+**I want to understand the agent loop and tool execution:**
+- Start: `packages/agents/src/agent.ts` — the stateless runtime loop
+- Then: `packages/agents/src/agent-step.ts` — individual iteration steps
+- Extensions: `packages/core/src/extensions/plugin/` — plugin discovery and sandboxing
+
+**I want to understand session persistence and state:**
+- Start: `packages/core/src/runtime/host/local-runtime-host.ts` — local session lifecycle
+- Then: `packages/core/src/runtime/orchestration/` — session orchestration
+- Settings: `packages/core/src/settings/` — settings mutation and state
+
+**I want to understand the hub system:**
+- Start: `packages/core/src/hub/server/` — WebSocket server and hub command handlers
+- Clients: `packages/core/src/hub/client/` — host-side hub clients
+- Transport: `packages/core/src/hub/runtime-host/` — hub-backed runtime hosts
+
+**I want to add a new tool:**
+- Tools registry: `packages/core/src/extensions/tools/` — built-in tool definitions
+- Tool execution: `packages/agents/src/tool-use.ts` — how tools are called
+- Plugin tools: `packages/core/src/extensions/plugin/` — plugin-registered tools
+
+**I want to understand settings and configuration:**
+- Watcher system: `packages/core/src/extensions/config/` — file watching and loading
+- Provider config: `packages/core/src/runtime/config/` — provider settings resolution
+- Settings services: `packages/core/src/settings/` — settings state and mutation
+
+**I want to add a new runtime feature (hook/extension):**
+- Hook contracts: `packages/shared/src/hooks/` — hook types and engine
+- Plugin system: `packages/core/src/extensions/plugin/` — plugin discovery and execution
+- Runtime builder: `packages/core/src/services/local-runtime-bootstrap.ts` — how runtime is composed
+
+### File Naming Conventions
+
+- `*.ts` — TypeScript source
+- `*.test.ts` — unit tests (Vitest)
+- `*.e2e.test.ts` — end-to-end tests requiring full integration
+- `*.ts` in examples — runnable example files (plugins, hooks)
+- `*.md` files in `apps/examples/` — documentation and markdown-based specs (cron, events)
+
+### Key Type Locations
+
+- **`ClineCore`** — `packages/core/src/index.ts` — the main SDK orchestrator
+- **`Agent`** — `packages/agents/src/agent.ts` — the agent loop
+- **`RuntimeHost`** — `packages/core/src/runtime/host/runtime-host.ts` — execution abstraction
+- **`AgentPlugin`** — `packages/shared/src/plugin/` — plugin contract
+- **`CronSpec`** — `packages/shared/src/cron/cron-spec-types.ts` — automation specs
+
+## Publishability Constraint
+
+This repo has both publishable SDK packages and internal workspace packages.
+
+Architectural consequence:
+
+- internal packages must not accidentally become part of the publishable SDK surface
+- release automation should only target the intended published packages
+- internal code may compose with published packages, but published packages should not take hard dependencies on internal-only workspace layers unless you explicitly intend to publish that integration
+
+### Published Packages
+
+The following packages are published to npm:
+
+- `@cline/shared` — shared types, contracts, and low-level utilities
+- `@cline/llms` — provider integrations and model manifests
+- `@cline/agents` — the agent loop and tool orchestration
+- `@cline/core` — the main SDK with session management, hub, and configuration
+
+### Internal Apps
+
+The following workspace apps are internal and not published as SDK packages:
+
+- `apps/cli` — CLI implementation
+- `apps/webview` — VS Code webview
+- `apps/examples` — example plugins and integrations

codna/agent-core/vendor/cline/sdk/CHANGELOG.md

@@ -0,0 +1,32 @@
+# Cline SDK Changelog
+
+## 0.0.44
+
+- Added support for Vertex AI Application Default Credentials (ADC) with tool use
+- Added a global auto-update setting for CLI startup updates
+- Fixed empty message content replay for Bedrock
+- Cleaned up the OpenAI Codex model list
+
+## 0.0.43
+
+- Added the Cline Hub web app for managing and monitoring agent sessions
+- Added plugin uninstall support
+- Added skills bundled with plugins, including grouping plugin skills in settings and rule contributions from sandboxed plugins
+- Added support for global AGENTS rules
+- Added Slack socket mode support and bound Discord sessions to individual message authors
+- Synced the Fireworks AI model registry and updated the model catalog to current platform offerings
+- Routed custom registered handlers through the agent runtime
+- Added a CLINE_PLUGIN_IMPORT_TIMEOUT_MS environment override for plugin import timeouts
+- Allowed a baseUrl field for Anthropic vendor-type providers
+- Fixed SAP AI Core to use the AI SDK community provider
+- Fixed the hub daemon to stay alive on runtime abort
+- Fixed read-files tool input validation to use a union schema
+- Fixed discovery of symlinked SDK skill directories
+- Improved Cline provider migration
+- Fixed OTEL variable bundling
+- Added telemetry for run_commands timeouts
+
+## 0.0.42
+
+- Supports Bedrock bearer API keys, direct IAM credentials, AWS profiles, and the default AWS SDK credential chain
+- Routes Z.AI GLM thinking through provider metadata while preserving generic thinking suppression for non-GLM Z.AI custom models