v0.1.3

Added

• Claude Code plugin. /plugin marketplace add yotambraun/saylent, then /plugin install saylent@saylent, adds the MCP server and four skills: gate-check (free crawler-access check), audit (shows the keys it found and the estimated cost, and asks before spending), verify (re-asks the frozen questions after your fixes) and read-report (summarizes an existing run). See the Claude Code plugin.
• The MCP audit dry run says what a real run would do. It now reports which providers have a key (never the key itself), the engines that would be asked, the judge mode and whether the run would start, and prices only the engines that have a key, the same way saylent audit --dry-run does.

Changed

• Dependencies refreshed within their existing major versions, including the Anthropic and Google provider SDKs, the MCP SDK (1.31), Next.js 16.3.7, React 19.3 and zod 4.6. Every test, the type check, the lint, the app build and the CLI dry run pass on the new set.

Fixed

• The GitHub Action resolves again. uses: yotambraun/saylent@v0 failed in every workflow because the repository was published without the Action's action.yml. It now ships with the built entry point it runs, and a test fails the release if either is ever missing again.
• The site's changelog page lists every release. It skipped any release heading that carried a date, so it showed no entries.

v0.1.2

Changed

• One computed cost range, everywhere - both READMEs, the docs, .env.example, the landing page and the CLI preflight now quote the same two numbers, computed by the same estimator the app shows before a run: about $0.60 to $1.20 for a smoke run across four engines and about $3.70 to $5.50 for a full one. The old "$2.50 to $4.00" contradicted the product's own screenshot. A unit test recomputes both from the estimator and fails if the published copy drifts.
• The site check is named once - the free, keyless check (saylent gate-check) is "the site check" on the docs page, in the sidebar, on the landing card and in both READMEs, instead of seven different names for one feature.
• Docs headings match the site - /docs/* headings and the sidebar wordmark are set in the landing page's display serif at the same weight, so clicking "Docs" no longer changes the typographic voice. Body copy stays Inter.
• Docs reorganized into six sections - Run it once, Keep score as a team, Operate it for others, Automate, Understand, Project - in the same order and under the same names on the docs sidebar, the docs start page, the landing page and this repository's README. Every existing docs URL still resolves: nothing moved, the grouping is the sidebar's own. New pages, all lifted from where the content already lived: Questions and models, Verify and history, Check again next month, Share, export and track fixes, Users and access, and one page each for the GitHub Action, the MCP server and the library. The operator screenshots now live on The operator console rather than in the middle of the app tour.

Added

• Docs: a visual tour of the app (/docs/tour) - every screen of the self-hosted app in the order you meet them (run, read, act, verify, operate), in both themes, with a link that opens each user screen in the live demo; the operator console - setup readiness, provider keys, models per role, spend cap and kill switch, the run feed, the audit log, takedowns and one account end to end - is shown for the first time. The page closes with a feature map of what the app adds over the CLI and the GitHub Action. Every image, and the new app.gif on the README and the landing page, is generated by npm run media from a running deployment and regenerated on every release.
• Docs: the operator console (/docs/self-host/admin) - every admin page in the order an operator meets them: /setup readiness rows and what each blocking row means, Providers and models (env vs console keys, APP_SECRET, what each model role does, the free Test key check), Budget and limits (spend cap, throttles, brand cap, exactly what the kill switch stops), Users (who becomes admin, promoting another, disabling an account), Runs (health badges, re-run, retry, mark failed), Support and Takedowns (what unpublishing a share does), Analytics (the activation funnel) and the Audit log.
• Docs: sharing, export and the fix tracker in Reading a report - creating and revoking a public unlisted link, what a reader of one gets, the takedown path, the CSV / JSON / run-bundle exports (the bundle is URL-only, with no button in the app), and the open → shipped → watched fix lifecycle with its win-rate line.
• Docs: users and access in Self-host - who can sign up to a deployment, the three ways to limit that, how a teammate joins, what a user can and cannot do next to an operator, and the per-account brand limit.
• Docs: scheduled verifies without a database in the CLI reference - a cron entry and a scheduled GitHub Actions job for saylent verify, where the movement report lands, and when to deploy the app instead.
• Docs: infrastructure cost in What it costs - the Supabase and Vercel free-tier limits that actually matter for a small team, and why scheduled runs need Inngest rather than platform cron.

Fixed

• Settings › Notifications no longer promises a movement email. Two transactional emails send: the report when an audit finishes, and a day-10 reminder to re-measure. The row now says which, and says plainly when the deployment has no email configured at all.

v0.1.1

Fixed

• The GitHub Action is consumed as yotambraun/saylent@v0, the floating tag that follows this 0.x line; the README shipped inside the npm package said @v1.
• The CLI's bin entry is stored in the form npm expects, so publishing no longer reports an auto-correction.

v0.1.0

First public release. Saylent is an open-source audit of what AI assistants
say about your brand: every verdict traced to the answer, the cited page,
and a fix.

Added

• saylent CLI (npx saylent audit <domain>): runs a full audit with
  no database, using your own OpenAI and Anthropic API keys (Gemini and
  Perplexity optional). Nine commands: audit, verify (movement against a
  frozen baseline), gate-check (alias check; a $0, no-LLM pass/fail on
  AI-bot access, JSON-LD, and meta directives), report (re-render a saved
  run), history (list a folder of run bundles), keys (store and test
  provider keys), questions (print or edit the buyer-question set),
  models (print the resolved model registry), and mcp (a Model Context
  Protocol server on stdio for agents).
• @saylent/engine: the audit pipeline as a standalone package, zero
  Next.js/Supabase/Inngest/React dependency. Crawls a site, derives a brand
  model, generates and freezes a question set, asks each configured answer
  engine, judges the answers with a cross-family LLM judge, aggregates
  citations, runs the site's bot-access and structured-data checks, and
  diagnoses weighted fixes.
• @saylent/report: pure report composers and renderers, shared by the
  CLI and the app so both produce the same output. Renders a run to
  Markdown (report.md) and to a self-contained, dark/light, print-clean
  report.html with the same components the full app uses.
• The run bundle format (run.json): a lossless, versioned record of a
  run, including raw answer text, the frozen question set, engine subset,
  model versions, and cost, so a run can be replayed, re-rendered, or used
  as a verify baseline without a database.
• Self-hosted app: the full dashboard, brand history, verify, compare,
  and share-link experience, deployable on your own Supabase project plus
  Inngest for jobs. Three supported run targets: locally on one machine
  (npm run app:local), on your own server via Docker, or on Vercel with
  the Supabase and Inngest integrations pre-wired. First sign-up on a fresh
  deployment becomes the operator/admin.
• Operator budget controls: a daily spend cap, per-kind throttles, and
  a kill switch, all self-hosted-first (no billing provider involved).
• saylent.config.ts: project-level configuration (question templates
  and quotas, competitor list, engine subset, profile overrides, crawler
  user agent, locale), read by the CLI and the engine's config loader alike -
  branding is validated by the same schema but not yet read by anything
  downstream. See Configuration
  reference for the
  full key-by-key table.
• Extension points: an engine adapter is one file implementing Ask; a
  site check is one registry entry in domainChecks.ts; a fix family is one
  rule in diagnose(); a report block is one case in the BriefBlock
  union plus its renderer. See CONTRIBUTING.md and ARCHITECTURE.md.
• The golden set: a labeled set of judged answers, with raw answer text
  inlined and no database required, that anyone can rerun
  (scripts/judge-golden.ts) to check agreement before and after a
  judge-rubric change - a live pass costs about $0.20 in judge calls;
  --offline replays the stored verdicts instead, at $0.
• Docs site with the quickstart, CLI reference, self-host guides, and the
  methodology behind what is measured, sampled, and diagnosed, and what is
  explicitly not claimed.