Releases

Node detail no longer repeats the pod list

• The monitoring section already lists the pods on the node, so the separate Pods section below it is no longer drawn.
• On clusters without monitoring data (connection without an agent, no collector, or no permission) the separate list appears as a fallback.
• Pods whose containers never started (ImagePullBackOff, ContainerCreating) are not in the monitoring data, so they do not appear on the Node page; they still appear in the Pod list and in the workload detail.

Secret values hidden in the edit dialog

• The Secret edit dialog (YAML and Form tabs) now opens with values (data, stringData and the copies inside the last-applied-configuration annotation) shown as ***; “Show values” reveals them. In 0.84.1 only the Secret's YAML view was hidden and the edit dialog showed values in the clear; that is now closed.
• While hidden, a value you did not touch is sent as the stored original; *** is never sent to the server. A new value you type after deleting the mask is sent as written.
• No plan is built, and the reason is shown, when the mask is mixed with other text or consists of asterisks only; for a key renamed while values are hidden; and when the same key is changed in data but left hidden in stringData (stringData wins in Kubernetes).
• This is a display measure, not an access boundary. “Create a copy” still shows the source Secret's values in the clear.

List tables: Node column and column order

• The Node column is removed from the Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob and ReplicationController lists; the workload-list Node column from 0.84.0 is gone. The Node column in the Pod list and its link to the node's detail stay.
• The Images column now follows Name directly and Age comes last: Status, Namespace (when shown), Name, Images, Age in the workload lists; Status, Namespace (when shown), Name, Images, Ready, Restarts, Node, Age in the Pod list. With the Node column gone from the workload lists, Images stays visible at narrower window widths there.

Node detail without tabs

• Node detail has no tab strip; the page runs top to bottom through the monitoring cards, the pods running on the node, Conditions and Events. YAML opens with the YAML button in the summary row.
• On a healthy node, events are read with the “Show events” button; if the node has a bad condition they are read when the page opens.

Secret values hidden in the YAML view

• In the YAML view of a Secret, values (data, stringData and the copies inside the last-applied-configuration annotation) show as *** by default and open with “Show values”. Every Secret opens with its values hidden. The copy YAML button copies what is on screen.
• This is a display measure, not an access boundary: the values reach the browser and “Show values” reveals them. The edit dialog still shows the values in the clear.

List tables: Status and Node columns

• ReplicaSet, DaemonSet and ReplicationController lists fold the Desired, Current and Ready columns into one Status column (ready/desired); hover it to see all three numbers.
• The Pod list shows each pod's node as a link to the node's detail. Deployment, StatefulSet, DaemonSet, ReplicaSet, Job and CronJob lists show the node the workload's pods run on; when they span several nodes, the node carrying the most pods plus “+N”. This comes from the agent's monitoring data (on clusters connected with the agent) and reflects changes with a delay of up to a few minutes; rows of pods whose containers never started show “—”.
• In a narrow window the Images column steps aside; resource names are never shortened at any width.

Tabbed object detail

• A one-line status summary sits under the title; an attention band appears only when something is wrong and says why.
• Tabs depend on the object: Pods (with monitoring below), Network (Service, Ingress, HTTPRoute), Configuration (ConfigMap, Secret, ServiceAccount and PVC references), Events, Conditions, YAML. A Service shows its endpoints and its traffic sources, a Node the pods running on it, a ConfigMap its Data.
• Pod detail has a container table: status, image, restart count and how long it has been up; the row menu offers Shell and Logs.
• Logs and Shell open in the bottom panel from everywhere.

Interface: buttons, tabs and tables

• Primary action buttons are now filled, so Apply stands apart from Cancel and Refresh on the approval card.
• Tabs became an underlined strip and the time-range picker a joined segment control. The selected state uses the accent color instead of the warning color.
• The operations log and audit trail read without horizontal scrolling on wide screens. Cells use two lines, and the full event body opens in a copyable dialog.
• Admin tables (Hooks, users, alert routes, silences, maintenance windows, AI providers) show one visible row action; the rest are in the ⋯ menu.
• Object detail now shows the object's conditions (status.conditions) as a table at the top: type, status, reason, message, since.
• The resource list filter row is slimmer, so the table starts higher.
• On cluster and admin screens the sidebar now collapses into a drawer up to 1099 px. Windows between 1024 and 1099 px get the full content width.
• Cluster menu group headings match the admin menu. The Operations and Monitoring entries no longer truncate their descriptions.
• Admin form fields are capped at a readable width; the compliance report shows both dates side by side.

YAML editor: the error stays on the line

When editing a resource in the YAML tab, a syntax error is now shown only inside the editor, by marking the offending line in red; hovering the line shows the short reason. The long error text above the editor is gone. Hovering the Form tab button says why it is locked.

helm: golang.org/x/net 0.62.0

The helm binary in the core image is now built with golang.org/x/net 0.62.0. The release scan found a high-severity vulnerability in 0.60.0 that is fixed in 0.62.0 (CVE-2026-78661). The helm and kustomize versions are unchanged.

MCP: Claude Desktop and Cursor setup

The Use with MCP section that opens when you create a token on the My account page now also covers Claude Desktop and Cursor, next to Claude Code and Codex. Each tab has one sentence on what to do and a single snippet to copy that contains the token. Claude Desktop connects to YEKE through the mcp-remote bridge and needs Node.js. Details: API and MCP.

Agent: undici 7.30.1

The agent image now uses undici 7.30.1. The release scan found four high-severity flaws with fixes in 7.30.0 (CVE-2026-109383, CVE-2026-109829, CVE-2026-109869, CVE-2026-87018).

AI providers: only current models in the catalog

The catalog on the AI providers screen now suggests only the current release of each family for Anthropic, Google Gemini and OpenAI. Anthropic: Claude Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1. Gemini: 3.8 Flash, 4 Argon and 3.5 Flash-Lite. OpenAI: GPT-6 Astra, GPT-6.1 Sol and GPT-6 Luna. Earlier generations are no longer listed. The catalog is a prefill suggestion; you can still type a model name that is not listed, and existing providers are unchanged. On OpenAI, tool calling over Chat Completions is unrestricted only on GPT-6 Astra. The connection test measures GPT-6.1 Sol and GPT-6 Luna at a tier without native tools; they work, but tools are sent through a text contract instead of native tool calls. The release's scan table is below.

KubeWorld: correct ready count for operator-managed workloads

KubeWorld draws a workload by the object at the top of its owner chain. When that object is an operator's resource (e.g. RabbitmqCluster) that never writes a ready replica count, the missing count was taken as zero, so a cluster whose pods were all ready showed a “0/1 ready” warning. The count is now read from the highest object in the chain that actually writes it (usually the StatefulSet). If none writes it, the count is still zero and the warning stays, so a workload with no ready pods still warns. The building type is unchanged.

helm and kustomize: Go 1.27.3

The helm and kustomize binaries in the core image are now built with Go 1.27.3. The release scan found a high-severity vulnerability with an available fix in the Go 1.27.2 standard library (CVE-2026-111943), and the gate held this release until it was patched. Both tools keep their versions (helm v3.22.0, kustomize v5.8.3). The release's scan table is below.

Cluster dots in both fleet sections

On the home page, the Open alerts section now uses the same indicator as Problem workloads instead of a table skeleton: one dot per cluster next to the heading and a counter such as “5/14”. The indicator of both sections appears as soon as the page opens and, even if loading is short, stays for at least 0.4 seconds. Before, the indicator appeared only once loading exceeded 0.6 seconds, so it never showed when alerts arrived quickly. If there are no open alerts, the indicator is removed; the page shifts far less than with the skeleton. The release's scan table is below.

Table skeleton while open alerts load

On the home page, the Open alerts section now shows the table's skeleton on first open until the data arrives: the real column headings and three faded rows. This makes the section's place clear from the start. Even when alerts arrive very quickly, the skeleton stays visible for a short time (about 0.4 seconds), so it does not flicker. If there are no open alerts, the skeleton is removed and the page glides upward. The cluster-dot indicator of the Problem workloads section is unchanged. The release's scan table is below.

Loading indicator in the home page fleet sections

The Open alerts and Problem workloads sections on the home page now give a visible sign while they load on first open. Next to the section heading there is one dot per cluster; the dot of a cluster that has responded fills in, with a counter such as “5/14” beside it. The indicator appears only if loading takes longer than 0.6 seconds; because alerts usually arrive faster than that, in practice it shows in the Problem workloads section. It is there only on the page's first open and does not show on later refreshes. If no cluster responds, the section does not stay empty: the heading and a note “…not read: no cluster responded” are shown. A screen reader announces loading twice: when it starts (“reading 14 clusters”) and when it finishes. The release's scan table is below.

Display fixes in the home page fleet tables

Four display problems seen with real data in the home page fleet sections introduced in 0.81.22 are fixed. In the Problem workloads table the state (such as ImagePullBackOff) is now on a single line on wide screens; rows are the same height as in the alerts table. The Namespace column is no longer truncated while there is room, in both tables. YEKE's own state names are written in plain language: Restarting repeatedly, Not ready, Failed Job, Failed pod. Kubernetes' own terms (ImagePullBackOff, OOMKilled…) stay untranslated. The restart count is written compactly in the Duration column (for example “11,559 times”). The release's scan table is below.

Fleet-wide open alerts and problem workloads on the home page; open alert count no longer undercounted on busy clusters

The home page now shows two fleet-wide sections above the cluster list, without opening a cluster: Open alerts and Problem workloads. Open alerts lists the alert engine's open events with severity, rule, object, namespace, cluster and start time. Problem workloads lists workloads in a state such as ImagePullBackOff, CrashLoopBackOff, OOMKilled or Unschedulable, with state, workload, namespace, cluster, ready count and duration. Each table first shows at most 5 rows and expands with Show all; a section with no rows is not shown at all. Clusters that could not be read, could not be reached or were read only partly are named in the note under the section heading. The data is read with the user's own Kubernetes permissions. Fix: the alert chip in the cluster top bar, the Monitoring › Alerts tab and the KubeWorld open events now read directly with the open-event filter. On a cluster with many old events, an alert that was still active could fall outside the list and the open alert count could come out too low. Fix (API): the error returned when the states parameter of the alert event list is repeated (?states=firing&states=pending) is gone; an unrecognised state name now returns 400 INVALID_STATE (the filter used to be ignored). The release's scan table is below.

Schema discovery no longer fetches the resource lists of the metrics API groups

If a cluster runs an adapter that serves the custom metrics API (for example Rancher Monitoring's prometheus-adapter), schema discovery fetched that group's full resource list every time the cache was empty. The list carries Prometheus metric names, not resource types, and can run to thousands of entries. On clusters with a slow agent tunnel it delayed schema loading by seconds, and with it plan building; it showed most in the “Update agents” queue, which builds every plan without a cache. Discovery no longer requests the resource lists of custom.metrics.k8s.io and external.metrics.k8s.io. The resource list, the side menu and the approval chain are unchanged; metrics.k8s.io (metrics-server) and the usage charts are not affected. In production, on three clusters running this adapter, uncached schema loading took 3.6–4.8 s before the rollout and 0.4–0.5 s after. The time depends on the agent tunnel's speed; because the rollout re-established the tunnels, the two measurements are not on the same connection. Limit: a failure of these two groups no longer shows up in the “Discovery skipped … API groups” warning, and the non-listable type the external metrics group produces on some installs disappears from type search. The release's scan table is below.

Revert: a controller's write no longer triggers the “changed by someone else” warning

When you revert an applied operation, the approval card warns you if the target was also changed by someone else after that operation. Until now that decision looked only at the object's version number (resourceVersion). Kubernetes controllers' status updates also increase that number, so objects with a controller, such as a Deployment, showed the warning even when no one else had touched them, for example when reverting a scale a few seconds later. Now, when the number has changed, YEKE compares the fields the revert would overwrite: spec, labels, finalizers, owner references (ownerReferences) and the rest of the object, such as a ConfigMap's data. The status field (status) and annotations are left out of the comparison, because controllers write annotations too (a Deployment's revision annotation, for example). As a result, a real intervening change still produces the warning, and a controller's write alone does not. Known limit: if the only intervening change is to annotations, there is no warning and the revert also returns those annotations to their previous state. Nothing else changes in the web UI or the approval chain. The release's scan table is below.

API: pod health endpoint

The new read-only endpoint GET /api/clusters/:clusterId/pod-health returns a cluster's unhealthy workloads in order of severity: pods whose image cannot be pulled, pods that crash and restart (including ones that never enter CrashLoopBackOff but restarted at least 3 times in the last 6 hours), pods ended by OOMKilled, pods with missing configuration, pods unschedulable for more than 5 minutes, pods not ready for more than 10 minutes, and failed Jobs. The classification uses the same rules as the scan, so both surfaces give the same verdict for the same workload. The read runs with the requesting user's own Kubernetes permissions and only reads; namespaces the user cannot see are not named in the response, only counted. The endpoint feeds the "Problems" screen of YEKE's not-yet-released iOS and Android client. The web UI does not change. The release's scan table is below.

License: the mobile feature

The license dictionary gains the name mobile (Enterprise). It is the license gate of YEKE's not-yet-released iOS and Android client: the client opens on an installation only with a license that carries this feature. The web UI, the CLI and the API do not look at it and work as before under every license. A core older than this release still accepts a license that contains mobile, but shows the name as an "unknown feature". No other behaviour changes. The release's scan table is below.

UI: node tables share one layout, resource headers carry an icon

The cell layout of the node table on the cluster overview has moved to the Monitoring › Nodes table and to the Pod column of the node list: each resource cell shows "used / total · percent" on top and a cell-width usage bar underneath. The Pod column of the node list now prints the percentage too (the "Full" warning stays where it was). The CPU, Memory, Disk and Pod headers of the cluster overview and Monitoring tables have a small icon each; its colour is fainter than the header text, and it is not a clickable element. To avoid sideways scrolling on a narrow screen, the Monitoring table narrows the bars slightly when space gets tight; in the dark theme the bar track stands out more clearly from the row background. This is the first release where the release gate also stops on a HIGH finding, not only on CRITICAL. The release's scan table is below.

UI: a terminal in a tab left open across an update no longer blanks the page

In a tab that stayed open after YEKE was updated, opening a Shell or a pod terminal for the first time could leave the page completely white; reloading the page fixed it. The tab was still running the old version, so a part the terminal needs was no longer on the server, and the interface had no layer to catch that error. Rendering errors in the interface no longer blank the whole page: if a terminal tab cannot open, the page stays up and the tab shows the message "YEKE was updated while this page was open" together with buttons to end the session and to reload the page. For other unexpected rendering errors the application also shows an error screen instead of a blank page. The page does not reload itself; the decision to reload is the user's. The scan table of this release is below.

Shell: kubectl connects behind a TLS-terminating edge too

When core serves its certificate from its local CA and an edge in front of it presents its own certificate (a proxy such as Cloudflare, a corporate ingress), kubectl and helm in the Shell failed with x509: certificate signed by unknown authority; this had been the case since 0.75.0. The Shell now trusts core's CA in addition to the image's system roots; before, it trusted only core's CA. As a result kubectl connects both when it reaches core directly and when it sits behind such an edge. This ships with toolbox image v7, and the default toolbox image of core is now nairotech/yeke-toolbox:v7. The tools and their versions in v7 are the same as in v6. If you build your own toolbox derivative for YEKE_TOOLBOX_IMAGE, the fix lives in the Shell script inside the toolbox image: base your derivative on FROM nairotech/yeke-toolbox:v7. The scan tables of this release and of toolbox v7 are below.

Toolbox image v6: no HIGH findings left

The default toolbox image of core is now nairotech/yeke-toolbox:v6. In this image, which the shell uses, kubectl 1.36.5, helm 3.22.0 and yq 4.54.1 are built from source with Go 1.27.2 at the same versions. All 12 HIGH findings in v5 were in the Go code inside these three tools; v6 has no HIGH findings. The tools' versions and command behaviour did not change. As a result, none of the core, agent and toolbox images has a HIGH finding. If you build your own toolbox image for YEKE_TOOLBOX_IMAGE, the current base is FROM nairotech/yeke-toolbox:v6. The scan tables of this release and of toolbox v6 are below.

No HIGH findings left in the core and agent images

The release scan of 0.81.12 found 33 (amd64) and 35 (arm64) HIGH findings in the core image and 13 in the agent image; this release leaves no HIGH finding in either. Node dependencies were updated: fastify 5.12.7 and fast-uri in core, undici 7.30.0 and js-yaml 4.3.2 in the agent. The runtime images no longer contain package managers (npm, npx, corepack, yarn), and the runtime stage now also picks up the base image's patches. The helm 3.22.0 and kustomize 5.8.3 in the core image are built from source with Go 1.27.2; their versions and behaviour did not change. This release's own scan result is in the table below.

Toolbox image v5

The default toolbox image of core is now nairotech/yeke-toolbox:v5. v5 is the first toolbox tag that was scanned before it was published.

Session loss is noticed while the socket is closed

If the session ends while the live connection is closed (computer sleep, a long network outage), an open tab now notices it without waiting for another request and shows the session-lost notice once. Before, the tab could not tell the unauthenticated rejection from a network outage and kept retrying the server.

kustomize and helm updated; CRITICAL vulnerability closed

The core image now ships kustomize 5.8.3 and helm 3.22.0. The kustomize binary in 0.81.11 was built with Go 1.24.0 and carried a CRITICAL vulnerability from the Go standard library (CVE-2025-68121); 5.8.3 is built with Go 1.27.1. Helm stays on the v3 series.

Every release is scanned before it is published

From this release on, the core and agent images are scanned with Trivy on both architectures before they are published. A CRITICAL finding stops the release; a finding with no fix available yet can only pass with a justified, time-limited exception, and that exception is listed under the release. The scan summary is published under every release as a table, with a machine-readable JSON next to it. The 0.81.11 table comes from the first scan, run after that release was published.

Kubernetes manifests: seccomp and the yeke-core ServiceAccount

The core Deployments under deploy/kubernetes (single-node and HA) now set seccompProfile: RuntimeDefault at pod level and run as their own yeke-core ServiceAccount, defined without RBAC permissions in 00-namespace.yaml. When upgrading an existing Kubernetes installation, apply 00-namespace.yaml before the Deployment. On OpenShift/OKD, core runs once the nonroot-v2 SCC is granted to the yeke-core ServiceAccount (tried on OKD 4.22). Core's fixed user ID (65532) is unchanged.

Higher memory settings for the agent

New agent installations request 128 MiB of memory and are limited to 512 MiB; before it was 64 MiB and 256 MiB. At 256 MiB, Node.js's own heap ceiling sat above the container ceiling, so when memory filled up the process could be killed without leaving a log and the tunnel could drop. At 512 MiB the heap ceiling does not change and there is room left outside the heap. "Update agent" carries these values to existing installations too, but only by raising them: it leaves a larger value alone, does not add a field that is not defined, and does not change the limit on an installation that has no memory request defined. The change shows in the note of the approval card. The agent's CPU settings did not change.

"Reload page" when the certificate is renewed

When YEKE serves its own HTTPS and its local CA re-issues the certificate (for example when the public address changes, or when you switch from your own certificate to an automatic one), a persistent "Certificate renewed" notice and a "Reload page" button appear in the save bar of System settings. Requests that fail in this state now show an explanation and "Reload page" instead of a silent "unreachable". Refreshing makes the browser close its open connections that use the old certificate; the browser then sees the new certificate and opens its confirmation screen. At the end of installation, if the certificate was renewed, "Go to YEKE" does a full page reload. This behavior applies only to YEKE's own TLS; it does not apply when TLS terminates at a load balancer or an Ingress.

Node table widens into bar columns on large screens

On a wide screen, the extra width in the node table goes to the columns that carry bars, so the bars get longer; the node name column keeps a fixed share.

The Download menu works with the keyboard

The "Download" menu in the log view can be used with the keyboard: when it opens, focus moves to the first option, the arrow keys and Home/End move through the options, and Escape closes the menu and returns focus to the "Download" button. It behaves like the other dropdown menus in the app.

Usage bars are back in the node table

The usage bars under the CPU, Memory, Disk and Pod values in the node table of the cluster overview are back; they had gone away in 0.81.8 together with the in-row charts. The small trend lines in the rows stay removed. When there is no reading or no upper limit, no bar is drawn.

Alerts table has a fixed height

The Alerts table shows 6 rows at a time; more rows scroll inside the table and the header row stays in place. With no alerts, the section is not shown. When the tunnel drops, no "Loading" box appears; the reconnecting banner shows only while there is data on screen.

Action menus work with the keyboard

The ⋯ action menus can now be used with the keyboard: arrow keys move through the items and Escape closes the menu.

PostgreSQL setup can create the database

If the database in YEKE_DB_URL does not exist and the connecting role may create databases, YEKE creates it and continues the setup; if the URL gives no database name, the name is yeke. An existing database is used as it is. Without that privilege, startup stops and tells you the database name, the role and what needs to be done.

Scan and Alerts are separate sections

In the cluster overview, Scan and Alerts are now two separate sections. The Scan card carries the verdict, the time and "Scan now"; Alerts stands on its own with its own heading, count and live feed.

Agent update popup is no longer clipped

In the cluster list, the popup opened by the agent update marker is no longer cut off at the bottom of the list. On the last rows, where there is no room below, it opens upward; on narrow screens it is fully visible and the "Update" button can be pressed. It closes when the page is scrolled or the window is resized. When opened with the keyboard, focus moves into the popup; Escape closes it and returns focus to the marker.

Menus no longer flicker in short windows

In short windows (for example a phone held sideways), the row action menu and the agent update popup no longer change height and flicker. When they do not fit, they stay at a fixed height and scroll inside.

A calmer cluster overview

Health and warnings now share one panel; when nothing is wrong the panel shrinks to a single line. The connection details under the title are one quiet line, with a label only when the tunnel is down. GitOps details are gathered in one list. In the cluster list, numbers are right-aligned and line up.

Operations log

Each row in the log now shows relative time, who made the change and what kind of change it was ("deleted", "updated ×2"). Consecutive identical operations fold into one row.

Menus and administration pages

