Why QCUL Pushes the Exact Package Tested in the Laboratory

QCUL pushes the exact tested package so production receives the same bytes that produced the reviewed laboratory evidence rather than a later redownload with the same version label.

Exact-package chain

  1. Capture package into protected run storage during lab test.
  2. Record filename, size, SHA-256 and target identity.
  3. Install those bytes in the laboratory and record the result.
  4. Before push, verify the stored package/hash still match.
  5. Copy that exact package to Joomla temporary storage and hash again.
  6. Install on production through Joomla Installer/core adapter.

Why this matters

Vendor/CDN packages can change without a visible version change. Redownloading at production time would break the evidence chain. If QCUL cannot prove the original tested package is intact, the safe response is to test the newly captured package, not to ignore the mismatch.

Production change rule

For Why QCUL Pushes the Exact Package Tested in the Laboratory, the live site should change only through the explicit tested-item production workflow after current readiness checks pass. Do not substitute a new package, skip the review/protection decision, or run a second production action while QCUL already owns an active push/rollback state.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.