Learns your codebase.
Cites every claim.
Rupic keeps a living map of how your code is built and works from it, in whichever tool the work turns up in. Everything it says points at the lines behind it.
01
It reads the codebase first
Before Rupic answers anything it builds a picture of how your code is actually put together, section by section, with the lines each claim rests on. A push invalidates the parts it touched, so the picture stays true instead of ageing.
- Written once, corrected by every push
- A citation that does not resolve is rejected, not published
- The same pages your team reads, and can publish
Presigned uploads
A client never holds a bucket credential. The API signs a URL that expires, and the client uploads straight to storage with it.
02
Then it works from what it read
Every pull request and issue is ranked and labelled as it arrives, and a review runs against a real checkout rather than a diff in isolation. Findings point at lines, and a re-review answers the change instead of repeating itself.
- Rank, stage, type and packages, all derived
- Findings carry the lines behind them
- Prior findings are carried forward, not restated
- #812Retry the upload when the presigned URL expiresBugfixNeeds reviewR0+64 −12 · 4 filesapi, storage
- #809Split the settings panel into its own routeRefactorAwaiting authorR2+210 −188 · 11 filesweb
- #804Document the webhook replay procedureDocsReadyR4+38 −2 · 1 filesdocs
03
And you can check all of it
Hand over an issue and Rupic opens a draft pull request. Nothing merges on its own, nothing goes public without someone promoting it, and every run is written down as the steps it took and the evidence it used.
- Draft pull requests, never a silent merge
- Publishing is a person's decision, page by page
- An append-only record of every action taken
- Cloned acme/api at 4f2ab1c
- Read 18 files, ran the storage suite
- Opened draft pull request #815
A review that reads like a colleague wrote it
A verdict, the findings that justify it, and the lines each one rests on. Rupic answers in your repository's own vocabulary because it learned that vocabulary first.
The retry reuses the expired URL rather than minting a new one, so every attempt after the first fails the same way.
The expiry is set when the URL is signed, and the retry path never returns to the signer.
Wherever the work turns up
The codebase is the thing Rupic understands. Where you happen to discuss it is a surface, and every surface lands in the same record and obeys the same approvals.
GitHub
Pull requests, issues, reviews and checks. Rupic reaches them through an app you install and can revoke.
Slack
Ask in a thread and the work starts there, with the same approvals and the same record behind it.
Linear
Issues delegated to Rupic come back as a draft pull request, with the ticket kept in step.
Your own tools
Register an MCP server and its tools join the ones Rupic already has, scoped to your workspace.
Where it runs
Agent work in a disposable sandbox
No database credentials or signing key ever reach it
Nothing merges, posts or publishes without a person
An append-only record of every action taken