Skip to content

Releases: kaimahi-agents/kaimahi

v0.6.0

Choose a tag to compare

@github-actions github-actions released this 14 Oct 19:35
430ab3e

Added

  • Create → Prove → Publish → Lift: kmx create NAME authors one tool-free
    workspace member; kmx eval evaluates all cases and exports a private receipt
    only on a full pass; kmx push --evaluation FILE REF publishes the exact suite.
    Create/eval/push discover the nearest workspace.yaml; --workspace DIR
    selects an exact root. Orka is default; kagent supports exact v0.10.3
    Go/linux-amd64 with author-owned bindings. Workspace guide.

  • kmx lift REF@sha256:DIGEST deploys an immutable suite with explicit passing
    evidence and destination selectors. --plan is GET-only; --promote permits
    a matching destination with source-only evidence, not destination evaluation.
    Orka can reuse exact evaluated resources; kagent refuses occupied targets.
    Lift runs no model and does not update, adopt or roll back resources.

  • Pinned AgentSessions chat supports offline packaging and explicit loopback
    eval --development-host FILE, with full-pass evidence for evaluated push.
    Hosts are unauthenticated and retain cleartext journals; this development proof
    cannot authorize Lift or receipt diff. Development evaluation.

  • kmx suite diff compares extracted suites and OCI layouts semantically.
    Registry suite push attaches unsigned provenance by default; it is not
    authenticated attestation.

  • AgentSuite Tools gain effect, approval and delegated-user authorization
    metadata. This specifies runtime obligations, not a credential broker or
    runtime approval implementation.

Changed

  • Quickstart and console creation now use native suite evaluation, publication
    and reviewed Lift. Console Ready means placement, not an answer.
  • New local kind clusters use a five-second kubelet sync cadence; existing
    clusters are unchanged. Repeated local setup preserves matching inference
    resources, and quickstart checks current Agent readiness before reconnecting.

Breaking

  • Legacy bundle commands, user agent.yaml workflows/receipts,
    create --live and previews, bundle-mode run, --bundles, and the old
    evaluation CI action are removed; suite status/retirement have no replacement.
    Instead: author with kmx create NAME --workspace DIR --model MODEL --instructions FILE,
    review cases, then eval/push/Lift; retain a historical release for old workflows.

  • The kmx agent group is removed without aliases or stubs.
    Instead: use root create/chat/run, orka show/list, and
    eval diff/from-sessions; run --agent NAME addresses independent live
    Orka Agents, not suite-owned objects.

  • Root ctx/up/down and the old infrastructure lift/lift down aliases are removed.
    Instead: use context show/use, local up/down and aks up/down;
    root lift now means digest-pinned suite deployment.

  • Workspace mode is removed from kmx suite push.
    Instead: use kmx push [--workspace DIR] REF; extracted-directory
    suite push DIRECTORY REF remains.

  • eval diff accepts only full-passing Orka/kagent suite receipts, not old
    bundle or AgentSessions receipts.
    Instead: generate fresh suite evidence; no old-receipt conversion exists.

  • Chat /lift and the old console Lift action are retired, with no live-copy fallback.
    Instead: use root digest Lift with explicit evidence; console creation
    separately composes the native workflow.

  • Chat/quickstart --azure-discovery is removed.
    Instead: select the destination context explicitly and provision AKS
    separately with kmx aks up.

  • Guided tool/host-inference shortcuts, --skills, --out and
    --result-service-account, and in-place tools/inference editing are retired.
    Instead: author tool-free workspace source, select a Ready Orka openai
    Provider for its exact model, and configure native result access separately;
    manage live resources with Kubernetes tooling.

  • Orka installs using the old kmx.kaimahi.ai/installed Helm label are no
    longer recognized as kmx-owned; the label is now kmx.kaimahi.dev/installed.
    Instead: back up before replacing an owned disposable local cluster
    (local down deletes its data), or arrange an operator-managed fresh
    persistent installation; relabeling live objects alone is insufficient.

  • targets -o json changes capability names to
    create/eval/push/lift/chat/run/inspect/diff (AgentSessions also has export),
    Orka/kagent kind to native-profile, and AgentSessions tier to
    development-only; schemaVersion remains 1.
    Instead: update JSON consumers to the new names and per-operation support flags.

  • Alpha Go APIs remove speculative environment-management methods and replace
    the old AgentSuites package/build/publish methods with staged operations.
    Instead: adopt EnvironmentSpec → Up → Environment and
    AgentSuites.Validate/Build/RecoverBuild/Push/RecoverPush; removed environment
    inspection/teardown/recovery methods have no replacement.

