turbo.json

{
  "$schema": "https://turborepo.com/schema.json",
  "tasks": {
    "//#typecheck": {
      "dependsOn": ["@loopover/engine#build"],
      // Root tsconfig.json's own "include" list ("src", "test", plus a handful of named config files) is
      // NOT a complete accounting of what tsc actually type-checks: "include" only seeds the starting file
      // set, and tsc's real surface expands to everything transitively imported from there, regardless of
      // whether the imported file physically lives inside src/ or test/. test/** (deliberately included so
      // Codecov's codecov/patch has one source of truth, see the plan doc referenced in ci.yml) turned out
      // to reach via relative-path imports into six other workspace packages/apps -- confirmed by grepping
      // every import in src/+test/ that crosses a packages/**or apps/** boundary, not just spot-checked:
      // packages/loopover-miner/{lib,bin}/**, packages/loopover-mcp/package.json (JSON import), packages/
      // discovery-index/src/**, apps/loopover-ui/src/lib/**, apps/loopover-extension/**, and apps/loopover-
      // miner-extension/**. Before this was added, none of those six were hashed, so an edit to (say)
      // packages/loopover-miner/lib/opportunity-fanout.js could silently leave a stale cache HIT here even
      // though a real `tsc --noEmit` would fail -- exactly the class of bug PR #5082 (see ci.yml's "Build
      // engine package" comment) already burned this repo on once. packages/loopover-mcp/bin/** is
      // deliberately NOT listed: every test reference to it is a runtime path string
      // (`join(process.cwd(), "packages/loopover-mcp/bin/loopover-mcp.js")`, spawned as a subprocess or
      // read as raw text), never a static import, so its contents don't affect tsc's type-checked surface.
      // This list is a snapshot of test/'s real cross-package reach as of the audit that added it, not a
      // structural guarantee -- a future test file importing from a NOT-yet-listed package/app would
      // reopen the same silent-stale-cache gap. Re-run the same grep (every src/+test/ import crossing a
      // packages/**or apps/** boundary) before trusting this list again, especially before ever wiring the
      // "Typecheck" ci.yml step through this task (it still calls plain `npm run typecheck` today,
      // specifically because tsc's own --incremental engine already tracks this exact transitive graph
      // precisely and correctly, without needing a hand-maintained approximation of it here at all -- see
      // that step's own comment in ci.yml).
      "inputs": [
        "src/**",
        "test/**",
        "scripts/check-engine-parity.ts",
        "worker-configuration.d.ts",
        "vitest.config.ts",
        "vitest.workers.config.ts",
        "drizzle.config.ts",
        "tsconfig.json",
        "package.json",
        "package-lock.json",
        "packages/loopover-miner/lib/**",
        "packages/loopover-miner/bin/**",
        "packages/loopover-mcp/package.json",
        "packages/discovery-index/src/**",
        "apps/loopover-ui/src/lib/**",
        "apps/loopover-extension/**",
        "apps/loopover-miner-extension/**"
      ],
      "outputs": []
    },
    "@loopover/engine#build": {
      "outputs": ["dist/**"]
    },
    "@loopover/ui-kit#build": {
      "outputs": ["dist/**"]
    },
    "@loopover/ui-kit#typecheck": {
      "outputs": []
    },
    "@loopover/discovery-index#build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    // apps/loopover-ui/src also imports three files this app has no formal package.json dependency on:
    // root src/signals/redaction.ts (from lib/browser-sentry.ts), root src/signals/focus-manifest.ts (from
    // lib/registration-workspace.ts) -- both real, always-bundled production imports -- and
    // packages/loopover-engine/src/miner/driver-factory.ts (from a .test.tsx file, so typecheck-only, not
    // build). None of these were hashed before, so a change to any of them with apps/loopover-ui itself
    // unchanged could give a false cache HIT on this task -- the same class of bug already found and fixed
    // in the root //#typecheck task, just missed here during that audit. Confirmed via grep: `grep -rn
    // "\.\./\.\./\.\./\.\./" apps/loopover-ui/src` finds exactly these three cross-boundary imports, no
    // others. @loopover/engine#build is added as an explicit dependsOn edge (rather than hand-listing
    // driver-factory.ts as an input) since engine has no default inputs override -- its whole src/** is
    // already hashed by that task, so depending on it transitively covers this file (and any other engine
    // file a future test might import) without needing to track individual paths here too.
    "@loopover/ui#typecheck": {
      "dependsOn": ["^build", "@loopover/engine#build"],
      "inputs": [
        "$TURBO_DEFAULT$",
        "$TURBO_ROOT$/worker-configuration.d.ts",
        "$TURBO_ROOT$/src/env.d.ts",
        "$TURBO_ROOT$/src/signals/redaction.ts",
        "$TURBO_ROOT$/src/signals/focus-manifest.ts"
      ],
      "outputs": []
    },
    "@loopover/ui#lint": {
      "outputs": []
    },
    // Same two root src/signals files as @loopover/ui#typecheck above -- both real production imports
    // (src/client.ts and src/routes/__root.tsx transitively pull them in), so vite's actual bundle depends
    // on them. Previously had no inputs override at all (bare $TURBO_DEFAULT$, own directory only). Does
    // NOT need the engine dependsOn edge @loopover/ui#typecheck has: the only file reaching into
    // packages/loopover-engine is imported from a .test.tsx file, which isn't part of the production build.
    "@loopover/ui#build": {
      "dependsOn": ["^build", "@loopover/extension#build", "@loopover/miner-extension#build"],
      "inputs": [
        "$TURBO_DEFAULT$",
        "$TURBO_ROOT$/src/signals/redaction.ts",
        "$TURBO_ROOT$/src/signals/focus-manifest.ts"
      ],
      "outputs": ["dist/**"]
    },
    // apps/loopover-miner-ui/src (typecheck) imports from packages/loopover-miner/lib/chat-action-registry
    // /chat-action-dispatch/chat-governor-actions -- 5 files reaching in via relative path, with no
    // package.json dependency on @loopover/miner to create a ^build edge, and no existing inputs override
    // (bare $TURBO_DEFAULT$). Same class of bug as @loopover/ui#typecheck above. Scoped to the whole
    // packages/loopover-miner/lib/** directory (not the 5 specific files) to match the same "don't
    // hand-track an ever-growing cross-package surface" reasoning already applied to //#typecheck's fix --
    // this UI already imports 5 files from that one directory, more is a matter of when, not if.
    "@loopover/ui-miner#typecheck": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/packages/loopover-miner/lib/**"],
      "outputs": []
    },
    "@loopover/ui-miner#lint": {
      "outputs": []
    },
    // apps/loopover-miner-ui's root-level vite-*-api.ts dev-server plugins (vite-attempt-api.ts,
    // vite-chat-api.ts, and 7 others) contain 14 dynamic import()s reaching into
    // packages/loopover-miner/lib/** and one into packages/loopover-engine/dist/index.js -- same
    // directory added defensively as @loopover/ui-miner#typecheck above. These execute inside vite's
    // configureServer request-handler hooks (vite dev only), so they likely don't affect this task's
    // actual `vite build` bundle output -- but that's inference from reading the plugin code, not proven
    // the way the typecheck gap above was, so the input is added here too rather than left asymmetric.
    "@loopover/ui-miner#build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", "$TURBO_ROOT$/packages/loopover-miner/lib/**"],
      "outputs": ["dist/**"]
    },
    "@loopover/extension#lint": {
      "outputs": []
    },
    "@loopover/extension#typecheck": {
      "outputs": []
    },
    // NOT declaring outputs here would be wrong, not just uncached: confirmed empirically (rm -rf'd
    // apps/loopover-ui/public/downloads/loopover-extension.zip, ran `turbo run build --filter=@loopover/ui`
    // against a warm cache, the zip never came back -- a cache HIT replays logs but restores nothing when
    // no outputs are declared). This build's real output crosses a package boundary
    // (apps/loopover-ui/public/downloads/loopover-extension.zip, written by scripts/build-extension.ts),
    // and Turborepo's docs are silent on whether cross-package "outputs" globs are honored on restore --
    // rather than rely on undocumented behavior, this task is never cached at all, so it always actually
    // executes (cheap, a handful of files) whenever something depends on it. That's what actually closes
    // the "@loopover/ui#build might silently ship without the extension zip" gap this graph edge exists
    // to fix -- caching this task and getting the restore wrong would be worse than not caching it.
    "@loopover/extension#build": {
      "cache": false
    },
    "@loopover/miner-extension#lint": {
      "outputs": []
    },
    "@loopover/miner-extension#typecheck": {
      "outputs": []
    },
    // No cross-package writes here (unlike @loopover/extension#build above) -- but keep the same
    // never-cached treatment for consistency with its sibling, since both are cheap and this avoids two
    // different caching policies for what's otherwise the same shape of package.
    "@loopover/miner-extension#build": {
      "cache": false
    },
    "@loopover/mcp#build": {
      "dependsOn": ["^build"],
      // Was `[]` (log-only caching, correct back when bin/lib's compiled .js was always committed --
      // present via git regardless of whether turbo actually ran tsc or replayed a cached log). Now that
      // compiled output is gitignored (build(mcp,miner): stop committing compiled .js/.d.ts entirely),
      // `[]` means a cache HIT never restores the real files turbo never snapshotted, only replays the
      // log text -- confirmed live: validate-tests' 3 parallel shards share one turbo-tests- cache key,
      // and whichever shard's Save lands first can make a LATER shard's Restore see a "hit" for content
      // it never actually built on that runner, leaving bin/lib empty while the log claims success
      // (#7705 CI, shard 2 vs. shard 1/3 on the same commit). Declaring the real outputs makes a hit
      // restore the actual files instead of only the log.
      "outputs": ["bin/**/*.js", "lib/**/*.js"]
    },
    "@loopover/miner#build:tsc": {
      "dependsOn": ["^build"],
      "cache": false
    },
    "@loopover/miner#build:verify": {
      "dependsOn": ["@loopover/miner#build:tsc"],
      "inputs": ["bin/**/*.js", "lib/**/*.js"],
      "outputs": []
    },
    "@loopover/miner#build": {
      "dependsOn": ["@loopover/miner#build:tsc", "@loopover/miner#build:verify"],
      "cache": false
    }
  }
}