@doist/doistbot-cli 1.0.12 → 1.0.13

package/dist/config.js

@@ -29,7 +29,7 @@ const ALL_REVIEW_FOCUSES = [
     'standards',
 ];
 const OPENROUTER_REVIEW_MODELS = ['deepseek', 'zai'];
-const CLI_GEMINI_REVIEW_MODEL = 'gemini-3.7-flash';
+const CLI_GEMINI_REVIEW_MODEL = 'gemini-3.8-flash';
 function createCliGeminiCredential(apiKey) {
     return {
         apiKey,

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@doist/doistbot-cli",
-    "version": "1.0.12",
+    "version": "1.0.13",
     "description": "Local self-review CLI for Doistbot",
     "type": "module",
     "main": "dist/index.js",
@@ -42,8 +42,8 @@
     "dependencies": {
         "@earendil-works/pi-ai": "0.85.1",
         "@earendil-works/pi-coding-agent": "0.85.1",
-        "@inquirer/checkbox": "5.2.4",
-        "@inquirer/password": "5.2.1",
+        "@inquirer/checkbox": "5.2.5",
+        "@inquirer/password": "5.2.2",
         "@napi-rs/keyring": "1.3.0",
         "@opentelemetry/api": "1.9.1",
         "ajv": "8.20.0",

package/sandbox/dist/core/pi.js

@@ -63,7 +63,7 @@ export const DEFAULT_OPENROUTER_MODELS = {
     zai: 'z-ai/glm-5.3-flash',
 };
 // Gemini flash fallback model.
-export const DEFAULT_GEMINI_FLASH_MODEL = 'gemini-3.7-flash';
+export const DEFAULT_GEMINI_FLASH_MODEL = 'gemini-3.8-flash';
 export const MAX_PI_THINKING_BY_PROVIDER = {
     deepseek: 'high',
     gemini: 'high',

package/sandbox/dist/core/repository-map.js

@@ -1 +1 @@
-export { APP_LABEL_ALIASES, APP_TO_ROUTE_SELECTORS, findIssueRoute, findRepositoryRoutes, findRepositoryTarget, PRODUCT_LABEL_ALIASES, PRODUCT_ROUTES, RESOLUTION_PRECEDENCE, TEAM_LABEL_ALIASES, TEAM_TO_ROUTE_SELECTORS, } from 'doistbot-issue-routing';
+export { APP_LABEL_ALIASES, APP_TO_ROUTE_SELECTORS, findIntegrationRoute, findIntegrationRoutes, findIssueRoute, findRepositoryRoutes, findRepositoryTarget, INTEGRATION_LABEL_ALIASES, INTEGRATION_ROUTES, PRODUCT_LABEL_ALIASES, PRODUCT_ROUTES, RESOLUTION_PRECEDENCE, TEAM_LABEL_ALIASES, TEAM_TO_ROUTE_SELECTORS, } from 'doistbot-issue-routing';

package/sandbox/dist/tasks/issue-summarize/context.js

@@ -11,6 +11,7 @@ export function parseSummarizeContext(env = process.env) {
         appId: requiredEnv('APP_ID', env),
         privateKey: requiredEnv('PRIVATE_KEY', env),
         githubToken: requiredEnv('GITHUB_TOKEN', env),
+        geminiApiKey: requiredEnv('GEMINI_API_KEY', env),
         openRouterApiKey: requiredEnv('OPENROUTER_API_KEY', env),
         commentId,
         reactionId,

package/sandbox/dist/tasks/issue-summarize/model.js

@@ -1,9 +1,9 @@
 import { SpanStatusCode } from '@opentelemetry/api';
 import { logger } from '../../core/logging.js';
-import { buildPiImageContent, createPiInvoker, DEFAULT_OPENROUTER_MODELS } from '../../core/pi.js';
+import { buildPiImageContent, createPiInvoker, DEFAULT_GEMINI_FLASH_MODEL, DEFAULT_OPENROUTER_MODELS, } from '../../core/pi.js';
 import { withPhase } from '../../core/tracing.js';
 const ISSUE_SUMMARIZE_TIMEOUT_MS = 5 * 60 * 1000;
-const ISSUE_SUMMARIZE_MULTIMODAL_MODEL = 'google/gemini-2.5-pro';
+const ISSUE_SUMMARIZE_MULTIMODAL_MODEL = DEFAULT_GEMINI_FLASH_MODEL;
 const SUMMARIZE_TEXT_PROVIDER = 'zai';
 // Single source of truth: inherit the repo-wide Z.ai default so a default-model
 // bump in core/pi.ts moves summarize too, and the executed model matches the
@@ -14,7 +14,7 @@ const SUMMARIZE_MULTIMODAL_PROVIDER = 'gcp.gemini';
 // `issue-summarize.model`; each chunk summary uses `issue-summarize.chunk`.
 const SUMMARIZE_MODEL_PHASE = 'issue-summarize.model';
 const SUMMARIZE_CHUNK_PHASE = 'issue-summarize.chunk';
-export function createIssueSummarizeModel(apiKey) {
+export function createIssueSummarizeTextModel(apiKey) {
     return createPiInvoker({
         provider: 'zai',
         apiKey,
@@ -23,6 +23,15 @@ export function createIssueSummarizeModel(apiKey) {
         capabilityPreset: 'read-only',
     });
 }
+export function createIssueSummarizeMultimodalModel(apiKey) {
+    return createPiInvoker({
+        provider: 'gemini',
+        apiKey,
+        piProviderId: 'google',
+        cwd: process.cwd(),
+        capabilityPreset: 'read-only',
+    });
+}
 async function invokeIssueSummarizeTextModel({ model, prompt, phaseName, }) {
     return withPhase(phaseName, {
         'gen_ai.operation.name': 'chat',
@@ -115,11 +124,11 @@ async function invokeMultimodalSummarizeModel({ model, prompt, mediaImages, }) {
         }
     });
 }
-export async function invokeIssueSummarizeModel({ model, prompt, mediaImages, }) {
+export async function invokeIssueSummarizeModel({ textModel, multimodalModel, prompt, mediaImages, }) {
     if (mediaImages.length === 0) {
         logger.info('Using text-only summarize model request');
         return await invokeIssueSummarizeTextModel({
-            model,
+            model: textModel,
             prompt,
             phaseName: SUMMARIZE_MODEL_PHASE,
         });
@@ -127,12 +136,20 @@ export async function invokeIssueSummarizeModel({ model, prompt, mediaImages, })
     logger.info('Using multimodal summarize model request', {
         mediaImages: mediaImages.length,
     });
-    const multimodal = await invokeMultimodalSummarizeModel({ model, prompt, mediaImages });
+    const multimodal = await invokeMultimodalSummarizeModel({
+        model: multimodalModel,
+        prompt,
+        mediaImages,
+    });
     if (multimodal) {
         return multimodal;
     }
     // Multimodal failed — fall back to a separate text request (own model span).
-    return await invokeIssueSummarizeTextModel({ model, prompt, phaseName: SUMMARIZE_MODEL_PHASE });
+    return await invokeIssueSummarizeTextModel({
+        model: textModel,
+        prompt,
+        phaseName: SUMMARIZE_MODEL_PHASE,
+    });
 }
 function buildChunkSummaryPrompt({ chunk, chunkIndex, selectedChunkCount, totalChunks, }) {
     return `You are preparing an intermediate summary for a GitHub issue discussion.

package/sandbox/dist/tasks/issue-summarize/summarize.js

@@ -7,7 +7,7 @@ import { resolveWriteOctokit } from '../../core/shared.js';
 import { withPhase } from '../../core/tracing.js';
 import { parseSummarizeContext } from './context.js';
 import { buildMediaPromptImages, extractMediaReferences, formatMediaContext, inspectMediaReferences, } from './media.js';
-import { createIssueSummarizeModel, invokeIssueSummarizeModel, summarizeChunks } from './model.js';
+import { createIssueSummarizeMultimodalModel, createIssueSummarizeTextModel, invokeIssueSummarizeModel, summarizeChunks, } from './model.js';
 import { buildFallbackSummary, ensureStructuredSummary, stripVisualContextSection, } from './output.js';
 import { fillTemplate, loadPromptTemplate } from './prompt.js';
 import { buildThreadEntries, prepareThreadPrompt } from './thread.js';
@@ -41,7 +41,8 @@ function summarizeMediaInspectionStats(mediaInspections) {
 async function summarizeIssue({ ctx, issue, entries, mediaReferences, mediaInspections, }) {
     const template = loadPromptTemplate();
     const threadPrompt = prepareThreadPrompt(entries);
-    const summarizeModel = createIssueSummarizeModel(ctx.openRouterApiKey);
+    const textModel = createIssueSummarizeTextModel(ctx.openRouterApiKey);
+    const multimodalModel = createIssueSummarizeMultimodalModel(ctx.geminiApiKey);
     logger.info('Prepared summarize thread prompt', {
         entryCount: entries.length,
         chunked: threadPrompt.chunked,
@@ -50,7 +51,7 @@ async function summarizeIssue({ ctx, issue, entries, mediaReferences, mediaInspe
     });
     const threadContent = threadPrompt.chunked
         ? await summarizeChunks({
-            model: summarizeModel,
+            model: textModel,
             chunks: threadPrompt.chunks,
             totalChunks: threadPrompt.totalChunks,
         })
@@ -75,7 +76,8 @@ async function summarizeIssue({ ctx, issue, entries, mediaReferences, mediaInspe
         mediaImagesIncluded: mediaPromptImages.length,
     });
     const summary = await invokeIssueSummarizeModel({
-        model: summarizeModel,
+        textModel,
+        multimodalModel,
         prompt,
         mediaImages: mediaPromptImages,
     });

package/sandbox/dist/tasks/issue-triage/hero-group-map.js

@@ -1,5 +1,5 @@
 import { normalizeScopedLabelValue, scopedLabelValue } from '../../core/label-parsing.js';
-import { APP_LABEL_ALIASES, findIssueRoute, findRepositoryRoutes, findRepositoryTarget as findRoutingRepositoryTarget, PRODUCT_LABEL_ALIASES, PRODUCT_ROUTES, } from '../../core/repository-map.js';
+import { APP_LABEL_ALIASES, findIntegrationRoute, findIntegrationRoutes, findIssueRoute, findRepositoryRoutes, findRepositoryTarget as findRoutingRepositoryTarget, INTEGRATION_LABEL_ALIASES, PRODUCT_LABEL_ALIASES, PRODUCT_ROUTES, } from '../../core/repository-map.js';
 const HERO_GROUPS = {
     'android-hero': { key: 'android-hero', mention: '@Doist/android-hero' },
     'app-copy-hero': { key: 'app-copy-hero', mention: '@Doist/app-copy-hero' },
@@ -63,11 +63,18 @@ export function resolveHeroTeamSlug(target) {
 function resolveAppLabelAlias(value) {
     return APP_LABEL_ALIASES[normalizeScopedLabelValue(value)];
 }
+function resolveIntegrationLabelAlias(value) {
+    return INTEGRATION_LABEL_ALIASES[normalizeScopedLabelValue(value)];
+}
 export function isKnownHeroRoutingLabel(label) {
     const teamValue = scopedLabelValue(label, 'Team');
     if (teamValue && TEAM_LABEL_TO_HERO[normalizeScopedLabelValue(teamValue)]) {
         return true;
     }
+    const integrationValue = scopedLabelValue(label, 'Integration');
+    if (integrationValue && resolveIntegrationLabelAlias(integrationValue)) {
+        return true;
+    }
     const appValue = scopedLabelValue(label, 'App');
     if (!appValue) {
         return false;
@@ -91,6 +98,28 @@ function resolveProduct(labels) {
     }
     return products.size === 1 ? products.values().next().value : undefined;
 }
+function resolveIntegrationHeroKeys(labels) {
+    const product = resolveProduct(labels);
+    const heroKeys = new Set();
+    for (const label of labels) {
+        const integrationValue = scopedLabelValue(label, 'Integration');
+        if (!integrationValue) {
+            continue;
+        }
+        const integration = resolveIntegrationLabelAlias(integrationValue);
+        if (!integration) {
+            continue;
+        }
+        const route = findIntegrationRoute(integration);
+        // An integration from another product is not in scope for this issue, so
+        // it must not contribute a hero the repository resolver would never pick.
+        if (product && route.product !== product) {
+            continue;
+        }
+        heroKeys.add(route.heroTeam);
+    }
+    return heroKeys;
+}
 function resolveAppRouteHeroKeys(labels) {
     const routeIds = new Set();
     for (const label of labels) {
@@ -99,7 +128,9 @@ function resolveAppRouteHeroKeys(labels) {
             continue;
         }
         const appLabel = resolveAppLabelAlias(appValue);
-        if (appLabel && appLabel !== 'all') {
+        // `all` spans every route and `integration` names no route of its own —
+        // the accompanying `Integration:*` label supplies that hero instead.
+        if (appLabel && appLabel !== 'all' && appLabel !== 'integration') {
             routeIds.add(appLabel);
         }
     }
@@ -135,6 +166,13 @@ export function resolveHeroGroup(labels, primaryRepo) {
     if (teamHeroKeys.size > 1) {
         return null;
     }
+    const integrationHeroKeys = resolveIntegrationHeroKeys(labels);
+    if (integrationHeroKeys.size === 1) {
+        return HERO_GROUPS[integrationHeroKeys.values().next().value];
+    }
+    if (integrationHeroKeys.size > 1) {
+        return null;
+    }
     const appHeroKeys = resolveAppRouteHeroKeys(labels);
     if (appHeroKeys.size === 1) {
         return HERO_GROUPS[appHeroKeys.values().next().value];
@@ -143,7 +181,13 @@ export function resolveHeroGroup(labels, primaryRepo) {
         return null;
     }
     if (primaryRepo) {
-        const repositoryHeroKeys = new Set(findRepositoryRoutes(primaryRepo).map((route) => route.heroTeam));
+        // A repository carried by both a product route and an integration route —
+        // todoist-macos owns the Safari extension, for example — keeps the product
+        // route's hero, so integration routes only cover integration-only repos.
+        const productRoutes = findRepositoryRoutes(primaryRepo);
+        const repositoryHeroKeys = new Set(productRoutes.length > 0
+            ? productRoutes.map((route) => route.heroTeam)
+            : findIntegrationRoutes(primaryRepo).map((route) => route.heroTeam));
         if (repositoryHeroKeys.size === 1) {
             return HERO_GROUPS[repositoryHeroKeys.values().next().value];
         }

package/sandbox/dist/tasks/issue-triage/resolution.js

@@ -12,10 +12,13 @@ export async function resolveTriageScope(params) {
             parsed_products: result.parsedLabels.productLabels,
             parsed_apps: result.parsedLabels.appLabels,
             parsed_teams: result.parsedLabels.teamLabels,
+            parsed_integrations: result.parsedLabels.integrationLabels,
             matched_routes: result.matchedRoutes,
+            matched_integrations: result.matchedIntegrations,
             unknown_product_labels: result.parsedLabels.unknownProductLabels,
             unknown_app_labels: result.parsedLabels.unknownAppLabels,
             unknown_team_labels: result.parsedLabels.unknownTeamLabels,
+            unknown_integration_labels: result.parsedLabels.unknownIntegrationLabels,
         });
         span.setAttributes({
             'resolution.status': result.status,

package/sandbox/src/review/prompts/ai-internal-tools.md

@@ -202,7 +202,7 @@ flowchart TD
     Agent --> NonSensitive
 ```
 
-> Note: see [`examples/internal-ai-service/`](https://github.com/Doist/platform-standards/tree/main/examples/internal-ai-service/) for the server-side service and [`examples/local-cli/`](https://github.com/Doist/platform-standards/tree/main/examples/local-cli/) for the thin local CLI. The example implements Zendesk only; the same pattern applies to Sentry/Datadog.
+> Note: see [`examples/internal-ai-service/`](https://github.com/Doist/standards/tree/main/examples/internal-ai-service/) for the server-side service and [`examples/local-cli/`](https://github.com/Doist/standards/tree/main/examples/local-cli/) for the thin local CLI. The example implements Zendesk only; the same pattern applies to Sentry/Datadog.
 
 ### How to read this diagram
 
@@ -236,9 +236,9 @@ Think of the diagram as three separate rooms, each with different access rules:
 
 1. **Remove** the direct connections to Zendesk, Sentry, and Datadog from your local AI setup.
 
-2. **Set up an internal service** (the Platform team can help) that fetches and cleans data before passing it to the AI — see [`examples/internal-ai-service/main.go`](https://github.com/Doist/platform-standards/tree/main/examples/internal-ai-service/main.go) for a working reference. It should only return what's needed to answer the question — never raw personal information.
+2. **Set up an internal service** (the Platform team can help) that fetches and cleans data before passing it to the AI — see [`examples/internal-ai-service/main.go`](https://github.com/Doist/standards/tree/main/examples/internal-ai-service/main.go) for a working reference. It should only return what's needed to answer the question — never raw personal information.
 
-3. **Point your local tool at that internal service** instead of at the third-party tools directly — see [`examples/local-cli/main.go`](https://github.com/Doist/platform-standards/tree/main/examples/local-cli/main.go) for a working reference.
+3. **Point your local tool at that internal service** instead of at the third-party tools directly — see [`examples/local-cli/main.go`](https://github.com/Doist/standards/tree/main/examples/local-cli/main.go) for a working reference.
 
 4. **Keep your Github, Twist, and Outline connections as-is** — those don't hold user personal data, so they're fine to use directly.
 

package/sandbox/src/review/prompts/backend-repository-standards.md

@@ -0,0 +1,102 @@
+# Standard: Backend Repositories
+
+| 📄 Document Type | Team Standard (Backend)                                                                                                   |
+| :--------------- | :------------------------------------------------------------------------------------------------------------------------ |
+| 🎯 Status        | Draft                                                                                                                     |
+| 👤 Owner         | Felipe Rodrigues                                                                                                          |
+| 📅 Last Reviewed | 2026-09-08                                                                                                                |
+| 🗂️ References    | [Standard: Service Production Readiness](https://handbook.doist.com/doc/standard-service-production-readiness-qgNRng8TJx) |
+| 📌 Version       | 0.2                                                                                                                       |
+
+This standard applies to **all backend repositories at Doist, regardless of language or current ownership.** Today that means `Todoist` and other repositories already owned by the Backend team as well as newer backend services such as `todoist-id` and `automations` - currently developed by squads, and expected to come under Backend team ownership over time.
+
+Meeting this standard is part of what makes that handover possible.
+
+## Tests
+
+Every repository must have automated tests. A repository with no tests is not production-ready.
+
+- Tests must run in CI on every pull request.
+- Tests must run in CI on every merge to `main`.
+- Deployments must be gated on tests passing. In GitHub Actions, the deploy job must depend on the test job — via `needs: test` in the same workflow, or by invoking the test workflow as a reusable workflow and depending on that job. A deploy that races its own test run is not gated.
+
+## Branch Protection
+
+Tests that exist but are never enforced provide false confidence. The `main` branch must be protected:
+
+- Changes land via pull request — no direct pushes to `main`.
+- Test, lint, and type-check jobs are configured as **required status checks**, so a PR cannot merge while they fail or haven't run.
+
+## Code Quality Hooks
+
+- Pre-commit hooks must be used to enforce formatting, linting, and repo hygiene. The runner is language-specific: [prek](https://prek.j178.dev) in Python repositories, [husky](https://typicode.github.io/husky/) in JavaScript/TypeScript ones.
+- The same checks must also run in CI on every pull request and merge to `main` (e.g. `prek run --all-files`, or the `npm` scripts the hooks call). Hooks that only run locally are advisory; developers can skip or misconfigure them.
+
+## README
+
+Every repository must have a `README.md` with at least:
+
+- Project description
+- How to run the project locally
+- How to run tests
+- How to deploy the project
+
+## Dependency Updates
+
+Automated dependency updates (Renovate or Dependabot) must be enabled. Update PRs go through the same CI gates as any other change.
+
+## Python Requirements
+
+Python repositories must use the following stack (mirroring the main Todoist codebase):
+
+| Concern                         | Tool                         |
+| ------------------------------- | ---------------------------- |
+| Project & dependency management | `uv`                         |
+| Minimum Python version          | 3.13                         |
+| Tests                           | `pytest`                     |
+| Linting & formatting            | `ruff check` + `ruff format` |
+| Git hooks                       | `prek`                       |
+| Type checking                   | `mypy` and `pyrefly`         |
+| Dead code detection             | `vulture`                    |
+
+- Dependencies in `pyproject.toml` must be pinned with upper bounds (`>=X.Y,<X+1`).
+- Type hints are mandatory on production code.
+
+## JavaScript / TypeScript Requirements
+
+JavaScript and TypeScript repositories must use the following stack (mirroring `automations`, our newest backend TS project):
+
+| Concern                         | Tool                                            |
+| ------------------------------- | ----------------------------------------------- |
+| Language                        | TypeScript                                      |
+| Runtime                         | Node.js — current LTS major                     |
+| Project & dependency management | `npm` (workspaces for monorepos)                |
+| Tests                           | `vitest`                                        |
+| Linting & formatting            | `oxlint` + `oxfmt`                              |
+| Git hooks                       | `husky`                                         |
+| Type checking                   | `tsc --noEmit`, exposed as `npm run type-check` |
+
+- Production code must be TypeScript. Plain JavaScript only where a tool requires it.
+- The Node version must be pinned in `engines` and in a version file (`.node-version`, which `actions/setup-node` reads via `node-version-file`; `.nvmrc` alongside it if people use `nvm`). Version files pin Node only, so pin the npm major in `engines` as well.
+- `engine-strict=true` must be set in `.npmrc`. Without it npm only warns on an `engines` mismatch, and the pins above do not actually stop local, CI and container builds from drifting apart.
+- Dependencies in `package.json` must be pinned to exact versions, with the lockfile committed.
+- The TypeScript config must extend the shared `@doist/tsconfig` base and keep `strict` on.
+
+## Related Documents
+
+This standard complements the Doist-wide [Service Production Readiness](https://handbook.doist.com/doc/standard-service-production-readiness-qgNRng8TJx) standard: that one covers how a service must _behave_ in production while this one covers the baseline health a _repository_ must have before its code reaches production.
+
+Related engineering-wide guidelines:
+
+- [GitHub Repository Guidelines](https://handbook.doist.com/doc/github-repository-guidelines-iJNZ0D2vLN)
+- [Automate linting and formatting](https://handbook.doist.com/doc/automate-linting-and-formatting-omSECLKiJI)
+- [Keeping dependencies up-to-date](https://handbook.doist.com/doc/keeping-dependencies-up-to-date-Qf28E929N5)
+
+---
+
+## Open questions/Possible future expansions to the Standard
+
+- Type checkers: Todoist currently runs `mypy`, `ty`, and `pyrefly` in parallel, but that is an evaluation state, not a recommendation (see [Choosing type checkers for Todoist](https://comms.todoist.com/69/ch/BH4VumxwScG1NAiomtcBq/t/CbVia3jW38koSRmHWXSeV/)). A June 2026 attempt to remove mypy was reverted after it left real gaps (pyrefly's legacy config disabled core checks; ty lacks Pydantic support). Current direction: pyrefly in strict mode is the candidate primary, mypy stays as the mature baseline, ty is a secondary bet pending Pydantic support. `mypy` + `pyrefly` therefore remains the right baseline for new repos; revisit when ty matures.
+- Maybe create a [Copier](https://copier.readthedocs.io/en/stable/) template for Python repos — and an equivalent for TS ones — so new services start compliant? Or even a small template repo with “sane defaults” for our tooling.
+- Dead code detection has no JS/TS entry yet. Python repos run `vulture`; `knip` is the closest equivalent, but nothing runs it today.
+- Define the baseline ruff rule set / prek hook list based on the Todoist codebase (its `prek.toml` is a good starting point: ruff, standard pre-commit-hooks, shellcheck, hadolint, mypy/type checkers, vulture on pre-push).

package/sandbox/src/review/prompts/outline-map.json

@@ -1,22 +1,26 @@
 {
     "workload-placement.md": {
-        "id": "26dac3b3-fc42-4e03-a559-ccff6b980557",
-        "url": "https://handbook.doist.com/doc/standard-workload-placement-j2Xe36eQar"
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-workload-placement-"
     },
     "secrets-management.md": {
-        "id": "c0daf063-8120-4ace-a26c-fd6f64656324",
-        "url": "https://handbook.doist.com/doc/standard-secrets-management-wbKmIfrtgr"
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-secrets-management-"
     },
     "ai-internal-tools.md": {
-        "id": "02f9d168-f91a-4632-88d9-4d25f4b33063",
-        "url": "https://handbook.doist.com/doc/standard-internal-ai-tools-zU0fqnhpmC"
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-internal-ai-tools-"
     },
     "service-production-readiness.md": {
-        "id": "1f4fba5d-9ca6-43bb-97b5-cc0ee8aad3cc",
-        "url": "https://handbook.doist.com/doc/standard-service-production-readiness-qgNRng8TJx"
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-service-production-readiness-"
     },
     "observability-standard.md": {
-        "id": "e9fe25ca-453d-40b2-b4b0-ef4cdcb5f030",
-        "url": "https://handbook.doist.com/doc/standard-observability-vWRaOfitho"
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-observability-"
+    },
+    "backend-repository-standards.md": {
+        "id": "",
+        "url": "https://handbook.doist.com/doc/standard-backend-repositories-"
     }
 }

package/sandbox/src/review/prompts/service-production-readiness.md

@@ -49,7 +49,7 @@ All services must produce structured, meaningful logs.
 
 Logs should support operational debugging and monitoring.
 
-See the Observability standard for more details. TODO(artyom): add a link once it's finalized.
+See [the Observability standard for more details](https://handbook.doist.com/doc/standard-observability-vWRaOfitho).
 
 ## Configuration Management
 
@@ -59,7 +59,7 @@ Configuration must be provided via environment variables.
 - Env files are allowed only if variables can be overridden by the environment.
 - Secrets must come from environment variables or read directly from a secrets management service (AWS Secrets Manager).
 
-See the Secrets Management standard for more details. TODO(artyom): add a link once it's finalized.
+See [the Secrets Management standard for more details](https://handbook.doist.com/doc/standard-secrets-management-wbKmIfrtgr).
 
 ## State Persistence
 

package/sandbox/src/review/prompts/which-cloud-and-where-to-deploy.md

@@ -1,344 +0,0 @@
-# Platform Standard: Which Cloud & Where to Deploy
-
-| 📄 Document Type | Platform Standard                                                                                                                                            |
-| :--------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 🎯 Status        | Approved                                                                                                                                                     |
-| 👤 Owner         | Luciano Facchinelli                                                                                                                                          |
-| 📅 Last Reviewed | 2026-03-06                                                                                                                                                   |
-| 🗂️ References    | [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/), [GCP Architecture Framework](https://cloud.google.com/architecture/framework) |
-| 📌 Version       | 1.0                                                                                                                                                          |
-
-# Workload types
-
-## Remote State Services
-
-- **Definition**: Services that either store state in external systems (databases, caches, object storage) and don't require persistent local disk or doesn't have a state at all.
-  Containers are disposable and can be recreated without data loss.
-- **Typical use cases**:
-    - REST APIs
-    - Web applications
-    - Backend microservices
-
-## No State / Local State Services
-
-- **Definition**: Services that require persistent local disk storage and expect data to survive container restarts. These need node affinity and persistent volumes.
-- **Typical use cases**:
-    - Analytics database (i.e ClickHouse)
-    - Observability tool (i.e Langfuse)
-    - Self-hosted databases
-    - Message brokers with persistence
-- Runs a database or database-like system
-- Benefits from node affinity control for performance
-
-## Event-Driven / Short-Lived Tasks
-
-- **Definition**: Sporadic, short-duration tasks triggered by events that must complete within 15 minutes
-- **Typical use cases**:
-    - Webhooks
-    - Scheduled jobs
-    - Queue processors
-    - Glue code between services
-    - File processing triggers
-- Code must be small and optimized to reduce consumption from a resource perspective.
-- Cold starts can impact latency for infrequent calls
-- Not suitable for long-running or high-memory processes
-
-## Preview / Ephemeral Environments
-
-- **Definition**: Temporary, short-lived environments designed for testing, demos, and validation with a clear expiration
-- **Typical use cases**:
-    - PR preview deployments
-    - Demo environments
-    - Temporary test instances
-    - Feature branch testing
-- Excellent developer experience for fast iterations
-
-## Internal Tools (Low Traffic)
-
-- **Definition**: Internal-facing utilities and dashboards with low, predictable usage patterns accessed only by team members
-- **Typical use cases**:
-    - Admin dashboards
-    - Internal utilities
-    - Analytics dashboards
-    - Configuration management UIs
-    - Reporting tools
-- Low and predictable traffic patterns
-- Users are internal team members only
-- May or may not require access to production resources
-- Simpler reliability requirements than user-facing services
-
-## Batch Processing / ML Training
-
-- **Definition**: Large-scale data processing or machine learning workloads that run for extended periods, often on a schedule or ad-hoc basis
-- **Typical use cases**:
-    - Large batch data jobs
-    - ML model training
-    - Data pipeline processing
-    - One-off data migrations
-    - ETL jobs
-- Variable duration — can run for hours or days
-- Often requires burst compute capacity
-- May need GPU resources for ML workloads
-- Clear distinction between experimentation and production
-- **Note: Requires case-by-case evaluation based on requirements**
-
-# 1\. Purpose
-
-"Where should I deploy this?" and "Can I use GCP for this?" shouldn't require a Platform team consultation. This standard provides clear defaults so teams can move fast while maintaining operational consistency.
-
-These two decisions are tightly coupled—your cloud choice often constrains your compute options, and vice versa. We're treating them as one standard.
-
-## 2\. Scope
-
-This standard applies to:
-
-- All new services, tools, and workloads
-- Migrations of existing services to new compute platforms
-- Any infrastructure that runs production or production-adjacent workloads
-
-This does **not** prescribe:
-
-- How to configure specific services (separate runbooks)
-- Database or storage choices (separate standard)
-
----
-
-# Part A: Which Cloud
-
-## 3A. Standard
-
-### Default: AWS
-
-**All new production workloads MUST be deployed to AWS unless there's a documented exception.**
-
-AWS is our primary cloud. This means:
-
-- All production databases, queues, and storage
-- All user-facing services
-- All internal services that modifies production data
-
-### When GCP is Acceptable
-
-GCP may be used for:
-
-| Use Case                    | Rationale                                        | Examples                                    |
-| :-------------------------- | :----------------------------------------------- | :------------------------------------------ |
-| **BigQuery analytics**      | Best-in-class data warehouse, existing pipelines | Data team experiments, analytics dashboards |
-| **ML/AI experimentation**   | Vertex AI, Colab integration                     | Prototype ML models before productionizing  |
-| **One-off data processing** | Cost-effective for burst compute                 | Large batch jobs with clear end dates       |
-| **Cloud Run previews**      | Fast, cheap preview environments                 | PR preview deployments for web apps         |
-
-GCP is **NOT acceptable** for:
-
-- Services that need to access production databases directly
-- Anything requiring low-latency connections to AWS resources
-- User-facing production services
-- Long-running local state services
-
-### Multi-Cloud \= Complexity Tax
-
-Every service in GCP means:
-
-- Separate IAM, networking, and monitoring
-- Cross-cloud latency and data transfer costs
-- Split operational knowledge on the team
-- Harder incident response
-
-The bar for GCP should be: "AWS genuinely can't do this well" — not "GCP has a nicer UI for this."
-
-## 4A. Rationale
-
-**Why default to AWS?**
-
-- Operational consistency: one set of tools, dashboards, runbooks
-- Network topology: VPCs, peering, and security groups are already configured
-- Cost visibility: unified billing, tagging, and attribution
-- Team knowledge: everyone knows AWS; GCP expertise is spotty
-
-**Why allow GCP at all?**
-
-- BigQuery is genuinely better for our analytics use cases
-- Cloud Run is excellent for preview environments (fast, cheap, ephemeral)
-- Forcing everything into AWS would be dogmatic, not practical
-
----
-
-# Part B: Where to Deploy (Compute)
-
-## 3B. Standard
-
-### Decision Tree
-
-```mermaid
-%%{init: {'flowchart': {'curve': 'linear'}}}%%
-flowchart TB
- subgraph PartA["Part A: Cloud Selection"]
-        AWS[/"✅ AWS<br>(Primary Cloud)"/]
-        Q1{"Which Cloud?"}
-        GCP_Check{"GCP Use Case?"}
-        GCP[/"☁️ GCP Acceptable"/]
-  end
- subgraph GCP_No["🚫 GCP NOT Acceptable For"]
-    direction TB
-        N1["Production DB Access"]
-        N2["Low-latency to AWS"]
-        N3["User-facing Production"]
-        N4["Long-running local state"]
-  end
- subgraph PartB["Part B: Compute Platform Selection"]
-        ECS[/"📦 ECS Fargate<br>(Default)"/]
-        Q2{"What Type<br>of Workload?"}
-        EKS[/"☸️ EKS Kubernetes"/]
-        Lambda[/"⚡ Lambda"/]
-        Platform[/"🤝 Consult Platform Team"/]
-        CloudRun[/"🏃 Cloud Run"/]
-        Q3{"GCP Compute?"}
-  end
- subgraph Examples["📋 Examples"]
-    direction TB
-        Ex1["REST API → ECS Fargate"]
-        Ex2["ClickHouse → EKS"]
-        Ex3["Langfuse → EKS"]
-        Ex4["Webhooks → Lambda"]
-        Ex5["PR Previews → Cloud Run"]
-  end
- subgraph Exceptions["⚠️ Exception Process"]
-    direction TB
-        E1["1. Document rationale"]
-        E2["2. Post in Platform channel"]
-        E3["3. Get Platform approval"]
-  end
-    Start(["🚀 New Service/Workload"]) --> Q1
-    Q1 -- Default --> AWS
-    Q1 -- Exception Cases --> GCP_Check
-    GCP_Check -- BigQuery Analytics --> GCP
-    GCP_Check -- ML/AI Experimentation --> GCP
-    GCP_Check -- "One-off Data Processing" --> GCP
-    GCP_Check -- Preview Environments --> GCP
-    GCP_Check -- None of above --> AWS
-    GCP -. Check Restrictions .-> GCP_No
-    AWS --> Q2
-    GCP --> Q3
-    Q2 -- remote state<br>(API, Web App) --> ECS
-    Q2 -- local state<br>(Persistent Storage) --> EKS
-    Q2 -- "Event-driven<br>(under 15 min)" --> Lambda
-    Q2 -- Batch/ML Training --> Platform
-    Q3 -- Previews/Internal Tools --> CloudRun
-    ECS -.-> Ex1
-    EKS -.-> Ex2 & Ex3
-    Lambda -.-> Ex4
-    CloudRun -.-> Ex5
-    E1 --> E2
-    E2 --> E3
-    Q2 -- Doesn't fit? --> Exceptions
-
-     AWS:::aws
-     Q1:::decision
-     GCP_Check:::decision
-     GCP:::gcp
-     ECS:::aws
-     Q2:::decision
-     EKS:::aws
-     Lambda:::aws
-     CloudRun:::gcp
-     Q3:::decision
-    classDef aws fill:#FF9900,stroke:#232F3E,color:#232F3E
-    classDef gcp fill:#4285F4,stroke:#174EA6,color:white
-    classDef decision fill:#f9f,stroke:#333,stroke-width:2px
-    classDef compute fill:#90EE90,stroke:#228B22
-```
-
-### Compute Platform Characteristics
-
-| Platform             | Best For                                   | Avoid When                                   | Notes                                                  |
-| :------------------- | :----------------------------------------- | :------------------------------------------- | :----------------------------------------------------- |
-| **ECS Fargate**      | remote state services, APIs, web apps      | Need persistent local storage, need GPU      | Our default. Good tooling, well-understood.            |
-| **EKS (Kubernetes)** | local state workloads, complex deployments | Simple local state services (overkill)       | Higher operational overhead. Worth it for local state. |
-| **Lambda**           | Event-driven, short tasks, glue code       | Long-running processes, high-cpu needs       | Cold starts matter. Keep functions small.              |
-| **Cloud Run**        | Previews, internal tools, experiments      | Production services, AWS-dependent workloads | Great DX, but it's GCP (see Part A).                   |
-
-## 4B. Rationale
-
-**Why ECS as default?**
-
-- Simpler than Kubernetes for most use cases
-- Fargate \= no EC2 instance management
-- Good integration with AWS services (ALB, CloudWatch, Secrets Manager)
-- Lower cognitive overhead for teams
-
-**Why Kubernetes for local state?**
-
-- local stateSets, persistent volumes, and operators
-- Better control over scheduling and node affinity
-- Community ecosystem for databases and local state apps
-- We're investing in EKS anyway; leverage it where it shines
-
-**Why Lambda for event-driven?**
-
-- Pay-per-invocation is cost-effective for sporadic workloads
-- Built-in scaling, no capacity planning
-- Native integration with SQS, SNS, EventBridge
-- Forces good practices (small, focused functions)
-
-**Why Cloud Run for previews?**
-
-- Deploys in seconds, scales to zero
-- Cheap for low-traffic ephemeral environments
-- Great developer experience
-- Isolated from production (GCP \= natural boundary)
-
----
-
-## 5\. How to Apply
-
-### Example: New API Service
-
-You're building a new internal API that serves data to the mobile apps.
-
-1. **Which cloud?** → AWS (it's production, needs DB access)
-2. **What compute?** → ECS Fargate (local state API)
-3. **How to deploy?** → CloudFormation stack, GitHub Actions workflow
-
-### Example: Analytics Dashboard
-
-You're building an internal dashboard that queries BigQuery and displays charts.
-
-1. **Which cloud?** → GCP (BigQuery-native, no prod DB access)
-2. **What compute?** → Cloud Run (internal tool, low traffic)
-3. **How to deploy?** → Cloud Run from container registry
-
-### Example: New Observability Tool (like Langfuse)
-
-You're deploying a self-hosted observability tool that needs persistent storage.
-
-1. **Which cloud?** → AWS (needs to ingest data from AWS services)
-2. **What compute?** → EKS (local state, needs persistent volumes)
-3. **How to deploy?** → Helm chart, ArgoCD
-
-## 6\. Exceptions
-
-### Requesting an Exception
-
-If your use case doesn't fit the decision tree:
-
-1. Document: What you're building, why the default doesn't work
-2. Post in Platform channel
-3. Get sign-off before proceeding
-
-Common valid exceptions:
-
-- Vendor-specific requirements (e.g., "only runs on GCP")
-- Cost optimization for specific workload patterns
-- Experimentation with explicit time bounds
-
-### Grandfathered Services
-
-We should apply the [Gartner’s TIME framework](https://unstoppablesoftware.com/understanding-gartners-time-model-maximizing-business-value-with-software-portfolio-management/#:~:text=1%2E%20Tolerate%20%28Low%20Value%2C%20Low%20Cost%2FRisk) when deciding. After that, we may realize some existing services don't follow this standard. We're not migrating them unless there's a compelling reason. Document them, but don't use them as precedent for new services.
-
-## 7\. References
-
-- [ECS Service Setup Runbook](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [EKS Deployment Guide](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [Lambda Best Practices](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- [Cloud Run Setup for Previews](https://file+.vscode-resource.vscode-cdn.net/Users/arod/work/doist/twist-threads/work/20260114-platform-standards-analysis/TBD)
-- \[Cost Tagging Standard\](TBD \- Group 3\)