FAQ

Questions, answered plainly

If you're new to Preview Dog, start here. If something's missing, open an issue and we'll add it.

The basics

What is Preview Dog?: A small banner you drop into any non-production build. It lets reviewers leave feedback, approve a build, and ask plain-language questions about open issues — without leaving the page.
How does feedback become a GitHub issue?: Click the pill, write a note, optionally point at a piece of text on the page. The handler enriches the note, picks a priority, and opens an issue on your repo with a back-link to the page and build.
Does Preview Dog ever show up in production?: No. It's gated on environment in the host app — production deployments don't render it. The package itself is opt-in: nothing ships unless you wire it up.

What does ‘Approved’ actually do?: A signed-in reviewer can mark the current commit production-ready. The approval is stored as a comment on a dedicated GitHub tracking issue, scoped to that commit. Every revoke records a reason so the history reads like a clean diary.
Can I revoke an approval?: Yes. Click the green check, write a short reason, and submit. The reason goes onto the tracking issue alongside the revoke marker — easy for the team to scan later.
Why a tracking issue and not a database?: GitHub is durable, auditable, and already part of the team's workflow. A database can come later; the marker format is forward-compatible.

Which issues show up in the bar?: By default, every open issue on the configured repo. Hosts can pass a `visibilityLabel` (e.g. `visible-on-site`) to gate which issues surface — useful when only a subset belongs in the reviewer view.
How do I sort and filter?: The Issues panel has a sort dropdown (priority, newest, recently updated, most discussed) and a label dropdown that lists every non-internal label across the loaded issues. Active chips show what's filtered and clear with one click.
Why don't I see Preview Dog's own tracking issue?: It's labeled `preview-dog:meta` and excluded from the visible list — internal plumbing, not a reviewer concern.

What can I ask the bot?: Anything that can be answered from the open issues: bugs by area, what's blocking sign-off, what changed since last preview, what needs design eyes. It cites the issues it used.
Is my context shared with the LLM?: The bot sees the current open issues and the site context the host provides. It does not see the page's DOM unless you paste it in. Reviewer-typed `Add context` is treated as data, not instructions.

What environment variables do I set?: All `PREVIEW_DOG_*`: token, repo, passphrase, session secret, and an optional `PREVIEW_DOG_VISIBILITY_LABEL`. The package never reads `process.env` directly — values flow through the handler config.
How do I install the package?: Once published on npm: `npm install @creo-team/preview-dog`. Mount the bar on non-production builds and point it at a route running `createDogBarHandler`.

Questions, answered plainly

If you're new to Preview Dog, start here. If something's missing, open an issue and we'll add it.

What is Preview Dog?: A small banner you drop into any non-production build. It lets reviewers leave feedback, approve a build, and ask plain-language questions about open issues — without leaving the page.
How does feedback become a GitHub issue?: Click the pill, write a note, optionally point at a piece of text on the page. The handler enriches the note, picks a priority, and opens an issue on your repo with a back-link to the page and build.
Does Preview Dog ever show up in production?: No. It's gated on environment in the host app — production deployments don't render it. The package itself is opt-in: nothing ships unless you wire it up.

What does ‘Approved’ actually do?: A signed-in reviewer can mark the current commit production-ready. The approval is stored as a comment on a dedicated GitHub tracking issue, scoped to that commit. Every revoke records a reason so the history reads like a clean diary.
Can I revoke an approval?: Yes. Click the green check, write a short reason, and submit. The reason goes onto the tracking issue alongside the revoke marker — easy for the team to scan later.
Why a tracking issue and not a database?: GitHub is durable, auditable, and already part of the team's workflow. A database can come later; the marker format is forward-compatible.

Which issues show up in the bar?: By default, every open issue on the configured repo. Hosts can pass a `visibilityLabel` (e.g. `visible-on-site`) to gate which issues surface — useful when only a subset belongs in the reviewer view.
How do I sort and filter?: The Issues panel has a sort dropdown (priority, newest, recently updated, most discussed) and a label dropdown that lists every non-internal label across the loaded issues. Active chips show what's filtered and clear with one click.
Why don't I see Preview Dog's own tracking issue?: It's labeled `preview-dog:meta` and excluded from the visible list — internal plumbing, not a reviewer concern.

What can I ask the bot?: Anything that can be answered from the open issues: bugs by area, what's blocking sign-off, what changed since last preview, what needs design eyes. It cites the issues it used.
Is my context shared with the LLM?: The bot sees the current open issues and the site context the host provides. It does not see the page's DOM unless you paste it in. Reviewer-typed `Add context` is treated as data, not instructions.

What environment variables do I set?: All `PREVIEW_DOG_*`: token, repo, passphrase, session secret, and an optional `PREVIEW_DOG_VISIBILITY_LABEL`. The package never reads `process.env` directly — values flow through the handler config.
How do I install the package?: Once published on npm: `npm install @creo-team/preview-dog`. Mount the bar on non-production builds and point it at a route running `createDogBarHandler`.