ScopeProof

See which acceptance criteria have credible PR evidence—and which still need review.

ScopeProof is a reviewer-controlled acceptance-coverage assistant for public GitHub pull requests. The primary-operator hypothesis is an engineer or technical QA reviewer, with a PM or requirements owner receiving the report; these roles remain unvalidated. It maps each confirmed criterion to inspectable implementation or test candidates, makes missing evidence visible, records attributable human decisions, and exports a reproducible review. The primary workflow has a product target of reaching an inspectable coverage report in under five minutes. That target has not yet been independently observed. The former Stage 1 under-ten-minute target closed unmet when the owner chose not to pursue Stage 1.

ScopeProof is an evidence assistant. It does not replace QA, engineering review, runtime testing, or human acceptance.

Current direction: maintain a bounded engineering reference product. The published evaluation download is v0.2.4, with its wheel, source archive, and checksums verified in the public verification record. The current source/package identity is 0.2.5.dev0, unreleased. Stage 1 is closed as not pursued with all external counts at zero; Stage 3 is dormant and gated. Stage 2 work requires a demonstrated defect, required upkeep, or a named bounded research question. Once that work and its checks are complete, stop; there is no standing feature backlog or request for personal testing or qualifying reviews. See the public roadmap for the maintenance finish line and official-source market comparison for substantial competing workflows and the remaining value hypothesis.

The R-001 Microsoft public-PR research record shows a compact, hash-bound engineering rerun: observed CI and static candidates remain distinct from runtime verification and human acceptance. It is public engineering research only and does not advance Stage 1.

The R-002 SWE-bench Verified static engineering benchmark adds a frozen 20-case, 12-repository deterministic baseline for candidate matching and immutable references. It executes no target code and contributes zero Stage 1 validation credit.

Controlled demo screenshot—not a customer case. It shows deterministic candidate evidence and missing-evidence states; it is not runtime verification or proof of correctness. See the deliberately constructed demo for the expected findings.

Why this exists

AI coding agents can produce pull requests quickly, but a green CI check does not establish that every ticket promise was implemented. Product reviewers still need to answer questions such as:

• Did export include every active filter?
• Is the failure state visible to the user?
• Was the required analytics event added?
• Does a test exercise the requested behavior, or does a similarly named test merely exist?
• Did the pull request expand scope beyond the approved requirement?

ScopeProof turns that review into a requirement-to-evidence matrix. It shows why each candidate matched and what remains unverified.

MVP boundaries

• The repository is published under an evaluation-only use policy and does not grant an open-source license.
• No paid LLM API and no model-generated verdicts.
• Supports public repositories only.
• Anonymous GitHub access works without a token.
• An optional GitHub token can increase free rate limits; it remains in Streamlit session memory and is never exported or saved.
• Users author and confirm criteria. ScopeProof does not invent product requirements.
• Pull-request code is never executed.
• Static candidates cannot be presented as runtime verification.
• General bug review, security scanning, automatic fixes, private repositories, Jira, billing, and team accounts are outside this release.

Evidence and review language

Level	Meaning in this MVP
E0	No candidate evidence found
E1	Candidate implementation or contract evidence
E2	Candidate test evidence that still requires reviewer confirmation
E3	Runtime verification recorded manually from an external check
E4	Explicit human acceptance

The workbench describes criterion evidence as Strong candidate, Weak candidate, No candidate, Analysis incomplete, Reviewer verified, or Rejected. Candidate strength is not correctness. Implementation, test, runtime, documentation, and contract evidence remain separate types.

New source analyses record a bounded core-source identity for later inspection; older reviews retain an unknown identity. That hash covers ScopeProof core Python source, not the UI, dependencies, environment, signed provenance, or proof of execution. See the engine identity boundary.

The release gate uses explicit precedence:

1. Action required for failed checks, change-required decisions, or unresolved must-have gaps.
2. Review incomplete for unconfirmed criteria, partial ingestion, unavailable checks, ambiguous evidence, or unresolved decisions.
3. Accepted with exceptions for explicitly accepted exceptions.
4. Review complete only after complete ingestion, passing observed CI, current decisions for every criterion, and final human acceptance.

Release and historical engineering references

