PR Drain
Pull requests converging on master, one at a time.
Every open pull request as the integration lane assessed it: what it waits for, what would move it, what it depends on and overlaps, and the issue it carries.
- Issues ready86plan.status /counts/by_status/READY
- Issues active1plan.status /counts/by_status/ACTIVE
- Issues blocked159plan.status /counts/by_status/BLOCKED
- Issues done161plan.status /counts/by_status/DONE
Issue
One issue of the plan, as the plan records it.
I2740 · truthful-plan-surfaces · p0 · wave 0
An issue's delivery is inferred from branches, pull requests, merges, tags and the published site
Add the capability plan.delivery (CLI majordomus plan delivery [--json] [<id>], HTTP and MCP from the one capability declaration) that answers, for every issue, the furthest stage of none, branch, pr_open, merged, released, deployed, each with the object that proved it and when it was observed, and expose it in the site data the plan pages read.
- Depends on
- none
- Blocked by
- none
- Serves
- none
- Scope
apps/majordomus-cli/src/capability/builtin/plan.rsapps/majordomus-cli/src/planapps/majordomus-cli/src/plan.rsapps/majordomus-cli/tests/plan_delivery.rsscripts/generate-site-datasite/data/generated/delivery.jsonand 3 more- Evidence
- 0 of 2
- Started
- not yet
- Verified
- not yet
- Completed
- not yet
plan.issues0 msAPI/api/v1/plan/issuesMCPmajordomus_plan_issuestechnical view
Pull-request drain
The integration lane asks the forge for every open pull request; this takes a while and arrives after the screen.