# 0.6.3 Rust-First Test Migration Review

## Executive Summary

- Review target: `0.6.3 rust-first-test-migration` spec package (requirements/design/tasks)
- Review method: inspected `git status --short`, reviewed uncommitted diffs first, traced spec requirements into `tools/e2e-harness/`, `tools/e2e/`, `Makefile`, `.github/workflows/ci.yml`, `AGENTS.md`, `docs/project/`, `docs/testing/`, and `tools/harness/`
- Commands executed as evidence:
  - `git status --short`
  - `git diff --stat`
  - `cargo run --manifest-path tools/e2e-harness/Cargo.toml -- suite --profile smoke`
  - `python3 tools/harness/check_harness_sync.py`
  - `make harness-check`
  - `make docs-check`
  - `make test-e2e-rust`
- Outcome: **Request Changes**
- Issue totals:
  - `P0 / Blocking`: 6
  - `P1 / Severe`: 4
  - `P2 / General`: 2
  - `P3 / Suggestion`: 3

The current change set updates governance and documentation to present the Rust
E2E harness as the canonical path, but the executable implementation is not yet
at the same maturity level. The largest gaps are that `make test-e2e` now
depends on a prebuilt `e2e-harness` binary, `make test-e2e-rust` fails in the
default Bootstrap path, the "migrated" Rust scenarios do not own runtime
lifecycle/fixture orchestration, and the new harness-routing pack is wired into
the manifest without its required documentation file, causing `harness-check` to
fail immediately. In addition, the fixture backend currently returns JSON
descriptors instead of real HTTP upstream responses, and AGENTS Rule 37 defines
Bootstrap behavior that conflicts with the 0.6.3 spec requirements.

Calibration note from follow-up verification: `bootstrap.rs` and `process.rs`
already contain substantial runnable infrastructure; the primary gap for
Bootstrap/lifecycle closure is wiring in `cli.rs` and scenario orchestration,
not greenfield implementation from scratch.

An additional review provided after the first draft correctly identified the
CI, Makefile, and harness-sync gaps, but it was still too optimistic in two
areas: Requirement 2 (Rust Harness Foundation) and Requirements 3-4 (Scenario
Migration / Python E2E Cleanup) cannot be marked as complete. The repository
contains the harness crate, scenario modules, parity docs, and C-boundary docs,
but the executable path is not yet closed: Bootstrap mode fails, shell wrappers
still retain canonical scenario logic, `make harness-check` fails, and the
Python E2E cleanup narrative contradicts the stated `Remove` classification.

## Issue Stats

```mermaid
radar-beta
  title 0.6.3 Migration Risk Profile
  axis RuntimeLifecycle, PublicUX, HarnessSync, Documentation, CIAutomation, TestCoverage
  curve Findings, 5, 4, 4, 4, 3, 4
```

| Area | Finding Count | Notes |
|---|---:|---|
| Runtime lifecycle / Bootstrap | 3 | Harness cannot yet own the canonical E2E path |
| Public UX / command stability | 2 | `make test-e2e` and `make test-e2e-rust` regressions |
| Harness sync / governance | 2 | Manifest and validation logic are out of sync |
| Documentation / release traceability | 3 | Docs overstate migration completion |
| CI / automation | 2 | Path filters updated, but execution coverage is missing |
| Tests / parity | 3 | Wrapper parity and harness integration tests are missing |

## Requirements Coverage

This section synthesizes the previously generated review with the later
reviewer's requirement-by-requirement assessment.

