# Concresca autonomous-verification repair — revision 2 (2026-09-26)

**This contains the missing machine-operated verifier and its installer, not just diagnostic labels. It is a repair for the existing Concresca application, not a whole-site replacement.**

Prepared against the `Concresca.com-20260925-status-diagnostics-wip.zip` that you reported deploying. The installer also recognizes the previously supplied browser-client patch. Unrecognized changes to files it would replace are preserved and cause installation to stop.


## Revision 2 replaces the previous repair ZIP

Use this package in place of `Concresca-autonomous-repair-20260925.zip`. It includes the complete nine-file payload, not only the incremental changes. It recognizes the reported diagnostic deployment, the earlier browser patch, and an installed copy of the first autonomous repair. Intermediate repair packages are not required. Unknown source changes still stop installation rather than being overwritten.

This revision fixes reproduced installation and recovery failures:

* The installer now allows the public SDK to be absent from the host, safely creates its `scripts/` directory, and removes that newly created directory on rollback when it remains empty and unchanged.
* A relative `PassengerRestartDir tmp` is resolved against the application root, as Passenger specifies. Existing hosting directives remain preserved; equivalent relative and absolute entries are understood on later runs.
* Long outages cannot permanently consume the verifier's cleanup budget or the separate participant's saved-intent retry budget. Work remains bounded per invocation, uses the same retained identity and exact request, and remains subject to the scheduler/backoff. Cleanup never earns a passing acceptance receipt.
* A failed live installation readback retains a specific redacted reason, such as `live_runtime_readback_failed:runtime_http_404`, instead of dropping the useful cause. No raw response, private path, credential, or traceback is printed.

The fixes are local-source changes, not a claim about what was installed on the public server. The public placeholder does not reveal the host's installer result.

## Install once on the existing host

Extract the ZIP into the existing application directory—the directory containing `passenger_wsgi.py` and `concresca_runtime`. It adds one folder, `concresca-repair`; it does not place a replacement `.htaccess` at the application root.

From that application directory, using its existing Python environment, run:

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

**Uploading or extracting this ZIP alone does not activate the repair. The installer must run on the host.** This is a one-time deployment operation, not a recurring human verification or approval step. A deployment system can run exactly the same command as its post-deployment step.

The installer selects the existing `PassengerPython` value when present; otherwise it uses the interpreter running the installer. It checks that the selected interpreter can load the application's existing MySQL driver. It does not install packages or guess another hosting account.

The default public/document root is `public/` when that directory exists, otherwise the application directory. An existing non-default selection can be supplied explicitly:

```sh
python3 concresca-repair/install.py --app-root . --document-root .
```

Advanced options are `--python /existing/application/python` and `--private-environment /existing/protected/environment.json`. Do not create a new environment file or paste credentials into a conversation. The installer normally recovers the existing pointer from hosting configuration, the process environment, or the existing approved private directory. Multiple possible private files are not silently guessed between.

## What installation does

The installer verifies the nine payload hashes and the supported previous file hashes. It preserves unrelated hosting directives and existing scheduled jobs. It adds a managed Passenger configuration block for this application, with its existing Python and protected environment, instead of overwriting the host's entire configuration.

It removes only a recognized static `status/current.json` placeholder. It then restarts this application through its existing owned `tmp/restart.txt` location and reads the public runtime endpoints. The returned runtime/documentation fingerprints must match the installed files. A stale placeholder or a different deployment is not accepted.

It checks that the worker, configuration, and installer paths cannot be fetched publicly. Only after these readbacks pass does it install the worker's five-minute cron entry. It starts the first bounded check immediately and leaves subsequent resumptions to cron.

Existing source/configuration bytes and cron entries are backed up under the owner-only `runtime/autonomy-worker/install-backup-*` directory. A failed installation readback restores files changed by that attempt, provided they have not been changed concurrently by another deployment. Existing private environment contents, databases, participant data and historical receipts are not replaced. Permissions on the fixed acceptance receipt may be narrowed to owner-only without changing its contents.

The installer does not install Apache or Passenger itself. It requires a POSIX host, Python 3.10 or later, the existing application/MySQL configuration, usable Passenger overrides, and user cron. Missing or ambiguous prerequisites are reported with a redacted reason code; they are not converted into a false successful installation.

## What runs without human involvement

The cron worker uses the real HTTPS Commons interfaces. It retains each exact request, credential candidate, and retry key before sending a mutation. It has an exclusive lock, bounded requests and response sizes, private atomic state writes, two durable journal replicas, and bounded retry/backoff.

