01
Connect
Project, GitHub App installation, repository binding, and execution policy.
From mission to merged code
One request becomes a controlled execution path.
A human defines the outcome. RustGrid binds the work to a project and repository, gives an agent a traceable run, records progress and validation, and returns the result to a human decision point.
The operating model
A continuous record across six control points.
Planning tools describe work. Coding agents execute work. RustGrid holds the operational state that lets those moments function as one governed system.
02
Define
Mission scope, requirements, attachments, comments, priority, and assignment.
03
Execute
A leased run, repository manifest, steps, and durable event stream.
04
Validate
Running, passed, or failed quality-gate results with structured checks.
05
Review
Pull request and check events return from GitHub to the mission state.
06
Decide
A human can approve, request refinement, cancel, or leave work blocked.
01 · Connect
Establish the project and repository boundary.
Install the RustGrid GitHub App, discover repositories available to that installation, and bind the intended repository to a RustGrid project. The binding carries required workflow policy, while the execution manifest includes the repository's default branch.
GitHub remains the source of truth for code. RustGrid stores which project is allowed to send autonomous work to which repository.
02 · Define
Turn a request into durable mission context.
The mission is the stable thread through every execution attempt. Its API resource is currently a RustGrid ticket, with mission used as the product language in the control plane.
Mission RG-184
Add organization member invitation management
Implement resend and revoke actions for pending invitations. Preserve the existing member table behavior and add regression coverage for both actions.
Acceptance criteria
- Pending invitations expose resend and revoke actions.
- Success and failure states are announced accessibly.
- Existing member actions remain unchanged.
- Typecheck, unit tests, and production build pass.
Context attached to the work
Conversation
Comments preserve clarification and feedback.
Files
Attachments travel through the managed upload lifecycle.
Structure
Labels, relations, and custom fields keep constraints addressable.
History
Activity and previous runs remain available to inspect.
03 · Execute
A worker claims one explicit attempt.
Claiming creates a running, leased agent run. The lease makes current ownership explicit; the run keeps its own status, steps, event sequence, output summary, and error state.
The run boundary
- Worker claims eligible work. Active unexpired claims conflict rather than silently double-executing.
- RustGrid resolves a manifest. Project, mission, repository, required workflows, permissions, and execution policy arrive together.
- The worker requests repository access. The API issues a short-lived GitHub App installation token restricted to the run repository.
- The worker reports progress. Steps and events build an operational timeline that can be queried or streamed.
- The worker closes the attempt. A status and output summary remain attached to that run.
{
"manifest_version": 1,
"project_key": "RGC",
"ticket_key": "RG-184",
"ticket_title": "Add organization member…",
"repository": "rustgrid/rustgrid-agentops",
"default_branch": "main",
"required_workflows": ["ci-quality-gate"],
"required_permissions": { "contents": "write" },
"run": { "status": "running", "attempt": 1 }
}Illustrative, abbreviated manifest based on the current contract. Repository access is issued separately as a short-lived token.
Continuous visibility
The timeline survives the terminal session.
Run events are durable and ordered by sequence. The Control Room can replay older events, consume new ones over server-sent events, and resume after a known sequence when a connection drops.
That gives people a shared account of the attempt: what phase the worker entered, what it reported, where it failed, and what summary it left behind.
04 · Validate
Quality is reported as a first-class result.
Quality-gate results belong to the mission and can reference the run that produced them. Their state is explicit—running, passed, or failed—and their checks are structured rather than inferred from a final message.
Passed · illustrative Quality Gate RG-184 / Run 01
Typecheck
Passed
npm run typecheck
Unit tests
Passed
npm test
Build
Passed
npm run build
Human review
Required
Automation does not make the merge decision.
05 · Review or refine
Return autonomous output to engineering judgment.
RustGrid receives GitHub pull request, review, check, and workflow lifecycle events. The mission can represent pull-request and review states while GitHub continues to own the code and merge controls.
Ready for review
Approve the result
Inspect the pull request in GitHub, review changed files and checks, and merge under the repository's normal policy. RustGrid keeps the work context around that decision.
Needs refinement
Start another accountable attempt
Add feedback to the mission and create or claim another run. The failed gate, first attempt, feedback, and new result remain separate parts of one history.
06 · Complete
The result is code. The product is the controlled path to it.
When a pull request reaches its human-approved outcome, the mission can move to done. Its description, context, assignments, attempts, events, quality results, GitHub links, and activity remain the operational history of how the work moved.
One mission. Complete context. Autonomous execution. Human approval.
Give the next request an execution path
Describe the outcome. Keep control of the decision.
RustGrid gives the mission, agent run, validation, and review state one durable place to meet.