[Feature] Establish Simpler as a vLLM program execution backend

[Crane-Liu]

Summary

Establish Simpler's program execution path as a safe, measurable backend for vLLM serving. The work starts from the Pipeline A run-to-run enqueue capability and ends with a fixed Qwen workload running through a vLLM eager adapter, followed by capture/replay support where the target SDK and platform contracts are proven.

The device remains serial at the operator level. The host may prepare and enqueue later runs while an earlier run is still executing; every run must retain independent completion, result, error, and resource ownership until its last consumer is finished.

Why this issue exists

Pipeline A and the P3 contracts provide the runtime foundation for this work:

• [Feature] Let consecutive runs queue on the same stream instead of round-tripping through a host sync #1853 tracks natural program-path queuing and the removal of host round trips from the run-to-run critical path.
• [Code Health] Codify parent-run ordering and host-build contracts (Track A P3) #2316 tracks parent-run ordering, build ownership, and host-access contracts required before broader admission.
• Let one run's device work be enqueued behind another's #2419 (5818054b) is merged and provides the first bounded Worker.submit early-enqueue capability.
• [Performance] Stage all eligible workers for a prepared successor run #2415 tracks staging all eligible workers for a prepared successor and is relevant when the target workload needs multi-worker staging.
• [CI][Flaky] Track code-level concurrency and completion-order failures in early-enqueue/HBG tests #2425 tracks intermittent early-enqueue and completion-order evidence; its findings must be resolved or explicitly bounded before acceptance claims are widened.

This issue is the end-to-end integration tracker. Individual implementation PRs should remain focused and link back here.

Scope and boundaries

The work is split into a program-path milestone and a later vLLM/capture milestone.

Program-path milestone

1. Validate the current P4 capability: real Worker.submit early enqueue, whole-operator device ordering, sustained refill, and depth-one default behavior.
2. Revalidate P1–P3 contracts under the new admission path:
   • run-owned parameter, runtime/image, arena, result, timing, and diagnostic resources;
   • per-run completion/drain, error attribution, event references, and generation retirement;
   • parent-run dispatch FIFO, prepared-successor admission, build/recorder ownership, and host accessor ordering;
   • safe default, unsupported-shape fallback, diagnostic exclusivity, direct-control, close, and stop-admission paths.
3. Extend the proven path only where the target workload requires it, with an explicit capability matrix for A3/A5 HBG, TMR, HOST/DEVICE tensors, group/SUB/communication/provider shapes, and endpoint scope.
4. Replace fixed-slot assumptions with bounded resource accounting and backpressure only after run identity, last-consumer retirement, workspace growth, and failure handling are proven.
5. Integrate continuous DFX collection by collector and runtime, preserving run identity, buffer ownership, accounting, bounded flush/close, and diagnostic isolation.

vLLM milestone

6. Freeze the Qwen workload and ABI: weights, prompt/token hash, prefill/decode shape, KV/page layout, sampling, output contract, and device/software versions.
7. Add a fixed-shape Simpler-backed vLLM eager path through the public model-runner boundary, then cover the agreed dynamic batch and request-lifecycle range.
8. Add capture/replay only after the preparation-result, parameter-binding, graph-reference lifetime, and target SDK contracts are established. Capture/replay is a separate capability boundary from the first program-path milestone.
9. Run end-to-end correctness and performance comparisons with identical workload and device conditions.

Current acceptance gate

The first P4 acceptance phase passed on the bounded A3 HBG scope: local L3, same endpoint, HOST tensors, single non-group NEXT_LEVEL task, launch_depth=2, with depth one as the default control.

The P1–P3 regression phase is currently partial:

• CPU contract tests passed, including admission/lifecycle coverage after the current runtime was built.
• A3 worker_async_fifo passed for HBG and TMR.
• worker_async_endpoint failed on both device 0 and device 1 with the same FFTSPLUS AICore fault (507018, 0x4000000000000000), followed by scheduler -100 and force reset.

