Linura v0.9.0

v0.9.0 — First Boot and supported reference environment

Status: Experimental v0.9.0 release contract for First Boot and the exact reference QualificationEnvironment.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.9.0 adds Linura's first bounded supported reference environment and a restart-safe First Boot/provisioning path on that exact environment. The release converts the existing deterministic authority, durable Library and proposal-only interpretation foundations into a reproducible Linura machine-adoption flow while retaining their authority boundaries.

The supported reference is the exact QualificationEnvironment qualification/ubuntu-24.04-lts/amd64/qemu-tcg-headless. The support claim begins from the pinned independently verified Ubuntu cloud-image substrate and covers Linura installation/adoption, First Boot, provisioning, recovery, update and migration behavior described below.

User-visible capability

On the exact reference environment, Linura can start First Boot from local declarative source material, validate the machine, observe current state, derive deterministic desired-state plans, establish a verified recovery checkpoint, resolve ownership/provisioning mode and reach First Boot readiness across system restart without replaying historical authority or blindly repeating already-started external effects.

The release-exposed production provisioning entry is linura-firstboot --bootstrap <absolute-state-root>. It performs restart-safe prepare for another owner adoption and stops at authenticated owner-enrollment-pending only after the preparer OS authority has been directly revoked and re-verified. Interactive-owner, unattended-manifest and selectable recovery provisioning modes remain qualified internal state-machine contracts in v0.9; they are not user-selectable production entry points in this release. Native checkpoint recovery remains separately qualified. Local deterministic operation remains available without a model provider after required installation material is present.

The --bootstrap command is not a raw Ubuntu hardening or installer entry point. It assumes the exact bounded base substrate and required Q8 policy inputs are already present and observable; during bootstrap it re-verifies the security baseline and fails closed if inbound default-deny, SSH-disablement or trusted-source requirements are not satisfied rather than configuring an arbitrary unqualified host.

Implemented scope

Exact reference environment

The v0.9 QualificationEnvironment is exactly:

• machine class: server;
• Ubuntu 24.04 LTS;
• amd64 / x86_64;
• headless interaction;
• QEMU TCG virtualization;
• systemd init/service management;
• base image https://cloud-images.ubuntu.com/releases/noble/release-20260725/ubuntu-24.04-server-cloudimg-amd64.img;
• base-image SHA-256 d1940f7d69d343355e183dff1e08a59852d32e7309baa7a4bad8365b11b005ac.

The environment is identified by qualification/ubuntu-24.04-lts/amd64/qemu-tcg-headless. A different image digest, distribution/release, architecture, interaction mode, init system, machine class or virtualization shape is separate evidence and cannot silently inherit this support claim.

First Boot and source model

The v0.9 First Boot state machine and qualification harness accept bounded declarative source classes: fresh intent, deterministic local defaults, exact local Library Setup/MachineProfile revisions, integrity-bound portable sources and explicit recovery/resume state. Provisioning Manifest v1 is likewise a qualified bounded internal contract. The release-exposed --bootstrap production path intentionally selects the deterministic deferred-owner/default-source path; it does not expose manifest, Library, portable-source or recovery-mode selection as a public v0.9 CLI surface. Those typed contracts remain available for qualification and later productization without becoming authority.

Persisted Setup/MachineProfile selections are resolved by exact revision from the protected Local Library. Production First Boot re-observes the target, reconstructs desired state, derives deterministic non-authorizing ReconciliationPlan material and durably binds the canonical plan digest/count before the planning stage can complete.

Durable bootstrap and ownership

The restart-safe bootstrap prefix is:

base-environment verification → Linura installation → persistent-state initialization → security baseline → provisioning-mode selection → bootstrap-connectivity resolution → hardware discovery → source selection → target observation → First Boot planning → recovery checkpoint → owner-enrollment resolution → First Boot ready.

The persistent ledger is bounded, integrity checked, writer serialized and machine/session bound. A machine-scoped generation anchor outside the mutable bootstrap state root protects against state-root rollback while that anchor remains trustworthy. Crash-reconciliation covers anchor staging, ledger publication and anchor finalization.

Prepared and effect-started stages are resumed through authoritative re-observation rather than blind effect replay. Interactive-owner, deferred-owner, unattended-local and recovery ownership states are durability-qualified across restart, while the v0.9 production CLI exposes only deferred-owner bootstrap. Qualification of a state-machine mode is not a claim that the mode has a user-facing production selector.

Deferred handoff to another owner requires authenticated evidence that the actual preparation principal has lost qualifying process/group/SSH/password/sudo authority before owner-enrollment-pending is recorded. Production First Boot can mint only this narrow preparer-revocation receipt, and only after directly verifying the fixed OS postconditions; it cannot mint final-owner credentials. Final owner enrollment requires separately authenticated, fresh, session/machine-bound Control evidence.

Security baseline and recovery

The v0.9 security baseline requires inbound nftables default deny on the actual input base chain, no active/enabled SSH-serving unit/socket or SSH server process owning a listener on any port, and no explicitly insecure one-line or deb822 APT source override. Qualification infrastructure is isolated from product observation rather than granted a production exemption.

Recovery checkpoints use a strict integrity-bound manifest covering the durable bootstrap ledger, durable session and external generation anchor. Native recovery restores this bundle and verifies resulting state while First Boot, networking and model/provider dependencies are unavailable.

Migration and update

The v0.8→v0.9 migration path operates on the released SQLite authority and Local Library stores. Recovery backup creation excludes concurrent writers, folds committed WAL frames into the independent backup image, validates the image and prevents stale WAL/SHM replay after restore. Migration verification covers the complete released Local Library semantic relation surface and authority transaction semantics.

Update recovery exercises an actually interrupted bounded local dpkg transaction. Restart re-observes the package state, reconciles configuration and requires independently generated authenticated verification evidence before completion. Indeterminate execution cannot create blind-replay authority.

Authority and security boundary

First Boot, bootstrap state, provisioning manifests, recovery state and deterministic plans are state/evidence only. They do not grant policy, approval, executor, shell, model, credential or replay authority.

The v0.8 agent_role = "proposal-only" contract remains unchanged. Model/provider output is never execution authority. Control-owned review/authorization remains the only path into supported managed effects.

The release does not widen the privileged mutation surface. managed_mutation_support = "narrow-experimental" remains the inherited v0.6 bounded systemd active/inactive convergence capability. Package/network/firewall/storage work performed inside qualification to prove install/recovery semantics does not become a generic public mutation API.

Platform and hardware scope

No named PlatformProfile is release-qualified by this contract; Supported platform profiles therefore remains none. The v0.9 platform-support claim is instead the exact QualificationEnvironment ID and values listed under Implemented scope.

The claim excludes bare-metal installation, KVM, ARM64, workstation/desktop interaction, arbitrary Ubuntu/cloud images, other distributions, dual boot, disk partitioning, bootloader management, full-disk takeover and universal server support. Hardware discovery is evidence used for compatibility/planning and never grants mutation authority.

Persistence, migration and upgrade

Durable bootstrap state uses versioned bounded encoding, crash-safe persistence and explicit newer/corrupt state rejection. Provisioning selections, completed-effect verification lineage, deterministic plan binding, owner state and checkpoint lineage remain inspectable after reopen.

The v0.8→v0.9 persistent-store migration requires validated backup/recovery and semantic preservation of released authority and Local Library state. A failure or indeterminate external effect is reconciled from authoritative post-state rather than inferred from prior dispatch intent.

Upgrade and migration evidence remains exact-source and exact-environment scoped. This release does not claim arbitrary historical upgrade paths or downgrade support.

Recovery and rollback

Expected process/system interruption is recoverable at every qualified bootstrap boundary. Prepared/effect-started work is re-observed; completed work is not blindly replayed. Recovery checkpoint restore is independently verifiable and available without First Boot/network/model dependence.

The external generation anchor protects the...

Linura v0.8.0

v0.8.0 — agent interpretation / IntentProposal

Status: Experimental v0.8.0 release contract for proposal-only model/agent interpretation.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.8.0 adds a provider-neutral interpretation layer that can transform natural-language, conversational and agent-originated inputs into typed IntentProposal values. The proposal boundary is non-authoritative: models can suggest structured intent, assumptions and capability references, but cannot approve, authorize, plan privileged execution or execute machine changes.

The release preserves the v0.7 durable intent/Library contract and the v0.6 managed-mutation authority lifecycle. Any proposal that is accepted into authoritative intent is deterministically validated and then follows those existing boundaries.

User-visible capability

Users and higher-level interfaces may ask an enabled model/provider to interpret a requested outcome into a structured proposal, inspect the normalized requirements, assumptions, uncertainty and provenance, reject or revise it, and explicitly accept it into durable typed intent where policy permits.

Linura remains fully operable without a model provider. Manual typed intent and non-agent workflows are first-class paths rather than degraded recovery modes.

Implemented scope

The implemented v0.8.0 scope is bounded to the proposal-only architecture below. These bytes are publication-stable: release authority is established only by Linura's protected proof-first, tag-last lifecycle and independent verification, not by transient wording in this contract.

IntentProposal boundary

The canonical proposal contract includes versioned structured fields for proposal identity, requested outcome, typed proposed requirements, assumptions/unresolved questions, provenance/context binding, provider/adapter identity, uncertainty where available and capability references.

Canonical proposal data is bounded, schema-validated and suitable for hashing/audit. Free-form rationale may accompany it but never overrides typed validation.

An IntentProposal is explicitly not:

• an approval or authorization decision;
• a privileged execution plan;
• an executor capability or credential;
• a committed desired-state change;
• a policy override;
• shell/command text to execute;
• trusted provenance merely because a model generated it.

Provider architecture

