Rovara

Cloud coding agents · Your AWS account

Give your agents a task. Work with them in Slack.

Cloud agents and persistent workspaces in your AWS account. Give a task in Slack, agree on the plan, then let agents build, run the configured checks and open a draft PR for your team to review.

Install in your AWS account
# engineering · Thread
2
Maya

@AgentX add a CSV export for our company’s orders, limited to the dates we select.

AgentXRovara’s Slack bot

I’ll help you choose the workflow, then propose the plan and checks.

Sam

Viewers must be blocked, including direct API requests.

Illustrative task · Public source · Mainline capability preview

The complete workflow

From a Slack request
to a reviewed PR.

You shape the intent. Agents handle the build, checks and reviews. Your team decides what gets merged.

Read the workflow guide
  1. 01

    Describe the task.

    Ask in your project’s Slack channel. Add the issue link and context. Rovara suggests Quick or Full; the task owner starts the work.

    Starts withYour explicit request
  2. 02

    Agree on the plan.

    Quick has one coding-plan approval. Full adds requirements and design approvals. Teammates add context; the owner approves the current version and check scope.

    You approveThe approach and checks
  3. 03

    Work in the cloud.

    The agent implements the approved plan in the project’s workspace in your AWS account. The branch, files and conversation stay with the task.

    Agents produceA working branch
  4. 04

    Test and review.

    Required and selected tests or checks run on the changed code. Separate code and security reviews follow. Blocking findings can go back to coding, then fresh checks.

    You can inspectResults and review findings
  5. 05

    Review the draft PR.

    When the selected checks and reviews pass, Rovara opens a draft PR of the checked code and posts it in Slack. Review the diff and repository CI in GitHub.

    Your team decidesWhat gets merged
  6. 06

    Keep the work moving.

    PR comments become proposed fixes. Approve the changes you want; agents update the same PR after fresh checks and reviews. Return to the retained workspace for follow-ups.

    Stays connectedThe thread, workspace and PR

An example, step by step

One task. A working conversation.

A teammate asks for a CSV export. Follow the plan, cloud work and checks through one Slack conversation.

# engineering · One task thread
Export orders to CSVapp-api · Your AWS workspace
Request

01 / Request

Start with a task.

MayaTask owner

@AgentX Finance needs a CSV of our company’s orders for the dates they select. Add an export action.

AgentXRovara’s Slack bot

I suggest Quick. I’ll inspect the repository, propose a coding plan, then wait for your approval.

02 / Plan · Team input

A better plan starts with the team.

Maya explicitly started the Quick workflow.

AgentXAPP · Planning

Plan v1 · proposedAssumption: date filters use UTC.

SamTeammate

Use our company timezone, including the whole last day. Viewers must be blocked even if they call the handler directly.

Maya requested a revision with Sam’s date rule.

02 / Plan · Revision

The clarification becomes the plan.

AgentX linked the revised coding plan to this thread.

Coding plan

Plan v2

Sam’s clarificationUTC date boundariesCompany timezone. The whole final day.

Date rangeOctober 1–2 → only a1, a2

Company scopeNo Beta rows in Alpha’s export

Viewer accessDirect handler returns 403

Proposed checks: source functions, synthetic rows, mocked database.

02 / Plan · Owner decision

Maya decides when work starts.

MayaTask owner
Owner decision

Plan v2 approved.

Company-timezone dates, company scope and the viewer guard. Proceed with the proposed source/mock checks.

Approval is recorded before implementation begins.

03 / Cloud work

The work carries on in the cloud.

AgentX is coding in the workspace linked to Export orders.

Your AWS account

app-api

Coding · Revision A
task/export-orders
src/orders/export.tsExport implementation
src/orders/export.test.tsSelected source checks

The files and task context stay in the cloud workspace.

MayaTask owner

I’ll pick this up here when the checks are ready.

04 / Test · Failed expectation

One row catches the mistake.

Checks posted the export result back to the thread.

Run 1 · Revision AFailed

Expected: October 1–2, company Alpha. Only a1 and a2.

OrderDateResult
a3Sep 30Outside range
a1Oct 1Expected
a2Oct 2Expected

September 30 is outside the approved dates. This required check blocks the draft PR.

Source check · synthetic rows · mocked database

05 / Fix · New revision

The failed expectation goes back to coding.

Maya sent the failed date expectation back for correction.

AgentXAPP · Coding

I corrected the date boundary. Revision B excludes September 30 and keeps the approved company-timezone rule.

src/orders/export.ts · illustrative excerpt

The date rule changes.

− dateBounds(from, to, "UTC")
+ companyDateRange(from, to, company.timezone)

A changed revision needs fresh checks. Run 1 stays in the history.

05 / Retest · Fresh results

Check the correction on the new revision.

Checks ran again on Revision B.

Run 2 · Revision BPassed with mocks
OrderDateCompany
a1Oct 1Alpha
a2Oct 2Alpha

Company isolation: no Beta rows. Viewer handler: 403.

3 selected source checks · synthetic rows · mocked database

Run 1’s failure remains inspectable. Separate code and security reviews follow for B.

06 / Draft PR · Human review

A change your team can actually review.

Draft PR · Revision B

Export filtered orders

Ready for human review

task/export-orders → main

+ if (actor.role === "viewer") return forbidden();
+ const range = companyDateRange(from, to, timezone);
+ const rows = await listOrders({ companyId, range });

3 selected checksPassed with mocks · B

Code reviewPassed · B

Security reviewPassed · B

Separate read-only review sessions · illustrative outcomes

Your team inspects the change and decides what gets merged.

07 / Return · The same workspace

Come back to the same work.

MayaTask owner

I’m back to review the draft PR. Let’s pick up where we left off.

The same cloud workspace

app-api

