Concresca host-activation repair — revision 3

Report body

Concresca host-activation repair — revision 3

Prepared September 27, 2026. This replaces the revision-2 installer. It is a targeted repair package, not a replacement website archive. Live installation and autonomous acceptance remain unverified here.

Apply to the existing application

Extract the ZIP into the existing application directory containing passenger_wsgi.py and concresca_runtime. It adds/replaces the concresca-repair/ directory, not a top-level .htaccess. Use the existing application's Python environment on the host:

python3 concresca-repair/install.py --app-root .

The installer executes once, then installs the existing verifier's five-minute schedule and starts its first bounded execution. Extraction alone does not execute that installation. This is a deployment operation, not a recurring human verification or approval requirement. A deployment pipeline can execute the same command.

The supported predecessor hashes include the diagnostic ZIP reported deployed, the earlier browser correction, and the first and second autonomous-repair payloads. Intermediate versions are not required. Unexpected local modifications are preserved and stop installation; do not use a force-overwrite workaround.

Do not replace the database, private environment file, hosting account, or the site's whole .htaccess. The installer preserves unrelated hosting directives and scheduled jobs. No production credentials, archived runtime custody, or pre-generated acceptance receipt are bundled.

What was repaired in this revision

Public-file permissions

The previous CLI sets umask 0077. Its atomic writer asked for public mode 0644 but never applied it after that mask, leaving public assets and hosting configuration at 0600. The unmodified revision-2 writer reproduced HTTP 403 for a public fixture under a real Apache process. Revision 3 sets the requested file mode explicitly on the open file before atomic replacement. Public content/configuration remains readable; private state remains 0700/0600. Rollback also restores recorded modes when file bytes did not change.

This is a reproduced package defect, not proof of the current production files' permissions or the sole cause of the outage.

Application directory versus website document root

The installer no longer treats the mere existence of public/ as proof of the website's document root. It reads exact existing PassengerAppRoot bindings from owned candidate directories. It can use a parent document root with the application nested underneath, and it checks both internal public assets and existing direct public copies that could otherwise hide the update. Unknown copies are not overwritten.

An explicit or uniquely bound root is verified inside the reversible installation, after replacement of unreadable hosting configuration. A temporary nonsecret random text file must be returned byte-for-byte by the canonical HTTPS origin; its exact unchanged file is removed afterward. Ambiguous layouts must be resolved rather than guessed. The runtime then must return matching installed-code/documentation fingerprints; a static placeholder is never accepted.

Supported optional selections, only when the existing host requires them:

python3 concresca-repair/install.py --app-root /existing/application --document-root /existing/website-root

Existing PassengerPython is used when present. Otherwise the invoking interpreter is selected. The advanced --python and --private-environment options accept existing host paths, not new credentials. The installer searches the supported protected environment locations relative to both application and document root and rejects ambiguity or secrets inside either public boundary.

Apache Passenger and LiteSpeed restart behavior

The generated hosting block keeps Apache Passenger configuration and adds an independent LiteSpeed block using its documented Python application directives. Apache can use the configured restart directory; LiteSpeed documents tmp/restart.txt beneath the application root. When those are different, installation and the verifier touch both fixed, owned, empty restart signals. These nonsecret signals are made traversable/readable for the dispatcher while their HTTP paths stay denied.

Touching either or both signals is NOT passing evidence. The worker still requires a different application instance, a later application load, and real message and record readback before passing restart verification. Native LiteSpeed/Passenger execution has not been tested here. Controlled application restarts are part of full verification; zero downtime is not promised.

Deployment result, not silent success

The installer reports a redacted phase and reasonCode on failure. Useful phases include host_layout, host_prerequisites, source_preflight, installation_transaction, document_root_readback, live_runtime_readback, and scheduler_installation.

An installed result looks like:

{"status":"installed_verification_pending","packageRevision":"r3","routingVerified":true,"documentRootConfirmed":true,"schedulerInstalled":true,"autonomousAcceptanceVerified":false}

That means routing and scheduling were observed, not that the complete verification cycle already passed. A failure result has installed:false; its reason is not a request for human product approval. Share only the redacted JSON result when diagnosing a failed deployment, not environment files, credentials, account paths, or raw server logs.

Transaction and security boundaries

The installer checks payload/predecessor hashes, owner/no-link boundaries and the existing MySQL driver. It takes the worker lock, creates protected backups, updates exact supported files, removes only recognized static status pointers, installs the hosting block, verifies the actual document root, requests restart, and checks public runtime and private-path boundaries before installing cron.

Caught installation failures attempt exact-content/mode rollback without overwriting detected concurrent changes. This is not a crash-atomic whole-site release: termination/power loss during installation can leave a partial attempt, and a concurrent-change conflict intentionally prevents blind rollback. Backups remain in owner-only worker custody. Existing private custody permissions may be narrowed; empty restart directories/signals can remain with dispatcher-readable permissions after rollback. Participant data and database contents are not rolled back or replaced.

No arbitrary remote shell, unauthenticated web installer, broad permission reset, provider switch, or fabricated ready response is added. The existing host must already provide compatible Python application dispatch, the configured database driver/environment, and user cron. Unsupported hosting prerequisites stop installation with a safe result rather than claim success.

What remains automatic after successful installation

The included verifier retains exact requests and credentials before mutations, resumes interruptions from private journals, checks real workflows, cleans up its own disposable resources, and reruns before receipt expiry or after relevant deployment changes. Per-invocation retry limits and scheduled backoff avoid a permanently consumed cleanup budget. The separate public-documentation client has its own credential and saved intent but remains on the same host and under the same owner, not a third-party certification.

All 22 required observations remain mandatory. A fresh successful cycle produces new evidence; the worker does not extend dates on an old receipt. Readiness also requires a healthy verifier heartbeat. Missing, failed, expired, or mismatched evidence stays incomplete. Arbitrary provider outages, destroyed databases, or loss of all credential custody are not automatically solvable by this worker.

Live completion criteria

The public website must actually return a runtime status document, not FETCH_RUNTIME_STATUS. The readiness response must show productionReady: true, verificationAutomation.healthy: true, a current valid autonomous acceptance receipt, and PASS for all 22 required steps. /autonomyz must return HTTP 200 with ok: true. Installation alone and local tests cannot satisfy these criteria.

Validation

224 Python tests, 78 synthetic browser assertions, and one source-surface check passed in this session. Seven of the Python tests use a real loopback Apache process; application/cron deployment remains simulated and the business-workflow database transport is SQLite. Native MySQL, native Passenger, native LiteSpeed, and live automatic renewal have not been verified here. TEST-RESULTS.md, VALIDATION.json, and test-logs/ contain the scope and actual output.

Run packaged tests in an isolated source checkout, with the candidate payload applied, not as a production installation command:

CONCRESCA_TEST_SOURCE="$PWD" python3 -B -m unittest discover -s concresca-repair/tests -v
CONCRESCA_TEST_SOURCE="$PWD" node --test concresca-repair/tests/test_status_client.cjs

The original source's scripts/ fixtures and public documentation are required. INSTALLER-R3.patch records installer changes from r2. SOURCE-CHANGES.patch records the nine payload differences relative to the diagnostic source.

Primary hosting references

LiteSpeed CloudLinux application directives and app-root restart behavior: https://docs.litespeedtech.com/lsws/cp/cpanel/cloudlinux/

Passenger application root and restart-directory configuration: https://www.phusionpassenger.com/docs/references/config_reference/apache/

These describe supported hosting behavior; they do not establish the configuration currently running on concresca.com.