Fix three pre-existing breakages in the example apps and task graph

[KayleeWilliams]

Three pre-existing breakages, all surfaced by running bun run build and bun run check-types across the monorepo while working on #157. Independent of that stack, so this is a standalone PR off main.

1. bun run check-types failed on main, differently each run

tanstack, then nuxt-example, then sveltekit-example. Not a type error — every example app's check-types script began with bun run --filter leadtype build, which rm -rfs and rebuilds packages/leadtype/dist. Turbo runs the tasks in parallel, so eight of those raced on one directory and whichever app was reading dist when another deleted it lost.

Turbo already knows the dependency; the scripts were working around it. Adding ^build to the check-types task builds leadtype once, ahead of every dependent, and the per-app self-build comes out.

Verified with three consecutive full runs: 9 successful, 9 total, each time.

2. apps/astro-example could not build at all

satteri — leadtype's MDX parser — is a napi-rs module whose loader picks a platform binding with a bare require("@bruits/satteri-darwin-arm64"). Bundled into Astro's prerender chunk, that require resolves relative to dist/.prerender/chunks/, where the binding isn't reachable:

Cannot find native binding. …
Caused by: Cannot find module '@bruits/satteri-darwin-arm64'
  at requireNative (…/dist/.prerender/chunks/source_BgsvcLQ8.mjs:14045:25)

Two things were needed, and the first alone isn't enough:

1. A resolveId hook rather than resolve.external. leadtype is a workspace package, so Astro's dependency crawl marks it noExternal — and noExternal wins. Astro 6's Vite 7 environment keys (environments.ssr / environments.prerender) don't get around that either; I tried both.
2. satteri as an explicit dependency of the app. Under bun's isolated node_modules layout a transitive dep isn't resolvable from apps/astro-example/dist/, so externalizing without declaring just moves the failure to Cannot find package 'satteri'. Pinned at the version leadtype uses.

Verified: 51 pages built, exit 0.

3. SvelteKit ignore drift

The SvelteKit example generates into static/ rather than public/. The two ignore lists had drifted — feeds/, mcp.json, robots.txt, schema-map.xml, and both sitemaps were ignored under public/ but not under static/ — so bun run build left six untracked build artifacts in the tree, one git add -A away from being committed.

The lists now mirror each other and both use apps/*/, so a future example with either output root is covered without a third list to keep in sync.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 46 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: df75239c-3823-41a6-895b-fd3d9f035d3a

📥 Commits

Reviewing files that changed from the base of the PR and between add9551 and 5bf1235.

⛔ Files ignored due to path filters (1)

• bun.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• .gitignore
• turbo.json

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Added support for the satteri parser in the Astro example application.
  • Improved handling of native components during builds.

• Chores

  • Updated ignore rules for generated documentation and build output.
  • Streamlined type-checking workflows across example applications.
  • Improved build and validation task ordering for more reliable checks.

• Tests

  • Improved isolation and reliability of temporary-file cleanup checks.

Walkthrough

The Astro example adds satteri and externalizes its native bindings through Vite. Workspace validation now follows upstream build tasks. The repository ignores generated outputs, and the cleanup test uses an isolated temporary directory.

Changes

Astro native parser and validation updates

Layer / File(s)	Summary
Native parser dependency and bundling apps/astro-example/package.json, apps/astro-example/astro.config.mjs	The Astro example adds satteri version ^0.9.3. Its Vite plugin externalizes satteri imports.
Validation task ordering apps/*/package.json, turbo.json	Example check-types scripts no longer build leadtype locally. Turbo now orders check-types after upstream build and check-types tasks.
Generated output ignore rules .gitignore	The ignore file documents separate generated-output roots and adds patterns for generated documentation, feeds, metadata, robots files, schema maps, and sitemaps.
Isolated cleanup test packages/leadtype/src/cli.test.ts	The cleanup test uses a test-owned TMPDIR, restores the environment, and checks for leftover generated directories there.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

A rabbit checks the Astro trail,
Native bindings stay outside the rail.
satteri joins the careful run,
Type checks follow builds already done.
Temporary files leave none behind.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the three primary fixes in the example apps and Turbo task graph.
Description check	✅ Passed	The description directly explains the task graph, Astro build, and SvelteKit ignore-list changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/example-app-build-hygiene

---

_{Comment @coderabbitai help to get the list of available commands.}

[pullfrog]

ℹ️ Both fixes are sound — a few rough edges inline, none blocking.