Resources with the same name are now told apart in the sidebar ("Event · events.k8s.io", for example). Administration pages keep a permanent sidebar, which becomes a drawer on narrow screens. On the Users page, row actions moved into a ⋯ menu and "Create user" sits in the header. Alert rules no longer repeat "no filter"; each row has Edit and ⋯. The ⋯ menus work from the keyboard too: arrow keys move, Escape closes.

Assistant panel

Token details show only on hover. The suggestion card shows how the change looks before and after.

Warnings table on the overview

The Warnings table on the cluster overview now shows seven columns: Namespace, Last Seen, Type, Reason, Object, Source and Message. The table no longer scrolls sideways; hover over a shortened cell to see its full value.

Pending plans in one click

In the Operations section, a plan waiting for approval now has an "Open" button that opens the approval card on the same screen.

Node table: long names and narrow screens

In the node table on the Monitoring page, long node names (GKE names, for example) are now shortened in the middle only when there is no room: the start is cut with "…" and the distinguishing end of the name always stays visible. The full name shows under the pointer and is read by screen readers. On a wide screen the name is shown in full. The gaps between the meter columns are also slightly narrower, so the table starts scrolling sideways later on narrow screens.

Usage bar in the dark theme

In the dark theme the empty part of the usage bar is one shade lighter, so you can now tell where the bar ends against the row background. The light theme is unchanged.

Usage bars sit under the value in node lists

In the node table on the Monitoring page's Overview and Nodes tabs, the CPU, memory, disk, pod and pressure cells now have two lines: the percentage and value on top, a cell-wide usage bar underneath. The bar used to be a short strip to the left of the value, and once the Pod column was added the table scrolled sideways on narrow screens. The new layout makes the columns narrower, and the longer bar makes close values easier to tell apart. The Pod column in the node list uses the same layout. Rows are slightly taller.

Chat and MCP: pod occupancy in node reads

When the AI assistant or an MCP client reads a node's metrics, the result now also carries the node's pod capacity and pod occupancy ratio; before, that read held only CPU, memory and disk. The assistant can now answer "is this node full?" from a single read; previously it saw occupancy only in the overview's attention list, and only for nodes above 90%. The number is the same node pod occupancy introduced in 0.81.0. The occupancy ratio requires agent 0.81.0 or later; an older agent reports only the capacity.

Pod fullness on nodes

You can now see how many pods each node can still take: the number of pods on a node, as a share of the node's pod capacity, is shown in Cluster overview, Monitoring › Nodes (a sortable column and the needs-attention list), the node list (a new Pod column) and the node detail (fullness in the header, plus a chart card). At 100% the cell also says "Full"; that means the scheduler will not place a new pod on that node, which is when "Too many pods" starts. The count is the same one the scheduler uses: every pod bound to the node that has not finished is counted, including pods that cannot pull their image or are waiting after a crash. The agent does the counting, so the screens and the alert show it only in agent mode and only after the agent is updated to 0.81.0 ("Update agent"). On an older agent the column is hidden, and a missing count shows "—" rather than 0. The ClusterRole did not change, so you do not need to re-apply the manifest. For this count the agent lists and watches pods per node asking for metadata only; it does not read pod bodies, specs, env or Secrets, and it asks for no new permission.

Alert: node pod fullness

The built-in rule set gains a "node pod fullness ≥ 90%" rule: it fires at warning level if fullness stays above 90% for 5 minutes. Alerts are an Enterprise (metrics-alerts) feature.

Scan: diagnosing a full node

The scan now diagnoses a full node; the new root cause is "node pod capacity". If the model leaves a node that is 100% full out of the report, YEKE adds the finding itself. When a pod is pending because of "Too many pods", the severity is critical. The scan reads the count with your own Kubernetes permissions, so it does not depend on agent mode; if you cannot see every pod, YEKE does not compute occupancy.

Deleted pods on the node detail

The pod count on the node detail no longer includes deleted or moved pods; it used to keep counting them for two days.

A ship in the report while a scan runs

While a scan is running, the scan report in Monitoring and the scan card in chat now show a Scanning… heading and the scan ship sailing across the row instead of a plain loading text; when the scan finishes, the result appears in the same place. The report's top row also no longer shows the finding and tool-call counts while the scan runs, so "0 findings" is not displayed before the result arrives.

Scan: when a DNS component has no pods, its controller is checked

When deep analysis cannot find the pods of a system component such as the cluster DNS, it no longer stops at "not reachable"; it checks the component's Deployment or DaemonSet and reports a component failure when no replicas are ready. If the controller is not found either, the absence alone is not treated as evidence.

A single scroll while the license banner is shown

The banner shown when the license is about to expire, is in its grace period or is frozen made the page taller than the window by the banner's height. The whole window scrolled in addition to the page's own scrollbar, so two scrollbars appeared. The banner and the page now share the window height, and only the page content scrolls while the banner is visible.

Top bar popovers on narrow screens

On phone-width screens, the top bar popovers (the namespace picker, the alert status chip, the identity badge, and the user and admin menus) overflowed the right edge of the screen or were cut off on the left; the overflow on the right made the page scroll sideways. Popovers now open inside the visible area and keep their position when redrawn while open. Wide screens look the same as before.

A closed terminal no longer leaves a shell behind in the pod

When a pod terminal or the YEKE shell was closed, Kubernetes did not tell the shell of a tty session that the connection had ended, so the shell and the program running in it stayed open in the pod. Now, when the session closes, YEKE runs a short cleanup command in the same pod with the same identity, sends SIGHUP to that session's shell and its processes, and terminates a shell that does not exit. This happens when the terminal is closed, when the idle timeout expires or when the session is revoked; terminals closed while YEKE restarts or the agent connection drops are cleaned up once the connection is back. The cleanup only touches the shell that session opened: if it cannot tell it apart from other terminals opened at the same moment, it terminates nothing. Every cleanup is written to the audit log and stated on the approval card. Jobs you leave in the background after typing exit yourself keep running, as with SSH.

Request bodies in multi-replica installations

With more than one core replica, requests for a cluster whose agent is connected to another replica are now forwarded with their body, unchanged. Before, JSON bodies (such as permission checks) reached the cluster empty, and patch, YAML and protobuf bodies failed. Installations running a single core never use this path and were not affected.

Singular and plural in the English interface

In the English interface, a count of 1 is now written in the singular (like 1 object, 1 line, +1 more pod); before, it always came out plural. Turkish texts did not change.

The ship takes three turns while a scan runs

While a scan is running, the ship that crosses the row now shows something different on each pass: a searchlight sweeping ahead of it on the first pass, sonar rings on the second, and the wake it leaves behind on the third, then it starts over. If reduced motion is turned on in the operating system, the ship stays still.

English warning count

In the English interface and in the subject line of the scan email, the warning count is now written with the correct plural (3 warnings, 1 warning).

Scans see the newest warning events

On clusters with many warning events, the scan now reads the event list newest first; when the list is long, the oldest events are the ones cut. Events used to arrive in name order, so the newest records of a frequently repeating failure could fall outside the list.

Repeats of the same failure on one line

Repeats of the same failure across different objects, such as a CronJob that starts a new Job on every run and fails each time, now collapse into a single line in the scan; the line says how many times it repeated and when it was last seen. A single noisy source no longer pushes failures in other namespaces off the list. Chat and MCP keep showing events one by one, and now also show how many times each event repeated.

No half-finished work left behind when the agent connection is renewed

When the connection between the agent and core drops, or a pod terminal or port-forward is closed while it is still opening, the unfinished work no longer spills over into the next connection. A terminal or port-forward closed while opening now sends the agent a close; before, the agent could still open the stream and hold it until the connection dropped. When the agent hits an intermediary that never answers the handshake, it reconnects instead of waiting silently. If reading the Kubernetes version takes too long, it does not hold the connection back and reports the last version it knew. The core-side fixes apply immediately; the agent-side ones once the cluster's agent is updated to 0.80.6.

Scan: a DNS outage is no longer mistaken for a configuration error

When an application cannot resolve the name of a Service that exists in its namespace because the cluster DNS is not answering, the scan now reports a network error instead of an application configuration error. When it sees the DNS component itself failing, it reports a DNS failure. A name that a single workload misspelled and that crashes its container is still reported as a configuration error. Two contrasting cases added to the evaluation set test the distinction.

An old scan result is shown through fog

When the last scan is more than 24 hours old, the cluster home page and the Monitoring overview no longer present the result as today's state: the headline switches to the past tense (The cluster was running healthy, There was a critical issue), "Last scan 12 d ago · not current" appears beneath it, and the sea scene is wrapped in fog. On the cluster home page, if you are allowed to start a scan, a Scan now button sits next to it.

A sonar ship while a scan runs

While a scan is running, the same row reads Scanning… and a container ship sails from one end of the row to the other, sending out sonar rings; when the scan finishes, the result appears on its own. If reduced motion is turned on in the operating system, the ship stays still.

Scans now see crashing workloads and image pull failures

The scan inferred faults from metrics and Kubernetes warning events, so two kinds of failure went unseen. On a pod that has been unable to pull its image for days, the warning events can disappear, leaving only informational ones. A container that crashes and restarts at long intervals, say once an hour, never enters CrashLoopBackOff and shows as "Running". The scan now reads pod status with your own Kubernetes permissions when it starts and summarises the unhealthy ones per workload: workloads that cannot pull their image, cannot start, are killed for running out of memory or have crashed repeatedly in recent hours; pods that cannot be scheduled or have not been ready for a long time; CronJobs whose last run failed. If the model leaves out a workload that cannot pull its image, keeps crashing or is killed for running out of memory, YEKE adds the finding itself. Old restart counts left over from a node restart are not counted as findings. The change is in core; the agent does not need updating.

A reconnecting agent no longer mixes up its details

When the agent connects to core it reads the cluster's Kubernetes version and reports it on that connection. If the read outlasted the connection and the connection was renewed in the meantime, the old connection's report could also reach the new one, labelling it with the old connection's Kubernetes version and certificate details. Each report now goes only to the connection it belongs to. The fix applies once the cluster's agent is updated to 0.80.2.

Pod terminals and port-forwards are bound to their connection

If the agent's connection to core dropped while a pod terminal or port-forward was being opened, the stream could still be opened on the next connection, and a stream cancelled while opening could open anyway. Each stream is now bound to the connection it was requested on: it is not opened after a disconnect or a cancel, and nothing from an old connection reaches a new one. The fix applies once the cluster's agent is updated to 0.80.1.

The scan email leads with the result

The scheduled scan email now starts with the result itself: a sentence such as The cluster is running healthy or There is a critical issue in the subject line and the first line, and a still image of the sea scene that changes with the result inside the email. The image is embedded in the email; nothing is loaded from outside, so it also shows in air-gapped installations. The plain-text part is unchanged.

The scene in the downloaded report

The HTML scan report downloaded from Monitoring also opens with the same scene, animated. The scene stays still when reduced motion is turned on in the operating system.

Result sentence in Slack, Google Chat and Teams

The scan report sent to chat channels now starts with the result sentence and the cluster name (e.g. There is a critical issue · prod). No image is sent to these channels.

Result code in the webhook

The scan report sent to the generic webhook has a new sea field: harbor, calm, choppy, rough, storm or fog. Existing fields are unchanged.

A nautical chart on the forced password change screen

The forced password change screen now has the same faint nautical chart background as the sign-in, password setup and setup screens. Every screen you see before entering the application now shares the same background.

The agent sends metric samples on time

While long-running watch connections were open in a cluster, the agent could send metric samples one round late (30–60 seconds). It now waits only for requests whose response has not started yet, and sends samples on time. The fix applies once the agent in the cluster is updated to 0.79.5.

Last scan on the cluster home page

On the cluster's home page, just above the Alerts section, the result of the last scan appears as two lines: the result itself on top, the detail below, with the sea scene beside it. Clicking the line opens the scan report in Monitoring. If no scan has run yet, or you are not permitted to view scans, the line does not appear.

The scan line on the overview now has two lines

The last-scan line on the overview now has two lines: the result itself on top (such as The cluster is healthy or There is a critical issue), and the detail below. With no issues it reads "No issues observed."; with findings it shows the most important finding and how many more there are. The sea scene also grew on this line; on narrow screens the scene is hidden and the two lines remain.

A nautical chart on the setup screen

The first-run setup screen now has the same faint nautical chart background as the sign-in and password setup screens. The background is the same on every setup step, from the account form to the final screen. With reduced motion turned on in the operating system, the drawing stays still.

Anomaly close notifications state the reason

When you close an anomaly with “Close as expected”, the closing notification sent to the channel now says so. Email and chat channels (Slack, Teams, Google Chat) show the line “This alert was closed after being marked as expected behavior.”; the HTTP hook body (ITSM, etc.) gains an optional "resolution": "expected" field on that entity. When YEKE itself closes an alert the body is as before, without the field. The name of the person who closed it is not sent to the channel; it stays in the audit log.

The agent sends measurements on time

The agent now stamps sample frames with their send time instead of the capture time. On clusters where the agent sent frames late, the clock skew could wrongly show ~30 s and charts were drawn one step off; updating the agent removes this. No change to the database schema.

Sea scenes in scan results

At the top right of a scan result there is now a sea scene that changes with the outcome: a ship in harbour when there are no issues, calm seas when there are only informational notes, choppy or rough weather for warnings, and a storm for a critical finding. If measurements are missing or the scan could not finish, the scene turns to fog. A small version of the same scene also appears in the scan row on the overview and in the scan card in chat. If reduced motion is turned on in the operating system, the scenes stay still.

When nothing is wrong: “Cluster is healthy”

When a scan finds nothing, the result now says Cluster is healthy, no issues observed; the email and HTML report also say “no issues observed”. A series that is largely complete, with the latest sample fresh, no longer counts as a finding just because a few samples are missing; cases where the collector was genuinely blind are still reported as warnings.

Anomaly alerts: “Expected behavior” now closes the alert

On the Alerts tab of the monitoring page, marking an anomaly with “Close as expected” closes the alert and stops its notifications. As long as the value stays at that level the same alert does not reopen; if the value changes noticeably, the rule fires again. This recognition lasts at most 14 days, by which time the profile has learned the new level anyway. “Undo” removes the mark: the alert stays closed, and if the value is still unusual a new alert opens. Previously the mark was only a feedback record and the alert kept firing.

• CPU and memory anomalies now fire only when usage rises above normal; dropping below normal (a new release, lower load) no longer raises an alert. Such alerts that are still open close on their own at the first evaluation after the upgrade. Administrators can choose the direction on their own rules (above only, below only, both).
• Marking and undoing are written to the audit log.
• When the connection drops and comes back, the measurements the agent kept are now written at their own times; previously they shifted to the time they were received and the whole disconnection remained a gap in the chart.
• Database schema advances (v64): a nullable column is added to alert records and applied automatically on upgrade. Going back to an earlier release requires restoring the database backup taken before the upgrade. No change to the agent.

Monitoring: lost measurements only within the selected time range

When the agent loses its connection to YEKE, it keeps measurements on its side; once that space fills up the oldest are deleted and the chart shows a gap. The warning chip on the monitoring page now reflects when that loss happened: it appears only if there was a loss within the selected time range (Live, 1h … 90d) and states the lost duration (e.g. “10 min of measurements lost”). Hovering shows where the lost range starts and ends. Previously the chip showed a count accumulated over the cluster's whole life and never went away once a cluster had been disconnected.

• The password setup screen now has the same nautical chart background as the sign-in screen.
• Database schema advances (v63): a small table recording when measurements were lost is added and applied automatically on upgrade. Going back to an earlier release requires restoring the database backup taken before the upgrade. Losses from before this release have no recorded time and do not appear on the chip. No change to the agent.

Values in the monitoring table are fully readable

In some browsers (Safari) the values in the CPU, memory and disk cells of the node table were cut off at the cell edge; they now show in full. When both sides share a unit it is written once (e.g. 12.6 / 17.1 GiB), so the table also fits on narrower screens. The network column shows numbers only.

Bars on the overview cards

The CPU, memory and disk cards now show a fill bar with a threshold notch instead of a ring gauge; the percentage is written next to the bar.

A nautical chart on the sign-in screen

The sign-in screen now has a faint nautical chart behind it: a chart grid, a compass rose and a dotted course passing behind the card. Only the dots of the course drift slowly; with reduced motion turned on in the operating system, the drawing stays still. The drawing ships inside the page, so no separate image is downloaded.

A container ship on the home screen

In the sea scene on the cluster list, a container ship has taken the place of the sun. The ship rolls gently between the waves, and now and then the containers in its load lift off one by one and a new one settles in, like a rolling update. With reduced motion turned on in the operating system, the scene stays still.

Node usage at a glance on the monitoring screen

The node table has colored usage bars for CPU, memory and disk (green, yellow, red), using the same thresholds as the attention list. Network shows a small trend line.

Pressure and Processes in separate columns

Pressure and Processes are now separate columns, each with an info button explaining what it measures. Pressure is the share of time processes spend waiting for CPU, memory or disk, and the resource being waited on is shown next to it. If no node in the cluster reports pressure, the column is hidden.

Ring gauges on the overview cards

The overview cards show a ring gauge with threshold ticks. Values fill in gently on load; with reduced motion turned on in the operating system, there is no animation.

A calm sea on the home screen

The sea scene on the cluster list is simpler: the wheel and the tiller are gone, leaving the horizon, the sun and slowly moving waves. With reduced motion turned on in the operating system, the waves stay still.

Token link in its own box on the sign-in screen

The password setup link now sits in a separate box below the sign-in card: Have a token? Set your password. Users without an account, or who forgot their password, ask their administrator for a token.

PostgreSQL install: the license is entered on the setup screen

An Enterprise (PostgreSQL) install no longer needs a license file: the docker run command takes only the database address and the snapshot key, and you paste the signed license block on the setup screen together with the first administrator. The license is kept in the database; renew it from Administration → System → License (Installation → Enterprise).

• Managing the license as a file stays optional (GitOps, high availability); when a file is provided, the setup screen doesn't ask for a license.
• On a PostgreSQL install the license can't be removed, only replaced with a new license that includes ha-postgres. An expired license doesn't lock anyone out.
• On a YEKE that hasn't been set up yet, signing in with LDAP or OIDC no longer creates an account; the first administrator is created on the setup screen.

One-command install, settings in the UI

Installing is now a single docker run; there is no compose or .env file. The settings you change after install live in Administration → System → System settings, not in environment variables.

• The Community command takes only a port and a volume. The Enterprise (PostgreSQL) command takes the database address, the snapshot key and the license file; both are on the Installation page.
• A new install starts on HTTPS. If you don't provide a certificate, YEKE issues one for the address you enter during setup, signed by its own CA, and that CA can only sign for that address. Download the CA and trust it to stop the browser warning, or upload your own certificate.
• After the first administrator, setup has one more step: address and certificate. The address is pre-filled from your browser.
• System settings: public address, certificate, internal CA, outbound allow-lists, session lifetimes, API token policy, MCP, Secret display, retention periods and AI. Only the owner can change them; other administrators can see them. Changes apply without a restart, and a setting the deployment passes as an environment variable shows as locked.
• If you save a value that locks you out of the UI, the recovery tool in the image puts it back (Installation → Locked out by a setting).
• Existing installs behave the same after the upgrade: an install serving plain HTTP stays on 8080, and environment variables keep working.
• Security: on some paths containing percent-encoded characters the authorization check could be bypassed; fixed. We recommend upgrading every install to this release.

Approval card: dotted keys now show their before and after values

In the "What will change" table on the approval card, fields whose key name contains a dot (for example tls.crt and tls.key in a Secret, or app.kubernetes.io/name in a label) now show their previous and new values. Previously both cells of these fields read "absent".

Chat: suggestion last, long explanation folds

When the model suggests a command or a plan, the suggestion card now sits below the explanation; a long explanation no longer pushes the card off screen.

• Shell and pod command cards come at the end of the text, in the same place as plan and approval cards. Short lines saying what was done (theme, screen) stay at the top.
• In an answer that carries a suggestion, a plan or a question, a long explanation folds after its first five lines and opens with Show more. Copy still takes the whole text.
• Answers without a suggestion (diagnosis, lists) do not fold; there the text is the content.
• After your own message, chat sometimes stopped following the answer at the bottom; fixed.

AI max output tokens: local DeepSeek models stay on the safe side

The provider's automatic output limit (the most tokens a model may produce in one answer) also recognized DeepSeek by the deepseek- prefix in the model name. Local servers such as Ollama use the same names, so a local deepseek-r1 got 32,768 as well. In our measurement Ollama did not reject this limit, but it did not stop when its context filled either and kept generating up to the limit: a long answer could run into the turn's time limit (240 s) instead of being cut off.

• DeepSeek is now recognized only by the api.deepseek.com address and gets 32,768. DeepSeek-named models at any other address stay at 8,192, like other unrecognized models. The context window has followed the same rule since 0.74.3; both settings now share one definition.
• If you use DeepSeek through a proxy or gateway and long reports get cut off, choose 32,768 from the Max output tokens menu in the row under Administration → AI providers.
• If an install-wide output limit (YEKE_AI_MAX_OUTPUT_TOKENS) is set, nothing changes; that value takes precedence over the automatic one. No changes to the agent or the database schema.

AI provider context window: shown correctly, chosen in the UI

The size of the resource type list that chat sends to the model is limited by the provider's context window. Records without a declared window stayed at 8,192 until now, which meant the list was shortened even for models with large windows. A window written through the API was not shown on screen either.

• Claude and DeepSeek API records work with a measured value (32,768) even without a declared window; the list can grow about threefold and on large clusters the model sees more resource types. Local and unrecognized models stay on the safe side at 8,192.
• In Administration → AI providers, each row has a window choice under the model: Automatic or a fixed value. Next to Automatic it says where the value comes from (by model or default). The new provider form has the same field.
• The window shown on screen and in the API is the window chat actually uses. A value written through the API appears in the menu as a “custom value”; sending null through the API returns it to Automatic.
• On large clusters requests to the model get bigger: the list is resent on every tool step. With Claude the system prompt is marked for caching.

Chat: the model's question survives a page reload

When the model is unsure it can ask a question with options (“which pod?”). Until now that question lived only on screen: after a reload an empty bubble was left in its place and the options were gone. The question is now part of the chat record.