The earlier post-merge v0.2.3 audit found two core integrity defects in the intended flow. PR #177 repaired those findings, PR #179 merged the completed workbench UX change, and PR #180 merged the exact-head runtime-evidence hardening as product commit 2a320df966eff30c05a2b1dce607a247201fa165.

The merged v0.2.3 exact-head runtime-evidence hardening binds each effective E3/E4 decision to exactly one runtime record for the same repository, pull request, reviewed head, criterion, reviewer, and evidence level. Version 1 and 2 local records migrate to version 3 without inventing links: legacy-unlinked manual decisions remain visible but become Needs Review until verification is re-recorded at the active head. It also exposes immutable provenance in the workbench and every export, shows skipped-check limits outside collapsed details, and provides a safe draft-clear recovery for revised bundle-less reviews. Independently verified PR head ed9f9c0cf6b7cf7cc25403d6138e7a8391f55e0f has the same product tree, add81a2d0ba7e64f8e4318a1959bbe7e6e4acfc8, as the merge commit. Stage 0's engineering foundation is restored. PR #183 merged the later integrity and reviewer-loop source work as cd362a85a558645a0f56d6540f6bf035e5821809; exact-main CI run 30847416893, CodeQL run 30847415556, and Pages run 30847417705 succeeded. Those runs remain historical source-integration evidence, not correctness evidence, customer validation, or Stage 1 credit.

ScopeProof v0.2.3 is published. PR #184 merged the release integration at 448c42758ea139bf9203cbf1bb04b02b02ae412c; the peeled v0.2.3 tag resolves to that release baseline. At the 2026-08-08 branch-start snapshot, origin/main also resolved to that commit. Exact-main CI run 30854382641, CodeQL run 30854382413, and Pages run 30854382659 succeeded. The release and those checks are engineering evidence only. Stage 1 later closed as not pursued with every external- evidence count still at zero. The exact-head verification audit records the product-tree engineering evidence and remaining gaps.

ScopeProof v0.2.4 is published from 11bcdc66f7d8f5a29055688208de1ed337eed07f, with its wheel, source archive, and checksums verified in the public verification record. Post-v0.2.3 engineering merged CLI lifecycle commands, strict saved-record validation, installed Chromium coverage, Python 3.13 and bounded keyboard/focus evidence, and verified-public provenance enforcement. Those changes remain engineering evidence only. Current source/package identity is 0.2.5.dev0, unreleased; Stage 1 remains closed as not pursued with every count at zero.

GitHub exposes visible check runs but does not reliably expose every repository's required-check policy to anonymous clients. ScopeProof therefore labels this value Observed CI state and counts only explicit success as passing.

Quickstart

Python 3.11 is the declared minimum. See the supported environment and engineering coverage for the tested Python versions, platform limits, and contributor setup.

The published evaluation download is v0.2.4. Its GitHub Release contains scopeproof-0.2.4-py3-none-any.whl, scopeproof-0.2.4.tar.gz, and SHA256SUMS.txt. The public verification record binds the published assets to source 11bcdc66f7d8f5a29055688208de1ed337eed07f. A source version, changelog entry, or passing CI run alone is not publication evidence. Current source 0.2.5.dev0 is unreleased.

The commands below install the published v0.2.4 wheel and require no clone. Verify its checksum before installation. See the release preparation and upgrade notes for release boundaries and saved-record guidance. The documentation map separates current guidance from historical observations. No personal testing or qualifying review is required to download or evaluate the package.

python3 -m venv .venv
source .venv/bin/activate
curl -LO https://github.com/YuzeJ21/Scope-Proof/releases/download/v0.2.4/scopeproof-0.2.4-py3-none-any.whl
curl -LO https://github.com/YuzeJ21/Scope-Proof/releases/download/v0.2.4/SHA256SUMS.txt

Select the wheel entry from the published manifest and use the command for your platform:

# macOS
grep " scopeproof-0.2.4-py3-none-any.whl$" SHA256SUMS.txt | shasum -a 256 -c -

# Linux
grep " scopeproof-0.2.4-py3-none-any.whl$" SHA256SUMS.txt | sha256sum -c -

Continue only after the checksum check succeeds:

python -m pip install ./scopeproof-0.2.4-py3-none-any.whl "pydantic>=2.13.4,<3" "streamlit>=1.66.1,<2" "Pillow>=13,<14"
python -m pip check
scopeproof --version
scopeproof benchmark
scopeproof-web --host 127.0.0.1 --port 8501

