@todoist/doistbot-cli 0.0.0-stage → 1.0.16

package/sandbox/node_modules/doistbot-repo-config/dist/index.js

@@ -0,0 +1,197 @@
+import fs from 'fs';
+import path from 'path';
+import { load as yamlLoad } from 'js-yaml';
+export const CONFIG_FILE_PATH = '.github/doistbot.yml';
+export const DEFAULT_REVIEW_MODELS = ['openai', 'deepseek', 'zai'];
+export class RepoFileContentError extends Error {
+    reason;
+    constructor(reason) {
+        super(`Repository file content is ${reason}`);
+        this.reason = reason;
+        this.name = 'RepoFileContentError';
+    }
+}
+function isMapping(value) {
+    return (typeof value === 'object' &&
+        value !== null &&
+        (Object.getPrototypeOf(value) === Object.prototype || Object.getPrototypeOf(value) === null));
+}
+function hasControlCharacters(value) {
+    return [...value].some((character) => {
+        const code = character.charCodeAt(0);
+        return code < 0x20 || code === 0x7f;
+    });
+}
+function parseReviewModeConfig(value) {
+    if (!isMapping(value)) {
+        throw new Error('review.mode must be a mapping');
+    }
+    const mode = {};
+    if (value.guidance_path !== undefined) {
+        const guidancePath = value.guidance_path;
+        if (typeof guidancePath !== 'string' ||
+            !guidancePath.trim() ||
+            path.posix.isAbsolute(guidancePath.trim()) ||
+            path.win32.isAbsolute(guidancePath.trim()) ||
+            /^[a-z][a-z\d+.-]*:/i.test(guidancePath.trim()) ||
+            guidancePath.includes('\\') ||
+            hasControlCharacters(guidancePath) ||
+            guidancePath.trim().split('/').includes('..') ||
+            !/\.(md|markdown)$/i.test(guidancePath.trim())) {
+            throw new Error('review.mode.guidance_path must be a repository-relative Markdown path');
+        }
+        mode.guidance_path = path.posix.normalize(guidancePath.trim());
+    }
+    if (value.labels !== undefined) {
+        if (!isMapping(value.labels)) {
+            throw new Error('review.mode.labels must be a mapping');
+        }
+        mode.labels = {};
+        for (const category of ['ask', 'show', 'ship']) {
+            const labels = value.labels[category];
+            if (labels === undefined)
+                continue;
+            if (!Array.isArray(labels) ||
+                labels.some((label) => typeof label !== 'string' || !label.trim() || hasControlCharacters(label))) {
+                throw new Error(`review.mode.labels.${category} must contain non-empty label names`);
+            }
+            mode.labels[category] = labels.map((label) => label.trim());
+        }
+    }
+    return mode;
+}
+/** Review-mode validation is opt-in so it cannot block unrelated config callers. */
+export function parseRepoConfigContent(content, { validateReviewMode = false } = {}) {
+    const config = yamlLoad(content);
+    if (!validateReviewMode)
+        return config;
+    if (!isMapping(config)) {
+        throw new Error('Repository configuration must be a mapping');
+    }
+    if (config.review !== undefined) {
+        if (!isMapping(config.review)) {
+            throw new Error('review must be a mapping');
+        }
+        if (config.review.mode !== undefined) {
+            config.review.mode = parseReviewModeConfig(config.review.mode);
+        }
+    }
+    return config;
+}
+export async function fetchFileContent({ octokit, owner, repo, path, ref, signal, logger, strict = false, maxBytes, }) {
+    const params = {
+        owner,
+        repo,
+        path,
+    };
+    if (ref) {
+        params.ref = ref;
+    }
+    if (signal) {
+        params.request = { signal };
+    }
+    let response;
+    try {
+        response = await octokit.rest.repos.getContent(params);
+    }
+    catch (error) {
+        if (error instanceof Error && 'status' in error && error.status === 404) {
+            logger?.info('File not found', {
+                component: 'repo-config',
+                repository: `${owner}/${repo}`,
+                path,
+            });
+            return null;
+        }
+        throw error;
+    }
+    const { data } = response;
+    if (!('type' in data) || data.type !== 'file' || (strict && 'target' in data)) {
+        if (strict)
+            throw new RepoFileContentError('not_file');
+        logger?.warn('Path exists but is not a file', {
+            component: 'repo-config',
+            repository: `${owner}/${repo}`,
+            path,
+        });
+        return null;
+    }
+    if (maxBytes !== undefined && 'size' in data && data.size > maxBytes) {
+        throw new RepoFileContentError('too_large');
+    }
+    if (!('content' in data) ||
+        typeof data.content !== 'string' ||
+        (strict && 'encoding' in data && data.encoding !== 'base64')) {
+        if (strict)
+            throw new RepoFileContentError('unavailable');
+        return null;
+    }
+    if (!strict && !data.content)
+        return null;
+    const content = Buffer.from(data.content, 'base64').toString('utf8');
+    if (maxBytes !== undefined && Buffer.byteLength(content, 'utf8') > maxBytes) {
+        throw new RepoFileContentError('too_large');
+    }
+    return content;
+}
+/**
+ * Fetches the repository-specific configuration from .github/doistbot.yml.
+ * Returns null when the file is genuinely absent (404) or the path is not a file.
+ * Throws on transport / authorization errors so callers can distinguish "no
+ * config" from "could not load config" — important when an opt-out flag would
+ * otherwise be silently ignored.
+ */
+export async function getRepoConfig({ octokit, owner, repo, ref, signal, logger, }) {
+    const content = await fetchFileContent({
+        octokit,
+        owner,
+        repo,
+        path: CONFIG_FILE_PATH,
+        ref,
+        signal,
+        logger,
+    });
+    if (content === null) {
+        return null;
+    }
+    const config = parseRepoConfigContent(content);
+    logger.info('Loaded repo config', {
+        component: 'repo-config',
+        repository: `${owner}/${repo}`,
+        path: CONFIG_FILE_PATH,
+    });
+    return config;
+}
+export function getLocalRepoConfig({ workspaceDir, logger, strict = false, }) {
+    const configPath = path.join(workspaceDir, CONFIG_FILE_PATH);
+    try {
+        const config = parseRepoConfigContent(fs.readFileSync(configPath, 'utf8'));
+        logger.info('Loaded local repo config', {
+            component: 'repo-config',
+            path: CONFIG_FILE_PATH,
+        });
+        return config;
+    }
+    catch (error) {
+        if (error instanceof Error && 'code' in error && error.code === 'ENOENT')
+            return null;
+        if (strict)
+            throw error;
+        logger.warn('Failed to parse local repo config', {
+            component: 'repo-config',
+            path: CONFIG_FILE_PATH,
+            error: error instanceof Error ? error.message : String(error),
+        });
+        return null;
+    }
+}
+export function getDefaultReviewModels() {
+    return [...DEFAULT_REVIEW_MODELS];
+}
+export function parseReviewModelsEnabled(value) {
+    const models = value
+        ?.split(',')
+        .map((model) => model.trim())
+        .filter(Boolean) ?? [];
+    return models.length > 0 ? [...new Set(models)] : getDefaultReviewModels();
+}

