APEX 1.0.0

APEX 1.0.0

This release establishes the APEX 1.0 public contract from the integrated development branch. The product version is 1.0.0 across the Rust package, capability discovery, MCP server metadata and OpenAPI. Input schema identifiers remain separate from the product version.

Product changes

• Ship the complete application in app/, including the Rust crate, lockfile, embedded viewer, schemas, examples, product skills, deployment helpers and full license. The application can be copied and built without contributor tooling or parent-directory dependencies.
• Use consistent component names: XG for construction, XH for hypersearch, XT for tree search and XE for direct schedule evolution. Combined improvement reports XHT or XHTE and preserves the existing shared budget and independent validation behavior.
• Advertise the canonical schedule.hypersearch and schedule.treesearch tools across all three transports and expose component identities in capability discovery. The viewer, examples and product documentation use the same names.
• Upgrade sha2 from 0.10.9 to 0.11.0 with compatible lowercase, zero-padded SHA-256 output for imports and policy fingerprints.

Compatibility and migration from 0.6.0

The repository layout, CLI/tool names and Rust API changes require callers and native customizations to update:

1. Run Cargo and npm commands from app/. The runtime source is now app/src/; product documentation, examples and skills also live under app/. Update build paths and use app/deploy/build.sh, app/deploy/start-viewer.sh and app/deploy/setup-mcp.sh. Rebuild and regenerate local MCP configuration with the new executable path while retaining the intended data workspace.
2. Replace CLI train with hypersearch and plus with treesearch. Replace tool calls schedule.train and schedule.plus with schedule.hypersearch and schedule.treesearch; the old command/tool names are not supported. schedule.create, schedule.improve, schedule.evolve and schedule.repair remain available.
3. Write options using xh, xt, xe, improve.xh_share and improve.xe_share. The previous JSON input keys trainer, plus, evolution, trainer_share and evolution_share remain accepted as aliases for saved options. Output and generated schemas use the canonical names. Supplying both names for the same field is rejected.
4. Update consumers of search reports and capability feature names to the canonical component names. Search reports use XH, XT, XE, XHT or XHTE; phase labels use XH, XT:n and XE. CLI benchmark output uses xg for the producer version and XG/XH method identities. XE diagnostic codes use the XE_ prefix.
5. Native Rust consumers must update module imports from engine/evolution to xg/xe, use the xh and xt search APIs and the renamed option types/fields, and rename the customization hook evolution_operators to xe_operators. Recompile native customizations.

Canonical apex.v3.1, apex.v3.2, apex.v3.3 and executable apex.v3.4 inputs continue to share one runtime. Existing saved results remain readable. No data-schema renumbering, license change or new optimality guarantee accompanies the product version change.

Contributor maintenance

Contributor scripts, workflow skills and historical migration evidence live under dev/. Protected PR integration targets dev; releases promote a selected revision to main, publish an immutable source tag and release, update the wiki after successful CI, and synchronize the release back to dev. Normal Dependabot updates target dev. The frozen benchmark reproduction package remains unchanged.

Validation

The integrated candidate passed local Rust formatting, Clippy with warnings denied, the Rust test suite and release build. The 47 contributor tests, generated skill checks, documentation links, wiki validation and source publication checks passed. MCP and HTTP integration passed against the rebuilt executable. The detached application check verifies builds and planning using only application source. Required CI checks cover Linux, Windows and macOS Rust builds/tests, Linux MCP/HTTP/viewer integration, source publication and the standalone distribution before merge.

Validation establishes the tested behavior; it does not establish complete historical v2 parity, universal production readiness or optimality. Existing documented scheduling and search limits remain in effect.