A matching checksum verifies the downloaded bytes against the published manifest; it does not provide code-signing or product-correctness assurance. The offline benchmark checks the installed package and bundled constructed regression corpus. It is engineering evidence, not runtime evidence for a target pull request or customer validation. Stop the local workbench with Ctrl+C.

The explicit dependency constraints follow the current maintained UI baseline. The wheel's older Streamlit API minimum is not a promise that every permitted resolution satisfies current patch guidance. In the dated dependency assessment, Streamlit 1.53.0 required Pillow below 13 and could not use the documented patched Pillow baseline. Pydantic 2.8.0 passed the smaller package journeys but failed existing R-002 strict JSON validation tests; the guidance uses the locked Pydantic baseline instead of promising full floor compatibility. The published wheel and its checksum remain unchanged; the constraints select its dependencies. Unreleased 0.2.5.dev0 source now declares these maintained floors directly, including Pillow; see the source declaration alignment.

Upgrade existing reviews

The v0.2.4 release writes saved-record format v5. Back up local review storage and retain any exported reports before upgrading. Pre-v5 records are conservatively reassessed: missing criteria-source provenance, verified-public metadata, or exact-head changed-file inventory is not invented, and prior acceptance may require renewed confirmation or analysis. Historical engine identity and candidate-selection counts remain unknown when absent. Reopening a record does not establish current-head correctness. Compatibility with older versions after saving in v0.2.4 is not promised; see the release preparation and upgrade notes.

Public PR CLI workflow

The commands below describe the published v0.2.4 CLI. They also apply to the current unreleased 0.2.5.dev0 source checkout after the locked source setup; they do not apply to the historical v0.2.3 wheel. The examples use the installed scopeproof command. In a source checkout, prefix it with uv run. The CLI provides read-only public-PR ingestion and a deterministic core without starting Streamlit. Live ingestion labels a review public only when GitHub returns matching, unambiguous repository metadata (private: false and visibility: public). A token-accessible private repository and missing, malformed, or contradictory visibility metadata fail closed before review data is saved. Historical records without that verified fact remain readable but cannot qualify for Stage 1. First create requirements.txt with one atomic criterion per line. A human requirements owner or authorized role must inspect and approve the exact file before creating the confirmation record. --confirmed-by is that human's explicit attestation; ScopeProof does not verify their identity, authority, or the criteria's correctness. Every retained line is therefore reviewer-confirmed criteria, not criteria inferred or approved by ScopeProof.

scopeproof prepare-requirements-confirmation \
  --requirements requirements.txt \
  --source-uri https://github.com/OWNER/REPOSITORY/blob/FULL_SHA/path/to/requirements.txt \
  --source-revision FULL_SHA \
  --confirmed-by "Requirements owner or authorized role" \
  --output requirements-confirmation.json

scopeproof validate-requirements-confirmation \
  --requirements requirements.txt \
  --confirmation requirements-confirmation.json

scopeproof review --pr https://github.com/OWNER/REPOSITORY/pull/123 \
  --requirements requirements.txt \
  --confirmation requirements-confirmation.json \
  --storage-dir .scopeproof/reviews \
  --report scopeproof-review.md

The preparation command performs no network request, computes both hashes from the exact UTF-8 bytes and ordered normalized criteria, and refuses to overwrite an existing confirmation file. The optional report path may end in .md, .json, .csv, or .html; ScopeProof validates the selected export and refuses to overwrite an existing file.

The command prints JSON containing the local review_id, record path, head SHA, and provisional gate verdict, plus the requested report path. Use the review identifier later to repeat the export or choose another format:

scopeproof export REVIEW_ID \
  --storage-dir .scopeproof/reviews \
  --format markdown

Available repeat-export formats are json, markdown, csv, and html.

Continue the same validated local review through the CLI with explicit human decisions. Store reviewer notes in UTF-8 files when they are needed:

scopeproof resolve REVIEW_ID \
  --criterion-id AC-01 \
  --decision accepted \
  --reviewer "Reviewer name or role" \
  --comment-file reviewer-note.txt \
  --storage-dir .scopeproof/reviews

scopeproof scope-file REVIEW_ID \
  --head-sha EXACT_HEAD_SHA \
  --path src/generated-client.py \
  --disposition outside_confirmed_criteria \
  --reviewer "Reviewer name or role" \
  --comment-file file-scope-note.txt \
  --storage-dir .scopeproof/reviews