Compute idle
task/export-orders
src/orders/export.tsRetained
src/orders/export.test.tsRetained
Approved Plan v2 and conversationStill with the task

Idle compute stops. The workspace retains the files and conversation for the next turn.

How workspaces continue
Illustrative task · fictional people and repository.Source/mock checks. Browser interaction is not exercised.
Scroll to follow the task.

Now bring your own task

Bring your next task to Slack.

An AWS administrator sets up the workspace and connections. Your team starts the work from its Slack project channel.

  1. 01

    Launch in your AWS account.

    Use the guided setup to create your workspace.

  2. 02

    Connect GitHub and Slack.

    Choose the repository and project channel.

  3. 03

    Bring your first task.

    Describe the change and explicitly start the suggested workflow.

You’ll need AWS, GitHub, Slack and model access. AWS and model usage have costs.

Before your first task

A few practical questions.

Planning, testing and the workspace behind your Slack conversation.

When should I use Quick or Full?

Use Quick for a well-defined fix or feature: approve a coding plan, then let the work run. Full adds requirements and design approvals before the coding plan, so your team can resolve unclear behavior and implementation choices first. Both keep the project’s required checks and reviews.

Explore the planning paths
What does “tested” mean for my task?

Checks follow the approved plan and project configuration. Results identify what ran on the changed revision, with passed, failed or unverified outcomes. Code and security reviews run in separate read-only sessions. End-to-end coverage depends on the project’s tests and qualified runtime; missing required coverage stays visible.

The example above uses synthetic rows and a mocked database. It does not show a browser test or a recorded customer run.

Understand checks and review evidence
Where does the work live when I leave?

In your AWS account. Each task has an isolated cloud worker and a persistent encrypted workspace. Idle compute stops; files and conversation stay on the workspace disk so the next mention can resume. AWS compute, retained storage and model usage have costs.

How workspaces stop and resume
What happens when a reviewer asks for changes?

Rovara reviews the PR comments and brings recommendations back to the Slack thread. The task owner approves the fixes to make, answers questions or dismisses feedback. Approved fixes go through checks and separate reviews again before updating the same PR. Your team controls the merge in GitHub.

Follow the PR feedback loop
Can I keep using my coding tools and model access?

Yes. Claude Code, Codex and Cursor can start or continue tasks through Rovara’s MCP tools. Model access is configured for your workspace. An administrator can also enable your own ChatGPT Plus or Pro plan for your own tasks; that option is off by default.

Connect your coding toolsRead the ChatGPT setup

Export orders · Plan and scenarios

Plan v2 · proposed approach and check scope

Extend the orders service with company-timezone date boundaries, filter the current company before CSV generation, and reject viewers in the handler.

Change requested by Maya after Sam’s clarificationPlan v1: UTC boundariesPlan v2: company timezone, including the whole last day
ScenarioExpected resultScope
Selected datesOnly a1 and a2 for October 1–2Source function · synthetic rows
Company scopeNo Beta row in Alpha’s CSVMocked database boundary
Viewer restrictionDirect handler returns 403Synthetic role context

Browser interaction is not exercised. A required native/browser check would remain unresolved without its qualified runtime.

Comments are input. The task owner approves the plan; comments do not grant approval.

Illustrative local interaction. No Slack message, agent execution, GitHub PR or deployment is performed.

Export orders · Assertion and run history

Expected order IDs: a1, a2. September’s a3 must be absent.

Run 1 · Revision AFailed · retained
OrderDateResult
a3Sep 30Outside range
a1Oct 1Expected
a2Oct 2Expected

Failed assertion: returned IDs did not equal the approved expected IDs.

Run 2 · Revision BPassed with mocks
OrderDateCompany
a1Oct 1Alpha
a2Oct 2Alpha

The date-boundary correction changed the candidate. Run 2 checks the new revision; Run 1 cannot qualify it.

Company isolation No Beta rows

Viewer handler 403

Source checks · synthetic rows · mocked database

Browser interaction is not exercised.

Source-check producer, synthetic data and mocked database boundary are part of this illustrative result. Revision labels are examples, not real commit IDs.

Illustrative local interaction. No Slack message, agent execution, GitHub PR or deployment is performed.

Export orders · Check coverage

TargetExample coverage
Date / company exportSource function with synthetic rows and mocked database
Viewer accessHandler check with synthetic role context
Code and security reviewSeparate read-only review sessions for Revision B
Browser / device interactionNot exercised
Live services / production dataNot exercised

A mock-scoped plan can proceed with this disclosure. If a required check needs a qualified runtime, missing that runtime remains unresolved.

Illustrative local interaction. No Slack message, agent execution, GitHub PR or deployment is performed.

Draft PR · Export filtered orders

Draft · task/export-orders → mainExample Revision B

Filter CSV export by the selected company-local dates and current company; reject viewers in the export handler.

src/orders/export.ts · illustrative excerpt
+ if (actor.role === "viewer") return forbidden();
- const rows = await listOrders({ companyId });
+ const range = companyDateRange(from, to, timezone);
+ const rows = await listOrders({ companyId, range });
  return ordersToCsv(rows);

Expected source-check CSV output · synthetic data

id,date,company
a1,2026-10-01,Alpha
a2,2026-10-02,Alpha

Run 1 / Revision A: date check failed · retained

Run 2 / Revision B: 3 selected checks passed with mocks

Code review: passed for B · separate read-only session

Security review: passed for B · separate read-only session

Source checks · synthetic rows · mocked database

Browser interaction is not exercised.

The diff, CSV and review statuses are illustrative, not recorded artifacts. The team reviews and merges in GitHub.

Read the actual PR workflow

Illustrative local interaction. No Slack message, agent execution, GitHub PR or deployment is performed.

Example diff