Provider-specific request/response encoding, bounded stream parsing and tool syntax remain adapter-specific, but untrusted runtime/adapter logic receives no ambient provider egress, raw/reusable credentials or transport handles. It first produces a bounded credential-free PreparedProviderInvocation, which Control validates against the selected provider/adapter/endpoint profile and attempt bounds. Side-effecting hosted or local provider transport is isolated behind a trusted invocation gate. For every admitted attempt, Control mints an unforgeable single-use ProviderInvocationPermit exact-bound to the attempt, selected adapter/provider/endpoint class, canonical interpretation-request and prepared-invocation digests, network/offline classification, per-attempt bounds and aggregate orchestration state. Only the gate receives, verifies against the exact prepared invocation and atomically consumes that permit before credential resolution, authentication, DNS, socket, process/session or provider transport initialization; the adapter/runtime cannot construct or replay it or bypass the gate.

Retry mechanics are not adapter-owned. One permit authorizes at most one provider invocation and is spent on success, timeout, rate limit, transport failure, cancellation or partial response. Automatic client retries, redirects that initiate another request, authentication-challenge replay, uncertain-write replay and stream reconnect/resume are disabled. The adapter must return every failure/partial outcome to Control without internally retrying, reissuing or starting a replacement/resume request. Every repeated provider invocation requires a fresh Control admission and permit and remains charged against the original Control-owned aggregate budget and deadline.

The proposal contract is provider-neutral and supports deterministic mock/replay qualification plus local/offline, hosted and enterprise-managed implementations as adapters become available. Linura Control owns provider eligibility/discovery, selection, cross-adapter scheduling, aggregate deadlines/budgets, timeout/cancellation policy, retry/fallback/advisor admission, caching/coalescing and aggregation. The agent runtime executes only a bounded Control-admitted attempt for one selected adapter and cannot autonomously select, retry, fallback, reset aggregate budgets or aggregate providers/advisors.

Linura Control constructs the bounded semantic projection before it crosses into the agent runtime. Raw secret-bearing Library, observation, retrieval or user context is not handed to the runtime for filtering. Secret values, privileged tokens, authority credentials and protected secret-bearing fields are removed before the runtime/provider boundary; only protected references/handles or intentionally non-secret metadata may cross where semantically required.

Provider credentials and reusable transport handles remain private to the trusted invocation gate/credential resolver and never enter runtime/adapter logic or proposal payloads. Runtime/adapter diagnostics and audit records must not expose secret-bearing source context or arbitrary provider response bodies.

When offline mode is active, a network-required adapter must be rejected before adapter invocation or transport initialization. Provider selection, discovery, health-check, fallback, authentication, DNS and socket setup must remain unable to trigger network activity. Release qualification must prove this with deterministic invocation/transport traps whose counters remain zero.

Deterministic acceptance path

Before a proposal becomes durable authoritative intent, Linura must use the dedicated v0.8 Linura Control-owned acceptance path. That path:

1. validates proposal schema/version, bounded content and canonical digest;
2. obtains the authenticated Principal independently from trusted transport/session state and treats proposal Actor data as provenance only;
3. re-establishes current authority-bearing observation, policy, Library, capability-registry and existing-intent dependencies;
4. re-checks time-based observation freshness using trusted Control time, reacquiring authoritative observation where a validity window expired and failing closed if fresh evidence cannot be established;
5. derives the current Control-owned context binding and requires exact equality with the proposal binding;
6. resolves referenced capabilities only against the current Control-owned local registry;
7. requires the applicable Control-owned acceptance decision to be exact-bound to authenticated principal + proposal ID/digest + accepted context binding + durable operation identity + create/revise action + exact target identity/revision expectation;
8. acquires the authority-internal durable acceptance transaction/write-CAS guard before final authority revalidation;
9. while that durable guard is held, revalidates the complete context/freshness/capability/decision binding using monotonic fail-closed trusted Control time, normalizes every time-limited authority contributor to its exclusive first-invalid instant, derives the earliest required authority-validity deadline, captures the final-revalidation trusted-time sample as the sealed authority-time floor, and fails closed on authority-generation, target-revision, freshness, decision drift or expiry;
10. mints a transaction-scoped sealed exact-bound acceptance-commit capability carrying both the authority-time floor and authority-validity deadline;
11. consumes the capability through the authority-internal Library acceptance primitive without releasing/reacquiring the durable guard, mechanically re-sampling trusted Control time at the actual intent+acceptance-record write/CAS linearization and aborting/rolling back unless time_floor <= now < deadline; a backward sample below the floor is an authority-clock failure and cannot revive expired authority; and
12. atomically commits the resulting normal Intent in Proposed state together with the durable acceptance record containing the decision identity/binding, exact principal/proposal/context/operation/action/target material, authority-generation/freshness evidence, decision/approval validity evidence, sealed authority-time floor, enforced authority-validity deadline, endpoint-normalization evidence, and resulting IntentId/revision.

The authority-internal Library acceptance primitive is not exposed as a public LocalLibrary/SDK proposal-acceptance mutation and does not accept caller-constructible authority fields. Its sealed commit capability is minted only by Linura Control after final exact-bound revalidation, is not deserializable from untrusted input, is exact-bound to the durable transaction, sealed trusted-time floor and earliest required authority-validity deadline, and is consumed for one durable linearization attempt.

All time-bounded authority must remain valid at the actual durable write/CAS linearization, not merely when the capability is minted. A database-lock, scheduler or internal-I/O delay after minting that crosses the sealed deadline—whether because observation freshness or decision/approval applicability expires—must cause rollback and fresh re-entry through Linura Control rather than commit stale or unauthorized acceptance. Trusted Control time must also remain monotonic for the in-flight transaction: a post-mint backward/reset/continuity-unknown sample fails closed even when it would otherwise satisfy now < deadline.

The pre-v0.8 public LocalLibrary::create_intent operation by itself is not ...

Linura v0.7.0

v0.7.0 — persistent intent lifecycle and local Linura Library

Status: Experimental v0.7.0 release contract for persistent intent lifecycle and the local Linura Library.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.7.0 adds Linura's first durable user-owned declarative persistence layer above the v0.6 authority plane. Intents survive restart with immutable revisions and a legal lifecycle; reusable configurations can be stored as versioned Setups and MachineProfiles; and declarative state can be exported, validated, imported and dry-run adopted without importing mutation authority.

The release does not widen the privileged effect surface. The only release-qualified managed external effect remains the v0.6 canonical linura-managed-*.service active/inactive convergence path.

User-visible capability

v0.7 exposes the local Linura Library through the Experimental SDK/workspace surface. Users and higher-level interfaces can persist intent history, save/revise Setups and MachineProfiles, inspect causal ownership/removal impact, create deterministic portable Setup/Profile artifacts, validate/import them, dry-run adoption, and perform validated local Library backup/restore.

Adoption itself does not execute Linux changes. Any resulting machine change requires fresh target observation, planning, validation and authorization through the existing authority lifecycle.

Implemented scope

The v0.7 implementation includes:

• lifecycle proposed -> active <-> suspended -> superseded | retired with immutable history, optimistic concurrency and exact-operation idempotency;
• explicit predecessor/successor supersession and restart-safe current projections;
• append-only Setup/Profile revisions with exact composition references;
• causal desired-state provenance and ownership/removal-impact evidence that fails closed when incomplete;
• deterministic bounded SHA-256-integrity-bound portable Setup/Profile encoding;
• parse/validate-before-mutation import and transactional direct adoption;
• dry-run reporting for create/reuse, collisions, missing secret references, machine-class mismatch and unsupported capabilities;
• SQLite schema-v1 persistence, migration, integrity validation, backup and restore;
• non-privileged SDK exposure without a new privileged release binary;
• permanent dedicated v0.7 qualification integrated into Trusted Release Proof.

Authority and security boundary

Portable/Library state is declarative only. It never contains or restores human approval, policy authorization, executor authority, transaction authority, integrity keys, secret values or machine-private operational state.

Secret references use one canonical constrained namespace:name grammar with a 256-byte bound across schema, persistence, export and adoption. Conflicting logical intent/setup revisions are rejected across the complete reachable composition closure, while equivalent ordering is canonicalized.

Restore validates canonical Library schema identity and foreign-key integrity before replacing the destination. Attacker-controlled SQLite schema metadata is count/size bounded before materialization. Same-version alien schemas, corrupt/newer backups, oversized schema definitions and excessive schema-object counts fail closed without replacing the active valid database.

Models and agents remain proposal-only and receive no executor handle. The v0.6 human-approval, durable prepare/handoff, narrow executor and independent-verifier boundaries remain unchanged.

Platform and hardware scope

No Linux distribution, desktop/headless environment, machine class, physical hardware tier, virtualization platform or fleet environment becomes a supported product profile in v0.7.0. Workstation/server/edge remain declarative target classes only.

Repository CI/qualification environments are evidence infrastructure, not support declarations.

Persistence, migration and upgrade

The local Library uses SQLite with foreign-key enforcement, WAL journaling, FULL synchronous durability, explicit schema versioning and repository-defined forward migration. Unsupported newer schema versions and corrupt/incompatible databases fail closed.

Setup/Profile and intent revision layers are append-only; current projections are derived transactionally. Stable operation identities remain semantically bound across restart and reject changed-content reuse.

The workspace version advances coherently to 0.7.0 during release preparation. Product SemVer, portable-format version, Library database schema version and other contract generations remain separate axes.

Recovery and rollback

Multi-record Library writes and adoption operations are transactional: failure/crash qualification requires either the old complete state or the new complete state, never a partial projection/history pair.

Library backup/restore is a local operational recovery mechanism distinct from portable export. Restore validates the source before replacement and preserves revision history, lifecycle lineage, ownership and idempotency state. Invalid restore sources leave the existing destination intact.

External machine rollback/removal is not granted by Library state. Cleanup eligibility is read-only causal evidence; any supported external effect still requires fresh authority and remains bounded by the v0.6 managed-mutation capability.

