jobtrackingapp/docs/redesign/phase-9/p9-sec-02/CI_ASSESSMENT.md

P9-SEC-02 hosted CI assessment — 25 October 2026

Repository quarantine checkpoint

After the read-only assessment below, the primary agent changed only .gitea/workflows/mariadb-integration.yml: removed automatic pull-request preparation, selected the unique jobtracker-mariadb-isolated label and added the current qualification branch to push coverage. The unconditional first-step exit1, database guards, image pin and existing test architecture remain. No runner host, registration, privilege, socket, service, backup or deployment workflow changed. Four new workflow invariant tests failed3/passed1 before the change and pass4/4 afterward; the existing five mocked runner tests also pass. The unique label is a routing prerequisite, not proof of a safe matching host. Hosted CI remains BLOCKED and current isolation UNVERIFIED pending operator/runtime evidence. The source hashes below describe the earlier read-only snapshot, not a claim that the workflow was unmodified afterward.

Hosted MariaDB: BLOCKED. Current runner isolation: UNVERIFIED. Current effective HostConfig is unknown. Historical run853 was unsafe for this database lane; that observation does not certify today's configuration. No hosted MariaDB test or private-service lifecycle was executed by this assessment.

Baseline f17dba2ec06ea8f53c2785eaaebd25abc515ebf8, branch fix/p9-model-cache-and-ci-qualification. Fresh metadata observation 2026-10-25T06:23:27.915835Z / 07:23:27 CET Europe/Paris. The user authorized bounded read-only CI/API and official-source investigation. Existing Git credentials were used only in memory with redirects refused; no helper output, Authorization header or credential values were retained. Repository permission is not host permission.

Fresh metadata and boundaries

Observation	Result	Meaning
Version/repository	HTTP200; Gitea1.26.0; admin/push/pull reported	Readable repository metadata; no infrastructure authority established
Repository runners	HTTP200; runner3 pi-runner-1, offline, non-ephemeral, ubuntu-latest/ubuntu-22.04	Not the actual runner5
Instance runners and user	Both HTTP403	Runner5 configuration, registration scope and host remain inaccessible
Latest runs	Requested100; returned50	Bounded window, not exhaustive history
New visible runs	855/854, main 5f835e54a9b74e6b71418422e28431b2af06453f, success	Job metadata names backup, runner5 Live-Runner; these are not MariaDB tests
Backup job times	Job1745 01:00:47–01:01:04UTC; job1744 00:01:21–00:01:38UTC,25October	Recent runner activity, not proof of its host boundary or production state
Current task branch	Branch query returns0; none in latest50	No accessible branch execution in the inspected window; filter support/exhaustive absence not certified
Latest visible MariaDB run	Historical853/job1743 at3727a72, failure	Isolation guard failure before database execution, as established previously

Only metadata for these jobs was requested. Backup logs, secret endpoints, production hosts, daemon endpoints and runner host files were not accessed. Source workflow backup/deployment/maintenance jobs reference production SSH credentials and share ubuntu-latest with the blocked MariaDB workflow. Metadata now verifies that actual runner5 executes backup jobs. It does not establish host co-location, secret values or scopes, or job-to-job credential availability.

Historical runtime versus current unknown

The previous isolation report inspected24October run853: runner-reported v0.4.1, job image node:20-bookworm, merged NetworkMode:host and /var/run/docker.sock bind, Privileged:false, persistent tool cache. The guard exited1 before checkout/SDK/database work. Log SHA256 448df52f9c9cf3c156b5f742dbef6e3745844b25f968d4e9138c142437837134 identifies that historical evidence. The earlier metadata refresh also did not inspect current HostConfig.

This investigation downloaded no runtime logs and performed no live HostConfig inspection. Therefore historical exposure is UNSAFE for the intended lane, while today's isolation verdict is UNVERIFIED, rather than an assertion that current configuration is unchanged. No private-service success/failure/cancel/crash cleanup or cross-job leakage proof exists.

Source capability and preserved repository guards

Fresh immutable upstream retrieval returned HTTP200 and matched all three previous source hashes:

Primary source	SHA256	Relevant capability
Runner configuration at9aafec169b7ebf3d71df2b06780868fb552b435e	e47d046dc368eb85b35665b4a5dba57ce0be4053c665ff737916a7561f7337fa	Lines86–115: automatic network, independent privilege/volume/options controls, docker_host: "-" to suppress socket mounting
Runner execution	857b163f42aeb350aa32fbdc884e8d2ceb738d77e8a25504ac38c3e0035ab590	Lines220–248 pass secrets and container settings, disable reuse and request automatic removal
act v0.261.10 engine	45aea88466bc40c1cddad7ee6cfe98444ffd225a719683ee319c909075466c2c	Lines116–121/309–401: generated network for services unless configured network overrides it, service DNS aliases, declared port bindings, normal cleanup attempts