| Requirement | Status | Calibrated Conclusion |
|---|---|---|
| `Req 1: Audit & Classification` | PASS | `docs/project/0.6.3-test-surface-audit.md` is detailed and covers all mandatory scope directories. |
| `Req 2: Rust Harness Foundation` | PARTIAL / FAIL | `tools/e2e-harness/` exists, the CLI surface is present, and required flags are defined, but Bootstrap mode is not operational and the harness does not yet own runtime/fixture/process orchestration. |
| `Req 3: First Batch E2E Migration` | PARTIAL | Five Rust scenario modules and `docs/project/0.6.3-e2e-parity.md` exist, but the shell paths still contain full scenario logic rather than thin wrappers. |
| `Req 4: Python E2E Cleanup` | FAIL / DEFERRED | The audit classifies the two Python E2E files as `Remove`, but the later decision text and release notes retain them anyway without unique-runtime-coverage evidence. |
| `Req 5: C Test Boundary` | PASS | `docs/testing/C_TEST_BOUNDARY.md` is present and satisfies the boundary-definition requirement. |
| `Req 6: Makefile & CI Simplification` | FAIL | `make test-e2e-rust` fails in practice, and CI only adds path filters for `tools/e2e-harness/**` without running harness quality gates. |
| `Req 7: Harness Rule Updates` | FAIL | `AGENTS.md` Rule 37 is present, but `tools/harness/check_harness_sync.py` does not enforce the new harness contract, `make harness-check` currently fails, and Rule 37's Bootstrap guidance conflicts with the 0.6.3 requirement contract. |
| `Req 8: Documentation & Release Traceability` | FAIL | `make docs-check` fails due broken/new-doc references (`risk-packs/e2e-migration.md` missing and multiple internal `.kiro` spec-directory references), and `PROJECT_STATUS.md`/`CHANGELOG.md` still reflect `0.6.2`. |
| `Req 9: Preserve Existing Public UX` | FAIL | `make test-e2e` has a clean-environment binary dependency risk, and `make test-e2e-rust` does not satisfy the advertised default UX. |
| `Req 10: Release Validation & Completion Gates` | FAIL | The required public validation surfaces are not green after migration; `make harness-check`, `make docs-check`, and `make test-e2e-rust` all fail when run now. |

## Additional Verification

The later review recommended final validation of `make harness-check` and
`make test-e2e-rust`. Both commands were executed during this synthesis pass:

| Command | Result | Evidence |
|---|---|---|
| `make harness-check` | FAIL | `tools/harness/check_harness_sync.py` reports missing `docs/harness/risk-packs/e2e-migration.md`, so the new manifest entry is not self-consistent. |
| `make docs-check` | FAIL | `tools/docs/check_docs.py` reports broken/misaligned docs references, including missing `risk-packs/e2e-migration.md` and internal `.kiro` spec-directory references in committed docs. |
| `make test-e2e-rust` | FAIL | The target builds `e2e-harness`, then all registered scenarios fail because Bootstrap mode is not implemented for the smoke and migrated scenarios. |
| `cargo run --manifest-path tools/e2e-harness/Cargo.toml -- suite --profile smoke` | FAIL | Reproduces the same Bootstrap-mode failure even outside the Makefile wrapper. |
| `python3 tools/harness/check_harness_sync.py` | FAIL | Reproduces the same missing risk-pack document error that breaks `make harness-check`. |

These results confirm that the outstanding gaps are not theoretical. They are
current, reproducible failures on the branch under review.

## Findings

### Runtime And E2E Execution