Reviewed changes — full review of 888dab2: the Astro native-binding workaround and the .gitignore generalization.

• Astro build fix — a local Vite plugin (astro.config.mjs 6-33, registered at 36-38) marks satteri and @bruits/satteri-* external from a resolveId hook, keeping leadtype's napi-rs MDX parser out of the prerender chunk.
• satteri declared on the app — added to apps/astro-example/package.json dependencies at ^0.9.3, so the externalized import resolves from dist/ under bun's isolated layout.
• .gitignore generalization — the five apps/sveltekit-example/static/* entries become eleven apps/*/static/* entries mirroring the apps/*/public/* list, plus a comment on why two lists exist.
• bun.lock — records the new dependency and incidentally corrects packages/leadtype 0.3.1 → 0.4.2.

I verified the .gitignore half end-to-end and it is correct and complete. Out roots are public for astro/fumadocs/next/nuxt and static for sveltekit only (c15t and tanstack ignore public/ wholesale locally), so apps/*/public/ + apps/*/static/ is the right pair. Every out-root artifact is now covered under both roots — feeds/schema.jsonl and schema-map.xml (src/nlweb/artifacts.ts:8-9), root mcp.json (src/mcp/card.ts:228), .well-known/, both llms*.txt, robots, both sitemaps — with search-index.json / agent-readability.json covered by docs/ and the configured /changelog/*.xml feeds covered by changelog/. Nothing tracked sits under the broadened glob (apps/astro-example/public/styles.css is the only tracked file there, matched by no pattern).

I also confirmed the plugin's blast radius is safe even though it applies to every Vite environment: the client graph cannot reach satteri, since the app's only client-side leadtype imports are leadtype/webmcp and leadtype/search/client, whose Rollup entries transitively reach none of the four satteri importers.

ℹ️ Nothing builds the example apps in CI, so both of these will regress silently

ci.yml builds, lints, typechecks and tests packages/leadtype only — no job runs astro build or any other example build. That is precisely why both of these breakages sat in main unnoticed until someone ran bun run build by hand, and why nothing stops either from coming back. The .gitignore half is self-healing once merged, but the Astro plugin is a load-bearing workaround with no test pinning it.

Technical details

# Example app builds are not covered by CI

## Affected sites
- `.github/workflows/ci.yml:32-53` — the `validate` job runs `bun run --filter leadtype build`, `lint`, `check-types`, `test`. Every step is scoped to `packages/leadtype`; no example app is ever built.
- `apps/astro-example/astro.config.mjs:24-38` (new) — the workaround this PR adds has no regression guard. If a future refactor drops the plugin, or `leadtype`'s import graph changes so `satteri` arrives by another path, CI stays green.

## Required outcome
- A merge-blocking signal that fails when an example app can no longer build, covering at minimum the Astro example that this PR just repaired.

## Suggested approach (optional)
- Add a job (or matrix leg) that runs `bun run --filter astro-example build` after the `leadtype` build + `Link CLI` steps. Note the example's `build` script already chains `bun run --filter leadtype build && bun run docs:generate`, so it is close to self-contained.
- A matrix over the example apps is the fuller version, but it is meaningfully slower — one Astro leg buys most of the protection for this specific PR.

## Open questions for the human
- Is leaving the examples out of CI a deliberate cost/runtime tradeoff? If so, this is fine to close — but then the Astro workaround is worth a comment noting it is unguarded.
- Would you rather this land as a follow-up issue than expand the scope of this PR?

ℹ️ Nitpicks

• bun.lock:228 also corrects packages/leadtype 0.3.1 → 0.4.2, drift left behind by release commit b5857b4 rather than anything in this PR. Harmless to carry here, but worth knowing it rode along given ci.yml:30 and release.yml:55 both run bun install --frozen-lockfile.
• apps/{next,nuxt,sveltekit}-example/test-results/.last-run.json are tracked in git — Playwright output committed in exactly the way this PR's .gitignore comment warns about. test-results/ is ignored only in apps/tanstack/.gitignore:6, and those three apps have no local .gitignore. Pre-existing and out of scope, but adjacent enough to mention; note it needs git rm --cached as well as an ignore entry, so it is not a one-line fix.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

Important

The check-types half of the race is fixed correctly, but the identical rm -rf dist race is still live in turbo run build.

Reviewed changes — delta since the prior review of 888dab2; the new commit 81adabb is the task-graph fix.

• Moved the leadtype build into turbo's task graph — check-types becomes dependsOn: ["^build", "^check-types"] (turbo.json:16-18), so packages/leadtype/dist is produced once ahead of every dependent.
• Dropped the per-app self-build — the bun run --filter leadtype build && prefix comes out of all seven apps' check-types scripts.
• Refreshed a tracked generated artifact — apps/next-example/app/generated/docs-mdx-map.ts is re-sorted and gains nine doc routes (mdxSlugs 41 → 50), which also widens generateStaticParams.

I confirmed the diagnosis rather than taking it from the description: packages/leadtype/rollup.config.ts:66-71 has a cleanDist plugin doing rm("dist", { recursive: true, force: true }) in buildStart, and apps read dist by literal path — apps/next-example's docs:generate runs bun ../../packages/leadtype/dist/cli.js — so concurrent self-builds really do delete dist out from under a sibling mid-read.

The turbo semantics are right. ^build and ^check-types reference only upstream workspace dependencies, so packages/leadtype's own check-types node gets an empty prerequisite set — no self-build, no cycle. Nothing outside turbo invokes an app's check-types either: ci.yml:50 runs bun run --filter leadtype check-types only, .husky/pre-commit runs ultracite fix plus bun test, and root package.json:21 (turbo run check-types) is the sole in-repo consumer. Direct bun run --filter <app> check-types on a clean checkout does now fail, but that is the intended consequence of moving ordering into turbo, not a regression to undo — re-adding the prefix would reintroduce the race.

The docs-mdx-map.ts refresh is genuine generator output, not a hand edit: apps/next-example/scripts/build-mdx-map.mjs sorts with .sort(), the new file is sorted and the old one was not.

⚠️ turbo run build still lets seven parallel self-builds rm -rf the same dist

check-types is fixed; build is untouched. turbo.json:5-9 already had dependsOn: ["^build"], and all seven apps/*/package.json build scripts still begin with bun run --filter leadtype build. Turbo dedupes its own packages/leadtype#build node, not a raw shell command sitting inside a sibling task's script body — so after leadtype builds once, seven concurrent apps/*#build tasks each re-invoke rollup, each hitting cleanDist while a sibling is reading dist/cli.js. That is the same failure this PR exists to fix, in the task where a wiped dist is most likely to be observed.

