DeliveryLens

Problem: the two sources describe the world at different scales. The financial documents describe a company with thousands of customers; the operational data describes a handful of projects and a small team. "How many people do we have?" therefore has two different correct answers depending on which source you ask.

Implementation: counts and rates come from SQL; prose comes from the corpus. The assistant always states which source it used, and it never adds a document figure to a measured one. Mixing them would produce a number that is arithmetically fine and semantically meaningless.

Problem: an aggregate without its denominator invites a wrong reading. A zero is the worst case: "no GitHub account linked" and "did not write any code" look identical, but only one of them is a performance signal.

Implementation: get_overdue_tasks also reports how many tasks have no due date and so cannot be judged either way. rank_developers returns its formula, its time window, who was excluded, and a note on any row where one data source contributed nothing. The caveat travels with the number instead of living in documentation nobody reads.

Problem: a project manager will never have commits. Scoring everyone on one combined number puts every non-engineering role at the bottom by construction — that is a fact about the job, not about the person.

Implementation: code-shipping roles and non-code roles are ranked separately, and the charts are drawn per group rather than combined, since combining them would imply a comparison the data cannot support. Anyone with zero activity in the window is listed separately instead of ranked, because no data is not the same as bad performance.

Problem: plain vector search misses exact terms — a similarity search can skip straight past the passage that names a specific metric. Keyword search misses paraphrasing. Either one alone loses real answers.

Implementation: a pgvector/HNSW vector search and Postgres full-text search run together, their rankings are fused by reciprocal rank, and the combined list goes to a Cohere cross-encoder that reads the query and each passage together and scores them. The per-document cap is applied after reranking, so it never reorders results — it only stops one long document from taking every slot.

Problem: the reranker is a third-party API call on the critical path of every document question. If it is the single point of failure, a quota problem takes out retrieval entirely.

Implementation: if the Cohere call times out or errors, retrieval falls back to selecting a diverse set from the vectors it already has — no extra API call, just arithmetic, which is what matters when quota is the limiting factor. The result records which path ran (cross-encoder or diversity-fallback) and the note passed to the model changes accordingly, so a weaker answer gets flagged rather than shipped silently.

Problem: GitHub handles and tracker accounts follow no shared naming pattern. An automatic wrong link would silently attribute one person's work to someone else, and nothing downstream would catch it.

Implementation: the identity service scores likely pairs and surfaces the busiest unmatched accounts first, but it only ever suggests. A human confirms. Bot accounts are filtered on both handle and display name, since some bots commit under a normal-looking login but a [bot]-tagged name.

Problem: the auth provider allows open sign-up, so a successful login says nothing about whether you should see the data.

Implementation: a separate allowlist decides access, and an empty allowlist locks everyone out rather than letting everyone in by mistake. That check deliberately does not depend on the auth library or on the framework, so the preflight script can test it directly by feeding in bad addresses and confirming they are rejected.

One provider streams a single tool call in fragments, each chunk tagged with a position index. Another sends multiple complete calls that all report the same position, distinguished only by an id. Keying purely by position concatenated two calls into one broken JSON string, which the provider then rejected with an unhelpful 400. The fix keys by call id when one is present, falling back to the position index only for a continuation of a call already in progress — which covers both providers' behaviour.

A lot of work lived on personal branches that were never merged, so syncing only the default branch missed most of it. The first attempt walked the full history of every branch on every sync, which made the rate-limit problem worse rather than better. The actual fix: sync the default branch first so its history is already stored, then skip any branch whose latest commit is already in the database.

get_overdue_tasks filtered its results by project but computed the "how many tasks have due dates" total against the whole workspace — so "6 overdue out of 35 with due dates, out of 51 total" mixed one project's overdue count with the entire organisation's task count. Every number was correct on its own; together they were misleading.

Separately, renameConversation and deleteConversation checked ownership correctly in their SQL, then decided success with result.length > 0. TypeORM returns [rows, affectedCount] for updates and deletes, so that check was always true regardless of who owned the row. Reading the code would not have caught either bug. Tests that asked "does the denominator match the filter?" and "can another user delete this?" found both immediately.