Compatibility boundary

All v0.7 intent/Library SDK APIs, SQLite schema and portable formats remain Experimental. Breaking pre-1.0 changes remain permitted when implementation, migrations, checked contracts, tests and documentation change coherently.

Portable v0.7 artifacts do not promise compatibility with unsupported-newer formats, and unsupported input is rejected rather than guessed or downgraded.

Required acceptance evidence

Publication requires:

• reviewed release-preparation exact-head CI, Security, CodeQL and dedicated v0.7 Library qualification;
• a single-parent tree-identical metadata-only release authorization with exact reviewed-source/tree trailers;
• fresh protected-main CI, Security and CodeQL for that authorization;
• Trusted Release Proof rerunning the dedicated v0.7 qualification and every inherited mandatory v0.4/v0.5/v0.6 release gate;
• sealed deterministic release construction with checksums, SPDX SBOM, build environment, release evidence, proof receipt and provenance/attestations;
• independent byte-for-byte reproduction of every distributable binary;
• promotion only after proof success;
• tag-last immutable v0.7.0 publication without rebuilding the sealed payload;
• independent published-release redownload/verification;
• protected post-release closure before roadmap advancement.

Development or implementation-head runs are supporting evidence only and never substitute for release-authorization proof.

Known limitations and unsupported states

• The Library is local-first; no hosted synchronization or remote/fleet Library authority is released.
• No supported distribution or machine profile exists yet.
• Portable adoption does not resolve missing secret values and never stores them.
• Unsupported desired-state capabilities can be reported but cannot become executable through the Library.
• Cleanup/removal eligibility fails closed when causal ownership is unknown, stale, corrupt or incomplete.
• Only the inherited v0.6 canonical managed systemd active/inactive effect can cross the privileged executor boundary.
• No multi-machine atomicity, generic snapshot rollback or universal recovery guarantee is claimed.

Explicit non-goals

v0.7.0 does not claim generic apply/root authority, arbitrary systemd control, package/file/network/storage/firewall/user/container/VM mutation, secret synchronization, hosted/remote/fleet Library authority, agent interpretation/execution authority, First Boot, a supported reference environment, Stable API compatibility or production readiness.

Traceability

• #93 — initial persistent lifecycle/Library implementation and permanent qualification integration.
• #94 — corrective review closure and hardening for restore/schema bounds, secret-reference consistency and portable composition-revision consistency.
• 92d0696 — corrected protected-main implementation source after guarded #94 merge.
• Qualification dossier: docs/qualification/v0.7.0.md.
• Security qualification: docs/qualification/v0.7.0-security.md.
• Release-preparation review: docs/qualification/v0.7.0-release-review.md.

Corrective PR #94 final exact head fa47a0e6040e6c267db07d1ee085ee5c1bedb3a6 passed CI 34082690256, Security 34082690270, CodeQL 34082690244, dedicated v0.7 qualification 34082690234, all review-thread closure, and a final exact-head Codex review reporting no major issues. Protected main 92d06961... then passed fresh CI 34083271533, Security 34083271504, and CodeQL 34083271502.

Artifacts and supply-chain evidence

The sealed distributable binary set remains exactly:

• linurad;
• linuractl;
• linura-authorityd;
• linura-update-guard;
• linura-executor-systemd.

The local Library remains a workspace/SDK component rather than an additional binary. linura-firstboot remains excluded.

Trusted Release Proof must bind the exact authorized source/version and frozen release notes to the repository-defined release evidence, checksums, SPDX SBOM, build-environment identity, proof receipt and provenance/attestations, and a separate fresh runner must reproduce all distributable binaries byte-for-byte before promotion.

Publication evidence

Publication is established only by the protected proof-first/tag-last lifecycle: a reviewed tree-identical metadata-only release authorization, successful Trusted Release Proof and promotion, immutable tag/GitHub Release publication from ...

Linura v0.6.0

v0.6.0 — complete bounded managed mutation lifecycle

Status: implementation qualified; release candidate; publication evidence remains pending the protected proof-first/tag-last release lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.6.0 is Linura's first milestone permitted to integrate the complete canonical managed-mutation lifecycle for one deliberately narrow external effect. The bounded effect is systemd active-state convergence for canonical linura-managed-*.service units, with the desired state limited to exactly active or inactive.

The release does not generalize this into arbitrary system management. It establishes one end-to-end authority path that preserves durable reviewed authority, explicit human approval, a separate executor authorization boundary, independent postcondition verification, fail-closed ambiguity recovery, commit/audit integrity and reconciliation.

User-visible capability

The candidate introduces one Experimental managed-authority entry point:

• D-Bus service/interface: org.linura.Authority1;
• object path: /org/linura/Authority1;
• method: ConvergeSystemdActiveState;
• resource namespace: canonical systemd:unit:linura-managed-*.service;
• desired state: active or inactive only.

A successful request may dispatch native systemd StartUnit(unit, "replace") or StopUnit(unit, "replace") only after the complete authority lifecycle establishes fresh durable execution authority. The method remains Experimental and is not a Stable compatibility commitment.

Implemented scope

The bounded v0.6 composition consists of:

• linura-control::ManagedLifecycleControl over the existing durable authority transaction/recovery substrate;
• stable operation identity mapped to a durable request identity and exact canonical request digest;
• the canonical eleven stages: request/intent → observe → plan → validate → authorize → prepare → execute → verify → commit → audit → reconcile;
• Experimental org.linura.Authority1 transport/caller-binding surface;
• dedicated unprivileged linura-authorityd composition/runtime service;
• protected SQLite/WAL authority state and integrity material owned by the authority service boundary;
• separately hardened root linura-executor-systemd service;
• managed executor operation SetManagedActiveState for the exact bounded systemd effect;
• fresh native-systemd observation and independent postcondition verification;
• exact committed retry/idempotency and changed-request substitution rejection;
• durable indeterminate/recovery behavior that does not reconstruct or blindly replay one-shot dispatch authority;
• component maturity and release-artifact governance that prevents future scaffolds from silently becoming current release claims.

The executor remains a narrow effector. It does not own planning, policy, durable recovery, truth about resulting machine state or generic orchestration.

Authority and security boundary

The v0.6 path deliberately separates four trust decisions:

1. the original system-bus caller is authenticated from D-Bus message metadata rather than caller-supplied identity;
2. the bounded Authority1 request requires the fixed human Polkit action org.linura.authority.manage-systemd-active-state;
3. linura-control establishes the exact fresh reviewed/durable authority and crosses the durable Prepared → Indeterminate ambiguity boundary before external dispatch can occur;
4. the root executor independently authorizes the dedicated linura-authority service identity for org.linura.executor.systemd.set-active-state and revalidates the bounded effect at the privilege boundary.

Human approval is not an executor credential. Serialized transaction IDs, operation IDs, digests, durable rows and executor receipts are correlation/evidence material, not bearer authority.

Direct ordinary-user and direct root/admin use of the supported managed executor action remains denied by product policy. Test-only qualification grants live only under disposable acceptance infrastructure.

Executor acknowledgement proves dispatch at most. Verified success requires a separately composed fresh native-systemd observation and independent verifier result. Stale, inconclusive, contradictory or missing evidence cannot commit.

Models and agents retain proposal-only authority and receive no privileged executor handle.

Platform and hardware scope

No Linux distribution, desktop/headless profile, machine class, physical hardware tier, virtualization platform or fleet environment is supported by the v0.6.0 product claim.

Repository qualification uses a SHA-256-pinned Ubuntu 24.04 LTS amd64 cloud image under disposable QEMU/TCG infrastructure with real systemd, system D-Bus, Polkit and SQLite/WAL. That guest is qualification infrastructure only and must not be interpreted as a supported Linura platform profile.

The planned first supported Experimental reference environment remains a later roadmap milestone.

Persistence, migration and upgrade

v0.6 continues the v0.4 durable authority model and qualified SQLite/WAL persistence boundary. Stable managed operation identity is additionally protected by an exact durable canonical request digest so the same operation ID cannot be rebound to changed request content.

The authority runtime stores state under its protected service state directory and retains the existing migration/integrity rules. Persistence never substitutes for authoritative Linux observation.

The workspace package version must advance coherently to 0.6.0 only during final release preparation. Product SemVer, D-Bus contract generation, persistence schema generation and contract stability remain separate axes.

Transparent replacement of the complete authority database with an older internally coherent copy or host/VM snapshot remains outside the claimed recovery guarantee unless separately protected by a future independently anchored restore protocol.

Recovery and rollback

A durable Prepared generation is not a reusable executor credential. Immediately before possible external dispatch, Control revalidates current authority and atomically crosses the exact durable generation to Indeterminate; only the winning in-process path receives the non-serializable one-shot handoff authority.

After restart, an Indeterminate generation cannot reconstruct that dispatch authority and is never blindly replayed. Recovery requires fresh authoritative observation. Intended-state-present recovery may verify the exact current generation; proven no-effect recovery may retire it and prepare a fresh generation only through current authority re-establishment; conflicting state blocks recovery rather than being overwritten.

Recovery approval is bound to the exact fresh recovery candidate. The candidate is constructed once before FreshRecoveryApproval is minted and the approval may be consumed only for that same candidate.

Verification failure does not commit and does not grant replay permission. Reconciliation failure after a successful verified commit retries verification/planning/reconciliation, not the already committed external effect.

Native administrator break-glass recovery remains outside Linura authority and is not replaced by this managed path.

Compatibility boundary

org.linura.Authority1, org.linura.Executor.Systemd1, the Rust component APIs and all related v0.6 managed-authority contracts remain Experimental. Version/generation names such as Authority1 and Systemd1 do not make those contracts Stable.

Breaking pre-1.0 changes remain permitted when implementation, checked contract, tests, documentation and contracts/stability.toml are updated coherently. No compatibility promise is made for direct third-party invocation of the root executor, internal durable authority material, qualification fixtures or test-only policy.

