# Eva-CLI V1.5 Release Hardening (Historical)

> Language: English
>
> Published default: `docs/en/release/v1.5-release-hardening.md`
>
> Translation: [Simplified Chinese](../../zh-CN/release/V1.5发布加固.md)

Updated: 2026-07-14

Status: historical description of the release command surface introduced before the `v1.5.0` tag; not a current production-readiness assertion.

## Scope

V1.5 added a source-release hardening report to turn release assumptions into structured CLI output. The commands aggregate declarations and evidence; they are not themselves a CI runner, vulnerability scanner, benchmark harness, compatibility diff, or production certification system.

Current release and production gaps are tracked in the [V1.x incomplete feature inventory](../planning/v1.x-incomplete-feature-inventory.md).

![Eva-CLI release history boundary](../../../assets/release-history-boundary.svg)

## Version Context

| Signal | Meaning |
| --- | --- |
| V1.0 | Internal milestone commit `437087c`; no `v1.0` tag exists |
| V1.4 | Internal lifecycle milestone commit `909ab07`; no `v1.4` tag exists |
| V1.5.0 | Annotated tag `v1.5.0`, resolving to commit `74d85e7da58ac40ef5d30b38e2844dee503a44c0` |
| Current `main` | Cargo and CLI report `1.11.5-alpha`; later V1.12-V1.17 strings are legacy evidence IDs, not release tags |

## Commands Introduced By V1.5

```powershell
cargo run -- release check --output json
cargo run -- release check --target windows --output json
cargo run -- release security --output json
cargo run -- release perf --output json
cargo run -- release migration --output json
```

| Command | Historical contract |
| --- | --- |
| `release check` | Aggregate platform, stability, documentation, security, performance, and migration gate objects |
| `release security` | Print the security findings compiled into `eva-release` |
| `release perf` | Print fixed source-release smoke budgets and observations |
| `release migration` | Print a declared migration guide and compatibility policy for supplied version labels |

## Evidence Model

![Eva-CLI release workflow evidence path](../../../assets/release-workflow-evidence-path.svg)

| Layer | Behavior | What it proves |
| --- | --- | --- |
| Static declarations | The V1.5 implementation constructs platform passes, stability scenarios, security findings, fixed performance observations, and a compatibility result in process | The report shape and declared source-release boundary only |
| Repository fixture | Current `main` additionally verifies a compiled-in MCP compatibility fixture | Fixture consistency, not an external MCP server run |
| Optional evidence | Current `main` can parse artifact, distribution, security-scan, and benchmark evidence files when explicitly supplied | The supplied file satisfies its parser and verification rules |
| CI execution | `.github/workflows/release.yml` separately runs Cargo checks, platform jobs, scans, benchmark commands, packaging, and evidence capture | That specific workflow run and its retained artifacts |
| External prerequisites | Signing identities, package repositories, platform service hosts, hardware fixtures, and production telemetry/storage require separate environments | Nothing until independently executed and recorded |

`release check` does not invoke the commands named inside gate evidence. With default inputs on current `main`, `status:"ready"` means that no required gate object is marked blocked; it does not mean that CI, scanners, external services, credentials, or production integrations ran during that invocation.

## Historical Gate Groups

| Group | V1.5 intent | Evidence limit |
| --- | --- | --- |
| Cross-platform | Record Windows, Linux, and macOS smoke expectations | Platform rows were declarations; CI performed the actual jobs |
| Stability | Record task, replay, restore-plan, and upgrade-plan scenarios | Recovery paths were local or synthetic boundaries |
| Documentation | Require release notes, migration, compatibility, and README coverage | Presence and consistency required separate validation |
| Security | Report policy, Lua, redaction, MCP, hardware, and lifecycle findings | Findings were compiled records, not a live scanner |
| Performance | Report EventBus, Scheduler, Adapter, memory, backup, and release budgets | Values were smoke constants, not production measurements |
| Migration | Declare the V1.4-to-V1.5 compatibility policy | No tag or schema diff was performed |

## Tag Boundary

The `v1.5.0` tag was a source-release checkpoint. It did not contain packaged installers, signed artifacts, real MCP server execution, raw hardware I/O, destructive restore apply, or an OS-managed Supervisor handoff. This is a statement about that immutable tag, not a forecast of work after it.

Current `main` has added controlled alpha paths in several of those areas. Their exact limitations belong in the operations and planning documents rather than this historical V1.5 record.

## Reproducing The Historical Checkpoint

Run these commands only from a `v1.5.0` checkout when reproducing the historical result:

```powershell
cargo fmt --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
cargo run -- --version
cargo run -- release check --output json
cargo run -- release security --output json
cargo run -- release perf --output json
cargo run -- release migration --output json
./scripts/build-site-i18n.ps1
./scripts/validate-i18n.ps1
```

Running the same commands on `main` validates current code and produces current `1.11.5-alpha` reports; it does not recreate the V1.5 acceptance record.

## Related References

- [V1.5 release acceptance record](v1.5-release-acceptance.md)
- [V1.5 migration declaration](v1.5-migration-guide.md)
- [V1.5 compatibility policy](v1.5-compatibility-policy.md)
- [Current V1.x incomplete feature inventory](../planning/v1.x-incomplete-feature-inventory.md)
- [Current process upgrade boundary](../operations/process-level-upgrade.md)
- [Project release plan](project-release-plan.md)