Concresca FULL ROOT r6 — activation from the locked page

Report body

Concresca FULL ROOT r6 — activation from the locked page

Release: concresca-full-root-20260927-r6 · 27 September 2026

This is the complete flat-root application and website, based on the r5 release. It is not a partial overlay. It adds the missing way to execute host activation from the working PHP control page, without requiring a terminal command. It does not claim that the production host has already been activated or verified.

Why this release exists

The supplied production diagnostic report identified the r5 application files, HTTP 404 for the Python routes, the static status placeholder, no recognized local Passenger application-root or interpreter declarations, and no visible worker installation record. An external private environment was visible. These are observations, not proof of whether any earlier activation was attempted.

Uploading source files did not perform the separate activation operation. R6 adds an authenticated, explicitly labeled activation action to the existing locked diagnostics. The action executes the fixed packaged installer; it is not another change to status labels, and it is not an arbitrary command console.

Deploy the whole archive

Extract the ZIP directly into the EXISTING website document root that already contains passenger_wsgi.py, concresca_runtime/, assets/ and status/. There is no outer folder to move and no public/ tree to merge.

Do not empty the website first. Preserve the existing root .htaccess, database, Python environment, external private environment, runtime/ state and the account-home .concresca-diagnostics/ directory. Those host-specific resources are deliberately absent from the archive. Back up the existing site before replacing code. The archive is complete application content, not a replacement for account-level server configuration or existing credentials.

Open a fresh page at:

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

Its footer should end in root-r6. Unlock using the current code from the existing account-home file, outside the public website:

.concresca-diagnostics/access-code.txt

Never send the access code in chat or in a URL.

In the Activate installed release section:

1. Choose Check activation prerequisites. This checks without changing application configuration or contacting the production APIs/database.
2. If the check passes, tick the explicitly worded consent checkbox and choose Activate installed release. This starts the fixed host installer.
3. The page reads the saved job result automatically. After reopening the page, use Refresh activation result. Download activation result exports only the redacted result; it does not export logs, credentials or full paths.

The start action requires an unlock from the past five minutes. If it requests FRESH_UNLOCK_REQUIRED, lock and unlock again using the same current code. Normal service operation and the subsequent automatic verifier do not require this page to remain open, an unlock, or a human approval decision.

What runs

The PHP page accepts no command, interpreter path, private-environment path or arbitrary URL from HTTP. It checks the existing code/session/CSRF controls, explicit release-specific consent, a recent unlock and fixed backend source hashes. It invokes a fixed Python backend with an argument array, not a shell.

The backend checks the whole release manifest, safe account/document-root ownership, existing private configuration, an existing compatible Python/MySQL driver environment, and readability of the existing crontab. It examines exact account-local virtualenv/cPanel names or fixed existing system interpreters. It does not install dependencies, invent credentials, or scan other accounts. Conflicting configured paths or multiple compatible environments stop the operation instead of silently selecting one.

After successful preflight the existing bounded installer updates the managed routing block while preserving unrelated configuration, removes only the recognized static status placeholder, restarts the application using the existing mechanism, checks the actual canonical runtime responses and private route protection, and registers the five-minute verifier schedule. Routing readback failure enters the installer's compare-before-restore rollback path. The initial verifier run is bounded; later runs use the installed schedule.

The start request hands the job to a separate process with an owner-only lock. The saved result is outside the website at:

account-home/.concresca-diagnostics/activation-state.json

A duplicate start does not create a second concurrent job. Terminal results have a retry cooldown. Browser timeouts or expired diagnostic sessions do not cancel an already authorized job. If the host kills that process, a missing active lock turns an unfinished result into interrupted, not success. Hard process termination, server failure or concurrent deployment can prevent complete rollback; the result deliberately does not certify an unobserved rollback or claim the application remained unchanged in those cases.

Interpreting the result

preflight_passed only means the named prerequisites passed. No routing change has been made by that check.

started / running mean an activation job exists. The displayed phase is recorded progress, not a production readiness claim.

installed_verification_pending means the installer observed runtime routing and registered the verifier schedule. This is historical installation evidence, not current scheduler health or a claim that all 22 workflows have passed.

blocked / failed include a redacted reasonCode and, when available, phase. For example, host_process_execution_disabled means PHP cannot start the fixed backend under this host's restrictions. existing_python_ambiguous_no_changes means the account has more than one compatible candidate without one explicit application interpreter. host_cron_unavailable_no_files_changed means the required scheduler command is unavailable. Existing dependency or configuration problems are reported rather than bypassed.

interrupted means a previously unfinished job no longer holds its lock. Do not interpret it as successful installation or successful rollback. Refresh and download the result before retrying. Saved diagnostic observations and the installer's private backups can then support a targeted recovery.

If prerequisites block the browser action, attach Download activation result to the conversation. There is no need to disclose the access code. The CLI entry point remains available to an authorized deployment environment:

python concresca-repair/activate.py

That alternative still requires the existing application environment. The web route cannot bypass PHP process restrictions, account permissions, unavailable Python/driver software, cron restrictions or disabled server integration.

Completion criterion

Readiness must return real runtime JSON instead of 404; canonical status must not return the static pointer. Separately, the existing automatic verifier must produce fresh matching evidence for all 22 required steps, report healthy worker state, and make productionReady true and /autonomyz HTTP 200. This release does not alter those checks or include a pre-generated passing receipt.

Security and scope

GET requests, unlocking, diagnostic snapshot/probe actions and prerequisite checks do not invoke host installation. Only the separately authenticated and confirmed start action does. This is an intentional extension of the previous read-only page's authority, visibly distinguished in its UI.

Access-code expiry and rotation, session expiry, CSRF/origin checks, secure host-only cookies and redacted reports remain in place. Secrets and activation results remain owner-only outside the website. The implementation does not grant participant authority or create an approval queue for autonomous workflows.

The manifest detects incomplete/mixed distributed source. It is not a signature, proof of source provenance, dependency attestation or certification of all loaded code. Existing server-level settings, native LiteSpeed/Passenger behavior and production MySQL still require real host execution and observation.

Implementation references: PHP's proc_open documentation states that argv arrays execute without a shell on PHP 7.4 and later; LiteSpeed documents its cPanel Python application directives. These are implementation references, not proof of the production account's enabled capabilities.

• https://www.php.net/manual/en/function.proc-open.php
• https://docs.litespeedtech.com/lsws/cp/cpanel/cloudlinux/

See TEST-RESULTS.md for exactly which local tests ran and their limitations.