session-report · RPT-3525F3A1A69D

Concresca status incident: runtime fallback and acceptance maintenance

Host activation and status routing

Source identity

Record
RPT-3525F3A1A69D
Original file
Concresca-current-status-incident.md
Original SHA-256
0ec489966453c9c6fb4ab1b750691c8d477c9b30ae4982f83bdfc3ac1ddc4dc0
Source family
repair-conversation
Public copy SHA-256
0ec489966453c9c6fb4ab1b750691c8d477c9b30ae4982f83bdfc3ac1ddc4dc0
Original custody
Exact bytes retained in the private project package under docs/_evidence/; not a public download.

Read the public source-text copy

Disposition and proof of use

not_assigned_by_this_integration · preserved_and_indexed_not_new_substantive_acceptance

Memory owners: .uai/architecture.uai, .uai/operations.uai, .uai/test-plan.uai. These are private repository records, not public web routes.

Jump to a report section

Report body

Concresca status incident: runtime fallback and acceptance maintenance

Production is not repaired. No deployment or production mutation was performed.

Current observations

Fresh live fetches during this response returned the static status bridge at /status/. The canonical /status/current.json returned schema: concresca.status-current-pointer.v001 and status: FETCH_RUNTIME_STATUS, with a self-referencing canonical URL. Its own fallbackMeaning states that it contains no readiness snapshot. A second live fetch at the end of the investigation returned the same pointer.

Fresh live fetches of /api/concresca/readiness, /api/matm/commons/capabilities, and /healthz returned tool fetch errors saying the requested URL could not be found. The tool did not expose numeric HTTP status codes, so these observations are not represented as verified HTTP 404 responses.

An earlier retrieved readiness snapshot reported operational availability with productionReady: false and receipt_not_current. That earlier snapshot must not be treated as fresh proof of current availability after the conflicting live observations.

The observed behavior is consistent with static content shadowing or bypassing the Python/Passenger runtime. The exact host cause is not established: no authenticated host configuration, process inspection, or logs were available. Do not infer that the database failed, that all 22 workflows failed, or that a human approval is pending from this static pointer.

Reproduced source defects and changes

  1. assets/site.js accepted any successful JSON response as a runtime status object. Passing the supplied static pointer into that projection leaves runtime/storage/workflow fields absent, so the client renders default false values as NOT READY and NOT VERIFIED. The patched client rejects the pointer, including the old pointer that misleadingly says runtimeGenerated: true. It also rejects malformed or incomplete runtime documents.
  2. The old workflow projection required activationReceipts.dogfood.summary.liveEvidence, which is not part of the current acceptance summary returned by the earlier readiness response. The new client uses current autonomousAcceptance evidence and required gates. All 22 requirements remain mandatory, including independent-agent evidence and distinct-process restart/readback. An expired receipt cannot stay green, even while a network refresh is in flight. Valid individual restart evidence remains separately visible when another workflow fails.
  3. The old runtime-identity card conflated source/package provenance flags with installed-file observation. The patched status card explicitly reports the current installed-file fingerprint and application-load baseline. The separate provenance/identity display stays NOT ATTESTED when its original flags are false; the patch never changes those flags or claims source provenance.
  4. The static pointer and both builders now label the pointer runtimeGenerated: false, staticFallback: true. Generated static content cannot label itself live evidence.
  5. Status reads are bounded to two fixed same-origin endpoints. The client rejects redirects, sends no credentials, limits responses to 256 KiB, times out each request after eight seconds, and uses no-store caching. It automatically retries status reads and expires displayed evidence. Browser polling is not an acceptance worker or a host repair.

Validation

187 local tests passed: 75 JavaScript contract/transport/display tests, 23 receipt tests, 22 autonomy-health tests, 20 root application integration tests, 39 publisher tests, four static-fallback tests, and four host-public-routing guard tests. JavaScript syntax validation and the current-status surface check also passed.

All browser payloads were synthetic fixtures. No test contacted production, enrolled agents, restarted Passenger, renewed an acceptance receipt, or established unattended live operation. Detailed commands and logs accompany the patch.

Deployment boundary

The earlier full-project ZIP is a source archive, not a drop-in installation for the live document root. Its repository .htaccess contains public-path guards but not the host-specific Passenger application root, interpreter, restart-directory, or private-environment settings generated by the deployment tooling. Replacing a host configuration with that generic file can discard required runtime configuration. Whether that replacement actually happened on this host is unconfirmed.

The source patch changes eight source/test files. The separate asset overlay contains only the three public assets under the existing app-root package layout (public/...). It deliberately contains no .htaccess, Passenger entry point, credential, database file, runtime receipt, or restart trigger. Neither artifact restores host routing. Neither should be treated as a complete site installer.

The authenticated deployment connection for the existing host was not available through the connected tools. The existing deployment helper refers to a machine-local credential file outside the supplied archive. Plugin discovery did not produce an installed connection to that host. No secrets should be pasted into public reports or bundled in deployment assets.

Machine-owned work still required

The deployment controller must restore and verify canonical runtime dispatch using the host's actual protected configuration, preserving private source/data boundaries and rollback. It must read a real current readiness document from both /status/current.json and /api/concresca/readiness; a successful HTTP response containing the static pointer is a failed dispatch check.

Then the actual autonomous acceptance suite must run, preserve recovery state and idempotent intents, publish correctly bound current evidence, and keep it renewed before expiration and after relevant deployments. The full recurring verification/renewal worker is not implemented by this patch. None of these requirements should turn into a human product-approval queue. No missing requirement is forced to PASS.

Completion remains: live runtime restored, real current acceptance verified, and unattended renewal/recovery observed.

Sources