The versioned Gitea documentation request returned403; no refreshed documentation contents are claimed. Pinned source proves supported capability, not installed binary identity, effective configuration, crash recovery or production egress separation. Services and runner-owned preparation precede workflow steps; an in-job guard cannot remove that exposure.

Repository source review preserves the unconditional first-step exit1, existing branch filters, explicit failure rather than SQLite fallback, loopback TCP validation, generated schema ownership and cleanup failure propagation. The current task branch has no push trigger. Broad pull-request and manual triggers remain. Five existing Python guard tests passed with mocked subprocesses; their injected cleanup17/setup1 outputs are expected fixtures. Seven bounded source assertions passed. Neither check is a hosted or database test. Exact source hashes for eight relevant workflow/runner/fixture/Compose files are in ci-assessment.json.

Repository improvement proposal only: consider removing the broad pull_request trigger while isolation is unverified, because the first failing step still allows runner preparation. This prevents an automatic event from preparing the known shared routing lane; manual triggering must remain operator-controlled. Review Gitea event behavior and dedicated routing before restoring it. No workflow or transport change was made here. A step-level bypass, adding Docker CLI, arbitrary remote endpoint exception, or routing to ubuntu-latest cannot safely close this gate.

Exact operator checklist before enabling execution

1. On a new dedicated nonproduction host/VM and daemon, provide sanitized ownership, OS/image identity, runner binary version/hash and registration scope. Do not reconfigure Live-Runner under this task. Prove production workloads, data, secrets and management endpoints are absent and unreachable. Register a unique label such as jobtracker-mariadb-isolated; validate and pin the job image digest.
2. Generate configuration for the chosen exact binary. For the reviewed source capability, use empty container.network, container.docker_host: "-", privileged:false, valid_volumes:[], and no options reintroducing mounts, devices, host networking or privilege. Start capacity1; disable shared cache until qualified; use disposable per-job state. Only the controller manages its dedicated daemon; jobs/services receive no daemon endpoint/socket or registration/config credentials.
3. Prove effective merged job/service HostConfig, mounts, capabilities, network attachments, port bindings and resource limits. Establish explicit host firewall/egress and cross-job separation; a private Docker network alone does not deny production/LAN access. Review fork/PR trust, token permissions and secret scope without printing secrets. No production credentials may reach this lane.
4. Qualify native service mariadb, exact mariadb:12.2.2@sha256:42a27baaba3e8f3f0159d16381d5a7156661aa91dcc65f663cabb6a6f9503c00, linux/amd64, development-only credentials and disposable storage. Declare no published ports or persistent DB volumes. Require bounded image health/authenticated readiness and exact version checks; prove job DNS mariadb:3306 and generated schema ownership.
5. After infrastructure evidence, review workflow and fixture transport together: unique label, native service, preserved default loopback guard, strict CI-only service name mariadb and TCP3306. No arbitrary remote endpoint/self-attested isolation bypass. Retain startup migrations, independent persisted-state assertions, sanitized useful logs, native TRX, current exact test discovery and zero hidden retries/skips. Do not substitute historic test totals.
6. Execute success, deliberate test failure, cancellation and interrupted-runner recovery. Retain job-scoped before/after resource inventories proving service/container/network/schema/data removal, no stale credentials/cache and no cross-job access. Document targeted orphan reclamation after daemon/runner failure without broad prune operations or production effects. Then execute and publish the actual hosted MariaDB lane at its exact source/image identities.

Hosted PASS requires real MariaDB test execution and verified isolation/lifecycle evidence. Current owner action is infrastructure proof followed by reviewed repository enabling changes and actual execution. API success, backup success, labels, source examples, mocked guards and local MariaDB qualification do not satisfy it. Production release remains an independent gate.

Raw bounded metadata, source bytes and manifests are retained under .artifacts/p9-sec-02/ci/; ci-assessment.json records response and source hashes, actual permission failures, limitations and actions. No workflow dispatch, host mutation, Docker socket use, secret-value/log access, database operation or deployment occurred.

Final metadata refresh25October12:32UTC: ci-final-refresh.json records runs856/857 at22ef8d0/30e251a queued for jobtracker-mariadb-isolated, with unassigned runner IDs0. The query returned metadata only; no current HostConfig or service lifecycle was inspected and no job log was downloaded. Hosted MariaDB BLOCKED; isolation UNVERIFIED;0 hosted database cases. Operator provisioning and actual isolation/execution proof remain necessary. Review stale owned queued guard jobs during that separately authorised operator handoff; this task did not cancel them.