Release Verification

An XTend change is ready to ship when source code, package contents, public types, documentation and machine-readable reports describe the same surface. This page covers the local checks that an integrator can verify before a merge or release.

Verification does not publish a package, and its core path does not require registry access. Network-dependent audit and SBOM evidence remains a separate, explicitly enabled step.

Fast pull request path

Run the report gate for a normal pull request:

npm run test:pr:report

The command writes .xtend-test-results/xtend-pr-gate-report.json. A successful process exit is not enough by itself. Check that every suite reports passed, that there are no unexpected skips, and that all expected subreports are registered.

For a documentation-only or DevTools extension change, run the focused path first:

node scripts/run_xtend_tests.js xtend-dev-surface docs-public-quality docs-content-depth references --json

The complete pull request report remains the integration check afterwards.

Full release verification

Before a release, verify the wider suite and package contents separately:

npm run test:release:full:report
npm run release:report
npm run pack:dry-run

test:release:full:report creates .xtend-test-results/xtend-release-gate-report.json. release:report writes .xtend-test-results/xtend-release-report.json. The pack dry run produces an archive inventory without publishing to a registry.

Compare three layers:

Gate reports must contain every required suite and artifact.
The archive inventory must not contain private fixtures, build caches, secrets or unapproved framework runtimes.
Public exports, .d.ts files and documentation paths must resolve to files that are actually shipped.

Read the reports

An XTend runner report records at least status, exit code, pass, failure, skip and warning counts for every suite. For failed, the first message is a starting point rather than necessarily the root cause. Follow the named files and rerun the affected suite with --json.

blocked means a required precondition was deliberately not met, such as a missing local runtime, a policy decision or a disallowed network path. Do not change the gate threshold in response. Provide the prerequisite or document why that operation is outside this release path.

Warnings are acceptable only when the report explicitly classifies them as non-blocking. A growing warning count indicates drift and should be investigated before release.

Offline and network evidence

Local core gates remain offline-capable. npm audit, registry requests and SBOM generation belong to conditional network evidence and must not prevent a developer without network access from checking source, types, manifests and package contracts.

If your release environment requires network evidence, run it in an approved job and retain the report together with the package fingerprint. See Conditional Network Evidence and Supply Chain Checks for the boundary.

Resolve common failures

For a missing export, compare package.json, the actual package archive and the corresponding .d.ts file. Do not add only a test marker: the export must resolve from the installed package.

When references fails, a path, schema or command has usually drifted between its source of truth and a consumer. Update the stale consumer and preserve the public name unless a migration has been announced.

When a docs gate fails, repair the content, locale pair, menu entry or link. Internal status records belong under development/, not in the public navigation as an exception.

When the pack dry run fails, inspect files, exports and generated artifacts in package.json first. A green test run does not prove that the published archive is complete or free of internal files.

Next steps

Bilingual documentation for 0.8.0

Verify DE and EN together: new APIs, defaults, migration steps and executable examples must agree. The release overview links scheduler/FastPass, Abort Boundaries, diagnostic demand, Hydrangea, the page runtime and Page Wire. Hydrangea remains opt-in; local measurements do not establish universal production latency.

After article or menu changes, regenerate navigation, search indexes and MCP knowledge:

node scripts/build_docs_navigation.js --write
node scripts/build_docs_search_indexes.js --write
node products/xtend-mcp/scripts/build-knowledge.mjs
node scripts/run_xtend_tests.js docs-public-quality docs-content-depth docs-quality-gates maraca-docs rmt-reference-docs rmt-tooling-docs rmt-playground-docs --json

After language-catalog changes, also generate the RMT AI Developer Kit with xt rmt ai-kit export --profile full --format jsonl --out tools/rmt-language/generated/rmt-ai-developer-kit --json before building MCP knowledge. After framework-runtime changes, rebuild the Docs shell with xt maraca tune docs/xtendrmt-docs-document-v2.rmt --config docs/maraca.config.json --out docs/generated/shell --write --json. Then use the corresponding --check paths.

In the browser, verify new articles in both languages, search, locale switching and narrow views. Docs acceptance supplements the full release, type, schema, artifact and package checks; it replaces neither the CI matrix nor the separate publishing step.

Profile capability preflight and harness regressions

The no-argument preflight retains the Nightly toolchain-stage contract (Node/subprocesses, npm, SQLite, PHP and a Chromium loopback probe). Run an explicit catalog profile after its fixtures have been prepared:

node scripts/test-runner/capabilities.js
node scripts/test-runner/capabilities.js --profile ci-release
node scripts/test-runner/capabilities.js --profile ci-nightly
node --test tests/browser/lifecycle_harness.test.cjs

The profile report distinguishes required, optional and unselected browser coverage. PHP includes a real UTF-8 to UTF-16BE iconv conversion; selected Laravel checks require installed fixture files, locked PHP extensions and a working autoloader. A configured fixture path alone is insufficient. Composer is a preparation prerequisite, not a new requirement to execute an already installed fixture. The no-argument Nightly phase deliberately does not require fixtures that later phases install.

Execution provenance records the effective PHP version, executable, extensions and ini hashes, plus configured local browser/driver versions. Changed PHP configuration invalidates report reuse. External WebDriver endpoint identity does not prove that a remote server has kept the same browser image; retain its actual browser evidence separately. Capability reports do not replace suite outcomes or prove every application-specific prerequisite. Existing advisory and skip rules remain unchanged.

The focused Lifecycle test uses the registered result key and the existing 10-second browser deadline. It requires the unchanged fixture to pass, then rejects a wrong result key and a foreign-origin asset served from a second local port. Absolute same-origin HTTP(S) URLs remain valid. Missing browser infrastructure fails this explicit test; it is not silently skipped.

--verify --from verifies an execution JSON and its provenance/suite records. Rejecting a missing input JSON does not establish integrity or freshness of logs/screenshots referenced inside it. Keep those artifact checks separate.

XTend Developer Center