| ID | Severity | Module | Files | Problem | Spec Reference | Actual Implementation | Fix Suggestion | Effort |
|---|---|---|---|---|---|---|---|---:|
| `P0-001` | Blocking | Canonical E2E suite | `tools/e2e/run_e2e_suite.sh:37-38`, `tools/e2e/run_e2e_suite.sh:155-167`, `Makefile:131-140` | `make test-e2e` now hard-codes `tools/e2e-harness/target/debug/e2e-harness` without building or resolving it first, so the public suite breaks on a clean checkout or CI worker that has not already run `cargo build`. | Requirement 3.5 / 6.2 / 9.1: "`make test-e2e` shall execute the migrated scenarios through the Rust harness without requiring a change to the public `make test-e2e` command." | The suite script invokes the debug binary directly; the top-level `test-e2e` target only delegates into `components/nginx-module/tests/Makefile` and never builds the harness first. | Build or resolve the harness inside `run_e2e_suite.sh` before first invocation, or delegate migrated cases through `cargo run --manifest-path ... -- scenario <name>` with a reusable build step. Add a smoke test that runs `make test-e2e` from a clean workspace state. | 3h |
| `P0-002` | Blocking | Rust harness entrypoint | `Makefile:136-140`, `tools/e2e-harness/src/cli.rs:121-135`, `tools/e2e-harness/src/bootstrap.rs:31-36`, `tools/e2e-harness/src/scenarios/smoke.rs:18-26`, `tools/e2e-harness/src/scenarios/conditional_requests.rs:32-40`, `tools/e2e-harness/src/scenarios/metrics_endpoint.rs:25-33`, `tools/e2e-harness/src/scenarios/status_codes.rs:25-33`, `tools/e2e-harness/src/scenarios/auth_cache.rs:27-35`, `tools/e2e-harness/src/scenarios/accept_negotiation.rs:25-33` | `make test-e2e-rust` cannot satisfy the default contract because every registered scenario fails immediately in Bootstrap mode. Verified by running `cargo run --manifest-path tools/e2e-harness/Cargo.toml -- suite --profile smoke`, which exits non-zero and prints `Bootstrap mode not yet supported` for all scenarios. | Requirement 2.5 / 2.7 / 6.8: "The Rust_E2E_Runner shall support both Reuse_Mode and Bootstrap_Mode." | The Make target runs `cargo run -- suite --profile smoke` without `--nginx-bin`; the harness selects Bootstrap mode and each scenario exits early. `bootstrap.rs` already has `prepare()` logic, but it is never wired into `run_scenario_inner()`. | Wire `bootstrap::prepare()` into `cli.rs` scenario setup (before scenario dispatch), pass resolved runtime inputs through context, and remove per-scenario Bootstrap immediate-fail branches. Add one integration test validating Bootstrap smoke path end-to-end. | 4h |
| `P0-003` | Blocking | Scenario migration | `tools/e2e-harness/src/cli.rs:166-193`, `tools/e2e-harness/src/process.rs:22-153`, `tools/e2e-harness/src/runtime.rs:78-170`, `tools/e2e-harness/src/scenarios/conditional_requests.rs:48-228`, `tools/e2e-harness/src/scenarios/metrics_endpoint.rs:41-219` | The Rust scenarios do not yet own NGINX process lifecycle, runtime preparation, or fixture backend orchestration. They issue HTTP requests against assumed endpoints on `127.0.0.1:<port>` but never call `ScenarioRuntime::prepare()`, `NginxProcess::start()`, or `start_fixture()`. | Requirement 2.8 / 2.10 / 2.11 / 3.3: "The Rust_E2E_Runner shall manage the NGINX process lifecycle... support embedded or launched fixture backends... and produce equivalent or stricter pass/fail behavior." | `process.rs` and `runtime.rs` already provide lifecycle primitives, but `cli.rs` dispatch never wires them into scenario execution; scenario files still assume pre-existing runtime. | Add orchestration wiring layer (prepare runtime/start fixture/start nginx/wait/cleanup) and make scenarios consume prepared runtime context. Prioritize wiring existing modules over rewriting them. | 8h |
| `P0-004` | Blocking | Fixture backend semantics | `tools/e2e-harness/src/fixtures/http_backend.rs:89-126` | Fixture route handling returns JSON descriptor payloads for every `RouteBehavior` variant (for example status/body/content-type encoded in JSON) instead of emitting real HTTP upstream responses with actual status/header/body semantics. This prevents fixture backends from behaving as real NGINX upstreams for migrated scenarios. | Requirement 2.10: "support embedded or launched fixture backends... for controlling status codes, headers, body content, and conditional-request behavior." | `handle_route` returns `axum::Json<serde_json::Value>` across all variants, so status/header/body behavior is descriptive rather than actual protocol behavior. | Replace JSON-descriptor route outputs with real HTTP responses (`IntoResponse`), and prefer integrating the existing logic in `fixtures/handlers.rs` instead of introducing a third behavior path. Then wire scenario assertions against those real responses. | 4h |
| `P1-004` | Severe | Thin wrapper parity | `tools/e2e/verify_accept_negotiation_e2e.sh:1-220`, `tools/e2e/verify_metrics_endpoint_e2e.sh:1-220`, `tools/e2e/verify_conditional_requests_e2e.sh:1-220`, `docs/project/0.6.3-e2e-parity.md:6-118`, `docs/testing/E2E_TESTS.md:29-46` | Docs describe the five scenarios as migrated, but the retained shell scripts still embed full build, runtime, fixture, and assertion logic. They are not thin wrappers, so the migration currently duplicates canonical behavior instead of relocating it. The migration table in `E2E_TESTS.md` can therefore be read as stronger completion than implementation currently provides. | Requirement 3.4: "The Shell_Wrapper ... shall not retain scenario-specific assertion logic." | The shell scripts still build or reuse NGINX, spin up Python upstreams, and perform the assertions that the docs mark as Rust-owned. | Either convert each script into a true wrapper that forwards flags/env into `e2e-harness scenario <name>`, or adjust migration wording to explicit "in-progress" until shell logic is actually removed. Add parity tests that compare wrapper behavior to direct harness execution. | 10h |

