# Concresca — complete root deployment, 2026-09-27 / r4

Release ID: `concresca-full-root-20260927-r4`

## What this archive is

This is the complete application/public-file release for the **existing Concresca website document root**. It is not a patch overlay and does not require any earlier repair ZIP. `index.html`, `passenger_wsgi.py`, `concresca_runtime/`, `assets/`, `status/`, all included public content, database migrations, the verifier, and the locked diagnostic page are already in their destination locations. There is no outer wrapper directory and no nested `public/` deployment to merge by hand.

The complete archive is assembled from the original user-supplied project, the latest host-activation/autonomous-verifier repair, and the locked diagnostics. The old stored receipts, development caches, machine coordination notes, development reports and test dependency installations are not a production release and are excluded.

**This is a complete application release, not a copy of your hosting account.** The running database, external private environment, existing `runtime/` state, diagnostic access-code directory, virtual environment, and root `.htaccess` are server-local resources. They are intentionally not shipped or overwritten by extracting the ZIP. Keeping them is necessary to avoid losing credentials, records, recovery progress, or host-specific settings.

## Deploy this one archive

Back up the existing website/application before replacing its release files. Do **not** empty the website directory and do not use a sync mode that deletes files absent from the ZIP.

Extract the archive directly into the existing domain document root. After extraction, these paths must be siblings:

```text
index.html
passenger_wsgi.py
app.py
requirements.txt
concresca_runtime/
assets/
status/
database/
concresca-repair/
concresca-diagnostics.php
concresca-diagnostics-check.txt
concresca-release.json
```

Existing `.htaccess`, `runtime/`, your private environment and the database remain in place. Do not copy a generic `.htaccess` over the host's own configuration. The archive carries its portable base template under `concresca-repair/`, not as an active root replacement.

From that root, using the hosting application's Python environment, execute the single post-deployment command:

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

This is the activation command for **this complete release**, not a request to install an earlier partial package. Use it as the deployment system's post-deploy command when that facility is available. Upload/extraction alone cannot install a host schedule or configure a server module.

To check just the distributed files without network requests, database access, cron changes or host-configuration writes:

```sh
python3 concresca-repair/activate.py --check-only
```

The checker verifies every listed distributed file against the complete-release manifest. A `packageComplete: true` result means the release files match; it is explicitly **not** a production-readiness result.

## What activation does

The activator verifies the complete release first, detects unexpected leftover runtime source rather than silently mixing code, and selects the explicit flat-root layout. An old `public/` directory cannot silently become this release's public root.

The host installer then validates the existing external private environment and MySQL driver, preserves unrelated hosting directives and existing schedules, and applies the owned Passenger/LiteSpeed configuration. It removes only the recognized `FETCH_RUNTIME_STATUS` static placeholder from the active status path. Unrecognized files are preserved and reported instead of deleted.

It checks the document root with an exact random non-secret file readback, signals the relevant restart locations, and verifies that the public API routes report the newly installed runtime fingerprints. It checks that private implementation/state paths are denied before starting the verifier. It registers the worker every five minutes and starts its first bounded check. Subsequent checks, renewal and saved-operation retries are automatic; no diagnostic unlock or participant approval is a runtime prerequisite.

Its exact-write rollback covers changes made **by the activation transaction**. It cannot undo an earlier ZIP extraction or restore a pre-upload website it did not back up. A missing driver, private environment, cron facility, usable dispatcher or public route is a real installation failure, not something this package can truthfully label verified.

## Existing hosting requirements and layout conflicts

The domain still needs a supported Python web dispatcher (Passenger or the compatible LiteSpeed/CloudLinux setup), the existing application Python environment with its MySQL adapter, the existing protected production environment, and a working host `crontab`. PHP is required for the separate diagnostic page, not for the Python runtime itself.

The root layout is deliberate: the application and public website in this release are at the same root. If the existing hosting configuration explicitly points to a different application directory, activation stops with `existing_application_root_conflict` rather than silently abandoning that application's credentials or mutable state. A complete application ZIP does not safely relocate unknown live application state by itself.

Nonstandard protected-environment/interpreter paths can be supplied as server-local path arguments:

```sh
python3 concresca-repair/activate.py --python /existing/application/python --private-environment /existing/private/environment.json
```

These are paths on the host, not passwords. Do not replace them with invented paths, relax private-file permissions, or paste secret values into chat.

The archive's public files carry mode 0644 and directories 0755; private state and access codes are generated with owner-only permissions on the host. Per-directory guards protect source/deployment directories. The existing root access-control configuration must be retained during extraction; this is not a safe fresh-host installer for a document root with no access controls.

## Readiness must come from the runtime

The archive does **not** contain `status/current.json`, a passing verification receipt, or a static fake readiness response. The installer removes a recognized old placeholder already on the server. After activation, both routes must return actual runtime JSON:

```text
/api/concresca/readiness
/status/current.json
```

The runtime response is identified by `component: concresca-root-network`, not by an HTTP 200 alone. Completing all 22 required workflow observations, matching evidence bindings and a healthy automatic verifier is still required for `productionReady: true`. `/autonomyz` must return HTTP 200 only when that full autonomous-readiness condition holds. A route becoming available is not the same as all acceptance steps passing.

`/concresca-release.json` identifies these static release files only. It explicitly does not attest runtime availability, installation success, source provenance or acceptance.

## Locked diagnostics are included

Open `/concresca-diagnostics.php`. The page generates its code in `.concresca-diagnostics/access-code.txt` in the hosting account home, outside the website. Unlock with that file's code, run the fixed read-only checks, and download the redacted report. Never share the access code, private environment, raw logs or participant records.

The report recognizes this full-root release's installer/layout file fingerprints and installation revision. It remains read-only: no shell endpoint, installer button, database credential use, configuration editor or false verification override was added. A human opening diagnostics is not part of the service's autonomous acceptance process.

`/concresca-diagnostics-check.txt` is a separate non-secret static reachability check. The full diagnostic setup and security boundaries are in `concresca-repair/DIAGNOSTICS.md`.

## Validation and limits

See `concresca-repair/VALIDATION.json` and `concresca-repair/TEST-RESULTS.md` for tests executed against this consolidated candidate. The release is also extracted and tested again before delivery. Tests cover real application logic with isolated test transport, native local Apache access-control behavior, synthetic browser status cases, PHP diagnostic functions, file completeness, and layout selection.

These results do not establish native production MySQL, Passenger/LiteSpeed activation, provider-specific permissions, or successful live acceptance. No production deployment or production state mutation was performed in this session. The deployment is complete only when the host's own runtime and autonomous health checks actually pass.

## Reference configuration documentation

Official Passenger Apache configuration reference:
https://www.phusionpassenger.com/docs/references/config_reference/apache/

CloudLinux documentation of a missing Passenger module:
https://cloudlinux.zendesk.com/hc/en-us/articles/6930299800860-Python-NodeJS-application-shows-the-Invalid-command-PassengerAppRoot-error

These explain hosting prerequisites; they are not evidence of this host's actual settings.