R2Kernel 1.0.0rc6

RC6 contains the managed-resource, authenticated Event, and deadline-handling fixes developed after RC5, together with the tutorial/fixture distribution contract described below. These are RC6 changes, not retroactive changes to published RC5 artifacts. R2Kernel remains a release candidate.

Subsequent audit

A later audit confirmed the earlier core fixes but found residual SDK descriptor cleanup, preparation-budget and invalidation, broker availability, installed diagnostics, secured fixture, and tutorial result-propagation issues. The historical successful scenarios below do not establish that all error and lifecycle paths were correct. See RC7 notes for the successor contracts; those repairs do not alter the bytes of published RC6 artifacts.

Changes

Tutorial and fixture distribution

Public benchmark demo sources, runnable benchmark guides, QA callers, and benchmark distribution/install entries are withdrawn. The replacement public source payload consists of SDK source, guided tutorials, and supporting transport fixtures. Installed tutorials are available under <prefix>/tutorials; supporting fixtures are under <prefix>/runtime/tools/qa/fixtures, also accessible through the installed tools alias. Fixtures support tutorial and protocol development; they are not a replacement performance demo or an acceptance runner.

Normal installed tutorial use does not require an SDK source checkout. Source <prefix>/env.sh before running installed commands. Installed managed Python and an optional development virtual environment remain separate: activate a development environment after sourcing the helper when that workflow is needed. Runtime Event and Control APIs remain supported. Withdrawing the benchmark demo does not weaken the declared performance requirement or promote tutorial output to timing qualification.

Managed resource lifetime and shutdown

Failed managed launches clean up the resources acquired for that launch, including preparation and process-start failures. Cleanup preserves the primary failure and reports cleanup failures. A resource that could not be released retains its reservation for explicit retry or administration rather than being reported as released.

Managed stop, kill, release, and reap retain process identities, device grants, and reservations until the owned process scope is quiescent and removed. Scope cleanup has a bounded budget separate from stop's termination grace periods. Managed shutdown continues to service the live authority proof needed by SDK shutdown, so waiting for a child to exit does not itself prevent that child from finishing its authorized shutdown. Authentication and termination grace periods are not relaxed.

Resource-service responses have bounded size and a single delivery deadline. A failed response does not replay an operation that already committed. Clients must close received resources safely if a response is malformed or incomplete. Existing legacy synchronization resources are not adopted merely because their names and ownership appear compatible; migration still requires verified ownership and object identity.

Authenticated Event metadata and continuity

Authenticated discovery preserves numeric values across JSON serialization and parsing, including timestamps, so valid metadata is not rejected because a numeric round trip changed the authenticated representation. Authentication, session/replay checks, and freshness limits remain enforced.

Typed Event peers must agree on accepted session, binding, payload type, and codec identity. Incompatible topics are quarantined without stopping unrelated compatible topics or Control service. An unchanged heartbeat from an already accepted peer in the same session preserves identity and liveness; an incoherent heartbeat is rejected without refreshing freshness. Changed identities and sessions still require admission. Internal bridge identities cannot be claimed by SDK participants.

Authenticated discovery advertises only acquired subsystem directions, not rejected claims. Discovery handshakes run separately from transport reconciliation; RC6 receipt installation can still wait for shared resource admission. After a genuine peer restart, a pinned binding must rebind to the accepted new generation before delivery resumes. Registration readiness alone is not evidence of payload delivery.

Original deadlines and Procedure results

A deadline-bound call through an interface binding includes runtime binding lookup, route selection, payload preparation, and the exchange in its original absolute deadline. Lookup expiry or failure does not fall back to stale launch bindings. Sub-millisecond waits do not enlarge the budget, and failure or late completion is not converted into success or an automatic retry.

Local Control preparation establishes provider readiness and reserves payload capacity without invoking the application callback. Prepared calls reject route changes or capacity overruns rather than silently reconnecting or growing buffers in the timed path. Upgrade runtime and SDK processes together: RC6 uses local Control protocol v5. Mixed v4/v5 peers fail negotiation before application effects; there is no compatibility fallback.

The cleaner tutorial propagates failed Procedure results and rejects malformed or non-Boolean acknowledgements. A valid Bool(false) is a negative acknowledgement, not a transport failure or permission to retry. A declared 1.5-second destination-handler I/O limit is honored within the caller's original total budget rather than being silently capped at one second. A failed call after admission does not undo an effect and does not authorize replay. Safe-off, pulse, lease, and watchdog obligations remain unchanged.

Validation and qualification boundaries

The following results belong to the audited source candidate. Release artifact build and installation checks are separate from these measurements.

The integrated candidate checks passed 845 Python SDK/tutorial/release and validation tests (11 skipped), 619 root-backed backend tests, 17 broker tests, and 106 installer tests. Public tutorial/fixture assembly was exercised without a benchmark demo or private periodic driver in the resulting payload.

Secured two-host typed Event validation passed 19 phases, with exact ordered receipts for 80 compatible publications, including genuine restart and pinned rebind. Freshness, incompatible-topic quarantine, compatible continuity, and spoof rejection were checked separately. Managed cleaner simulator operations completed 15 of 15 collections with successful nested acknowledgements and no cleanup warnings. These are finite software checks, not physical-action timing qualification.

The finite C++ local raw-eight-byte echo qualification remains valid: a 1 ms period/deadline, Core FIFO99 on CPUs 0 and 1, and actual caller/handler FIFO80 passed all 18 runs across both hosts. Each host passed three five-second runs, three five-second affinity runs, and three 30-second affinity runs; affinity conditions used caller CPU3 and handler CPU2. Hosts ran sequentially without tracing in the measured acceptance windows. These results apply to that declared profile, not all operating conditions.

Python is outside this release's strict 1 ms periodic acceptance target. Its failed diagnostics remain evidence and are not reported as passes; they do not invalidate the qualified C++ profile. No cross-host 1 kHz Control, worst-case hard-real-time, physical effect timestamp, or hardware PTP guarantee is asserted. Guest CPU affinity is not physical-core or hypervisor isolation.

See Installation, Quickstart, Resource Control, and Time Sync Operations for supported setup and operating requirements. RC5 release notes remain historical context and do not describe changes to immutable RC5 artifacts.