@doist/doistbot-cli 1.0.11 → 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.11",
+    "version": "1.0.13",
     "description": "Local self-review CLI for Doistbot",
     "type": "module",
     "main": "dist/index.js",
@@ -40,20 +40,21 @@
         "test": "vitest run src scripts --config ../../config/vitest.base.ts"
     },
     "dependencies": {
-        "@inquirer/checkbox": "5.2.1",
-        "@inquirer/password": "5.1.1",
-        "@earendil-works/pi-ai": "0.84.3",
-        "@earendil-works/pi-coding-agent": "0.84.3",
+        "@earendil-works/pi-ai": "0.85.1",
+        "@earendil-works/pi-coding-agent": "0.85.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",
         "chalk": "4.1.2",
         "commander": "14.0.3",
-        "js-yaml": "4.3.1",
+        "js-yaml": "4.3.2",
         "octokit": "5.0.5",
-        "undici": "8.10.0",
-        "yocto-spinner": "1.2.0"
+        "undici": "8.10.2",
+        "yocto-spinner": "1.2.2"
     },
     "devDependencies": {
-        "vitest": "4.1.9"
+        "vitest": "4.1.11"
     }
 }

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/providers/helpers.js

@@ -141,6 +141,9 @@ export function parseRawFindings(comments, modelName) {
             side,
             body: comment.body.trim(),
             sourceModel: modelName,
+            ...(comment.translationResolution
+                ? { translationResolution: comment.translationResolution }
+                : {}),
         };
     });
 }

package/sandbox/dist/providers/schemas.js

@@ -1,4 +1,5 @@
 import { Ajv } from 'ajv';
+import { TRANSLATION_RESOLUTIONS } from './types.js';
 export const REVIEW_SCHEMA = {
     type: 'object',
     additionalProperties: false,
@@ -14,7 +15,13 @@ export const REVIEW_SCHEMA = {
                     line: { type: 'integer', minimum: 1 },
                     side: { type: 'string', enum: ['LEFT', 'RIGHT'] },
                     body: { type: 'string', minLength: 1 },
+                    translationResolution: {
+                        type: 'string',
+                        enum: TRANSLATION_RESOLUTIONS,
+                    },
                 },
+                // Classification stays optional so omission keeps the finding instead of failing
+                // the entire review pass.
                 required: ['path', 'line', 'side', 'body'],
             },
         },

package/sandbox/dist/providers/types.js

@@ -1 +1,4 @@
-export {};
+export const TRANSLATION_RESOLUTIONS = [
+    'automated_sync_resolves',
+    'code_change_required_or_uncertain',
+];

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/dist/tasks/review/diff.js

@@ -1,4 +1,4 @@
-const MAX_DIFF_CHARS = 128000;
+export const MAX_DIFF_CHARS = 128000;
 /**
  * Converts GitHub's file list (with unified patches) into annotated diffs plus fast line lookups.
  */

package/sandbox/dist/tasks/review/engines/multi-focus.js

@@ -8,6 +8,7 @@ import { buildMultiFocusPrompt, REVIEW_FOCUS_DEFINITIONS, } from '../multi-focus
 import { buildFallbackSummary, summarizeReviewFindings } from '../review-summary.js';
 import { parseSeverity } from '../severity.js';
 import { buildGeminiFlashReviewSummaryModel } from '../summary-model.js';