Technical details

# The `dist` race is fixed for `check-types` but left live for `build`, `dev`, `mcp` and `test:e2e`

## Affected sites
- `turbo.json:5-9` — the `build` task (unmodified) is `dependsOn: ["^build"]`, exactly the shape that made the `check-types` prefix redundant. Nothing was removed from the app scripts to match.
- `apps/astro-example/package.json:9`, `apps/c15t-example/package.json:9`, `apps/fumadocs-example/package.json:9`, `apps/next-example/package.json:10`, `apps/nuxt-example/package.json:9`, `apps/sveltekit-example/package.json:9`, `apps/tanstack/package.json:8` — every `build` script still opens with `bun run --filter leadtype build &&`. None of these lines are in the diff.
- `apps/*/package.json` `dev` (all seven) plus `apps/tanstack/package.json:11` (`mcp`) and `:13` (`test:e2e`) carry the same prefix. `dev` is lower risk in practice because root `package.json:18` filters it to `tanstack` alone.
- `packages/leadtype/rollup.config.ts:66-71` — `cleanDist` runs `rm("dist", { recursive: true, force: true })` in `buildStart`, so each redundant invocation opens a window where `dist` does not exist.
- `packages/leadtype/package.json` `build` is `rollup -c ... && bun run --silent docs:generate` — a plain bun subprocess when reached via `--filter`, invisible to turbo's graph and cache, so there is no dedup or locking.

## Required outcome
- `turbo run build` must not be able to delete `packages/leadtype/dist` while a sibling app task is reading it — the same guarantee `81adabb` establishes for `check-types`.
- Whatever is decided, the `turbo.json` comment should describe the state the repo is actually in.

## Suggested approach (optional)
- Drop the `bun run --filter leadtype build &&` prefix from the seven `build` scripts and rely on the existing `^build`, mirroring what this commit did for `check-types`. `dev`, `mcp` and `test:e2e` are the same one-line change if you want them consistent.