Upgrading

Upgrading the CLI migrates or deletes no saved files or deployed resources.
Old receipts remain readable only by the historical release that understands
them. See upgrade instructions and cluster backup boundaries.

v0.5.1

Choose a tag to compare

@github-actions github-actions released this 12 Oct 01:44
5565704

Fixed

  • kmx targets --detect accepts kubectl List Deployment responses, reporting empty lists as absent and labelled controllers as present.
    Malformed responses and failed reads remain unreadable and exit nonzero. Target detection (#429).

  • Homebrew formula tests check the binary's version instead of help prose; the release workflow runs the generated test before publication. Formula test fix.

  • Orka lift-prerequisite recovery commands preserve and safely quote the selected destination context.
    Prerequisite checks and installation defaults are unchanged. Recovery advice.

v0.5.0

Choose a tag to compare

@github-actions github-actions released this 11 Oct 20:39
586e076

Added

  • kmx agent evaluate supports contains, notContains and RE2 regex assertions alongside expectContains, and keeps immutable run receipts.
    toolCalled and toolNotCalled syntax is accepted but currently reports unknown. Evaluation assertions.

  • kmx agent eval diff <before.json> <after.json> compares saved evaluations offline by case and assertion, showing regressions, fixes and lost evidence without rerunning models.
    Comparison requires compatible full-case v2 receipts; regressions and incomplete comparisons exit nonzero. Compare evaluations.

  • The console's R key shows recent Orka Tasks, task lanes and sanitized activity for the selected agent, context and namespace.
    Discovery is bounded and reports missing or unreadable evidence without showing conversation payloads. Interactive console.

  • The reusable kmx GitHub evaluation action runs a tracked bundle's cases through Sessions, optionally replay-checks receipts, and fails the job unless every case passes.
    Sessions evaluation does not satisfy an Orka lift gate. Run evals in CI.

  • kmx agent eval from-sessions <session-uid>... extracts private single-turn UID/prefix references and authored assertions without copying recorded inputs or answers; existing --out manifests append atomically and refuse duplicates.
    agent evaluate --from-sessions verifies source prefixes in memory and runs fresh candidate sessions, with named candidate/judge confirmation and payload-free output unless --show-content is explicit. Expired/unavailable references remain unknown; current diff conservatively makes the whole comparison incompatible when a case lacks runtime identity (#403). Ordinary authored-input evaluation and v2 receipt formats are unchanged. Recorded cases and privacy.

  • kmx agent evaluate supports explicit llmJudge rubric/threshold/model/version assertions with --judge-base-url and optional --judge-key-env (environment name only), without model/endpoint defaults.
    Two temperature-zero scores must agree on the threshold side; split or unavailable evidence is unknown. Receipts bind identity/policy/threshold and both scores without payloads; input/answer/rubric go to the chosen judge provider and terminal reasoning may contain answer text. Replay makes zero judge calls and explicitly leaves judge outcomes unverified. Judge configuration and privacy.

  • v0.5.0 introduces kmx context show/use to inspect and save context selection, and kmx local up/down for the existing local kind setup and deletion operations. Command names.

  • kmx targets reports runtime capabilities offline, with optional Orka and Sessions probes. It selects, installs and deploys nothing; unreadable probes exit nonzero, distinct from absence. Target view.

  • kmx suite validate, push and pull validate and exchange portable AgentSuite artifacts through OCI registries or local layouts; push reports the digest and registry tag pulls show a digest-pinning hint. Suite commands.

  • Experimental kmx suite build builds an agent image with Docker buildx and an OCI-export-capable builder.
    Output is not AgentSuite-conformant; use --require-attestations to refuse missing attestations and never pass a key value to --model-api-key-env. Build limits.

  • kmx agent evaluate --sessions <host:port> evaluates bundles on a Sessions chat host; kmx agent verify --sessions <host:port> replays receipts locally with zero live model calls.
    This is eval-only and reference verification, not host attestation or a lift gate; remote hosts require verified TLS, and host journals retain conversation content. Sessions evaluation and verification.

  • Portable agents can declare an explicit spec.coordination.allowedAgents helper allowlist for Orka delegation.
    Older readers and kagent refuse this field: upgrade readers before using it with Orka. Bundle compatibility.

  • Core-only bundles may omit extensions or use extensions: {}.
    extensions: null and unsupported runtime behavior are refused, not silently dropped. Bundle compatibility.

  • kmx agent create --runtime kagent <name> creates on preinstalled exact kagent v0.10.2, optionally sending one task; Orka remains the default.
    Create-only, with no rollback or ambiguous retry; kagent and Service-proxy audits may retain conversation content. Prerequisites and limits.

  • Explicit kmx agent lift and kmx agent status with --runtime kagent --runtime-version v0.10.3 support Go declarative bundles on an operator-prepared target with --to-context and desired KagentBindings.
    Lift is create-only or complete UID-bound receipt reuse, with no adoption/update; receipts prove readiness, not execution. Dedicated CI qualifies Go plan/lift/repeat/status/conflicts and a separate one-shot native A2A MCP answer with payload-free evidence. Version-qualified placement.

  • v0.5.0 includes checksums.txt.sigstore.json, a keyless cosign bundle for the four binaries' checksum manifest.
    Earlier releases and the Homebrew formula are not covered; installers still verify checksums, not signatures automatically. Verify a release.

Changed

  • kmx ctx, up and down remain compatibility routes; help and hints use context and local.
    Notices go to stderr with no removal scheduled; hidden kmx aks up/down remains callable. Command compatibility.

  • kmx agent run submits one Task without rewriting a deployed bundle or live Orka Agent; kmx task result retrieves its phase/answer without resending, with answer-only run stdout.
    Timed-out Tasks remain retrievable; pending results exit 2, failed/cancelled results exit 1. Run and retrieve results.

  • Native Orka coordination supports same-namespace helpers, concurrency/depth limits and drift checks. Lift/--plan refuse missing helpers or coordination schema; autonomous Job loops remain unsupported. Configure coordination.

  • Orka create and its wizards accept native azure-openai inference.
    Supply a matching deployment/model, HTTPS resource root and existing Secret; lift requires a matching Ready Provider, while /openai/v1 remains openai. Azure inputs.

  • Bundle lift can require a passing staging evaluation through lift-policy.yaml or --require-evaluated <context>.
    Missing, stale, partial, failed or unknown evidence blocks lift; receipts are forgeable local evidence: do not commit them. Evaluation gates.

  • kmx agent lift --override-gate "reason" explicitly bypasses only an evaluation gate and prints/records the reason and bypassed condition. Interactive /lift and console refuse before deployment review, with no silent bypass. Gate overrides.

  • kmx agent retire checks dependents, deletes created objects and releases adopted/legacy objects.
    --delete-adopted opts into deleting adopted objects; the selected Provider, its Secret and existing Tasks remain untouched. Retirement and ownership.

Fixed

  • Recovery advice preserves local and AKS selectors and safely quotes the selected context, including status/Orka diagnostics and retired-edit migration hints.
    Teardown is unchanged; advice no longer suggests deleted Make targets. Recovery commands.

  • Message text after -- stays positional data instead of being interpreted as a --context or legacy -context selector. Context parsing fix.

  • Quickstart and native chat check Task-result read access before creating a Task, stopping on denied or malformed responses.
    No Task is created on refusal; earlier setup may remain. Result-access fix.

  • kmx agent show and bundle-aware kmx agent status return a failure when their JSON output cannot be written. JSON output fix.

  • Creation and quickstart help distinguish offline rendering, optional bundle persistence, fixed-mode answers and guided readiness/chat.
    Operations, defaults and flag names are unchanged. Help improvements.

  • kagent refusal messages identify unsupported chat and the retired AKS installer payload, and point to kmx targets for supported operations.
    Explicit bundle lift/status and historical AKS teardown remain available. Runtime guidance.

  • make build delegates freshness checks to Go so source, embedded-data and build-option changes rebuild the CLI. Build and verify.

  • install.sh --help prints its complete header instead of truncating instructions or showing script code. Installer.

  • Console Prepare can repair the quickstart Kubernetes Tool's scoped policy-...

Read more

v0.4.1

Choose a tag to compare

@github-actions github-actions released this 30 Sep 09:11
800e112

Changed

  • Interactive /lift in chat and the console now deploys an agent's local bundle through kmx agent lift after showing its shared plan. It writes the same ownership markers, receipt and remembered target, then connects chat to the destination. Orka and the quickstart Tool can be prepared only through a separate confirmed action; bundle lift itself installs nothing. Select an existing Ready destination Provider; Foundry creation is not part of this route. With no bundle, the clearly labelled live-copy fallback remains available but status/evaluate cannot track it. An invalid bundle refuses instead of copying.

Upgrading

  • If an agent has a local bundle and needs Foundry inference, create a Provider on the destination first, then select it when lifting the bundle. Agents without a bundle still use the untracked live-copy route.

v0.4.0

Choose a tag to compare

@github-actions github-actions released this 30 Sep 03:02
f473535

Added

  • The getting-started journey now leads through creating a custom agent with kmx quickstart-wizard, proving a local chat answer, lifting it with /lift, and sending a new message to verify the destination. It also describes existing Kubernetes and AKS targets and optional Orka/tool preparation (#251).

Fixed

  • kmx console refuses a mismatched local bundle before contacting the cluster, reuses the status report's full deployed commit for diffs, and gives a shell-safe command when a diff is truncated. Unreachable targets remain unknown without attempting a diff; the CI Go test step was streamlined (#243).
  • On reruns, kmx checks the live Orka controller's image digest as well as the Helm release's pinned values. A patched, missing, unreadable or ambiguous controller is refused without changing the cluster; offline schema help now names v0.2.0 as the default (#252).
  • Homebrew installation instructions now fail closed if the formula prefix cannot be resolved, and explain which release asset and checksum the formula uses (#241). Stale implementation and CI comments were corrected to describe current behavior without changing the CLI (#250).

Changed

  • Orka v0.2.0's chart AI worker does not grant itself read access to the quickstart Tool's OutboundAccessPolicy. kmx now grants only get on its named gateway policy in orka-system to the chart worker ServiceAccount; the Tool's logical public IP avoids DNS-answer drift during v0.2.0 SSRF validation. A live Tool Task returned the cluster's ConfigMap marker after both changes.
  • The plane's Orka egress policy now selects both v0.1.3's legacy controller and the v0.2.0 chart controller in orka-system. Without the chart selector, a migrated owner's model call received 502 upstream unreachable even while the v0.2.0 controller was Ready.
  • Orka installation now pins v0.2.0's Helm chart (orka-0.2.0.tgz, SHA-256 checked before use) instead of applying the v0.1.3 manifest. kmx resolves Helm on PATH or fetches its pinned, checksum-verified toolchain binary, applies CRDs extracted from the verified chart before helm install, pins --kube-context, and installs release orka with controller.mode=harness-v2 and fullnameOverride=orka-api. Orka generates the snapshot encryption Secret orka-api-agent-execution-snapshot; kmx never prints its value. There is no helm upgrade --force path. A rerun preserves a Ready kmx release and key only when all pinned image overrides match; an existing controller/CRDs from v0.1.3 or a foreign/partial release is refused, not upgraded. A pre-created namespace alone is allowed; standalone install also provisions the Task result reader. Offline create now defaults to the v0.2.0 CRDs; --schema-target v0.1.3|main remains available explicitly for old fixtures and does not install an old runtime. See Orka setup and replacement and upstream v0.2.0 installation / unsupported version upgrades (#244).

Breaking

  • Orka v0.1.3 installations are not upgraded in place. Local kind replacement requires kmx down followed by kmx up and deletes the cluster's Tasks, Secrets, PVC-backed data, model data and plane ledger; export anything needed before deletion. On AKS, back up existing volumes/PVCs and Orka resources/Secrets, including any existing snapshot key; after a fresh v0.2.0 installation, back up its new chart-managed snapshot key with its controller volume without printing the key. Neither an untested Helm upgrade nor restoring an old SQLite volume into v0.2.0 is a supported migration. Do not delete a production cluster until the recovery plan is verified.

Upgrading

  • Install the v0.4.0 CLI, then replace any existing Orka v0.1.3 cluster rather than rerunning kmx up against it. For a local kind cluster, export what you need first: kmx down deletes the entire cluster, including Tasks, Secrets, PVC-backed data, model data and the plane ledger; kmx up creates a fresh Orka v0.2.0 installation.
  • On AKS, plan a fresh Orka v0.2.0 installation, not a Helm upgrade. Back up existing Orka resources and volumes/PVCs together with their Secrets, including the agent-execution snapshot key if one exists. Back up the new chart-managed orka-api-agent-execution-snapshot Secret with its controller volume and resources after installation. Never print or log the key; verify recovery before deleting production resources.

v0.3.0

Choose a tag to compare

@github-actions github-actions released this 29 Sep 03:50
d5b3328

Added

  • Homebrew installation through the official kaimahi-agents/tap tap: brew install kaimahi-agents/tap/kmx. The formula installs the existing checksummed release binaries on macOS and Linux, on Intel and ARM; no second binary build or bottle is introduced. Stable releases publish a generated kmx.rb asset for a reviewed tap PR, while dry runs and prereleases do not update the stable formula.
  • kmx agent evaluate <bundle-dir> runs the bundle's eval/*.yaml cases (strictly decoded id, input, expectContains) as one Orka Task each against the deployed revision, and only when the live Agent carries the bundle's current portable digest. Each case is pass, fail or unknown and is never retried; answers are printed, and receipts/eval-<target>.json records the portable digest, a case-set digest, the target and per-case Task identity and answer SHA-256, never answer text. It exits non-zero unless every case passed. The Orka lifecycle adapter now implements Evaluate.
  • kmx agent status shows each target's evaluation result for the current digest and case set: pass, fail, unknown or none.
  • kmx agent create scaffolds eval/example.yaml in a new bundle, and bundle reruns accept an eval/ directory.
  • The quickstart k8s-get-resources tool now says why a workload is unhealthy: pods return per-container ready, restartCount and waiting/terminated/last-terminated reasons (ImagePullBackOff, CrashLoopBackOff, OOMKilled) plus their Ready condition and, when unscheduled, PodScheduled; Deployments, StatefulSets, ReplicaSets and DaemonSets return ready/updated/available counts (zero stated, not omitted); workloads and Jobs return conditions as type, status and reason. No messages, images, env or annotations are returned, and a reason that is not a Kubernetes reason word is dropped. Existing fields are unchanged. Re-run the quickstart to reinstall the tool's code.
  • kmx console compares the selected agent with its local bundle: b, or "Compare with local bundle" in the actions menu. The pane reports the same state kmx agent status does for that row's own context and namespace. For a target that is behind, it shows what a lift would change as a diff of agent.yaml from the deployed commit to the working copy, read from Git rather than the cluster. A drifted target shows field paths only, as status does. Bundles are found under agents/<name> or --bundles <dir>, and a missing bundle is reported rather than guessed. The pane reads and never writes.
  • kmx agent status <bundle-dir> compares each target's live revision, current-generation readiness and rendered-field drift with the portable definition in Git, with table and JSON output. A recorded cluster UID mismatch blocks object reads; an explicit context can be inspected without a receipt.
  • kmx agent lift <bundle-dir> deploys an existing portable bundle to a prepared Orka target with an explicit or locally remembered context and provider:<name> inference. It checks prerequisites without installing them, supports a read-only --plan using the same reconciliation inspection as deployment, reports per-resource outcomes and update diffs, and writes per-target receipts with Git provenance after success. /lift remains the interactive live-agent path.
  • Orka lifecycle Deploy can opt into bundle-owned reconciliation: create absent resources, reuse matching owned resources, update drift with a resourceVersion precondition, or mark an identical unowned resource as adopted. Conflicting or terminating names are refused; a completed deployment returns per-resource outcomes and a receipt with digests and target identities. Reconcile never runs Tasks.

Changed

  • kmx agent create (and the wizards built on it) can be rerun after a failed deploy. It keeps an existing artifact that is byte-identical to what it renders and refuses, naming the file, one that differs; it reconciles the Provider and Agent like kmx agent lift, reusing or updating resources carrying the bundle's markers, adopting identical unmarked ones and refusing anything else. The optional Task stays create-only after both are Ready, so a --task rerun still needs a new --out. A failed create's error says that rerunning is safe; a clean first create prints what it did before. --dry-run and offline creates keep create-only semantics.
  • Bundle reconcile refreshes stale digest markers on identically rendered owned resources with a resourceVersion precondition, reporting reused while making comment-only revision lifts observable. Lift's uncommitted warning now names the failing Git condition.
  • kmx agent create and the quickstart wizard now write agents/<name>/agent.yaml and bindings.yaml as the portable bundle and creation-target bindings (#227).

Fixed

  • The v0.2.0 known issue in #217 is resolved: Orka can now reach the quickstart Kubernetes Tool through a same-namespace gateway route. KMX installs and waits for the exact OutboundAccessPolicy that permits the Tool's private Service; a missing or invalid policy fails closed. Re-run kmx quickstart-wizard to install the working Tool. The non-interactive kmx quickstart answer does not depend on it.
  • Bundle status and lift find the deployed commit when the local bundle directory is reached through a symlink (#239).
  • App-owned state respects KMX_HOME (#230).

v0.2.0

Choose a tag to compare

@github-actions github-actions released this 27 Sep 22:19
89ac685

This is the first Orka-capable release. The entries below include the sequence
of changes since v0.1.0; where an intermediate entry describes a command that
was subsequently retired, follow the final Breaking and Upgrading
sections, not the intermediate instruction.

Changed

  • Nothing in this tree supports the legacy kagent runtime any more, and a
    checker keeps it that way.
    The removal had already taken the installer,
    the steps, the manifests, the chart, the CLI pin and the model presets; what
    it left behind was CLAIMS. A guard banner naming a namespace nothing wrote
    to. Four probe scripts defaulting to a namespace nothing created. A
    committed NetworkPolicy admitting model traffic from that namespace, which
    read as the plane's model door and admitted nobody. Two dead validation
    paths, a dead test fixture and a dead scaffolder helper whose only caller
    had been removed. Documentation rows pointing at guides for a platform an
    operator could not install. Each one reads as support, and the cost of a
    false claim of support is paid by a reader months later who believes it.

    scripts/check-legacy-runtime.py now refuses all of it, on every tracked
    file, in CI and in make docs-check. Hard identifiers — the API group and
    its kinds, the images, the version pin, the three command spellings — are
    refused EVERYWHERE, workflows included, because a workflow is where an
    install would come back. The bare name is refused from the surfaces a
    reader takes as current, one approved line at a time in
    scripts/legacy-runtime-allowlist.json, because prose can refuse a runtime
    or advertise it and no pattern tells those apart. Each surviving line is
    named there with a category and a reason: the production refusals that must
    spell what an operator typed, the historical teardown sentinel a
    pre-retirement lift record decodes to, the bounded negative tests, and the
    CI tripwires' own negative controls. The historical record — this file, the
    coordination board and the dated reviews — keeps its past tense.

    The scanner fails closed on every way it could quietly stop working: an
    empty enumeration, files enumerated and none read, a count below the floor,
    an exemption that matches nothing, a rule that stops matching its own
    example or starts matching its counterexample. It cannot be disabled by
    declaring a current documentation directory historical — a named floor
    refuses exactly that. Sixteen deliberate breakages in its mutation
    specification each make it fail; four of them found real holes in its own
    self-test before they were closed.

    Upgrading: the plane's committed ingress allowance is gone. It admitted
    the retired runtime's namespace, which nothing creates; a migrated adopter
    is admitted by the per-namespace kaimahi-proxy-ingress-<ns> policy
    kmx migrate applies, as before. SECRET_NAMESPACE on the seam, spend-race
    and replica-kill probes and CONTROL/PROBE_NS on the upstream-boundary
    probe are now REQUIRED rather than defaulted — every caller already passed
    them, and a default pointing at a namespace that does not exist turned a
    missing Secret into what looked like a cluster fault. The guard banner's
    namespace list is kaimahi, ollama, orka-system in all four places that
    print it, pinned together by a test. docs/tools.md,
    docs/tool-governance.md, docs/govern-your-agent.md, docs/isolation.md
    and the spikes/ conversion experiment with its workflow are deleted; git
    retains their history.

  • The front door is Orka. kmx quickstart now goes kind → keyless Ollama
    → the pinned Orka release → a fixed hello-world-agent Provider/Agent
    bundle → a fresh Task with a readable answer. Nothing on that path installs,
    reads or waits on the legacy kagent runtime, and nothing on it uses Helm:
    the Orka runtime is a pinned, digest-checked manifest, not a chart. The
    command is also deterministic and non-interactive — the host-Ollama picker
    is gone from it, so the same command on the same machine produces the same
    cluster and fixed Agent bundle, which is what lets an unattended caller
    rerun it and compare. It does not read or replace the local Provider,
    even after a host-Ollama kmx up: it only shares that Provider's keyless
    placeholder Secret. kmx up --step orka still refuses to replace a
    different local endpoint and offers an explicit command that replaces
    the host route. Choosing your own model and authoring your own agent is
    kmx quickstart-wizard and kmx agent create.

  • A bare kmx up is the runtime and deploys no agent. It now runs
    cluster, ollama, model, orka and stops. kmx quickstart is the
    command that ends with an agent answering; kmx agent create is the one
    that authors your own. The legacy kagent, agent and tools-agent steps
    remain individually addressable with kmx up --step <name> so the slices
    that retire them can each be green on their own. There is no flag that
    puts them back into a bare run
    — deliberately, so no configuration can
    keep the old default alive past its retirement.

  • kmx up --step orka owns the Task result identity. It provisions the
    orka-result-reader ServiceAccount and its Role/RoleBinding, whose entire
    grant is get on tasks.core.orka.ai in orka-system. kmx agent create
    still only NAMES an existing account and creates no RBAC: minting an
    identity as a side effect of authoring an agent would hide a grant inside a
    command nobody reads as a grant. Orka v0.1.3 authenticates result reads but
    does not enforce Task-read RBAC, so this Role is the ceiling kmx can state,
    not one the server enforces — which is why it is kept this small.

  • kmx quickstart reruns by exact match. A live Provider or Agent whose
    spec differs from the one quickstart would write is somebody's deliberate
    change — an edited endpoint, a different model, a hand-applied bundle — so
    the command now stops rather than overwrite it, and says different configuration. A half-finished run resumes: whichever of the two already
    matches is kept and the other is created. Every run creates a fresh
    Task; reporting an existing completed Task's answer would turn "the agent
    answered" into "the agent answered once, some time ago".

  • A Provider pointed away from the in-cluster endpoint is no longer refused
    for an unrelated Service.
    kmx orka install --model-url only checks for
    the in-cluster ollama Service when the URL is the in-cluster default. A
    host Ollama reached over the kind gateway is the caller's own endpoint, and
    kmx up has already verified it is reachable from the cluster.

Fixed

  • kmx plane no longer closes by telling you to run a command that does not
    exist.
    Its "Next" actions and its upgrade note both named kmx govern,
    which was retired with the legacy runtime — worse than an unknown command,
    because a command that had just succeeded was the thing recommending it.
    Both now name kmx migrate <deployment> --namespace <ns>, which is the
    route this cluster can actually take. A package-wide test now fails if any
    production code suggests a retired command through operationCommand.

Breaking

  • The legacy kagent installer, its manifests and its status report are
    removed.
    This is the last slice of the retirement: what earlier slices
    left addressable is now gone rather than hidden.

    Commands. kmx up --step kagent, --step agent and --step tools-agent
    are no longer steps. kmx up --step accepts exactly cluster, ollama,
    model and orka — the same four a bare run performs — and anything else
    is refused locally as an unknown step, naming the four that exist. There is
    no flag, environment variable or payload that restores the installer.
    Upgrading: a script naming one of the three retired steps must drop it.
    A cluster that already runs the legacy runtime is untouched by this release
    and is operated with kubectl.

    kmx status now reports the runtime kmx installs. It was a report about
    agents.kagent.dev, modelconfigs and the kagent namespace's pods, with a
    governance envelope counted off them. Nothing in kmx installs, drives or
    deploys any of that, so the report was confidently describing objects this
    project has nothing to do with — which reads as coverage and is not. The
    command keeps its name and now delegates to the same reading as
    kmx orka status: running version against the kmx pin, deployments, CRDs
    and Provider readiness. It delegates the Orka portion unchanged, with no
    separate context check before its toolchain preflight. It also reports
    kaimahi-proxy Deployment and pod readiness/restarts and the serving seam
    certificate's subject, issuer and expiry, warning when renewal is due.
    An absent plane is distinguished from an unreadable one; these reads use
    the same pinned context. kmx ctx explains an incomplete local setup.
    Upgrading: the old kagent agent/model counts and governance envelope are
    gone; the independent plane and certificate health lines remain in the table.

    kmx credential issue --secret now requires --namespace. It defaulted
    to the retired runtime's namespace, so an operator who omitted the flag
    minted a one-time token into a namespace nothing here installs any more —
    and that token is shown exactly once. The namespace is now named rather than
    guessed, and a destination that is blank or does not exist is refused before
    the credential is issued and before any Secret is written, so a missing
    namespace can no longer strand a token that cannot be recovered.
    Upgrading: add --namespace <ns> to any kmx credential issue --secret
    invocation that relied on the default. --discard is unaffected, and
    kmx migrate already took its namespace.

    kmx status -o json|yaml is removed, and refused by name. The document
    published `govern...

Read more

v0.1.0

Choose a tag to compare

@github-actions github-actions released this 03 Sep 23:13
eaf0520

The first tagged release: everything the project has built since P1, at a
version you can name. Most of what is below is release plumbing — the product
can now be installed and upgraded without a commit hash — plus the last
capability to land before the tag was cut.

Added

  • An agent's calls record who it acted for, and credentials expire. A run
    opened at the inbound door (where a Slack signature has already proved who
    typed the message) is what joins a governed call to a person, so the ledger
    and the tool audit carry an actor the plane itself observed — never a claim
    made by the thing being governed. Every credential issued from now on has a
    deadline (default 30 days, no way to ask for "never"), enforced at the LLM
    proxy, the MCP gateway and the inbound door, failing closed and audited.
    make credentials shows what is expiring; kmx credential renew moves the
    date without touching the token, so custody is unchanged
    (docs/identity.md).
  • Tagged releases, built by CI from the tag. kmx binaries for
    linux/amd64, linux/arm64, darwin/amd64 and darwin/arm64, with a
    checksums.txt published beside them. The job refuses to publish a build
    that does not report its own tag, and refuses a tag with no entry in this
    file.
  • go install …/cmd/kmx@latest as the install line — no sha, no
    package-manager namespace claimed, and no new tooling to trust: the module
    proxy and the Go checksum database already stand behind it.
  • kmx version reports the build's own version, not only the versions it
    installs. A release binary reports its tag; a go install reports the
    version you asked for; a checkout build says it is a checkout build.
  • A released binary deploys the plane at its tag. kmx plane used to
    depend entirely on VCS stamping surviving the build; the tag is now the
    first source it reads, and the release refuses to publish unless the
    plane module's matching plane/vX.Y.Z tag exists at the same commit.
  • A documented upgrade path (docs/releases.md),
    including what happens when a migration fails halfway (the plane does not
    start), and a CI job that upgrades a plane across a real schema gap with
    live data in it and proves the data survives.

Upgrading

  • From an untagged go install …@<sha> build: install @latest and run
    kmx version. There is no state in kmx itself to migrate.
  • For the plane, see docs/releases.md.
    Migrations are additive and run at startup under a lock. Two behaviours are
    worth knowing before you upgrade, and both follow the same rule — an
    upgrade never silently widens or voids what an operator already had:
    • past 00008: tool grants minted before argument binding existed keep
      their old verb-level meaning, and no new one of that kind can be created.
    • past 00010: credentials that already exist keep a NULL expiry and keep
      working. Expiring a running estate at migration time would be an outage,
      not a control. kaimahi_credentials_without_expiry is the gauge for
      shrinking that set; re-issue or renew at your own pace.

Not in this release

  • No container image is published. kmx plane still builds the plane's
    image locally from the Go module proxy at kmx's own revision, so Go remains
    a prerequisite for the governed half even if you installed a binary. The
    reasoning is in docs/releases.md.
  • No package-manager namespace is claimed — no Homebrew tap, no npm, no
    crates, no PyPI. The name is provisional and no trademark opinion has been
    obtained; claiming namespaces would raise the cost of a rename that may
    still happen. See docs/NAMING.md.