APEX 1.0.2

APEX 1.0.2

Changes

• Fix the demo's Open in Excel action when an earlier starter created its shared
  desktop bridge as root. Initialization now uses the configured container user
  and repairs the bridge directory ownership without replacing the workbook.
• Keep the synthetic demo at October 5, 2026, 10:00 Europe/Berlin. The MES shows
  the fixed snapshot and rejects attempts to advance it. Order, receipt,
  calendar and Excel dates do not move with the computer's current date.
• Carry the frozen snapshot through chat onboarding, adapter assumptions,
  import reports and persisted scenario source views. Distinguish work already
  overdue at that snapshot from predicted lateness in a validated future plan.

Compatibility and upgrade

The scheduling input contract and engine semantics are unchanged. Rebuild the
demo containers with the normal starter and resume existing data to apply the
fixes. Credentials, MES edits, saved workbooks and APEX plans are retained.

The optional demo's clock control is intentionally read-only; POST /api/clock
now returns HTTP 409. A previously advanced saved snapshot is preserved, not
silently reset. Existing imported scenarios also retain their original evidence;
new imports and updated chat instructions carry the explicit frozen time basis.

Sequence-dependent setup matrices and workplan-navigation changes are not
included. The full-factory acceptance case explicitly extends the planning
horizon to October 30, 2026 and uses the release construction strategy. This
does not change the demo's October 5 snapshot or its October 16 source horizon,
and does not claim feasibility under the original horizon or optimality.

Validation

The reviewed feature revision passed CI on Linux, Windows and macOS, including
Rust linting, tests and release builds, real-engine adapter validation, MCP/HTTP
and viewer integration, standalone source-distribution checks, PostgreSQL
conformance and publication checks. The container acceptance test imports all
3,705 unfinished demo operations from MES and saved Excel, plans them and checks
the independently validated MCP result and source views. It also verifies frozen
time after import, service recreation and reset, Excel bridge ownership, workbook
persistence and retained access tokens. Local checks additionally passed 55 MES
tests, 54 contributor tests and locale consistency checks. The versioned release
candidate must pass the same required CI gate before merging.

APEX 1.0.1

APEX 1.0.1

This release brings the integrated factory showcase to the MCP App: MES and saved Excel data can be imported, planned, independently validated and explored through a branded Planning overview in chat.

Product changes

• Add an optional demo adapter for the public MES API and saved Excel workbook. It exports canonical scheduling facts and source evidence, detects newly added rows, preserves explicit commitments, and rejects malformed or ambiguous data with source locations.
• Ship the standard Planning overview with aggregate KPIs, delivery outcomes, critical orders, resource utilization, work mix and searchable schedule navigation. Package hooks support additional views and renderers; the demo supplies MES/Excel source coverage and import notices.
• Correct general construction to consider machines, phase-specific staff, shifts and material when selecting feasible modes. Construction and full decoding share transactional placement state for eligible models; neighbor-dependent and native-policy models retain their full decoding path. Dated stock reservations allow independent earlier work without borrowing future material.
• Keep the application, engine, middleware and desktop package versions aligned so MCP discovery and result provenance identify the same product release.
• Provide the central control platform with authenticated HTTP/MCP access, scenarios and immutable revisions, background planning runs, saved results and PostgreSQL persistence. Runtime configuration selects optional packages; the standalone application remains independent of contributor tooling.
• Include standalone and composed demo container deployment, a bilingual synthetic MES, the shared saved workbook and local onboarding with resume/reset and connection details. Explicit adapter import leaves MES and workbook records unchanged.
• Improve input diagnostics for zero processing allowances and Excel proposals beyond the selected horizon. Keep source-specific interpretation in customization modules and reusable planning/display behavior in the application.

Verified showcase and limits

The complete synthetic source contains 3,800 MES operations and 3,800 Excel rows. Excluding completed history leaves 3,705 operations, including six running operations and 65 locks. With the horizon explicitly extended to October 30, 2026, the existing release strategy constructs a complete independently validated plan without replaying Excel assignments or ordering. A local Windows release-build measurement took about 2.3 seconds. The resulting plan has 41 of 118 remaining orders on time; this is a feasible starting plan, not an optimization or delivery-performance claim.

The original October 16 source horizon and the default queues strategy did not yield complete plans in these checks. Failed greedy construction does not prove infeasibility. Horizons are never extended automatically. New source edits require a fresh import, planning run and validation. The adapter guide describes the explicit tested showcase settings.

Validation

Local checks passed Rust formatting, Clippy with warnings denied, 173 Rust tests (two explicitly ignored), 22 adapter tests with the release engine, 54 contributor tests and 54 MES tests. The standalone source export builds and exercises all five planning methods and additional fixtures. A clean source publication scan, documentation/wiki checks and both language-template checks passed.

MCP SDK, control-platform and browser checks cover branding, charts, filters, custom views, revision pinning, validation state, errors, schedule search and responsive layouts. The full factory result renders all 3,705 operations with a bounded initial schedule view. Isolated standalone/demo container checks exercise authenticated planning, the full MES/Excel import, MCP views, database isolation, restart persistence and reset behavior.

Contributor maintenance

Reconcile onboarding with the implemented adapter, publish the Planning overview guide in the wiki, mark superseded implementation plans as historical and keep architecture/search documentation aligned with shared placement and dated material reservations. Runtime snapshots, generated reports and local credentials remain outside the source distribution. Required benchmark and migration evidence is retained.

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.