• After a reload the question and its options are shown again. If the question is the last message of the chat, the options can be pressed; pressing one sends it as the answer.
• The options of an answered question appear as a plain list, not buttons; once the conversation has moved on, an old question cannot be answered.
• On the next turn the model sees its own question and options, so an answer sent by pressing an option arrives with its context.
• Sending your own message or an option scrolls the chat to the bottom and keeps it there while the answer streams in; a large card could previously pull it away from the bottom.
• Two descriptions in the AI settings were corrected: a plan-proposing token can also be connected to MCP, and masking of environment variable values depends on a policy that can be turned off.
• Database schema advances (v61): a nullable column is added to chat messages and applied automatically on upgrade. Going back to an earlier release requires restoring the database backup taken before the upgrade. Questions asked before this release do not come back. No change to the agent.

KubeWorld: district names only on signboards, labels start on

From afar, the map no longer shows district names; with many namespaces and long names these covered the map. The namespace name now appears only on the sign in front of each district. The sign shows up once you are close enough to read its name, and that threshold is the same at every zoom level. Very long names are split into two balanced lines on the sign. The “+N” count of problem callouts that don't fit sits on the sign's corner if there is a sign, otherwise at the district's position; on a crowded map, the districts with the most problems come first. Labels are now on by default; the earlier preference is reset once and remembered again afterwards.

From chat to a pod's terminal

Chat can now suggest a command for a pod's own terminal. When the root cause is inside a container (a config file, a process, a listening port, environment variable names) or the question is “can this pod reach that service”, the card offers a “Run in pod” button.

• The button types the command into the terminal; it does not run it — Enter is yours. If a terminal is already open for the same pod and container, the command goes there; otherwise you first get the approval card for starting a shell in the pod.
• The command runs with the pod's own identity and network position and does not go through YEKE's write chain; the card's info box says so.
• The target is verified when the suggestion is made: if the pod does not exist, is not running, is being deleted, or has several containers and the one meant is unclear, no card appears and the model corrects itself.
• With the Shell tab in the background, “Run in Shell” now brings the Shell tab to the front first; the command is no longer typed into a terminal you cannot see.

Tara: rollout shutdown noise no longer becomes a finding

The rule added to the home page Warnings section in 0.73.7 now also applies to the AI health scan (Tara). A stopping pod's last readiness failure is dropped from event reads before they reach the model, so Tara no longer reports an “It's failing its own health checks” finding for it. The rule has a single source and the home page and Tara run the same code: the failure is hidden only when the same pod already received a “Stopping container” event and the failure started at the same time or later. The extra reads this check needs use the permissions of the user who started the scan; if they fail, the row stays. Chat and MCP keep seeing events unfiltered.

KubeWorld: the district name is on the signboard

Up close, the namespace name is now written on the board of the sign in front of each district. It grows and shrinks with the buildings and stays inside the board. Before, the name was a fixed-size label sitting on the board, so it grew larger than the buildings as you zoomed out and spilled over the board. The board widens to fit the name, so long names such as cattle-monitoring-system are readable at the same zoom as short ones. When you zoom out too far to read it, the board disappears together with its name, so no empty boards are left. District names no longer depend on the Labels button: with labels off they still show on the board up close and on the map from afar. The button still controls problem callouts, host signs and the name of the selected object; up close, problem callouts that don't fit are counted as “+N” at the corner of the board.

Home page warnings: rollout shutdown noise is no longer shown

When a rollout stops an old pod, Kubernetes keeps running that pod's readiness check. The last check after the pod's network is torn down fails with a network error, for example connect: invalid argument or connection refused. This is harmless and can show up on any rollout, so the Warnings section of the cluster home page and its count no longer include it. The rule is narrow: the failure is hidden only when the same pod already received a “Stopping container” event and the failure started at the same time or later. Readiness failures that began before the stop, liveness and startup failures, and failures of a pod recreated under the same name still show. The events list is unchanged and keeps every event.

MCP: description of the cluster inventory tool

The description of the yeke_clusters MCP tool said it takes no arguments, while MCP asks this tool for a clusterId like every other tool. The description now says the result is always the full inventory, so the agent gets the same list whichever cluster it passes. Behaviour is unchanged.

Permission group scope: namespace list when the cluster is unreachable

On a permission group's Scope tab, the “Selected namespaces” list no longer shows “loading” forever when the cluster is not connected or its API discovery cannot be fetched: it shows the reason and a Refresh button. When discovery answers but does not return the namespace resource, the list no longer looks like “No namespaces to choose from”; it says the list could not be loaded, and saved selections are not marked “not found”. Refresh asks the cluster for discovery again.

Log streams refresh when settings change

In the log panel, changing the container, “previous container” or “timestamps” now restarts the stream with the new setting; before, it kept running with the old one. On a pod with several containers, the first container choice starts the stream. Typing in the last lines, last N seconds and byte limit fields no longer resets the stream on every key: when the value differs from what is shown, the Stop button becomes “Apply”, and Enter does the same. In the bottom drawer the log toolbar is more compact, and a focused field's outline is no longer cut off.

SIEM names for API token events

Audit events for personal API tokens now reach the SIEM as “API token issued”, “API token used”, “API token expired” and “API token scope denied”; since 0.70.0 they had been sent as “Read token …”, which read as if they did not cover plan tokens. The event types (auth.token_*) are unchanged. If you have a SIEM rule that filters on the old names, update it to the new ones.

Two error messages in the interface now cover both scopes: when tokens are turned off on the installation the message says “API tokens are turned off”, and when a token attempts something outside its scope the message explains what read and plan tokens can each do.

Terminal stays usable on narrow screens

At phone width, a terminal (Shell or pod exec) opened under a long list shrank to a few pixels, a single line. The drawer now takes most of the screen, as the log tab already did, and the list scrolls in the space that remains. When the screen rotates, or shrinks and grows back, the terminal stays on screen and fits its rows to the new size.

The drawer bar no longer overflows

With a single session open, the drawer bar overflowed sideways on narrow screens and pushed “End session” off screen; a log tab opened with a very long pod name overflowed the same way at tablet widths. The title is now truncated (in the middle for log tabs), and the status label and buttons stay whole.

Long lists keep the page in place

On a long list with status badges or links (for example 40 pods), the whole page became scrollable, and scrolling carried the top bar and the log/terminal drawer off screen along with the list. Now only the list scrolls; the top bar and the drawer stay in place. The screen-reader text in the badges is unchanged, and nothing else looks different.

Pasting a .env

Paste a .env text into a key-value field such as labels, annotations, or ConfigMap and Secret data, and each line becomes its own entry. An existing key is updated, comments and blank lines are skipped, and the result is stated in one line (“3 added · 1 updated”). The container's env list has the same box; type KEY=value and press Enter to add a single variable. A variable whose value comes from a Secret or ConfigMap is left alone. Multi-line values in quotes (a certificate, for example) are read as one value.

Container tabs

In workloads with more than one container, each container opens in its own tab. The tab shows how many fields are changed, missing, or invalid, and the error marker opens the right tab. Reordering and removing sit on the same row.

Faulty lines in YAML

In the YAML tab, a line with a syntax error is marked in red. A field that is not in that kind's schema (for example replicaz) is shown in yellow before you save; below the editor it says which field is on which line, and clicking jumps to the line. Saving is not blocked, and the final check is still Kubernetes itself. Free-form areas (labels, annotations, the free-form parts of CRDs) do not raise false alarms.

One-step MCP setup on the account page

The “Use with MCP” section that appears after you create a token is simpler and half as tall. Claude Code and Codex have tabs; you copy one snippet for the selected client with the token already in it, with no separate environment variable step. The Claude Code command installs at user scope (--scope user) and writes the token to ~/.claude.json in your home directory; it leaves no file in the project folder. The Codex snippet goes into ~/.codex/config.toml and carries the token in http_headers.

Log tabs in the bottom drawer

The log tab's bar is simpler: the cluster and namespace line and the “live” chip are gone, since each tab's title and status dot already carry that; cluster and namespace show when you hover over the tab. The selected tab stands out with a blue border. With many tabs the bar no longer wraps to a second line: the tabs scroll sideways and the Minimize and Close buttons stay on the right. For pod names that share a prefix, the tab label is shortened in the middle so the part that tells the pods apart stays visible. With several logs open, the bar's “Close all logs” button closes every log tab; the Shell and pod terminals stay open. The number fields in the log toolbar match the buttons' height and no longer have spinner arrows.

The create form fills in from the name

When you create a new Deployment, DaemonSet or StatefulSet, typing the name fills in the app label, the selector, the pod template label and the first container's name on its own; for a StatefulSet also serviceName, and for an Ingress the backend Service name. These fields are marked “bound to name”. A field you edit by hand leaves the binding; Revert puts it back. Changing the name in the YAML tab updates the same fields.

Presets

Job and CronJob open with restartPolicy: Never, a PVC with ReadWriteOnce, an Ingress with the / path; a Service comes with a single port row. Secret has type suggestions: for the TLS, basic-auth, SSH and registry types the keys they need are ready as empty rows.

Create from context

A workload's menu has “Create Service”, and a Service's menu has “Create Ingress”. The selector, ports and backend come filled in from the object itself; it is still applied with a single approval.

Smarter copy

In a copy, values derived from the name move to the new name; values that point at another object (a Service selector, an Ingress backend) stay as they are. Fields the cluster assigns (such as clusterIP, nodePort, volumeName) are not carried into the copy.

Draft is kept

With unsaved changes, clicking outside the window or pressing Esc does not close the editor; it asks “N changes will be discarded”.

Readability

Missing required fields are counted per section (name and namespace included). When the namespace is empty, the plan button says why. List items can be collapsed and the row order is fixed.

Plan token

Creating a token on the My account page now asks for a scope: “Read” or “Propose plans”. With a plan token, an external system or your own AI agent can build a change plan but cannot apply it. Plans are proposed over REST with POST /api/clusters/<id>/operations and over MCP with the propose_operation tool; the response gives the link to the approval card in YEKE. You open the card, review the plan and approve it in YEKE; apply, refresh, cancel and revert are closed to the token. The approval card says which token proposed the plan and whether it came over the API or MCP; the model's or client's note shows separately, labelled “Model's summary” or “Client's note”. When the same token proposes a new plan for the same cluster, the pending older one is cancelled and the new one replaces it; use separate tokens for parallel changes. Each token can make at most 10 proposals a minute (REST and MCP share the budget). The MCP tool returns no values: it returns the paths of the changed fields, the approval level and the card's link. A plan that is not approved expires after 30 minutes. Details: API and MCP.

ops.nl-strict now covers plan tokens

When the built-in ops.nl-strict template is turned on, elevated approval now applies not only to writes from chat but to every write proposed with a personal plan token (REST or MCP). New policy context field: op.origin, the plan's origin, e.g. "TOKEN". Details: Policies.

Logs in the bottom drawer

Logs in a pod row's action menu no longer opens a separate window; it opens as a tab in the bottom drawer where the Shell lives. You can follow several pods' logs at once in separate tabs, side by side with the Shell and pod terminals. The list stays visible, and the log tab stays open when you move to another page. If the pod is deleted the tab stays too: the stream ends and the last lines remain on screen. Opening the same pod's logs again does not open a second tab; it brings the open one forward. Live follow now starts at the newest line, and scrolling up keeps your place while new lines arrive.

Log download

The Download menu in the log panel has two options. “Download what's shown” saves the text you see in the panel as is. “Download full log” fetches the log again from Kubernetes with no line, time or byte limit; your container, previous-container and timestamp choices are kept, and the file is written raw (colour codes included). While it downloads you see how much has arrived and can cancel. If Kubernetes returns an error, no file is saved and the error shows in the panel. “Full” means what the Kubernetes log API serves: older log files that were rotated on the node are not included (same as kubectl logs).

MCP setup command no longer writes the token into the configuration

The Claude Code command in the “Use with MCP” section of the My account page no longer makes Claude Code store the token in plain text in its configuration: the header is in single quotes and given with --scope project, and the YEKE_MCP_TOKEN variable is expanded in .mcp.json at run time.

Personal read token

“Create read token” on the My account page lets scripts, dashboards and automation use YEKE with your permissions, but read-only. The token passes only GET and HEAD requests; writes, the Shell and admin endpoints are closed to it whatever your role. Secret values come back at least masked, regardless of the installation's setting. You choose its lifetime when you create it (30, 90, 180 or 365 days); the installation can lower that ceiling or turn token creation off. Each token has a per-minute request limit. The value is shown once; the token sits in the same list as your open sessions and is ended there. Changing or resetting your password also revokes your tokens. Read responses carry a link to the object's or list's YEKE screen in a Link header; the body is unchanged. Details: API and MCP.

MCP server

YEKE now also provides an MCP server: with your own Claude Code or Codex subscription you can read the clusters connected to YEKE and diagnose problems. The agent uses the YEKE chat's read tools with the same masking: objects, events, logs, metrics, operations and the audit record. Reads run under your Kubernetes identity and every read lands in the audit trail. The server is off by default; an administrator turns it on, and only clusters that allow AI data egress can be read. MCP cannot write: not to the cluster, not to YEKE's own settings. The agent tells you which screen a management task belongs on, and you do it in the interface. When MCP is on, the My account page shows copyable setup snippets for Claude Code and Codex under the new token, titled “Use with MCP”; the snippets do not carry the token value, which is read from an environment variable. For installations behind an internal CA, the yeke mcp relay ships with YEKE CLI 0.5.0.

Chat link

An alert e-mail or an ITSM ticket can open a cluster's chat with text already in the box through a /clusters/<id>?chat=<text> link. The link never sends the text itself: sending is your gesture. Text you have already typed is not overwritten, and a label above the box says the text came from a link.

Scaling in the actions menu

Scaling no longer opens a separate dialog: it now happens in a single row inside the actions menu. Type the replica count or nudge it with the − / + buttons. The arrow button (or Enter) builds the plan, and the approval card opens as before. When your draft differs from the live value, the live value is shown under the row. If the plan is rejected, the reason appears right in the menu and your number stays put.

Fix

In Compose installations, the YEKE_SECRET_DISPLAY setting now reaches the container. Before, it was not applied even when written to the .env file.

Deep links: a single operation and SSO sign-in

An operation's approval card can now be opened from a link: /clusters/<id>/operations?op=<operation-id> opens the plan in the card and filters the audit trail to that operation. If the operation does not exist or you have no access to it, the page shows a warning instead of silently doing nothing. Together with object links (/clusters/<id>/r/apps.deployment/obj?name=…&namespace=…), these addresses are now stable: an ITSM ticket or an alert e-mail can link to them directly.

Signing in with SSO (OIDC) no longer loses the link's destination. A signed-out user who arrives through an object or operation link and signs in with SSO now returns to that destination instead of the home page. Local sign-in already did this.

Operation source is set by the identity channel

The source of an operation plan (op.source in policies) is no longer taken from a claim in the request body; it is set by the identity channel the request arrived on: a request with a browser session is ui, and every request with an API token (Bearer) is api. Policies written by source (for example, a separate approval card for writes coming from the API) can therefore no longer be sidestepped by writing a different value in the body.

For API users: the source field in the body of POST /api/clusters/:id/operations is now optional; if given, it must match the identity channel, otherwise the call returns 400 INVALID_OPERATION. The YEKE CLI and the web interface are unaffected. op.source is an origin label, not a security boundary; in policies, use it to tighten approval, not to loosen it.

Shell notifications reach only the user who ran the command

The approval card and the “applied” notice for a write made from Shell (kubectl) now go only to the open tabs of the user who ran it. Previously, another user with Shell open on the same cluster could see an approval card they could not apply, and the write was counted in their strip; operation IDs and state changes also streamed live to every signed-in browser. There is no exception for admins; other users' operations remain visible on the Operations page.

“Update agents (N)” on the home screen opens an approval card for each cluster in turn. The card's heading now shows which cluster you are approving and its place in the queue (e.g. Cluster prod-eu 2/5). Until this release the name appeared only at the start of the note in the card body, and not at all on the loading and “plan could not be built” cards.

• The name appears on all three cards: loading, approval/result and error.
• When a single cluster is updated with “Update” on its row, only the name is shown, with no position.
• Screen readers announce the card with the cluster name and position.
• The note in the card body no longer repeats the cluster name.
• No database migration.

Anomaly detection is live (Enterprise)

• The four built-in anomaly rules moved from shadow mode to live (node and workload × CPU and memory). They had been running in shadow mode since 18.09. There's no fixed threshold: when CPU or memory departs from its own time-of-day normal over the last 14 days for at least 60 minutes, an event opens; nothing fires until 7 days of history have built up.
• Events now count toward open alerts on the Monitoring → Alerts tab, are written to the audit trail (alert.fired) and go to SIEM targets whose Scope includes the “operation” class.
• Severity is “Info”; an event reaches a notification channel only through a route whose Minimum severity is “Info”. A route that picks the rule by name but is set to “Warning” doesn't receive it. The built-in rules have no default route.
• On upgrade, your settings on the built-in rules (enabled/disabled, severity, minimum duration, resolve duration) are kept; shadow events open at that moment close as shadow events. Installations that already have an “Info” route start receiving anomaly notifications right after the upgrade.
• Shadow mode stays selectable for anomaly rules you write yourself. Details: Alerts.
• No database migration.

GitOps repo reflection and drift

• Objects are matched independently of the API version (group, kind, namespace, name). If the repo declares an object with a different API version (for example an HPA as autoscaling/v1 while the change comes from v2), the card no longer says “not declared”; it names the file and both versions. Because field paths differ between versions, the change is not written to the declaration; deletions and label/annotation-only changes are written. Drift also measures with the declaration's own version.
• Plain manifests that contain {{ … }} (for example PrometheusRule alert templates, Grafana dashboards) are no longer mistaken for Helm templates and no longer drop the scope. Only files in a Helm chart's templates/ directory, or files that cannot be read as YAML, count as templates.
• Resources such as Flux Kustomization and Dapr Component are no longer mistaken for kustomize files; they are read as declarations.
• When a kustomization above the scope sets the namespace (the namespace: field), drift and the card now take it into account. The “namespace could not be resolved” results seen when a binding was narrowed to an application directory, and the false “missing” rows that appeared when the file's own namespace was overridden, are gone. If base and overlay give different namespaces, the outermost valid one wins, as in kustomize.
• In repos that use kustomize, the card now says “not in the repo” for an object that truly has no counterpart; before, it said “layout not supported”. This answer is given only when the repo could be read completely. If there is a name-changing transformer, a generator or an unreadable file, the card says “could not look”, not “not there”.
• An older copy of the same object that is outside the build no longer disturbs the conflict warning, the container deletion or the reference check.

GitOps repo reflection

• A declaration file that is not part of the build is now named. If the file being edited does not enter the kustomize build, the card says which kustomization's resources: list the file needs to be added to. Before, the card only said “the kustomize build broke the edit”.
• When two files define the same object and only one enters the build, that one is chosen. Older copies outside the build no longer abort the reflection.
• A “Declaration files outside the build” list in the drift window. It shows files that sit in the repo but that kustomize does not read, the objects inside them, and whether those objects exist live. Directories never reached from the root and commented-out entries count as deliberate exclusions and are not listed. If the list is empty, the section does not appear.

GitOps repo reflection

• Scaling is now reflected to the repo. For Deployments, StatefulSets and ReplicaSets, the replicas line of the declaration in the repo is updated. Before, the card reported this action as “not in GitOps scope”.
• Strategic-merge patches produced by the AI chat are reflected too. The change the server computes in a dry-run is written to the declaration.
• Fields written by the server and by tools no longer abort the reflection. This includes fields such as last-applied-configuration and the restart timestamp. An action that changes only these fields, for example Restart, produces no commit in the repo.
• The “Repo value differs from live” warning now also appears for repos that use Kustomize and points to the declaration file. The comparison is made against what Kustomize renders, not the raw file; transformers such as images: no longer produce false warnings.
• Subresources such as status and eviction, and CRD scaling, are still not reflected; the card says so by name.

The key that verifies license signatures is now part of the product itself and can't be changed through installation settings. Valid licenses keep working as before; there's nothing to do when you upgrade.

• No database migration.

Windows now work fully with the keyboard. When a window opens, focus moves into it, Tab and Shift+Tab stay inside it, and when it closes focus returns to the button that opened it. Until this release focus stayed on the page behind and Tab walked through the buttons under the backdrop.

• On open, focus lands on the window itself, not on a button such as “Approve”, so an accidental Enter does not approve anything.
• With a window open on top of another, Escape closes only the top one. Previously the one underneath closed and the top one stayed on screen.
• The navigation menu follows the same rules.
• No database migration.

The page behind an open window or the navigation menu no longer scrolls. Until this release the keyboard (PageDown, arrow keys, End) or the mouse wheel could scroll the list behind an open window, so closing it left you somewhere else on the page.

• When a window closes, the page is where you left it.
• Content does not shift sideways or up while the scrollbar is hidden.
• Long windows and the menu still scroll their own content.
• No database migration.

Validation hooks moved to Enterprise. Validation hooks, which ask your own system (ITSM, change board, maintenance window service) at plan and approval time, are now part of the Enterprise license's itsm item. Notification hooks (HTTP, email, chat channel) keep working exactly as before in every edition.

• Validation hooks already set up keep running without a license and keep stopping changes when they need to. They can be turned off and deleted; a new definition, a rule change or turning one back on needs a license.
• Validation hooks defined in files (YEKE_HOOK_DIR) are recorded on the first start after the upgrade. On an installation without a license, a new or changed validation hook file stops core from starting.
• The screen does not hide a hook that is already set up: the row carries the “Enterprise” chip and its status, and Turn off and Remove stay available. On a new hook the validation option is visible but cannot be selected.
• No database migration.

Details: Hook integration.

When a license gate stops core from starting, the refusal is now written to the audit trail on PostgreSQL installations too. Until this release, on an installation running on PostgreSQL, core could exit without writing the license.limit-hit event when it refused to start over a feature its license doesn't cover. SQLite installations did write it.

• Refusals where the loss was measured: every refusal in central policy mode, and the file-mode constraint gate's refusal on restarts after the constraint had been recorded.
• Before exiting, core waits at most 5 seconds for pending audit writes. The refusal itself and the exit code are unchanged.

