workflow_run_status returns {conclusion, html_url, run_id, started_at, status} and workflow_run_list returns the same per run. Neither says which jobs ran. The estate's own standing rule is "read the first CI run's jobs, not its conclusion", because a run whose real jobs were skipped reports success (template-go-web#9, #10). With these tools an agent cannot follow that rule.
Seen on 2026-10-08 in mathias/doodle: a tag-push run came back success because deploy is restricted to branch pushes and was skipped, while every branch-push run failed. The tool showed one green run and no way to see why, or which job failed in the red ones. Retro cause RC2: mathias/doodledocs/retro/2026-10-08-remotion-bootstrap.md.
Do not assume the endpoint exists
The brain records that a green fake-server suite is not proof the endpoint exists (code_search once called an API path Gitea never had). Step one is to check the live swagger at https://git.d-ma.be/api/swagger for a per-run jobs endpoint on this Gitea version. If none exists, the finding is that job-level data is only reachable another way, and the rest of this issue becomes research, not feature work.
Acceptance Criteria
The swagger check is done and the result (endpoint path, or "absent") is posted as a comment.
If the endpoint exists: workflow_run_status returns a jobs array, each entry with name, status, conclusion (including skipped), and the step names with their conclusions.
A table-driven test using a recorded Gitea response covers: all jobs succeeded; one job failed; a job skipped while the run concluded success. In the third case the tool's output makes the skipped job visible.
The tool's description says that conclusion alone is not evidence that the real jobs ran.
The locked tool-count test (if the repo has one) is updated deliberately, and task check is green with exit code 0.
If the endpoint is absent: a type/research follow-up is filed naming the alternative (REST fallback or another route) with its own binary criterion.
Risk: LOW
Source
doodle retro RC2; template-go-web#9, #10; brain inception-sprint-and-oath (the fake-green shape).
## Problem
`workflow_run_status` returns `{conclusion, html_url, run_id, started_at, status}` and `workflow_run_list` returns the same per run. Neither says which jobs ran. The estate's own standing rule is "read the first CI run's jobs, not its conclusion", because a run whose real jobs were `skipped` reports `success` (`template-go-web#9`, `#10`). With these tools an agent cannot follow that rule.
Seen on 2026-10-08 in `mathias/doodle`: a tag-push run came back `success` because `deploy` is restricted to branch pushes and was skipped, while every branch-push run failed. The tool showed one green run and no way to see why, or which job failed in the red ones. Retro cause RC2: `mathias/doodle` `docs/retro/2026-10-08-remotion-bootstrap.md`.
## Do not assume the endpoint exists
The brain records that a green fake-server suite is not proof the endpoint exists (`code_search` once called an API path Gitea never had). Step one is to check the live swagger at `https://git.d-ma.be/api/swagger` for a per-run jobs endpoint on this Gitea version. If none exists, the finding is that job-level data is only reachable another way, and the rest of this issue becomes research, not feature work.
## Acceptance Criteria
- [ ] The swagger check is done and the result (endpoint path, or "absent") is posted as a comment.
- [ ] If the endpoint exists: `workflow_run_status` returns a `jobs` array, each entry with `name`, `status`, `conclusion` (including `skipped`), and the step names with their conclusions.
- [ ] A table-driven test using a recorded Gitea response covers: all jobs succeeded; one job failed; a job skipped while the run concluded `success`. In the third case the tool's output makes the skipped job visible.
- [ ] The tool's description says that `conclusion` alone is not evidence that the real jobs ran.
- [ ] The locked tool-count test (if the repo has one) is updated deliberately, and `task check` is green with exit code 0.
- [ ] If the endpoint is absent: a `type/research` follow-up is filed naming the alternative (REST fallback or another route) with its own binary criterion.
**Risk:** LOW
## Source
doodle retro RC2; `template-go-web#9`, `#10`; brain `inception-sprint-and-oath` (the fake-green shape).
---
_Created via git-mcp on behalf of @mathias_
Step one of the acceptance criteria is done: the endpoint exists. Checked against the live swagger (https://git.d-ma.be/swagger.v1.json, Gitea 1.27.1) on 2026-10-08:
GET /repos/{owner}/{repo}/actions/runs/{run}/jobs (also .../runs/{run}/attempts/{attempt}/jobs)
GET /repos/{owner}/{repo}/actions/jobs/{job_id} and GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs
GET /repos/{owner}/{repo}/actions/jobs (repo-wide list)
Verified in use, not only listed: on mathias/doodle run id 9757 the jobs endpoint returned each job with status, conclusion and its steps[] with per-step conclusion including skipped, and the logs endpoint returned the failing step's text. Note {run} is the long run id, not the run number shown in the UI.
So this is feature work, not research. The "if absent" branch can be dropped. The recorded-response test should use a real response shape from this endpoint; the steps[] field is where a skipped job or step shows up.
Context: mathias/doodle#3 needed exactly this to find the failing job; it read the data through a short read-only script until this tool exposes it (mathias/doodle#13).
Step one of the acceptance criteria is done: **the endpoint exists.** Checked against the live swagger (`https://git.d-ma.be/swagger.v1.json`, Gitea **1.27.1**) on 2026-10-08:
- `GET /repos/{owner}/{repo}/actions/runs/{run}/jobs` (also `.../runs/{run}/attempts/{attempt}/jobs`)
- `GET /repos/{owner}/{repo}/actions/jobs/{job_id}` and `GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs`
- `GET /repos/{owner}/{repo}/actions/jobs` (repo-wide list)
Verified in use, not only listed: on `mathias/doodle` run id 9757 the jobs endpoint returned each job with `status`, `conclusion` and its `steps[]` with per-step `conclusion` including `skipped`, and the logs endpoint returned the failing step's text. Note `{run}` is the long run **id**, not the run number shown in the UI.
So this is feature work, not research. The "if absent" branch can be dropped. The recorded-response test should use a real response shape from this endpoint; the `steps[]` field is where a skipped job or step shows up.
Context: `mathias/doodle#3` needed exactly this to find the failing job; it read the data through a short read-only script until this tool exposes it (`mathias/doodle#13`).
---
_Created via git-mcp on behalf of @mathias_
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
workflow_run_statusreturns{conclusion, html_url, run_id, started_at, status}andworkflow_run_listreturns the same per run. Neither says which jobs ran. The estate's own standing rule is "read the first CI run's jobs, not its conclusion", because a run whose real jobs wereskippedreportssuccess(template-go-web#9,#10). With these tools an agent cannot follow that rule.Seen on 2026-10-08 in
mathias/doodle: a tag-push run came backsuccessbecausedeployis restricted to branch pushes and was skipped, while every branch-push run failed. The tool showed one green run and no way to see why, or which job failed in the red ones. Retro cause RC2:mathias/doodledocs/retro/2026-10-08-remotion-bootstrap.md.Do not assume the endpoint exists
The brain records that a green fake-server suite is not proof the endpoint exists (
code_searchonce called an API path Gitea never had). Step one is to check the live swagger athttps://git.d-ma.be/api/swaggerfor a per-run jobs endpoint on this Gitea version. If none exists, the finding is that job-level data is only reachable another way, and the rest of this issue becomes research, not feature work.Acceptance Criteria
workflow_run_statusreturns ajobsarray, each entry withname,status,conclusion(includingskipped), and the step names with their conclusions.success. In the third case the tool's output makes the skipped job visible.conclusionalone is not evidence that the real jobs ran.task checkis green with exit code 0.type/researchfollow-up is filed naming the alternative (REST fallback or another route) with its own binary criterion.Risk: LOW
Source
doodle retro RC2;
template-go-web#9,#10; braininception-sprint-and-oath(the fake-green shape).Created via git-mcp on behalf of @mathias
Step one of the acceptance criteria is done: the endpoint exists. Checked against the live swagger (
https://git.d-ma.be/swagger.v1.json, Gitea 1.27.1) on 2026-10-08:GET /repos/{owner}/{repo}/actions/runs/{run}/jobs(also.../runs/{run}/attempts/{attempt}/jobs)GET /repos/{owner}/{repo}/actions/jobs/{job_id}andGET /repos/{owner}/{repo}/actions/jobs/{job_id}/logsGET /repos/{owner}/{repo}/actions/jobs(repo-wide list)Verified in use, not only listed: on
mathias/doodlerun id 9757 the jobs endpoint returned each job withstatus,conclusionand itssteps[]with per-stepconclusionincludingskipped, and the logs endpoint returned the failing step's text. Note{run}is the long run id, not the run number shown in the UI.So this is feature work, not research. The "if absent" branch can be dropped. The recorded-response test should use a real response shape from this endpoint; the
steps[]field is where a skipped job or step shows up.Context:
mathias/doodle#3needed exactly this to find the failing job; it read the data through a short read-only script until this tool exposes it (mathias/doodle#13).Created via git-mcp on behalf of @mathias