The v0.6 capability does not revive superseded generic apply/provider-owned planning or mutation paths.

Required acceptance evidence

Publication requires fresh exact-source evidence after the implementation/docs history is final:

• canonical CI success;
• Security success;
• CodeQL success;
• authoritative-observation disposable-VM acceptance;
• Control1 plan-preview acceptance;
• v0.4 durability fault qualification;
• v0.4 real filesystem/ENOSPC qualification;
• v0.5 isolated executor/verifier qualification;
• dedicated v0.6 managed-lifecycle disposable-VM qualification;
• successful deterministic eleven-case v0.6 recovery/failure matrix on the exact candidate;
• live Authority1 and executor D-Bus introspection agreement with checked XML;
• real ordinary/root executor-bypass denial;
• real inactive→active and active→inactive one-dispatch success;
• exact retry without duplicate dispatch and changed-body substitution rejection;
• verification-not-satisfied without false commit/replay;
• executor loss + authority restart without reconstructed dispatch permission;
• SQLite WAL/integrity success;
• Trusted Release Proof success on the exact tree-identical release authorization;
• independent byte-for-byte reproduction of every distributable binary;
• tag-last publication and independent published-release verification.

Development runs on intermediate SHAs are diagnostic evidence only. Terminal run IDs/source SHAs must be recorded only after the final compacted source actually passes.

Known limitations and unsupported states

• Only linura-managed-*.service active/inactive convergence is in scope.
• An already-satisfied requested state is treated as no external effect rather than a mutation success path.
• Package, file, network, storage, firewall, user, boot, container, VM and arbitrary service management remain unsupported.
• No generic shell, arbitrary executable, generic systemd method forwarding or unrestricted privileged D-Bus proxy exists.
• No supported distribution, machine class, hardware profile, flee...

Linura v0.5.0

v0.5.0 — isolated privileged executor and independent verifier qualification

Status: implementation qualified; publication pending protected proof-first/tag-last lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.5.0 qualifies Linura's first deliberately narrow privileged effect component and a separate independent postcondition verifier without publishing a supported Linura-managed external mutation path.

The qualified slice is a restart of a disposable linura-v05-qualification-*.service systemd fixture. The executor authenticates the system-bus sender, requires the fixed Polkit action, revalidates the exact namespaced effect/binding, dispatches native systemd RestartUnit, bounds the native method wait, and distinguishes rejection, dispatch acknowledgement, and indeterminate outcome. A separate verifier evaluates only fresh canonical authoritative systemd observation and never treats executor success as machine-state proof.

The release intentionally stops before the v0.4 durable one-shot DispatchPermit is connected to the executor. Therefore executor_state = "isolated-qualified", managed_mutation_support = "none", and complete_lifecycle = false remain the v0.5 product boundary.

User-visible capability

v0.5.0 does not add a supported user-facing mutation command. Existing Experimental observation, deterministic plan-preview, policy/review, approval, and durable transaction/recovery foundations remain available, while the new executor/verifier is qualification-only infrastructure.

There is no public Control1, linuractl, linura-sdk, agent, First Boot, or Control Center apply, execute, mutate, restart, or equivalent method in this release. The presence of a privileged executor binary is not a claim that end users can or should use it as a generic root service.

Implemented scope

• linura-provider-sdk defines bounded component digests, deterministic effect descriptors, execution bindings, structured execution dispositions, and structured verification outcomes.
• Binding material preserves exact transaction, generation, state-version, authority-binding, authority-use, provider/resource, operation, effect and dispatch correlation without becoming bearer authority.
• linura-executor-systemd runs as a separately hardened root system service on the system bus.
• The only qualified method is the fixed QualifyRestart operation for canonical linura-v05-qualification-*.service fixtures.
• Caller identity comes from the authenticated unique D-Bus sender and the fixed org.linura.executor.systemd.qualify-restart Polkit action is checked before dispatch.
• Unit namespace and exact effect/binding material are revalidated at the privilege boundary.
• The executor uses native org.freedesktop.systemd1.Manager.RestartUnit(unit, "replace"); no arbitrary command, shell text, environment injection, file write, or generic systemd method gateway exists.
• Outgoing executor D-Bus method calls use a five-second method timeout. Any error after the native dispatch attempt, including timeout, is Indeterminate unless absence of dispatch is independently provable.
• Canonical Linux observation records ActiveEnterTimestampMonotonic and native authority/freshness metadata.
• linura-verifier-systemd is pure over a canonical ObservationEnvelope, has no executor/native transport dependency, and requires exact identity, current native authority, loaded/active state, and a strictly advanced activation timestamp.
• Permanent layering and anti-drift tests prevent executor authority expansion, verifier self-attestation, broad production Polkit grants, loss of hardening, and accidental public mutation surfaces.
• Trusted Release Proof requires the exact-source v0.5 disposable executor/verifier VM before sealed build and promotion.

Authority and security boundary

The executor is a narrow effector, not a second control plane. Transaction IDs, digests, reviewed plans, policy Allow, approval evidence, durable transaction rows, execution bindings, and executor receipts are not independently sufficient execution authority.

The qualification caller must be authenticated by the system bus and separately authorized by Polkit. Production policy is deny-by-default for ordinary callers; the permissive qualification principal exists only under disposable acceptance-test infrastructure.

The verifier is independent of the executor. Dispatched proves only that systemd acknowledged the method call. Intended state is satisfied only when fresh canonical native observation matches the exact expected provider/resource/capability/unit and proves an activation timestamp strictly newer than the pre-dispatch baseline.

A native dispatch timeout is not treated as no-effect. Because an effect may have occurred before the reply was lost, the result is Indeterminate; subsequent logic must obtain authoritative observation rather than blindly retrying.

Models and agents remain proposal-only and have no path to the qualification action. v0.5 does not serialize, persist, reconstruct, or weaken v0.4's process-local one-shot dispatch authority.

Platform and hardware scope

No Linux distribution, desktop/headless profile, machine class, physical hardware tier, virtualization platform, or fleet environment is supported by the v0.5.0 product claim.

Repository qualification uses a SHA-256-pinned Ubuntu 24.04 LTS amd64 cloud image under disposable QEMU/TCG infrastructure. That environment is evidence infrastructure only; it is not a supported Linura platform profile.

Persistence, migration and upgrade

v0.5 introduces no new durable authority-store schema or migration. The v0.4 SQLite/WAL transaction and recovery foundation remains the durable authority substrate and its released migration identities remain unchanged.

Executor binding material is correlation/integrity material, not a new persistence credential. v0.5 does not persist or reconstruct DispatchPermit, does not turn durable rows into executor bearer tokens, and does not add a product upgrade path that enables external effects.

The workspace package version advances coherently to 0.5.0; persistence schema versions, Control1 D-Bus generation, checked *.v1 schemas and product semantic version remain independent axes.

Recovery and rollback

v0.5 qualifies component-level ambiguity handling but does not integrate complete execute/recover/commit orchestration. Rejection before dispatch is distinguishable from successful dispatch acknowledgement; any provider/transport error after the dispatch attempt is conservatively Indeterminate.

The executor method wait is bounded. A timeout or lost reply cannot create safe retry authority. Authoritative post-observation is required to determine whether the intended effect occurred.

v0.4 durable crash/recovery semantics remain unchanged, but v0.5 deliberately does not connect the one-shot durable handoff to the privileged executor. Full retry/recovery integration after an indeterminate real external effect belongs to v0.6 complete-lifecycle qualification.

Compatibility boundary

All v0.5 component contracts remain Experimental. The qualification-only D-Bus executor interface is not a supported public product API and may evolve coherently before any Stable contract is declared.

No compatibility promise is made for direct third-party invocation of org.linura.Executor.Systemd1, the qualification Polkit action, fixture namespace, example binding/verifier helpers, or acceptance infrastructure.

Existing public observation/preview/review semantics are not widened into execution authority. v0.5 does not revive superseded generic apply/provider-owned planning paths.

Required acceptance evidence

The principal implementation is PR #64, exact final head 1d1f9cf43f0cc45beb1db8e8b7265f2790933fdb, guarded squash-merged as 4102512896ed034dbc4f743a18b05ae54249170b. Its exact-head qualification passed CI 33931164166, Security 33931164159, CodeQL 33931164178, authoritative-observation VM 33931164176, Control1 plan-preview VM 33931164313, v0.4 ENOSPC 33931164283, v0.4 durability 33931164224, and v0.5 executor/verifier VM 33931164168.

Fresh review found one remaining acceptance gap: outgoing privileged systemd method waits were not explicitly bounded even though timeout/indeterminate evidence was required. PR #69, exact head 73aa4d9fb28972d0cfccda5de92d8de4ea415d30, fixed that gap with a five-second zbus method timeout plus permanent timeout-to-Indeterminate regression. It passed CI 33963220513, Security 33963220434, CodeQL 33963220525, and the exact-source v0.5 VM 33963220495, then guarded squash-merged as 3e0297f18b9f809d5e5f5b110adcebfe4aec1ffc.

The corrected protected-main implementation source then passed fresh CI 33963551394, Security 33963551453, and CodeQL 33963551461. Release preparation must additionally pass its own exact-head PR gates. The subsequent tree-identical release authorization must pass fresh exact-SHA protected-main CI/Security/CodeQL, and Trusted Release Proof must rerun observation, plan-preview, v0.4 durability, v0.4 ENOSPC, and v0.5 executor/verifier qualification before sealed build/promotion.

Known limitations and unsupported states

• No supported Linura-managed external mutation exists in v0.5.
• The qualification executor is isolated from linura-control; v0.4 DispatchPermit cannot reach it.
• No complete authorize → prepare → execute → verify...

Linura v0.4.0

v0.4.0 — durable transaction and recovery foundation

