1. GitHub issue
A newly selected issue becomes a provider event that Rainrail can normalize instead of handing raw GitHub payloads to workflow code.
Examples
GitHub issue to Project queue to agent PR to review to merge.
This first end-to-end example shows the intended path from a work item to an observable agent workflow while keeping provider details behind Rainrail contracts.
GitHub -> Project -> agent -> PR -> review -> mergeOne traceable workflow across source, queue, runtime, and review events.
End-to-end path
2. Project queue
The queue provider selects the next eligible issue, takes a starting lock, and keeps closed issues or already running work out of the dispatch path.
3. Agent run
A workflow plugin requests an agent run through the runtime provider, passing deterministic issue, branch, and session inputs.
4. Pull request
The agent pushes an implementation branch and opens a pull request that links back to the issue and records the checks that were run.
5. Review
Review events can re-enter Rainrail as neutral events so follow-up work uses the same workflow and provider boundaries.
6. Merge
After review and CI pass, merge remains behind explicit workflow capability gates instead of being an implicit side effect of event ingestion.
Contracts behind this example
The example intentionally stays implementation-neutral. The exact event envelope, Project queue claim semantics, and runtime capability gates are documented in the engineering specs.