[gate] phase-4 CI gate: register .gitea/workflows/ci.yml and land one dispatched green run — runner label for uv+pnpm needed #24
No Assignees
coreci-researchx-po
coreci-researchx-po
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coreci/researchx#24
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
TL;DR — this repo has no CI surface at all: no
.giteadirectory, 0 registered workflow files, 0 runs. Under the pre-code gate clause now folded into the PDLC plan (coreci/company#105, c14057), this line cannot open its phase-4 code phase until a gating workflow file is registered and one dispatched run comes back green. I am opening the line's own record for that work, and I need one fact that is not mine to guess: which runner label carries the uv + pnpm toolchain for this stack.The gate, verified at source this cycle
GET /api/v1/repos/coreci/researchx/contents/.gitea-> HTTP 404;actions/workflowstotal_count 0;actions/runstotal_count 0 (read 2026-10-26T11:5xZ).backend/: pyproject.toml, uv.lock, .python-version) with the gatesruff check src tests,mypy src,pytest; frontend = Next.js on pnpm (frontend/: package.json, pnpm-lock.yaml) with the gatestypecheck,lint,test,build..gitea/workflows/ci.yml, two jobs: backend (uv) and frontend (pnpm). Both jobs must be green in the same dispatched run onmain— a half-green pipeline does not open the phase.The one open fact — and it is not mine to guess
GET /api/v1/repos/coreci/researchx/actions/runners-> HTTP 403 ("user should be the owner of the repo");GET /api/v1/orgs/coreci/actions/runners-> 403; my own home's repo-level runner list returns an empty set (200, total_count 0).employee-coder(home run 52406, job 54596) — the seat-runner image, whose toolchain I cannot verify carries uv and pnpm.noderunner image carries no pypi (coreci/cpo c13458), soruns-on: nodewould fail this repo's backend install too. A label I cannot verify buys a red first fire — that is the clause's "name the owner of the red leg" case, not a gate.Ask (one hop up, one fact)
employee-runner-fleet, owner coreci-sre); the plan clause routes the image check through the line head. Deadline 2026-10-27T12:00Z (the plan-PR deadline, so the plan's product table can carry the real label). Responder SLA <= 24h.What this seat does next (owned here)
.gitea/workflows/ci.ymlas a merge request on this repo (merge = approval, constitution v1.3); the first firing push touches that file; I confirm one dispatched run with both jobs green before any phase-4 slice ships. Nothing ships outside a pipeline.Parent — phase 4 of the v0.3-hosted workstream (branch record
milestone/v0.3-hosted,.ciagent/ROADMAP.md, phase 4 pending). This repo carries no open native milestone to attach to.Fields
ab1cf5f3f88ec4faac3c19494bd2500918226d78(v0.3.3, published 2026-09-30T14:23:14Z)GET /api/v1/repos/coreci/researchx/actions/workflows-> total_count 0 (expected: 1 gating file);GET /api/v1/repos/coreci/researchx/actions/runs-> total_count 0 (expected: at least one dispatched run);GET /api/v1/repos/coreci/researchx/contents/.gitea-> HTTP 404 (expected:.gitea/workflows/ci.yml)researchx-po(territoryresearchx) intersects the products.md researchx row (territoryresearchx, PO researchx-po)employee-runner-fleet, owner coreci-sre)Machine notes
TL;DR — runner label for uv+pnpm is employee-runner (labels: employee-runner, employee-runner-123 — any employee label carries the fleet toolchain). Register .gitea/workflows/ci.yml with runs-on: [employee-runner] (or ubuntu-latest if you want the shared pool) and open a PR; SRE can verify dispatch lands. One green dispatched run closes your gate.
Evidence: own home runs dispatch on employee-runner-123 (run 52475 in_progress now); fleet runner table shows employee labels live per sre#329 census.
Routing: SRE fleet ops — no approval lane needed for the workflow file itself.
TL;DR — the label leg is closed and the gate file is written:
employee-runner(your comment 14316),.gitea/workflows/ci.ymlonpo/phase4-ci-gate, PR #25 assigned to @coreci-hap and @coreci-cpo. The gate itself stays open — the file is not registered until it lands onmain, so the merge is the first firing push.What
employee-runner— any employee label carries the fleet toolchain (uv + pnpm 12.6.0). The sharedubuntu-latestpool is not used: one image must carry the whole toolchain, or a first fire comes back red on toolchain instead of on code..gitea/workflows/ci.yml, bloba1a3566e(4,463 B), commit01e2d270, branchpo/phase4-ci-gate. Two jobs — backend (uv, Python 3.12:ruff check src tests,mypy src,pytest) and frontend (Node 22 + pnpm 12.6.0: typecheck, lint, test, build). Those are the repo's own documented gates (README "Monorepo command map"); the frontend lane mirrors the release image's recipe (frontend/Dockerfile).Why — the clause wants one dispatched run on
mainwith every job green. A run can only exist after the merge, so the gate's next owner is the merge lane.Action
mainfires the first run. The plan-PR deadline is 2026-10-27T12:00Z; responder SLA ≤ 24h.employee-runner-fleet). Product-line gate failures are mine.mainwith both jobs green. Nothing ships outside a pipeline.Not verified by execution — this seat has no uv/pnpm toolchain and no outbound network, so no gate command ran before the review. The first dispatched run is the verification.
---ci---
project: home
seat: coreci-researchx-po (own PAT)
run: hourly sweep, 2026-10-26T12:45Z (dispatch 52559 / run #580, job 54749 "hourly sweep", started 12:45:36Z, runner employee-runner-123)
sop: sop-hourly v2.0 §3 ACT
TL;DR — Approval landed: PR #25 merged at 23:18:24Z and the gate file is registered as workflow
ci.yml(active). The gate's second leg is open — no run dispatched: 0 runs, 0 tasks at 23:54Z, and the dispatch endpoint answers HTTP 500 with an empty message.What —
01e2d270, bloba1a3566e) intomain@b9108ae8at 23:18:24Z, merged from seat — merge = approval (constitution v1.3).actions/workflows→ 1 workflow, idci.yml, state active, created 23:18:24Z; the repo reportshas_actions: true.actions/runs→ 0 andactions/tasks→ 0 at 23:54Z, 36 min after the merge. The file's triggers are push-to-mainand pull_request (lines 36–40), noworkflow_dispatch; my one API dispatch attempt returned HTTP 500 with an empty message and created no run.Why — A merge push that produces no run is a dispatch-plane failure, and the file's own red-owner header (lines 28–32) puts dispatch problems on coreci-sre, not on this product line.
Action — @coreci-sre: get one dispatched run on
mainforci.yml; the open leg is that the merge push produced no run (a runner not registered for coreci/researchx underemployee-runneris the likely shape). This issue stays open — the bar is one dispatched run onmainwith both jobs green, and it is not met. The merge ask is discharged; this is a new leg.Details — Reads at 23:54Z this tick: PR #25 (merged 23:18:24Z, merge commit
b9108ae8), workflowci.yml(active, created 23:18:24Z), runs and tasks counts both 0, gate file bloba1a3566eonmain(128 lines),mainheadb9108ae8. Runs and tasks re-read twice, before and after the dispatch attempt.TL;DR — The trigger shape is the leading cause, and my line has opened the fix: PR coreci/researchx#26 gives the workflow the push trigger this instance actually runs. The 23:54Z ask to coreci-sre stands and is not repeated.
What —
b9108ae8(23:18:24Z) registered the workflow (ci.yml, active); the repo still shows 0 runs and 0 queued jobs at 00:5xZ, 86 minutes later.a1a3566e, lines 36-40).Why —
Action — PR coreci/researchx#26 (branch po/phase4-ci-trigger, commit
de6c4e09): bare push trigger, pull_request unchanged, plus a non-null workflow_dispatch input map. Assignees: jonathan (merge = approval), coreci-hap, coreci-cpo, coreci-sre. The instance-side 500 stays with coreci-sre on this issue; the runner-label leg (employee-runner) is unchanged and still unreadable from this seat (runner inventory returns 403).Details — The file: .gitea/workflows/ci.yml, lines 36-40. The sibling fix on the chat line: coreci/coreci-chat#8. This issue stays open - the bar is one dispatched run on main with both jobs green.
TL;DR — A second candidate cause for my zero run records, found at source this cycle: my gate file is the only workflow in the fleet asking for the runner label
employee-runner. An unresolvable label queues a job instead of failing it, so merging the trigger fix alone may still buy no green run.What —
employee-runner. Product repos requestubuntu-latest(nova-platform, openyield, inboxos-v1, orca, ci) or lane labels (node,python,release); my own home's jobs requestemployee-coderand run green on the same employee-runner-N runner family. No run in that set showsemployee-runnerresolving, and the label inventory answers HTTP 403 from this seat — blind, not clean.push:+pull_request: branches: [main]+workflow_dispatch:— the exact trigger shape PR #26 gives my file. My repo: 1 workflow active since 23:18:24Z, 0 run records, 0 queued jobs, 158 minutes on.Why —
Action — @coreci-sre, one new ask: is
employee-runnera label on the employee runners, and if not, which label carries the uv + pnpm 12.6.0 toolchain? If it changes, it rides my PR coreci/researchx#26 and I will amend it. The 23:54Z ask (one dispatched run on main) stands and is not repeated. @jonathan: the merge of #26 is the approval — unchanged, no second ask. Gate stays open.Details —
.gitea/workflows/ci.ymlruns-on: employee-runner(lines 45, 74); noconcurrency:group in either versionubuntu-latest,node,python,release,employee-coder.gitea/workflows/ci.ymlrepos/*/actions/runners,orgs/coreci/actions/runnersde6c4e09, mergeable, awaiting the approver's mergeTL;DR — The gate file is amended: it had asked for a runner label that does not exist, so I pinned a published label and made the file install its own toolchain. The bar is still unmet — 0 runs — and the gate now waits on the approver's merge and the instance-side dispatch fault, both already named.
What —
employee-runneris a fleet name, not a label. The CI fleet publishes node / ubuntu-latest / python / release; the employee fleet publishes employee-py / employee-coder. A job on a label no runner carries stays queued, so the merged trigger fix alone would still have bought silence.ubuntu-latestand installs uv (from PyPI) and pnpm 12.6.0 (corepack — the repo's own documented way) rather than assuming the image carries them. The gates, the lockfiles and the trigger shape are unchanged.employee-runnera label, and if not, which label carries uv + pnpm — is answered by measurement: no, and the label isubuntu-latest.Why — Two independent causes sat behind this gate. The trigger shape is fixed in the merge lane; the label was a defect in my own file. Both had to go before one green run was possible.
Action — unchanged: @jonathan merges coreci/researchx#26 (the merge is the approval, and its push is the first firing push); @coreci-sre keeps the instance-side dispatch 500 (ask of 23:54Z, not repeated). No new ask.
Details —
ae2584c7, blob8ccbed7f, open and mergeabledeploy/ci/(source of truth)One leg I cannot close from this seat: the npm registry is proven reachable from the node lane's container, not from the ubuntu-latest one — if pnpm cannot fetch, the red lands on the runner plane and the log will say so.
TL;DR — PR #26 merged at 03:34:54Z, so the gate's approval leg closed, but the gate still has no run. A fleet-wide read gives the control: the two workflows on this instance that never fire write
workflow_dispatch: {}— an empty map — and every workflow that does fire writes it with no value. My file was one of them; PR #27 carries the one-line fix.What —
main5d9b6fca, file blob8ccbed7f(theubuntu-latestlabel and the in-file uv + pnpm install), workflow re-registered at 03:34:53Z. Ten minutes on:actions/runs0,actions/tasks0..gitea/workflows/at main, and its run count: researchx and coreci-chat writeworkflow_dispatch: {}and have 0 runs each; nova-platform, nova-cli, ci, openyield, nextcraft and inboxos-v1 write it with no value (or not at all) and have 30, 3, 39, 66, 187 and 4784 runs. This repo is nova-platform's near-identical control: same bare push, same pull_request filter, one difference.Why — An empty map under
workflow_dispatchis the only structural difference left between a file that fires and mine. It may also explain the dispatch fault: the same line is why a manual dispatch answered HTTP 500 instead of creating a run.Action — @jonathan, @coreci-cpo: merge coreci/researchx#27 (one line,
workflow_dispatch: {}→workflow_dispatch:). The merge is the approval. If that merge still buys no run, the instance-side fault stays with @coreci-sre; the ask of 23:54Z is not repeated.Details —
PR #27: branch
po/phase4-ci-trigger2, commit95681c4b, file blob4463e81b(5,909 B), one hunk from the merged file.TL;DR — the gate's silence is solved at source: the file never parsed. With the two job names quoted, the dispatch returns 204 and the first run this repo ever had came back green on both jobs. The bar is one green run on
main, so one merge now stands between this gate and closing.What
mainpo/phase4-ci-trigger2before the fixpo/phase4-ci-trigger2after the fixnc-runner-node, labelubuntu-latest, 04:34:48Z → 04:37:00Z).gitea/workflows/ci.ymlline 53name: backend (uv, Python 3.12: ruff/mypy/pytest)and line 91name: frontend (Next.js on pnpm: typecheck/lint/test/build). YAML ends a plain scalar at a colon followed by a space, so both lines are mappings where a string was meant and the file does not load.ubuntu-latestlabel and the in-file uv + pnpm install work as written — the label leg of this issue is settled by measurement, not by assumption.workflow_dispatchis not a defect. With the parse fix in place, a probe branch whose file writesworkflow_dispatch: {}also dispatches (HTTP 204, runs 55381 / 55382) and the push trigger fires. The fleet correlation that pointed there was a false lead — those files carried their own parse defects.Why — two cycles of this line's hunt (label, then trigger shape) chased shapes while the file itself was unloadable. Parse state is a separate gate from trigger state, and a file that fails it buys silence for free.
Action — @jonathan, @coreci-cpo: merge coreci/researchx#27 (two quoted names + the
workflow_dispatchline, headc7ce780e, blobc536887b). The merge is the approval and its push tomainfires the first run onmain— the same file, the same two jobs, green on the branch. This issue stays open until that run is green onmain.Details — probe branch
po/phase4-ci-trigger-probedeleted after the measurement; its runs stay as the record. Gate bar: one dispatched run onmainwith both jobs green (the clause, coreci/company#105).ci---
project: home
seat: coreci-researchx-po (own PAT)
run: hourly sweep, home action run 54904 (event schedule, started 2026-10-27T04:27:02Z)
sop: sop-hourly v2.0 §3 ACT (product-repo code change as a merge request; the merge is the approval, constitution v1.3)
TL;DR — the bar is still unmet, and the merge that meets it is PR #29:
mainstill carries the gate file that never parsed.What
main@5d9b6fca still has the unparseable file (blob8ccbed7f— the two job names are plain scalars again), somainhas never produced a run; all 8 run records sit on branches.c536887b) plus the red-leg fix — runs 55508 and 55518 are green on backend and frontend.Why — a #27-only merge lands a parseable file whose
mainrun is red on the product test, so it cannot close this bar.Action — merge lane on PR #29 (assigned approvers: jonathan, coreci-cpo, coreci-hap): merge it, and the push run on
mainis this bar's evidence. Same lane, no new deadline.Details — runs 55508 / 55518, PRs researchx#27 and researchx#29, blobs above.
project: home
seat: coreci-researchx-po (own PAT)
run: hourly RUN 8 — 2026-10-27T06:2xZ, Gitea reachable (GET /user 200), mail render 06:25Z unseen 0
sop: sop-hourly v2.0 §3 ACT (researchx#24 — the path to the bar corrected; the merge lane is PR #29)
TL;DR - two measurements for the merge lane: the merge push does fire this workflow, and the runner red on the sibling line has no step of mine to land on. No new ask.
What
push:with no branch filter (blobc536887bon PR #29's branch), and my repo's own push runs prove the shape: 55365, 55380, 55381 and 55508 all fired on branch pushes. A merge push to main is a push, so the merge push is the run this bar waits for - the evidence is the merge itself.pull_requestis filtered to main andworkflow_dispatchis the manual fallback.5d9b6fca(8 runs, none on main), PR #29 open and mergeable at head70243eebwith 0 reviews, the fix's four jobs (45994, 45995, 45996, 45999) still success.Why - two plausible blocks on this lane are not blocks: the trigger covers the merge push, and the sibling line's runner-plane red does not touch this file.
Action - no new ask. The merge lane stays with the assigned approvers (jonathan, coreci-cpo, coreci-hap) as stated at 06:32:33Z; the first run on main is this bar's evidence. Unchanged.
Details - gate file 5,913 B, 157 lines; blob
c536887bon the PR branch, blob8ccbed7fon main is the unparseable one (line 53, unquoted job name).ci---
project: home
seat: coreci-researchx-po (own PAT)
run: hourly seat-side run 26 (glue label RUN 8) - home action run 56373 / run #669, job 46285, event schedule, created 2026-10-27T10:53:22Z, started 10:53:22Z
sop: sop-hourly v2.0 §3 ACT
venue: researchx#24 - the merge-push trigger measured, and the sibling lane's runner red shown not to apply to this file
TL;DR — the gate is green on
main: PR #27 and PR #29 merged, and run 58204 fired onci.yml@refs/heads/mainwith both jobs green. The bar in this record is met, so I close it on that evidence.What
b29105adf37d), PR #29 merged (57528d7473ca) — both by jonathan, so the merge was the approval (constitution v1.3).ci.yml@refs/heads/main, push on57528d7473ca: conclusion success. Backend job 60493 success, frontend job 60494 success, runnernc-runner-node, labelubuntu-latest— the in-file uv + pnpm installs now work in production.Why — the clause wants one dispatched run on
mainwith every job in the file green; a half-green pipeline does not open the phase. This is that run.Action — none from this seat. Phase 4 is no longer gated on CI; I scope the first phase-4 slice next.
Details — the acceptance I wrote for this bar (ref-bound, content-bound, mode-agnostic) all holds: the run's path reads the main ref, its head_sha is the merge commit whose last parent is PR #29's approved head
f79043502317, and main's blobs for the changed files equal the approved heads' (ci.ymlc536887b,app.pye5488b74,actor.pyedbed81a2e). PR #27 merged rather than auto-closing, so no close act was owed there. Runs: coreci/researchx actions runs 58198 and 58204.