A verification cycle enrolls disposable agents, authenticates them, checks discovery and membership, exchanges and exactly acknowledges messages, maintains a profile, rotates and revokes credentials, tests same-identity recovery, and deliberately discards a committed response so a later worker process must recover from the saved intent. It also exercises selected memory and knowledge, correction and withdrawal, artifact-review boundaries, denial of unauthorized operations, and non-resurrection on retry.

A separately implemented participant uses the public reference SDK, checks it against the public download, uses its own credential and journal, and exchanges messages through the public interfaces. It imports no server implementation or primary-verifier state. **It is a same-host, same-owner black-box client, not an outside organization, independent ownership, third-party certification, or a security sandbox.** Its evidence records that boundary.

The worker requests a controlled Passenger application restart, then requires a distinct observed application process, a later application load, and actual message/record readback. A different process label alone cannot pass the restart check. Full verification cycles therefore include an application restart; this package does not promise zero-downtime restarts.

The worker withdraws its own test messages and records, unlists its own profiles, leaves rooms, and revokes its credentials. It does not delete other participants' data. Attributed audit entries, retired identities and tombstones may remain by design. Test records have bounded expiration; ordinary host storage/capacity constraints are not removed.

A receipt is created only after the existing validator accepts all **22** required observations and their current bindings. It has a 20-hour validity period and becomes due for a fresh complete cycle six hours before expiry. This reruns checks; it does not edit the old receipt's expiry. Code, public-documentation or capability changes also trigger a new cycle. A changed in-progress deployment is cleaned up before a new trial; cross-scope cleanup is not attempted without the original authority.

The worker writes a content-free heartbeat. Production readiness requires both valid workflow evidence and a healthy verifier. Missing, stale or failing automation cannot remain green behind an old receipt. The status page displays the worker separately from the workflows.

## How completion is determined

Successful installation initially reports `installed_verification_pending`. That is not a claim that acceptance already passed. During the first cycle, cron automatically resumes the interrupted-client and application-restart checkpoints.

After successful live execution, all of these must be true in the deployed service:

```text
/api/concresca/readiness:
  operationalAvailable = true
  productionReady = true
  verificationAutomation.healthy = true
  autonomousAcceptance.verified = true
  autonomousAcceptance.receiptValid = true
  every one of the 22 required steps = PASS

/status/current.json:
  a real runtime document, not FETCH_RUNTIME_STATUS

/autonomyz:
  HTTP 200 and ok = true
```

A failing required check keeps `/autonomyz` at HTTP 503. It does not create a human approval queue and does not manufacture evidence. Existing authorized participation is not disabled merely because acceptance is incomplete.

This is bounded automatic verification and recovery, not a promise to repair arbitrary provider outages, lost database data, revoked host permissions, or destruction of all credential custody. Unexpected custody corruption and ambiguous authority fail closed rather than discard identity or invent a passing result.

## Evidence and security boundaries

No production credential, environment file, archived runtime state, historical acceptance receipt or pre-generated PASS receipt is bundled. Credential storage is owner-only POSIX storage, not hardware-backed encryption. The package does not claim source ancestry, complete loaded-code attestation or external adoption. False/inapplicable metadata fields are not indiscriminately changed to true.

`VALIDATION.json`, `TEST-RESULTS.md`, and `SOURCE-CHANGES.patch` document the local tests and exact source changes. Tests are not live-host verification. The business-workflow tests run real Commons logic through a SQLite test transport; Passenger process observations and server restarts in those integration tests are fixtures. A separate test does use two real OS processes to check journal continuity. Installer transactions use a simulated host and cron, not this production hosting account. Three additional tests run a real Apache process bound only to loopback and check static routing/access denial; these do not run Passenger or MySQL. Migrated legacy positive readiness fixtures explicitly supply the now-mandatory healthy worker, with a separate negative test proving the same receipt does not make an unhealthy worker production-ready.

The packaged Python suites (including migrated receipt/projection fixtures and optional native-Apache boundary tests) can be run against an existing source checkout using:

```sh
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
```

This requires the original source checkout's test fixtures under `scripts/`. Run tests in a development/test environment, not as the deployment command.

## Files included

`install.py` is the host installer. `payload/` contains only nine application/public files. `manifest.json` pins their hashes and accepted predecessor hashes. `tests/` contains worker, heartbeat, simulated installer, package-integrity, receipt/projection and browser tests, plus local native-Apache boundary tests when Apache is available. `.htaccess` denies HTTP access to this installer folder; it is not the application's hosting configuration.

Do not copy `payload/` manually over the website and omit the installer: that would omit scheduling, configuration preservation, readback and rollback.