docs(rfc): define executable lease launch boundary - #1969
Conversation
Define the threat model, retained native authority, launch receipt, platform feasibility gates, and stacked delivery contract for issue #1948. The RFC prevents pathname rechecks or best-effort fallbacks from being mistaken for process-image authority and makes native packaging, script compatibility, lifecycle, and adversarial conformance explicit prerequisites.\n\nAffected files:\n- docs/rfc/executable-lease-launch-boundary.md
![ouroboros-agent[bot]](https://avatars.githubusercontent.com/in/3091302?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review — ouroboros-agent[bot]
Verdict: REQUEST_CHANGES
Metadata
| Field | Value |
|---|---|
| PR | #1969 |
| HEAD checked | 277b1bd34360c6636bf32ecfa7a284a818d99a89 |
| Request ID | req_1786305283_1194 |
| Review record | c45b1e9c-a266-406d-89c0-e619c3f1752f |
What Improved
- Defines a strong fail-closed launch-authority model that binds attestation, version probes, and task launches to one retained executable generation.
- Explicitly covers immutable executable bytes, pre-application loader/interpreter closure, hostile replacement barriers, lifecycle cleanup, platform feasibility gates, and unsupported entrypoint behavior.
- Correctly keeps #1948 open until all five attested Codex-family runtimes and the complete platform/release matrix are implemented and verified.
Issue Requirements
| Requirement | Status |
|---|---|
Select one retained native ExecutableLease authority for attestation, version probes, and launches without pathname fallback |
Met |
| Use an in-process native extension rather than a pathname-launched helper | Met |
| Retain the initially accepted executable generation and revalidate the live resolution chain before every probe/spawn | Met |
| Require immutable executable bytes and the complete pre-application loader/interpreter/delegate closure | Met |
| Preserve fail-closed behavior for unsupported platforms and entrypoint shapes | Met |
| Define lifecycle, process, receipt, cancellation, and cleanup contracts | Partially met — receipt settlement ordering and durable pre-dispatch identity publication remain undefined |
| Define Linux, macOS, and Windows feasibility gates | Met |
| Grant Node/shebang support only for explicitly proven installed CLI shapes | Met |
| Define an exact-versioned companion native-wheel strategy | Partially met — the documented PEP 508 marker syntax is invalid and editable-development dependency resolution remains underspecified |
| Activate Codex, Copilot, Gemini, Goose, and Grok under one shared launch contract | Partially met — the intended shared boundary is identified, but retained in-memory and fresh durable-resume acquisition contracts are not reconciled |
| Keep #1948 open through native wheels, entrypoint support, shared activation, and the full platform matrix | Met |
| Limit this PR to draft architectural direction without claiming runtime activation | Met |
Prior Findings Status
No prior ouroboros-agent review rounds or human review comments were present. No earlier concerns required maintenance, modification, or withdrawal.
Blockers
| # | File:Line | Severity | Finding |
|---|---|---|---|
| 1 | docs/rfc/executable-lease-launch-boundary.md:401 | BLOCKING | Async “first-dispatch initialization” conflicts with the existing durable session-publication boundary. OrchestratorRunner.prepare_session() builds and persists model_routing.runtime_execution before any worker dispatch (src/ouroboros/orchestrator/runner.py:8667 and src/ouroboros/orchestrator/runner.py:5631), and fresh-process resume later requires exact equality with the newly constructed runtime identity (src/ouroboros/orchestrator/runner.py:6608). Moving executable attestation out of CodexCliRuntime.__init__ without defining a replacement publication phase leaves the durable contract without the accepted executable generation, or forces the supposedly asynchronous acquisition back into synchronous identity construction. Specify whether lease acquisition must complete before session publication, or define an atomic provisional-to-sealed contract transition before any effect; also define the persisted lease/receipt identity used by fresh-process resume and distinguish that path from reuse of a retained in-memory runner and capability. |
| 2 | docs/rfc/executable-lease-launch-boundary.md:78 | BLOCKING | The receipt contract lacks an ordering protocol capable of satisfying its own no-effect guarantee. The RFC requires receipt failure to refuse launch before application code runs, while suspended strategies verify and then resume the child, spawn() returns both process and receipt, and conformance explicitly includes a child exiting before receipt publication. If the backend resumes before the receipt crosses the extension/Python boundary, allocation, delivery, or caller cancellation can fail after hostile or legitimate application effects have already occurred; if it publishes first, it still needs an acknowledgement/commit step and cleanup ownership for cancellation between publication and resume. Define a native-owned two-phase state machine—prepared/suspended, receipt settlement, committed/resumed—with exact cancellation, timeout, child-exit, and handle-cleanup transitions. |
Follow-up Findings
docs/rfc/executable-lease-launch-boundary.md:356[warning] The proposed dependency marker syntax is not valid PEP 508:platform_machine in {"x86_64", "aarch64"}fails marker parsing because marker membership operands must be quoted strings, not set literals. Since the RFC directs a build hook to generate exactRequires-Distmetadata from this marker set, implementing the documented expression would make package metadata generation or installation fail. Specify valid complete marker expressions, including the exactplatform_systemcomparisons, and require a metadata parsing/install-resolution test for every supported target.
| # | File:Line | Priority | Confidence | Suggestion |
|---|-----------|----------|------------|------------|
| 1 | docs/rfc/executable-lease-launch-boundary.md:363 | Medium | Medium | Clarify the concrete workspace dependency mechanism for source/editable installs. A mandatory exact dependency on a dynamic development version needs an explicit workspace/source override so local resolution does not attempt to download an unpublished matching companion wheel, plus a test that editable and release metadata preserve the intended authority boundary. |
Non-blocking Suggestions
None.
Test Coverage Notes
- Reviewed the changed RFC, current shared runtime, durable execution-contract construction and resume validation, runtime ownership/closure paths, packaging configuration, and existing executable-attestation documentation.
SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest -q tests/unit/orchestrator/test_codex_cli_runtime.py -k 'execution_identity or version_attestation': 4 passed, 139 deselected.SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest -q tests/unit/orchestrator/test_routing_contract_resume.py -k 'contract_build_records_codex_runtime_execution_identity or different_runtime_execution_profile': 1 passed, 199 deselected.- A focused
packaging.markers.Markerprobe confirmed the RFC’s set-literal marker is invalid PEP 508 syntax. - Direct formatting inspection found 507 lines, no trailing whitespace, and no tabs. The PR is design-only and adds no executable conformance harness or receipt-state tests, so the proposed native behavior remains unverified by this snapshot.
Design Notes
The RFC chooses the right security direction and rejects unsafe pathname rechecks and best-effort fallback. However, two central state-machine boundaries—durable identity publication and receipt-before-resume settlement—must be made implementable before this can safely guide native runtime work.
Design / Roadmap Gate
The affected boundary is security-critical process authority. Current sessions persist executable-dependent runtime identity before dispatch and can resume either through a retained in-memory owner or a newly constructed runtime. The proposed lazy lease must preserve both cases without reconstructing missing authority from current mutable state. Likewise, successful launch must atomically reconcile native verification, receipt delivery, resume, cancellation, and cleanup so no receipt failure can occur after application effects. Packaging metadata must also be valid and reproducible across release and editable installation modes. These gaps are architectural rather than implementation details.
Directional Notes
Review focused on replay-safe durable execution identity, parity across shared runtime entrypoints, native process lifecycle cleanup, and concrete feasibility gates. Maintainer memory was used only to direct inspection; all blockers are grounded in the current RFC and source snapshot.
Test Coverage
- Reviewed the changed RFC, current shared runtime, durable execution-contract construction and resume validation, runtime ownership/closure paths, packaging configuration, and existing executable-attestation documentation.
SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest -q tests/unit/orchestrator/test_codex_cli_runtime.py -k 'execution_identity or version_attestation': 4 passed, 139 deselected.SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest -q tests/unit/orchestrator/test_routing_contract_resume.py -k 'contract_build_records_codex_runtime_execution_identity or different_runtime_execution_profile': 1 passed, 199 deselected.- A focused
packaging.markers.Markerprobe confirmed the RFC’s set-literal marker is invalid PEP 508 syntax. - Direct formatting inspection found 507 lines, no trailing whitespace, and no tabs. The PR is design-only and adds no executable conformance harness or receipt-state tests, so the proposed native behavior remains unverified by this snapshot.
Merge Recommendation
Request changes before adopting this RFC as the implementation contract. Resolve the durable precreation/resume phase, specify an enforceable receipt settlement state machine, and replace the invalid dependency-marker syntax. The overall direction is strong, but these ambiguities sit directly on the authority and release boundaries the RFC is intended to secure.
Review-Metadata:
verdict: REQUEST_CHANGES
head_sha: 277b1bd
request_id: req_1786305283_1194
review_profile: memory-aware-zero-trust-v2
advisory_memory_only: true
Reviewed by ouroboros-agent[bot] via Codex deep analysis
Convergence audit — HOLD, directionally sound but not yet an adoptable contractI independently reconciled the current Draft against linked issue #1948, the repository's durable execution boundary, CI, and the official review bot. Exact snapshot audited: The official What is already strongThe RFC is moving in the correct security direction:
Blocking gaps to resolve
Minimal convergence loop
This is not a rejection of the architecture. It is a request to make the two authority state machines and release contract executable enough that later native implementation cannot reinterpret away the promised safety properties. |
There was a problem hiding this comment.
Review — ouroboros-agent[bot]
Verdict: REQUEST_CHANGES
Metadata
| Field | Value |
|---|---|
| PR | #1969 |
| HEAD checked | 277b1bd34360c6636bf32ecfa7a284a818d99a89 |
| Request ID | req_1786322679_1346 |
| Review record | ce615d41-9633-4e22-b714-6d1c1aa59842 |
What Improved
- Defines a strong fail-closed direction: one retained native launch authority, no pathname fallback, complete pre-application load closure, explicit unsupported-platform outcomes, bounded lifecycle ownership, and adversarial platform feasibility gates.
- Correctly keeps #1948 open through native implementation, shared-runtime activation, packaging, and platform-matrix completion.
Issue Requirements
| Requirement | Status |
|---|---|
Select one retained ExecutableLease authority for attestation, probes, and launches without pathname fallback |
Met |
| Preserve live selected-chain revalidation before every probe and spawn | Met |
| Define immutable executable bytes and complete loader/interpreter/delegate closure | Met |
| Fail closed for unsupported platforms and entrypoint shapes | Met |
| Define a process and receipt contract that prevents effects when receipt publication fails | Not met |
| Integrate lease authority with durable publication and fresh-process resume semantics | Not met |
| Define an exact-version companion-wheel packaging and release strategy | Partially met — direction is specified, but the marker syntax is invalid and hook/editable resolution remains insufficiently executable |
| Provide the first-stack receipt schema, test vectors, and backend-neutral conformance interface | Not met |
| Define lifecycle, concurrency, cleanup, resource budgets, and platform feasibility gates | Partially met — broad requirements are present, but receipt settlement transitions remain incomplete |
| Keep #1948 open through native wheels, entrypoint support, shared-runtime activation, and the full platform matrix | Met |
| Limit this PR to architecture/design rather than claiming runtime delivery | Met |
Prior Findings Status
The prior review’s durable authority-publication, receipt-settlement, and dependency-marker concerns remain blocking based on fresh evidence from the current RFC and source snapshot. The subsequent human first-stack artifact concern also remains present: the current diff still contains only the RFC. No contributor response or current-source change addresses these points. Claims about stale branch state or remote CI were not used because they cannot be independently verified from the supplied snapshot.
Blockers
| # | File:Line | Severity | Finding |
|---|---|---|---|
| 1 | docs/rfc/executable-lease-launch-boundary.md:401 | BLOCKING | The async first-dispatch lease is not reconciled with the existing durable execution contract. runner.py:5631 publishes model_routing.runtime_execution before dispatch, while runner.py:6608 requires exact equality during fresh-process resume. The RFC says routing may cache an opaque capability and receipt evidence, but does not define a stable durable attestation fingerprint, a pre-publication sealing phase or atomic provisional→sealed transition, or how fresh-process reacquisition differs from retained in-memory resume. Because process-local lease_id cannot be reproduced and the pre-lease pathname identity is not the accepted native authority, an implementation cannot satisfy both the RFC and current replay checks without underspecified authority weakening. Define what is persisted, when it becomes authoritative, and how it is revalidated before the first effect and on both resume modes. |
| 2 | docs/rfc/executable-lease-launch-boundary.md:259 | BLOCKING | The launch protocol does not enforce the RFC’s own receipt-before-effect guarantee. The macOS and Windows strategies verify and then resume the child, while the public API returns the process and receipt together afterward. If receipt construction, serialization, Python delivery, cancellation, timeout, or child bookkeeping fails after native resume, application instructions may already have executed even though invariant 5 requires receipt failure to refuse before application code runs. Specify a native-owned two-phase state machine such as prepared/suspended → receipt delivered and acknowledged → committed/resumed, including timeout, cancellation, early child exit, Python delivery failure, kill/reap, and handle-cleanup transitions. |
| 3 | docs/rfc/executable-lease-launch-boundary.md:356 | BLOCKING | The proposed dependency-marker syntax is not valid PEP 508. Parsing each documented form (platform_machine in {"x86_64", "aarch64"}, and the macOS/Windows variants) with packaging.requirements.Requirement raises InvalidRequirement, so a generated Requires-Dist using this contract would make the core wheel metadata unusable. Replace these set expressions with complete valid boolean marker expressions, specify the exact Hatch metadata-hook/editable-workspace behavior, and require metadata parse/resolution tests for every supported OS, architecture, and Python 3.12–3.14 combination. |
Follow-up Findings
docs/rfc/executable-lease-launch-boundary.md:472[warning] The declared first delivery step says to merge the RFC together with the receipt schema, test vectors, and backend-neutral conformance interface, but the authoritative diff contains only this Markdown file and the snapshot contains no correspondingExecutableLeaseschema, vectors, or interface. This leaves the adopted stack gate internally inconsistent and allows later implementations to reinterpret prose without executable compatibility fixtures. Either include those first-stack artifacts in this PR or explicitly revise the delivery plan to assign them to the next mandatory stacked PR before native backend implementation begins.
| # | File:Line | Priority | Confidence | Suggestion |
|---|-----------|----------|------------|------------|
None.
Non-blocking Suggestions
None.
Test Coverage Notes
- Ran
SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest tests/integration/plugin/test_wheel_packaging.py tests/unit/orchestrator/test_routing_contract_resume.py -q: 202 tests passed. - Independently parsed the three documented companion-wheel marker forms with
packaging.requirements.Requirement; all three failed withInvalidRequirement. - The changed-files list and unified diff contain exactly one documentation file. No launch-receipt schema, test vectors, backend-neutral conformance interface, or tests for the proposed native lifecycle were added.
- Existing passing tests confirm the current packaging and durable-resume behavior, but cannot validate the proposed lease boundary.
Design Notes
The architecture is directionally strong and correctly moves authority into a retained native boundary. It is not yet an adoptable implementation contract because durable sealing, receipt settlement, packaging metadata, and first-stack executable artifacts remain underspecified or absent.
Design / Roadmap Gate
This PR affects a security-critical subprocess authority boundary shared by Codex, Copilot, Gemini, Goose, and Grok. Existing execution contracts are persisted before dispatch and exact-compared on resume, so lease acquisition cannot remain an unspecified lazy process-local detail. Likewise, a suspended child must not resume until receipt acceptance is irrevocable, and mandatory native dependencies must be expressible as valid, testable wheel metadata. The no-fallback, unsupported-platform, closure, lifecycle, and roadmap direction fits the project, but the unresolved state-machine and release-contract gaps prevent safe adoption.
Directional Notes
Review focused on replay-safe durable authority, exact effect-before-receipt ordering, valid reproducible wheel metadata, and executable conformance gates. Maintainer memory only directed these checks; every blocker is grounded in the current RFC, changed-files list, parser result, or existing runtime persistence source.
Test Coverage
- Ran
SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 /root/.local/bin/uv run python -m pytest tests/integration/plugin/test_wheel_packaging.py tests/unit/orchestrator/test_routing_contract_resume.py -q: 202 tests passed. - Independently parsed the three documented companion-wheel marker forms with
packaging.requirements.Requirement; all three failed withInvalidRequirement. - The changed-files list and unified diff contain exactly one documentation file. No launch-receipt schema, test vectors, backend-neutral conformance interface, or tests for the proposed native lifecycle were added.
- Existing passing tests confirm the current packaging and durable-resume behavior, but cannot validate the proposed lease boundary.
Merge Recommendation
Request changes before merging this RFC. Preserve the overall native lease direction, but define durable pre-effect sealing and fresh-process reacquisition, add an acknowledged receipt-before-resume protocol, replace the invalid PEP 508 markers with tested metadata mechanics, and either add or explicitly defer the promised first-stack schema, vectors, and conformance interface.
Review-Metadata:
verdict: REQUEST_CHANGES
head_sha: 277b1bd
request_id: req_1786322679_1346
review_profile: memory-aware-zero-trust-v2
advisory_memory_only: true
Reviewed by ouroboros-agent[bot] via Codex deep analysis
1 participant
Refs #1948
Summary
ExecutableLeasenative authority that owns attestation, version probes, and task launches without a pathname fallback.Direction decisions
Verification
git diff --checkpasses.LeasedProcess, packaging/release, drift, snapshot recovery, and runtime scope.Review focus
This Draft asks maintainers to approve or revise the architecture and packaging direction before native runtime code begins. It deliberately covers design only; #1948 remains open.