## Open questions for the human
- Is the prefix kept in `build` deliberately, so `bun run --filter <app> build` stays self-sufficient for someone who bypasses turbo? That goal and race-freedom are in direct conflict, and `check-types` has now picked the other side — worth making the split explicit rather than incidental.
- No CI job runs `turbo run build` or `turbo run check-types`, so neither the fix nor the remaining hazard is exercised anywhere. Does that change how much you want to invest here versus in the CI gap?

ℹ️ Nitpicks

• apps/c15t-example/README.md:25-26 still says "The dev, build, and check-types scripts all rebuild the local leadtype package", which is no longer true for check-types. It is the only README in the repo making that claim.
• apps/next-example/app/generated/docs-mdx-map.ts is stamped Generated by scripts/build-mdx-map.mjs — do not edit and is rewritten by docs:prepare before every build and check-types, yet it is tracked — so it re-dirties the working tree on every run, which is how it came to ride along in a commit about the task graph. Same hygiene family as this PR's .gitignore change, and worth deciding whether it should be ignored instead. The refresh itself is a real improvement: nine doc routes were missing from generateStaticParams on main.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

Important

Three of the four comment corrections are right. The fourth replaces an imprecise claim with a false one — and the false claim is the reason the remaining dist race won't get fixed.

Reviewed changes — delta since the prior review of 81adabb; the new commit 39223d4 rewrites four comments and deletes one dead code path. Only astro.config.mjs and turbo.json changed.

• Corrected the Astro plugin's causation comment — the inaccurate noExternal attribution is gone, replaced by "monorepo-specific: leadtype is a linked workspace package, so it is bundled rather than externalized", and the record that resolve.external plus Astro 6's environments.ssr / environments.prerender equivalents were both tried is retained.
• Deleted the unreachable @bruits/satteri- resolver arm — the hook is now if (id === NATIVE_PARSER) and NATIVE_PARSER_BINDING is removed (astro.config.mjs:38).
• Documented the satteri version coupling — a comment at astro.config.mjs:6-9 explains that externalizing makes the import resolve to this app's copy, so leadtype's range must be kept in step.
• Rewrote the turbo.json check-types comment — the count is corrected to seven and the scripts still carrying the self-build prefix are now named.

I verified the resolver-arm deletion is behavior-preserving rather than taking it on the comment's word. satteri/dist/index.js:13-14 statically imports only the #binding subpath, which maps to dist/binding.js; that file reaches its platform binding through createRequire(import.meta.url) followed by a runtime require('@bruits/satteri-*') — a call expression Rollup's static specifier discovery cannot see. Independently, a resolveId returning { external: true } bypasses the load/transform pipeline entirely, so index.js is never parsed once satteri is external. Nothing in the repo, in leadtype's built dist, or in packages/leadtype/src references a binding id statically. The arm was dead before this PR, and removing it is safe.

The count in the turbo.json comment is also now correct: exactly seven app check-types scripts carried the prefix, and none carry it after 81adabb.

ℹ️ Nitpicks

• apps/astro-example/astro.config.mjs:6-9 — the new coupling comment sits above const NATIVE_PARSER = "satteri", a module specifier rather than a version range, so "Kept in step with packages/leadtype/package.json's range" reads as though this line held the range. Someone bumping satteri at apps/astro-example/package.json:23 never passes it. package.json is strict JSON and cannot carry the note itself, so there may be nowhere strictly better — but naming the dependency line explicitly in the wording would close the gap.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@turbo.json`:
- Around line 13-20: Remove the nested `bun run --filter leadtype build`
invocation from each app’s `build` script so app builds no longer independently
rebuild `leadtype`. Rely on the root Turbo `build` dependency configuration,
including the existing `^build` behavior, to build `leadtype` once before
dependents.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6ab5f081-dee6-4b56-b2aa-e67ea1d3a17c

📥 Commits

Reviewing files that changed from the base of the PR and between 81adabb and 39223d4.

📒 Files selected for processing (2)

• apps/astro-example/astro.config.mjs
• turbo.json

📜 Review details

⏰ Context from checks skipped due to timeout. (1)

• GitHub Check: pullfrog

🔇 Additional comments (1)

apps/astro-example/astro.config.mjs (1)

6-9: LGTM!

Also applies to: 21-43, 45-48

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/leadtype/src/cli.test.ts`:
- Around line 2203-2234: Update the temporary-directory setup around runCli to
set TMPDIR, TMP, and TEMP to privateTmpDir, then restore or delete each variable
according to its original value in the finally block. Keep the existing leak
scan unchanged so it checks the directory actually used by the CLI across
platforms.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 283c4945-9be8-47b7-ac7f-7ce6207e70bb

