Concresca FULL ROOT r8 — bounded permission repair before host activation

Report body

Concresca FULL ROOT r8 — bounded permission repair before host activation

Release: concresca-full-root-20260927-r8.

This is the complete flat-root website and application, not an overlay. No intermediate repair ZIP is required. R8 addresses the reported r7 activation failure source_preflight: writable_host_ancestor. It does not claim that the live Python routes, production database, or autonomous workflows are working.

Deploy this complete release

Extract the entire archive into the EXISTING website document root containing passenger_wsgi.py, concresca_runtime/, assets/, and status/. There is no outer folder and no separate public/ tree to merge. Do not empty the directory. Preserve the existing root .htaccess, external private environment, Python installation/virtual environment, database, runtime/ state, and account-home .concresca-diagnostics/. Those host-specific resources are not shipped. Maintain an existing host backup before replacing application code.

Open a fresh https://concresca.com/concresca-diagnostics.php page. The footer must end in root-r8. Unlock with the current server-generated code from account-home/.concresca-diagnostics/access-code.txt. Never share that code.

Select Check activation prerequisites. Two actionable results are possible:

• preflight_passed: the observed host prerequisites passed.
• permission_repair_required: release bytes match, but owner-controlled source paths need permission tightening. This check has changed nothing. Python environment and scheduler checks are explicitly deferred until the unsafe source permissions have been repaired; they are NOT claimed to pass.

For either actionable result, tick the checkbox describing the permission and hosting changes, then select Activate installed release. The write action first performs any planned owner-only tightening, re-verifies the full release, then checks the remaining host prerequisites and invokes the existing routing and automatic-verifier installer. No terminal command is needed for this path. A blocked result is not actionable and exports a fixed reason code.

Uploading files alone still does not run activation. The diagnostic page must remain locked to unauthorized visitors, but scheduled service verification does not require it to stay open or unlocked. This is a deployment action, not a human approval gate in ordinary agent operation.

Exactly what the permission repair changes

R7 checked the complete release's bytes, but did not audit its nested directory permissions during the browser prerequisite check. The strict installer then rejected a writable parent path later in source_preflight. An unchanged r7 installer reproduces the same error with an account-owned payload directory at 0775, and accepts the same bytes once that directory is 0755. This is a local reproduction, not identification of the exact directory on your host.

R8 keeps that strict rejection rule. Instead, after explicit activation consent it removes ONLY group-write and other-write bits from repairable account-owned paths: new_mode = old_mode & ~0022. Examples are 0775 -> 0755, 0777 -> 0755, and 0666 -> 0644. It never grants missing read, write, or execute permissions. Already-restrictive files remain restrictive. Directory setgid bits are kept.

The bounded inventory covers manifest-listed release files and their parents, the root .htaccess, a recognized legacy static status pointer, and these existing directories only: runtime, runtime/autonomy-worker, and tmp. It does not recursively scan private records, virtual environments, unrelated applications, databases, or the account home. It never changes ownership. Private environment values, diagnostic codes, runtime receipts and participant content are neither read by this permission stage nor replaced by it.

The full release must pass byte verification before planning. A second digest check binds the plan's files; descriptor-relative O_NOFOLLOW walks reject symlinks, hardlinked files, replaced paths, and changed modes/identities. All plan entries are checked before the first change. Each chmod targets an opened descriptor, rechecks ownership and identity, and verifies its result. Release bytes are re-verified before application imports continue. The hash manifest checks consistency, not cryptographic source provenance.

An unsafe account/application anchor, host-owned/shared path, unowned writable object, symlink, unknown source, or denied chmod is NOT bypassed. A fixed error identifies the blocked scope without exposing account paths. Such a host-level block can require hosting-provider intervention; this package cannot grant itself privileges. Existing explicit permission and authentication boundaries remain in force.

Mode-bit tightening is retained if a later activation step fails. Reintroducing unsafe write access during routing rollback would recreate the blocker. The later routing transaction retains its existing byte/configuration/cron rollback behavior, subject to concurrent-change protections. The exported job result distinguishes permissionChangesMayHaveOccurred from routingChangesMayHaveOccurred and includes bounded counts and mode samples. It does not imply database writes or source-byte changes merely because a permission was tightened. An interrupted operation is reported conservatively.

This is POSIX mode-bit handling, not a whole-host ACL, loaded-code, or isolation attestation. The PHP page and pinned activation bootstrap still require their existing safe outer directory chain; R8 does not automatically chmod account homes, system directories, or an unsafe activation bootstrap into trust.

Read the actual result

The job saves progress outside the public document root and runs separately from the browser. Use Refresh activation result after reopening/unlocking the page; do not start a duplicate job after a lost response.

Download activation result exports the current error/job observation. A permission report shows counts, fixed categories such as installer_payload and runtime_code, original/target mode bits, and completed tightening counts. It contains no host paths, raw commands, environment values, access codes, session identifiers, participant data, or raw server responses.

A permission_repair_required check is NOT readiness. An installed_verification_pending result means the installer observed runtime routing and registered scheduling; it is NOT completed autonomous acceptance. The existing 22 workflow gates, evidence freshness/binding, and verifier health requirements remain unchanged. The live completion criteria remain real JSON from /api/concresca/readiness, productionReady: true, current passing evidence for every required workflow, a healthy automatic verifier, and HTTP 200 from /autonomyz. No passing receipt is distributed or manufactured.

Optional host command

Using the EXISTING application Python environment, from the document root:

python concresca-repair/activate.py

This default command authorizes the same bounded permission tightening before installation. python concresca-repair/activate.py --check-only inventories and verifies without changing application bytes, modes, routing, or scheduling. The lower-level installer continues to enforce strict safe-path checks.

Packaging and validation boundary

The ZIP contains explicit directory entries requesting 0755 and file entries requesting 0644. Extractors differ in their handling of existing directory permissions; the permission preflight, not the ZIP metadata, verifies the host.

See TEST-RESULTS.md for actual local checks and their limitations. No production activation or authenticated server modification was performed in this session.