scopeproof verify-runtime REVIEW_ID \
  --criterion-id AC-02 \
  --level E3 \
  --reviewer "Runtime reviewer" \
  --artifact-reference https://example.test/artifacts/run-123 \
  --scenario "Exercise the confirmed acceptance scenario" \
  --environment "Owner-operated staging environment" \
  --result "Observed result supplied by the reviewer" \
  --comment-file runtime-note.txt \
  --storage-dir .scopeproof/reviews

scopeproof final-acceptance REVIEW_ID \
  --accept \
  --reviewer "Final reviewer" \
  --comment-file final-note.txt \
  --storage-dir .scopeproof/reviews

scopeproof compare PREVIOUS_REVIEW_ID CURRENT_REVIEW_ID \
  --format markdown \
  --output comparison.md \
  --storage-dir .scopeproof/reviews

Each inspectable changed file is bound to the reviewed head. An uncited file prevents Ready until it has an explicit, explained reviewer decision that it falls outside the confirmed criteria. Use --disposition within_confirmed_criteria --criterion-id AC-01 to record that a file belongs to a criterion; that decision does not replace a candidate citation. A skipped file leaves ingestion partial and cannot be waived through scope-file. Old saved reviews without a verified inventory remain Needs Review and require a new exact-head analysis. File decisions do not prove tests ran or that the implementation is correct.

The v0.2.4 release can also inspect and append one bounded local JUnit XML artifact without executing target-repository code. First inspect the sanitized scope IDs:

scopeproof inspect-junit results.xml

Create a strict mapping document that records an explicit human relationship rather than inferring one from test names:

{
  "schema_version": "junit-mapping-v1",
  "artifact_sha256": "COPY_THE_64_CHARACTER_DIGEST_FROM_INSPECT_JUNIT",
  "selections": [
    {"scope_id": "suite-0001", "criterion_id": "AC-01"}
  ]
}

Then append the validated import to the exact-head saved review:

scopeproof import-junit REVIEW_ID results.xml \
  --mapping junit-mapping.json \
  --importer "Asserted reviewer name or role" \
  --storage-dir .scopeproof/reviews

The adapter accepts at most 1 MiB, 100 suites, 5,000 cases, and 20,000 XML elements. Each review can retain at most 20 imports, and each retained warning or asserted limitation is capped at 1,000 characters. The byte cap is exactly 1,048,576 bytes. In published v0.2.4, the browser upload control can reject a valid file at that exact cap on non-Windows browsers; use inspect-junit and import-junit above for the full byte range. The unreleased 0.2.5.dev0 source fixes the upload allowance while preserving the exact parser cap; see the version-bound reproduction. The adapter accepts UTF-8 only and rejects DTDs, entities, non-declaration processing instructions, XInclude, remote references, unsupported nesting, and ambiguous result markers. It stores computed statuses, stable local scope IDs, the artifact SHA-256, exact review and criteria provenance, explicit mappings, an asserted importer, warnings, and limitations. Raw XML, stdout, stderr, properties, failure bodies, commands, paths, URLs, and attachments are discarded; path- or URL-like suite/class/test names are replaced with deterministic redacted labels. The CLI mapping digest must match the selected artifact before any saved-review mutation. An import is external, non-gating context—not E1, E2, E3, E4, observed CI, runtime verification, human acceptance, final acceptance, or proof that a criterion passed. Failed inspection, mapping, validation, or storage does not mutate the saved review.

resolve records one human criterion decision and never executes PR code. Static candidates never become runtime evidence through resolve; accepting below a criterion's required evidence level requires a non-empty reviewer note. verify-runtime is the only CLI command above that atomically links a human-supplied E3/E4 runtime record to its manual-verification decision. It does not run or independently verify the cited artifact. Final acceptance remains fail-closed until the deterministic prerequisites are satisfied; use --revoke to append a revocation. compare validates both saved reviews, reports candidate changes without carrying decisions forward, reports imported-artifact and mapping changes separately, and refuses to overwrite an existing output file. Changed imported context can require a previous human decision to be reviewed again, but it never carries, creates, or changes that decision or either gate.

