Releases

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 on a customer-provided 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.