+import { filterTranslationSyncOnlyFindings } from '../translation-review-policy.js';
 import { dedupeMultiFocusFindings } from './dedupe.js';
 import { buildGeminiFlashCredential, getApiKeys, getAvailableModels, getEnabledReviewModels, getOpenRouterReviewCredential, getProviderFailures, requestModelReview, } from './shared.js';
 const DEFAULT_REVIEW_MODELS_BY_FOCUS = {
@@ -340,8 +341,26 @@ export async function runMultiFocusReviewEngine({ ctx, prompt, lineLookup, prTit
                 providerFailures,
             };
         }
-        const allFindings = successfulRuns.flatMap((run) => run.findings);
-        const reviewObservations = collectReviewObservations(successfulRuns);
+        const modelFindings = successfulRuns.flatMap((run) => run.findings);
+        const { findings: allFindings, droppedFindings: translationSyncFindings } = filterTranslationSyncOnlyFindings({
+            repoOwner: ctx.owner,
+            repoName: ctx.repo,
+            findings: modelFindings,
+        });
+        if (translationSyncFindings.length > 0) {
+            logger.info('Filtered translation sync-only findings', {
+                repository: `${ctx.owner}/${ctx.repo}`,
+                droppedCount: translationSyncFindings.length,
+                droppedFindingIds: translationSyncFindings.map((finding) => finding.id),
+            });
+        }
+        const suppressedFindings = new Set(translationSyncFindings);
+        const reviewObservationRuns = successfulRuns.map((run) => {
+            const hasSuppressedFinding = run.findings.some((finding) => suppressedFindings.has(finding));
+            const hasKeptFinding = run.findings.some((finding) => !suppressedFindings.has(finding));
+            return hasSuppressedFinding && !hasKeptFinding ? { ...run, summary: '' } : run;
+        });
+        const reviewObservations = collectReviewObservations(reviewObservationRuns);
         let dedupedFindings = allFindings;
         try {
             dedupedFindings = await dedupeMultiFocusFindings({
@@ -380,7 +399,9 @@ export async function runMultiFocusReviewEngine({ ctx, prompt, lineLookup, prTit
             supportModels: allAvailableModels,
             focuses: focusDefinitions.map((focus) => focus.name),
             successfulRuns: successfulRuns.length,
-            findingsCount: allFindings.length,
+            findingsCount: modelFindings.length,
+            findingsAfterPolicyCount: allFindings.length,
+            translationSyncFindingsCount: translationSyncFindings.length,
             dedupedFindingsCount: dedupedFindings.length,
             inlineFindingsCount: routedFindings.inlineFindings.length,
             summaryOnlyFindingsCount: routedFindings.summaryFindings.length,

package/sandbox/dist/tasks/review/local-git.js

@@ -1,14 +1,36 @@
 import { execFileSync } from 'child_process';
 import os from 'os';
 import path from 'path';
-import {} from './diff.js';
+import { MAX_DIFF_CHARS } from './diff.js';
 const GIT_MAX_BUFFER_BYTES = 50 * 1024 * 1024;
 export function createGitRunner(workspaceDir) {
-    return (args) => execFileSync('git', ['-C', workspaceDir, '-c', 'core.quotePath=false', ...args], {
-        encoding: 'utf8',
-        maxBuffer: GIT_MAX_BUFFER_BYTES,
-        stdio: ['ignore', 'pipe', 'pipe'],
-    });
+    return (args, options) => {
+        try {
+            return execFileSync('git', ['-C', workspaceDir, '-c', 'core.quotePath=false', ...args], {
+                encoding: 'utf8',
+                maxBuffer: options?.maxBufferBytes ?? GIT_MAX_BUFFER_BYTES,
+                stdio: ['ignore', 'pipe', 'pipe'],
+            });
+        }
+        catch (error) {
+            const failure = error;
+            const stdout = typeof failure.stdout === 'string'
+                ? failure.stdout
+                : Buffer.isBuffer(failure.stdout)
+                    ? failure.stdout.toString('utf8')
+                    : '';
+            if (failure.code === 'ENOBUFS' &&
+                options?.returnPartialOutputOnMaxBuffer === true &&
+                options.maxBufferBytes !== undefined) {
+                return stdout.slice(0, options.maxBufferBytes);
+            }
+            if (typeof failure.status === 'number' &&
+                options?.allowedExitCodes?.includes(failure.status)) {
+                return stdout;
+            }
+            throw error;
+        }
+    };
 }
 export function tryGit(runner, args) {
     try {
@@ -75,7 +97,7 @@ function unquoteGitPath(rawPath) {
             unquoted = trimmed.slice(1, -1);
         }
     }
-    return unquoted.replace(/^[ab]\//, '');
+    return unquoted.replace(/^[ab]\//, '').replace(/^\.\//, '');
 }
 function readDiffGitPath(input, startIndex) {
     let index = startIndex;
@@ -162,6 +184,38 @@ export function parseGitDiffToFiles(diff) {
     flushCurrent();
     return files;
 }
+function getUntrackedReviewFiles(runner) {
+    const untrackedPaths = runner(['ls-files', '--others', '--exclude-standard', '-z'])
+        .split('\0')
+        .filter(Boolean);
+    if (untrackedPaths.length === 0) {
+        return [];
+    }
+    const files = [];
+    let remainingDiffChars = MAX_DIFF_CHARS;
+    for (const filename of untrackedPaths) {
+        if (remainingDiffChars <= 0) {
+            break;
+        }
+        // The two-file form also works with Git versions before 2.51.
+        const diff = runner([
+            'diff',
+            '--no-index',
+            '--no-ext-diff',
+            '--no-color',
+            '--',
+            '/dev/null',
+            `./${filename}`,
+        ], {
+            allowedExitCodes: [1],
+            maxBufferBytes: remainingDiffChars,
+            returnPartialOutputOnMaxBuffer: true,
+        });
+        files.push(...parseGitDiffToFiles(diff));
+        remainingDiffChars -= diff.length;
+    }
+    return files;
+}
 export function getLocalReviewFiles({ runner, source, }) {
     if (source === 'staged') {
         const diff = runner(['diff', '--staged', '--no-ext-diff', '--no-color']);
@@ -183,7 +237,7 @@ export function getLocalReviewFiles({ runner, source, }) {
     const mergeBase = runner(['merge-base', baseBranch, 'HEAD']).trim();
     const diff = runner(['diff', '--no-ext-diff', '--no-color', mergeBase]);
     return {
-        files: parseGitDiffToFiles(diff),
+        files: [...parseGitDiffToFiles(diff), ...getUntrackedReviewFiles(runner)],
         baseBranch,
     };
 }

package/sandbox/dist/tasks/review/prompt.js

@@ -2,6 +2,7 @@ import fs from 'fs';
 import path from 'path';
 import { fileURLToPath } from 'url';
 import { logger } from '../../core/logging.js';
+import { buildTranslationReviewGuidance } from './translation-review-policy.js';
 const MAX_BODY_CHARS = 4000;
 let cachedStandardsSection = null;
 const REVIEW_TASK_DIR = path.dirname(fileURLToPath(import.meta.url));
@@ -75,5 +76,6 @@ export function buildReviewPromptVariables({ repoOwner, repoName, prNumber, prTi
         PR_CONVERSATION: formatPrConversation(prConversation),
         DIFF_SECTION: fullDiffSection,
         STANDARDS_SECTION: standardsSection,
+        TRANSLATION_REVIEW_GUIDANCE: buildTranslationReviewGuidance(repoOwner, repoName),
     };
 }

package/sandbox/dist/tasks/review/translation-review-policy.js

@@ -0,0 +1,37 @@
+const ENGLISH_SOURCE_FIRST_REPOSITORIES = new Set([
+    'doist/todoist-web',
+    'doist/todoist-android',
+    'doist/todoist-ios',
+    'doist/todoist-electron',
+    'doist/todoist-macos',
+]);
+export function usesEnglishSourceFirstTranslations(repoOwner, repoName) {
+    return ENGLISH_SOURCE_FIRST_REPOSITORIES.has(`${repoOwner}/${repoName}`.toLowerCase());
+}
+export function buildTranslationReviewGuidance(repoOwner, repoName) {
+    if (!usesEnglishSourceFirstTranslations(repoOwner, repoName)) {
+        return '';
+    }
+    return `## Repository-specific Translation Workflow
+
+This repository uses an English-source-first workflow: feature PRs change the English source strings, automation sends them to the repository's translation service, and translated locale files arrive through a later automated sync.
+
+- Do not create a finding or summary note merely because translated locale files or generated locale bundles are unchanged in the feature PR.
+- Do not ask the author to pull, update, generate, or commit translations manually. If the PR description already mentions the translation-service follow-up, including Transifex, do not repeat it.
+- Continue to report concrete i18n implementation errors introduced by the diff, such as incorrect translation API or gettext usage, broken interpolation placeholders, pluralization or context mistakes, and patterns that prevent source-string extraction.`;
+}
+export function isTranslationSyncOnlyFinding(repoOwner, repoName, finding) {
+    return (usesEnglishSourceFirstTranslations(repoOwner, repoName) &&
+        finding.translationResolution === 'automated_sync_resolves');
+}
+export function filterTranslationSyncOnlyFindings({ repoOwner, repoName, findings, }) {
+    const keptFindings = [];
+    const droppedFindings = [];
+    for (const finding of findings) {
+        const destination = isTranslationSyncOnlyFinding(repoOwner, repoName, finding)
+            ? droppedFindings
+            : keptFindings;
+        destination.push(finding);
+    }
+    return { findings: keptFindings, droppedFindings };
+}

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/tasks/review/prompts/review-multi-focus-base-prompt.md

@@ -73,6 +73,8 @@ $DIFF_SECTION
 - Keep code ranges tight and comments easy to understand without close reading.
 - **Do not flag dependency or tooling versions as nonexistent, outdated, or "too new."** Your training data has a cutoff, so you can't know which versions of GitHub Actions, npm/PyPI/etc. packages, or their APIs are currently published. Never tell the author a version doesn't exist, is wrong, or should be downgraded based on your own knowledge — and never claim a library feature or API is unavailable because you assume the project uses an older major version. Raise a version-related finding only when the diff or checked-out repo contains concrete contradicting evidence (e.g., the manifest/lockfile pins a different version, or the referenced symbol is absent from the dependency's actual source on disk).
 
+$TRANSLATION_REVIEW_GUIDANCE
+
 ## Writing Style
 
 - Write clearly, concisely, and directly. Be engaging without sounding generic.
@@ -97,6 +99,20 @@ At the beginning of each finding title, tag it with a priority level:
 
 ## Output Format
 
+For every finding, answer this internal classification question: assuming the repository's normal
+translation automation completes successfully, would the issue be fully resolved without changing
+application code, source-string keys, extraction configuration, lookup behavior, placeholders,
+pluralization, or locale context?
+
+- Use `automated_sync_resolves` only when the answer is clearly yes.
+- Use `code_change_required_or_uncertain` for all non-translation findings, concrete i18n
+  correctness problems, and any uncertain case.
+- Keep this classification out of the finding body.
+- Missing or stale translated content, requests to pull or commit locale artifacts, and advice to
+  wait for the automated sync are `automated_sync_resolves` when no code-level problem remains.
+- Broken extraction, keys, lookups, placeholders, pluralization, or locale handling are
+  `code_change_required_or_uncertain`, even when their symptom is a missing translation.
+
 Return strict JSON in this exact shape:
 
 ```json
@@ -107,7 +123,8 @@ Return strict JSON in this exact shape:
             "path": "relative file path exactly as shown in the diff above",
             "line": 42,
             "side": "RIGHT",
-            "body": "[P2] Brief description of the issue and actionable fix."
+            "body": "[P2] Brief description of the issue and actionable fix.",
+            "translationResolution": "code_change_required_or_uncertain"
         }
     ]
 }

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\)