# Concresca: post-restart live check

Recorded: 2026-09-28T20:07:32Z. Live requests were made during the approximate window
2026-09-28T20:03:00Z to 2026-09-28T20:07:32Z.

## Result

The restart is followed by a responding Python runtime, not the earlier across-the-board
404 condition. The application reports it loaded on September 28, 2026 at 20:02:18 UTC
(15:02:18 America/Chicago). It reports `operationalAvailable: true`, a connected MySQL
backend and verified schema. All 22 named operational gates are true.

Full autonomous operation is **not** ready: `productionReady: false`,
`verificationAutomation.reasonCode: worker_not_observed`, `heartbeatAt: null`,
`receiptValid: false`, and all 22 required acceptance workflows remain without current
passing evidence. This does not show that each underlying operation fails; it shows the
required evidence is missing. No human approval gate is reported.

## Public responses

| Endpoint | Live observation |
| --- | --- |
| `/api/concresca/readiness` | Real runtime JSON; operationally available, not production-ready. Repeated with a unique query. |
| `/healthz` | JSON reports `ok: true`, `status: healthy`. |
| `/readyz` | Runtime readiness JSON returned; extracted copy was truncated, not a raw transport capture. |
| `/api/matm/commons/capabilities` | JSON reports available production MySQL service and an empty blockers list. |
| `/status/` | Renders the current runtime checks and a degraded/automatic-verifier-unavailable message. |
| `/status/current.json` | Still returns `FETCH_RUNTIME_STATUS`, not runtime readiness. Same result with a unique query. |
| `/autonomyz` | Fetching tool returned an error without a numeric HTTP status or body; direct endpoint result unresolved. The readiness document itself reports autonomy health false. |
| Diagnostic ping | R8; PHP executing and private code ready. |
| Release marker | R8; this identifies the marker, not every installed file. |
| `/assets/site.js` | Tool reached the resource but could not extract it. Live source hash and browser execution were not checked. |

## Remaining repair target

The Python service is now reachable. The remaining deployment work is to make the
canonical status JSON route reach that runtime and to establish the scheduled verifier
and its valid heartbeat/acceptance evidence. A Python restart alone does not demonstrate
completion of those steps. The public response does not distinguish a missing worker
from unreadable/invalid worker-state files; the activation result is needed to resolve
that narrower question.

The existing r8 instructions say the authenticated activation operation configures routing
and verification; **Refresh activation result** reads an already-started job without
starting another. No new package or server change was made by this check.

## Evidence and limitations

The companion JSON contains selected fields from explicit live Keenable fetches. It is
not a raw HTTP capture. The extraction service did not expose raw response headers or
numeric HTTP statuses, so successful HTTP 200 codes are not invented. One general
retrieval tool continued to return failures/older HTML; those were not used to override
the explicit live bodies with the fresh process timestamp. The local container's DNS
failure was also excluded as an origin-health verdict.

No authentication, enrollment, message exchange, credential changes, real restart/readback
test, or other state-changing workflow was exercised. No browser session was executed.
The status content was extracted live from the page. Private cron configuration, effective
hosting configuration and the saved r8 activation result were not inspected.

The separate restart-readback acceptance gate remains unverified: observing a process
load timestamp is not a before/after persistence test.