📥 Commits

Reviewing files that changed from the base of the PR and between 39223d4 and add9551.

📒 Files selected for processing (1)

• packages/leadtype/src/cli.test.ts

📜 Review details

⏰ Context from checks skipped due to timeout. (1)

• GitHub Check: pullfrog

🧰 Additional context used

📓 Path-based instructions (3)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{ts,tsx}: Use explicit types for function parameters and return values when they enhance clarity
Prefer unknown over any when the type is genuinely unknown
Use const assertions (as const) for immutable values and literal types
Leverage TypeScript's type narrowing instead of type assertions

Files:

• packages/leadtype/src/cli.test.ts

**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{js,ts,jsx,tsx}: Use meaningful variable names instead of magic numbers - extract constants with descriptive names
Use arrow functions for callbacks and short functions
Prefer for...of loops over .forEach() and indexed for loops
Use optional chaining (?.) and nullish coalescing (??) for safer property access
Prefer template literals over string concatenation
Use destructuring for object and array assignments
Use const by default, let only when reassignment is needed, never var
Always await promises in async functions - don't forget to use the return value
Use async/await syntax instead of promise chains for better readability
Handle errors appropriately in async code with try-catch blocks
Don't use async functions as Promise executors
Remove console.log, debugger, and alert statements from production code
Throw Error objects with descriptive messages, not strings or other values
Use try-catch blocks meaningfully - don't catch errors just to rethrow them
Prefer early returns over nested conditionals for error cases
Extract complex conditions into well-named boolean variables
Use early returns to reduce nesting
Prefer simple conditionals over nested ternary operators
Don't use eval() or assign directly to document.cookie
Avoid spread syntax in accumulators within loops
Use top-level regex literals instead of creating them in loops
Prefer specific imports over namespace imports
Use descriptive names for functions, variables, and types for meaningful naming
Add comments for complex logic, but prefer self-documenting code

Files:

• packages/leadtype/src/cli.test.ts