Status: implementation complete; publication evidence is established only by the protected release lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.4.0 proves an Experimental durable reviewed-authority transaction and recovery foundation on top of the v0.3 review/approval boundary, without adding a supported executor or a Linura-managed external machine effect.

The qualified authority path is:

authenticated principal + reviewed plan + current authoritative observation
→ Control-owned prepare revalidation
→ immutable durable transaction/generation binding
→ fresh handoff-time principal/observation/policy/risk/approval revalidation
→ durable Prepared → Indeterminate CAS
→ one-shot process-local non-reconstructible dispatch permit
→ authoritative recovery classification
→ Verified / RecoveryBlocked / explicit no-effect N+1 reprepare
→ verified commit metadata + append-only authenticated audit

No v0.4 path invokes an executor. The durable handoff/recovery machinery closes authority, crash, concurrency, integrity, migration, and storage-recovery boundaries before executor qualification begins in v0.5.

User-visible capability

v0.4.0 adds no supported apply/execute/mutate product surface. Existing Experimental observation, deterministic plan-preview, and plan-review capabilities remain available. The durable transaction/recovery foundation is an internal authority substrate exercised by deterministic tests and repository-owned qualification.

A transaction ID, generation, durable Prepared, Indeterminate, Verified, or committed record is evidence about the authority lifecycle; none is a public mutation credential. A process-local dispatch permit is sealed, non-cloneable, non-serializable, non-persistable, and non-reconstructible after restart, and v0.4 has no executor that can consume it to change Linux.

Implemented scope

• Persistence-neutral linura-transaction domain with typed transaction/generation identities, deterministic domain-separated authority bindings, immutable generation history, idempotency, transition rules, and recovery serialization.
• Control-owned non-cloneable transaction signer; persistence receives verification authority only and cannot mint trusted Control requests or dispatch permits.
• Current authenticated-principal binding plus prepare/handoff/recovery revalidation of authoritative observation, trusted review, policy/risk provenance, and required approval.
• Signer-authenticated validity windows enforced after SQLite write serialization so lock waits cannot extend expired authority.
• Restart-safe handling of durable Prepared, sticky Indeterminate, durable verified commit material, resume/commit, and explicit no-effect recovery into exactly one next generation.
• SQLite/WAL persistence with synchronous=FULL, application/schema identity, immutable migration ledger, exact V1→V2 migration validation, and bounded live-schema validation.
• Separately provisioned SqliteIntegrityKey authenticating retained transaction, generation, and audit records; raw writers can alter bytes but cannot mint valid keyed integrity tags.
• Literal CI pins for released migration bodies so an assigned V1/V2 migration identity cannot silently drift with runtime checksum code.
• Bounded persisted-input materialization, aggregate capacity checks, logical audit reservations, and physical recovery reservations.
• Same-filesystem physically allocated recovery reserve with at least 1 MiB per slot, crash-tail reconciliation, regular-file/path/inode/device/link validation, and fail-closed replacement/symlink handling.
• Explicit open_for_terminal_recovery and open_for_terminal_recovery_with_limits for qualified true-ENOSPC Prepared retirement. Before SQLite opens, only the dedicated opener slot may be physically deallocated through bounded Linux hole punching while logical sidecar length is preserved.
• Terminal-recovery open blocks normal prepare/handoff/recover/commit authority and preserves caller-supplied StoreLimits.
• Every audit-reservation DELETE is filesystem-neutral while SQLite can still roll back. Physical reserve shrinking occurs only after durable SQLite commit through authenticated, write-serialized reconciliation, including multi-reservation retirement.
• Non-mutating database identity/schema preflight before persistent journal-mode transition, preventing rejected unrelated SQLite databases from being modified.
• Permanent positive/negative/concurrency/fault regressions covering authority substitution, raw-persistence tampering, forged/replaced history, migration compatibility, custom recovery limits, one- and two-reservation rollback, restart/resume, CAS races, stale/mixed evidence, key lifecycle, capacity exhaustion, real ENOSPC recovery, and durability faults.

Authority and security boundary

Models, agents, transports, and ordinary callers remain untrusted proposers. linura-control owns trusted prepare, handoff, recovery, and commit orchestration. Persistence verifies authenticated requests and retained records but does not own policy, approval, principal authentication, or authority minting.

Policy Allow, approval evidence, a reviewed plan, transaction/generation identity, durable Prepared/Indeterminate/Verified state, or an audit row does not authorize a Linux mutation. v0.4 adds no public apply/execute/mutate API, generic privileged command surface, Polkit grant, supported executor integration, or Linura-managed external effect.

Raw filesystem/database writers can physically modify SQLite bytes. v0.4 protects retained authority history by keyed record authentication, schema/migration identity, immutable-history checks, and fail-closed validation. It does not claim that coherent rollback of the entire authority database/filesystem/VM snapshot can be detected without a future independently protected monotonic anchor/restore protocol.

Platform and hardware scope

No Linux distribution, desktop/headless profile, machine class, hardware tier, virtualization profile, or fleet environment is supported by the v0.4.0 product claim.

Repository qualification uses disposable Ubuntu 24.04 LTS amd64 QEMU guests and explicitly exercises loop-mounted ext4 ENOSPC plus SQLite/WAL fault scenarios. Those environments are evidence fixtures, not supported Linura platform profiles.

The durability claim is limited to named local-filesystem/storage assumptions that honor the locking and sync behavior exercised by qualification. PRAGMA synchronous=FULL is part of the design but is not presented as a universal hardware/storage durability guarantee.

Persistence, migration and upgrade

v0.4.0 introduces the first release-qualified local durable authority database for transaction/recovery state. SQLite carries explicit application/schema identity, repository-visible migration identity, immutable migration-ledger verification, bounded schema validation, and fail-closed handling of corruption, unsupported newer schema, and migration mismatch.

Released schema V1 remains immutable. Existing canonical schema-v1 stores are authenticated against the historical V1 schema fingerprint, exact one-entry migration ledger, and authority-store identity before the additive V2 migration is applied. V2 installs terminal-recovery trigger semantics, records its own ledger checksum once, and advances user_version to 2. Fresh stores apply V1 then V2. CI independently pins the literal released V1/V2 bodies.

Durable idempotency is scoped to one monotonic authority-database history. Exact retained generations are immutable and one current-generation/state-version serialization point governs mutually exclusive recovery outcomes. The store maintains bounded authenticated audit history and explicit logical/physical recovery reservations rather than silently evicting authority history under capacity pressure.

An unrelated or unidentified existing SQLite database is rejected before Linura makes a persistent journal-mode change. A genuinely empty unidentified database can be initialized transactionally and restartably.

Recovery and rollback

Indeterminate is sticky across restart and never becomes retry authority merely because a process restarted or a permit was lost. Recovery requires fresh authoritative re-observation and current authority revalidation.

Authoritative intended-state evidence may advance only the exact current indeterminate generation to Verified; conflicting evidence may advance only that exact generation to RecoveryBlocked; ambiguous or stale evidence leaves it indeterminate. Authoritative no-effect evidence can permit explicit current-authority re-establishment and exactly one N+1 Prepared generation while retiring N atomically; it does not itself grant retry authority.

For a qualified Prepared terminal exit at genuine filesystem ENOSPC, the sidecar retains a dedicated opener slot. A special recovery open validates the database/sidecar path and SQLite page size before SQLite open, punches only that opener slot while keeping the sidecar's logical layout stable, then opens and validates the authority database. The special mode cannot silently become generic mutation authority.

Reservation deletion itself never shrinks filesystem reserve while the SQLite transaction can roll back. This invariant applies at every reservation cardinality. After a successful durable transition, authenticated post-commit reconciliation shrinks only provably excess physical allocation. Therefore a process death or failed SQLite commit before durability leaves the full rollback-required reserve shape intact, while a crash after commit but before cleanup leaves only excess allocation that a later open may safely shrink.

Real loop-mounted ext4 qualification proves Prepared retirement after true ENOSPC, new-process terminal-recovery open, durable abort, reopen, unmou...

Linura v0.3.0

v0.3.0 — policy, authorization, approval, and plan review

Status: implementation complete; publication evidence is established only by the protected release lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.3.0 proves Linura's review-only authority boundary on top of the authenticated observation and deterministic non-executable planning released in v0.1.0–v0.2.0. Linura can derive a trusted risk classification from the exact canonical reconciliation plan, evaluate deterministic policy, project an explicit approval requirement, and bind bounded process-local approval evidence to the exact reviewed authority material without acquiring or exercising mutation authority.

The release-qualified lineage is:

authenticated request
→ authoritative observation
→ deterministic ReconciliationPlan
→ planner risk floor
→ Control-owned trusted risk classification
→ authenticated policy-review subject
→ allow / deny / require-approval / blocked
→ exact reviewed-plan projection
→ bounded approval evidence semantics where required

The capability remains Experimental. A policy allow, valid approval, or reviewed plan is not an execution capability, durable prepare record, Polkit grant, or supported Linux mutation.

User-visible capability

A local authenticated user can continue to use the v0.1 observation/graph and v0.2 plan-preview surfaces and can additionally use the Experimental SDK/CLI review surface to:

• run linuractl review-plan <plan-id> on a retained canonical plan;
• run linuractl explain-plan-review <plan-id> without converting the review into an executable effect;
• inspect the planner risk floor and Control-reviewed risk;
• inspect deterministic allow, deny, require-approval, or blocked policy outcome;
• inspect the exact required approval class and reason when approval is required;
• inspect policy/risk-policy identity and revision/rule provenance exposed by the review contract;
• retain the semantic reason summary plus intent, requirement, and capability origin identities;
• inspect the exact planned changes/findings and authoritative evidence/provider/resource/capability lineage being reviewed;
• observe that the reviewed plan remains explicitly non-executable.

