# 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/