**/*.{test,spec}.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{test,spec}.{js,ts,jsx,tsx}: Write assertions inside it() or test() blocks
Avoid done callbacks in async tests - use async/await instead
Don't use .only or .skip in committed code
Keep test suites reasonably flat - avoid excessive describe nesting

Files:

• packages/leadtype/src/cli.test.ts

🪛 ast-grep (0.45.0)

packages/leadtype/src/cli.test.ts

[warning] Importing child_process exposes a command-execution surface; ensure any command/argument built from input is validated, and prefer execFile/spawn with an argument array over exec.
Context: import { execFile } from "node:child_process";
Note: [CWE-78] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').

(detect-child-process-typescript)

[pullfrog]

ℹ️ The test change is sound and genuinely falsifiable — two nitpicks, neither blocking.

Reviewed changes — delta since the prior review of 39223d4; the new commit add9551 touches packages/leadtype/src/cli.test.ts and nothing else.

• Scoped the temp-dir leak assertion to a private TMPDIR — the test "cleans up mirrored sources when the generate pipeline fails" no longer snapshots leadtype-generate-* in the shared os.tmpdir() before and after runCli and diffs the two sets. It creates a private dir, points process.env.TMPDIR at it for the duration of the CLI call, and globs only that dir.
• Restored the env in a finally — including the originally-unset case, so the mutation cannot outlive the runCli call.

I mutation-tested the assertion rather than trusting that the override lands: patching createSourceMirror's cleanup (packages/leadtype/src/cli/generate.ts:2553) to a no-op makes the test fail with + ["/tmp/leadtype-cli-XXXX/leadtype-generate-XXXX/"]. So the override is effective and the assertion can still catch the leak it exists to catch — the usual failure mode for this refactor, where the glob silently starts pointing at an always-empty directory, is not present here.

No coverage is lost relative to the old glob either. Every tmpdir() call site under src/ sits inside a function rather than a module-level constant (cli/generate.ts:2244,2531, internal/generate-lock.ts:73, source/index.ts:439, openapi/index.ts:2114), so all of them re-read process.env.TMPDIR per call, and this test's code path spawns no subprocess that could inherit a stale env. The comment's stated flake mechanism also checks out: generateLockPath returns leadtype-generate-<key>.lock and tryAcquire creates it with mkdir (internal/generate-lock.ts:167), so despite the suffix it is a directory and did match the old glob's onlyDirectories: true — a concurrent worker's lock landing inside the before/after window really was misattributable. And the env mutation cannot leak: tests in this file are sequential (no .concurrent), and vitest workers hold independent process.env copies. privateTmpDir itself comes from createTempDir() (cli.test.ts:97), so afterEach (cli.test.ts:156) already removes it.

ℹ️ Nitpicks

• packages/leadtype/src/cli.test.ts:2204 — os.tmpdir() reads TEMP/TMP on Windows and ignores TMPDIR entirely, so there privateTmpDir stays empty and expect(leakedTempDirs).toEqual([]) passes vacuously rather than failing. CI is ubuntu-only (ci.yml:19) so there is no merge-gate impact, but a Windows contributor loses the assertion silently. Setting TMP/TEMP alongside TMPDIR would close it if the repo cares about that platform.
• The PR title and body still describe "three pre-existing breakages in the example apps and task graph". This commit is a fourth change, and a test-flake fix in packages/leadtype is neither an example app nor the task graph — worth a line in the body so the merge commit records why it rode along.

Note on scope: add9551 does not touch turbo.json, so the open thread on turbo.json:16-18 from the previous review is unaffected and stays open.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[KayleeWilliams]

Rebased onto origin/main.

None of the three original fixes had landed: check-types still lacked ^build, the example check-types scripts still self-built leadtype, Astro still had no satteri externalization, and .gitignore still only covered a subset of SvelteKit static/ outputs. Those are replayed on current main.

Also dropped the later cli.test.ts TMPDIR change — main already absorbed a different fix for that flake — and corrected the turbo comment so it no longer claims build is not run concurrently (5bf1235).

[pullfrog]

✅ No new issues found.

Reviewed changes — delta since the prior review of add9551: the branch was rebased onto main at 76af4e4 and 5bf1235 corrects the turbo.json comment. Both open threads from earlier reviews are now resolved.

• Corrected the check-types comment's concurrency claim — turbo.json:18-21 no longer says the other scripts "are not run concurrently by turbo". It now states that turbo run build fans the seven app builds out as siblings after packages/leadtype#build, so those nested rebuilds can still race, and that the fix is scoped to check-types rather than repo-wide.
• Rebased onto current main — the packages/leadtype/src/cli.test.ts temp-dir fix and the apps/next-example/app/generated/docs-mdx-map.ts refresh both left the PR, bringing it back to the three changes the title and body describe.
• bun.lock version correction moved with it — packages/leadtype now reads 0.3.1 → 0.4.3, matching packages/leadtype/package.json exactly.

The rewritten comment is accurate, which is the thing the previous review blocked on. I re-checked each clause: turbo.json:5-9 still gives build only dependsOn: ["^build"], all seven build scripts still open with bun run --filter leadtype build &&, and root package.json:17 is an unfiltered turbo run build — so "those nested rebuilds can still race" is exactly right, and the count of seven matches the seven apps and seven now-prefix-free check-types scripts. Your note on the thread that the prefix is kept deliberately so standalone bun run --filter <app> build stays self-sufficient answers the design question that section was really asking; treating it as a separate change is a reasonable call.

The rebase does not stale anything. satteri is still imported from five files under packages/leadtype/src/, so the Astro workaround is still load-bearing, and apps/astro-example/package.json:23 is still identical to packages/leadtype/package.json:212 at ^0.9.3. The test-flake fix that dropped out was superseded rather than lost — main now narrows the same glob to source-mirror dirs at cli.test.ts:2292-2305.

I also re-verified the .gitignore half against the newer main's generator rather than assuming the earlier check still held, since roughly thirty commits of docs-pipeline work landed underneath it. Every write rooted at the CLI's out dir still lands inside the eleven ignored entries: docs/i18n-manifest.json (cli/generate.ts:1239), .well-known/agent-card.json (llm/skills.ts:243), both llms*.txt and their .well-known/ twins, docs/agent-readability.json plus .well-known/api-catalog, robots and both sitemaps (llm/llm.ts), feeds/schema.jsonl and schema-map.xml (nlweb/artifacts.ts:89-90), and mcp.json plus the two MCP cards (mcp/card.ts:227-229). The two top-level writers that would escape the list — generateAgentsMd's AGENTS.md and bundle-mode's root SKILL.md — are both gated behind args.bundle (generate.ts:1975), which no app passes.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}