Development record
Approve a merge from the dashboard or a web app
Press Release
The technical facilitator can approve a pull request's head from the dashboard or a web app, as one more channel beside the terminal's abcd land --approve. The approval is the same record either way: of that head commit and no other, counted by the merge gate in human mode. Before the approval is given, the page shows what is being approved: the pull request, its head commit and the review receipt that names it.
Why This Matters
Why this matters to the user — replace before planning.
Mechanism
Prompted (the claim-recording gradient): why the authors expect this to work, as a falsifiable "we expect X because Y" — not the outcome restated. Replace this line with the claim, or with the exact token
None stated.alone on its line to record the claim as considered and declined.
Scope Conditions
Required (the claim-recording gradient): the population, platform, scale, or assumptions this claim holds under, one per top-level bullet —
abcd intent planstamps each with a persistent identity. Replace this line with those bullets, or with the exact tokenNone stated.alone on its line.
Acceptance Criteria
Required (the itd-1 discipline): add at least one Given-When-Then bullet describing the verifiable bar for "shipped" before this draft can be planned.
Open Questions
None recorded yet.
Audit Notes
Empty. Populated by intent-auditor when intent moves to shipped/.
Frontmatter
| id | itd-2610300955049260 |
|---|---|
| type | intent |
| lifecycle | drafts |
| severity | minor |
.abcd/development/intents/drafts/itd-2610300955049260-the-technical-facilitator-can-approve-a.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26103009551548512026-10-30 — Merge approval and pull-request check rulings. Human mode's merge approval is a rule agents keep, not a proof of who approved: it stops an agent merging by mistake, not one set on getting round it, abcd says so wherever it describes the mode, and no proof mechanism enters this release. The person approves in the terminal through an abcd command (abcd land --approve today, or a dedicated verb), so the current act stands; the dashboard or a web app is one more channel for the same approval (itd-2610300955049260), not a gap. Agents working under a forge account of their own is optional work, designed from current practice to run in the cloud and locally, through an API key or a subscription (itd-2610300955026531). Requiring a security key touch for an approval is later work (itd-2610300955031405). The three checks every pull request runs, the change labeller, the dependency review and the vulnerability scan, stay non-blocking, and a failure in any of them is fixed without being asked until it passes.
- itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them