package/sandbox/node_modules/doistbot-repo-config/package.json

@@ -0,0 +1,12 @@
+{
+    "name": "doistbot-repo-config",
+    "version": "1.0.0",
+    "type": "module",
+    "main": "dist/index.js",
+    "exports": {
+        ".": {
+            "types": "./src/index.ts",
+            "default": "./dist/index.js"
+        }
+    }
+}

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

@@ -0,0 +1,254 @@
+# Standard: Internal AI Tools
+
+| 📄 Document Type | Standard                                                                                                                                                                            |
+| :--------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 🎯 Status        | Approved                                                                                                                                                                            |
+| 👤 Owner         | Luciano Facchinelli                                                                                                                                                                 |
+| 📅 Last Reviewed | 2026-03-06                                                                                                                                                                          |
+| 🗂️ References    | [Data Classification Policy](https://handbook.doist.com/doc/data-classification-policy-t7mCBRgaec) [Encryption Policy](https://handbook.doist.com/doc/encryption-policy-zJ5ZApYT30) |
+| 📌 Version       | 1.0                                                                                                                                                                                 |
+
+## 1. Purpose
+
+As we build internal tools that leverage LLMs (e.g., for debugging, support, analytics), we need clear guardrails to prevent accidental data exposure. PII sent to third-party AI providers is a data leak waiting to happen.
+
+This standard exists to:
+
+- Prevent PII from reaching local developer machines or unauthorized third parties
+- Define what data can (and cannot) be sent to LLM providers
+- Establish an approval process for new AI-powered internal tools
+- Ensure auditability of AI tool usage
+
+## 2. Scope
+
+This standard applies to:
+
+- All internal tools that invoke external AI/LLM APIs (OpenAI, Anthropic, Google, etc.), whether directly or indirectly
+- Tools that process, display, or transmit user data (PII, task content, account info)
+- Both production services and developer tooling
+
+This does **not** apply to:
+
+- User-facing AI features in Doist products, such as Todoist/Twist (covered by product specs)
+- Purely local development tools that never touch real user data
+
+## 3. Quick Reference
+
+This is a list of requirements all internal AI tools should follow:
+
+- Tools must only be accessible through our secure internal network (Tailscale)
+- All processing happens on the server-side.
+- Remove or mask personal information before sending data to AI services
+- Keep records of all AI tool usage so we can review them if needed
+
+## 4. Standard
+
+### 4.1 Server-Side Only
+
+**All AI-powered internal tools that access user data MUST run server-side.**
+
+- No PII on local machines.
+- Tools must authenticate users and enforce access controls (via Tailscale, preferably)
+- Data flows: Production DB → Server-side service → approved LLM API → answer returned to local CLI/tool
+- Local clients may only display results, never raw user data
+
+### 4.2 External Service Credentials
+
+The server-side service will call third-party APIs on behalf of internal users. How credentials are managed depends on how the external service enforces access control.
+
+**Pattern A — Shared service token** (e.g. Zendesk, HiBob)
+
+A single API key or service-account token is stored securely on the server (e.g. in a secrets manager, never in source code). All requests are made using this one credential, regardless of who triggered the request.
+
+Use this pattern when the external service does not enforce per-user access controls. In this case, the internal service layer is responsible for filtering what each caller is allowed to see before returning a response.
+
+**Pattern B — Per-user delegated token / OAuth** (e.g. Google Workspace)
+
+Each user authenticates with the external service independently. Their OAuth token is stored server-side, scoped to their identity, and refreshed as needed. When a user makes a request, the server calls the external API on their behalf using their own token.
+
+Use this pattern when the external service enforces its own per-user permissions that the internal service cannot replicate, or when acting as the user is required by the service's terms.
+
+**Decision rule:** Does the external service itself enforce per-user access controls? If yes → use per-user delegated tokens. If no → use a shared service token with internal filtering.
+
+> Credentials must never be hard-coded in source code or committed to version control. Please follow our [standard secrets management practices](https://handbook.doist.com/doc/standard-secrets-management-wbKmIfrtgr)
+
+### 4.3 Data Filtering Before LLM Calls
+
+Where possible, sensitive data should be only used on a need basis.
+
+Examples:
+
+- Ensure prompts/data flows prefer user IDs over their email addresses
+- Error messages, stack traces (with user ID, not email)
+- Schema information, code snippets
+
+Things tool builders should actively avoid sending (feeding to the context window):
+
+- User email addresses, names, or other PII
+- Task/project content (user-generated text)
+- Authentication tokens, credentials
+- Payment information
+
+### 4.4 Approved Providers Only
+
+Only pre-approved LLM providers may be used and any interaction should happen through our organization's accounts.
+
+Avoid using any browser extension or fancy AI tool under the sun that lack the required scrutiny in terms of the LLMs they use behind the scenes, as well as data retention.
+
+Per our Privacy Policy, here are the ones we communicate publicly:
+
+- OpenAI
+- Anthropic
+- Google Vertex AI
+- AWS Bedrock
+
+Loop in Platform team review if there’s any new tool.
+
+> The example uses AWS Bedrock rather than the Anthropic API directly because Bedrock is likely already covered under Doist’s AWS agreement, keeping data within existing infrastructure. Any of the approved providers are valid — the key is using the organisation’s account, not a personal one.
+
+### 4.5 Audit Logging
+
+All LLM API calls SHOULD be logged.
+
+Logs to include:
+
+- Timestamp
+- Tool/service name
+- User who initiated the request
+- What data context was accessed (user IDs, not content)
+- LLM provider used
+
+Logs must NOT include:
+
+- Actual prompts containing user data
+- LLM responses containing user data
+
+### 4.6 Approval Process
+
+New AI-powered internal tools that access user data require explicit approval.
+
+Process:
+
+1. Create a brief spec describing: what the tool does, what data it accesses (or is capable of accessing), if and how data is filtered
+2. Create a Github Issue on Platform-backlog repo for Review
+3. Get sign-off from at least one Dev head team member. Also remember to include Platform Team as Reviewers
+4. Document the tool in [TBD: internal tools registry]
+
+## 5. Rationale
+
+Why server-side only?
+
+- Local machines are harder to audit and secure
+- Reduces blast radius if a developer's machine is compromised, or person leaves Doist
+- Easier to enforce consistent filtering and logging
+
+Why attempt to filter before LLM calls?
+
+- Some third-party providers may not be covered by our DPA for user data processing
+- Even "private" API calls may be logged, used for training, or accessed by provider staff
+- Regulatory compliance (GDPR, SOC 2) requires controlling data flows and applying the principle of minimization
+
+Why approved providers only?
+
+- Ensures we have appropriate agreements in place
+- Maintains consistency in security posture
+- Simplifies compliance audits
+
+**Decision Tree: Can I Build This?**
+
+```text
+Does your tool access user data?
+├── No → Build it, no special approval needed
+└── Yes → Does it send data to an LLM?
+    ├── No → Follow standard data access policies
+    └── Yes →
+        ├── Is it server-side only?
+        │   └── No → STOP. Redesign as server-side.
+        ├── Is PII filtered before LLM calls?
+        │   └── No → STOP. Add filtering.
+        └── Yes to both → Get Platform approval, add logging, ship it.
+```
+
+## Examples
+
+```mermaid
+flowchart TD
+    subgraph LOCAL["🖥️ Local Computer"]
+        Agent["Claude Code / Agent"]
+        Tool["Local CLI"]
+        Agent --> Tool
+    end
+
+    subgraph SERVER["☁️ Server Side"]
+        BedrockAPI["Bedrock API"]
+
+        subgraph DataSources["Data Sources"]
+            DD["DD"]
+            Sentry["Sentry"]
+            Zendesk["Zendesk"]
+        end
+
+        Service["Service"]
+        Service --> DataSources
+    end
+
+    subgraph NonSensitive["🔓 Non-Sensitive Data Sources"]
+        Github["Github"]
+        Twist["Twist"]
+        Outline["Outline"]
+    end
+
+    Tool --> Service --> BedrockAPI
+    Agent --> NonSensitive
+```
+
+> 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
+
+Think of the diagram as three separate rooms, each with different access rules:
+
+- **Your laptop** — where you work. The AI assistant lives here, but it can only see non-sensitive information directly.
+- **Your local CLI** — a thin relay that sends your question to the secure server and prints the answer. It never touches raw user data.
+- **The secure server** — a locked room in the cloud. All sensitive data and AI calls happen here, never on anyone's personal machine.
+- **Non-sensitive sources** — services like Github or Outline whose content is safe to access directly, since they don't hold user personal information.
+
+> Note: the developer's free-text question is forwarded as-is. Avoid including PII (e.g. email addresses) in your questions.
+
+**How a request travels:**
+
+- When a task involves user data (e.g. "what's going on with this support ticket?"), it goes: your laptop → secure server → data is fetched and cleaned → AI is asked → answer comes back to your laptop.
+- When a task doesn't involve user data (e.g. "find the relevant code for this feature"), the AI reads Github or Outline directly — no server needed.
+
+> Authentication in this example is handled entirely by Tailscale — only machines on the internal network can reach the service. No additional API key is needed.
+
+---
+
+### Migration example: from local PII access to the compliant architecture
+
+**Scenario:** You have Claude Code set up on your laptop so it can query Zendesk, Sentry, and Datadog directly. It's convenient, but it's not compliant — user emails, names, and ticket content are flowing through your personal machine and being sent to an external AI without any filtering.
+
+**Before (non-compliant):** The AI on your laptop connects directly to Zendesk and other sensitive tools, reads raw data including personal details, and sends all of it to an external AI service.
+
+**After (compliant):** The AI on your laptop connects only to an internal service. That service fetches the data, removes any personal details, and handles the AI call — your laptop only ever sees the final, cleaned-up answer.
+
+**What to change:**
+
+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/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/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.
+
+The result: your AI assistant works just as well, but sensitive data never leaves the secure server — and there's a full audit trail of everything that happened.
+
+---
+
+## 6. References
+
+- [Data Classification Policy](https://handbook.doist.com/doc/data-classification-policy-t7mCBRgaec)
+- [Encryption Policy](https://handbook.doist.com/doc/encryption-policy-zJ5ZApYT30)
+
+(add list of approved LLMs)

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