In file mode, dual approval and maintenance windows now depend on the license. Until this release, requireSecondApproval rules and freezes: windows in file mode (YEKE_POLICY_DIR) went into force without a license check; the license gate existed only for the central package.

• On a start whose license doesn't cover the feature, core refuses to start if it finds a rule or window that isn't in the record or has changed; the message names the rule and the license feature it needs.
• Recorded rules and windows stay in force when the license is removed or expires. Removing them from the files is always allowed.
• Upgrading: on the first start after the upgrade, the rules and windows in an existing installation's files are recorded once. A Community installation that uses these fields keeps starting; only a new definition or a change needs a license.
• Central package mode is unchanged.

Details: Governance.

Monitoring: a CronJob's runs are one workload, a single run's history is 48 hours

• A CronJob's runs are now a single workload. The agent also reads the owner of the Job a CronJob creates, and the CronJob's pods are attached to the CronJob. In the Workloads list of Monitoring the CronJob shows as one row; previously every run opened its own workload row.
• A single run's history is 48 hours, like a pod. A workload owned by a Job (standalone Jobs, and runs on clusters whose agent has not been updated) is not moved into the long-term tiers: it is visible for the last 48 hours and not visible in ranges of 7 days and above. The long-term copies of these records are deleted in the core's first maintenance pass and the metric store shrinks. On PostgreSQL the freed space does not return to the file system right away; new writes reuse it.
• The alert row goes to the CronJob. The link in the alert of a pod owned by a CronJob opens the CronJob's page.
• A workload's last-seen record is now updated on every collection; the maintenance worker ages the record correctly.
• Update the agent: this behavior requires an updated agent. “Update agent” grants the read permission it needs along with the image (batch jobs, list/watch, metadata only). With the old role that lacks the permission, monitoring keeps working; runs appear as Jobs as before.

Monitoring: CPU throttling measures time actually throttled, deleted objects drop off the list

• CPU throttling now tells you how much of the time a container was actually throttled. The old ratio only looked at the moments the container was waiting for CPU, so processes that wake up rarely and do a short burst of work (exporters, for example) could show “70% throttled” while using 1–2% of their limit, and raising the limit often did not make it go away. One example: a container with a 50m limit using 0.8m showed 77% under the old measure; the share of time it was throttled was 1.3%.
• The needs attention list looks at the last 15 minutes: a pod is listed only if it sat at its CPU limit for at least roughly 25% of the last 15 minutes. One-off short peaks, such as a two-minute startup load, no longer show; frequent or sustained throttling does. This is a starting threshold; it has not yet been tuned against real usage and may change.
• Deleted pods, nodes and PVCs drop out of the places that show “now”: the needs attention list, the pod count and throttling column on the Workloads tab, the AI scan and the monitoring tool in chat. A deleted pod disappears within 3–4.5 minutes; previously it stayed for the whole selected time range (7 days, for example). If the agent connection drops, the list does not empty. Past scan records stay as they are — a record of the moment they were made.
• Fix: on clusters with more than 200 pods the needs attention list only looked at the 200 pods using the most CPU, so pods with small limits could be missed. It now looks at up to 1000 pods.
• Update the agent: the new measure is produced by agent 0.62.0. Until a cluster's agent is updated, the monitoring page does not show CPU throttling and says so in a one-line note. Upgrade it through the usual “Update agent” flow.

Alerts: the built-in “CPU throttling” rule moved to the new measure (Enterprise)

• The built-in rule uses the new measure automatically and looks at the same 15-minute window as the needs attention list. Your routing and silence settings are kept; incidents opened under the old measure close on their own.
• Rules you wrote yourself: rules using the old “CPU throttling (old agent)” metric get no data once the agent is updated. Rewrite them with the new “CPU throttling” metric.

KubeWorld: labels are off by default

• KubeWorld opens with labels off: at first glance the city has no text; problem markers, the selection and the side panel stay. The Labels button brings back district names and problem callouts.
• Your choice is still remembered: turn labels on and this browser keeps them on next time. A choice made in earlier versions is reset once, so everyone starts from the new default.

KubeWorld: the city uses the whole page

• The title above the KubeWorld page is gone; the city takes that space too and fills the rest of the page height. The page scroll seen in a 1024×768 window is gone too.
• The way back to Monitoring is at the far left of the toolbar: the Monitoring button takes you back with your selected namespaces kept. It is also there while the city loads or cannot be shown; in full screen it is hidden.
• Fix: on clusters with many problems the Problems list on the right stretched the page downwards and added a second scrollbar; the list no longer lengthens the page.

Monitoring: you enter KubeWorld through a preview band of the city

• The plain “KubeWorld” button in the Monitoring header is gone; in its place is a wide preview band cut from the KubeWorld city. It fades into the background on the title side and sharpens towards the right.
• The whole band is clickable; its right end reads Enter KubeWorld.
• The band is a light image and does not hold up the page: KubeWorld itself loads only when you enter.

KubeWorld: traffic finishes its route, buildings closer to the first drawings

• Vehicles and mail carriers are no longer reset when data refreshes: each one finishes its route and disappears at its end (the exit, the target gate, the mailbox); new ones appear only at the start of a route. Vehicles on the road move at one speed, so no queues form.
• Buildings and rooms are closer to the first concept drawings: framed, curtained windows, flower pots, floor bands, doors with awnings; the bank has columns and floor numbers, the workshop a pitched roof, the clock factory a saw-tooth roof. The eight room states are told apart by shape at window level.
• The limit is unchanged: traffic is still an estimate; vehicle speed carries no data. The numbers on the bank are its floors, not pod identities; the clock is decoration, not schedule information.

KubeWorld: services are mailboxes, in-cluster traffic is mail carriers

• Services are now mailboxes instead of bus stops; a service with no pods behind it is a locked mailbox.
• In-cluster service traffic is carried by mail carriers instead of buses: a mail carrier on foot for light traffic, a bicycle courier for heavy traffic. They walk the sidewalk and deliver in front of the receiving building.
• Vehicles no longer pile up at toll gates or on the road; problem callouts on the map are limited by screen area, and the ones that don't fit fold into a “+N” badge on the district sign.
• The limit is unchanged: traffic is still an estimate; a mail carrier shows local delivery, claims no measured service-to-service flow, and a road that isn't measured has no moving carrier. Details: KubeWorld → Traffic.

KubeWorld: the chip for a cut metrics list is corrected

• On very large clusters (1000+ pods), when the metrics list is cut, the toolbar chip now says the right thing: “N pods without metrics”. Every pod is on the map; only its CPU, memory and network values are missing. The previous text said these pods were not drawn.

KubeWorld: see the cluster as a living city

• A new "KubeWorld" button in the Monitoring page header opens the selected cluster as a city. District = namespace, building = workload, room = pod, power plant = node; toll gate = entrance rule, bus stop = service, depot = volume claim. Trouble shows itself by shape: a crash-looping pod has broken glass and a fire engine outside, a Pending pod is under scaffolding, rooms fed by a NotReady node lose power. The sky tells you the cluster's state; a dark cloud over a district marks where a critical problem is.
• The side panel says why for every mark. The selected object's reason, the problems and waiting lists, and an Operations card summarising YEKE operations awaiting approval and those from the last 24 hours.
• Traffic is an estimate. Vehicle density comes from the measured network intake of the pods at the end of each road; service-to-service flow is not measured, and a road that isn't measured has no vehicles.
• "Save" downloads the current view as a PNG at 2× resolution or more; "Labels" turns the map's text off. The cluster name and time are not written into the image. No license required. Details: KubeWorld.

Silences can be edited in place; the "Silence" shortcut now starts narrow

• On Administration > Alerts > Silences, every row now has an "Edit" button. The reason, scope and dates can be rewritten; the same record changes, no new one is opened. The table now shows who edited it and when, with the exact time on hover. The Written by column now shows a name instead of the user's id.
• The "Silence" window on Monitoring > Alerts now asks for a scope. The default silences only that alert's own target — for a pod, that means the pod's owning workload (e.g. "checkout · Deployment/api"), which stays valid even if the pod restarts. For a pod whose owner can't be resolved, the silence narrows to that pod; for a workload, node or volume alert, to itself. The second option is the old behavior: "all targets on this cluster". A cluster-level alert has no scope choice, since it already covers the whole cluster. Because a CronJob's pod is owned by that run's own Job, "this workload only" silences just that run on a CronJob; the window says so.
• The silence table's Match column now spells out the scope — "all targets" or namespace · Kind/name — and no longer overflows horizontally on a narrow (1280 px) screen.

"All clusters" means one thing for alert routes and silences

• An alert route or silence can no longer be saved with a "*" cluster. For these two records, "all clusters" means leaving the cluster field empty (which is what the UI already does). A record written straight to the API with "*" showed as "All clusters" in the admin screen but applied to no cluster at all; such a request is now rejected.
• A route or silence saved that way earlier now shows as * in the list, not "All clusters" — its behavior is unchanged, the screen just describes it correctly. Delete it and recreate it with the cluster field empty. Selecting "all clusters" on alert rules and maintenance windows works as before.

Silence visibility on the Alerts tab

• On the monitoring page's Alerts tab, a silenced alert is now marked with a "Silenced" label. Hovering it shows until when notifications are held back; the "Silence" button no longer reappears on a silenced row. The alert itself still fires and its status still changes — only the notifications are held back.
• On Administration > Alerts > Silences, what each silence targets is now visible. Previously only a count and a raw id were shown; now the rule and cluster names, the target type, and the name/namespace selector are shown. Long lists are truncated, with the full text on hover.

A restore from the History tab refreshes without a page reload

• After a restore is applied, the History tab stays put; the list and the comparison refresh without a page reload. A new "Restore (from rN)" row appears at the top, the selected version is kept, and the comparison shows the result by saying "Current state already matches rN". This applies to every applied Secret change made while on the History tab — including an edit made from the Data tab.

Four fixes in the Secret History tab

• The "Recreated" divider now sits under the right row. It used to be one row too high, which made it look like it was separating the delete row from the new object; it now sits under the new object's first version.
• Opening a deleted Secret's history now selects its newest version with content. "Recreate from rN" is usable right away, with no need to pick another version first.
• Row-level "Restore"/"Remove" are disabled while the Secret is gone from the cluster, and the table says why. The buttons come disabled; one line under the table explains that a deleted Secret can only be recreated as a whole.
• "Object not found" now shows once. In the History tab, this used to repeat three times.

Silence an alert for days, weeks or longer

• New durations in the Silence dialog: 1 day, 1 week, 1 month, 1 year. The longest option used to be 24 hours, so a known condition lasting days, such as a node under maintenance, had to be silenced again every day. A month counts as 30 days and a year as 365; silencing for a few hours or until a set date stays in Administration → Notifications → Alerts → Silences. A long silence can be ended early there at any time by deleting it; a reason is still required.
• Roomier Silence dialog. The reason, duration and buttons are now spaced apart, and the buttons sit on the right as in other dialogs.

Secret versions: every YEKE write is a record, an outside change is caught on the next one

