Concresca FULL ROOT r7 — corrected activation sequence and error reports

Report body

Concresca FULL ROOT r7 — corrected activation sequence and error reports

Release concresca-full-root-20260927-r7, 27 September 2026.

This is a complete flat-root release, not an overlay. It includes the existing application, website, automatic verifier and authenticated PHP activation page. R7 corrects two reproduced r6 activation-interface defects. It does not claim that the live Python route has been activated or that all workflows have passed.

Deploy the whole release

Extract the entire archive into the EXISTING website document root containing passenger_wsgi.py, concresca_runtime/, assets/ and status/. There is no outer project folder and no separate public/ directory to merge. A previous r6 installation is not required. Do not empty the destination first.

Preserve the existing root .htaccess, external private environment, Python environment, database, runtime/ state, and account-home .concresca-diagnostics/ directory. These host-specific resources are NOT included in the archive. Back up the existing installation before replacing code. A release archive is not a copy of your hosting account or credentials.

Open a fresh page at:

https://concresca.com/concresca-diagnostics.php

The footer must identify concresca-locked-diagnostics-20260927-root-r7. Unlock using the current code from the existing private account-home file .concresca-diagnostics/access-code.txt. Do not send the code in chat or URLs.

In Activate installed release, choose Check activation prerequisites. When it passes, tick the consent checkbox and choose Activate installed release. The check no longer consumes the start action's rate limit. Repeated checks and repeated starts still have their own short rate limits; concurrent installation is independently prevented by the backend process lock.

No terminal command is required for this path. Uploading files alone still does not execute the host installer. The one-time authenticated activation runs the fixed packaged installer to configure routing and the automatic schedule. Subsequent verifier runs do not require this page to remain open or unlocked.

Two demonstrated r6 defects corrected

Cross-action rate limiting: r6 used one timestamp for both prerequisite checking and installation start. A start immediately after a check could return HTTP 429 ACTIVATION_RATE_LIMIT. A native local Apache/PHP HTTPS test reproduced this with the unmodified r6 page/backend. R7 uses separate action timestamps, retains repeat-submission limits and sends a bounded Retry-After value.

Stale error export: after a start request was rejected, r6 could leave the Download activation result button exporting the previous preflight_passed result instead of the new error. The regression test reproduced that exact mismatch. R7 replaces the displayed/downloadable result with a redacted report of the current failed request. Network errors, unconfirmed server errors and non-JSON responses get an explicit unavailable-response report, not raw server text or a stale success.

These defects are local reproductions. They are NOT established as the cause of the existing live HTTP 404, nor proof that an r6 activation was attempted.

Interpreting results

A backend result uses schema concresca.web-activation.v1. A browser request failure report uses concresca.web-activation.client-result.v1; it is not an installer completion receipt. Its allowlisted fields include the requested action, HTTP status when available, error code and bounded retry interval. No tokens, access codes, arbitrary error strings, response bodies or paths are included. The current failure remains downloadable even after a prior successful prerequisite check.

preflight_passed means only that prerequisites passed; it made no routing change. started or running is progress, not service readiness. installed_verification_pending is the installer's historical observation of routing and scheduler registration, not current workflow acceptance.

request_rejected describes a refused request. response_unavailable means that the browser did not obtain a usable result; a submitted start may still have reached the backend. Do NOT repeatedly click start in that case: use Refresh activation result to read the saved job. It does not start a job. After a lost session or FRESH_UNLOCK_REQUIRED, reopen and unlock the page, then refresh the saved result. Download the current redacted result for review.

A started job executes independently of the browser. Its private state is saved at account-home .concresca-diagnostics/activation-state.json. An unfinished job without its process lock is reported as interrupted, not successful. Hard host termination or concurrent deployment can prevent complete rollback, so an interrupted result does not certify rollback.

Existing installer behavior retained

The PHP action accepts no arbitrary command, URL, interpreter or private path. It requires authentication, CSRF validation, explicit release-specific consent, a recent unlock and matching backend source hashes. It invokes the fixed Python backend without a shell. Whole-release verification and existing account-local Python, private configuration and scheduler checks occur before installation. The installer preserves unrelated host configuration and schedules, removes only the recognized static status placeholder, checks the served runtime and private-route protection, and registers verification every five minutes. Readback failures enter its compare-before-restore transaction. This release does not bypass disabled PHP process functions, unavailable host integration, missing dependencies, account permissions, cron restrictions or database errors.

The CLI alternative remains python concresca-repair/activate.py using the existing application Python. It is not required for browser activation.

Readiness completion criterion

First the readiness URL must return genuine runtime JSON rather than 404, and /status/current.json must not serve the static placeholder. Then the verifier must obtain current matching evidence for all 22 workflows and a healthy heartbeat before productionReady is true and /autonomyz returns HTTP 200. No status flag, receipt TTL or workflow requirement was weakened in r7.

Validation boundary

See TEST-RESULTS.md and the external validation record for executed results. Native tests here use local Apache/mod_php, not LiteSpeed/Passenger on your account. The new HTTPS fixture deliberately lacks production configuration: the real backend starts and correctly stops without changing routing. Successful installer transactions remain simulated-host tests. Browser-report tests use a synthetic DOM, not a completed browser navigation. No production deployment, MySQL activation or unattended production recovery is claimed.

Implementation references (not proof of production configuration): https://www.php.net/manual/en/function.proc-open.php https://docs.litespeedtech.com/lsws/cp/cpanel/cloudlinux/