# Concresca FULL ROOT r9 — activation without a disabled-checkbox dead end

Release: `concresca-full-root-20260928-r9`.

This is the complete website and application at the root, not a partial patch.
It contains the existing Python runtime, verifier, migrations, public pages,
locked PHP diagnostics and host installer. Earlier repair archives are not
required. This release repairs the activation controls; it is not evidence of
successful production activation or autonomous verification.

## Deploy and activate

Extract the entire ZIP into the **existing website document root** containing
`passenger_wsgi.py`, `concresca_runtime/`, `assets/` and `status/`. There is no
outer folder or `public/` directory to merge. Do not empty the website first.
Keep an existing host backup and preserve the root `.htaccess`, external private
environment, Python environment, database, `runtime/` state and account-home
`.concresca-diagnostics/`. They are not distributed in the archive.

Open a fresh page at `https://concresca.com/concresca-diagnostics.php`. Confirm
that the footer ends in **root-r9**. Unlock with the current code from the
existing private account-home `.concresca-diagnostics/access-code.txt` file.
Do not put the code in a URL or share it in a report.

Select **Activate installed release**. The button is enabled after unlocking;
it performs the read-only prerequisite check automatically. When activation is
allowed, the page opens a visible **Confirm the hosting changes** section.
Select **Confirm activation** to submit the write request, or **Cancel — make
no changes** to stop. There is **no activation checkbox** in this revision.
The separate **Check activation prerequisites** button remains optional.

A `permission_repair_required` result with `canActivate: true` is actionable:
the confirmation shows the reported directory/file counts. Permission repair
runs only after confirmation; remaining host checks have not passed yet. A
blocked check instead shows its reason and leaves the initial button available
for a later recheck. Authentication or CSRF errors still require a fresh unlock.

The button is temporarily disabled during an in-flight request or known active
job, with an adjacent explanation. A lost start response changes its action to
**Check previous activation result** rather than submitting a duplicate. The
saved job can also be read with **Refresh activation result**. Download its
redacted result with **Download activation result**.

Uploading alone does not run the installer or register verification. This is
a one-time deployment operation, not human approval during normal service
operation. PHP must be able to run the installed Python backend. No terminal
command is required for the browser path. The existing alternative is:

```sh
python concresca-repair/activate.py
```

Run that only on the host from this root using its existing application Python
environment; do not run two installation methods concurrently.

## What changed

The r8 page initialized activation as disabled and required both the allowed
preflight result and a separate checked checkbox. The supplied report shows
`permission_repair_required`, `canActivate: true` and `packageComplete: true`.
The old UI still remained disabled until its separate checkbox event occurred.
In the local Chromium fixture it enabled after checking that checkbox; this
does not establish why the checkbox was missed or unusable in the user's
browser. R9 removes that dependency entirely, rather than telling the user to
keep trying a control they report cannot be used.

The first activation click is read-only. A distinct confirmation button is the
only JavaScript action that sends `activation_start`. It includes the current
release identifier, and PHP still checks authentication, a fresh unlock, CSRF,
origin, allowed fields, pinned backend hashes and job locking. Python rechecks
the release and host prerequisites before changes. No security check, workflow
gate or required receipt was forced to pass.

The controls now serialize requests, show why they are busy, retain the latest
failure for download, and require saved-job readback after an uncertain start.
They do not resend a mutation automatically after a lost response.

Saved activation results retain their actual release, timestamp and run ID.
When an older job is displayed by r9, `viewerReleaseId` identifies this page
separately and `recordedForDifferentRelease: true` is shown. Its process lock
is checked even for older releases. Merely uploading r9 does not convert an
old failed job into a new activation.

## Existing permission and installation safeguards

R8's bounded repair is retained. It removes group/other write bits only from
eligible account-owned release paths: `old_mode & ~0022`. Examples are
`0777 -> 0755` and `0666 -> 0644`. It preserves file bytes and does not add
permissions. Symlinks, unexpected source, hardlinks, unowned writable paths,
unsafe anchors and concurrent replacements are rejected, not bypassed.
Private credentials, database contents and receipt evidence are not recreated.

After permission repair and byte re-verification, the installer checks the
existing private environment, interpreter and scheduling capability. It then
updates managed routing, removes the recognized static status placeholder,
checks the real runtime routes and installs the verifier schedule. The existing
transaction rollback protections remain unchanged. Permission tightening is
retained if later routing fails, rather than reopening unsafe write access.

The full-root manifest, PHP backend pins and historical file fingerprints are
regenerated consistently. There is no root `.htaccess`, static status pointer,
private environment, diagnostic code, mutable runtime state or passing receipt
in this archive. ZIP directory/file modes request `0755`/`0644`; actual host
permissions are still checked by activation, not assumed from extraction.

## Results and limits

`permission_repair_required` is not successful installation.
`installed_verification_pending` means the installer observed routing and
registered scheduling; it is not completed autonomous acceptance. The existing
22 required workflow checks, receipt validity and healthy-verifier requirements
are unchanged. The final service criteria remain real runtime status JSON,
`productionReady: true`, current evidence for all required checks, a healthy
verifier and HTTP 200 from `/autonomyz`.

No live-host activation was performed while preparing this release. Browser
rendering tests use the real PHP-emitted page with controlled responses;
canonical-host browser navigation is blocked by the test environment. Native
Apache/PHP request tests are separate, and do not establish LiteSpeed,
Passenger, production MySQL, production scheduling or live workflow success.
See TEST-RESULTS.md and the external final-archive validation record.