feat(governance): add core task, approval, and receipt APIs - #544
Merged
Pal Lakatos-Toth (pallakatos) merged 36 commits intoSep 8, 2026
Conversation
…0 slice 1) The substrate primitive underneath kars Bridge: a typed unit of governed agent work that carries its trust envelope (autonomy tier 1..5, budget, tool/egress allow-list refs, delegationDepth, authorityCeiling). Independently usable on a plain kars cluster with no Bridge — kubectl apply a KarsTask and the controller validates the envelope and stamps a stable sha256 envelopeDigest (the value the Governance Receipt will bind to). - controller/src/kars_task.rs: KarsTaskSpec + TaskEnvelope + KarsTaskStatus, mirroring the KarsEval CRD conventions (kube-rs derive, camelCase serde, JsonSchema, printcolumns). Deterministic envelope digest. 6 unit tests. - controller/src/kars_task_reconciler.rs: finalizer + envelope validation (defence-in-depth behind CEL) + status stamping (phase, Ready condition, envelopeDigest), preserving lineage for the delegation-minting slice. The reconciler is the sole writer of envelope-derived status. 4 unit tests. - crd_validations.rs: CEL admission rules enforcing the trust-envelope invariants — including the anti-amplification rule authorityCeiling <= tier. - crd-karstask.yaml: generated via the helm_drift dumper; drift test green. - field_managers.rs: CLAW_TASK SSA manager. main.rs: reconciler wired in. - tests/e2e/run.sh: kind integration test (valid->Ready+digest; CEL rejects amplifying envelope). Verified live on kind: valid task -> phase=Ready + envelopeDigest stamped; digest recomputes on spec change; CEL rejects authorityCeiling>tier and out-of-range tier at admission. Full suite: 861 controller tests pass, clippy -D warnings clean, fmt clean, zero helm drift. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…dge V0 slice 2) Pillar A — the security headline. A KarsTask may reference a parent via spec.parentRef; the controller verifies the child's trust envelope is a strict subset (attenuation) of the parent's and mints status.lineage from the parent's ancestry. A child that amplifies authority on ANY axis is rejected as Degraded with NO envelope digest — a Governance Receipt can never bind to amplified authority. This is OWASP ASI-08 (cascading authority) solved at the substrate, not asked of the model. - kars_task.rs: pure attenuation lattice — TaskEnvelope::attenuation_violations returns a precise EnvelopeViolation list across every axis: tier <= parent ceiling, ceiling <= parent ceiling, depth <= parent depth - 1, budget caps (no unbounded child under a bounded parent), and pinned tool/egress policy refs. 9 unit tests covering each amplification + valid attenuation. - kars_task_reconciler.rs: resolve_delegation fetches the parent, mints lineage (controller is sole writer), and routes Ready / Degraded / ParentMissing. - crd-karstask.yaml regenerated (parentRef); helm drift test green. - tests/e2e: delegation test (valid child Ready+lineage; amplifying child Degraded+no-digest). Verified live on kind: parent Ready (root); valid child Ready with lineage=[parent]; tier-5 child under a ceiling-4 parent Degraded with no digest and the exact violation message. 870 controller tests pass, clippy -D warnings clean, fmt clean, zero drift. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… KarsSandbox (V0.1b)
Closes the governance/execution gap surfaced in live dogfood ("I created a
task, nothing happens"). A governed task can now run a real agent — gated by
an explicit launch, faithful to plan §20 (review the package, then launch).
- kars_task.rs: spec.execution { launch, runtime } (default not-launched =
governed-but-idle); status.executionPhase / sandboxRef / executionDetail;
Execution printcolumn.
- kars_task_execution.rs: on launch, server-side-apply an owned InferencePolicy
+ KarsSandbox bounded by the envelope (tool policy → governance, token budget
→ InferencePolicy), then read back the sandbox phase. Un-launch tears them
down; owner refs cascade on task delete. 4 unit tests.
- kars_task_reconciler.rs: reconcile_execution folds launch/teardown into
status; execution errors degrade execution only, never the governance status.
- crd-karstask.yaml regenerated; drift green.
Verified live on kind: launch=true → real KarsSandbox + InferencePolicy
materialized (owned, envelope-bounded), executionPhase=Degraded with the honest
"needs a real Foundry endpoint" detail; launch=false tears the sandbox down
(Idle); default (no execution) makes no sandbox (§20 gate holds). 874 controller
tests pass, clippy -D warnings clean, fmt clean, zero drift.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The KarsTask reconciler (Bridge V0) needs cluster permission to
get/list/watch/patch karstasks + status + finalizers. Without it the
in-cluster controller ServiceAccount hits a 403 and the reconciler disables
itself ("KarsTask CRD not installed — Forbidden"). Earlier kind tests ran the
controller out-of-cluster (full kubeconfig), so RBAC was never exercised;
running in-cluster surfaced the gap.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tion (Inc 3) The Governance Receipt is the auditor's moment: a signed, independently verifiable record that a KarsTask was governed under its trust envelope. Core (controller): - New KarsReceipt CRD (controller-written only; no admission CEL — integrity comes from the signature, not schema gates). - providers/signing.rs (allowlisted crypto): Ed25519 over DSSE PAE; loads/ persists a receipt identity Secret and publishes the public key to the out-of-band kars-receipt-pubkey ConfigMap (the verifier's trust anchor). - kars_receipt.rs: pure, deterministic in-toto Statement builder (no timestamps → idempotent emission, re-derivable by a verifier) + the honest claim matrix: integrity=PASS, conformance=PASS, completeness=PARTIAL (router token/cost audit chain is V1), regulatory=OMITTED (no external anchor in V0 local signing). - Reconciler: emits an owner-referenced KarsReceipt for every governance-Ready task; retracts it when the task is Degraded (no validated authority to attest). A child receipt records its attenuation of the parent. CLI (kars receipt verify / show): - Verifies the DSSE/Ed25519 signature against the published anchor (never a key embedded in the receipt), plus key-binding and envelope-binding, then prints the claim matrix. Works on a plain kars cluster, no Bridge required. - Unit tests cover the DSSE PAE framing and tamper/wrong-key rejection. Honest V0/V1 split: the plan puts the full emitter in the router (token/cost from the audit chain), which needs a real Foundry run; V0 ships the governance half in the controller and self-labels completeness/regulatory accordingly. Documented in the design note. Verified end-to-end on a kind kars-dev cluster: receipt emitted + CLI-verified for a Ready task; amplifying child Degraded with no receipt. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
KarsApproval makes the autonomy tiers mean something: a priced/external/ irreversible action, a checkpoint, or a tier-raise becomes a human decision the fleet waits on — and the decision is recorded in the task's Governance Receipt. Core (controller): - New KarsApproval CRD + reconciler. The controller owns the authority binding: it copies the gated task's status.envelopeDigest into status.boundEnvelopeDigest on first observation and never changes it. If the task envelope later drifts, a still-pending approval goes Stale — you cannot grant authority against a moved target. - Pure, exhaustively-tested decision function: Pending → Approved/Denied (decidedAt/decider immutable) / Expired (past TTL) / Stale. A recorded human decision wins over expiry/staleness. Unknown verdicts fail closed. - Receipt closure (Inc 3 ↔ Inc 4): the in-toto predicate now carries the decided approvals (approve AND deny) for a task, deterministically ordered, so every steer is part of the signed record. The DSSE signature re-verifies over the enriched payload. CLI (kars approval list/approve/deny/show): - Plain-cluster parity for the steering primitive; approve/deny patch spec.decision, the controller drives the transition. The reconciler RECORDS decisions; acting on an approved action (actually widening egress, raising the tier) is the consuming reconciler's job and is the V1 wire — documented honestly in the design note. Verified end-to-end on kind kars-dev: bind, approve (CLI + UI), deny, TTL/staleness on envelope drift, and all three decisions bound into a re-verifiable receipt. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… metering (Inc 5)
Three parallel hardening deliverables that strengthen the Governance Receipt
without overclaiming.
Completeness floor:
- New CREATE-time kars-task-namespace-floor ValidatingAdmissionPolicy denies
hostNetwork/hostPID/hostIPC, privileged, allowPrivilegeEscalation,
ephemeralContainers, and hostPath in isolated=strict namespaces — closing the
gap the UPDATE-only posture-lock leaves, so the receipt's no-bypass claim
holds against a compromised controller / direct kubectl apply.
- The reconciler observes which floor controls are enforced (the new VAP,
exec-ban VAP, posture-lock VAP, default-deny egress) and binds them into the
receipt predicate. The completeness claim stays honestly PARTIAL (runtime
iptables hash + token/cost = V1, eBPF witness = V2, all named), but its
detail now reflects the concrete enforced controls.
Receipt inclusion log (self-hosted-Rekor precursor):
- Every emitted receipt is entered in a hash-chained kars-receipt-log
ConfigMap. `kars receipt verify` now also checks chain integrity + inclusion;
`kars receipt log` shows/verifies the chain. Gives cross-receipt
tamper-evidence (deleting/altering/reordering breaks the chain). Labelled
operator-controlled — does NOT give operator-non-repudiation (external
witness + KMS-attested signing are V2); regulatory stays OMITTED.
Metering attribution (efficiency pillar plumbing):
- The task reconciler stamps task-id + lineage-root annotations on the
materialized sandbox; the main reconciler forwards them as
KARS_TASK_ID/KARS_TASK_ROOT; the router emits kars_task_tokens_total
{task,root_task,model,direction} so cost rolls up per task branch. Bounded
cardinality — only task sandboxes emit the series. Live token numbers need a
Foundry run (the same honest boundary as V0.1b).
Verified end-to-end on kind kars-dev: VAP denies each escape vector + honours
break-glass; receipt carries the enforced-controls evidence; inclusion chain
populates, a tampered chain fails verification and a restored one passes;
non-task sandbox correctly omits the task metric labels.
Wave-2 KMS-attested key-release (SKR/MAA), external witness, and the eBPF
datapath witness remain hardware/partner-gated and seam-ready — not faked on
kind, per the product's honesty discipline.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ceipt log Delivers the verifiable operator-side half of the V2 witness story for the receipt inclusion log. On each receipt emission the controller publishes a signed checkpoint — an Ed25519-signed note over (origin, tree_size, head_hash), Go-sumdb signed-note style — to the kars-receipt-checkpoint ConfigMap, via the allowlisted providers::signing::sign_note. The head hash of a hash chain already commits to the entire prefix, so a checkpoint over it is a sound signed tree head. - `kars receipt verify` now also validates the checkpoint (signature vs anchor + agreement with the live log). - `kars receipt checkpoint` verifies it standalone and prints the pinnable root. - The Bridge surfaces the checkpoint in the receipt panel. Why it matters: the bare chain gives tamper-evidence but the operator could rewrite the *whole* chain silently. A pinned signed checkpoint detects a silent history rewrite even when the rewritten chain is internally intact — verified live: truncating the log to a valid shorter chain passes `receipt log`, but the pinned checkpoint reports "size 6 diverges from live 5 — history may have been rewritten." Still V2 (genuinely partner/hardware-gated): an external party counter-signing/gossiping these checkpoints (non-equivocation) and hardware-attested signing. The checkpoint gives clients something concrete to pin; the external witness is the remaining step. regulatory stays OMITTED. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…agents were degraded) Launching a KarsTask materialized an InferencePolicy with no modelPreference.primary.deployment — but the sandbox reconciler REQUIRES a deployment (it's plumbed to AZURE_OPENAI_DEPLOYMENT / OPENCLAW_MODEL). Without it every task-launched sandbox degraded immediately at materialization, before inference was ever attempted. Only `kars dev`-created sandboxes (which carry a full modelPreference) ran. The task execution path now sets modelPreference.primary from a controller-env default — KARS_TASK_DEFAULT_MODEL → AZURE_OPENAI_DEPLOYMENT → DEFAULT_MODEL → gpt-4o-mini, with provider KARS_TASK_DEFAULT_PROVIDER (default azure-openai; the router routes by the configured endpoint URL). An operator points the controller at any OpenAI-compatible provider (GitHub Models, Azure OpenAI, Foundry) and launched agents do real governed inference. Verified end-to-end on kind kars-dev with GitHub Models as the dev provider: a launched task's sandbox reaches 2/2 Running (no longer Degraded), the router loads the model, and a chat completion through the secure router (with content safety filtering active) returns a real response + token usage. The whole 7-stage pipeline is now live, including agent execution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…al run The launch package (design note §20) needs to compile a task-giver's intent into the substrate's existing CRDs rather than duplicate them. Extend KarsTask with a TaskBlueprint (runtime, model, instructions, toolPolicy, mcpServers, egress, isolation, memory) and have materialize() compose it: - model -> InferencePolicy.spec.modelPreference.primary - runtime -> KarsSandbox.spec.runtime.kind - isolation -> KarsSandbox.spec.sandbox.isolation - prompt -> KarsSandbox.spec.agent.instructions (objective + standing instructions) - tools -> KarsSandbox.spec.governance.toolPolicyRef (existing ToolPolicy, by ref) - MCP -> KarsSandbox.spec.governance.mcpServerRefs - egress -> KarsSandbox.spec.networkPolicy.allowedEndpoints (+ Strict mode) - memory -> KarsSandbox.spec.memoryRef (existing KarsMemory) Governance is composed cohesively: tools come from a single source (blueprint or envelope toolPolicyRef); MCP refs only attach when a tool policy bounds them, so without a policy governance is a valid 'enabled: false' rather than an invalid 'enabled: true' with no toolPolicyRef. CEL guards added: mcpServers requires toolPolicy; has() guards on optional vec fields. Verified live on kars-dev: a launched task materializes the correct InferencePolicy + KarsSandbox and reaches Running through the secure router. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… + gate on parent readiness Two correctness fixes that make capability-attenuating delegation (Pillar A / design note §12 'the org chart IS the security topology') honest rather than nominal: 1. Authority-model cohesion. Attenuation previously checked the envelope's toolPolicyRef/egressAllowlistRef, but materialize() composes the sandbox from the blueprint's toolPolicy + inline egress (and egressAllowlistRef was never materialized). A child could therefore pass delegation checks while changing its real tool/egress surface. New spec_attenuation_violations() checks the *effective* authority the sandbox actually enforces: effective_tool_policy (blueprint-or-envelope) and effective_egress (blueprint egress, subset of the parent's, with any-port parent entries covering child ports). The verified subset relation now matches execution. 2. Parent-readiness gating. resolve_delegation() no longer grants a child authority against an unvalidated parent: a child whose parent is not governance-Ready (no envelope digest) resolves to a transient Pending (DependencyMissing) state and requeues quickly, instead of going Ready under a degraded/in-flux parent. Verified live on kars-dev: a subset child → Ready; an egress-amplifying child → Degraded with the exact reason; a child of a degraded parent → Pending. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ndboxes The finalizer-drop used a server-side apply patch that set finalizers: []. The apiserver does not reliably remove a finalizer that way once it no longer attributes the field to this manager — it rejects with 'name must be provided based on URL' (HTTP 400). The reconcile then errors and requeues forever, so the KarsTask sits in Terminating with its cleanup finalizer and its materialized KarsSandbox (and per-sandbox namespace) is never reaped. This is exactly the 'sandboxes pile up' symptom seen in dogfood. Fix: drop the finalizer with a deterministic merge patch (the same operation that clears it by hand). Adding-the-finalizer keeps the apply path (which works) and now also carries metadata.name for correctness. Verified live on kars-dev: launching then deleting a task now reaps the task, its sandbox (owner-ref GC), and its namespace within the delete timeout — no stuck finalizer. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Separate large unit-test modules, add receipt and approval CEL/status metadata, and document the security review so the core governance slice passes LOC, CNCF, drift, and security-audit gates. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Use atomic creation and UID/resourceVersion guarded execution updates and cleanup. Keep empty task egress Strict, normalize runtimes, bind approvals immutably, and fail closed on unsupported subtree token/money launch ceilings. Report completeness as unverified and retry namespace-aware signer initialization. Add API-boundary and contract regressions; Rust execution awaits coordinated validation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Derive claims from verified DSSE predicates and reject mismatched claim, identity, digest, issuer and scheme echoes. Resolve the verifier namespace consistently with the controller. Cover forged PASS echoes with a valid signature and related unsigned metadata tampering. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Carry task UID/resourceVersion through status writes, make approval finalizer updates correctly named and race-checked, and cover cleanup errors retaining Stopping until a successful retry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Share effective runtime, model/provider, instruction and capability-reference normalization between materialization and task authorization hashing. Use the full domain-separated digest for task status, approvals and receipt subjects while retaining the envelope-only lattice digest. Preserve terminal decisions as history but require current task UID, digest, readiness and immutable decision coherence before authorization. Add canonical golden vectors, blueprint drift, replacement, receipt and materialization regressions. Rust execution remains pending the coordinated build window. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Fix regression-test module linkage, boxed Kubernetes Status errors, and jiff-to-chrono approval creation timestamps. Use realistic Kubernetes error reasons in API tests, exercise creation-time expiry, and distinguish lattice and authorization digests in diagnostics without lint waivers. All 103 focused governance/signing/CRD-drift tests and controller all-targets clippy pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Default absent admission/taskNamespaceFloor maps and missing enabled flags to the secure enabled state without resetting saved settings. Preserve the existing explicit boolean false switch and reject malformed flags. Add nine real-Helm compatibility tests using saved values as isolated chart defaults, an old-values fixture, and a Helm CI gate; no new dependencies or global values reset. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Treat an explicitly null taskNamespaceFloor.enabled as unset and keep the security default active, matching envelope-write-lock upgrade semantics. Preserve explicit boolean false and continue rejecting non-boolean scalar flags. Ten isolated real-Helm compatibility tests pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Expose authorization_configuration_with_model as the serializable canonical snapshot already hashed by task authorization. Keep one normalization implementation, preserve the existing digest bytes and golden vector, and document reuse by receipt producers with one resolved model-default snapshot. Add a configuration-shape regression; no wire fields or authorization semantics change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Collect coherent terminal decisions before filtering current authorization. Sign an explicit approvalHistory with original digest/request and immutable task/approval identities, validated decider/generation/timestamps, and non-grant/non-consumption markers. Preserve all current authority/readiness guards. Add D0-to-D1 collector/DSSE and invalid-history regressions; Rust execution awaits the parent's Cargo lease schedule. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
…nance Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Use the existing phase constant without changing behavior. Give the two archive-and-Helm integration cases a bounded timeout consistent with their subprocess budget, retaining all assertions and guards. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Pal Lakatos-Toth (pallakatos)
marked this pull request as ready for review
September 7, 2026 17:30
Pal Lakatos-Toth (pallakatos)
requested review from
Johnson Shi (johnsonshi) and
Lachlan Evenson (lachie83)
as code owners
September 7, 2026 17:30
Refresh the protected integration base without changing the qualified governance content. Human approval remains required before merging this PR. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: eb3654cd-f1e0-445a-8734-430800af1903
Pal Lakatos-Toth (pallakatos)
changed the base branch from
public/pr1-generic-kubernetes
to
kars-bridge
September 8, 2026 11:53
Pal Lakatos-Toth (pallakatos)
enabled auto-merge
September 8, 2026 11:55
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
KarsTasktrust-envelope API and capability-attenuating delegation rulesKarsSandboxresourcesStack
Security properties
Current behavior and review readiness
Ready for independent review at
6a74289e. All exact-head GitHub checks have passed; automated review findings and follow-ups are closed. This is not human approval, and it does not authorize merging into the intermediate feature branch.UnsupportedLaunchBudget; this foundation does not claim durable aggregate budget enforcement. Existing standalone Sandbox daily budgets are unchanged.Prior local qualification
cargo clippy --all-targets --all-features -- -D warnings: passedcargo fmt --all -- --check: passedSecurity audit:
docs/security-audits/2026-09-03-core-governance-apis.md.Publication review contract
#543 has landed in the protected
kars-bridgeintegration branch. This PR now targetskars-bridgedirectly. Merge-base refreshc412fa7echanges ancestry only: its source tree is identical to the previously qualified6a74289e. Fresh required CI and an eligible approving GitHub review remain mandatory; no review requirement is bypassed.Integration landing plan
The public integration branch
kars-bridgestarts at current main7eb039e9. Land the reviewed, fully qualified slices there in order: #543 -> #544 -> #545 -> #547, followed by the remaining bounded layers. Downstream PRs stay stacked for focused review until their parent lands, then retarget to the integration branch. Preserve merge ancestry; do not squash/restack away reviewed history by default.The integration branch has required CI/security gates, up-to-date-base checks, independent approval and conversation resolution, with force pushes, deletion and admin bypass disabled. Its CI pushes must not automatically publish images or releases. Required genuine audit sign-offs are not waived.
Only after complete cross-layer review and qualification of standalone Kars, existing-customer CLI/install/upgrade behavior, and additive Bridge install/removal should a final integration-to-main promotion PR be merged. No partial runtime is being landed directly in main.