The original endpoint failure was investigated with controlled depth-one/depth-two runs and five-round pressure tests on two additional devices. The fault did not reproduce with the same main, callable, and runtime. It is retained as a non-stable device/runtime anomaly; no code repair is opened from this incident. The bounded program-path milestone is now complete for the documented scope, while vendor-level root-cause analysis remains optional follow-up if maintainers request it.

Milestones

• P4 bounded capability and evidence audit complete
• P1–P3 contracts pass under the new admission path (bounded program-path scope)
• Endpoint fault dispositioned as a non-stable device/runtime anomaly; bounded supported scope recorded
• Qwen fixed-workload Worker.submit path is correct for the bounded Step 2 scope (depth one real qualification; depth-two safe fallback)
• Step 3 clone-request L3 contract and A3 early-enqueue evidence accepted (Test clone requests on the early-enqueue path #2471)
• PR-S3-1 clone-request contract implementation and complete CI validation passed; merge pending
• Qwen clone-request path is connected on the merged Step 2 baseline
• Same-request DEVICE feedback joined enqueue is accepted for the target shape
• Required A3/A5 HBG and TMR capability matrix is accepted
• Resource lifetime, workspace budget, backpressure, and continuous DFX contracts are accepted
• vLLM fixed-shape eager path is correct
• Agreed dynamic request range is correct
• Capture/replay capability is accepted for the target platform/version
• End-to-end correctness and performance report is complete

Step 2 closeout and Step 3 handoff

The bounded Qwen Step 2 scope is complete in two review PRs:

• #2447: real Qwen depth-one Worker.submit, 127-step autoregressive token/KV qualification, adapter and lifecycle contract.
• #2456: workload manifest, dependency matrix, depth-two request evidence, and explicit safe serial fallback when host sampled-token feedback prevents joined enqueue.

Both PRs are merged into main. The Step 2 depth-two conclusion is a safe fallback; it does not claim joined native early enqueue.

Step 3 starts with the L3 clone-request path on the current program runtime. The first proof uses multiple logically independent requests with identical workload content:

• request content may be identical;
• request/run/generation identities must differ;
• live KV pages, block tables, input staging, sampled-token/output buffers, events, errors, results, and resource leases must be request-private;
• request B must be prepared and enqueued while request A is still executing;
• operator execution remains serial, parent dispatch FIFO remains ordered, and A remains readable after B starts;
• physical capacity may be reused only after the previous request's last consumer retires.

PR #2471 is the first Step 3 contract/evidence PR. It adds the clone-request identity/resource checks to the existing A3 early-enqueue path and records A3 hardware evidence. Its current head is 0095497523c33fb86766d5e90e01de649ea578a3, based on main at 833327f60ea8f4772bf1673ea8edb349314a350d. The complete GitHub CI matrix passed, including A2A3/A5 simulation and onboard checks, UT, pre-commit, build, and DeepSeek/network validation. The PR remains open pending merge. It does not add Qwen adapter code or change runtime admission.

After the clone-request contract is accepted, the project will connect the real Qwen adapter on the post-merge Step 2 baseline. Same-request adjacent decode feedback (sampled token/KV/sequence metadata) is a separate DEVICE producer/consumer capability and remains depth-one fallback until proven. A5 HBG, TMR, multi-worker extensions, and distinct-request HBG numerical correctness remain separate capability work. The existing program-path boundaries remain in force: operator execution stays serial, host access has no implicit cross-run synchronization, and unsupported shapes must fall back or be rejected explicitly.

Tracking rules

Every implementation PR must:

• link this issue in the PR body, using Part of #<issue-number> unless the PR is intended to close the entire issue;
• state the exact phase and capability it changes;
• record the base/head, supported scope, tests, hardware task IDs and evidence paths;
• preserve the distinction between accepted, prepared, enqueued, completed, and retired states;
• document unsupported or fallback paths when the change affects admission.

Progress updates on this issue should summarize the phase, current commit, evidence, open blocker, and next action. Individual PR merge does not close this issue. Close this issue only after the milestone checklist and final vLLM acceptance are complete.

Related design boundaries

The first milestone follows the existing program-path Pipeline A design. Kernel API work, tiling caches, ACLGraph, and capture-specific resource contracts are separate follow-on capabilities and are not implicit prerequisites for the bounded program-path acceptance. No stage in this issue changes device execution from serial operator ordering to device concurrency, adds implicit host tensor synchronization, or promises a performance gain before controlled measurements are complete.

[Crane-Liu]

Initial progress snapshot — 2026-09-23

• Current main tested for the P1–P3 regression: 385956e29cd2e3d6ace7bfa4ab98a8bbce3027fa.
• P4 bounded A3 HBG early-enqueue evidence is available from the merged Let one run's device work be enqueued behind another's #2419 line (5818054b): depth-two early submission, whole-operator ordering, sustained refill, and depth-one control passed.
• P1–P3 CPU contract coverage passed after building the current runtime; A3 worker_async_fifo passed for both HBG and TMR.
• The remaining gate is worker_async_endpoint: device 0 and device 1 both reproduced FFTSPLUS AICore fault 507018 / 0x4000000000000000, followed by scheduler -100 and force reset.
• The failure is under diagnosis. It is not currently attributed to a card, the test, or the P4 implementation without a minimal comparison and call-chain analysis.

Next action: isolate the endpoint failure against depth-one/depth-two and the FIFO control shape, identify the smallest trigger and ownership boundary, then propose the repair or supported-scope decision here before opening an implementation PR.

[Crane-Liu]

Endpoint fault diagnostic update — 2026-09-23

The endpoint fault is partially localized; the stable root cause remains unknown.

Confirmed from the original failures

• Both original failures used current main 385956e29cd2e3d6ace7bfa4ab98a8bbce3027fa.
• The endpoint path completed bind, image publication, input staging, and native preparation before the device fault.
• The observed sequence was 507018 / FFTSPLUS AIVector 0x4000000000000000, then bounded drain 507015, scheduler -100, and force reset.
• The original endpoint test did not request launch_depth; it exercised the depth-one prepared-successor path. The original failures therefore do not directly establish a P4 early-launch defect.

Bounded diagnosis

• Explicit depth-one endpoint variant: task task_20260922_183549_204396217140, device 0, passed.
• Explicit depth-two endpoint variant: task task_20260922_183718_211147514872, device 0, passed; both runs reported aic_rc=0 and wo_rc=0 device boundaries.

The endpoint kernel/configuration is therefore not a stable failure on the current main, and the direct P4 causal claim is weakened. A timing, lifecycle, scene-specific, or environment interaction remains possible and requires further evidence.

Diagnostic report and evidence are retained in the phase worktree and 686 logs. No production/test source was changed and no PR was opened. The program-path milestone remains gated until the endpoint behavior is either explained and accepted or fixed and revalidated.

[Crane-Liu]

Endpoint cross-card stress disposition — 2026-09-23

The bounded follow-up stress test changes the release disposition for the original endpoint fault.

Using current main 385956e29cd2e3d6ace7bfa4ab98a8bbce3027fa, the same endpoint callable/runtime, and launch_depth=2:

• Device 2: task task_20260922_201340_305144232401, 5 rounds × 2 runs, 10 submits, exit 0.
• Device 3: task task_20260922_201340_30514466036, 5 rounds × 2 runs, 10 submits, exit 0.
• Both devices had no 507018, 507015, FFTSPLUS, AICPU exception, or force reset.

Together with the controlled depth-one/depth-two endpoint passes, this is sufficient for the implementation decision: there is no stable code or P4 admission failure to repair at this time. The two original endpoint faults remain recorded as a non-stable device/runtime execution anomaly; vendor-level AICore dump evidence was unavailable for those original failures.

Next project action: update the Phase 2 P1–P3 report and close the Step 1 acceptance gate with this limitation recorded, then begin the fixed Qwen production-path phase. No endpoint/P4 code change or PR is opened from this incident.

[Crane-Liu]

Step 1 closed — bounded program-path scope — 2026-09-23

Step 1 is now closed for the documented bounded scope.

Evidence:

• P4 early enqueue, whole-operator ordering, sustained refill, and depth-one control passed on the Let one run's device work be enqueued behind another's #2419 line.
• P1–P3 CPU contract coverage passed on current main after the current runtime was built.
• A3 worker_async_fifo passed for HBG and TMR.
• The original endpoint fault was not reproduced by controlled depth-one/depth-two runs or by five-round depth-two pressure on two additional devices using the same main, endpoint callable, and runtime.

Disposition:

• No endpoint/P4 code repair is opened from the incident.
• The original FFTSPLUS fault remains recorded as a non-stable device/runtime anomaly because the original vendor-level dump was unavailable.
• The accepted scope remains bounded: current program path, documented A3 HBG/endpoint/HOST/single NEXT_LEVEL conditions, depth-one default and depth-two opt-in, plus the tested CPU/FIFO contracts.
• A5, complex group/SUB, cross-endpoint, DEVICE tensor, full continuous DFX, and broader resource-depth claims remain separate follow-up work.

Next phase: freeze the Qwen workload and ABI, establish the single-launched correctness baseline, map decode/KV/token dependencies, and identify which portions can use the accepted program-path enqueue capability.

[Crane-Liu]

Step 2 code delivery PR opened — 2026-09-24

PR #2447 is open from Crane-Liu:codex/vllm-step2-qwen at commit 279671d3.

This PR delivers the fixture-backed standalone adapter and the Worker.submit contract:

• per-step metadata, KV/page state, and sampled-token chain;
• generated 25/26-argument ABI validation and explicit buffer directions;
• handle completion, sampled-output consumption, and slot-retirement rules;
• workload/evidence documentation and focused CPU tests.

Validation recorded in the PR: 55 Qwen-related CPU tests passed, 21 standalone-adapter tests passed, plus ruff, formatting, and diff checks.

The PR is intentionally scoped as the Step 2 code and contract delivery. Real NPU token/KV golden qualification remains open because the available fixture contains structural expanded rows and the prior shared runtime path was blocked by FANIN_CAPACITY_EXCEEDED. The real prefill/KV/golden evidence will be added in a later update once available.

Step 2 is therefore split into two review gates:

1. review and merge the standalone adapter/contract code in Qualify real Qwen Worker.submit depth one #2447;
2. complete real token/KV hardware qualification before claiming the full workload milestone or starting broader vLLM/P5 work.

[Crane-Liu]

Progress and blocker report — 2026-09-24

A local handoff report is available at VLLM接入当前进展与阻塞说明.md in the project workspace.

Current status:

• Step 1 bounded program-path acceptance is complete: P4 early enqueue and the P1–P3 CPU/FIFO contracts are accepted for the documented A3 scope; the historical endpoint fault is retained as a non-stable device/runtime anomaly.
• Step 2 code/contract delivery is open in PR Qualify real Qwen Worker.submit depth one #2447 at commit 279671d3: fixture-backed standalone adapter, metadata/KV/page state, sampled-token chain, 25/26-argument ABI validation, and Worker.submit lifecycle. CPU validation is green (55 Qwen-related tests, 21 adapter-focused tests, lint/format/diff checks).
• Step 2 real workload qualification is still open. The available fixture-v2 passes structural checks but contains an expanded structural golden; the prior shared NPU decode path was blocked by FANIN_CAPACITY_EXCEEDED.

The current blocker needs one of the following from the responsible owner:

1. authorized access/copy of the original old_snapshot_v1 fixture/artifact/golden under /data/l00955553/tmr_workspaces/serving_tmr_20260901_card12/, including manifests and checksums;
2. a supported method and environment to regenerate the real prefill/KV/sampled-token golden;
3. a diagnosis or compatible runtime/configuration for the FANIN_CAPACITY_EXCEEDED path if the restored fixture is the authoritative input.

Until real token/KV qualification is available, #2447 should be reviewed as the standalone adapter/contract delivery. The full Step 2 milestone and Step 3 production runtime expansion remain gated by real depth-one token/KV correctness followed by bounded depth-two validation.

[Crane-Liu]

Step 2 first PR updated: real Qwen3-14B Worker.submit depth-one qualification is now pushed to PR #2447 at commit 13a799de. Task task_20260924_104821_77637523973 passed 127 decode dispatches, 2,032 exact tokens, and KV readback at steps 0/117/118/126. The distinct-request HBG consumer and depth-two capability remain explicitly scoped for the follow-up PR.

[Crane-Liu]

Step 2 closeout update

Step 2 is now split into two focused pull requests, with the distinct-request HBG consumer investigation kept in a separate workstream.

PRs

• PR #2447 — real Qwen3-14B Worker.submit depth-one path and single-request KV qualification. Cleanup head: 7a28eaf7.
• PR #2456 — Step 2 closeout manifest, dependency matrix, bounded depth-two fallback evidence, and final documentation. Head: 5e926fb2.

Depth-one evidence

The real Qwen reference path completed 127 autoregressive dispatches and matched all 2,032 sampled tokens. The accepted qualification recorded logits and K/V checks, including prefix preservation, unused-tail zeroing, and the page boundary at step 118.

Depth-two conclusion

Hardware task [task_20260925_043921_34195018347] requested launch_depth=2 with the same manifest, model, KV bundle, and artifact. The driver applied the explicit safe serial fallback required by host sampled-token feedback:

• requested depth: 2;
• effective depth: 1;
• 127 dispatches completed;
• 2,032 tokens matched exactly;
• maximum logits relative L2: 0.0348324;
• minimum cosine: 0.9995546;
• all 40-layer K/V readback passed at steps 0, 117, 118, and 126;
• run IDs were continuous from 1 through 127.

This establishes the bounded Step 2 fallback and complete depth-one correctness. It does not claim joined native early enqueue for the host sampled-token feedback path. Any future DEVICE/P5 early-enqueue capability remains a separate runtime work item.

Scope and validation

The closeout adds a workload manifest, dependency matrix, depth-two decision record, and closeout report. Qwen reference/adapter/artifact tests passed (20 passed), Ruff and formatting checks passed, and mkdocs build --strict passed.

The 16-request distinct-KV HBG post-processing issue is handled separately. It is excluded from both Step 2 PRs and does not change the bounded Step 2 conclusion above.

[Crane-Liu]

Step 3 planning baseline — 2026-09-27

For planning, treat PRs #2447 and #2456 as the approved Step 2 baseline after maintainer review and merge. No merge action is performed by this update.

Step 3 begins with the capability that Step 2 intentionally records as a gap: Qwen DEVICE-backed KV with joined native early enqueue. The first implementation slice should establish the real producer/consumer ordering for sampled tokens and KV, independent per-run metadata/output storage, last-consumer retirement, and a safe fallback when the dependency cannot be submitted early.

The next slices are capability-driven:

1. A3 HBG Qwen path and task-shape matrix;
2. multi-worker staging only if the real Qwen task shape requires it;
3. distinct-request HBG numerical correctness from the separate workstream;
4. A5 HBG submit/poll ownership and board evidence;
5. TMR shared-arena and completion compatibility if required by the workload.

The operator execution order remains serial. Step 3 does not add implicit host synchronization, broaden support to group/SUB, cross-endpoint, DEVICE tensor, A5, or TMR without separate evidence, or mix capture/replay into the program-path change.

[Crane-Liu]

Step 3 handoff update: two parallel workstreams (2026-09-27)

Assuming the bounded Step 2 review PRs (#2447 and #2456) are merged on a clean current base, Step 3 can begin implementation. The Step 2 depth-two result remains a safe serial fallback; it does not establish joined native early enqueue.

We are proceeding on two parallel workstreams:

1. L3 / real early-enqueue capability (main implementation line)

   • Add the Qwen DEVICE-backed KV and sampled-token producer/consumer contract needed for joined native enqueue.
   • Define per-run metadata/output ownership, event dependencies, and last-consumer retirement.
   • Implement the L3 active/staged request path while preserving parent dispatch FIFO and serial operator execution.
   • Build the A3 capability matrix and contract tests first, then extend only to workload shapes that are explicitly proven.

2. HBG distinct numerical correctness (independent validation line)

   • The corrected loader and one-step controls are working: distinct-row counts 0/1/2/4/8/16 produce correct tokens.
   • Three-step runs pass through four distinct rows, but eight/sixteen rows still fail at step 2 in numerical/KV checks. A single row can pass logits/tokens while appended KV still diverges in later layers.
   • The current evidence points to a conditional multi-row, cross-layer KV-append/numerical propagation issue. It is not localized to a stable single-layer defect and has not yet produced a production fix PR.
   • This line does not block starting the Step 3 control-plane and DEVICE-KV implementation, but it remains a gate for final HBG multi-request correctness acceptance.

Step 3 acceptance boundary

Step 3 development may proceed after Step 2 is merged and the P3/P4 contracts remain green. We must not claim final HBG multi-request support, joined native early enqueue, or A5/TMR support until the corresponding capability-specific evidence passes. Final HBG acceptance requires combining the two lines: real DEVICE-KV joined enqueue, at least two in-flight requests with continuous refill, and reproducible token/logit/KV correctness over the intended multi-step workload.

Every follow-up implementation PR should link this issue, state which workstream and capability it changes, and record the exact supported/fallback scope and evidence.

[Crane-Liu]

Step 3 scope correction: clone requests are the primary multi-request case (2026-09-28)

The project will continue Step 3 with multiple logically independent requests that intentionally carry the same workload content. This is the correct first proof for L3 asynchronous multi-request handling: identical prompt/model inputs remove content variance, while request identity and resource ownership remain independent.

For example:

request A: prompt=X, request_id=A
request B: prompt=X, request_id=B
request C: prompt=X, request_id=C

Equal request content must never cause live requests to share request-private state. While requests are live, each request must have independent:

• request/run identity;
• KV pages and block table;
• input staging, sampled-token and output buffers;
• completion events, errors, timing and result records;
• resource lease and retirement state.

The implementation may still share immutable model weights, callable/configuration data, and may reuse physical workspace only after the previous request's last consumer has retired. This follows the repository lifetime rule: logical ownership is per request; physical capacity reuse is allowed only after an explicit retirement proof.

Step 3 primary acceptance path

1. Accept request B while request A is still executing.
2. Prepare and enqueue B before A completes; a post-completion submit does not count as asynchronous early enqueue.
3. Preserve parent dispatch FIFO and serial operator execution.
4. Verify live request-private addresses/pages do not alias.
5. Keep A's result readable after B starts.
6. Reuse A's physical capacity only after A's last consumer retires.
7. Extend from depth-two to continuous refill and bounded backpressure.

This changes the Step 3 entry condition: HBG distinct is not a prerequisite for the L3 clone-request path. The first implementation and validation PRs should use the already-qualified same-content Qwen workload, duplicated into separate request contexts and storage, then prove real overlap, ownership, result isolation and retirement.

Independent HBG distinct capability

HBG distinct remains tracked separately in #2459. That issue concerns distinct KV tails/rows inside the HBG execution path and currently reports token success but appended-KV drift after decode step 2. It does not establish that L3 requests overwrite each other's state, and it does not block beginning the clone-request implementation. It remains a separate backend capability gate for distinct-row numerical correctness.

The two lines share some HBG/KV implementation components, so clone-request validation must still inspect request-private addresses and KV ownership rather than relying only on equal output tokens. Final HBG distinct support will require its own KV correctness evidence and fix PR; it must not be claimed from the clone-request result.

All Step 3 PRs should link this issue, state that they implement the clone-request or HBG-distinct workstream, and record the exact supported/fallback scope and evidence.

[Crane-Liu]

Step 2 PR correction and review status (2026-09-28)

The two Step 2 PRs have been rebuilt as a clean stacked series on main 50fb75b9 (which includes the WorkspaceManager test ABI correction from #2463):

PR	Current head	Scope	Current status
#2447	fb8d1c28007e9e7f99f49c5b730a4fdf0235290e	Real Qwen depth-one Worker.submit qualification	Open; mergeable/clean; 18 CI checks succeeded, 1 deploy check skipped, 0 failures
#2456	cf03b1646f6f20d9edea9359673579ebc0ad853d	Bounded depth-two request closeout with effective-depth-one safe fallback	Open; mergeable/clean; 18 CI checks succeeded, 1 deploy check skipped, 0 failures

#2447 is one logical implementation commit. #2456 is stacked on #2447 and contains one additional closeout commit (two commits shown by GitHub when viewed from main). Earlier UT failures caused by the mainline ABI mismatch are resolved by the new base. Earlier A5 queue/test failures did not recur in the current-head CI matrix. Both PRs still await maintainer review and merge; passing checks do not mean they have been merged.

Scope conclusion: Together these PRs complete the bounded Step 2 evidence: real Qwen depth-one correctness plus an explicit safe fallback when depth two is requested but host sampled-token feedback prevents joined enqueue. They do not deliver real Qwen native depth-two early enqueue or L3 multi-request concurrency.

Step 3 handoff: Continue with the clone-request plan recorded above: multiple requests may have identical content but must have distinct identities and independent live request-private KV, block tables, token/output buffers, completion/error state, and resource leases. Prove that a successor is enqueued while its predecessor is still executing, then prove continuous refill and last-consumer retirement. The HBG distinct numerical issue remains a separate backend workstream in #2459 and is not a prerequisite for starting this clone-request path.

[Crane-Liu]

Step 3 PR-S3-1 delivered — clone-request contract

PR #2471 has been created and linked to this issue.

Scope:

• identical request payload content with separate request-private buffers;
• distinct canonical buffer identity and mapped address checks;
• distinct run/task/pipeline lease identity checks;
• existing public A3 Worker.submit early-enqueue evidence remains the hardware gate;
• no production runtime, Qwen adapter, HBG distinct, A5/TMR, or implicit host synchronization changes.

Validation:

• test_early_launch_admission: 9 passed;
• test_pending_run_queue: 14 passed;
• test_orchestrator: 62 passed;
• test_chip_run_lane_joined_launch: 13 passed;
• Python compile and Ruff checks passed;
• A3 host_build_graph hardware task task_20260928_053953_303588416890: TestEarlyEnqueueDepthTwo::early_enqueue passed, exit 0.

The next decision point is review of #2471. After it is accepted, the next implementation is the real Qwen clone-request path on the merged Step 2 baseline. Same-request DEVICE feedback remains a separate later capability.

[Crane-Liu]

Step 3 PR-S3-1 review update — 2026-09-29

PR #2471 was re-reviewed with the installed exhaustive-code-slimmer and ce-simplify-code skills and updated to head 18291ec855d6736056da1dc8495a5b77c6f22ad1.

The review fixes are limited to the two contract tests:

• Keep distinct output sentinels in the Python scene so result attribution, output overwrite, and cross-run aliasing remain observable while request buffers are independently allocated.
• Rename the C++ case to DistinctSubmissionsOwnIdentityAndLease because the fixture constructs two submissions directly rather than invoking a clone API.
• Route the second C++ submission through acceptance before completion and release.

Validation on 686:

• test_early_launch_admission, test_pending_run_queue, test_orchestrator, and test_chip_run_lane_joined_launch all passed.
• Python compile, Ruff, Ruff format, clang-format, diff check, and changed-file path scan passed.
• A3 host_build_graph hardware task task_20260929_044650_295943030348 passed TestEarlyEnqueueDepthTwo::early_enqueue.

The first hardware retry hit an isolated AICore/CCECPU timeout during finalization; the subsequent clean queued run passed. No runtime production code changed. The Step 3 clone-request acceptance checklist remains pending until #2471 is reviewed and merged; the next implementation target remains the real Qwen clone-request path on the merged Step 2 baseline.