The public Control1/SDK/CLI surface does not expose a release-qualified operation that converts the review or approval evidence into a machine effect.

Implemented scope

• Canonical policy review derived only from linura-planner::ReconciliationPlan through linura-control; linura-policy is not a transport/provider orchestration path.
• Typed authenticated principal separated from request-provenance actor identity.
• Deterministic trusted risk classifier treating planner risk as a floor, choosing the strongest overlapping rule, blocking unclassified mutation and attempted downgrade, and retaining risk-policy revision/rule provenance.
• Conservative initial typed systemd active_state classification as security-sensitive for review purposes only.
• Deterministic typed policy outcomes: allow, deny, require-approval, blocked.
• Opaque Control-owned trusted review material so caller-mutated PolicyEvaluation cannot mint weaker approval.
• Typed approval request/evidence identities, exact review binding, authenticated approver classes, self/non-human/weak-approver rejection, issuance/expiry/revocation validation, and exact idempotent retry.
• Control-owned authority clock with monotonic rollback protection; caller-supplied time cannot preserve or revive authority.
• Count-, per-entry-byte-, aggregate-byte-, tombstone-count-, tombstone-byte-, and tombstone-retention bounds with deterministic reclamation and replay protection.
• Fail-closed wire decoding that rejects blocked/allow mismatch, protected-risk allow, weaker approval class than reviewed risk, and proposed-change/read-only inconsistency.
• Experimental Control1/SDK/CLI review and explanation with semantic provenance retained end-to-end.
• Authority anti-drift/layering checks preserving Control-only policy orchestration and rejecting revival of superseded provider-owned/executable planning.
• Exact-source VM acceptance extending the real daemon/CLI planning fixture through review/explanation while proving no native state mutation.
• Experimental machine-class/profile contract additions (workstation, server, edge) as declarative metadata only; no class becomes a supported platform claim.

Authority and security boundary

Models and agents remain untrusted proposers. They cannot choose their authenticated principal, lower reviewed risk, select policy revision, mint approval evidence, approve their own proposal, or obtain an executor handle through this release.

D-Bus authenticates the service caller and derives transport identity, but that identity is not itself trusted human/admin approval — including when the service caller has UID 0. Approval evidence can be issued only from opaque Control-owned trusted review material and only by an authenticated approver satisfying the required class.

Review and approval bind the material authority context rather than a plan ID alone: principal, request/plan, planned changes/findings, authoritative evidence, provider/resource/capability, semantic provenance, planner risk floor, classified risk and risk-policy provenance, policy identity/revision, and approval requirement. Substitution or mismatch fails closed.

Blocked and Deny are never approvable. Allow does not authorize execution. Valid approval does not authorize execution. Public reviewed-plan output is explanation/evidence, not a capability token.

Platform and hardware scope

No Linux distribution, desktop, machine class, hardware tier, virtualization profile, or fleet profile is supported by the v0.3.0 claim.

Automated system evidence uses the repository-pinned disposable Ubuntu 24.04 LTS amd64 cloud-image/QEMU fixture. The systemd route is deliberately narrow and exists to prove authoritative observation, deterministic planning, conservative risk classification, policy review, explanation, and non-mutation. It does not establish general systemd administration support or promote Ubuntu/QEMU into a supported product profile.

The Experimental workstation, server, and edge machine-class metadata introduced during this development interval describes future targeting and portability semantics only. It grants no support or authority.

Persistence, migration and upgrade

Plan previews, trusted reviews, approval evidence, revocation state, and replay tombstones used by the v0.3 authority proof are intentionally bounded and process-local where applicable. Daemon restart may discard that authority state. A caller must obtain fresh authoritative observation, planning, and review rather than reconstructing authority from stale client data.

This release introduces no release-qualified durable authorization schema, transaction store, prepare/commit record, persistent desired state/intent, crash-recovery state, or durable audit database. Therefore no new supported durable-user-data migration is claimed. Durable transaction/recovery semantics are the v0.4.0 milestone.

All v0.3 public contracts remain Experimental and may evolve coherently under the repository's contract-stability rules.

Recovery and rollback

Because v0.3.0 performs no supported managed external effect, there is no product mutation to roll back. Loss of process-local review/approval state requires a fresh observe → plan → review sequence. Expired or revoked approval cannot be revived by client time or wall-clock rollback.

The disposable VM may use snapshot isolation to clean its external qualification fixture, but that is test infrastructure rather than a Linura product recovery capability. v0.3.0 does not claim durable prepare recovery, indeterminate-operation recovery, compensation, break-glass mutation, snapshot management, or transactional rollback.

Compatibility boundary

Product version v0.3.0, D-Bus generation Control1, and checked *.v1 schemas are independent version axes. The v0.3 review/approval contracts remain explicitly Experimental in the stability registry and do not become Stable merely because they are public or included in a release.

The superseded Experimental ActionPlan / provider-owned planning / generic apply-runtime path was intentionally removed while establishing the canonical authority lineage. No compatibility shim revives it. Stable contracts, if any are promoted in the future, remain governed by historical compatibility enforcement.

Required acceptance evidence

Publication requires all of the following on the exact frozen source/bytes where applicable:

• release-preparation CI, Security, CodeQL, repository/contract/layering/authority checks, and configured review with no unresolved blocking thread;
• deterministic tests for allow, deny, require-approval, blocked, planner-risk floor, elevated risk, unclassified mutation, attempted downgrade, overlapping-rule strength, exact review binding, policy/risk-policy substitution, self/non-human/weak approver, expiry, revocation, replay/substitution, monotonic authority time, and bounded retention/tombstones;
• wire tests rejecting blocked/allow mismatch, protected-risk allow, weaker approval class, and change-proposed with read-only reviewed risk;
• CLI/acceptance evidence preserving semantic reason summary and intent/requirement/capability origins through plan review/explanation;
• exact-source authoritative-observation VM regression;
• exact-source control1-plan-preview VM qualification exercising real daemon/CLI plan review and required approval-class projection while proving native Linux state remains unchanged;
• no fake trusted-human approval over D-Bus: issuance/expiry/revocation/approver semantics are qualified by deterministic Control tests until a trusted human/admin adapter exists;
• a single-parent metadata-only `r...

Linura v0.2.0

v0.2.0 — deterministic desired state and non-executable planning

Status: implementation complete; publication evidence is established only by the protected release lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.2.0 proves Linura's first end-to-end deterministic planning slice on top of the authenticated authoritative-observation foundation published in v0.1.0. A local authenticated client can submit a bounded hand-authored semantic desired-state request, Linura can bind that request to current authoritative Linux evidence, and the control plane can return an explainable, evidence-bound reconciliation preview without acquiring or exercising mutation authority.

The release proves this pipeline:

hand-authored semantic request
→ typed route + semantic-origin validation
→ retained replay/idempotency check
→ current authoritative observation
→ normalized desired state
→ deterministic diff
→ structural validation
→ bounded retained plan preview

The capability is Experimental. It is not a production-ready operating-system release and does not support applying the proposed change.

User-visible capability

With linurad running on the user's session D-Bus, a local client can continue to use the v0.1.0 identity/observation/graph surfaces and can additionally use linuractl/the public SDK to:

• request a deterministic desired-state preview for one typed resource and authoritative observation route;
• inspect whether the result is no-change, change-proposed, or blocked;
• see the exact authoritative evidence identity used to derive the diff;
• see ordered proposed state changes and findings/blockers;
• retrieve a retained process-local preview by typed plan ID;
• explain the retained preview without re-observing, recomputing, or invoking a model;
• retry an identical authenticated request ID and receive the exact retained preview rather than a new evidence-bound result;
• observe explicit failure when the same authenticated request ID is reused for materially different normalized input;
• verify from every public preview that execution_authorized=false.

The public surface does not expose an apply method or any conversion of a preview into an executable effect.

Implemented scope

• Typed declarative capability resource blueprints that contribute provider-neutral desired state rather than command strings.
• Deterministic capability resolution with explicit missing-capability and declared-conflict failure.
• Deterministic merging of multiple desired-state contributions with contradictory values rejected.
• Desired resources that bind resource identity, authoritative provider/capability observation route, normalized attributes, and semantic origin.
• Validation requiring at least one intent, requirement, or capability origin for managed desired state.
• Pure deterministic planning over normalized desired state plus a current authoritative observation projection.
• Exact provider/resource/capability identity and freshness validation before evidence may participate in planning.
• Ordered deterministic changes/findings and no-change, change-proposed, and blocked preview status.
• Fail-closed handling when a requested desired attribute is absent from authoritative evidence.
• Exact evidence-ID binding in every preview.
• Prospective risk classification that is descriptive only and never grants authority.
• execution_authorized=false enforced by the public preview contract.
• Transport-neutral linura-control::PlanPreviewControl ownership of normalized replay semantics, authoritative observation, planner invocation, evidence binding, bounded retention, and retained lookup/explanation.
• A transport-neutral authenticated-principal namespace for replay/retention ownership while retaining the concrete first accepted actor as provenance.
• Pre-observation idempotency lookup so response-loss retries do not create a new observation/evidence identity.
• Count-, per-entry-byte-, and aggregate-byte-bounded process-local preview retention with deterministic oldest-first eviction and oversized-entry rejection.
• Bounded public request decoding, including limits for semantic summaries, semantic origins, desired attributes, individual strings, and total normalized payload.
• Experimental Control1 methods PlanDesiredState, GetPlanPreview, and ExplainPlanPreview, with matching checked D-Bus XML, SDK/client methods, CLI surface, tooling checks, and tests.
• D-Bus kept as an authentication/wire adapter: it derives caller credentials, maps them to a generic authenticated principal and actor provenance, decodes/encodes bounded typed values, and delegates planning authority semantics to linura-control.
• Experimental JSON contracts for desired-state/capability planning and plan previews.
• Exact-source disposable-VM acceptance for both the v0.1.0 authoritative-observation regression and the v0.2.0 Control1 plan-preview scenario.

Authority and security boundary

v0.2.0 expands the authenticated local read/planning surface but does not expand mutation authority.

The caller cannot supply or override its authenticated D-Bus identity. The transport resolves the live sender credentials and derives a concrete actor for provenance plus a stable authenticated-principal namespace for daemon-lifetime replay ownership. Different authenticated principals cannot read or replay each other's retained previews.

Desired state, semantic summaries, semantic-origin identifiers, and request identifiers are untrusted input. They are bounded and typed before authoritative observation or retention work. Reuse of the same authenticated request ID with different normalized input fails closed before observation.

For a first-seen request, planning consumes a fresh ObservationCoordinator result for the exact provider/resource/capability route. Stale/future evidence, identity mismatches, unsupported routes, unavailable providers, malformed values, conflicting desired state, and unknown current attributes fail or block according to the typed contract rather than being guessed.

The preview may classify a prospective change as system-mutation, but it contains no executor handle or authorization token and its execution-authorized state is false. Planning never calls an executor, never requests Polkit authorization, never performs policy approval, never invokes arbitrary shell commands, and never creates a durable prepare record.

Models/agents are not required for this release and receive no authority through it.

Platform and hardware scope

No Linura Linux distribution, desktop, hardware tier, or platform profile is supported by this release claim.

Automated system evidence uses the repository-pinned Ubuntu 24.04 LTS amd64 cloud image defined by the disposable-VM harness, with SHA-256 verification, ephemeral cloud-init/SSH identity, and QEMU snapshot execution. That environment proves only the bounded behavior exercised by the acceptance scenarios; it does not promote Ubuntu, QEMU, TCG, KVM, systemd-capable distributions generally, or any physical hardware class into a supported Linura platform profile.

The plan-preview VM scenario exercises a controlled systemd fixture because it provides a narrow authoritative state that can be changed externally and independently inspected. The scenario proves planning semantics and non-mutation, not supported systemd administration by Linura.

Persistence, migration and upgrade

The v0.2.0 preview store is intentionally bounded and process-local. It supports daemon-lifetime idempotency and retained lookup/explanation only. Restart may discard previews.

This release does not introduce release-qualified durable desired-state persistence, persistent intents, a transaction database, durable replay prevention, prepare/commit records, production audit persistence, or crash-recovery state. Consequently there is no supported durable-user-data migration introduced by the v0.2.0 planning slice.

v0.1.0 and v0.2.0 public contracts remain Experimental. v0.2.0 is an additive product capability milestone, but it does not promise an installed-system upgrade path or Stable wire compatibility. Any future persistent representation must define explicit format versioning, migration, corruption handling, backup, and recovery before being supported.

Recovery and rollback

Because v0.2.0 performs no managed external effect, a planning failure does not require machine-state rollback. The control process may be restarted and the caller may submit a new request, causing a fresh authoritative observation and new evidence-bound preview.

A retained preview is never treated as durable recovery evidence. If it has been evicted or the daemon restarted, the caller must request a new preview rather than reconstructing authority from stale client state.

The acceptance fixture itself creates/observes controlled systemd state using external test authority and QEMU snapshot isolation. The scenario verifies native state remains unchanged after preview generation/retrieval/explanation. Test-fixture cleanup or snapshot rollback is not a Linura product mutation or recovery capability.

v0.2.0 does not claim managed compensation, durable rollback, indeterminate-operation recovery, break-glass mutation, or transactional crash recovery.

Compatibility boundary

Product release v0.2.0, D-Bus name Control1, and *.v1 JSON/schema generations are independent version axes. The planning surfaces in this release remain explicitly Experimental in the repository stability registry and may evolve coherently while Linura is pre-1.0 until explicitly promoted.

The canonical Control1 surface now includes the v0.1.0 authenticated observation/graph operations plus explicit preview-oriented PlanDesiredState, GetPlanPreview, and ExplainPlanPreview operations. No removed pre-stable generic mutation/plan compatibility surface is revived.

Experimenta...

Linura v0.1.0

v0.1.0 — authoritative observation and causal graph

Status: implementation complete; publication evidence is established only by the protected release lifecycle.
Claim class: Experimental
Supported platform profiles: none

Outcome

v0.1.0 is Linura's first implementation milestone beyond the architecture/bootstrap record. It proves an authenticated, deterministic, read-only path from a local client through Linura's public D-Bus/SDK boundary to authoritative Linux provider state, then projects that evidence into the causal system graph for inspection and explanation.

The milestone was originally tracked internally as v0.0.1. Before publication it was renumbered to v0.1.0 because Linura's pre-1.0 versioning policy reserves patch releases for compatible repairs to an already-published minor line and uses a new minor version for a new externally testable end-to-end capability slice.

This is an Experimental capability release, not a claim that Linura is a production-ready operating system or that managed system mutation is supported.

User-visible capability

With linurad running on the user's session D-Bus, a local client can use linuractl to:

• identify the authenticated D-Bus caller with whoami;
• inspect provider availability and observation capabilities with capabilities;
• read current systemd unit state with observe systemd:unit:<name>;
• read NetworkManager manager/device state when NetworkManager is available;
• inspect the observed causal graph with graph;
• explain the current authoritative evidence for an observed resource with explain <resource>.

The observed result carries provider/resource/capability identity, native-authority metadata, freshness, observation time, validity duration, sequence and typed attributes. Re-observation reads the provider again; an out-of-band change is not hidden behind Linura-owned desired state or a client-supplied claim.

Implemented scope

• Session D-Bus service org.linura.Control1 and non-privileged public client boundary.
• Transport-derived caller credentials bound to typed Linura actor identity.
• Explicit provider health/capability reporting, including unavailable/degraded states.
• Native systemd D-Bus observation of installed units.
• Native NetworkManager D-Bus observation of manager/device state when the service is present.
• Authoritative observation envelopes with freshness and identity validation.
• Observed resource/capability/evidence projection into the causal system graph.
• Deterministic SDK/CLI surfaces for identity, capabilities, observation, graph and explanation.
• Contract-lifecycle metadata in checked D-Bus XML and live runtime introspection.
• Historical enforcement for any contract explicitly promoted to Stable while the v0.1.0 public contracts remain Experimental.
• Repository-owned disposable-VM qualification using an exact-source build, a dated SHA-256-pinned Ubuntu 24.04 cloud image, ephemeral cloud-init/SSH identity, QEMU snapshot execution and machine-readable VM evidence.

For explicitly named systemd resources, Linura uses systemd's native LoadUnit lookup before reading Unit properties. That allows an installed inactive unit to remain observable after systemd garbage-collects its previous in-memory loaded-unit object; LoadUnit loads the installed definition into the manager but does not start the unit or alter the unit file.

Authority and security boundary

linurad remains unprivileged. The observation path exposes no generic privileged shell, no privileged executor handle and no model/agent authority. D-Bus caller identity is derived from the OS transport boundary rather than accepted from client payload fields.

System state is obtained from native systemd/NetworkManager D-Bus interfaces and is validated before it becomes current graph evidence. Client-supplied, malformed, mismatched, stale or unsupported observations cannot override provider authority.

The disposable acceptance guest uses passwordless sudo only as external test-fixture authority: it installs the exact-source test binaries and creates/stops/removes a controlled systemd unit. That fixture privilege is not exposed through Linura and is not evidence of a supported Linura mutation path.

LoadUnit may change systemd's in-memory loaded-unit bookkeeping so an installed unit can be inspected, but it does not start/stop the unit and does not modify persistent system configuration. v0.1.0 claims observation, not managed mutation.

Platform and hardware scope

No Linura platform profile or physical hardware tier is supported by this release claim.

Automated system evidence uses a repository-pinned dated Ubuntu 24.04 amd64 cloud image as a disposable acceptance environment. That proves the bounded observation behavior exercised by the scenario; it does not promote Ubuntu, arch-hyprland-v1, QEMU/TCG, KVM or any physical machine class into a supported Linura platform profile.

systemd observation requires the systemd D-Bus service. NetworkManager observation is available only when the NetworkManager D-Bus service is present; service absence is represented explicitly rather than treated as successful evidence.

Persistence, migration and upgrade

The v0.1.0 observation/graph slice does not introduce a production durable desired-state store, prepare/commit transaction database or release-qualified persistence migration.

There is no supported upgrade guarantee from v0.0.0: v0.0.0 is an Architecture-class foundation record rather than a supported installed-system line. Public contracts in this release remain Experimental and may evolve coherently until explicitly promoted.

No durable user data migration or backup procedure is required for the read-only observation capability itself. Future persistence work must define independent migration, corruption and recovery guarantees before it becomes supported.

Recovery and rollback

Because the claimed capability is read-only, recovery is primarily process-local: restart the client/service and re-observe authoritative provider state. Linura does not rely on replaying cached observations to reconstruct current machine state.

The acceptance fixture removes its temporary unit and performs systemd daemon reload during cleanup. QEMU executes the guest in snapshot mode so the verified base image is not persisted or mutated by the test run.

v0.1.0 does not claim production snapshot rollback, managed-mutation compensation, durable transaction recovery or a supported break-glass workflow. Those remain later lifecycle milestones.

Compatibility boundary

Product version v0.1.0 and contract generation Control1/version 1 are independent. The checked D-Bus contract, CLI surface, Rust SDK surface and JSON schemas remain explicitly Experimental in contracts/stability.toml; a v1/Control1 name is not a Stable compatibility commitment.

Experimental contract changes may be made coherently in later releases. If a contract is explicitly promoted to Stable, Linura's historical contract checker prevents removal, downgrade or same-generation incompatible replacement against the accepted baseline.

No compatibility shim is promised for obsolete pre-stable development surfaces.

Required acceptance evidence

Before v0.1.0 can be accepted as published:

• the exact release-preparation source must pass canonical CI, including formatting, strict clippy/workspace tests, repository/tooling validation, contract-stability validation and non-mutating source checks;
• Security/dependency audit and CodeQL must pass on the exact candidate source;
• configured review must be complete with no unresolved blocking review threads;
• docs/qualification/v0.1.0.md must remain consistent with this contract and map the claimed capability to reproducible positive, negative and failure-path evidence without overriding machine-generated results;
• disposable VM qualification must build linurad/linuractl from the exact source, verify the pinned base-image SHA-256, boot an ephemeral snapshot guest, authenticate the caller and run the repository's authoritative-observation scenario;
• VM acceptance must prove systemd native authority/freshness, explicit causal graph node/edge relationships, observed graph/explanation evidence and an out-of-band active → inactive transition through a subsequent authoritative observation;
• NetworkManager acceptance must prove native observation when its service is present and explicitly prove the provider/capability unavailable/unsupported branch when the service is absent rather than silently skipping it;
• VM qualification must emit machine-readable evidence binding source SHA, scenario digest, base-image URL/digest, acceleration mode, tested binary digests, harness versions and workflow identity;
• the final release-intent source must again pass exact-main CI, Security and CodeQL;
• Trusted Release Proof must re-run the required exact-source VM qualification, canonical validation and isolated release build;
• an independent fresh runner must reproduce distributable binaries byte-for-byte;
• the sealed payload must carry verified checksums, SPDX SBOM, release evidence, source/version identity and GitHub/Sigstore provenance attestations;
• promotion and final publication must consume the exact proven bytes without rebuilding;
• the version tag must be created only by final publication and bind to the selected source SHA;
• the GitHub Release must be immutable and an independent verification workflow must re-download and verify metadata, notes, checksums, release evidence, assets and attestations.

Known limitations and unsupported states

• No managed system mutation is supported by the v0.1.0 claim.
• No Polkit-backed production authority path is included in the claim.
• No durable desired-state, prepare/commit, reconciliation or production audit store is release-qualified.
• No supported Linux distribution/profile or physical hardwar...

Linura v0.0.0

v0.0.0 — architecture and trustworthy development foundation

Status: implementation complete; publication is qualified only by the protected immutable release lifecycle and successful independent verification.
Claim class: Architecture
Supported platform profiles: none

Outcome

v0.0.0 locks Linura's product vocabulary, trust boundaries and core contracts before supported machine mutation begins. It establishes an executable Rust bootstrap and production-oriented development/release machinery while explicitly avoiding a claim that Linura is already a production operating system.

The durable architecture now includes intent, reusable setups and the local-first Linura Library, machine profiles, capability composition, the causal system graph, semantic provenance, agent/authority separation, and the canonical eleven-stage managed-mutation lifecycle.

User-visible capability

v0.0.0 is primarily an architecture/developer release. It can build bootstrap binaries and exercise repository/tooling contracts, but it does not claim that a user can safely delegate real production machine configuration to Linura yet.

Implemented scope

• Typed core/protocol/provider/policy/planner/graph/provenance bootstrap crates.
• Canonical managed-mutation ordering:
  request/intent → observe → plan → validate → authorize → prepare → execute → verify → commit → audit → reconcile.
• Reusable, revisioned Setup contract and self-contained setup/profile portability model.
• Provider-neutral agent boundary where model output is proposal-only.
• Narrow privileged-executor architecture without a generic root shell API.
• Arch/Hyprland platform-profile contract, bootstrap/update/recovery scaffolding and disposable VM harnesses.
• Canonical cargo xtask check validation, Security and CodeQL workflows.
• Proof-first/tag-last release control: exact-main gate observation → Trusted Release Proof → proof-only promotion → final Release tag/publication → independent verification.
• Build-once promotion: the exact payload is built and attested during Trusted Release Proof, then publication consumes the same sealed bytes without rebuilding.
• SPDX SBOMs, SHA-256 checksums, machine-readable release evidence and GitHub/Sigstore build provenance for the published payload set.

Authority and security boundary

linurad is designed to remain unprivileged, agents receive no privileged executor handle, natural language cannot become executable text, and managed effects must use narrow typed executors. Executor success is not state proof; verification is an independent boundary.

These are architecture/contracts in v0.0.0. The release does not claim that all concrete production backends for the eleven stages are implemented.

Release publication authority is also bounded. The asynchronous gate observer cannot create tags or Releases. Trusted Release Proof is exact-current-main and read-only with respect to repository contents; Release Promotion can only hand a successful exact proof to the final Release workflow; only the final publish job has contents: write, and it creates the version tag only after exact-source validation and proof verification have succeeded. Every explicit workflow handoff supplies its repository context directly; canonical tooling rejects a gh workflow run handoff that could fall back to local .git repository discovery.

Platform and hardware scope

The repository defines arch-hyprland-v1 as the first development platform profile, but v0.0.0 makes no supported platform or physical-hardware claim. The profile and hardware evidence frameworks are inputs to later release qualification.

Persistence, migration and upgrade

Durable intent/prepare/commit persistence is not yet production-implemented. Migration/update frameworks exist as scaffolding/contracts. There is no supported previous Linura release to upgrade from and no production downgrade guarantee.

Recovery and rollback

Bootstrap, coordinated update, snapshot and native break-glass recovery contracts exist, but v0.0.0 does not claim end-to-end recovery qualification on a supported installed system. No release consumer should treat the presence of recovery harnesses as proof of a production rollback path.

Compatibility boundary

All public contracts remain pre-stable. SemVer 0.0.0 communicates that interfaces, schemas and platform contracts can change as the first vertical slice is implemented.

Required acceptance evidence

Before final v0.0.0 publication qualification:

• configured review must complete and every blocking review thread must be addressed on release-control changes;
• exact-source canonical CI must pass;
• Security/dependency audit and CodeQL must pass;
• repository/schema/tooling checks must pass;
• GitHub release immutability must be enabled before publication; because GitHub applies the setting only to future releases, a release published while the setting is disabled cannot satisfy this requirement retroactively;
• Trusted Release Proof must prove the exact current-main source, run canonical acceptance and produce one sealed/attested payload;
• the trusted build must be reproduced independently and distributable binaries must match byte-for-byte;
• Release Promotion must hand forward only that exact successful proof while the source is still current main;
• final Release validation must bind the workflow request, exact source SHA, version, permanent gates and proof receipt before publication authority is entered;
• the v0.0.0 tag must be created only by final publication and must bind to that selected source SHA;
• publication must use the same sealed proof bytes and frozen release notes without rebuilding;
• the GitHub Release must become immutable after the verified draft is published;
• independent publication verification must freshly download the release, prove tag/source/evidence/checksum/note identity, run gh release verify, verify each local asset against the immutable release, and verify build provenance.

VM/hardware harness existence is not elevated into a supported-system claim for this architecture-class release.

Requalification procedure for the superseded first publication

The first v0.0.0 publication from 59831a143731ab78cf843197a92818ce5cfa4474 never satisfied Linura's immutable-publication contract, so the same version may be requalified only after deliberate cleanup of that non-immutable publication. Perform this before merging the fresh final release-intent commit:

1. Enable GitHub release immutability for linura-org/linura and verify the repository setting is enabled.
2. Confirm the existing v0.0.0 publication is the superseded non-immutable publication described below, not an accepted immutable release.
3. Delete the superseded GitHub Release and its v0.0.0 tag together.
4. Verify that neither the GitHub Release nor refs/tags/v0.0.0 remains.
5. Only then merge a fresh release: v0.0.0 — architecture and trustworthy development foundation authorization on the final repaired main; that new exact source must traverse the complete gates → proof → independent reproduction → promotion → publication → verification chain again.

With an administrator-authenticated GitHub CLI, the administrative/cleanup checks are:

gh api --method PUT repos/linura-org/linura/immutable-releases
gh api repos/linura-org/linura/immutable-releases --jq '.enabled'
gh release delete v0.0.0 --repo linura-org/linura --cleanup-tag --yes
! gh release view v0.0.0 --repo linura-org/linura >/dev/null 2>&1
! gh api repos/linura-org/linura/git/ref/tags/v0.0.0 >/dev/null 2>&1

The immutable-release enablement requires GitHub repository administration permission; ordinary Actions GITHUB_TOKEN authority is intentionally insufficient for that repository setting. Never use this same-version requalification procedure for a release that was already immutable: GitHub permanently prevents reuse of a tag name after immutable publication, even if that immutable release is later deleted.

Known limitations and unsupported states

• No production D-Bus control service.
• No release-qualified authenticated caller binding.
• No production systemd/NetworkManager observers.
• No durable production prepare/commit/recovery store.
• No release-qualified Polkit-backed executor.
• No real capability has yet been proven through all eleven lifecycle stages on a supported machine.
• No production First Boot, Control Center, Shell or agent-driven system configuration.
• No supported hardware matrix.

Explicit non-goals

v0.0.0 does not claim production readiness, a supported installable Linura OS, autonomous AI administration, broad Linux-distribution support, fleet control, hosted sync, or real privileged machine management.

Traceability

Key architecture-lock and release-control changes include:

• Canonical managed-mutation lifecycle and independent verification boundary.
  e58a8321313dde8fd869dd32a63c026a940a2bfe
• Reusable Setup domain, self-contained portability and local-first Linura Library architecture.
  ecd1932452e4c246807017384cea32b998a20932
• Version-scoped release contracts, claim classes and machine-readable release evidence. PR #6 · 4714b983234ff28c6b1b754abe9a8ba1ae5a0cf5
• Initial trusted-candidate/promotion/verification machinery. PR #9 · 3a9a6d1d0165d5e76a777d41c96026f9c124d29f
• Release-control correction and alignment to the proof-first/tag-last lifecycle: observer-only proof dispatch, exact-source Trusted Release Proof, pr...