Anthony Shew

feat: Migrate TUI virtual terminals from vt100 to Ghostty (#13135) <!-- CURSOR_AGENT_PR_BODY_BEGIN --> ### Description Migrates Turborepo's TUI task output panes from the vendored `turborepo-vt100` crate to [Ghostty](https://ghostty.org)'s `libghostty-vt` terminal emulator. **Why Ghostty?** Ghostty's VT library is actively maintained, supports modern terminal features, and is the same engine powering the Ghostty terminal. This replaces the older in-repo vt100 implementation and removes the `tui-term` dependency. #### Architecture - **`turborepo-ghostty-sys`** — In-repo FFI against `libghostty-vt`. `build.rs` fetches a pinned Ghostty commit and compiles via Zig 0.15.2; `bindings.rs` is checked in for docs.rs. - **`turborepo-ghostty`** — Safe Rust wrappers (adapted from [libghostty-rs](https://github.com/Uzaaft/libghostty-rs)) plus Turborepo-specific `Parser` and ratatui `TerminalWidget` (adapted from [ratatui-ghostty](https://codeberg.org/jint/ratatui-ghostty)). - **`turborepo-ui`** — Task pane rendering, scroll, and selection updated to use the Ghostty-backed widget. TUI dependencies are gated behind a `tui` feature so lightweight consumers (e.g. `turborepo-telemetry`, `@turbo/repository`) don't pull in Ghostty/Zig. **Removed:** `crates/turborepo-vt100`, `tui-term` dependency. #### Notable fixes included - **Selection/copy** — Ghostty selection grid refs go stale as output streams; viewport endpoints are now persisted and refreshed before render/copy. Selected cells are highlighted during drag. - **`Send` for tokio** — Static Ghostty allocator objects are marked `Send + Sync` so the TUI `App` can be moved into `tokio::task::spawn`. - **CI / Zig** — `setup-zig` detects host arch (`aarch64` vs `x86_64`), uses the correct Windows `.zip`, and sets isolated `ZIG_GLOBAL_CACHE_DIR` to avoid stale linker failures on reused macOS runners. - **`@turbo/repository`** — Gating Ghostty behind `turborepo-ui`'s `tui` feature prevents the NAPI package from building `libghostty-vt` unnecessarily. #### Build requirements Zig 0.15.2+ is now required to build the `turbo` binary (documented in `CONTRIBUTING.md`). CI installs it via `.github/actions/setup-zig`. Optional env vars for local Ghostty development: `GHOSTTY_SOURCE_DIR`, `GHOSTTY_ZIG_SYSTEM_DIR`, `TURBOREPO_GHOSTTY_SYS_OPTIMIZE`. #### Attribution Vendored code is documented in the crate READMEs. Most safe wrappers and FFI patterns come from libghostty-rs; ratatui integration from ratatui-ghostty; `Parser` and Turborepo UI glue are original. ### Testing Instructions 1. Build and run the TUI: `cargo build` then `turbo run <tasks> --ui=tui` in a monorepo with long-running tasks. 2. **Selection/copy** — Click-drag across task output; verify highlight appears and copied text is correct after more output streams in. 3. **Scroll** — Mouse wheel and keyboard scrolling through task scrollback. 4. **Stdin** — Interactive tasks that read from stdin still work in the focused pane. 5. **Resize** — Resize the terminal while the TUI is open; panes should reflow cleanly. 6. **Non-TUI paths** — `turbo run` without `--ui=tui` and `@turbo/repository` tests should work without requiring a Zig build. <!-- CURSOR_AGENT_PR_BODY_END --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Anthony Shew <anthonyshew@users.noreply.github.com>

fix: Refactor `turbo watch` (#13423) ## Summary - replace the shared raw filesystem event broadcast with scoped, demand-driven subscriptions for package changes, hashing, outputs, discovery, cookies, devtools, and daemon root monitoring - model inherited and nested Git ignores, global excludes, tracked exceptions, dynamic Git controls, and explicit ignored input/output interests - prune ordinary ignored trees from Linux inotify coverage while preserving explicit coverage, and route non-mutating backends directly after readiness - add scoped recovery for backend rescans/errors and document the watcher architecture Closes #13402 ## Validation - `cargo test -p turborepo-filewatch --lib` focused and platform-independent coverage - Linux all-feature filewatch test binary in Docker: 68/68 passed - `cargo test -p turborepo-lib package_changes_watcher::test` - `cargo clippy -p turborepo-filewatch --all-targets --all-features -- -D warnings` - `cargo clippy -p turborepo-lib -p turborepo-daemon -p turborepo-devtools --all-targets -- -D warnings` - `cargo check -p turborepo-filewatch --target x86_64-pc-windows-gnu` - original Linux reproduction with three repeated 100,000-file bursts: zero package/hash lag, one package build each, and one web-server start ## Notes Native macOS FSEvents stress was limited by local stream exhaustion after repeated test runs; focused FSEvents path/rescan tests and macOS compilation pass.

perf: Overhaul pnpm lockfile parsing and dependency closure computation (#13228) ## Why On large pnpm monorepos, the bulk of `turbo run` startup — the window between invocation and the first task starting — is spent parsing `pnpm-lock.yaml` and computing per-workspace transitive dependency closures. Profiling a 1191-package internal monorepo (43k tracked files, 5.4MB lockfile) showed the closure walk dominated by string allocation, hashing, and map probes rather than actual resolution work, and YAML parsing spending ~75% of its time inside a general-purpose scanner that pnpm's rigid machine-generated output doesn't need. ## What This PR has grown into the full pnpm startup overhaul: five stacked changes, each merged into this branch after independent review and verification. **1. Closure walk interning + FxHash.** Resolved packages are interned to dense `u32` ids behind the existing caches: resolve-cache hits become a refcount bump instead of cloning two `String`s per closure edge, visited sets hash a `u32` instead of two heap strings, and the deps cache is keyed by id. Cache maps use FxHash — lockfile content is developer tooling input, not a hash-flooding vector. **2. pnpm hash index** (#13229). The post-parse `dependency_index` becomes an `FxHashMap` carrying membership flags and versions, making `has_package`/`package_version`/`all_dependencies` O(1) probes instead of `BTreeMap` walks over long keys. Entry dependency maps stay `BTreeMap` so closure iteration order remains deterministic. Also fixes `subgraph()` returning pruned lockfiles with an empty index. **3. Fast pnpm parse on saphyr events** (#13230). An event-driven parser (pure Rust, ~2x libyaml scanner throughput) builds `PnpmLockfile` without serde on the hot path. Deliberately conservative: multi-document input, anchors/aliases, tags, duplicate keys, and exotic numeric forms bail to the unchanged serde path. Observable serde quirks (untagged variant order, `lockfileVersion` float formatting, plain-scalar typing, unknown-field dropping) are mirrored exactly and enforced differentially. **4. Structural line scanner** (#13238). pnpm-lock.yaml is line-oriented machine-generated YAML, so a `memchr`-driven scanner specialized to exactly that subset replaces the general YAML state machine as tier 1, emitting the same event stream the semantic layer from (3) consumes — quirk handling is shared, not duplicated. Tier order: scanner → saphyr → serde; the scanner also declines anything a general parser would *reject*, so it can never fabricate a lockfile from invalid input. Roughly halves parse time again on every corpus measured. **5. Shared bitset closure DP** (#13239). Closures were recomputed per workspace, so shared dependencies were re-walked once per workspace reaching them. When the lockfile can prove every transitive edge resolves identically across workspaces (pnpm importers can shadow transitive resolution, so this is proven per edge via importer equivalence classes, not assumed), closures are computed once globally: iterative Tarjan SCC condensation, then a bottom-up bitset DP where set unions are word-parallel `u64` ORs, processed in bounded-memory chunks. Any sensitive edge, non-pnpm lockfile, or single-workspace call falls back to the unchanged legacy walk. ## Results Interleaved A/B against current `main`, 4-core Linux, telemetry disabled, on the 1191-package monorepo. Time-to-first-task is measured in-process (invocation to first task dispatch in the chrome profile). | Benchmark | main | this PR | delta | |---|---|---|---| | time-to-first-task (real run) | 1117ms | 472ms | **−58%** | | `turbo run build --dry=json` end-to-end | 1481ms | 871ms | **−41%** | | lockfile parse (5.4MB, `from_bytes`) | ~285ms | 56ms | **−80%** | | peak RSS (dry) | — | −27MB vs branch base | bitsets beat per-workspace set churn | Parse deltas hold on public corpora too: next.js lockfile (1.29MB) 30.9→15.0ms, this repo's (707KB) 15.3→8.0ms for the scanner tier alone. ## How to verify - Full `--dry=json` output diffed against current main on the internal benchmark monorepo and this repo — byte-identical modulo run id and version string. - 20 differential parse tests assert scanner == saphyr == serde (`Eq`-identical lockfiles, byte-identical `encode()` round-trips) across v5/v6/v9 fixtures, folded/literal block scalars with chomping/blank-line edges, quoting, flow collections, catalogs, patches, and this repo's own `pnpm-lock.yaml` — with scanner acceptance *required* on mainline shapes so regressions can't silently fall through to slower tiers. Each unsupported construct has explicit fallback coverage. - The closure DP is differentially tested against the legacy walk (an independent oracle — the single-workspace entry point never uses the DP), including a crafted divergent-edge fixture proving the fallback triggers. 220 crate tests pass.

feat: Add deferred hashing for task inputs (#13125) ## Why Some task inputs are not reliable when `turbo` starts. Generated code, generated CSS, API types, and other materialized files may be missing or stale until an upstream task runs, which can produce a cache key that does not represent the files the task actually consumes. Deferred hashing gives power users a way to finalize a task hash after its dependencies complete. Simple examples: Hashes normal package inputs at startup, using defaults while excluding `dist`: ```json { "inputs": [ { "mode": "startup", "withDefaults": true, "globs": ["!dist/**"] } ] } ``` Waits for `codegen`, then hashes generated files before checking cache: ```json { "dependsOn": ["codegen"], "inputs": [ { "mode": "startup", "withDefaults": true, "globs": ["!src/generated/**"] }, { "mode": "jit", "globs": ["src/generated/**"] } ] } ``` Hashes declared outputs from the selected `codegen` task after it runs, without also hashing generated files at startup: ```json { "dependsOn": ["codegen"], "inputs": [ { "mode": "startup", "withDefaults": true, "globs": ["!src/generated/**"] }, { "mode": "dependencyOutputs", "from": ["codegen"], "globs": ["src/generated/**"] } ] } ``` ## What Adds deferred hashing support through `startup`, `jit`, and `dependencyOutputs` input modes, including validation, hashing, dry-run summaries, schema/bindings, architecture docs, user-facing docs, and regression coverage. ## How Ton of test coverage added, and did a lot of manual testing.

feat: Rebuild the factory image on every merge to main (#13781) ## What Agents in `apps/factory` booted from `vercel/eve:latest` plus a shallow clone. The sandbox had no Rust toolchain, `protoc`, Cap'n Proto, Zig, LLD, pnpm 10.28.0, `node_modules`, or performance tooling, and its Eve `revalidationKey` was hardcoded to `"turborepo-main-v1"`, so the template never rotated. `.devcontainer/Dockerfile` had most of that toolchain but was unused and had drifted three Rust nightlies, two Node majors, and two pnpm majors behind. This adds the factory image: one specification for what an agent's sandbox contains, a snapshot rebuilt by the application on every merge to `main`, and both agent paths booting from it. ## One specification `apps/factory/agent/lib/factory-image.ts` owns the image. It pins versions to the values the repository and CI already use, emits idempotent provisioning phases, and fingerprints the whole thing so a changed pin rebuilds every image. | Tool | Version | Source of truth | | --- | --- | --- | | Rust | `nightly-2026-05-22` + `rustfmt`, `clippy` | `rust-toolchain.toml` | | Node.js | 24 | root `package.json` `engines` | | pnpm | 10.28.0 | root `package.json` `packageManager` | | protoc | 26.1 | `.github/actions/setup-protoc` | | Cap'n Proto | 1.1.0 | `.github/actions/setup-capnproto` | | Zig | 0.15.2 | `.github/actions/setup-zig` | Plus `build-essential`, `pkg-config`, LLD (`.cargo/config.toml` links with `-fuse-ld=lld`), OpenSSL headers, `jq`, `zstd`, the workspace `node_modules`, a warm Cargo registry, and `hyperfine`, `cargo-bloat`, and `twiggy` for the performance skill. A final phase verifies every required tool, warns about missing optional ones, and writes a version manifest. `.devcontainer/Dockerfile` was rewritten against the same pins, and a test fails when either drifts from `rust-toolchain.toml`, the root `package.json`, or the CI actions — so the local dev container and the agents' sandbox stay on one toolchain. ## Rebuilt on every merge, without GitHub Actions A push to `main` reaches `POST /api/github/push`, which verifies the GitHub HMAC signature and starts a Workflow run. The workflow creates a build sandbox, detaches the provisioning script inside it, polls the markers the script writes, snapshots the result, and publishes the snapshot id to a Blob-backed ledger. No step holds a function invocation open for the length of a build. When a published image already exists for the same toolchain the build boots from it, so a merge build only fast-forwards the checkout, refreshes dependencies, and recompiles. ## Rapid merges Resolved in the ledger rather than by racing: - Claiming a build cancels every build still in flight, records which build replaced it, stops its workflow run, and deletes its sandbox. - Every step re-reads the ledger before acting; a build that has lost can neither report progress nor publish a pointer. - Redelivered webhooks deduplicate onto the live build, a revision that is already published is skipped, and a build that stops reporting progress for 15 minutes is replaced instead of wedging its revision. ## Consumers - **Eve** (`agent/sandbox.ts`) provisions its template from the same phases and boots from the published snapshot when one matches. Eve freezes `revalidationKey` at build time, so the template rotates when the fingerprint changes or a newer image is published; each session then fast-forwards its checkout to the current `main`. - **Harness** (`agent/lib/harness-agent.ts`) uses the snapshot as its sandbox source instead of a stock `node24` runtime plus a clone, rotates its template with the image, and falls back to cloning when no image matches this deployment's toolchain. - The **operator page** shows the published snapshot, the toolchain fingerprint, warnings, and recent builds, and can rebuild from the current `main` head. ## Validation Every provisioning phase was run against a real `vercel/eve:latest` sandbox. All eleven phases pass through verification in about two minutes, with no warnings: ``` system-packages 10s · node 1s · pnpm 2s · rust 11s · protoc <1s · zig 5s checkout 2s · node-modules 12s · cargo-registry 7s · performance-tools 45s · verify 1s {"capnp":"Cap'n Proto version 1.1.0","node":"v24.17.0","pnpm":"10.28.0", "protoc":"libprotoc 26.1","rustc":"rustc 1.97.0-nightly (e96c36b6f 2026-05-21)", "zig":"0.15.2"} ``` That run also confirmed the image is Ubuntu 26.04 with `apt`, that commands run as root, and that `ld.lld`, `hyperfine`, `cargo-bloat`, and `twiggy` all land on `PATH`. 45 unit tests pass (`pnpm test`), covering the pinned versions against the files they mirror, the phase list and generated script, revision validation, progress parsing, the fingerprint, the ledger's supersede and publish rules, and webhook signature and event filtering. `eve build`, `next build`, `tsc --noEmit`, `oxlint --deny-warnings`, and `oxfmt --check` are clean. ## Deployment notes - Requires the private Vercel Blob store the run registry already uses. - Set `FACTORY_IMAGE_WEBHOOK_SECRET` (falls back to `GITHUB_WEBHOOK_SECRET`) and deliver `push` to `/api/github/push`. Deployment Protection covers that path, so append the automation bypass token as a query parameter; the HMAC signature authenticates the delivery. - The first build after a toolchain change provisions the Eve template during the Vercel build, because Eve prewarms templates there. The phases that compile Rust are wrapped in timeouts so one bad upstream release cannot hold a deployment build open, and only the merge webhook asks for the warm `cargo build`. - Performance-tool installation failures are recorded as warnings rather than failing a build, so a broken upstream crate cannot stop an otherwise complete image from publishing. The warnings surface on the operator page. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>

fix: Tolerate transient input files (#13734) ## Summary - Tolerate `ENOENT` for task inputs and `globalDependencies` files that disappear between discovery and hashing. - Keep required resolution fallback files strict and report path-specific `HashFile` errors. - Respect configured inputs literally, including `.git` metadata and linked-worktree pointer files. - Classify regular files from opened handles where supported and skip non-regular discovery candidates consistently across Git and manual SCM. - Record vanished candidates, non-regular candidates, and hashing failures when verbosity is enabled. Closes #13732 ## Testing - `cargo test -p turborepo-scm` - `cargo test -p turborepo-task-hash` - `cargo clippy -p turborepo-scm -p turborepo-task-hash --all-targets -- -D warnings` - `cargo fmt --all -- --check` --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>

feat: Add durable Factory workspaces (#13804) ## Summary - Replace browser-local ad hoc chats with durable, shareable workspaces backed by private Blob records, named Vercel Sandboxes, and saved `fx` sessions. - Run all interactive and manual example-maintenance work exclusively through pinned `fx v0.0.5`; remove the Claude Code, Codex, OpenCode, and AI SDK Harness paths and dependencies. - Expose the native fx audit and resume the exact same session from browser terminals or local SSH with `fx resume --id`. - Add synchronized transcripts, live status, capped diffs, PR links, browser terminals, SSH commands, and a local Factory CLI. - Use at-most-once turn dispatch and terminal Workflow reconciliation so retries cannot duplicate agent or GitHub side effects. ## Validation - `pnpm test` (92 tests) - `pnpm exec tsc --noEmit` - `pnpm exec oxfmt --check .` - `pnpm exec next build` - Verified the pinned fx release checksum and CLI syntax for `ask --json --resume-id` and `resume --id`. - Desktop and iPhone 14 browser smoke tests for workspace navigation and creation UI. - Pre-push formatting and TOML hooks. ## Platform boundary Eve task-mode schedules remain audited through Agent Runs. Eve does not expose its native sandbox name or PTY, so those existing task-mode sandboxes cannot be attached through SSH. New interactive and manually triggered maintenance work runs fx inside named workspaces to provide synchronized chat, native session audit, terminal, diff, and SSH access.

fix: Disable unresolved Cargo artifact caching (#13362) ## Why Cargo artifact caching must fail closed when task outputs depend on layout inputs Turborepo cannot safely resolve. Otherwise, cache restores can reuse or omit the wrong artifacts. This is stack 2/4 and depends on #13360. ## What Unsupported Cargo arguments, manifests, configuration, compiler overrides, and paths that escape the workspace now disable inferred artifact caching. Supported default and profile-only builds retain wildcard output discovery. ## How Validated the repository, engine, and library test suites; all 24 Cargo workspace end-to-end tests; `cargo lint`; `cargo fmt --check`; and `git diff --check`. Reviewers can focus on fail-closed classification in `cargo.rs` and the hermetic cases in `cargo_workspace_test.rs`.

refactor: Migrate CLI parser to usage-rs (#13890) ### Description Migrate the primary Turborepo CLI parser from `clap` to `usage-rs` 6.5.0. - Refactor parser-facing command structures where `usage-rs` requires owned, unboxed argument groups. - Preserve implicit `turbo <task>` routing, global flags, aliases, optional values, conflicts, requirements, `--` pass-through arguments, `--single-package`, and repeated-scalar rejection. - Replace clap help, diagnostics, and completion generation with usage-rs equivalents. - Add deterministic arbitrary-argv property coverage and an ASan/libFuzzer target, including non-UTF-8 `OsString` inputs on Unix. - Update CLI snapshots for the expected cosmetic help and diagnostic changes. #### Benchmarks Measured on Apple Silicon macOS using the `release-turborepo` profile: | Measurement | clap | usage-rs | Difference | | --- | ---: | ---: | ---: | | Cold build wall time | 285.66s | 284.24s | 0.5% faster | | Build max RSS | 3.48 GB | 3.37 GB | 3.2% lower | | Binary size | 45,090,512 B | 45,479,680 B | 0.86% larger | | `--help` | 10.9 ± 2.0 ms | 10.5 ± 0.5 ms | ~4% faster | | Invalid argument | 11.4 ± 3.0 ms | 10.7 ± 2.2 ms | ~9% faster | The runtime differences are close to process startup noise. `clap` also remains in the final dependency graph through other crates, so this migration alone does not remove it from the binary. #### Differential fuzzing I preserved a release build of the clap implementation from the migration base and ran it beside the usage-rs build. The differential corpus covered explicit and implicit `run`, other subcommands, aliases, global flags in different positions, optional values, invalid values, conflicting flags, repeated scalar and repeatable flags, Unicode values, unknown flags, and `--` pass-through arguments. Both binaries received the same argv. I compared parser acceptance/rejection and exit behavior, then compared focused stdout/stderr for stable cases such as help, unknown arguments, conflicts, and duplicate scalar values; diagnostic prose and formatting were intentionally treated as cosmetic. This differential work found that usage-rs accepted a repeated nested scalar such as two `--concurrency` values where clap rejected it. The migration now rejects repeated scalar flags explicitly and retains a regression test. Grammar-guided sentinel runs were also used as a discovery tool for differences in error precedence and command-local flag placement; those findings were checked against the existing CLI regression suite rather than treating first-error wording as semantic equivalence. This sat alongside, rather than replacing, the arbitrary-byte property test and ASan/libFuzzer campaigns described below. #### Patch-level compatibility escape hatch A missed parser incompatibility can be repaired inside the usage-rs path in a normal patch release, without user configuration, a second binary, or reverting the migration. `Args::parse_args` owns the complete `Vec<OsString>` immediately before `Args::try_parse_from`, and it already uses this boundary for compatibility behavior such as stripping and restoring `--single-package`, rejecting clap-incompatible duplicate scalar flags, and rejecting values attached to boolean switches. A targeted hotfix can therefore normalize a legacy spelling or argv shape before parsing, or adjust the typed `Args` immediately afterward, before any command handler runs. For example, if usage-rs stopped accepting the existing `--dry` alias, the compatibility patch can live at the pre-parse boundary: ```rust let words: Vec<OsString> = single_package_free .map(|word| match word.to_str() { Some("--dry") => OsString::from("--dry-run"), Some(value) if value.starts_with("--dry=") => { OsString::from(value.replacen("--dry=", "--dry-run=", 1)) } _ => word, }) .collect(); let mut args = Args::try_parse_from(&refs) .map_err(|error| Args::render_failure(&refs[1..], &error))?; ``` This is transparent to users: the same command line continues to work after installing the patch release. The same boundary can handle renamed flags, changed optional-value syntax, argument ordering, legacy aliases, and other token-level differences. If the parser accepts the tokens but binds them differently, the patch can instead mutate the typed `args` directly after `try_parse_from` and before returning from `parse_args`; command handlers only receive the corrected representation. I proved this locally and removed it without committing: I temporarily removed the declared `--dry` alias from usage-rs, added the normalization above, and verified both `turbo run build --dry` and `turbo run build --dry=json` still parsed successfully. The existing focused typed parser tests passed (2 passed, 0 failed), and both end-to-end binary invocations exited 0. #### Expected cosmetic changes - Help uses usage-rs layout, wrapping, headings, and metavariable names. - Diagnostics are shorter and use usage-rs wording. - Conflict diagnostics can name flags in a different order. - Shell completions use usage-rs's smaller dynamic completion protocol rather than clap's large static script. ### Testing Instructions - Exercise representative explicit and implicit runs, such as `turbo run build` and `turbo build`. - Verify global flags before and after subcommands. - Verify unknown flags and repeated scalar options fail. - Verify arguments after `--` reach the underlying task unchanged. - Generate completions for each supported shell. Fuzz validation performed: - 100,000 deterministic property cases with arbitrary byte-backed arguments, including non-UTF-8 Unix arguments. - 1,000,000 ASan/libFuzzer executions with no crashes or hangs. - An additional 100,000 ASan/libFuzzer executions after adding repeated-scalar enforcement, also with no crashes or hangs.

fix: Scroll TUI task list with mouse wheel (#13479) ## Summary - Preserve mouse-wheel coordinates through TUI input translation - Scroll only the task-list viewport when the pointer is over the sidebar - Keep the active task and output pane unchanged while browsing the list - Reuse the same acceleration, throttling, and decay algorithm as log scrolling - Keep independent momentum state for the task list and log pane - Reattach the viewport to selection on keyboard navigation or row clicks ## Testing - `cargo test --package turborepo-ui --features tui` (130 passed) - `cargo test --package turbo --test tui_test scrolls_the_task_list_with_the_mouse_wheel_over_the_sidebar` - `cargo fmt --all -- --check` - `pnpm format` - `pnpm lint`