# coreci/executor-config — approval-request queue (repurposed, REQ-27) **TL;DR** — this repository. This file explains how to stand it up and who to contact; the machinery detail stays lower under Details. Governance lane for CoreCI's executor rail (LXC 116 coreci-executor + LXC 117 coreci-broker — BOTH STAY RUNNING). The rail is REPURPOSED as an approval-request queue ONLY: operational requests from acting employees' pipelines are parked here, routed across the chain of command, decided by the resolved approver at the executor UI, mirrored to a Gitea issue lane, and POLLED by the requesting pipeline. The queue NEVER executes anything against production. This repo is FROZEN: the one-way config change below (a PR) is the only change channel — direct pushes are denied, no apply pipeline lives here, and there is no CI: the deploy step is the on-host, operator-gated reconcile in `docs/approval-queue-runbook.md`. ## What this repo carries (post-repurpose) - `allowlist.yaml` — policy engine config, v5.0 (`mode: approval_queue_only`) — every legacy AUTO_RUN grant is REVOKED; failure mode is NEEDS_APPROVAL for everything (fail-closed). The revoked grants are enumerated inline. - `routing.json` — GENERATED approval-routing table (manager edges, system owners, C-09 chairman-direct seat set; source: coreci/company `org/systems-ownership.md` v1.2 + org-chart.json; generator: coreci/sre `scripts/p04-executor/gen-routing-table.py`). Do not hand-edit — regenerate. - `compose.yaml` + `executor.env.example` — deployment; secrets in `.env` only (never committed). - `app/` — legacy classifier module (v0.1.1 history kept for the audit trail). Stale vs the live rail (0.3.0 server, built on-host): do NOT "restore" it — the 0.4.0 decision-only server is built from the live source, per the runbook. - `docs/` — approval-queue runbook (this repurpose), legacy approval-ui spec (kept for history), Open WebUI registration, legacy runbook. - `logs/` — git-durable audit JSONL (one line per queue event; see the event vocabulary in the mirror contract). ## The NEVER-EXECUTES guarantee (REQ-27) The queue path contains no execution of any kind: - the legacy job runner (pack execution on approve) is DISABLED in approval-queue mode; approve/deny are decision-RECORD operations; - no script execution, no host execution, no work-runner container — `WORK_ROOT` remains only as legacy-compat storage, never a run surface; - the executor's own credentials (below) are scoped to the queue's WRITE surface: meeting-lane issues + audit logs, nothing else; - the v4.1 mailbox-path AUTO_RUN exemption was app-code-level; in approval-queue mode it can no longer reach an execution path (nothing executes). v5.0 records its revocation inline. Routing semantics: manager-first (one chain-of-command hop) + system owner when an owned system is touched (both when both). Chairman-direct lane per C-09 (acting C-suite, CEO, coreci-sre → Chairman decides directly). Unresolvable chain → CEO → Chairman queue (sanctioned skip-path 2). Full audit: every request event is append-only JSONL under `logs/` and mirrored to `coreci/meetings` (labels `approval-request`, `approval:L2|L3`, `dept:`). ## Decision surface Approvers decide at the executor UI (passcode-gated `/ui/*`) and/or read the mirror issue in coreci/meetings; the requesting pipeline polls `GET /request_status?request_id=…` (Bearer EXECUTOR_API_KEY). Requests are CREDENTIAL-FREE envelopes; the executor injects nothing anywhere — the requestor keeps its own credentials, the queue only carries their REQUEST for approval. ## Freeze discipline - `allowlist.yaml`, `routing.json`, `executor.env.example`, `README.md`, `docs/` change ONLY via PRs into this repo's `main` (one-way channel). - `coreci/broker` (LXC 117) is frozen on the same one-way-PR discipline. - No redeploy pipeline reads this repo; deployment is operator-gated (runbook §"Apply the change"). Executor identity: `coreci-executor` (non-admin Gitea account; its PAT carries only what the mirror + audit need — see `docs/approval-queue-runbook.md`).