### Harness Governance And Validation

| ID | Severity | Module | Files | Problem | Spec Reference | Actual Implementation | Fix Suggestion | Effort |
|---|---|---|---|---|---|---|---|---:|
| `P0-005` | Blocking | Harness sync | `docs/harness/routing-manifest.json:565-600`, `docs/harness/routing-manifest.md:24-45` | The new `e2e-migration` risk pack is registered in both manifest surfaces, but its backing file `docs/harness/risk-packs/e2e-migration.md` is missing. `python3 tools/harness/check_harness_sync.py` fails with `missing docs: docs/harness/risk-packs/e2e-migration.md`, so the change set violates the required `make harness-check` gate. | Requirement 7.7 / 10.7: "When `make harness-check` is run ... it shall pass without errors." | The new pack is referenced in JSON and Markdown, but the doc file does not exist. | Add the missing risk-pack document in the same change set and rerun `make harness-check`. Include verification families, primary surfaces, and remediation guidance matching the manifest entry. | 1h |
| `P1-006` | Severe | Harness enforcement | `tools/harness/check_harness_sync.py:509-540`, `.github/workflows/ci.yml:74-86`, `.github/workflows/ci.yml:116-159` | Governance is documented, but not enforced. The harness validator does not check that `tools/e2e-harness/` exists, that `Cargo.toml` declares the `e2e-harness` binary, or that stale Python/new shell scenario paths are rejected. CI only adds path filters, and the `rust-quality` job does not run fmt/clippy/tests for `tools/e2e-harness`. | Requirement 7.6 / 6.7: "`tools/harness/check_harness_sync.py` or an equivalent path shall validate that `tools/e2e-harness/` exists and that its binary target is declared in `Cargo.toml`." | `check_harness_sync.py` only validates manifest/docs truth surfaces. The workflow currently relies on `e2e` filter output to trigger `rust-quality`; `tools/e2e-harness/**` is not explicitly part of the `rust` filter. | Extend `check_harness_sync.py` with explicit Rust harness checks and stale-path detection. Add harness quality steps (`fmt`/`clippy`/`test`) and at least one harness execution gate; also include `tools/e2e-harness/**` in the `rust` path filter for direct trigger semantics. | 4h |
| `P1-010` | Severe | Rule contract conflict | `AGENTS.md:1353-1358`, `0.6.3 requirements contract (Req 2.5/2.7)` | Repository rule text currently defines "Bootstrap_Mode returns a failing report" as the expected scenario pattern, which conflicts with the 0.6.3 requirement contract that Bootstrap mode shall provide a runnable runtime directly or via compatibility bridge. This creates conflicting governance for contributors and reviewers. | Requirement 2.5 / 2.7: Bootstrap mode must be supported and runnable, not normalized as permanent failure behavior. | Rule 37 codifies failing Bootstrap behavior while the spec requires executable Bootstrap behavior. | Align Rule 37 with the 0.6.3 requirement contract: treat failing Bootstrap behavior as temporary implementation gap, not normative rule semantics. | 1h |

