@fanalis/orchestrator

per-route audit driver. takes a url + a list of pillar adapters + options; returns a single AuditReport.

entry

runAudit(url, pillars, {
  tier,           // 1..5
  noDownloads,    // refuse to fetch new models
  siteType,       // override the auto-detected genre ("saas" / "ecommerce" / etc)
  log,            // (msg) => void
  models,         // ModelLoader (defaults to createLoader())
  llm,            // LLMRunner | null
  visionLLM,      // VisionLLMRunner | null (post-v1)
  auditId,        // pin a stable id (the CLI does this so reports replay)
  keepBrowser,    // don't closeBrowser() at end (for batch mode)
}) → AuditReport

what one call does

1. detect hardware → pick budget per tier (TIER_BUDGETS[tier].budgetSec)
2. renderUrl(url) → AuditContext (from @fanalis/render)
3. site-type classification (saas / ecommerce / docs / etc) for composite genre-weighting, unless caller overrides
4. Promise.allSettled over pillars, each wrapped in withTimeout(p.runAtTier(ctx, opts), budget * 1000, p.id). failures yield a neutral 50-score finding with the error message — never a missing pillar
5. computeComposite(pillarScores, siteType) from @fanalis/core — power-mean with genre weights
6. signature = sha256 of {engineVersion, tier, siteType, weights, pillarIds.sort()} truncated to 16 chars. lets the same report fingerprint identify identical engine configs across runs.
7. unless keepBrowser, closeBrowser() from @fanalis/render

what's NOT here

• source-pass modules (those run from the CLI directly via @fanalis/repo; the orchestrator only drives the render-pass pillars)
• saved-report persistence (the CLI uses @fanalis/models/reports for that)
• llm narrative end-of-audit summary (the CLI does that — orchestrator just forwards the llm runner into pillars)

caveats

• runAtTier is per-pillar's responsibility. timeout is enforced from the outside; long-running pillars get killed and yield the neutral fallback.
• the orchestrator is stateless across calls. concurrency comes from the CLI parallel-route batch (--concurrency N → Promise.all(batch.map(runAudit))). lighthouse runs inside the perf pillar are mutex-serialised via withLighthouseLock in @fanalis/pillar-performance/lighthouse.ts — they can't all spawn chrome simultaneously even with high route concurrency.
• audit.lighthouse is filled by the perf pillar inside runAtTier, not by the orchestrator. the rest of the pillars see it via ctx.lighthouse only if it ran before them — which is why perf is typically registered early in the pillar array.