CSV exports neutralize leading spreadsheet-formula characters in scalar text cells. Fields that can contain multiple values (ingestion_warnings, skipped_files, evidence_links, missing_evidence, runtime_artifacts, runtime_result, and imported-JUnit fields) are JSON arrays inside their CSV cells so delimiters in repository or reviewer text do not destroy provenance.

In v0.2.4, every CSV criterion row also carries the review-level gate_reason_codes, gate_blocking_criteria, gate_conditional_criteria, gate_unresolved_criteria, gate_resolved_exceptions, and gate_guidance as JSON arrays. These appended columns preserve the reason and next action when a row is filtered or shared; for example, accepted criterion decisions can still require final acceptance. They explain the existing validated gate and do not change a decision or establish correctness.

New v0.2.4 analyses also record eligible_candidate_count, candidate_limit, and omitted_candidate_count in retrieval diagnostics. The workbench and human-readable reports explain how many passing matches were shown or omitted during the existing bounded selection; JSON and CSV retain the validated counts. The limit remains eight, and identical duplicates may also be suppressed. Historical diagnostics keep these fields unknown (null), never inferred as zero. Selection counts explain the search and do not prove criterion satisfaction.

Anonymous public-repository access is the default. --token is optional and can increase GitHub's free rate limit, but it is not required or persisted. The CLI never comments on the pull request, executes its code, or converts static candidates into runtime verification.

Contributor setup

For a fully pinned setup, use the reproducible development environment. The standard editable setup remains available below.

Read the evaluation-only use policy before cloning or proposing a contribution. Public visibility does not grant permission beyond evaluation and review.

Clone the repository to run the Streamlit workbench or contribute changes:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
streamlit run apps/web/app.py

Open the displayed local URL, then choose either path:

1. Select Load deliberately constructed demo for a complete offline walkthrough.
2. Enter a public GitHub PR URL, fetch it, paste one criterion per line, and confirm the criteria. Session-only tokens and bounded unchanged candidate paths are under Advanced source options.

The six review sections are:

1. Start Review.
2. Confirm Criteria.
3. Decision Progress.
4. Criterion Review.
5. Evidence Matrix.
6. Summary & Export.

Criterion Review contains the selected criterion evidence, separate external JUnit context, external verification, and human resolution controls. Summary & Export provides the Markdown, JSON, and CSV review records.

Durable local review workflow

The workbench keeps criteria revisions and append-only resolution history. Adding, removing, splitting, reordering, or editing criteria invalidates the previous analysis and requires explicit reconfirmation before another review run. Human decisions and final acceptance are recorded as history rather than silently replacing earlier decisions.

Local review storage

The workbench stores versioned JSON records under ~/.scopeproof/reviews. The reopen panel lists safe local record IDs in deterministic order, while an empty store retains manual ID recovery. The app validates the selected record when it is opened and refuses a configured review path if it or any ancestor is a symbolic link or reparse point, or if an existing path component is not a directory. This app-owned local directory prevents a browser input from selecting arbitrary file paths. Saved review, alpha-case, and owner-rehearsal JSON records each have a 64 MiB UTF-8 byte limit on save and reopen; oversized records fail with a local-storage error rather than being parsed or treated as partial evidence. Records preserve the review SHAs, criteria revisions, evidence, bounded imported-JUnit envelopes, findings, resolution history, and gate decision. They never contain raw JUnit XML or the optional GitHub token. A reopened review prepares its public PR URL and bounded unchanged-candidate paths for a one-click current-head check rather than silently reusing old evidence. Records also preserve whether public repository visibility was verified; legacy records without that fact remain explicitly unverified. After a new analysis, the workbench compares previous and current heads, candidates, finding states, reviewer decisions, and review status without mutating either bundle. Candidate evidence is classified as Unchanged, Relocated, Modified, Added, or Removed. Changed candidates show both the previous and current immutable location and excerpt so the reviewer can inspect what moved or changed before recording a new decision. Exact unchanged candidates remain inspectable in a collapsed section, and the validated comparison can be downloaded as Markdown or JSON. This comparison does not prove criterion satisfaction or carry a prior human decision forward. Imported JUnit artifacts are compared separately by digest and explicit mapping signature as Unchanged, Added, Removed, or Mapping modified. This projection does not reinterpret test names, copy decisions, or make imported results a gate input.