### Documentation And Release Traceability

| ID | Severity | Module | Files | Problem | Spec Reference | Actual Implementation | Fix Suggestion | Effort |
|---|---|---|---|---|---|---|---|---:|
| `P1-007` | Severe | Python E2E cleanup | `docs/project/0.6.3-test-surface-audit.md:187-192`, `docs/project/0.6.3-test-surface-audit.md:260-279`, `docs/project/release-notes-0-6-3.md:41-47` | The audit correctly classifies the Python E2E spec files as `Remove` and states there are no unique product-level assertions, but a later section and the release notes override that with "intentionally retained" / "removal is deferred". This directly contradicts the spec and makes the release narrative internally inconsistent. | Requirement 4.1 / 4.3 / 4.5: "`test_streaming_e2e.py` and `test_streaming_failure_cache_e2e.py` shall be removed ... unless unique, non-duplicated runtime coverage remains." | The same document says removal is mandatory and that no unique assertions exist, then keeps both files anyway as "safety-net documentation". | Either delete the files now and update references, or provide documented evidence of unique runtime coverage that justifies retention. The current "no unique assertions exist" rationale cannot support keeping them. Add a regression check ensuring `make test-e2e` no longer invokes Python E2E for migrated/removed paths. | 2h |
| `P0-008` | Blocking | Docs validation contract | `docs/project/0.6.3-test-surface-audit.md:4`, `docs/testing/C_TEST_BOUNDARY.md:4`, `docs/project/0.6.3-checkpoint-1.3-notes.md:4`, `docs/harness/routing-manifest.md:45` | `make docs-check` fails on this branch. Besides the missing risk-pack doc already called out in `P0-005`, multiple newly added docs use internal/untracked `.kiro` spec-directory references that violate repo docs policy and immediately break the docs gate. | Requirement 8.8 / 10.6: "Documentation validation SHALL pass" and "WHEN `make docs-check` is run, THE documentation validation SHALL pass." | `tools/docs/check_docs.py` reports these exact violations and exits non-zero. The branch therefore cannot satisfy release validation gates even before functional runtime issues are fixed. | Replace internal `.kiro` spec-directory references with tracked-file references (or plain version text), and keep docs policy checks green in the same change set as review/doc updates. Keep `P0-005` fix in scope because its missing file also breaks `docs-check`. | 1h |
| `P2-012` | General | Release traceability | `docs/project/PROJECT_STATUS.md:14-23`, `CHANGELOG.md:8-12`, `Makefile:203-211` | Required release traceability surfaces are still on 0.6.2. This is not the primary blocker in the current branch: existing P0/P1 gates fail earlier, and the current `release-gates-check` target validates baseline/spec-framework gates rather than a dedicated 0.6.3 version gate. It still leaves release narrative inconsistent and should be fixed before closeout. | Requirement 8.4 / 8.6: project status and changelog must be updated for 0.6.3. | `release-notes-0-6-3.md` exists, but `PROJECT_STATUS.md` and `CHANGELOG.md` were not advanced to 0.6.3. | Update both files in the same change set as migration closeout, and keep them in docs/release verification scope. | 1.5h |

### Architecture And Code Quality