• New "History" tab. Every version on a Secret's detail page is listed as rN plus a date/time (with an accessible name like "Revision 7"); a source tag says how that version came about: First record, Outside YEKE, Interface, AI, API / shell, Revert, Restore.
• A change made outside YEKE is caught on the next YEKE write. There is no continuous watch — a change made through something like kubectl is recorded as "Outside YEKE" the next time YEKE itself writes to that Secret (lazy detection; see Limits below for what that means in practice).
• Restore a single key or the whole Secret to an earlier version. "Restore" row by row from the diff screen, or "Restore all to rN" — both go through an approval card and never write straight to the live Secret.
• Recreate a deleted Secret from its history. The "Deleted Secrets" view links into the History tab; picking a version there and choosing "Recreate from rN" recreates the WHOLE Secret (not a single key) — it requires Secret write access and gets a new object/uid.
• History is stored encrypted and respects the display ceiling. It uses the existing envelope mechanism and can't be read from the DB directly; while YEKE_SECRET_DISPLAY is masked/hidden, a "blind restore" is possible — restoring by knowing which keys changed, without seeing the value. A user with key-level access can only change a key that already exists, not add or remove one.
• Retention defaults to 90 days / 50 versions. YEKE_SECRET_VERSION_RETENTION_DAYS (default 90) and YEKE_SECRET_VERSION_MAX (default 50, per Secret) make it configurable; the highest-revision head row is never deleted, only its content is dropped once it ages out.
• E6's fourth item. secret-versions joins secret-display/secret-keys/effective-access — Access and Secret management. See the Secret versions page for how to use it.
• Limits. No key rotation (older versions can't be opened if the encryption key changes); lazy detection catches only the LAST of several outside changes made between two YEKE writes; history starts from the first time YEKE wrote to that Secret; Helm's own release Secrets are out of scope (use helm rollback instead); restoring never changes a Secret's type, only its data; if the license lapses, recording stops and reading/restoring closes, but existing records aren't deleted until retention expires; an existing Enterprise license does not unlock this item on its own — it needs a license re-signed with the secret-versions name.

Monitoring only on workloads; the Secret page opens without an error flash

• Monitoring only on objects that have pods. It stays on Deployment, StatefulSet, DaemonSet, ReplicaSet, Job and Pod details and no longer appears on objects without pods such as ConfigMaps and Services. Previously, once a workload's history had been viewed, these pages got stuck on "0 pods measured".
• The Secret page no longer says "not allowed" first. A user who reaches a Secret through a permission group's key rule goes straight to the key table, without a permission error flashing on load. The error appears only when the user really has no key access to that Secret.

Cleaner Secret page for per-key access

• The empty toolbar and the "stream stopped" warning are gone. A user who reaches a Secret through a permission group's key rule reads it through YEKE, not from the cluster; the live stream failing is expected and is no longer shown.
• No monitoring panel on Secrets. A Secret has no pods, so the panel that said "0 pods measured" was removed from this page. The page opens straight on the title and the key table.

Administration menu split into categories

• The Administration menu is now four categories instead of a flat list. Identity & access, Integrations, Notifications, Compliance & audit — License stays on its own, uncategorized. The screens themselves and their permissions are unchanged, only where they sit in the menu.
• Categories start collapsed every time the menu opens. Clicking one expands it, and if another category is already open, it collapses — only one stays open at a time.
• A collapsed category still shows the names of the screens inside it. You can see which screen you're looking for in the Administration menu without opening the category first.

E6 redefined: Access and Secret management

• E6 is now "Access and Secret management". Three items: secret-display (install-wide Secret display ceiling, moved from E3 — behavior unchanged), secret-keys (a permission group's key-level Secret access) and effective-access (another user's effective access view).
• Key-level Secret access for permission groups is now Enterprise. It used to be flagless, i.e. free; from this release it requires secret-keys (E6). The foundation of permission groups — definition, membership, templates, namespace scope, RBAC generation — stays Community.
• The old E6 (managed AI) is removed. managed-ai, ai-policies and ai-audit-report left the dictionary; scim and saml moved to E1 — the names are unchanged, only their phase.
• Existing licenses lose nothing. A license carrying any of the old E6 names is treated as having unlocked all three items of the new E6.

Data tab and key × group access matrix on the Secret screen

• New default "Data" tab. The Secret page now opens a key–value table: values are masked by default, with per-row Show / Copy / Edit and a top-level "Show all", plus adding and deleting keys. Binary and multi-line values are shown separately; a TLS certificate shows a CN and expiry summary.
• The ceiling and key rules still apply. In a restricted display mode Show/Copy are not drawn; editing only accepts a blind write through "New value". Without write access the buttons are disabled and the reason is shown.
• The Access tab is back to a key × group matrix. Each cell picks between Hidden / Can view / Can edit; the "All keys" row writes a rule for every key the group currently has in one step — not a wildcard, a key added later still starts hidden.
• The "New group" button on the permission groups page moved. It now sits in the same place as on the other admin pages.

Secret display: values can be hidden from everyone, owner included

• One environment variable, three modes: YEKE_SECRET_DISPLAY. full (default, today's behavior), masked (a marker that stays the same across equal values, instead of the value) or hidden (no marker either, only key names). An unrecognized value stops core at startup.
• Identity-independent ceiling — everyone, owner included. In a restricted mode the Secret screen draws no "Show values"; instead it shows a mask chip and a per-key "New value" field — blind write: the new value is written without the old one ever being shown.
• Requires the Enterprise secret-display flag. An unlicensed first install does not start in a restricted mode — silently falling back to full would show every value meant to stay hidden. If the license is later dropped, core still starts: the stricter of the previously enforced mode and the environment variable applies, with a warning in the startup log and the UI.
• Boundary: this is a display boundary through YEKE. Reading from inside a pod via exec, a workload that logs the value, or cluster access outside YEKE are all out of scope — Kubernetes authorization itself is unchanged.

Permission groups: build RBAC from the UI, key-level access to Secrets

• A permission group is set up from the UI — with Capabilities, Scope, Members and Cluster status tabs: pick pre-selected Kubernetes capabilities (view, execute, workload/config, node), scope them to one or more namespaces (or all of them), and add members. The "Create RBAC" button is owner-only — the group definition and membership are open to every admin.
• Five ready-made templates: Observer, Developer, Release team, Namespace owner, SRE / on-call. They pre-fill capabilities; still editable by hand afterward.
• A member who joins an applied group leaves the cluster-wide read-only axis. They no longer impersonate yeke:cluster-viewers; what they see is the union of the scopes of the groups they belong to.
• Key-level access to Secrets. The group itself has NO access to Secrets in the cluster; for a group with a key rule, YEKE's Secret screen marks each key individually as View / Edit / Hidden. A key without a rule — including one added later — starts hidden.
• The namespace picker now reads from the cluster. For a user who gets a 403 on the cluster-wide list, the picker fills in from the scope of their own permission groups. Action buttons are gated by permissions read from the cluster and state why; the per-user "effective access" view is also read from the cluster, not from the groups.
• Limits: permission groups only grant, RBAC doesn't add restrictions — the admin role cannot be narrowed by group membership. Redeploying and changing the image cannot be separated in RBAC. In a group that can execute code (shell, ephemeral container, Job/CronJob, workload edit) hiding keys is not a boundary — code running in the pod can already read that Secret.

Alert notifications are now collected, and flapping targets get one notice

• Collection window: 5 minutes per cluster. Alerts that fire in a cluster are collected for 5 minutes and sent as one message for that cluster (email and chat). Critical alerts don't wait — they go out in the same pass.
• The close message waits 30 minutes. If the same target reopens during that time, the close never goes out and the new firing isn't announced either — as far as the channel is concerned, the alert never closed. A close that does go out says "Not reopened for 30 min"; if monitoring was interrupted in between, that's added too.
• A target that flaps open and closed several times is reported once. The close message says how many times it reopened; the Alerts tab shows a "reopened N times" badge.
• A cluster that goes blind (no data arriving) gets a "no data for N min" note on its reminder.
• HTTP hooks (ITSM, etc.): the body format is UNCHANGED, the timing is not: firing arrives ~5 minutes late, closing ~35 minutes late. On a flapping event the id can change — match records by fingerprint instead. Audit logging and SIEM export are not delayed; they stay real-time.
• New default on the hook form: "Only alerts and scan reports" — no operation notifications are selected. Choosing "All operation events" now says it can produce a lot of notifications on busy clusters.

A hook's event choice now asks only about operation notifications

• Alerts and the scan report are gone from a hook's event list. Which hook those two families reach — including the closing notification — was already chosen by alert routing and scheduled scans; the alert.fired/alert.resolved/ scan.report checkboxes on the hook form changed nothing. In their place is a single line linked to the Routing and Scheduled scans tabs.
• A hook's event choice is now limited to six operation notifications: three terminal outcomes (applied, partially applied, failed) and the three gestures of dual consent (requested, given, revoked). Leaving it empty means "no operation notification."
• Existing hook records were corrected by a migration; the notifications they receive did not change — only the ineffective checkboxes dropped out of their subscription.
• Two bugs were fixed along the way: a YAML hook that listed only an alert event was incorrectly subscribed to every operation event; and turning a narrowed hook back to "all events" in the form did nothing.

Server info now lives in a card with bars

• The one-line server strip in the top bar is gone. In its place, below the buttons in the welcome block, there's a card titled “YEKE server”: CPU, memory and disk usage, each with its own percentage and bar.
• The bar's color follows a threshold: green under 80%, orange between 80–90%, red at 90% and above. In the warning and danger bands the percentage is colored too, and it gets bolder in the danger band.
• The card is admin-only and keeps no history. On a wide screen it doesn't stretch the page — it sits in space the welcome block already has. Unlike the strip, it's also visible on narrow screens.
• If the container has a memory quota, a second “Container” bar appears under Memory; each bar carries the color of its own ratio.
• The card describes YEKE's own server; a cluster's node metrics stay on that cluster's own screens.

Alert notifications are now short and use the cluster's name

• The message is now short. The title carries the status and the cluster's own name; below it, a single measurement line (value · threshold · duration), at most 10 entities with "…and N more" for the rest, and an Open in YEKE link. In chat, an alert that used to take 9 lines now takes 4.
• The cluster's name instead of its id (like c-6) — across alert, operation and scan notifications, including the subject line.
• Time is written only as a duration: "open for 5m", "lasted 20m" — no clock time. The closing message doesn't claim a cause either: "No reading above the threshold in the last 2 minutes."
• Email is now HTML (a colored strip by status, an Open in YEKE button) alongside a plain-text copy; chat (Google Chat, Slack, Microsoft Teams) gets a formatted message with a bold headline, a status marker and a clickable link — the machine identity line stays email-only. The formatting was measured live on Google Chat; Slack's and Teams's are so far only verified structurally.
• On a single-entity alert, "Open in YEKE" goes straight to that alert: it opens the Alerts tab and marks the row; if the alert has since dropped off the list, it says so in one sentence.

The hook address is now stored like a secret

• The address is encrypted in the database. For chat webhooks the address itself is the credential: the key and token in Google Chat's query string, the path itself on Slack. In 0.52 the authorization header and the signing secret were stored encrypted while the address was plain text; now the address of HTTP and chat hooks is encrypted with the same key. The encryption protects against someone who reads the database or its backup without the key — the key stays in core's environment.
• A saved address cannot be read back. The Administration → Hooks screen and the API show only the address's host and fingerprint (last four characters plus a short hash); to change it, press Replace and paste a new one. If a script of yours reads hooks from the API, the url field is gone; urlHost and urlFingerprint take its place.
• Nothing to do by hand when upgrading. Existing addresses are encrypted on core's first start and hooks keep delivering to the same address. Because the database schema moves forward, going back to 0.52 means restoring the database backup taken before the upgrade. Details: Chat channels.

Server strip: an unreadable CPU no longer says "waiting"

• If the CPU counters can never be read, the strip now says so. On hardened runtimes (gVisor, hidepid, an unmounted /proc) the CPU item stayed at "waiting for the first sample" indefinitely, although no sample was ever coming. It now says "could not be read", like the memory and disk items.
• A one-off read failure does not wipe the number. Once a ratio has been computed, a failed sample keeps the last valid value; the next sample tries again.
• No visible change on a healthy server: CPU shows "waiting for the first sample" for roughly the first 20 seconds after start-up, then a percentage.

The server, one line in the top bar

• YEKE now shows the server it runs on, too. In the top bar of the home screen, next to the brand name, CPU, memory and disk usage sit on one line; admins only, no history kept. Amber at 80%, red at 90%; the normal band carries no color. The disk figure is the filesystem holding YEKE's own data directory — on a single-machine install that's the same disk as the Docker logs.
• If the container has a memory quota, the strip shows that too, as a second, labeled number next to the host figure, not instead of it: something like "Memory 41% (container 80% / 512 MiB)".
• Not cluster node metrics. The strip is only on the home screen and only about YEKE's own server; cluster CPU/memory charts stay where they already were.

A third transport for the notification hook: Chat

• Chat joins the transport options — it sends a formatted message to Google Chat, Slack, or Microsoft Teams. The trigger was a real incident: a hook wired to a Google Chat webhook got HTTP 400 from the Sina (test) button, because YEKE's standard hook body (schemaVersion, hookId, deliveryId, stage) didn't match Google's own schema at all.
• The chat format is picked from a closed list: Google Chat, Slack, or Microsoft Teams; the body is built to that product's own schema, and the message text comes from the same Turkish/English templates as the email channel. Setup is on the same screen as email: Administration → Hooks → New hook → Transport: Chat.
• Google Chat is verified live: Test returned 200 and a real alert notification was delivered on the first attempt. The Slack and Teams envelopes were validated with structural tests; no live request has been sent to either product yet. Setup and limits: Chat channels. Whether Google Chat's 4096-character limit counts characters or bytes also hasn't been measured, so the message text respects both caps — 4000 characters and 4080 bytes, whichever fills first is where it gets truncated.

Security fix: a secret nothing reads can no longer be written

• The Authorization header and the signing secret can now only be written on the HTTP transport. Until now these two fields were independent of the transport: an Authorization value entered on an email or chat hook was encrypted and stored, its fingerprint shown on screen, but no request ever read it — the identity is already carried by the address itself or the SMTP relay. An operator filling in that field could believe the channel was signed when it wasn't.
• Existing records don't drop, no migration is needed. The gate only questions a new write; when the transport moves away from HTTP while a secret is stored, the screen warns first, and the secret is deleted from the server the moment the change is saved.

The hook HTTP error message now splits on 4xx/5xx

• A 400 now points at the request, not the service. When a hook returned anything outside 2xx, the screen showed one sentence: "look at the service itself." In the Google Chat case that was wrong — the service was up and had rejected the request for a good reason; what got rejected was the body we sent. For 4xx the sentence now reads "look at our own request (body or headers)"; for 5xx and unreachable endpoints the old sentence stays as is.

nairotech/yeke:0.52.0 stayed live for a short while; 0.52.1 replaces it, carries the same content, and adds only the server strip on top.

The email channel is findable from the menu

• The Hooks menu tooltip says what the page actually holds. The tooltip used to explain what a hook is for, a sentence the page's own intro already gave, and it never mentioned the SMTP server setting. It now reads "verification and notification hooks, SMTP server for email", so the email relay is visible from the menu.
• Alert routing shows a channel's destination. The channel list in the route and scheduled-scan forms used to print only a hook's id. It now shows the destination under the id too: recipient count for an email hook, host for an HTTP hook. The field's helper text names the channel's two forms, and links to the Hooks screen even when no notification hook exists yet. Sending alerts by email already worked; the screen just didn't show it.

Main menu on short screens

• Clusters and Administration share the space half and half. On a short screen the Administration section never shrank and the cluster list was left with a few rows. The two sections now split the remaining height equally and each scrolls on its own; if one fits in its half, the other gets the rest. Rows in a long list are no longer squeezed either. Large screens look the same as before.

Three things seen in production after 0.51.0.

• An anomaly event's value was shown as a percentage. For node memory and CPU anomalies the Alerts tab turned bytes into a percentage. The value is now in its own unit next to the usual value: "7.8 GiB (usual 14.1 GiB)". The alert email is fixed the same way.
• The alert chip in the top bar gives a summary. The chip is red when an alert is firing and amber when only pending ones are open. The popover no longer repeats the count; it shows the state split ("2 firing · 1 pending") and the rule and subject of up to five alerts.
• The "Open in chat" button on Monitoring › Scan is gone. The report's own actions (apply, deepen, send to chat) are where they were, and so are the chat panel's "Scan" button and scan card.

The second release of the E5 phase (monitoring: alerts and anomalies): scheduled scans with a single-file HTML report, anomaly detection in shadow mode, and readability fixes on the Alerts tab. Setup steps and limits: Alerts. Same one flag, Enterprise: metrics-alerts.

Scheduled scans and a single-file HTML report (Enterprise)

• One schedule per cluster: every 6, 12 or 24 hours, or weekly, in local time and timezone. The schedule runs with the identity of the admin who created it.
• The owner check runs again on every occurrence. If the owner has been disabled, has lost the admin role, has a narrowed directory group membership, is an OIDC owner who hasn't logged in for 30 days, or the cluster's AI egress has been turned off, the schedule pauses and says so to admins in the top bar; a transient failure doesn't stop it — the same occurrence is retried within a window.
• When the report finishes, it goes to the notification channel: finding counts by severity, the first 10 findings, and a link to the report. The report itself is now a single-file HTML document; the scan's JSON output stays free in Community.

Anomaly detection — shadow mode (Enterprise)

• Four built-in rules ship: node and workload × CPU and memory. Each node and workload is compared with its own last 14 days' time-of-day profile (median and typical deviation); a deviation fires when it holds for at least 60 minutes and is large enough to act on: 10% of the node's own capacity, or 1% of the cluster's capacity for a workload. At least 7 days of history are required.
• Shadow mode only in this release: a firing anomaly shows up in the Alerts tab and carries its own badge, but never reaches a channel. The goal is to validate the method against live data; delivery to a channel is a later release's subject.
• Scope is node and workload; network, disk and pods are out of scope (details and reasons: Alerts).
• "Expected behavior" marker: mark an anomaly event as normal, and undo it — a reversible feedback record that doesn't change the profile on the spot.

Readability on the Alerts tab

• Status now takes its color from state, not severity: a firing alert is red; a closed-and-stale event carries its own combined state ("closed — target no longer reported").
• The subject is clickable: it links to the owning Deployment/StatefulSet/DaemonSet/ReplicaSet/Job page when the owner is known, or to its own object page otherwise.
• Values and thresholds are now written in their own unit (e.g. "CPU ≥ 90%"), not a bare decimal — both on the Alerts tab and in the admin rule list.

The first release of the E5 phase (monitoring: alerts and anomalies): threshold and "data not arriving" rules, routing, silences, maintenance windows and an email notification channel. Setup steps and limits: Alerts. One flag, Enterprise: metrics-alerts.

Alert rules, routing, silences and maintenance windows (Enterprise)

• The monitoring page has a new tab: Alerts. The count of open alerts also shows as a chip in the top bar.
• Every installation ships with 14 built-in rules, enabled by default (11 threshold rules + 3 "data not arriving" rules), derived from the monitoring page's own "needs attention" thresholds. The fields that define the measurement (kind, metric, threshold, scope) are locked; enabled/disabled, duration and severity are free.
• A stale sample (older than 3 minutes) is never evaluated against a threshold rule. "Data not arriving" is its own rule kind, watched separately for the collector, the node and ingest; a cluster whose state couldn't be asked for doesn't count as a failure.
• Every matching route sends, and an unresolved alert is re-sent as a reminder every four hours. Transitions landing in one tick for the same rule and cluster merge into a single delivery (at most 50 entities plus a remainder count).
• Silences and maintenance windows are two separate records and only silence alerts; neither affects a change-freeze window.
• Rules, channels, routing and silences are written only by an admin; the alert list itself is filtered by each user's own Kubernetes permissions.

Email notification channel and SMTP (Enterprise)

• A second transport was added to the notification hook: email. Built on top of the existing hook mechanism (signed body, retries, dead-letter queue) — no second queue was opened. Details: Hook integration.
• The SMTP relay is a single record on the Administration → Hooks screen; the password is stored encrypted. A relay on the organization's own internal network can be used — only loopback and link-local addresses are rejected.
• The email body's language is chosen per channel (Turkish/English).
• Operation notification emails are now lossless. The reason an apply failed, which step it failed on, and the apiserver's response used to be missing from the email; now each field gets its own line.
• If the license lapses, the alert engine stops and says so: a chip in the top bar and a record in the audit trail. Existing rules, past events and delivery records stay readable; no new rule can be written.

Community limit: monitoring history is now 30 days

• The Community edition now reads monitoring history up to 30 days back; the limit used to be 90 days. History beyond 30 days, up to 90, is now part of the Enterprise license (metrics-retention). This is a narrowing and it is not hidden: the feature shipped on 09.09.2026, so no installation yet had history past 30 days — no data is lost today.
• The locked 90-day view isn't hidden, it states its reason. The screen and the AI tool state plainly when a window longer than 30 days gets clipped; there is no silent clipping.
• Metric collection, graphs, manually-started scans and diagnostic reports stay free in Community with no change in behavior; only how far back you can read changes.

kubectl's YEKE messages in the browser shell are in English

• The explanations kubectl receives from YEKE are now in English. When a command in the browser shell waits for approval, is rejected or cannot be applied, the YEKE: … line that kubectl prints used to be in Turkish. Because kubectl's own frame (Error from server (Forbidden): …) is English, the line read in two languages. If your scripts match Turkish text in these lines, switch them to the English wording.
• The shell's startup lines and the web terminal's messages are unchanged; they still follow the selected language.
• No database or agent changes.

The OIDC screen shows the redirect URI from the core

• "Redirect URI to register at the provider" on the OIDC single sign-on screen is now the address the core actually uses at sign-in. It used to be built from the address you opened in the browser. An admin who opened YEKE at an address other than YEKE_PUBLIC_URL could register the wrong URI at the provider, and the first sign-in failed on the provider's side (AADSTS50011 in Entra ID). If YEKE_PUBLIC_URL is not set, the screen says so instead of showing an address.
• API: the GET /api/oidc/providers response gained a redirectUri field; it is null when YEKE_PUBLIC_URL is not set.
• New guide: Entra ID SSO Setup — what to do in Entra and in YEKE, step by step.
• No database or agent changes.

Apply failures and identity diagnostics in the selected language; causes as codes in events

• The reason a step failed is now shown in the interface language on the approval card. The server used to write it as a Turkish sentence, which also appeared in the English interface. The same applies to the identity diagnostic in the cluster list.
• Field changes for SIEM export and notification hooks: failure is added to plan.apply_step; cause, causeStepIndex and failure to plan.failed and plan.partially_applied; cause and failure to the notification body's result. reason and error now carry only the apiserver's own sentence or nothing. If your SIEM rules look for YEKE's explanation in these fields, move them to the new code fields; records written before this release are unchanged.
• API: identity.message is removed from the GET /api/clusters response; params and foreign take its place.
• No database or agent changes.

The dedicated warning for writes that stop YEKE's own agent is removed

• The three builtin.agent-self-* policies added in 0.49.17 are removed. A write that scales YEKE's own agent to zero, deletes it or removes its identity no longer opens a dedicated warning; like any other write it is classified by the general built-in policies (for example, scaling to zero asks for elevated approval).
• Upgrade note for organization policies: the op.cluster.agent field that policies could read is gone. A policy that references it still loads, but refuses any step that reaches the field. A policy file or package that carries one of the removed warning codes (AGENT_SELF_…) fails to load and YEKE does not start; remove such policies before upgrading.
• The namespace fixes for "Update agent" and the removal command are unchanged (0.49.21, 0.49.22, 0.49.26).
• In PostgreSQL mode the startup log now names the schema migrations it applied; it used to say "no migration needed" even when a migration ran.
• No database or agent changes.

The removal command shows the right namespace for a disconnected agent too

• The removal command shows the agent's last verified namespace even while the agent is disconnected. Since 0.49.22 the command has been built from the identity Kubernetes verifies for a connected agent; once the agent disconnected it still fell back to yeke-system. The verified namespace is now stored on the cluster record and used after a disconnect, a YEKE restart or a token rotation. If the agent is reinstalled in another namespace, the record is updated when the agent reconnects.
• Records whose identity has never been verified still show yeke-system. Existing records are filled once the agent connects to this release and is verified.
• The database schema advances (v45): a nullable column is added to the cluster table and applied automatically on upgrade. Going back to an earlier release requires restoring the database backup taken before the upgrade. No agent changes.

Multi-replica installations: the right error when the tunnel changes hands

• In installations running several YEKE replicas, when a request is forwarded to the replica holding the tunnel and the tunnel changes hands at that moment, the error no longer says the apiserver could not be reached. The request never went to the apiserver, so the old hint to check the kubeconfig address was wrong; the new message says the tunnel changed hands.
• The body of this error no longer carries Turkish text; the reason is in a machine-readable field.
• No database or agent changes.

When a plan is refused, the editor shows the field at fault

• When Kubernetes refuses an edit in the dry-run, the editor shows the field the refusal points to. The line is marked in the YAML view and the reason appears under the field in the form; "Show" in the "Fields to fix" list takes you straight to it.
• Refusals in which Kubernetes names no field mark nothing; the reason is still shown in the band as before.
• For a patch with an unknown or duplicated field, the reason on the approval card and in the refusal band is now Kubernetes' short explanation instead of a long echo of the request that was sent.
• No database or agent changes.

Server log: the explanation is in English when a plan cannot be built

• When a change plan cannot be built, the explanation written to the server log is now in English. The plan could not be built line, written when no agent is connected to the cluster, the target resource cannot be resolved or the target object is not found, carried a Turkish sentence; it now carries a short English explanation with the cluster ID, path or resource. The same applies to plans built from a scan suggestion and from the Shell; it follows the approval gate line in 0.49.22.
• The error text kubectl shows in the Shell is unchanged.
• API: the CLUSTER_NOT_CONNECTED error returned while no agent is connected now also carries the cluster ID, matching the same error returned by a revert request.
• No database or agent changes.

Removing a cluster: the shown command targets the agent's own namespace

• The kubectl delete namespace command in the "Remove cluster" dialog and the install panel now shows the namespace the agent actually runs in. The command said yeke-system for every registration; if the agent was installed in another namespace and another YEKE registration's agent ran in yeke-system on the same cluster, copying and running the command would have deleted that agent. The namespace comes from the same source as the "Update agent" fix in 0.49.21 (the ServiceAccount identity verified by Kubernetes) and is also used for registrations installed with restricted access.
• While the agent is disconnected, or its identity cannot be verified, the command still shows yeke-system. If you installed the agent in another namespace and it is currently disconnected, check the namespace before running the command.
• Server log: for requests refused by the approval gate, the explanation on the "approval gate refused" line is now in English.
• No database or agent changes.

"Update agent": an agent installed in another namespace is targeted correctly

• "Update agent" now targets the namespace the agent actually runs in. If the install manifest was applied to a namespace other than yeke-system, the update plan still pointed at the agent in yeke-system; when another YEKE registration's agent ran there on the same cluster, the plan would have restarted that agent. The namespace now comes from the agent's ServiceAccount identity as verified by Kubernetes, and the organization CA ConfigMap is written to the same namespace.
• No change where the identity cannot be verified: on clusters older than Kubernetes 1.27, or where the identity query is not allowed, the target is still yeke-system. Deployment and ClusterRole names are unchanged.
• In installations running several YEKE replicas, two clusters connected to the same replica could mix up their identity details and metrics cache; each cluster now keeps its own entry.
• No database or agent changes.

Approval card: scaling to zero now shows 0

• When a workload is scaled to zero, the "What will change" table now shows 0. When scaling goes through Kubernetes' scale subresource, a zero value is dropped from the object the apiserver returns; the table showed this row as spec.replicas · 1 · absent, so the card did not show that replicas were going to zero.
• When scaling up from zero, the "Before" column shows 0 as well; it said "absent" there for the same reason.
• For changes written to the object itself, "absent" still means the field was not touched. No database or agent changes.

AI providers: every column of the table is reachable on a phone

• On narrow screens the middle columns of the provider table are visible again. At phone width the pinned Label and Actions columns covered the whole table; Model, Tier, Key · max output, Capability, Price and Last probe could not be reached even by scrolling. This left the "Max output tokens" choice from 0.49.18 unusable on a phone.
• On narrow screens the Label column now scrolls with the table, while Actions stays pinned on the right. The group's product and address remain in the heading above the table. Wide columns (Model, Key, Capability) are read in two scroll positions on a narrow screen.
• Nothing changes on wide screens. No database or agent changes.

AI providers: a selectable max output tokens setting per provider

• Each AI provider now has a "Max output tokens" choice. How long a single answer may be is now part of the provider record: 4,096, 8,192, 16,384, 32,768 or 64,000. It is set in the new provider form and in the provider list (the "Key · max output" column).
• "Automatic" picks by model. Without a choice, Anthropic Claude and DeepSeek models get 32,768 and other providers 8,192; an installation-wide value, if set, takes precedence. The option shows which value applies and where it comes from.
• Answers from thinking models no longer get cut off. Thinking models such as DeepSeek spend their thinking from the same budget; with a low limit a long scan report was cut off halfway. The "cut off at the output token limit" error now points to this setting.
• The value is tried when you save. If the model does not accept the chosen limit, the provider record shows it right away.
• Upgrading adds a new field to the database; existing providers stay on "Automatic" and nothing else needs to be done.

Guardrail: writes that stop YEKE's own agent now raise a dedicated warning

• When a user scaled YEKE's own agent to zero from the interface, the approval card said only "all pods of the workload go down" — it never mentioned the actual consequence: YEKE's connection to that cluster would be cut, and the change could not be reverted from YEKE itself. Three new built-in policies close that gap.
• Stopping or de-identifying the agent now counts as destructive. builtin.agent-self-stop catches deleting or scaling the agent Deployment to zero, and deleting the agent's namespace; builtin.agent-self-credentials catches removing the agent's ServiceAccount, token Secret, ClusterRole, or a binding that carries it as a subject. Both cards say the connection will be cut and the change cannot be undone from YEKE; the user approves by typing the target's name.
• Restarting the agent (an image or environment change, including the "Update agent" button) asks for standard approval but always opens its own card — builtin.agent-self-rollout does not pass silently under a shell session grant. The card warns that if the new pod can't connect, the connection won't come back.
• Limits: the agent's namespace and ServiceAccount are read from the apiserver-verified identity — an agent installed into a different namespace is still recognized — but these three policies don't apply in direct (kubeconfig) mode, and an installation with a renamed Deployment/Secret/ClusterRole isn't recognized. The policies don't block, only warn and raise the approval level; an organization can fully deny these writes with its own deny policy.
• Agent behavior hasn't changed; you don't need to update the agent image to get this protection.

Chat: long option buttons no longer overflow the panel

• Long option text now wraps inside the button. When the model asks a question with long options, the option buttons no longer overflow the chat panel; the panel no longer scrolls horizontally.
• Short options look the same as before. No extra step is needed when upgrading.

Monitoring: a summary of the latest scan on the Overview

• See the latest scan from the Overview. Below the "Run scan" button there is now a summary of the most recent finished scan: the critical, warning and info counts, the most important finding and how many more there are, and how long ago it ran. Clicking the row opens that scan's report.
• The summary always shows a finished scan. While a new scan is running, the previous scan's summary stays in place. A scan with no findings or one that failed gets a short sentence; with no scans at all, the row is not shown.
• Permissions are respected. Findings in places you cannot see are left out of the summary; if there are any, the row says how many are outside your permissions.
• No extra step is needed when upgrading.

Scans: the "can't be applied here" explanation moved behind an info button

• The same explanation no longer repeats on every card. When a suggestion cannot be applied with one click, the sentence explaining why is no longer in the card body; it appears when you press the "?" info button next to the suggestion's buttons.
• No extra step is needed when upgrading.

Sidebar: one sub-menu open at a time under "Other resources"

• Opening a sub-menu closes the other. Only one of the API groups under "Other resources" stays open at a time; clicking the open group's heading again closes it. The group of the resource you are viewing opens on its own.
• The heading you click stays put. When an open group above it closes, the list does not jump; the heading you clicked keeps its place on screen and its contents open below it.
• No extra step is needed when upgrading.

Scans: a simpler finding card

• Summary, evidence and suggestion read separately. The card opens with the summary of what is happening. The suggested fix sits in its own block, together with its action buttons.
• The evidence table starts collapsed. The card says how many readings the finding rests on and where they came from (for example "2 pieces of evidence", next to "YEKE measurements · Cluster events"). One click opens the table. Columns that no row fills are no longer shown, and long values are no longer cut off.
• "Deepen" and "Send to chat" are now buttons with icons. It is clear at a glance that they can be clicked, and "Apply" stands out as the primary button.
• The same card is used in the Monitoring scan report and in the chat panel. No extra step is needed when upgrading.

Sidebar: "Other resources" group headings match their items

• API group headings no longer look smaller. The group headings under "Other resources" (for example core, cert-manager.io) are now the same size as the resource names inside them. The heading stands apart through its bolder weight and the leading arrow; the menu is no taller than before.
• No extra step is needed when upgrading.

Scans: warnings no longer get lost in a busy event stream, suggestions move to chat

• Warnings no longer get lost among normal events. When the scan reads events it now asks only for warnings, and the Kubernetes API itself applies that filter. In a freshly started or very chatty cluster, a warning such as a pod that cannot be scheduled no longer falls outside the list that gets read.
• A harmless warning is not reported as a fault. If the object a warning refers to is healthy and what the warning says shows up in no other reading (for example, the disk capacity warning a node publishes once while starting), the scan does not count it as a fault; if it writes it down at all, it is an informational note.
• "Send to chat". A suggestion that cannot be applied with one click, such as a finding whose fix lives in a ConfigMap, now has a "Send to chat" button on its card. It fills the chat box with the finding's target, summary and suggestion but does not send it; you edit the text and send it yourself. The AI first checks the finding against the cluster, asks you for any missing value (an address, for example) instead of inventing it, and opens the change in the usual approval card.
• Chat can read events by type too. When the AI wants to put warnings first, it can filter events by type; when it does not ask for a filter, events are read as before.
• No extra step is needed when upgrading.

Scans: apply a suggestion from chat, dig into an unclear cause

• Scan suggestions can be applied with a button in the chat screen. Move a report from Monitoring to the chat panel with "Open in chat", or start a scan from chat with "Scan". On an applicable suggestion, "Apply" opens the change in the usual approval card: the dry-run result, what will change and how to revert it are all there, and the decision is still yours. The plan is built with the identity of the person who pressed the button; if their permissions fall short, the approval card shows it. A suggestion can only change the object that was diagnosed.
• Findings are written in plain language. The summary says what is happening and how the application is affected; numbers and metric names stay in the evidence table. Cause labels are simpler too ("It's restarting because it ran out of memory", for example).
• When the cause is unclear, the scan digs deeper. If the readings do not make a finding's cause clear, YEKE runs a second investigation for that finding: the pod's status, events, the container log and, when needed, the logs of Kubernetes system components (DNS, networking, storage, the scheduler). A network error in an application can this way be traced to the cluster's DNS not working. You can also start this investigation by hand with "Deepen" on the finding card.
• Permissions are never raised. The investigation reads with the Kubernetes permissions of the user who started it. For a user who cannot see the system components' records, that step is skipped and the summary says so. When someone else opens the report, investigation details that come from places they cannot see are hidden.
• Fix: diagnosis in chat can read logs now. In earlier versions the AI's log step was rejected by the Kubernetes API and no log could be read.
• Upgrading adds a new table to the database; nothing else is needed.

The node list on the cluster home screen is a table now

• The node list is a table now, not cards. Columns: Node, Status, CPU, Memory, Roles, Kubelet.
• Problem nodes stand out at a glance. A node that is not ready or is over 90% utilization gets a red stripe and background; a node reporting pressure or over 80% utilization gets a yellow one. Nodes that are not ready or reporting pressure move to the top of the list; utilization does not change the ordering, only the color.
• CPU and memory usage bars span the cell width. Each one is paired with a short trend line.

On PostgreSQL installs, a silently broken network no longer waits forever

• This round only concerns PostgreSQL-backed installs. The break meant here is not the other end closing cleanly (the database restarted, the session was terminated); it is a firewall dropping packets, a NAT session ageing out, a dying node — the connection still looks open, no answer ever arrives, and no error is reported.
• If the database cannot be reached at startup, core now stops with a coded error. It used to wait silently: the container looked "up", printed nothing and never recovered on its own. It now says why and exits, so your restart policy can do its job. That is exactly the behaviour you want when a machine comes up in a disaster recovery environment and reaches for the database.
• If the path breaks while running, new requests fail with a clear error. Before, they waited indefinitely and it was not one socket but the whole database connection pool that wedged. The declared wait budget of the schema setup lock now holds too — a single unanswered query used to void it.
• Two limits were deliberately left off, and both are stated here. A query already running when the break happens is not cut short: migrations and archive scans can legitimately take minutes on a large database, so a blanket time limit would cut one in half; only the connection keepalive brings that query down. And because the health endpoint does not touch the database, health checks stay GREEN during this window — read the failure from the logs, not from health status.

The AI provider list is now grouped by product

• Records of the same product sit under one heading. If one product holds several models (two Claude models, say), you no longer get two cards side by side but two rows under a single heading. The heading is derived from the record's address: when the address matches a catalog product, that product's name is shown; when it does not, the address itself is. If you picked a product and pointed the address at your own proxy, the heading follows the address, not the selection — where the data goes is read from the address alone.
• A row now carries only what differs. What the whole group shares (product, address, egress badge, record count) moved into the heading; the row keeps the label, model, tier, key fingerprint, measured capability, price and last probe. Each record takes markedly less room on screen than the stack of cards it replaces. Nothing that needs attention was hidden: a failed probe still shows on its own line, and an unmeasured tier or a disabled record is still marked.
• The price fields in the new-provider form were merged. Input and output price now sit side by side inside a single field; the form's fields lay out in equal columns and the last one no longer stretches across a row of its own.

In high availability, when the path to the database goes quiet

• The background workers' leadership attempt no longer waits forever. This round only concerns PostgreSQL-backed (high-availability) installs; a single-node install has no leadership election to begin with. When the network breaks silently — the connection still looks open, no answer ever arrives, and no error is reported — every attempt opened one more connection and stayed there. The attempt now has an upper bound for both connecting and querying: the number of open connections settles at a fixed ceiling, the replica can shut down cleanly, and the election picks up where it left off once the path returns.
• The connection holding the lock is no longer left on its own. The idle leadership connection is now opened with TCP keepalive, so a silent break is eventually noticed and leadership is released. Before this, that replica could believe it was the leader indefinitely and no other replica could take the workers over.
• A dropped database connection can no longer take the replica down. A connection that broke before the leadership lock was acquired could end the replica with an unhandled error. The break is now caught at every stage: the replica stays up and retries on the next round.

The chat strip is now a single line

• The strip is now one line: the provider's class (external/local), its address, and an info (?) button. The "this turn's context goes to this third party" sentence and the "acting as X" identity line that used to sit on their own lines are gone; both now live behind that same info button, along with the breakdown of what leaves and what never does.
• Saving a posture in the admin's "Egress & provider" drawer updates the strip instantly. On a successful save the strip shows the new address and class right away and the drawer closes itself; if the save fails the drawer stays open and the error shows in the form.

A shutdown race in high availability is fixed

• A replica could finish shutting down while still holding the background workers' leadership lock. When a lock attempt landed at the same moment as shutdown, the replica counted as stopped but the lock stayed with that process, and no other replica could take the workers over until the process had fully exited. Shutdown now waits for the in-flight leadership attempt — a replica that reports "stopped" has released the lock too.

Chat egress and identity info now sits in a fixed strip

• Where your data goes, which identity you're acting as, and the admin's egress setting now sit in a fixed strip right under the chat header. The strip stays in place as you scroll down a long conversation — no need to scroll back up to see whether the provider is external or local, its address, or the "acting as X" identity line.
• The provider card is simpler now. With an external provider, the card shows only its class, address and a one-line consent statement; the breakdown of what leaves and what never does sits behind an info (?) button. Model and tier info moved off the card — it's already shown on each turn's own line.
• The admin's egress and provider setting lives in a drawer opened with the "Egress & provider" button inside the strip. On short screens the message box stays visible even with the drawer open.

"Other resources" opens with its groups collapsed

• Opening "Other resources" in the cluster menu now shows its API groups collapsed. Expand the ones you need; several can stay open at once. If the resource page you are on belongs to one of these groups, that group stays open.

Trusting core's certificate against a corporate CA, without skipping verification

• If core's certificate is signed by your organization's own CA, the agent, Shell and CLI can now connect without -k/--insecure. Give core the CA as a PEM file with YEKE_PUBLIC_CA_FILE; the agent's install manifest carries the CA itself, and the install screen shows a piped-ca form and a "Download the CA" link. Details: Internal CA.
• On existing clusters, an agent that hasn't picked up the CA yet shows an agent · core CA missing chip in the inventory. "Update agents (N)" updates the ClusterRole, ConfigMap and Deployment under one approval card; the pod restarts and the chip clears on its own.
• CLI 0.4.0: yeke login --ca-file root.pem. A TLS trust error now names its cause and its fix; roots added via NODE_EXTRA_CA_CERTS stay trusted when --ca-file is given.
• Shell toolbox image v4. Core's CA is now carried into the shell session automatically; a custom image based on v3 still gets an x509 error from kubectl/helm.

Replicas start safely at the same time in PostgreSQL mode

• Two core replicas started at once no longer take each other down. In PostgreSQL mode, on a first install against an empty database or on an upgrade that changes the schema, replicas tried to set up the schema at the same time: one exited with an error and restarted, and the message sometimes said the database was only partially migrated. That diagnosis was wrong; nothing was wrong with the data. Schema steps now run one replica at a time: while one sets up the schema the other waits, then starts. In our local measurement the wait with two replicas was about half a second.
• The wait is bounded and visible in the log. A waiting replica logs which connection it is waiting for. If the wait passes 60 seconds it exits with SCHEMA_SETUP_LOCK_TIMEOUT and tries again when restarted. Single-replica installations on SQLite are unaffected.

The old core no longer holds up an upgrade

• With agents connected, core now shuts down as soon as it is asked to. In earlier versions open agent tunnels kept core from shutting down: the process did not exit on its own and was killed when the grace period ran out — 30 seconds by default on Kubernetes, 10 seconds on Docker. On a single-replica installation the new core cannot start before that, so every upgrade's downtime grew by the same amount; on our own production we measured 36–42 extra seconds. Tunnels are now closed during shutdown and agents reconnect to the new core on their own; in our measurement shutdown with an agent connected takes well under a second.
• Shutdown is capped at 5 seconds. If some other connection still holds it up, core logs the number of open connections after 5 seconds and exits with code 1. Nothing to configure; the cap stays below the kill deadline of both Docker and Kubernetes.

HTTPS with your certificate, no reverse proxy in front

• YEKE can serve HTTPS itself. Give it the certificate and key files (YEKE_TLS_CERT_FILE, YEKE_TLS_KEY_FILE); YEKE listens for https on 8443 inside the container, published with -p 443:8443. One image, one command. Leave both unset and nothing changes. Details in the Installation guide.
• Certificate renewal doesn't drop connections. Replace the files; YEKE switches to the new certificate within 60 seconds, and the agent tunnel and open terminals stay up. docker kill -s HUP switches without waiting. If the new file is broken, the old certificate keeps being served and the error is logged.
• The expiry date is visible. The /healthz response carries tls.daysLeft; once 30 days or fewer remain, a warning is logged once a day.
• A wrong setup doesn't start, and says why. An unreadable key file (YEKE runs as user 65532, not root), a key that doesn't match the certificate, or a truncated chain shows up in the log with the file name and a suggested fix.
• Limits. No HTTP/2 and no 80→443 redirect; YEKE doesn't obtain or renew the certificate. In a Kubernetes install TLS still terminates at the Ingress.

Password recovery from inside the container

• When the one administrator forgets their password, or their account gets locked, it can now be recovered without the UI. An operator with exec access to the container runs tools/yeke-reset-password.mjs; it prints a one-time password setup token to the terminal, valid for 60 minutes, never the password itself. The token is pasted into /set-password; a new one invalidates the previous. Core does not need to be stopped.
• --reset-mfa also clears the authenticator. With the flag, MFA enrolment and recovery codes are cleared along with the token.
• Local, active accounts only. An LDAP/OIDC account's password is reset in the directory, not with this tool; a disabled account has to be re-enabled by an administrator first. The operation is written to the audit log; the API rule is unchanged. Details are in the Installation guide.

When a hook can't be reached, the screen and the chat say the right thing

• A validation hook that cannot answer now shows its failure in the interface's own language. A timeout, an unreachable address, a non-2xx response or an unreadable body is written on the approval card and in the apply-time error with the same sentence as the hooks screen; it used to appear in Turkish even in the English interface and was labelled as the hook's own reason. Text that is the hook's own reason is still shown as is.
• SIEM: the plan.approval_checked event carries the failure as a code. For a hook that could not answer, reason is empty and failureCode (e.g. HOOK_TIMEOUT) is set; no prose enters the event line.
• The chat no longer mistakes a hook rejection for a policy rejection. When a proposed operation is rejected by a validation hook, the assistant describes it as the decision of an external system (e.g. change management), not as a guardrail block or an unspecified denial.
• CLI 0.3.2: yeke port-forward prints the failure code of a hook that could not answer. 0.3.1 and earlier print such a rejection as "no reason given" against this release; upgrade the CLI to 0.3.2.

The audit log records only what changed on every settings update

• AI provider, SIEM export target and hook updates now list only the fields that actually changed. The fix that 0.46.1 brought to SSO/directory settings now applies to these three as well: fields re-submitted unchanged no longer show up as "changed", and clearing a value is recorded as a change. Secrets themselves never enter the log.
• Hook secret changes have their own fields. The fields list of the hook.config_updated event no longer carries secret names; whether the Authorization header or the HMAC secret was re-entered is in authorizationRotated and hmacSecretRotated. If your SIEM rule looks for authorization in that list, switch to the new field.

Rejection reasons show the right title, in the right language, everywhere

• A validation hook's rejection now has its own title. It used to say "Cannot be applied"; the card and the editor now say "Blocked by validation hook", and the hook row shows which hook said what.
• A missing terminal or port-forward permission now names the verb and resource. Under "You do not have permission", the required verb on the resource (e.g. get on pods/exec) is written in the interface's own language; this sentence used to appear in Turkish even in the English interface.
• When a hook asks for elevated approval at apply time, the screen says what to do in its own language. The approval level cannot be raised at apply time; refreshing the card rebuilds the plan and asks the hooks again.
• CLI 0.3.1: yeke port-forward shows why an operation was denied. The rejecting hook's name and reason, and the missing verb and resource for a permission denial, are printed. 0.3.0 prints these two rejections without an explanation against this release; upgrade the CLI to 0.3.1.
• SIEM: plan.denied and plan.blocked events carry the cause code. The cause and causeHttpStatus fields make the reason for a rejection that happens before any step exists (e.g. a 403 on the request reading the target's current state) readable in the event line as well.

OIDC login with Entra ID can now be set up

• Microsoft Entra ID can now be registered as a provider. Earlier releases rejected the registration: Entra doesn't advertise PKCE methods in its discovery document. End-to-end login against a real Entra tenant was tested, along with group object ID (GUID) to role and Kubernetes group mapping. PKCE (S256) is always sent; if a provider advertises methods but doesn't include S256, registration is still rejected.
• A wrong client secret now shows its own error code. IDP_CLIENT_REJECTED — it used to report "cannot reach identity provider".
• The OIDC settings screen warns when a GUID-shaped client secret is pasted. On Entra, the column to copy is Value, not Secret ID.
• The audit log now lists only fields that actually changed. An SSO/directory setting update no longer writes the whole form, just the changed fields.

A rejected plan doesn't close the editor

• The editor now waits for the plan. When you click "Build the plan" while creating, editing, or scaling a resource — through the form or YAML — the editor now stays open and waits for the result.
• A rejection shows inside the editor. If Kubernetes' dry-run rejects the request (an unknown or invalid field, an immutable field, a name conflict, a permission denial) or a policy blocks it, the reason appears right there, with what you typed still in place; you can fix just the wrong part and try again.
• A valid plan still goes to the approval card. A valid plan opens the approval card as before; if the cluster can't be verified at that moment, your draft isn't lost either.

A shorter AI provider list

• Six providers remain in the list by name. Anthropic, Google Gemini, OpenAI, DeepSeek, Ollama and OpenRouter. xAI, Mistral, Groq, vLLM, LM Studio and llama.cpp left the list; they all speak the same OpenAI-compatible endpoint, so you can still add them.
• New choice: "OpenAI-compatible — other". For any server that exposes the Chat Completions endpoint. Picking it sets the adapter and clears the label, address and model fields; you enter the address and model name from the provider's own documentation.
• Your existing providers are unchanged. The list is only used when you add a new provider; a provider set up with Groq, Mistral or vLLM keeps working as it is.

Current models in the AI provider list

• New models in the suggestion list. When you add a provider, the models suggested for the product you pick now include the ones released in the last six weeks: OpenAI gpt-6-astra, xAI grok-4.6, Anthropic claude-fable-5-1, Google gemini-3.8-flash and gemini-3.7-flash, DeepSeek deepseek-flash. Every name was read from the provider's own documentation on 14.09.2026.
• Retired or superseded models left the suggestions. Groq shut down its two Llama models on the free and developer tiers; DeepSeek deepseek-v4-flash, Anthropic claude-fable-5 and Google gemini-3.5-flash gave way to newer ones.
• Your existing providers are unchanged. The list is only a suggestion when you add a new provider; a saved provider's model does not change on its own, and you can still type a model name that is not in the list. DeepSeek still accepts the old name and routes it to the new model. If you set up a Groq provider with Llama and have no Enterprise contract, switch to openai/gpt-oss-120b, the model Groq recommends.

Long diagnoses no longer stop halfway

• A turn now gets twice as long (2 minutes → 4 minutes). When a diagnostic question takes several reads, every step re-sends the whole context accumulated so far, so the last steps are slower than the first. The old limit therefore ran out in the middle of the answer, and what you saw was half a sentence.
• The answer length limit is now YEKE's own setting, and twice as large. Until now each provider applied its own default: a long diagnostic report was cut off silently, and nothing said why. The limit now lives in one place, is twice as wide, and if it is still reached the reason appears under the answer. Per-installation setting: YEKE_AI_MAX_OUTPUT_TOKENS.
• Chat looks twice as far back (6 turns → 12 turns). On the seventh turn you can refer to something said on the first.
• Read results carry twice as many items (50 → 100). A truncated list pushed the model into "narrow it down and read again", and every re-read made the turn longer.
• The context window you enter on a provider record is now actually applied. Entering the model's window saved the value but never reached the type catalogue's budget — not until a separate connection test was run. On models with a large window the catalogue was being shortened for no reason.

Search in the monitoring table

• The Workloads tab now filters by name or namespace as you type. The tab's own namespace picker is gone: scope was already set by the picker in the top bar, and the two controls wrote the same thing. A search box that narrows the table took its place, and matching is case-insensitive.
• An empty table now says why it is empty. When the search matches no rows the screen no longer stays silent. And when the scope is what emptied it — the namespace selection in the top bar, or the type filter — the sentence points at the scope rather than the search: clearing the search box would not bring a row back.

Going back to a list no longer makes you wait

• Opening an object and returning to the list no longer shows an empty screen. The rows you last saw are drawn immediately while a fresh list is fetched in the background, and they are replaced in one step when it arrives. Meanwhile the status chip reads "refreshing…" and tells you when those rows last synced — what you are looking at is never ambiguous.
• Adding a namespace no longer reloads the others. When watching several namespaces, adding one used to tear down and rebuild the streams of the namespaces already open; now only the new one connects.

The Logs/Shell window now closes with its row

• The window follows the row it belongs to. A Logs/Shell window opened from a list row now closes together with that row when the row leaves the list (the object is deleted, or the filter changes); it used to stay on screen showing an object that no longer existed.

GitOps reflection now sends only the changed field

• Only the changed field now lands in the repo. A change made from the Edit form no longer lands in the repo as-is; only the fields that actually changed do. When a single field of a container changed (e.g. removing resources.limits), the patch sent had to carry the entire container under Kubernetes' patch rules; that carried along the server's own filled-in defaults too, and since those would then be written into the repo's clean manifest, the card said "No repo counterpart is possible" and refused the reflection. Now only the field the operator approved is written to the repo; in the measured example, three lines come out of the manifest and none are added.

When a repo reflection is refused, the card says why

• A refusal now has an address. When an edit could not land in the repo, the card said "No repo counterpart is possible — kustomize build ran and refuted the edit", and that one sentence collapsed dozens of distinct cases into a single cell: the object was not produced, an object that should have been deleted is still produced, declarations were left behind when their container went away, an expected value is missing from the output… The card now carries, right next to the state, the machine-readable diagnosis naming the case — object-not-produced, cascade-incomplete, expected-value-missing and their siblings — along with which step, which object and which path was refused. When the write succeeds the card stays as quiet as before: the diagnosis surfaces only on refusals, and stays in the details popover otherwise.

GitOps: field removal now lands in the repo

• A removed field now lands in the repo too. When a field is removed from an object (e.g. resources.limits from a Deployment), even when the edit was generated correctly and verified with kustomize build, the card said "No repo counterpart is possible — kustomize build ran and refuted the edit" and no commit was made: the validator looked for the expected value in the dry-run result, and a removed field is by definition not there. Removal is now verified too: the field's real absence from the build output is measured, and if a patches entry puts it back, the reflection is still refused.

Pod list: logs straight from the row

• Logs are now in the row menu. Open a row's action menu in the pod list and Logs is there; the log window opens on the same screen. Until now that shortcut existed only in the pod table inside a workload's detail page, so anyone looking at the list had to go to the pod's detail page first.
• It appears only where logs exist. The action shows up when the resource's own schema declares a log subresource — on the rows of resource types that carry no logs it is not in the menu at all.

Node detail: every pod on the node is listed

• The list is no longer truncated. The "Pods on this node" table on the node detail page used to show only the five highest-consuming pods; it now lists every pod with a measurement on that node. The order is unchanged: descending by CPU, pods with no measurement at the end.
• No added cost. The truncation was client-side — the data was already downloaded, and the rows past the fifth were thrown away before they were ever drawn. This release adds no extra query and no extra load.
• The header says so when the ceiling is hit. On a very large node, if the server's entity ceiling kicks in, the table's heading states how many entities are shown; the list does not silently fall short.

Monitoring: the rollup pass now reads only the closing window

• The maintenance pass reads less. The five-minute rollup pass now reads from the source tier only the window that closes in that pass; before, the half-hour and two-hour steps pulled whole day-rows and discarded almost all of them unused. Measured on a copy of a 205-pod cluster: data read in the half-hour-step pass 20.8 → 12.3 MB, that pass's query + decode time on production hardware 2.9 → 0.8 s. Data written to disk is byte-identical; the write side is unchanged in this release.
• A silent agent no longer costs an empty pass. When a cluster's agent has gone quiet and the window is empty, the pass does not read that day's rows at all — previously ~2 s was wasted every five minutes for three hours.
• Measurement tool. The write-path bench now also reports rows/bytes read and written per pass and the number of pages that reach the disk.

Diagnostics: slow database transactions are now named in the log

• The warning line names the transaction. Core already warned when a database transaction exceeded 1 second; the same line now carries the first SQL statement, the statement count and the number of affected rows (first=… statements=… changes=…). Which background job caused a stall is read from kubectl logs, not guessed.
• Follow-up to 0.44.1–0.44.2. After the event-loop fix, a few 1–3 second transactions remained in production; this release exists to name them. Recommended probe values are unchanged: timeoutSeconds: 5, failureThreshold: 6, CPU limit 1000m.

Approval card: step numbers

• Step boxes are numbered. Every step box on the approval card now carries its ordinal, and the warning sentences ("Step 2: there is no record of the previous state", "Step 1 cordons the node and step 3 changes the pod template") say the same number, counting from 1. The first step used to be called "Step 0" with nothing on the card to match it.
• Partial-apply result uses the same number. When a plan stops halfway the result line ("Step 2 failed: …") uses the box number. The step index in records and in the audit trail is unchanged; result sentences written earlier keep their old form.

Monitoring read path and table alignment

• Monitoring reads are chunked too. Large reads of the metric history are split by asset group; the result is byte-identical, but a single long query no longer holds the event loop.
• Numeric columns align with their headers. In the node detail's pod table, the port-forward table and the operations table, headers of right-aligned numeric columns are right-aligned too.

Event loop: chunked monitoring writes

• Monitoring writes no longer hold the event loop. Metric writes coming from the collector are split into small transactions with the event loop breathing in between. This is where the blocking that let the liveness probe kill core under load lived.
• /healthz carries an event-loop measure. The health endpoint now returns event-loop lag (p50/p99/max) — a measure, not a gate.
• Probe and limit values in the install manifest are measured. The liveness/readiness timeouts and the CPU limit in the Kubernetes example were updated from measured values.

Guardrail: node cordon and single-node clusters

• Cordoning the last node needs elevated approval. A patch that closes a node to scheduling (spec.unschedulable) is now classified on its own: if the target is the cluster's last schedulable node the plan counts as destructive, the approval card asks for the name and says "after the cordon no new pod can be scheduled". If the node count cannot be read the plan is raised too; unknown does not mean safe. With other nodes open the current class stays and the card shows a single warning line.
• Cordon and rollout in one plan get a warning. When a plan carries both a cordon and a step that changes a pod template, the card says so: the rollout's new pods cannot be scheduled and the workload stays Pending.
• Chat does not suggest cordon for throttling. The diagnosis prompt no longer proposes cordon for CPU throttling or limit problems; cordon is suggested only when maintenance or drain is asked for explicitly, and never on a single-node cluster.

Monitoring: several namespaces at once

• The namespace filter is multi-select. On the Workloads tab namespaces are picked from a checkbox list; "All" clears the selection, and a search box appears past twelve namespaces. The selection travels in the address (?ns=odeme,uretim), so a shared link opens with the same filter. With one namespace the request goes to the server with it; with several, all visible namespaces are read and filtered on screen.

Monitoring: grey curve on the cards

• The curve on the total cards is neutral again. Colour lives only in the usage bar (green, amber, red); the curve beneath it is grey like the network card's, since the line's job is the shape.

Monitoring: sortable tables

• Tap a header to sort. In the Nodes, Workloads and Storage tables the CPU, memory, disk, network, throttling and name columns sort on tap: first tap descending, second tap ascending. Columns with a ratio sort by the ratio (19% vs 93%), network by inbound plus outbound; rows without a measurement stay at the end in both directions rather than counting as "smallest". Headers are keyboard accessible.

Monitoring: three colours on the cards

• The total cards' bar has three colours. Green below the threshold, amber as it nears, red at and above; grey remains only on a card that cannot be measured (the network card has no capacity). In 0.41.0 a healthy value was drawn grey and read as "no measurement".

Monitoring: cards carry state, the attention list groups

• The total cards carry state. CPU, memory and disk cards show a thin usage bar toned by threshold under the value and a small curve across the selected window; the "worst node" line appears only when a node is clearly worse than the average. The network card shows inbound and outbound rates separately. On a healthy cluster the cards stay quiet; colour arrives only as a threshold nears.
• The attention list stops repeating itself. One cause is one row ("CPU throttled · 14 workloads"), the worst three subjects inline, the rest behind "+n more". Pods roll up to their workload: a DaemonSet's five pods are one subject, not five rows, and "Diagnose" targets the workload.
• Two new signals. Network errors (pod and node; any error warns, one per second or more is red) and PVC inode usage (volumes that run out of files while the disk looks free). The summary the chat reads carries the same criteria. Restart counts and pod memory limits are not on the wire, so they are not listed; those classes belong to the scan.

Monitoring: the right sentence in kubeconfig mode

• On a cluster connected with a kubeconfig, the Monitoring page no longer says "update the agent". There is no agent in that setup; the page says so in one sentence and explains the move to agent mode. The node panel and pod cards keep using metrics-server in kubeconfig mode when it exists. In agent mode, monitoring needs neither Prometheus nor metrics-server; YEKE installs no components into a cluster, so there is no install card either.

Monitoring: kubelet TLS acceptance from inside the product

• "Accept unverified TLS". On Kubespray and kubeadm clusters the Monitoring page flagged an unverifiable kubelet certificate with a chip, but the remedy needed kubectl. The button at the end of the strip takes the acceptance through today's approval card: the card states what it means (unverified TLS to the kubelet inside the cluster network) and the lasting alternative (kubelet serving certificate rotation); on Apply, YEKE_KUBELET_INSECURE_TLS=true is written onto the agent Deployment, the agent restarts and the chip clears within a minute. Nothing is accepted silently: the step is in the audit trail and nothing is written before approval.
• Only when needed, only for the entitled. On a healthy cluster the strip never appears; the button follows the same three conditions as "Update agent" (agent mode, known image, full access).

Monitoring: an empty store is not "no permission"

• The Workloads tab separates two empty states. When the collector has not written any series yet (kubelet certificate not verifiable, agent just installed) the tab says "no workload has reported a measurement in this range" and points to the collector's state; "no permission" now appears only when permission is actually missing. On a Kubespray cluster a cluster admin was told they had none.
• Chat states the right remedy for a blind node. The collector status the assistant reads during a diagnosis now carries why a node cannot be read and what to do: when the kubelet certificate cannot be verified, YEKE_KUBELET_INSECURE_TLS=true or kubelet serving-certificate rotation; the node itself is healthy. The previous release guessed the remedy in that case.

Scan

• The scan now reads events too. Pods that never started (unschedulable, image pull failures, missing configuration), crashing pods and pods that are not ready show up in the report. The previous release only looked at metrics, and these failures ended as "no findings".
• OOM is reported by name. A workload whose memory peak sits at its limit is now reported as "oom-killed", with the peak and the limit as evidence.
• Process count and image disk in node diagnosis. PID pressure and image filesystem usage are part of the default read; before, they were invisible unless the model asked for them.
• Measurement. On YEKE's own 24-case broken-cluster set, with a single model (DeepSeek) and one run per case, the correct root cause went from 10/24 to 23/24; false positives on healthy clusters stayed at 0. This is a baseline, not a general guarantee: other models, other clusters and other failure classes were not measured. Only the server needs updating, the agent is untouched.

Scan

• The report no longer gets dropped. When the model wrote an opening sentence first and then put the report inside its answer, the report was lost and the scan ended with "the model produced no valid output". Both parts are now read together; the scan template and the chat behaviour are unchanged. Only the server needs updating, the agent is untouched.

Diagnosis

• "Diagnose". A button on the Monitoring page's attention list, on node, workload and PVC rows, and on the monitoring blocks of object pages: it opens the chat with that entity and that time window, the message is prefilled but nothing is sent until you send it. The assistant now reads YEKE's own series first (saturation, throttling, missing points), then events and logs; the answer follows FINDING → EVIDENCE → LIKELY CAUSE → SUGGESTED FIX and every piece of evidence carries its unit.
• "Scan". One button on Overview: the cluster is read with a fixed scan template and the findings appear on the Scan tab ordered by severity, each with a code from a closed set of root causes (OOM, CPU throttling, node pressure, full PVC, image pull, crash on start, unschedulable, failing probe, network errors, collector gap…), a target and an evidence table; past scans live on the same tab. When a finding comes with a fix, it goes through today's approval card, and the card says so: the proposal came from a scan, the dry-run passed, the decision is yours. The report is trimmed to the reader's namespace permissions; findings you cannot see are counted, never named.
• Diagnosis is measured. A 24-case "broken cluster" set (13 root-cause classes, two healthy cases) runs through the product's own seeding and scan path; in this release, with one model and one run, root cause and target were found in 10 of 24 cases. Failures that leave no trace in metrics (unschedulable pods, image pulls, crash on start, failing probes) are today's blind spot, and the measurement document says so.
• Kubelet certificate. On Kubespray and kubeadm installs the kubelet's self-signed serving certificate stopped the collector and the reason was invisible; the agent now logs the reason and the remedy in one line, and the Monitoring page states the remedy (YEKE_KUBELET_INSECURE_TLS or kubelet serving certificate rotation). Needs agent 0.38.0; "Update agent" is enough.

Monitoring

• The "Monitoring" page is here. Under Operations in the left menu: Overview (CPU, memory, disk and network totals; a "worst node" chip; items that need attention; the node strip), Nodes (a curve per node), Workloads (namespace and kind filters), Storage (PVC usage). Time window Live · 1h · 6h · 1d · 7d · 30d · 90d, and the choice follows you from page to page. No Prometheus or metrics-server required.
• Object pages read the same source. The node page gains a seven-card monitoring section plus the pods on that node; the pod cards on a workload page and the node panel on the cluster home draw from YEKE's own series when they exist and behave as before when they don't. You never pick a source; the numbers are the same everywhere.
• "Update agent" now updates permissions too. One approval first brings the agent's cluster permissions to the current manifest, then writes the image; in 0.36.0 only the image changed and monitoring could stay "forbidden". Press "Update" once on any cluster that moved to 0.36.0.
• Agent fixes. The collector could go silent after a few minutes on some clusters; it no longer does, and it logs a liveness line every ten minutes. Missing permissions are reported as "forbidden". PVC usage is collected (for hostPath/local-path volumes the kubelet reports the host disk's capacity).

Monitoring foundation

• The agent now collects usage data. Every 30 seconds it reads CPU, memory, disk, network and IO figures from each node's kubelet in the connected cluster; node, pod and workload series are kept in YEKE's own database. No Prometheus, metrics-server or other component is installed. Nothing is drawn on screen in this release; the history is read from /api/clusters/<id>/metrics/…, and the interface follows in the next release.
• The identity rule did not change. Collection runs under the agent's own identity, but every series a user sees is bounded by that user's own Kubernetes permissions: node series need permission to list nodes, pod series need permission to list pods in that namespace, and the name of a namespace the user cannot see never appears in a response.
• Retention and budget. 30-second raw data for 3 hours, 5-minute summaries for 48 hours, 30-minute summaries for 14 days, 2-hour summaries for 90 days. Up to 400 MB per cluster (YEKE_METRICS_BUDGET_MB); at the limit the finest tier is trimmed first, never the newest.
• Agent update required. Collection starts with the 0.36.0 agent; older agents stay connected and keep working, they just do not produce series. The agent's ClusterRole gained read access to nodes and kubelet statistics; it still has no verb on Secrets.

Interface

• Works on small screens. At tablet and phone widths the resource menu is now a drawer: the "Resources" button in the top bar opens it, and it closes when you pick a resource or press Esc. The chat panel slides over the work area and has its own "Close" button. On phones the top bar wraps onto more lines, and tables and the cluster list scroll horizontally inside themselves with the row's name pinned.
• The home page heading no longer overlaps the list. On narrow screens the welcome text and buttons spilled over the cluster list.
• Nothing changed on wide screens; at 1024 px and above the layout is the same as before.

Interface

• The action menu lines up with its button. The right edge of the "⋯" menu sat about 11 px inside the button's right edge, one scrollbar width; the menu read its position from the window width, which includes the scrollbar. The info popup could overflow by the same amount near the right edge. Both now use the layout width, which excludes the scrollbar.

Interface

• The cluster list menu no longer runs off the bottom of the screen. On the last rows of the list, the "⋯" menu opened past the page edge and its lower items were out of sight. The menu now opens upward when there is no room below; if it fits neither way it stays on screen and scrolls inside. The row menu in resource lists already behaved this way; both now share one mechanism.

Shell

• A closed session now says why it closed. A Shell session that hit the memory ceiling and was OOMKilled, or ended on a signal, used to close silently and the first diagnosis was "it never finished". The terminal now reads the reason from the pod's own status and shows it, and says that the memory ceiling is an operator setting. If the reason cannot be read, none is invented.
• Shell straight from the pod list. Reaching a pod meant opening its detail screen first; Shell is now in the row action menu as well. Same approval chain, same terminal.

Interface

• The button is called "Shell" everywhere. The pod detail toolbar said "Execute" while the row menu said "Shell" — one action, two words.

Chat

• Scripts now write to a directory that exists. A suggested script that prepared a values file wrote it under /tmp; the Shell box has a read-only root filesystem, so the script stopped on its second line with Read-only file system. Chat now knows the box's writable directory and puts files there.

Chat

• Chat can now suggest a multi-line script. Work that does not fit on one line with && — writing a values file and then installing, a loop, a conditional, several charts — arrives as a script on a single card. Short work still comes as a one-line command; the preference is still for the shorter form.
• Enter is still yours. The button types the script into the terminal, it does not run it: every line collects on the prompt and waits for a single Enter. If the terminal cannot take multi-line text as one piece, not a single byte is sent and the card says so.
• The script runs in its own subshell. Nothing after a failing step runs, and the script stopping does not close your Shell session. The cost is stated on the card: cd and export inside the script do not persist into the session.

Shell

• Shell writes were failing on GitOps-connected clusters. On a cluster whose repository has "reflect changes back to the repo" turned off by default, every write made from the Shell was rejected with a "plan content changed, command not applied" error. The rejection came from the plan and the request disagreeing about the reflection decision, and it was deterministic: re-running the command never helped. The Shell now carries the plan's own decision. The write goes through, and the repository's decision is still honoured — with reflection off, the repo is left untouched.

Chat

• No more "I added the card" without a card. Chat would sometimes write the Shell command into the answer text instead of the card and then claim it had added one; no button appeared. A turn that leaves a runnable Shell command in the answer without producing a card is now sent back: chat either creates the card or takes the command out of the answer. Commands it writes while explaining reads it did with its own tools are unaffected.
• Large objects can be read again. Reading a single object could fail with "the response exceeded the wire limit" because of parts of the object that never reach chat at all. We measured the difference and separated the limit for that one read; the amount of text sent to chat is unchanged.

Terminal

• The pod terminal lives in the bottom drawer too. A terminal opened from a pod's detail page or row action is no longer a full-screen overlay; it opens as its own tab in the same drawer as the Shell. The session survives navigation between pages; switching tabs does not drop the connection, and a tab's × ends only that session.
• One drawer, several sessions. Shell and pod terminals side by side; while the Shell tab is in the background its "N approvals pending" and "N writes" chips stay visible. Switching clusters ends every session in the drawer.
• The chat panel is no longer squeezed by the drawer. Chat keeps its full height on the right; the drawer opens on the left, up to the chat panel. With chat closed the drawer spans the full width.

Shell

• The Shell box's memory limit is now 1 GiB. helm repo add bitnami … used to kill the box out of memory under the old 512 MiB limit: the Bitnami index is 27 MB and helm parses it in memory. The limit is now configurable with YEKE_TOOLBOX_MEMORY_LIMIT_MI (floor 512); the box's memory request is unchanged.
• Chat prefers a chart's OCI address when it knows one. The helm install <name> oci://… form skips the repository index; the Bitnami address is taught to the chat.
• Switching clusters ends the Shell session. With the drawer open, switching to another cluster from the top menu left the old cluster's shell running under the new title; the Shell is bound to a cluster, so it now ends on switch and reopens for the new cluster with one click.

Chat

• The "Run in Shell" card survives a page reload. The chat's interface lines (the command card and theme/language/screen chips) are now stored with the history and redrawn when it loads; the button works from history too.

From chat to Shell

• Chat no longer refuses work the Shell can do; it proposes a command. Installing a Helm chart, watching rollouts, a bulk operation or in-cluster network/TLS diagnosis now yields a one-line command card. The "Run in Shell" button types the command into the Shell terminal; it does not run it. Enter is yours. If the Shell is not open yet it opens first, with two approval cards on the way.
• The command is validated on the server. Single line, no control characters, at most 512 characters, at most one suggestion per turn. The audit trail records a digest (sha256 and length), not the command itself. kubectl exec/attach/port-forward/cp are never suggested; to get inside a pod, chat opens the pod screen and points to its Terminal action.

Shell

• The Shell is now a drawer at the bottom of the page. Top bar, sidebar, lists and chat stay visible; the height is set by dragging or keyboard and remembered in the browser; minimizing keeps the session alive. The pod terminal stays a full-screen overlay.
• The banners above the terminal collapsed into one bar. Status, "Recording on", "N approvals pending" and "N writes" chips live in the bar; long explanations sit behind the info button. The close button now says "End session". A minimized bar keeps its chips — applied-write announcements never go quiet.

Approval card

• The card is simpler while the "reflect into the repo" box is off. Four indicators saying the same thing became the box and one line: nothing is written to the repo, and the next reconcile may revert the change.
• Ticking the box now shows "rebuilding the plan". The box is disabled while the plan is rebuilt with the repo counterpart in the background; before there was no feedback and the screen looked frozen.

GitOps

• The default of the "reflect into the repo" box can now be set per repo. Turn the default off in the GitOps repo settings and the box comes unticked on clusters bound to that repo; the plan is built without consulting the repo — faster on experimental repos. Tick the box and the plan is rebuilt with the repo counterpart. The product default stays on.
• The card says why the box is off. Repo default or your choice — the record carries it too.
• Known limit. While the box is off no conflicting-declaration warning is raised; on a repo whose default is off that warning is silent by default.

Interface

• Action buttons on the Operations page stay visible. The ledger's "Show the trace" and the audit trail's "Download recording" buttons stay pinned to the right edge when the table is scrolled horizontally. The operation ledger shows at most ten rows and scrolls inside the table beyond that; the Approval column now follows the Actor column. In the audit trail the download column is drawn only when a recorded session exists.

Governance

• Session recording setting on the cluster screen. At the bottom of the screen that opens when a cluster is selected, after the GitOps binding section, the terminal session recording posture is shown: on, off, and whether a missing licence means no new recording starts. An administrator can turn it on or off from there; the entry in the cluster list menu remains. Against an older core that does not report the posture the section is not drawn at all.

Fixed

• The approval card no longer shows "ticket missing" when an already-applied terminal plan is opened from the list. The ticket is single-use and is never written to the plan; on an already-applied record opened from the list or the chat its absence is expected. The card now expects a ticket only for a plan applied in this very flow; the warning appears only on a real mismatch.

Governance (Enterprise)

• The compliance report's scope statement now gives session COUNTS. Terminal sessions opened in the period, how many started recording, how many opened with recording off — sessions whose recording state cannot be read from the trail are counted as "unknown", not unrecorded. The same counts are in the NDJSON summary.
• The guardrail CEL context sees two recording fields. op.cluster.execRecording carries the cluster's recording POSTURE (independent of the license); op.cluster.recordingActive carries posture and the license together — whether this session's recording actually starts. A closed template ships in the repo (ops.recording-required, off by default) — it cannot be turned on in place, copy it into your own namespace. Details on the Policies page.

Fixed

• The policy package signing tool didn't recognize an encrypted private key, fixed. Given an encrypted PEM (an ENCRYPTED PRIVATE KEY header, or the older Proc-Type: 4,ENCRYPTED), the tool failed without ever asking for a passphrase; it now reads one from YEKE_POLICY_KEY_PASSPHRASE or a secret prompt.

Fixed

• Core failed to start on PostgreSQL installations without the archive table; fixed. The 0.26.0 schema migration assumed archived_operations exists on every PostgreSQL installation; on an older installation without it the migration rolled back and core did not start. The migration now skips that step when the table is absent. SQLite installations were not affected.
• The compliance report now records an unreadable archive in its scope statement instead of failing. On the same class of installation the report endpoint returned 500; it now builds the report from live records and shows an "archive unreadable" line with the error summary.

Brings all five items of phase E3 (governance): dual approval (four-eyes), maintenance windows (change-freeze), centralized policy management, terminal session recording, and compliance reports. Setup steps and operator behavior: Governance. All five sit behind Enterprise flags — respectively dual-approval, change-freeze, policy-central, session-recording, and compliance-reports.

Dual approval — four-eyes (Enterprise)

• A guardrail policy field can require a second approval. When requireSecondApproval (with an optional requiredApproverGroup) matches, the plan is classified with a secondApproval field; default is OFF, so a single-admin install is never locked out.
• The second approver GRANTS consent, the OWNER still applies the plan. The actor-≠-owner gate is unchanged; there is no second applier.
• Consent is tied to the plan's CURRENT hash. If the plan is refreshed and the hash changes, consent is dropped and must be given again.
• If no eligible approver exists, this is not left to apply time. The plan is still created and its card says so AT PLAN TIME; the existing notification hook is queued to reach a second person at the same moment.
• A configured rule stays in force when the license is removed — the only thing that's cut off is defining a new rule.

Maintenance windows — change-freeze (Enterprise)

• The calendar is defined as freezes: (a separate file under file mode, the package's freezes field under central mode); every window's timezone is REQUIRED.
• An apply inside the window waits. It gets 409 APPROVAL_HOOK_DENIED plus the window's end time; the plan record stays unmutated.
• There is no break-glass path. v1 only "waits".
• A configured window stays in force when the license is removed — the only thing that's cut off is defining a new window.

Centralized policy package (Enterprise)

• The policy set can also be loaded from a signed package instead of a file (YEKE_POLICY_MODE=central). The package ({version, policies, freezes?, signature}) is Ed25519-signed — the key is the organization's own, separate from the license and air-gap release keys.
• File mode and central mode can't be the source at the same time (giving YEKE_POLICY_DIR together with central mode stops core with an explicit error).
• Loading takes effect immediately but never affects a plan already in flight; every change is logged.
• A package with a broken signature does NOT drop the previous version — it is rejected, and the previous version keeps being read.

Terminal session recording (Enterprise)

• Full pty recording is opt-in per cluster, OFF by default. Metadata events (who, which pod) are always written, Community included; when full recording is turned on, the terminal says so on its opening line — there is no covert recording.
• The download format is asciinema v2 .cast. There is no inline playback in the browser; customers bring their own player.
• It has its own retention dial (YEKE_EXEC_RECORDING_RETENTION_DAYS, default 30 days) and does not enter E2's archive plane.
• When the license is removed, no new recording starts, but existing recordings remain readable.

Compliance reports (Enterprise)

• A cluster × period change report is produced from a single endpoint. The report is a derivative: it writes no new table or event, its sources are the audit trail and admin approvals.
• Format is a single HTML file (default) or NDJSON. The period cap is 366 days.
• The report carries a chain summary of the range it covers (start/end canonical hash plus event count) and can be verified with verify-tool.
• Without a license the report endpoint returns 403; raw trail reads and NDJSON export (SIEM) are unaffected.

Fixes

• The hook delivery list failed on PostgreSQL installations; fixed. /api/hooks/deliveries returned 500. Delivery itself always worked — requests reached your hook; only the endpoint that lists past deliveries was broken. SQLite installations were not affected.
• The schema check did not know the latest migration; fixed. The check that keeps the SQLite and PostgreSQL schemas in step was missing the newest migration. It did not affect installations; it only showed up in development against PostgreSQL.

Hooks and ITSM

• A typed ticket block in the hook response. Your hook can return the change record's id, URL and status as separate fields. The block is optional; leave it out and nothing changes. A malformed block is not dropped silently — the whole response counts as not understood. Details in the hooks guide.
• A ticket badge on the approval card. The card draws the change record's id as a link and its status as a chip; the approver sees which record authorised the operation without switching to the ITSM and, when a URL was given, reaches it in one click. The ticket on an approved card cannot change silently after approval.

Fixes

• The hook allow-list written to .env never reached the container; fixed. The deployment files (compose, .env.example, the Kubernetes manifests) now carry YEKE_HOOK_ALLOWED_HOSTS. Before, the value written to .env was not passed through, saving a hook that pointed at an ITSM on the internal network was rejected, and the fault was hunted in the ITSM.

Other

• The installation examples were updated. The compose and Kubernetes examples in the repository point at this release's image tag.

The nine releases from 0.16.0 to 0.24.0 are collected in this entry. They all had one subject: making the changes you apply from the console land in your GitOps repo too.

Reflecting changes into the repo

• Changes you make in the console now land in your GitOps repo too. When you scale a Deployment or delete an object, YEKE finds the matching YAML in the repo and writes the same change there. A quick fix made from the console is no longer reverted by the next reconcile.
• What will be written is shown before you approve. The approval card names the file and how it changes; if no counterpart is found it says so, and the operation still applies.
• A "reflect into the repo" checkbox, ticked by default. Untick it while you are doing experimental work; with it off, the repo is never consulted.
• Adding a new file and deleting one need a separate tick. Updating an existing declaration is automatic; writing a new file to the repo or removing a declaration is not.
• Your formatting survives. Comments, indentation and line layout stay as they are, and every untouched byte stays identical. Removing a list entry no longer shifts the neighbouring lines either.
• Kustomize and Helm setups are supported. The namespace set in a parent kustomization.yaml is taken into account when the right file is found, and removing a declaration also drops its entry from kustomization.yaml. Helm release names are resolved as well.
• Deleting a Namespace covers the declarations inside it. Delete a Namespace or a CRD and the declarations bound to it go too; the list of covered files sits on the card before you approve and is part of the plan you approved.
• Declarations left pointing at a deleted object are listed. If a route targets that Service or a pod template mounts that PVC, the card shows them before you approve. None of them are edited — they are only shown.
• An object owned by a controller is out of scope. Delete a pod and the repo is never consulted: the counterpart in the repo is not the pod but the Deployment that created it.

Binding a repo, and drift

• You bind your GitOps repo from the console. Registering the repo, the public key YEKE generates and binding a cluster to the repo are all on screen; at the start these were API-only.
• A "Test connection" button measures the setup. Was the public key added, does that key carry write access, does your scope path match anything in the repo — all three are shown separately. A repo that was never tested does not say "ready".
• A bound repo cannot be deleted; you are asked to remove the cluster bindings first. When the server identity changes, you type the new fingerprint yourself.
• Drift reports work on Kustomize repositories. The declaration set is read from the build output rather than the raw files — the objects the reconciler actually applies to the cluster.
• The report says which scope it looked at. Bind a cluster with a narrow scope and the report comes from that scope. A scope that cannot be rendered is not counted as clean; it says "unknown".
• The GitOps binding is on the cluster overview. You see which repo, which branch and which scope; if there is no binding, you can create it from there.
• The GitOps screen and the repo half of the approval card are leaner. Rationale moved behind info buttons; nothing was removed.

Speed

• Building a plan got noticeably faster, and in most cases it resolves without calling the model at all: finding the counterpart is mechanical, and the model only steps in when that path fails.

Fixes

• Undo did not land in the repo; fixed. When you undo an operation the declaration goes back to its old value, and only the changed line enters your file.
• The plan was stale right after your own commit. Applying a change and trying to undo it immediately could let the repo drift quietly.
• An environment failure looked like an answer about the repo. When the render tool could not be run, the card said there was no counterpart in the repo; it now says it could not look.
• The reason a counterpart was not found was folded into one sentence, and is now written out — including whether the model was never called or looked and found nothing.
• Two lines on the card were wrong. A cross-namespace target was written by name only, and is now written as namespace/name; and on a deletion the line "undo recreates the object" stayed in the list.
• A single unparseable YAML file blinded the whole scope. Only that file is skipped now, and the card names the file it could not read.
• A cluster's GitOps binding was exposed to non-admin sessions; closed.

Known limits

• Inserting into the middle of a list can still shift the neighbouring lines, and references inside a file that cannot be parsed cannot be scanned.

• Repairing malformed model output now works the same across every provider. The repair path that previously ran for one provider family was made shared and applied to OpenAI-compatible endpoints too. The same model no longer behaves differently depending on the provider.

• A setting the provider rejects is now dropped by MEASUREMENT, not by model name. If a provider refuses a setting, YEKE learns it from the request result, drops the setting and retries. The old path guessed from the model name; there is no list to keep up to date when a new model ships.

• The AI now proposes replica changes through the scale subresource. The console's Scale action already used that path; the model was patching the object root instead. Both reach the same result, but the subresource needs a narrower permission and shows up in the audit trail exactly like the same action taken from the console. This gap was found by the first measurement run against real models.

• The data directory default is now separate from the operator's setting. The image's own default and the path supplied at install time no longer shadow each other, and PostgreSQL mode no longer requires a writable data directory.
• The air-gapped install bundle was hardened. The way the bundle moves images onto the target changed, and signature verification behaves correctly even when no key is configured at all. The bundle is positioned as the third and rare path for an air-gapped install — the usual path is still pulling images directly.

• The singleton lock no longer gives up instantly against a frozen predecessor. When the lock is held elsewhere, startup now polls every 500 ms for a fixed 60-second budget before returning the same refusal as before. No forced takeover; the terminationGracePeriodSeconds (30s) and the Recreate deploy strategy are unchanged. What was measured: an instant refusal, combined with restartPolicy: Always against a frozen predecessor, turned into a crash-loop — the wait closes that without weakening the guard.
• Startup in PostgreSQL mode no longer requires a writable data directory. The disk-write check now runs only in SQLite mode; in PG mode the snapshot encryption key's source (env var or file) is mandatory and verified at startup — starting from a default path or an ephemeral generated key in production is now a named startup error. This makes readOnlyRootFilesystem: true usable in the HA deployment.
• The air-gapped install bundle is now in the product. After this release's packaging fixes (image-name prefixes in the compose install, the load step for the multi-architecture image archive), a full acceptance run passed on a real, network-isolated environment (a Harvester VM): a fresh 0.15.0 install from the bundle's own files, then an upgrade to 0.15.1 — the pre-upgrade password still worked afterward, and data and the audit trail were preserved. The single-machine compose install needs only docker, no outbound network call was made at any step, and the package is Ed25519-signed with out-of-band verification. Detail and the boundary are on the pricing page.

Brings all five items of phase E2 (scale and continuity): the PostgreSQL driver, the SQLite → PostgreSQL migration tool, YEKE core running highly available (HA), long retention and archiving, and the air-gapped install bundle.

PostgreSQL driver (Enterprise)

• A second backend next to the single-file SQLite. YEKE connects to a PostgreSQL your organization already runs: it does not install, cluster, back up or operate it.
• The shape of the connection target is a contract: a direct connection to postmaster, or a session-mode pooler, is supported; transaction/statement pooling is not supported and is rejected at startup. No server-side configuration is required.
• Minimum version PostgreSQL 15; tested against PostgreSQL 15 and 18.6, no difference between them.
• YEKE_DB_URL selects PG, its absence selects SQLite; if the connection can't be established, core does not silently fall back to SQLite — startup stops with an explicit error.

SQLite → PostgreSQL migration tool (yeke-migrate)

• Moves an existing SQLite installation into PostgreSQL: offline and one-way, run while core is stopped.
• Integrity verification is part of the tool itself — row counts, the sequence number, and whether the encrypted columns still open are checked before the target is marked "complete".
• Verified with a synthetic dataset (1,201 operation-log rows); not yet measured against real production volume.

YEKE core running highly available / HA (Enterprise)

• PostgreSQL mode only: a multi-replica core and zero-downtime version upgrades, replacing today's ~60-second deploy outage.
• Measured with 2 replicas in a development environment — a real kind cluster, a real agent tunnel and a local PostgreSQL 18.6 (not measured on an organization's own PostgreSQL): a rolling update produced zero errors across 566 HTTP probes; the tunnel handover window measured 3.1 seconds against a ≤15-second target.
• PostgreSQL's own high availability is still the customer's responsibility — this item's scope is YEKE's own operation only.

Long retention and archiving (Enterprise)

• Runs only in PostgreSQL mode: a deleted operation is copied, in the same transaction as the delete, into a monthly-partitioned archive table and stays readable through a dedicated API endpoint.
• SQLite mode is unchanged; today's sweeper and retention-duration dials keep working exactly as they do now.

Air-gapped install bundle

• An OCI archive of the published images, plus a single-file CLI and a signed manifest.
• An acceptance run on a real, network-isolated environment found a handful of issues in the packaging step; fixed in 0.15.1 — see that entry for the full acceptance run that measured the fix.

• Namespace panels are back, columns stay aligned. Each namespace draws its own panel with its own table again. Column widths are now measured once across the whole screen and applied the same way to every panel, so the same column starts in the same place in every panel.
• Measured: drift used to run up to 15.4px on the Name column, 33.7px on Age, 48.3px on Containers, and 80.3px on Images; it is now 0.00px on all seven columns — in both wide and narrow windows. In a narrow window the columns don't get clipped, the table scrolls horizontally instead.
• This is a visual change: which rows get drawn, sorting, and the underlying query are unchanged. The ungrouped (flat) view works exactly as it did before.

Completes phase E1 (identity and compliance): OIDC login and audit-trail export to SIEM.

OIDC login (Enterprise)

• Targets Keycloak and Entra ID, using Authorization Code + PKCE. The user goes through the IdP's own login screen; the local password form does not disappear — it stays as an emergency access path, and the install owner is always local no matter what.
• The user is created automatically at login (JIT) and consumes a license seat; the group claim in the token flows into Kubernetes groups through the mapping in the cluster's identity rule.
• LDAP and OIDC can be enabled at the same time. A single mapping list carries both LDAP group DNs and OIDC's plain group names.
• Roles can be derived from the directory (adminGroup); when that's set, writing the role from the UI is refused.
• Same license item: no new flag — Enterprise sso is shared with LDAP. SAML still doesn't exist.
• Measured against a real Keycloak and a real Active Directory forest; not measured against Entra ID.

Audit-trail export to SIEM (Enterprise)

• Reading the audit trail stays free at every tier; what's sold is export (the audit-export flag).
• Two destination types: TLS syslog (CEF) and signed webhook (NDJSON). Plain TCP and UDP syslog are deliberately absent — the trail carries usernames and Kubernetes identities.
• Continuous streaming: a cursor per destination; export resumes where it left off even if core restarts.
• Gap detection: an increasing sequence number on every record, plus a chain built from the previous record's digest.
• Signed format: a periodic checkpoint record is signed with Ed25519; the key belongs to the install itself, and the verifying party gets the public key out-of-band.
• Multiple destinations can be defined; each has its own cursor and its own chain. Where export starts from is the operator's explicit choice ("from now" or "from the beginning"), and that choice is declared in the first checkpoint.
• If schema validation fails, the record is not dropped: the destination stops, the cursor doesn't advance, and the status is reported.
• No acceptance test was run against an enterprise CEF parser — this isn't a general guarantee.

• The namespace-grouped resource list is now a single table. Each namespace used to draw its own panel with its own table, and because every table sized its columns from its own contents, the same column drifted from one namespace to the next. The groups now live inside one table: the column headers are drawn once and stay fixed at the top, each namespace gets a full-width heading band, and that band sticks under the column header while you scroll.
• Measured against the real component in the browser, the drift ran up to 23.3px on the Age column, 26.1px on Containers, and 53.5px on Images; in the single table, across ten measurement points per column (the header plus every data cell in every group), the difference is 0.00px.
• The checkbox that bulk-selects a namespace's rows now lives on that namespace's band; the color stripe that flags a namespace with a problem is still there, but now it only draws when there's actually a problem to report.
• This is a visual change: which rows get drawn, sorting, and the underlying query are unchanged. The ungrouped (flat) view works exactly as it did before.
• Correction (0.14.1): this single-table layout was reverted. The product owner didn't like it; each namespace draws its own panel with its own table again. Column alignment was kept, solved a different way.

• Clarified the scope of high availability. What YEKE sells is the uninterrupted operation of the application itself: a multi-replica core and zero-downtime version upgrades. Clustering, backing up, and maintaining the database stays the customer's job — YEKE connects to an existing PostgreSQL, it doesn't operate one. This is a boundary statement, and it's now reflected on the pricing page too.
• The image tag in the installation guide now updates automatically with every release. The version number on these pages won't fall behind again. It has before: once, for seven releases in a row.
• No user-facing behavior changed in this release; what changed is how the scope is described and how releases get shipped.

• Fixed: the default identity rule in direct mode could silently defeat your AD group mapping. The rule created by "write default" used a fixed identity and did not say so on screen; with a directory mapping in place, whoever signed in could end up collapsing to that same one identity. The screen now warns about this explicitly.
• Fixed: "write default" was deleting your directory group mappings. Clicking that button used to wipe the AD group mappings on a cluster's identity rule; they are preserved now.
• Fixed: the forbidden-group check could be bypassed by changing letter case. system:masters was rejected, but SYSTEM:MASTERS slipped through silently. The check is now case-independent everywhere it runs — the identity rule, adding a cluster, and the agent token.
• Fixed: an internal field was leaking into responses. A record-version number meant only for internal use has been removed from the API output.
• All four were verified against a real cluster. This affects any install using an identity rule or AD group mapping in direct mode.

• Active Directory / LDAP login (Enterprise). Bind to your organization's directory and accept sign-ins from it. Users never see a separate form — the same login screen branches on the server side once it recognizes the account. Details: Active Directory / LDAP Login.
• Local accounts stay. Turning on the directory does not remove username-and-password login; the install owner is always local, and local administrator access stays available even if the directory is unreachable, misconfigured, or the license is frozen.
• Users are created automatically on first login. You do not pre-invite anyone from the directory; every automatically created user consumes a license seat, exactly like one added by hand.
• AD groups map to Kubernetes groups — including nested membership. If someone belongs to a group only through another group, the mapping still picks it up, and that cannot be turned off.
• Roles can come from the directory. Name an "admin group" and a user's role is recomputed from it on every login.
• Connection security cannot be disabled. LDAPS or StartTLS is required, and certificate verification cannot be turned off by any setting.
• Requires the Enterprise sso license item; without it, the directory screen and directory login are refused with an explicit error, and local login is unaffected.

• Two-step verification is here. You can protect your account with a second factor from an authenticator app — Google Authenticator, Authy, Microsoft Authenticator, or any app that supports TOTP. Turn it on from the account screen: scan the QR code, enter one code from the app, done. The key is also shown as text next to the QR for installs without a camera and for desktop authenticators.
• Recovery codes. Ten codes are shown once when you turn it on — that is your way back in if you lose your phone. Each code works once and goes into the same 6-digit field at sign-in, so there is no separate screen to find. The codes are visible only at that moment and can never be shown again; if you lose them, an administrator can reset the factor.
• Scope, stated plainly: two-step verification is optional. This release has no installation-wide policy that forces everyone to enable it — an administrator who never turns it on keeps a single-factor account, and nothing compels otherwise. Enforcement is the subject of a later release.
• Not a paid feature: it is in the Community tier and needs no licence.

• Fixed: sign-in did not work on non-https addresses. If you installed YEKE on a server and opened it by IP or hostname (http://…), signing in failed even with the right password: the page reloaded and no error appeared. The session cookie was sent with the Secure flag, and browsers silently drop such a cookie on an insecure address. The cookie now carries that flag only over https; nothing changes if you run behind a TLS-terminating reverse proxy.
• A sign-in that fails silently now speaks. If the cookie is refused for any reason (browser cookie policy, managed profile), the screen says what happened and what to do — so nobody goes hunting for a password problem that isn't there.
• Installations reached over localhost never saw this: browsers treat localhost as a secure origin.

• When the data directory isn't writable, core now stops and says what to do: which directory, which user the process runs as, and the exact command to paste — in one line. It used to print only EACCES, which sent the reader to the wrong object: the key file instead of the directory.
• The message also states that the path inside the container is not the path on the host: on a bind mount the directory to fix is the host one, and core cannot see the mount source.

• The key step is gone from installation. Core now generates the snapshot key (YEKE_SNAPSHOT_KEY) itself and writes it into the data directory (snapshot.key, mode 600), then reads it from there on every later start. You no longer generate one, paste it into the command, and file it away separately.
• Which also removes the risk of losing the key on an upgrade: it lives next to the data it encrypts, not in the container's environment — docker rm + docker run doesn't touch it.
• Nothing changed for installs that keep the key outside the data directory: supplying YEKE_SNAPSHOT_KEY still wins over everything, and the file is neither read nor written. A new YEKE_SNAPSHOT_KEY_FILE moves the key file to another path. On Kubernetes a Secret is still the recommendation.
• The single-machine install now mounts a host directory instead of a named Docker volume (/opt/yeke/data): everything the installation holds — the database and the key — sits in one visible directory, so what to back up is obvious.
• Existing installs are unaffected: one that supplies the key through the environment keeps working exactly as before. Don't drop the variable afterwards — core would generate a new key and the records encrypted until then would not open.

The first entry in the log: everything built up to 0.10.0 is collected here, as a summary of what the product does today. Every release after this one gets its own heading on top of it.

Connecting a cluster

• You import a cluster that already exists: the agent you install in it opens an outbound tunnel — you don't expose the apiserver, open an inbound port, or set up a VPN.
• The tunnel protocol ships as its own package (@nairotech/yeke-tunnel); the agent's image tag is derived from core's own version, so the two move up together.
• The cluster list is a single grid, the left menu groups into accordions, and each cluster's version and distribution mode are written in the inventory.

The AI — inside the approval chain

• The model acts with your Kubernetes identity: who it acts for is verified at the apiserver, it cannot do anything you could not do yourself, and every step it takes is written to the audit trail.
• What leaves shows up on every message — body size, destination host, how many paths were redacted. Secret values never reach the model at all.
• Egress is set per cluster: off · local-only · allowed. Providers are Anthropic Claude, OpenAI, Google Gemini, DeepSeek and fully local Ollama; keys are encrypted in the database, not sitting in an environment variable.

The operation path

• There is one way to apply: plan → dry-run → guardrail → approval → apply. The operation you build by hand and the one the model proposes take the same path.
• 11 built-in CEL policies classify every request (namespace-delete, rbac-binding-write, scale-to-zero…); destructive steps are marked on the approval card and stand out in the operations log's Status cell.
• Approval is given to content, not to a button: every refresh produces a new plan summary and an apply request carrying an old one is rejected. The person who creates, approves and applies is the same person.
• Bulk actions: multi-select, one approval for multiple targets.
• Hooks: your own system is asked before an operation is applied.

Day-to-day work

• Forms for 10 resource types; an image column in the pod list; in list rows, text in every cell other than the name can be selected and copied.
• A pod terminal (exec) and port-forward — port-forward reaches both Pods and Services (svc/<namespace>/<name>), from the CLI (@nairotech/yeke-cli), after a one-time yeke login <origin> step.
• Monitoring: pod and node metrics, historical charts (1h · 6h · 24h · 7d).
• Role-based permissions, with built-in roles.
• The Enterprise license signing key is embedded in production: PUT /api/license can actually deliver an Enterprise contract.
• The interface speaks both Turkish and English; command boxes carry a copy icon embedded inside them.

Removed: cluster provisioning

• 0.10.0 also took something back. Creating VMs on Harvester, installing RKE2, the machine inventory and adding or removing nodes left the product; YEKE now only manages clusters that already exist — whatever tool built them.
• On upgrade, machine records, stored SSH keys and Harvester provider records are deleted; the deletion counts are written to the core log.
• Critical: deleted SSH keys and API tokens are not revoked at the source — you still need to remove them from the machine's authorized_keys and revoke the token on the Harvester side yourself.
• Existing cluster records are not affected by this change.