From the CLI, run scopeproof list to return the safe local review IDs in the default .scopeproof/reviews directory; add --storage-dir PATH only when earlier CLI commands used that same alternative directory. The command lists identifiers in deterministic order and does not parse review contents. This local inventory is not review, test, runtime, or correctness evidence.

To delete one saved review in the workbench, select its listed ID, then check Permanently delete the selected local review. From the CLI, run scopeproof delete REVIEW_ID; add --storage-dir PATH only for a review saved outside the default CLI directory. Deletion removes only that app-owned JSON record. Exported reports remain user-owned and are not removed, and deletion is not secure erasure of storage media or backups. An open deleted review remains available as unsaved session work until it is replaced or the session ends.

Deliberately constructed demo

The bundled CSV export case is a deliberately constructed demo, not a real incident. Its PR-shaped fixture implements CSV export, one active filter, and a happy-path test. It intentionally omits another filter, the error state, and the research_exported event.

Expected output:

Criterion	Expected finding
AC-01 Export CSV	Strong candidate
AC-02 Respect all active filters	Weak candidate
AC-03 Show export failure	No candidate
AC-04 Record research_exported	No candidate

The review status is Action required because must-have gaps remain.

Verification

The packaged-browser suite currently contains eleven checks: one full installed-wheel Chromium journey, four constructed Streamlit selection checks, and six helper/capture checks. The total is not a count of full end-to-end journeys. These constructed engineering checks do not establish independent use or accessibility conformance.

Run lint and all offline tests:

python -m ruff check .
python -m pytest -q

Run the labeled regression benchmark:

uv run scopeproof benchmark
uv run scopeproof comparison-benchmark

The first command executes 12 executable benchmark cases for acceptance coverage, rather than treating a static category list as coverage. The equivalent module entry point is python -m scopeproof_core.evals.runner. It reports executed case and criterion counts, False Ready, False Blocker, case-level mismatches, immutable evidence-link errors, and unexecuted required categories. It exits nonzero when a known must-have False Ready, label mismatch, evidence-link error, or unexecuted category is present.

The second command executes two paired previous/current review cases and checks deterministic re-review classification, including exact Unchanged coverage and conservative handling of ambiguous duplicate candidates. This corpus is deliberately constructed engineering evidence. It does not advance Stage 1. It does not prove correctness. It does not constitute customer validation. It does not show external use. Both benchmark commands execute local JSON inputs only; they do not run fixture repository code.

Run the opt-in live public GitHub smoke test:

RUN_LIVE_GITHUB_TESTS=1 python -m pytest tests/github/test_live_public_pr.py -q

Check the running Streamlit server:

curl --fail http://127.0.0.1:8501/_stcore/health

Architecture

Public GitHub PR
      ↓
Read-only ingestion
      ↓
User-confirmed criteria
      ↓
Deterministic candidate retrieval
      ↓
Provisional findings + human resolution
      ↓
Deterministic gate
      ↓
Markdown / JSON / CSV / HTML

scopeproof_core contains Pydantic contracts, ingestion, retrieval, verification, gates, reporting, fixtures, and evaluation. It has no Streamlit dependency. apps/web/app.py is a thin local interface over those core services.

Every evidence item contains a file, line, immutable head SHA, GitHub permalink, excerpt, matching rule, relevance reason, deterministic score, and limitations. Deleted lines cannot become current implementation evidence. Partial ingestion cannot produce Ready.

GitHub file and commit ingestion follows pagination and has explicit file, patch, and total-diff limits. If GitHub does not provide inspectable patch text for a changed path, ScopeProof excludes that path, names it as skipped, and marks ingestion partial; it never treats missing diff content as a complete empty file. ScopeProof can also inspect a bounded unchanged candidate file when a caller explicitly justifies it. This evidence is labeled unchanged_candidate, anchored to the head SHA, and never means that the repository was scanned broadly.

Repository layout

apps/web/                 Streamlit review workbench
scopeproof_core/github/   Public GitHub ingestion
scopeproof_core/criteria/ Manual criterion preparation
scopeproof_core/retrieval/Deterministic evidence candidates
scopeproof_core/verification/Provisional findings
scopeproof_core/gates/    Release truth table
scopeproof_core/reporting/Markdown, JSON, CSV, and HTML exports
scopeproof_core/evals/    Regression runner
evals/                    Controlled fixtures and labels
tests/                    Unit, regression, AppTest, and live smoke tests

