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.
I1206 · web-sign-in · p1 · wave 5
What an anonymous reader may do is derived from the effect classification, not from a list
Derive the exposure decision from the capability registry: a read-only capability stays open to an anonymous reader, anything that mutates requires an identified one, and the decision is stated once in policy over effect classes rather than per route. Project the decision into the OpenAPI security scheme, the Cockpit's disabled controls with their reason, and the generated documentation.
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.