R2Kernel 1.0.0rc8

RC8 corrects Event security-mode compatibility and remaining readiness, managed-process, and removal contracts found after RC7. RC7 remains an immutable historical candidate; this release does not replace its artifacts or turn earlier partial verification into a pass. Upgrade the runtime and SDKs together. Local Control remains protocol v5 without mixed-version fallback.

RC8 follow-up audit

The follow-up audit confirmed the Event-mode, stale-gate, foreground cleanup, and outside-consumer refusal improvements. It also identified a publisher startup-order race in the fixture recipe, remaining whole-startup deadline boundaries, and an external HTTPS configuration write-capability mismatch. Subsequent release qualification found that mixed Disabled/Optional native Event connections can also depend on which host initiates the connection. RC8 remains a prerelease; these findings are addressed by the next candidate, not by replacing the RC8 tag or artifacts.

Federation Event compatibility

Inbound Native Event admission follows the configured federation security mode. disabled retains the supported plaintext Event path. optional supports the documented migration path for signed and unsigned peers. required still requires authenticated peer registration and rejects missing or invalid proof. The fix does not disable Host API authentication or weaken required-mode security to obtain successful delivery.

Selected peer and publisher identity, compatible topic codecs, freshness, and source-lifetime checks remain applicable in every mode. Accepting plaintext under an explicit policy does not make it cryptographically authenticated. Queued Events from a retired or replaced source lifetime cannot be relabelled as a newly accepted source. These checks do not introduce per-packet application-session proof or physical production-time guarantees.

See Web and API Security and Federation.

Readiness and diagnostic evidence

Event fixture publishers and the readiness helper use an execution-specific start gate. A previous run's gate is not readiness for the next run, and a failed check cannot be repaired by deleting an arbitrary caller file after a publisher may already have started. Follow the updated fixture recipe for all participants in the same run.

Explicit cross-host readiness requires observation of both sender and receiver. When clock acceptance is requested, both sides must be inspected. Sender-only status or the existence of a peer is not proof of receiver readiness.

Explicit legacy topology smoke checks remain diagnostic-only. They cannot report accepted one-way latency evidence, even when their clocks satisfy the requested checks. A readiness gate is not measured packet delivery, physical clock synchronization, or a periodic performance qualification.

See Deployment Checks.

Managed launch and foreground completion

RC8 uses bounded, cancellable gate and response progress once package preparation has completed. This does not establish a deadline for the entire startup: pre-exec preparation and some preparation-error replies have separate boundaries. The follow-up audit did not qualify cancellation or concurrent progress across all of those phases. Incomplete startup data must not authorize application execution or launch replay.

Foreground completion covers the owned scope, not just a successful leader exit. Broker-owned and approved-operator paths must terminate remaining owned work, confirm the owned child has been reaped, and release resources before reporting successful completion. A refused release or incomplete cleanup is a top-level failure, and recovery identity is retained rather than reporting success. An ambiguous launch is not automatically resubmitted.

See Resource Control.

Managed uninstall and inspection

Service-upgrade readiness probes the effective configured resource endpoint. An explicit absolute or config-relative socket takes precedence over the unit's socket environment, just as it does for the running broker. A healthy unrelated default socket is not readiness for the selected service.

For a protected external configuration, preserving HTTPS OFF is a read-only operation. Protected input and managed-store ownership checks still run; no TLS material is created and no policy is written. Actual TLS provisioning remains restricted to configuration inside the selected installation prefix. The fixed-config HTTPS settings broker can start and inspect this protected configuration. Requests cannot select configuration or output paths; settings writes outside the fixed prefix are explicitly refused before any material or policy write.

Service installation publishes non-secret IPC identifiers as readable 0644 files under the shared 0755 etc directory, independently of a restrictive caller umask. Same-prefix recovery repairs these public modes only after checking the expected identities. Credential stores and private key permissions are unchanged.

Removal uses the protected configuration and resolved registry identity selected by the installation's actual managed service. A successful check against an unrelated empty default registry does not establish that the selected resources have been retired. Ambiguous ownership or configuration divergence is refused, not repaired by guessing from ambient environment variables.

After owned consumers stop and before destructive retirement or removal, installed executable, library, working-directory, and file-descriptor users outside the managed service graph also block removal. Only the invoking helper and its exact validated privileged monitor chain are exempt; unrelated sudo processes and other consumers are not.

Dry-run distinguishes safely observable preflight checks from conditions that can only be established after services stop. Deferred lock or final live-state checks are not reported as passed. Inspection does not create, migrate, retire, or delete registry state. Unreadable or invalid protected state is not treated as an empty registry. A refused operation preserves the information needed for recovery.

See Installation.

Qualification boundaries

The declared local C++ acceptance profile remains raw-eight-byte echo with period and deadline of 1 ms, Required authority, Core FIFO99 on CPUs 0 and 1, and actual caller and handler FIFO80. Affinity runs place caller on CPU3 and handler on CPU2. The retained profile includes repeated five-second runs with and without application affinity and 30-second affinity runs on each host, measured sequentially without tracing inside acceptance windows.

Both provider and caller use finite measurement mode. Provider diagnostic latency-statistic accumulation is excluded from the timed window; integrity and handled counters remain. Every scheduled slot, skipped slot, failure, caller deadline, scheduled-completion deadline, and after-window completion belongs to the result. No catch-up, automatic replay, deadline relaxation, or silent cold recovery is used to promote a failing run.

Measured results and artifact identity are recorded with the RC8 prerelease. Historical RC7 corrected-method 18/18 and original-method 17/18 failure remain separate evidence; neither is a new RC8 result or proof of the original miss's root cause.

Python is outside strict 1 ms periodic acceptance. Guest affinity does not prove physical CPU or hypervisor isolation. No general WCET/hard-real-time, cross-host 1 kHz Control, physical-effect timestamp, hardware PTP, or native ARM runtime qualification follows from unit tests, build success, readiness, or functional Event delivery. Benchmark demos remain withdrawn.