Privacy and trust

The application does not persist credentials or execute repository code. Review exports contain the repository, PR number, head SHA, ruleset version, criteria, evidence, findings, resolutions, and gate reasons. They do not contain the optional GitHub token.

Large or truncated diffs are labeled partial and force human review. Missing GitHub checks are represented as unavailable, never passing. A parser or retrieval failure must fail safely rather than produce Ready.

The privacy-readiness design documents current local-only retention, deletion responsibility, fork protection, and the future read-only private-repository boundary. It does not claim private support exists.

Product status

This is a public-repository reference product under bounded owner-led maintenance. That strategy does not establish customer validation, demand, adoption, repeat use, or willingness to pay.

The public roadmap defines the closed Stage 1 record, active owner-led Stage 2 scope, and separate owner gates for later stages. The changelog summarizes the active development line and links to authoritative published release notes. Neither document turns engineering work into customer evidence or human acceptance.

Standard reviews create no research record. Evaluation downloads do not require personal testing, a public case, a qualifying review, or participant feedback. Report a reproducible problem through the sanitized defect form, including the version or commit, minimal steps, and expected and actual behavior. Remove private code, tokens, customer data, and confidential material. Report security concerns through GitHub private vulnerability reporting, following the security policy.

ScopeProof is an acceptance-coverage assistant, not an AI code reviewer. Stage 1 is closed as not pursued (closed_not_pursued_by_owner) with all external counts at zero; owner-led Stage 2 remains bounded maintenance. Stage 3 is dormant and gated. The public-alpha participant quickstart preserves the historical alpha path; the optional design-partner protocol remains inactive until separately authorized. In that archived or separately authorized participant path, Alpha feedback session remains an explicit local opt-in under research options; Standard reviews create no research record. Only a completed genuine review with a participant-selected outcome can supply participant evidence; incomplete reviews earn no completed-review credit. No outreach, recruitment, paid product, billing, or customer validation follows from this evaluation release. The market-positioning research records hypotheses that still require genuine participant evidence.

The launch evidence matrix and archived LinkedIn preparation in the draft and playbook preserve prior launch research and its constructed-demo boundaries. The current policy is passive GitHub intake; those LinkedIn materials are not authorized for publication without a separate owner decision.

GitHub Action advanced preview

The default product is the local workbench. The checked-in GitHub Actions guide covers an advanced, non-blocking preview for repositories that make a separate operator decision to adopt it. It requires checked-in, hash-confirmed requirements and never checks out or executes pull-request head code. For a maintainer-labeled same-repository PR, it may publish the neutral-only ScopeProof evidence summary (informational) Check bound to the exact PR head and confirmed criteria-source snapshot. A same-head rerun updates that identity; a new head creates a new auditable Check identity. Removing the opt-in label updates an existing trusted exact-head identity to neutral Needs Review while retaining prior evidence for audit. Fork or missing token paths do not write, and a stale head or malformed GitHub response fails closed. Withdrawal uses a separate trusted-base-only event so conflicted PRs are covered without executing pull-request code; same-repository eligibility is based on repository identity, not whether the target repository itself is a fork. The Check is not a required branch-protection check. It is not part of first use and does not replace the reviewer-controlled workflow. Reviewer and source-owner identities remain asserted, not authenticated. This engineering surface does not prove correctness, runtime behavior, accessibility, demand, adoption, or customer validation, and it does not alter the closed Stage 1 counts.

Explicit local Definition-of-Done packs

scopeproof_core.rule_packs offers opt-in local prompts for error, loading, empty, analytics, authorization, API documentation, and migration coverage. They are never inferred or added to a review automatically. Each is labelled Implicit local rule and has an implicit_rule_pack source so it cannot masquerade as a user-confirmed source requirement; a reviewer must explicitly include and confirm it before analysis.

Evidence-quality metrics

scopeproof benchmark emits evidence_quality_metrics alongside its executed fixture results: immutable evidence-link precision, incorrect-line-citation rate, criterion agreement, criterion-level and uncited-file False Ready totals, and False Blocker totals. These measure only the checked-in, executed labels; they do not prove runtime correctness or market validation. Human override, accepted-exception, and unresolved-ambiguity rates are intentionally null unless calculated from selected persisted review histories.