| ID | Severity | Module | Files | Problem | Spec Reference | Actual Implementation | Fix Suggestion | Effort |
|---|---|---|---|---|---|---|---|---:|
| `P2-013` | General | Fixture implementation split | `tools/e2e-harness/src/fixtures/handlers.rs`, `tools/e2e-harness/src/fixtures/http_backend.rs` | `handlers.rs` provides functional response logic (`conditional_handler`, `cache_handler`, `auth_handler`) but is not used by route execution in `http_backend.rs`; two fixture behavior implementations now exist in parallel and diverge. | Requirement 2.10 (deterministic backend behavior) and design intent (single fixture behavior model). | `http_backend.rs` serves JSON descriptor payloads while `handlers.rs` is only exercised by its own unit tests. | Unify fixture behavior to one production path: route execution should call shared behavior logic and emit real HTTP responses. | 3h |
| `P3-014` | Suggestion | Dead-code suppression scope | `tools/e2e-harness/src/main.rs:14` | Crate-level `#![allow(dead_code)]` masks module integration gaps and makes it harder to detect unused runtime/process/fixture APIs during migration. | Quality gate intent behind Requirement 2.17 (strict linting discipline for harness). | Global allow hides dead-code signals that would otherwise highlight incomplete wiring. | Remove crate-level allow; use narrow `#[allow(dead_code)]` only where intentional and temporary. | 1h |
| `P3-015` | Suggestion | Async/sync execution model drift | `tools/e2e-harness/src/http.rs`, `tools/e2e-harness/src/fixtures/http_backend.rs`, `0.6.3 design contract (scenario async signature)` | Scenario execution is synchronous (`reqwest::blocking`), while fixture lifecycle is async (`tokio`/`axum`) and design contract shows async scenario execution. This increases lifecycle orchestration friction for fixture start/ready/stop handling. | Design contract and migration architecture consistency. | Current sync scenario shape can still work, but requires extra runtime bridging and increases complexity of proper fixture lifecycle ownership. | Standardize on one model: either fully async scenarios or explicit/centralized runtime-bridge helpers with strong lifecycle tests. | 3h |
| `P3-016` | Suggestion | Suite script hygiene | `tools/e2e/run_e2e_suite.sh:144-153`, `tools/e2e/run_e2e_suite.sh:160` | `accept_args` is assigned (and conditionally populated) but never used in execution. This is low-risk but creates misleading maintenance surface and review noise. | Shell hygiene and maintainability. | Accept scenario execution uses `e2e_harness_args`; `accept_args` is dead state. | Remove the unused `accept_args` variable and keep argument flow single-sourced via `e2e_harness_args`. | 0.2h |

## Priority Matrix

| Priority | Severity Mapping | IDs | Immediate Goal |
|---|---|---|---|
| `P0` | Blocking | `P0-001`, `P0-002`, `P0-003`, `P0-004`, `P0-005`, `P0-008` | Restore executable command surfaces, real fixture semantics, and harness/docs checks |
| `P1` | Severe | `P1-004`, `P1-006`, `P1-007`, `P1-010` | Align migration claims, CI enforcement, and rule contract with spec |
| `P2` | General | `P2-012`, `P2-013` | Close release traceability drift and remove split fixture behavior paths |
| `P3` | Suggestion | `P3-014`, `P3-015`, `P3-016` | Improve maintainability and reduce future integration drift |

## Regression Test Cases

Each `P0`/`P1` issue below has at least one automated regression target.

| Finding ID | Proposed Automated Test | Recommended Location |
|---|---|---|
| `P0-001` | Run `make test-e2e` from a clean clone or after deleting `tools/e2e-harness/target/`; assert the suite bootstraps or builds the harness automatically. | `.github/workflows/ci.yml` + `tools/e2e` smoke job |
| `P0-002` | Run `cargo run --manifest-path tools/e2e-harness/Cargo.toml -- suite --profile smoke` without `NGINX_BIN`; assert Bootstrap mode either succeeds or returns the documented clear error for missing runtime. | `tools/e2e-harness/tests/bootstrap_mode.rs` |
| `P0-003` | Integration test that launches a fixture, prepares runtime, starts NGINX, waits for readiness, executes one migrated scenario, then confirms child-process cleanup. | `tools/e2e-harness/tests/runtime_lifecycle.rs` |
| `P0-004` | Fixture endpoint integration test that verifies upstream responses expose real HTTP status/header/body semantics (not JSON descriptors). | `tools/e2e-harness/tests/fixture_http_behavior.rs` |
| `P0-005` | `make harness-check` in CI must assert the presence of all referenced risk-pack docs, including `docs/harness/risk-packs/e2e-migration.md`. | existing harness-check workflow |
| `P0-008` | Run `make docs-check`; assert no internal `.kiro` spec-directory references in tracked docs and no broken `docs/harness/risk-packs/*` links. | docs-check workflow + docs policy tests |
| `P1-004` | For each migrated shell entrypoint, verify `bash tools/e2e/verify_<scenario>.sh --help` and a dry-run invocation delegate into `e2e-harness scenario <name>` without running in-script assertions. | `tools/e2e/tests/wrapper_parity.sh` |
| `P1-006` | Unit test for `check_harness_sync.py` that fails when `tools/e2e-harness/Cargo.toml` lacks the `[[bin]] name = "e2e-harness"` declaration. | `tools/harness/tests/test_check_harness_sync.py` |
| `P1-007` | CI guard that fails if `components/nginx-module/tests/e2e/test_streaming*.py` still exists after the migration flag is marked complete. | docs/release validation job |
| `P1-010` | Policy consistency test that fails when AGENTS rule text defines Bootstrap failure semantics incompatible with current spec contract. | `tools/harness/tests/test_check_harness_sync.py` or docs-policy check |

