Metadata-Version: 2.4
Name: deployment-verifier
Version: 1.0.0
Summary: Independent deployment verification for AI-built applications. AI proposes. Verifier proves.
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: typer>=0.9
Requires-Dist: pydantic>=2.0
Requires-Dist: pyyaml>=6.0
Requires-Dist: rich>=13.0
Requires-Dist: cryptography>=41.0
Provides-Extra: dev
Requires-Dist: pytest>=8.0; extra == "dev"

# Deployment Verifier

Independent deployment verification for AI-built applications.

**AI proposes. Verifier proves.**

The verifier is an independent verification layer. It does not replace the
application, the coding AI, or the deployment platform. It inspects reality,
produces evidence, identifies blockers, explains root causes, produces a
verdict, and hands verified facts to an external coding agent. It never
fixes code.

## Install

Requires Python 3.10+ on Windows 10/11 (x86-64; ARM64 where dependency
wheels are available).

```text
pip install deployment-verifier
verifier --help
```

No source checkout, no `PYTHONPATH`, no repository access needed after install.

## The product loop

```text
verifier verify <PROJECT>   # compact verdict + INSPECTION TOKEN
verifier inspect <TOKEN>    # detailed visual inspection in your browser
verifier handoff <TOKEN>    # evidence-based repair package for a coding AI
# ... external AI changes the application ...
verifier verify <PROJECT>   # new session, new token, updated verdict
```

## Commands

| Command | Behavior |
|---|---|
| `verifier verify <PROJECT>` | Run a complete deployment verification: discovery, static checks, sandboxed execution where applicable, evidence, findings, verdict. Prints a compact 15–30 line summary plus a prominent `INSPECTION TOKEN`. Exit 0 when ready, 1 when blocked, 2 on usage errors. |
| `verifier inspect <TOKEN>` | Open the detailed visual inspection for one verification session (localhost only). Prints the local URL and opens the browser. |
| `verifier status <PROJECT>` | Show the latest known verification state without rescanning: verdict, counts, top issue, latest token. |
| `verifier history <PROJECT>` | Show recent verification sessions with verdicts and tokens (`--limit N`, `--all`, `--json`). |
| `verifier handoff <TOKEN>` | Print a factual repair package for an external coding AI: verdict, blockers with evidence references, root causes, required actions, and the verify-after-fix command. Never invents fixes; secrets stay redacted. |
| `verifier --help` | Full product documentation for the five commands. |
| `verifier --version` / `verifier -v` | Print one line: `Deployment Verifier 1.0.0`. |

Examples:

```text
verifier verify C:\Projects\my-app
verifier inspect VRF-X7K92P
verifier status C:\Projects\my-app
verifier history C:\Projects\my-app
verifier handoff VRF-X7K92P
```

Internal engineering commands (`scan`, `discover`, `check`, `report`,
`machine-report`, `context-pack`, `graph`, `init`, `explain`,
`verify-url`, `post-deploy`, `open`) remain available for maintenance and
automation but are intentionally absent from public help. Notes:
`post-deploy` is an alias of `verify-url` (live URL gate, exit 0 only on
`VERIFIED_READY`); `open` is an alias of `inspect`; `explain` is a
deferred stub. The execution scheduler (`verifier/core/scheduler.py`) and
`verifier/adapters/` are documented future scaffolding, not load-bearing
(the engine walks checks sequentially; discovery is table-driven).

## Output and streams

The terminal is a summary surface: verdict, counts, top issues, token, next
command. `verifier verify` prints 15–30 lines by default (`--verbose` adds
the full check list and finding detail). Everything (product output and
human errors) goes to **stdout**; machine modes (`history --json`,
`report --format`, `machine-report`, `context-pack`, `discover --json`)
stay parseable, including JSON error objects on failure.

## Operations

- History is append-only SQLite per project (`.verifier/verifier.db`) plus a
  per-user token registry (`~/.verifier/inspect.db`). There is no automatic
  pruning: each session stores its full evidence payload, so the database
  grows with every verification. History display is bounded (recent 10 by
  default, `--limit/--all`).
- SQLite uses WAL with a 30 s busy timeout; concurrent verifications of one
  project serialize safely (unique scoped sequence + token retry).
- Requirements: Python 3.10+; external tools only as your project needs them
  (`node`/`npm` for Node builds, `python`/`pip` for Python, `git` for commit
  metadata, `docker` never required). No compiler needed: the package ships
  `py3-none-any` with `cryptography` wheels for x86-64 and ARM64.
- Tested: Windows 10/11 x86-64 (AMD and Intel treated identically).
  Windows 11 ARM64 is expected to work via upstream wheels but is
  **NOT VALIDATED** (no ARM hardware in the release environment);
  Windows 10 ARM64 is not validated either.

## What it does not do

No auto-fixing, no cloud provisioning, no deployment automation, no
dashboard product. Detailed analysis belongs in `verifier inspect`; the
terminal stays a summary surface.

## State model

- `NOT_APPLICABLE`: a check gated itself out of scope (informational).
- `UNVERIFIED`: skipped/pending/errored — genuinely unknown.
- Zero executed checks → `BLOCKED` with an explicit reason.
- Finding `severity` is what the check found; membership in `blockers` is
  the policy decision. Policy-escalated warnings carry `escalated_by_policy`.
- Every persisted session gets an inspection token (`VRF-XXXXXX`): short,
  copyable, resolving to exactly one session, visible in `status` and
  `history`, accepted by `inspect` and `handoff`.

## Secret-detection contract

Flagged (high-precision prefixes): private keys, `AKIA…`/`ASIA…` (AWS),
`ghp_/gho_/ghu_/ghs_/ghr_…` (GitHub), `xox…` (Slack), `sk-ant-…` (Anthropic),
`sk-proj-…`/`sk-…` (OpenAI, excluding `sk-live-`/`sk-test-`), `AIza…`
(Google), `hf_…` (Hugging Face), `r8_…` (Replicate), `xai-…` (xAI), `gsk_…`
(Groq), `pplx-…` (Perplexity), `sk-live-…` (Stripe live). The evidence
redactor masks the same provider-token shapes wherever they appear, including
terminal output, handoff, history, and the inspection UI.
Deliberately NOT flagged: generic `API_KEY=<value>` assignments and
`sk-test-…` keys (indistinguishable from placeholders without a live oracle).

## Platform support

- Supported and tested: Windows 10/11 x86-64 (AMD and Intel — the framework
  treats architecture as x86-64, never by CPU vendor).
- NOT VALIDATED: Windows 11 ARM64 (expected to work via upstream dependency
  wheels, but no ARM hardware was available for release validation) and
  Windows 10 ARM64.
- Dependencies are pure Python plus `cryptography` (ships Windows wheels for
  x86-64 and ARM64; used at runtime for TLS certificate parsing). If a
  native wheel is ever missing, installation fails with the pip
  compatibility message rather than a mysterious crash.
