DocsReference

Review source in a Git repository

Register a checkout, inspect current source and store reviewed work with the project.

On this page

Open a local Git checkout in Studio to review its website or supported source files. Studio reads the working copy, shows its source version and keeps decisions and tasks beside the source.

Identify the revision#

In File and Git, check the source file, branch, resolved commit and local changes before reviewing. Refresh after an external edit. You can also inspect the checkout directly:

sh
git branch --show-current
git rev-parse HEAD
git status --short

A clean file and a clean repository are different states. If the review uses uncommitted changes, retain those contents with the review; the base commit alone cannot reproduce them. For a running website, record its build identity as well. The current checkout does not establish what a previously started server or the published website is rendering.

Git storage#

Git stores the project's source and the review records selected for version control. Studio writes its current records into the registered project:

text
.voice-lint/
  reviews/<document-id>.voice-meta.json
  tasks/<document-id>/<task-id>.json
  semantic-runs/<run-id>/
  backups/<document-id>/
  transactions/

The storage reference explains these files and includes complete JSON examples. Studio does not create commits or alter the project's ignore rules. Check the diff before committing review data: task/run files can contain full source, prompts and model output; transaction journals include a local backup path. Keep session credentials and installation registry files outside shared review records.

Review against a page goal#

Record the intended audience, page purpose and claims to preserve in the source task's instruction. Include the relevant approved context; when it comes from a separate marketing repository, record that repository's commit and file path. Studio does not automatically import a marketing context repository.

Review the mapped passages, keep intentional wording and save specific feedback. For a broader change within one supported file, create and explicitly start a source task. Its result retains the source version, run and proposed diff. Read the complete diff before applying it, then run the configured project check and inspect the rendered page.

Studio's project report aggregates file findings. Its current semantic review and source tasks operate on one file with configured related context. A site-wide SEO, consistency or visual assessment requires a separately scoped agent task; there is no built-in holistic evaluator or AGT pipeline step yet.

Retain the result#

Keep the reviewed source, task/run records and relevant evidence together. Include the capture time, route, viewport and build for screenshots, plus the command and result for checks. A source hash detects changes but cannot restore the source. Saved proposals show the task's historical diff; use Git for the current diff.

To check source and optional saved-task provenance against a running Studio:

sh
npm run test:source-provenance -- --help

The command documents the required project/file arguments and writes a compact report under test-results/. It does not infer a deployed website revision.

Git and source reference

Source for this page: docs/holistic-review.md. Content hash and Git revision: Build record.

Download the Markdown source
Next guideUse AI findings in your application →