## Suggested Patch Outline

### Patch 1: Restore Command Stability

```diff
diff --git a/tools/e2e/run_e2e_suite.sh b/tools/e2e/run_e2e_suite.sh
@@
-E2E_HARNESS_BIN="${WORKSPACE_ROOT}/tools/e2e-harness/target/debug/e2e-harness"
+E2E_HARNESS_MANIFEST="${WORKSPACE_ROOT}/tools/e2e-harness/Cargo.toml"
+build_e2e_harness() {
+  cargo build --manifest-path "${E2E_HARNESS_MANIFEST}"
+}
+build_e2e_harness
+E2E_HARNESS_BIN="${WORKSPACE_ROOT}/tools/e2e-harness/target/debug/e2e-harness"
```

### Patch 2: Wire Runtime Ownership Into Harness

```rust
// sketch only
let runtime = prepare_runtime(&ctx)?;
let mut fixture = start_fixture(fixture_spec).await?;
let mut nginx = NginxProcess::start(
    &runtime.nginx_bin,
    &runtime.nginx_conf(),
    &runtime.base_url,
    ctx.timeout,
)?;
let report = run_assertions(&runtime, &ctx)?;
nginx.stop_graceful(ctx.timeout)?;
fixture.stop().await;
```

### Patch 3: Make Wrappers Actually Thin

```bash
#!/usr/bin/env bash
set -euo pipefail
exec cargo run --manifest-path tools/e2e-harness/Cargo.toml -- \
  scenario accept-negotiation "$@"
```

### Patch 4: Close Governance Drift

```diff
diff --git a/tools/harness/check_harness_sync.py b/tools/harness/check_harness_sync.py
@@
+def _check_e2e_harness_contract() -> CheckResult:
+    cargo_toml = REPO_ROOT / "tools" / "e2e-harness" / "Cargo.toml"
+    ...
+    return _result("e2e-harness-contract", PASS, "Rust harness contract present")
```

## Verification Script

```bash
#!/usr/bin/env bash
set -euo pipefail

python3 tools/harness/check_harness_sync.py
make docs-check
make harness-check

cargo fmt --check --manifest-path tools/e2e-harness/Cargo.toml
cargo clippy --manifest-path tools/e2e-harness/Cargo.toml --all-targets --all-features -- -D warnings
cargo test --all-features --manifest-path tools/e2e-harness/Cargo.toml

make test-e2e-rust
make test-e2e
```

## Acceptance Criteria

- All `P0` and `P1` findings are closed
- `make harness-check`, `make docs-check`, `make test-e2e-rust`, and `make test-e2e` are green on clean environments
- `cargo test --all-features --manifest-path tools/e2e-harness/Cargo.toml` passes
- CI contains an executable Rust harness validation path, not only path filters
- Python E2E cleanup is either completed or re-scoped with an explicit spec update
- Documentation and release traceability surfaces (`PROJECT_STATUS.md`, `CHANGELOG.md`, release notes, audit, parity docs) agree on the same 0.6.3 state
