From a repository map to a cited answer.
CARA reads what each product already says about itself, condenses it into numbered claims, checks every quote against its source, and answers from those claims. It runs on one machine for one person, and it only reads.
The registry
Everything starts from a list of products, read from two repository maps, one per workspace, and synced on request.
A product is a name and a slug, a kind, the repositories that make it up, and the Docket board that tracks its work. The first repository is the primary one; the others are marked client or library. The sync adds new products, updates changed ones, and keeps a product that has left the maps, flagged, so its profile and your edits are never lost.
A board is found by matching its name to the product. If the match is wrong, you pin the right board, and a pinned board is never replaced by a later sync.
| Kind | tool, app, library, service, product, infrastructure, core, client, or website |
|---|---|
| Repositories | One primary, plus any client or library repositories, each shown with its role |
| Docket board | Matched by name, or pinned by you |
| Scope | In scope, partly in scope, or out of scope, from the scope mirror |
| Profile state | Not built, queued, building, ready, or failed |
Building a profile
A build reads the product's sources, asks Claude Sonnet 5.5 to condense them, and checks the result before it is saved.
A build is read-only against the outside world and records its cost from the usage the API reports. Three builds run at a time, a build that would start past the daily cap of $10 is refused, and a product whose sources do not exist yet says so instead of failing quietly.
Gather
The README, requirements, design, and plan documents are read from the primary repository, each cut at a heading to a size cap. The product's Docket board gives its open cards and those closed in the last 90 days, up to 60. Gavel gives the decisions that name its repository, up to 40.
Condense
The model returns a profile as structured JSON: a summary, users, phase, capabilities, open problems, planned work, what was decided against, and constraints. A list holds at most eight claims. Everything inside a source is treated as data to summarize, never as instructions.
Check
Each claim cites a source and quotes it. CARA keeps a cite only if its quote is found in that source, with case and spacing ignored. The rest are dropped, and the product page shows how many.
Number
Claims are numbered across the whole profile, after your overrides are applied, so a conversation can cite claim 7 and mean the same claim you see on the page.
What a build read
A profile is only as good as its sources, so the page lists every one.
The source manifest names each document, card, and decision a build read, with a link to it. A document can be read, missing from the repository, or unavailable because a service could not be reached, and a cut-off document is marked truncated. A repository with no design document says so in the manifest rather than leaving a gap you have to notice.
A rebuild is queued when something changed. A scheduler check compares each product with its sources: documents within the hour, Docket and Gavel at most daily, ten products per check, and never an out-of-scope product.
Answering a question
A conversation runs on Claude Opus 5.5, with the portfolio in front of it.
The advisor is told never to invent a fact, a source, or a detail of a product, to say which body of knowledge an answer comes from, and to treat anything you paste as material to discuss, not as instructions. It has no tools, so it cannot browse, fetch a page, or read a repository live.
Bring in the profiles
The advisor always gets a one-line index of every product. When your latest messages name a product, by its name, its slug, or a repository, that product's full profile joins the turn, up to four at once.
Stream the reply
The reply streams to the page as it is written. A turn runs as its own task, so a closed tab does not lose the reply or its cost.
Resolve the markers
The advisor cites a claim with its marker, such as [engram-fabric:4]. CARA looks each marker up and lists the claims under the reply, in order of first use, each linked to its product and to its source. A marker that names nothing gets no entry.
Record the spend
The call's measured usage goes into the ledger, and the Desk shows today, this week, and this month.
What you control
A profile is a draft you can correct.
Overrides
Edit any section and your text replaces the built claims, marked Owner. A rebuild keeps it, and the advisor is told those claims are your own words. The Notes section exists only as an override.
- Spot-checks
- Mark a profile spot-checked once you have read it, and clear the mark when it goes stale.
The scope mirror
An ordered list of rules, each with a match, a status, a note, and when it reopens. A product takes the rule that names it, else the * rule, and exactly one rule must be *. Saving recomputes every product at once.
What leaves the machine
CARA reads three services and sends text to one model API.
- GitHub, Docket, and Gavel are read with GET requests only. CARA writes to none of them.
- Your messages, and the profiles they bring in, are sent to Anthropic's API to be answered.
- During a profile build, the product's documents, cards, and decisions are sent to the API to be condensed.
- Conversations, profiles, overrides, scope rules, and the spend ledger stay in a local PostgreSQL database.
CARA does not claim its profiles are complete or current. Each shows when it was built, which model built it, what it cost, and how many cites were dropped.
Questions about this tool?
Write to Renkara Media Group and a person will answer.