Tickets in. Reviewed pull requests out.
Orchwright gives your team AI members that plan, build, test and review, each on a locked-down machine of its own. Your people answer their questions, approve every plan and merge every change.
Tickets in Jira, Azure Boards or Orchwright · Code on Azure DevOps or GitHub · Sign-in with Microsoft
- 0credentials to your tracker, repository or Teams held by the AI
- 1isolated machine for each AI member
- 2+independent reviews of every plan, and of every change before its pull request
A developer assigns the ticket
Two labels on the ticket, or one click in Orchwright. The member checks for new work every five minutes.
Let customers save a cart for later
Signed-in customers save their cart and come back to it on any device. A saved cart keeps for 30 days.
- Save from the cart page
- Open a saved cart on any device
- Saved carts expire after 30 days
Questions go on the ticket
When a requirement is unclear, the member asks on the ticket and recommends an answer.
Should a saved cart keep the prices it was saved with, or show current prices?
Recommended: current prices, with a note on each item whose price has changed.
The team answers
Accept the recommendation or give another answer in a comment. The member then continues on its own.
Should a saved cart keep the prices it was saved with, or show current prices?
Recommended: current prices, with a note on each item whose price has changed.
Agreed. Please use current prices, with the note.
A reviewed plan
The plan states what changes for users and the decisions taken. At least two independent reviews check it against the code before anyone is asked to approve it.
What changes for users
- A Save for later button on the cart page
- Saved carts on the account page, on any device
- Current prices, with a note on each item whose price has changed
Decisions
- A saved cart expires after 30 days
- One saved cart per customer
How it is checked
dotnet test --filter SavedCart and a browser check of the cart pageThe plan is approved
Nothing is built until the plan is approved from the project's owner account. Anyone can request changes first. A one-sentence change a trusted account labels simple skips the plan, but not the reviews.
Plan approved.
Built and tested
Each code commit is accepted only after the commit reviewer approves exactly what is staged. The build and tests run after every code stage, and when the change affects what users see, a browser check captures screenshots.
- branch feature/SHOP-482-save-cart
- + SavedCart table and its migration
- commit review: approved
- commit 3e1f2a4
- + Save for later, account page, 6 tests
- commit review: approved
- commit 9b07c1d
- build succeeded · 148 tests passed · lint clean
- browser check: 3 screenshots captured
Independent code reviews
Two full reviews of the whole change, each by a session that did not write it. Your branch rules, your protected paths and a check for the member's own secrets run before anything is pushed.
Saving twice created two saved carts; the plan allows one per customer.
Full change reviewed again; all earlier findings are resolved.
Pull request ready by morning
The build passes, and the quality gate where the project has one. Screenshots of what users see are attached, and the description covers what changed and how it was verified.
SHOP-482 Let customers save a cart for later
- Build succeeded
- Quality gate passed
- Two plan reviews and two code reviews
A person merges
Reviewers comment as they would for a colleague, and the member addresses every thread from the reviewers you trust. Only a person merges; the member then resolves the ticket and proposes lessons learned.
Please show the previous price in the note as well.
Done in 5c2d9e0: the note now shows the previous and the current price.
Thread resolvedYour team keeps every decision
The member does the work in between. Three decisions stay with your team, in the tools you already use.
- On the ticket
Answer questions
Each question comes with a recommended answer, or the reason there is none. Accept it, or answer differently.
- On the ticket
Approve the plan
With a comment from the project's owner account, or with one click when the tickets are kept in Orchwright. Only an approval of the latest version of the plan counts.
- In the pull request
Review and merge
Your reviewers comment as usual and the member addresses every thread from the reviewers you trust. Only a person can merge.
Contained by design
Six layers of control around the AI, none of which it can disable. Built for code that matters; the members run on your own infrastructure.
- No credentialsThe AI holds no credentials for your tracker, repository or Teams, and not its own model token, which a gateway on the machine keeps. The pipeline around it makes those calls. Within its reach are only its own test environment's credentials: disposable test users, the test tenant's app and the Azure resources you set aside for it.
- Isolated machineEach member runs on its own locked-down VM. The AI's network ends at that machine, without DNS; beyond it, only the hosts you list for your application and its own Azure resources, through a proxy. Packages come from read-only mirrors.
- Enforced controlsManaged settings that no run can disable check every shell command. Each code commit is accepted only after the commit reviewer approves exactly what is staged.
- Pre-push checksBefore anything is pushed: your branch rules, your protected paths (changes to build pipelines and the paths you name are refused) and a check that none of the member's own secrets is in the change. The build and tests must pass before the work goes on to review.
- Independent reviewsAt least two reviews of every plan, and of every change before its pull request goes out, each by a session that did not write it. Later changes are reviewed again before they are pushed.
- PeopleOnly trusted accounts can assign tickets. Plans are approved from the project's owner account (in Orchwright, by its editors and admins), unless a project turns plan approval off. Only a person can merge.
Around the clock, with people in the loop
Members can work nights and weekends, or only the hours you set. While a ticket waits for a person, the member moves on to the next one, and by default it takes no new ticket while two of its pull requests await review, or while it has three open tickets.
- AI member at work
- A person answers, approves or comments
- A person merges
- An example day of three members on one project
After the pull request
The member stays with its change until it is merged, and beyond.
- Failed buildsIt analyses a failed build or quality gate and fixes it, in up to two attempts, then escalates to a person.
- Review commentsIt addresses every thread from the reviewers you trust and marks each one fixed or open, after an additional review of its changes, for up to three rounds.
- Release fixesA fix to a release branch is ported to develop and reviewed again.
- Ticket closureThe ticket is resolved in its tracker once the change is merged.
- Lessons learnedIt proposes rules for future tickets in a separate draft pull request, in repositories that keep rules by area.
For the whole team
One place to follow every member's work.
- The boardEvery ticket's progress and live activity, what needs a person, and what is ready to merge.
- MetricsTime and usage per stage and per ticket.
- Microsoft sign-inPeople sign in to the Orchwright app with their Entra ID accounts, and each project's admins decide there who can view it and who can configure it.
- Teams notificationsItems that need a person or look wrong, and a weekly summary every Monday.
- Members connect outEach member connects out to the Orchwright app; the app never connects in to a member.