{"_id":"@autodevops/verifier-portal-client","name":"@autodevops/verifier-portal-client","dist-tags":{"latest":"0.1.0"},"versions":{"0.1.0":{"name":"@autodevops/verifier-portal-client","version":"0.1.0","description":"Shared AutoDevOps portal event schema and signed ingest client","type":"commonjs","main":"dist/index.js","types":"dist/index.d.ts","bin":{"autodevops-agent-activity-conformance":"dist/conformance-cli.js","autodevops-agent-run-audit-snapshot":"dist/agent-run-audit-snapshot-cli.js","autodevops-agent-trust-signoff-receipt":"dist/agent-trust-signoff-receipt-cli.js","autodevops-agent-trust-signoff-verify":"dist/agent-trust-signoff-cli.js","autodevops-byoc-deployment-readiness":"dist/byoc-deployment-readiness-cli.js","autodevops-connector-compatibility":"dist/connector-compatibility-cli.js","autodevops-connector-proof-bundle":"dist/connector-proof-bundle-cli.js","autodevops-connector-proof-bundle-create":"dist/connector-proof-bundle-create-cli.js","autodevops-connector-proof-portal-readback":"dist/connector-proof-portal-readback-cli.js","autodevops-connector-proof-receipt":"dist/connector-proof-receipt-cli.js","autodevops-connector-proof-walkthrough-plan":"dist/connector-proof-walkthrough-plan-cli.js","autodevops-connector-proof-walkthrough-run":"dist/connector-proof-walkthrough-run-cli.js","autodevops-connector-proof-verify":"dist/connector-proof-cli.js","autodevops-connector-upstream-snapshot":"dist/connector-upstream-snapshot-cli.js","autodevops-connector-upstream-verify":"dist/connector-upstream-verify-cli.js","autodevops-control-evidence-bundle":"dist/control-evidence-bundle-cli.js","autodevops-control-evidence-receipt":"dist/control-evidence-receipt-cli.js","autodevops-control-evidence-verify":"dist/control-evidence-cli.js","autodevops-control-ownership-matrix-verify":"dist/control-ownership-matrix-cli.js","autodevops-customer-cloud-smoke-plan":"dist/customer-cloud-smoke-plan-cli.js","autodevops-customer-cloud-smoke-run":"dist/customer-cloud-smoke-run-cli.js","autodevops-customer-cloud-validation-receipt":"dist/customer-cloud-validation-receipt-cli.js","autodevops-customer-cloud-validation-verify":"dist/customer-cloud-validation-cli.js","autodevops-evidence-anchor":"dist/evidence-anchor-cli.js","autodevops-evidence-object-anchor-receipt":"dist/evidence-object-anchor-receipt-cli.js","autodevops-evidence-object-anchor-verify":"dist/evidence-object-anchor-validation-cli.js","autodevops-evidence-package-verify":"dist/evidence-package-verify-cli.js","autodevops-external-review-handoff-package":"dist/external-review-handoff-package-cli.js","autodevops-external-review-handoff-verify":"dist/external-review-handoff-cli.js","autodevops-external-review-signoff-receipt":"dist/external-review-signoff-receipt-cli.js","autodevops-external-review-signoff-verify":"dist/external-review-signoff-cli.js","autodevops-ip-disclosure-packet":"dist/ip-disclosure-packet-cli.js","autodevops-model-risk-signoff-receipt":"dist/model-risk-signoff-receipt-cli.js","autodevops-model-risk-signoff-verify":"dist/model-risk-signoff-cli.js","autodevops-portal-client-publication-check":"dist/publication-readiness-cli.js","autodevops-portal-client-publication-receipt":"dist/publication-receipt-cli.js","autodevops-pr-branch-protection":"dist/pr-branch-protection.js","autodevops-pr-github-check":"dist/pr-github-check.js","autodevops-pr-github-comment":"dist/pr-github-comment.js","autodevops-pr-merge-evidence":"dist/pr-evidence-cli.js","autodevops-pr-merge-gate":"dist/pr-merge-gate-cli.js","autodevops-pr-rollout-bundle":"dist/pr-rollout-bundle-cli.js","autodevops-pr-rollout-receipt":"dist/pr-rollout-receipt-cli.js","autodevops-pr-rollout-verify":"dist/pr-rollout-proof-cli.js"},"scripts":{"build":"tsc -p tsconfig.json","clean":"rm -rf dist","dev":"tsc -w","example:golden-path":"node examples/golden-path-governed-capability.js","publication:check":"npm run build && node dist/publication-readiness-cli.js .","prepublishOnly":"npm run clean && npm run build"},"keywords":["autodevops","portal","agent-activity","hmac"],"license":"MIT","repository":{"type":"git","url":"git+https://github.com/autodevopsai/autodevops.git","directory":"packages/verifier-portal-client"},"dependencies":{"zod":"^3.23.8"},"devDependencies":{"@types/node":"^20.14.2","typescript":"^5.4.5"},"engines":{"node":">=18"},"publishConfig":{"access":"public"},"_id":"@autodevops/verifier-portal-client@0.1.0","gitHead":"c606f3266c1d0de9daa4c031eb27a393dd2e2bd5","bugs":{"url":"https://github.com/autodevopsai/autodevops/issues"},"homepage":"https://github.com/autodevopsai/autodevops#readme","_nodeVersion":"23.11.0","_npmVersion":"10.9.2","dist":{"integrity":"sha512-3dBzmqmXzEdXkvezX8SiIPwIZng5DkP5BU+wBuI+ye/9vwsy6jbBWOGPlRnt0fhZsY7R+Gl+vND8TeKGgUx0kw==","shasum":"883232545d650c9799cd1558a1d2ba972a4963a3","tarball":"https://registry.npmjs.org/@autodevops/verifier-portal-client/-/verifier-portal-client-0.1.0.tgz","fileCount":281,"unpackedSize":3688467,"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEYCIQDy/cpCpKsDIbWSUB8RSRAPM/yIxqvisVidRR9awq+eCgIhAMKT8JsJNTOaU8xwAY4WjKUd8LfB0BFA3wp7EsfycK9q"}]},"_npmUser":{"name":"brij-singh","email":"opensource@sociallabs.com"},"directories":{},"maintainers":[{"name":"bsociallabs","email":"brij@sociallabs.com"},{"name":"brij-singh","email":"opensource@sociallabs.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/verifier-portal-client_0.1.0_1784959153415_0.7451213596597259"},"_hasShrinkwrap":false}},"time":{"created":"2026-07-25T05:59:13.289Z","0.1.0":"2026-07-25T05:59:13.593Z","modified":"2026-07-25T05:59:13.819Z"},"maintainers":[{"name":"bsociallabs","email":"brij@sociallabs.com"},{"name":"brij-singh","email":"opensource@sociallabs.com"}],"description":"Shared AutoDevOps portal event schema and signed ingest client","homepage":"https://github.com/autodevopsai/autodevops#readme","keywords":["autodevops","portal","agent-activity","hmac"],"repository":{"type":"git","url":"git+https://github.com/autodevopsai/autodevops.git","directory":"packages/verifier-portal-client"},"bugs":{"url":"https://github.com/autodevopsai/autodevops/issues"},"license":"MIT","readme":"# AutoDevOps Portal Client\n\nShared TypeScript client for building `agent_activity.v1` events and posting signed JSON to the AutoDevOps verification portal.\n\nThis package is intentionally small and runtime-neutral so the verifier CLI, MCP server, and future agent session connectors use the same schema, redaction, signature, and idempotency behavior.\n\n## Connector helper\n\nUse `createAgentActivityConnector` when building an internal agent connector or governed capability in JS/TS. It wraps the low-level payload builders with session state, dry-run validation, signed posting, idempotency, and provenance attributes.\n\n```js\nconst { createAgentActivityConnector } = require('@autodevops/verifier-portal-client');\n\nconst connector = createAgentActivityConnector({\n  dryRun: true,\n  source: {\n    kind: 'custom_connector',\n    name: 'internal-agent-connector',\n    version: '0.1.0',\n  },\n  provenance: {\n    source_classification: 'customer_internal',\n    connector_id: 'internal-agent-connector',\n    connector_version: '0.1.0',\n    capability_id: 'shell-command-preview',\n    capability_version: '1.0.0',\n    policy_pack_id: 'regulated-baseline',\n    policy_pack_version: '2026-05-16',\n  },\n});\n\nawait connector.startSession({ session_id: 'custom-session-1' });\nawait connector.emitToolFinished({\n  tool: {\n    name: 'shell',\n    action: 'exec',\n    command_preview: 'npm test',\n  },\n  outcome: {\n    status: 'succeeded',\n    summary: 'Tests passed.',\n  },\n});\nawait connector.finishSession({ status: 'succeeded' });\n```\n\nSet `dryRun: false` after configuring portal credentials to post signed events to the ingest endpoint. If the connector must never block the agent on ingest failure, set `failOpen: true`; sensitive execution and approval flows should still fail closed in the governed runtime.\n\nAn executable example lives at `packages/verifier-portal-client/examples/custom-connector.js`.\n\nThe governed capability golden path lives at `packages/verifier-portal-client/examples/golden-path-governed-capability.js`.\nFrom the repository root, run:\n\n```bash\nnpm run platform:golden-path\n```\n\nBy default it runs in dry-run mode and prints the signed-event transcript that would feed sessions, approvals, audit, and Agent Run Audit. Set `AUTODEVOPS_DRY_RUN=0` plus the portal ingest environment below to post to a configured customer-owned portal.\n\n## Conformance helper\n\nUse `validateAgentActivityConformance` before posting a custom connector payload. It validates the emitted `agent_activity.v1` envelope and the minimum event-specific fields for sessions, tools, approvals, hook decisions, Intent Fidelity, and Agent Run Audit source snapshots.\n\n```js\nconst {\n  validateAgentActivityConformance,\n} = require('@autodevops/verifier-portal-client');\n\nconst result = validateAgentActivityConformance(payload);\n\nif (!result.ok) {\n  throw new Error(\n    result.issues\n      .map((issue) => `${issue.path}: ${issue.message}`)\n      .join('; ')\n  );\n}\n```\n\nUse `validateAgentActivityJsonl` and `formatAgentActivityConformanceReport` when validating newline-delimited event files in tests or connector compatibility checks. The default `record` profile validates each event independently. The explicit `core` profile also requires the public core event suite so release and adopter evidence can prove coverage, not just per-record shape.\n\n```js\nconst {\n  AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA,\n  AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA_ID,\n  AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA_SHA256,\n  formatAgentActivityConformanceReport,\n  validateAgentActivityJsonl,\n} = require('@autodevops/verifier-portal-client');\n\nconst report = validateAgentActivityJsonl(jsonl, { profile: 'core' });\nconsole.log(formatAgentActivityConformanceReport(report));\nconsole.log(report.schemaId === AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA_ID);\nconsole.log(report.schemaSha256 === AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA_SHA256);\n```\n\nAfter building or installing the package, the same JSONL check is available as a CLI:\n\n```bash\nautodevops-agent-activity-conformance ./events.jsonl\nautodevops-agent-activity-conformance ./events.jsonl --profile core --format json\nautodevops-agent-activity-conformance --print-schema > agent_activity.v1.schema.json\n```\n\nThe conformance helper, JSONL runner, and printed JSON Schema are public compatibility layers. They do not expose proprietary sensitivity weights, runtime closed-loop score fields such as `drift_score` or `cognitive_debt_score`, cognitive-debt coefficients, anomaly fingerprints, or customer-specific policy logic. The JSONL runner rejects proprietary closed-loop, policy-hash, and runtime score fields from public conformance records, including camel/snake/kebab and punctuation-separated field aliases.\n\nConformance reports include `schemaVersion`, `schemaId`, `schemaSha256`, and `completeCoreSessionIds` for the exported public JSON Schema. When the CLI writes connector-proof output assertions, it records the conformance profile, schema id, and schema SHA-256 so live walkthrough receipts can reject stale or ambiguous schema evidence. For `--profile core`, the assertion also records the session ids that contain every required core event type; live walkthrough run-report validation rejects core-profile assertions that do not include the captured session id.\n\nA core event fixture suite lives at `packages/verifier/test/fixtures/agent-activity/core-events.v1.jsonl` and covers session, prompt, model, tool, hook, approval, Intent Fidelity, Agent Run Audit, and session-finished events for one session lifecycle. Validate it with `--profile core` when producing public release, registry, adoption, or control-evidence artifacts; connectors that cannot observe every family in one session should use the default `record` profile plus connector-specific compatibility manifests instead of overstating coverage.\n\n## Publication readiness check\n\nUse `validatePortalClientPublicationReadiness` before publishing the portal client or claiming the package is ready for public distribution. It checks package metadata, the MIT license file, required publish files, public CLI bins, README coverage for `agent_activity.v1`, the exported public schema, the publishable README/example surface, the repo-local disclosure files under `docs/ip/`, and the absence of known proprietary terms from both `AGENT_ACTIVITY_V1_PUBLIC_JSON_SCHEMA` and the public package surface. The schema check also blocks closed-loop governance, runtime score fields, approval-history, agent-trust/model-risk, policy-hash, and sample-threshold internals from the exported public compatibility schema.\n\n```js\nconst {\n  validatePortalClientPublicationReadiness,\n} = require('@autodevops/verifier-portal-client');\n\nconst report = validatePortalClientPublicationReadiness({\n  packageRoot: process.cwd(),\n});\n\nif (!report.ok) {\n  throw new Error(report.issues.map((issue) => `${issue.path}: ${issue.message}`).join('; '));\n}\n```\n\nAfter building the package, run the same check from the CLI:\n\n```bash\nnpm --workspace @autodevops/verifier-portal-client run publication:check\nautodevops-portal-client-publication-check ./packages/verifier-portal-client --format json\n```\n\nBefore using this check to support public release, review `docs/ip/schema-publication-strategy.md` and complete `docs/ip/public-disclosure-checklist.md` for the target material. The current strategy is package-first release followed by counsel-approved defensive publication; it does not authorize claims that `agent_activity.v1` is an industry standard.\n\nTo hand auditors or release reviewers a tamper-evident local release artifact, create a publication receipt after the package has been built:\n\n```bash\nautodevops-portal-client-publication-receipt ./packages/verifier-portal-client \\\n  --operator release-owner \\\n  --core-fixture ./packages/verifier/test/fixtures/agent-activity/core-events.v1.jsonl \\\n  --public-disclosure-review ./public-disclosure-review.json \\\n  --ip-disclosure-packet ./ip-disclosure-receipt.json \\\n  --require-public-disclosure-review \\\n  --require-ip-disclosure-packet \\\n  --output portal-client-publication-receipt.json\n```\n\nThe receipt records the package name/version, checked CLI bins, README/license/package metadata, public schema hash, optional core fixture hash, optional public-disclosure review evidence, optional IP disclosure packet evidence, safety checks including public schema and public package surface term scans, result checks, proof level, and receipt hash. `local_package` receipts prove the built package surface passed local release gates, including the public schema disclosure-boundary check. They do not prove the package has been published to npm, adopted by customers, accepted as a standard, or approved by counsel unless reviewed public-disclosure and IP disclosure packets explicitly say so. Use `--proof-level published_registry` only when registry URL, publication timestamp, and tarball integrity evidence are available.\n\n`--public-disclosure-review` reads a reviewed JSON packet with `schemaVersion: \"autodevops.public_disclosure_review_receipt.v1\"`, the material destination and audience, reviewed material hashes, candidate mechanics, implementation and verification evidence, explicit trade-secret holdbacks, product review, counsel review status when required, approved wording, and safety checks against patent-status, standards, compliance-certification, proprietary-scoring, and customer-data claims. `--require-public-disclosure-review` makes that packet mandatory and hash-bound in the publication receipt.\n\n`--ip-disclosure-packet` reads an `autodevops.ip_disclosure_packet_receipt.v1` packet and embeds it into the publication receipt. The packet `scope.packageName` must match the publication package name. When a public-disclosure review is also attached, its `reviewedMaterials` must include the embedded packet's `receiptSha256`; otherwise the publication receipt fails validation because the review did not cover the exact packet. `--require-ip-disclosure-packet` makes that packet mandatory and validates core candidate coverage, packet hash, implementation-reference hashes, verification output hashes, non-empty known core-candidate holdbacks, and safe public summaries. `--require-counsel-reviewed-ip-disclosure` additionally requires the nested packet to be `counsel_reviewed` with candidate-level approval coverage and packet-after-review chronology.\n\nAfter real publication, bind reviewed registry metadata and downstream adopter conformance evidence into the receipt:\n\n```bash\nautodevops-portal-client-publication-receipt ./packages/verifier-portal-client \\\n  --operator release-owner \\\n  --proof-level published_registry \\\n  --registry-url https://registry.npmjs.org/@autodevops%2fverifier-portal-client \\\n  --registry-metadata ./registry-metadata.json \\\n  --adoption-evidence ./adoption-evidence.json \\\n  --public-disclosure-review ./public-disclosure-review.json \\\n  --ip-disclosure-packet ./ip-disclosure-receipt.json \\\n  --require-published-registry \\\n  --require-adoption-evidence \\\n  --require-public-disclosure-review \\\n  --require-ip-disclosure-packet \\\n  --output portal-client-publication-receipt.json\n```\n\nRegistry metadata should capture the published package name/version, public-access marker, registry URL, publication timestamp, dist-tags, and tarball integrity or SHA-256. Adoption evidence is a reviewed JSON array of downstream users that records package version range, `agent_activity.v1` schema version, evidence reference, evidence capture timestamp, conformance command, zero exit code, SHA-256 command-output hash, non-zero command-output byte count, passing conformance report status, checked record count, conformance profile, complete core session ids when the profile is `core`, public schema id, public schema SHA-256, and passing conformance result. When `conformanceOutputPath` points to JSON output from `autodevops-agent-activity-conformance --format json`, the receipt builder derives those report/profile/core-session/schema fields and rejects supplied values that contradict the file. Core-profile adoption evidence must also record a conformance command that ran `--profile core`. Adoption evidence is hash-only; the receipt verifier rejects normalized raw stdout/stderr/output, conformance-output, prompt/source/source-code/file-content, object-body, tool-output, and secret/key/credential aliases at any depth even when the adoption entry and receipt hashes have been recomputed. These fields make publication and adoption proof reviewable, but only after real registry and adopter evidence exists.\n\nThe receipt validator recomputes publication result checks from the embedded readiness metadata, public schema hash, checked bins, hash-bound artifacts, and release-surface package metadata, so a rehashed receipt cannot retain positive public-release flags after checked bins/artifacts are stripped or package metadata is flipped. It also treats registry, adoption, public-disclosure, and IP-disclosure result checks as derived evidence claims. Positive registry flags fail unless the receipt is `published_registry` and the attached registry metadata supports package/version visibility, public access, publication timestamp, and tarball integrity; positive downstream adoption flags fail unless attached adoption evidence includes timestamped passing `agent_activity.v1` conformance evidence with `conformanceExitCode: 0`, a non-empty SHA-256 `conformanceOutputSha256`, a positive `conformanceOutputBytes` count, `conformanceReportOk: true`, positive `conformanceCheckedRecordCount`, a valid `record` or `core` conformance profile, `--profile core` command evidence plus complete core session ids for `core`, current public schema id/SHA-256 values, and no embedded normalized raw stdout/stderr/output, conformance-output, prompt/source/source-code/file-content, object-body, tool-output, and secret/key/credential aliases at any depth; positive IP-disclosure flags fail unless the nested IP packet verifies and is scoped to the publication package; and paired public-disclosure/IP-disclosure evidence fails unless the review cites the embedded packet hash. Published-registry receipts also reject registry publication, downstream adoption capture, public-disclosure review, or IP disclosure packet timestamps that occur after the receipt `generatedAt`.\n\n## IP disclosure packet\n\nUse `buildIpDisclosurePacketReceipt` or `autodevops-ip-disclosure-packet` when preparing a counsel-facing `autodevops.ip_disclosure_packet_receipt.v1` packet for patent-candidate or public-disclosure review. The packet hash-binds the core IP audit, goal PRD, disclosure checklist, implementation refs with SHA-256 evidence, zero-exit verification output hashes, trade-secret holdbacks, and safe public summaries for the core IP candidates. Verification recomputes packet result checks from the embedded materials, candidates, safety checks, and counsel-review details, and rejects duplicate candidate ids, so rehashed positive result flags cannot hide removed candidates, duplicated candidate coverage, weakened verification evidence, or missing disclosure controls. With `--require-core-candidates`, verification also requires `sourceAudit.path` to cite `docs/core-ip-strengthening-audit.md`, `goalPrd.path` to cite `docs/core-ip-strengthening-goal-prd.md`, `reviewedMaterials` to include hash-bound invention-disclosure notes, public-disclosure checklist, and schema-publication strategy files, and every core candidate to record a non-empty known proprietary holdback category.\n\n```bash\nautodevops-ip-disclosure-packet \\\n  --input ./ip-disclosure-draft.json \\\n  --output ./ip-disclosure-receipt.json \\\n  --require-core-candidates\n\nautodevops-ip-disclosure-packet \\\n  --verify ./ip-disclosure-receipt.json \\\n  --require-core-candidates \\\n  --format json\n```\n\n`counsel_prep` packets are review evidence only. Add `--require-counsel-review` only when the receipt includes accepted counsel review details, reviewer identity, review reference, `proofLevel: \"counsel_reviewed\"`, candidate-level approval coverage for every claimed candidate id, and a packet timestamp after the cited review. The verifier rejects non-planned candidates whose implementation refs are only path strings, rejects result checks that contradict packet content, rejects malformed or custom-only core-candidate holdbacks, rejects unsafe public wording such as patent-status, standards, compliance-certification, and proprietary scoring claims, but it is not legal advice and does not create patent, compliance, or publication approval.\n\n## Connector compatibility manifests\n\nUse `validateConnectorCompatibilityManifest` when CI needs to verify that current third-party connector samples still project into the expected `agent_activity.v1` transcript. This is separate from live proof receipts: compatibility manifests catch schema and projection drift; live receipts prove an actual walkthrough reached the customer-owned portal.\n\n```js\nconst {\n  buildConnectorCompatibilitySnapshot,\n  formatConnectorCompatibilityReport,\n  validateConnectorCompatibilitySnapshot,\n  validateConnectorCompatibilityManifest,\n} = require('@autodevops/verifier-portal-client');\n\nconst report = validateConnectorCompatibilityManifest(manifest, (fixture) =>\n  fixture.events_jsonl_path ? readFile(fixture.events_jsonl_path) : undefined\n);\n\nif (!report.ok) {\n  throw new Error(formatConnectorCompatibilityReport(report));\n}\n```\n\nAfter building or installing the package, run the same check as a CLI:\n\n```bash\nautodevops-connector-compatibility ./connector-compatibility-manifest.json\nautodevops-connector-compatibility ./connector-compatibility-manifest.json --format json\nautodevops-connector-compatibility ./connector-compatibility-manifest.json \\\n  --format json \\\n  --snapshot-output connector-compatibility-snapshot.json\n```\n\nThe manifest schema is `connector_compatibility_manifest.v1`. Supported fixture entries point to normalized `agent_activity.v1` JSONL transcripts and declare expected event sequences, source identity, connector ids, required fields, and forbidden raw-content substrings. The optional snapshot schema is `connector_compatibility_snapshot.v1`; it hash-binds the manifest text, runner command and output, normalized transcript hashes, upstream sample refs, derived fixture counts, and unsupported no-claim fixtures so CI can hand reviewers a stable upstream-compatibility artifact. The snapshot verifier rejects missing runner command evidence and count summaries that do not match the embedded fixture list. The regulated control evidence bundle requires that snapshot as reviewed connector-compatibility evidence. Passing compatibility or a passing snapshot is still not a live receipt; it only proves fixture projection remains compatible. The repository fixture suite includes static Claude Code lite hook, Cursor Agent CLI, MCP event-emission, and Copilot normalized transcripts. Unsupported live-connector entries, such as live Copilot until a real connector source exists, must include an explicit `unsupported_reason` and no live transcript.\n\nUse `buildConnectorUpstreamCompatibilitySnapshot`, `validateConnectorUpstreamCompatibilitySnapshot`, and `formatConnectorUpstreamCompatibilitySnapshotValidationReport` when a reviewer needs the compatibility snapshot bound to live upstream command evidence. The upstream snapshot schema is `connector_upstream_compatibility_snapshot.v1`. It embeds the compatibility snapshot, records reviewed source entries, requires live connector sources to include successful version plus help or stream-json-help command evidence, stores only command output hashes instead of raw stdout or stderr, and keeps unsupported sources as explicit no-live-claim entries. Validation also rejects normalized raw stdout/stderr/output, prompt/source/source-code/file-content, object-body, tool-output, and secret/key/credential aliases at any depth in command evidence, reports exact raw-evidence paths, then recomputes `resultChecks.rawOutputRedacted` from that field set. A source cannot be upgraded to `live_connector` by attaching command hashes when the compatibility snapshot marks that source unsupported or no-live-claim; validation requires a supported compatibility fixture for the source first. When CI or a reviewer supplies `maxEvidenceAgeDays` (or the CLI flag `--max-evidence-age-days`), validation also rejects stale upstream snapshot timestamps, stale live command captures, missing command `captured_at` timestamps, and future-dated evidence relative to the supplied `asOf` timestamp. This narrows the gap between fixture compatibility and a live walkthrough receipt without claiming the full portal walkthrough is complete.\n\n```bash\nautodevops-connector-upstream-snapshot \\\n  --compatibility-snapshot ./connector-compatibility-snapshot.json \\\n  --sources ./connector-upstream-sources.json \\\n  --output ./connector-upstream-snapshot.json \\\n  --proof-level live_upstream_surface \\\n  --operator field-engineer \\\n  --preproduction-scope-only \\\n  --raw-command-output-excluded \\\n  --no-secrets-included \\\n  --unsupported-sources-not-claimed-live \\\n  --require-live-upstream \\\n  --max-evidence-age-days 7 \\\n  --as-of \"$REVIEWED_AT\"\n\nautodevops-connector-upstream-verify ./connector-upstream-snapshot.json \\\n  --require-live-upstream \\\n  --max-evidence-age-days 7 \\\n  --as-of \"$REVIEWED_AT\"\n```\n\n## Connector proof receipt verifier\n\nUse `collectConnectorProofEventEvidence`, `buildConnectorProofReceiptFromAgentActivityJsonl`, and `validateConnectorProofReceipt` when turning a live `agent_activity.v1` transcript into a third-party connector walkthrough receipt before claiming Claude Code, Cursor, hook-pack, MCP, or custom connector proof. The builder derives event ids, event types, session id, inferred agent source, repository name, conformance output, and a canonical `receipt_hash` from the transcript and draft evidence; the verifier still checks metadata, receipt-hash integrity, transcript lifecycle coverage, portal session/event evidence, PR evidence, evidence-package verification, walkthrough environment, approval behavior, redaction notes, safety assertions, and unsupported connector claims.\n\n```js\nconst {\n  buildConnectorProofWalkthroughPlan,\n  buildConnectorProofReceiptFromAgentActivityJsonl,\n  buildConnectorProofReadinessReport,\n  runConnectorProofWalkthroughPlan,\n  validateConnectorProofWalkthroughPlan,\n  validateConnectorProofWalkthroughRunReport,\n  validateConnectorProofReceipt,\n} = require('@autodevops/verifier-portal-client');\n\nconst walkthroughPlan = buildConnectorProofWalkthroughPlan({\n  operator: 'platform-security-reviewer',\n  portal: {\n    environment: 'customer_cloud',\n    team_id: 'team-payments-risk',\n    base_url: 'https://portal.customer.example',\n  },\n  agentSources: ['claude_code', 'cursor_agent_cli'],\n});\nconst planReport = validateConnectorProofWalkthroughPlan(walkthroughPlan, {\n  requireCustomerCloud: true,\n  requiredAgentSources: ['claude_code', 'cursor_agent_cli'],\n});\n\nconst { receipt } = buildConnectorProofReceiptFromAgentActivityJsonl(receiptDraft, eventsJsonl);\nconst readiness = buildConnectorProofReadinessReport(receipt, {\n  requireCustomerCloud: true,\n});\nconst report = validateConnectorProofReceipt(receipt, {\n  requireCustomerCloud: true,\n});\n\nif (!planReport.ok || !readiness.ready || !report.ok) {\n  throw new Error(report.issues.map((issue) => issue.message).join('; '));\n}\n```\n\nBefore the live walkthrough, create a customer-cloud command plan for the connector sources that must be proven. The plan is not live proof; it rejects dry-run or fixture-replay commands under `--require-customer-cloud` and requires every planned command to collect a zero exit code plus SHA-256 output hash before the receipt and bundle are created. MCP plans are source-specific: setup and live capture must call `verifier-mcp-walkthrough`, and the plan verifier rejects generic commands, handwritten transcripts, or hook-pack commands for `agent_source: \"mcp\"`. After the customer runs the plan inside their cloud boundary, use the walkthrough run report to capture command ids, exit codes, timestamps, and output hashes without storing raw stdout or stderr in the handoff. The standalone verifier also rejects embedded normalized raw stdout/stderr/output, prompt/source/source-code/file-content, object-body, email-body, tool-input/tool-output, and secret/key/credential aliases at any depth inside command evidence, even when `raw_output_stored` is false. For customer-cloud proof, enrich that report with `output_assertions` or pass `--output-assertions` to the CLI so the verifier can check parsed live facts for connector setup, captured session/events, conformance result/count, portal read-back route/events, evidence-package hash/verification, connector proof receipt id/hash, and walkthrough bundle id/hash. The standalone run-report verifier now also compares the captured session/event assertions to portal read-back assertions for the same connector source, requires conformance record counts to cover the captured event ids, and rejects core-profile conformance assertions whose complete core session ids do not include the captured session id. The generated conformance, portal read-back, evidence-package verification, receipt, and bundle commands pass the assertion file and agent source to their CLIs; `autodevops-connector-proof-portal-readback` fetches or validates structured customer portal output before appending the `portal_readback` assertion. Live receipt verification also recomputes result checks from portal read-back command/hash evidence, transcript lifecycle/activity coverage, conformance output, session route, audit route, PR evidence reference, evidence-package verifier command, package hash, safety flags, and redaction notes, so edited receipts cannot keep positive live-proof flags after removing the backing evidence.\n\n```bash\nautodevops-connector-proof-walkthrough-plan \\\n  --operator platform-security-reviewer \\\n  --portal-environment customer_cloud \\\n  --portal-base-url https://portal.customer.example \\\n  --portal-team-id team-payments-risk \\\n  --agent-source claude_code \\\n  --agent-source cursor_agent_cli \\\n  --require-source claude_code \\\n  --require-source cursor_agent_cli \\\n  --require-customer-cloud \\\n  --output ./connector-proof-walkthrough-plan.json\n\nautodevops-connector-proof-walkthrough-plan \\\n  --verify ./connector-proof-walkthrough-plan.json \\\n  --require-customer-cloud \\\n  --require-source claude_code \\\n  --require-source cursor_agent_cli\n\nautodevops-connector-proof-walkthrough-run \\\n  --plan ./connector-proof-walkthrough-plan.json \\\n  --output ./connector-proof-walkthrough-run.json \\\n  --runner-id customer-platform-runner \\\n  --runner-role platform-security-reviewer \\\n  --allow-execute \\\n  --output-assertions ./connector-proof-walkthrough-assertions.json \\\n  --require-customer-cloud\n\nautodevops-connector-proof-walkthrough-run \\\n  --verify ./connector-proof-walkthrough-run.json \\\n  --output-assertions ./connector-proof-walkthrough-assertions.json \\\n  --require-customer-cloud\n```\n\nAfter building or installing the package, validate a JSON receipt locally:\n\n```bash\nautodevops-connector-proof-receipt from-events ./events.jsonl ./receipt-draft.json --preflight --require-customer-cloud --format json\nautodevops-connector-proof-receipt from-events ./events.jsonl ./receipt-draft.json --output ./connector-proof-receipt.json --output-assertions ./connector-proof-walkthrough-assertions.json --assertion-agent-source claude_code --fail-on-invalid\nautodevops-connector-proof-verify ./connector-proof-receipt.json\nautodevops-connector-proof-verify ./connector-proof-receipt.json --require-customer-cloud\n```\n\nThe receipt generator does not auto-approve safety or result assertions; missing checks remain false and fail verification. Use `buildConnectorProofReadinessReport` or `autodevops-connector-proof-receipt --preflight` before writing a receipt or bundle to see missing conformance/evidence-package verifier commands, receipt-hash integrity, transcript lifecycle/activity coverage, portal read-back command and output hash, approval ids, walkthrough metadata, safety checks, and result checks. Receipts default to `proof_level: \"live_portal\"`, which requires a matching tamper-evident `receipt_hash`, portal evidence, transcript event types proving `session.started`, `session.finished`, and at least one prompt/model/tool/hook/approval activity event, PR evidence, evidence-package verification, walkthrough command-log/environment/approval/redaction fields, safety checks, and live result checks. Live receipts also require `portal_evidence.portal_readback` with the portal read-back command, `exit_code: 0`, output SHA-256, evidence reference, and capture timestamp; JSON read-back output must expose the receipt session id and portal session route through structured session fields, and event ids/types through structured event fields such as `event_ids` / `event_types` or nested event objects, not only through notes text. A true `evidence_package_verification_passed` result now requires an evidence-package verifier command with `exit_code: 0`, not just a verifier command reference. If approval behavior is `approved`, `denied`, `blocked`, or `mixed`, the receipt must include portal approval ids. Fixture receipts use `proof_level: \"fixture_replay\"` and require conformance plus connector compatibility checks instead; they pass only as replayable compatibility evidence and still warn that they are not customer-cloud validation. The verifier accepts Copilot only for fixture-replay receipts today and rejects incomplete live Copilot claims until a supported live connector walkthrough exists, along with missing or mismatched live receipt hashes, broken session route references, missing transcript lifecycle coverage, missing conformance output, missing portal read-back evidence, missing passing evidence-package verification, and safety checks that are not explicitly true. Fixture examples live under `packages/verifier/test/fixtures/connector-proof/`.\n\nFor the common live walkthrough handoff, the receipt CLI can build the receipt, write the transcript conformance output artifact, assemble the walkthrough bundle, and validate the bundle before writing it. Bundle validation rejects bundles generated before the connector proof receipt or live walkthrough run report they wrap.\n\n```bash\nautodevops-connector-proof-receipt from-events ./walkthrough/events.jsonl ./walkthrough/receipt-draft.json \\\n  --base-dir ./walkthrough \\\n  --output connector-proof-receipt.json \\\n  --bundle-output walkthrough-bundle.json \\\n  --output-assertions ./walkthrough/walkthrough-output-assertions.json \\\n  --assertion-agent-source claude_code \\\n  --write-conformance-output conformance-output.txt \\\n  --artifact agent_activity_jsonl=events.jsonl \\\n  --artifact conformance_output=conformance-output.txt \\\n  --artifact connector_proof_walkthrough_run_report=connector-proof-walkthrough-run.json \\\n  --artifact compatibility_output=compatibility-output.txt \\\n  --artifact walkthrough_notes=walkthrough-notes.md \\\n  --artifact pr_evidence_summary=pr-evidence.md \\\n  --artifact evidence_package=evidence-package.json \\\n  --artifact evidence_package_verification=evidence-package-verify.txt \\\n  --artifact portal_readback_output=portal-readback.json \\\n  --artifact screenshot_or_recording=session-detail.png \\\n  --command \"events.jsonl=autodevops-agent-activity-conformance ./events.jsonl --output-assertions ./walkthrough-output-assertions.json --assertion-agent-source claude_code\" \\\n  --command \"connector-proof-walkthrough-run.json=autodevops-connector-proof-walkthrough-run --plan ./connector-proof-walkthrough-plan.json --allow-execute --require-customer-cloud\" \\\n  --command \"compatibility-output.txt=autodevops-connector-compatibility ./connector-compatibility-manifest.json\" \\\n  --command \"evidence-package-verify.txt=autodevops-evidence-package-verify ./evidence-package.json --output-assertions ./walkthrough-output-assertions.json --assertion-agent-source claude_code\" \\\n  --command \"portal-readback.json=autodevops-connector-proof-portal-readback --input portal-readback.json --from-events events.jsonl --agent-source claude_code --output-assertions ./walkthrough-output-assertions.json\" \\\n  --require-customer-cloud \\\n  --fail-on-invalid\n```\n\nThis one-pass mode still requires operator-supplied draft assertions and live artifacts. It does not run the connector, PR evidence query, evidence export, compatibility check, or screenshot capture for you; it binds the resulting files into one validated receipt/bundle handoff.\n\nFor live walkthrough evidence, put the receipt and its referenced artifacts in a bundle directory and validate the bundle manifest before using it in customer-facing claims:\n\n```bash\nautodevops-connector-proof-bundle-create \\\n  --base-dir ./walkthrough \\\n  --receipt connector-proof-receipt.json \\\n  --output walkthrough-bundle.json \\\n  --operator platform-security-reviewer \\\n  --output-assertions ./walkthrough/walkthrough-output-assertions.json \\\n  --assertion-agent-source claude_code \\\n  --artifact agent_activity_jsonl=events.jsonl \\\n  --artifact conformance_output=conformance-output.txt \\\n  --artifact connector_proof_walkthrough_run_report=connector-proof-walkthrough-run.json \\\n  --artifact compatibility_output=compatibility-output.txt \\\n  --artifact walkthrough_notes=walkthrough-notes.md \\\n  --artifact pr_evidence_summary=pr-evidence.md \\\n  --artifact evidence_package=evidence-package.json \\\n  --artifact evidence_package_verification=evidence-package-verify.txt \\\n  --artifact portal_readback_output=portal-readback.json \\\n  --artifact screenshot_or_recording=session-detail.png \\\n  --command \"connector-proof-walkthrough-run.json=autodevops-connector-proof-walkthrough-run --plan ./connector-proof-walkthrough-plan.json --allow-execute --require-customer-cloud\" \\\n  --command \"compatibility-output.txt=autodevops-connector-compatibility ./connector-compatibility-manifest.json\" \\\n  --command \"evidence-package-verify.txt=autodevops-evidence-package-verify ./evidence-package.json\" \\\n  --command \"portal-readback.json=autodevops-connector-proof-portal-readback --input portal-readback.json --from-events events.jsonl --agent-source claude_code --output-assertions ./walkthrough-output-assertions.json\" \\\n  --require-customer-cloud\nautodevops-connector-proof-bundle ./walkthrough-bundle.json --require-customer-cloud\n```\n\nThe bundle schema is `connector_proof_walkthrough_bundle.v1`. It requires the live receipt, event transcript, conformance output, assertion-enriched hash-only walkthrough run report, connector compatibility output, walkthrough notes, PR evidence summary, evidence package, evidence-package verification output, portal read-back output, and screenshot or recording artifacts with SHA-256 hashes. The create command computes artifact hashes, links the receipt artifact, defaults screenshot routes from the receipt session route, validates the bundle, and writes the manifest only when verification passes. The verifier also checks that the PR evidence path, evidence package hash, portal session screenshot route, transcript-derived session id, event ids, event types, agent source, repository, conformance output, walkthrough run report source/environment/team, non-empty unique per-command output hashes, command/source/exit/output-hash evidence and structured live assertions, compatibility-output pass evidence, evidence-package verification pass evidence, portal read-back output structured session/event evidence and hash/content, and walkthrough-notes environment/approval/redaction content line up with the receipt, so a rehashed but substituted transcript, tampered run report, failed compatibility output, failed evidence-package verification output, failed portal read-back output, missing assertion evidence, or contradictory notes file fails validation.\n\n## External review signoff helper\n\nUse `buildExternalReviewSignoffReadinessReport` before creating an external-review signoff receipt for a customer handoff. It runs the same validator without writing receipt files and reports missing hash-bound customer-cloud validation receipt and validation-report linkage, reviewed-bundle hash/scope mismatch, accepted customer control-owner coverage, reviewer identity, accepted outcome, documented exceptions, non-opinion acknowledgement, timestamp-order failures, and safety assertions. The signoff verifier recomputes result checks from those embedded facts, so edited receipts cannot retain positive review flags after compliance-pack hashes, validation linkage, reviewer identity, control-owner coverage, or acknowledgement evidence is removed.\n\n```bash\nautodevops-external-review-signoff-receipt \\\n  --preflight \\\n  --bundle-report ./regulated-control-bundle-report.json \\\n  --bundle-sha256 <bundle-sha256> \\\n  --compliance-evidence-pack ./docs/compliance-evidence-pack.md \\\n  --proof-level reviewed_packet \\\n  --environment customer_cloud \\\n  --require-customer-cloud \\\n  --require-signed-review \\\n  --format json\n```\n\nPreflight mode returns non-zero until the signed-review receipt would validate, and it does not write `--output` even when one is supplied. A passing preflight is readiness evidence only; completed external regulatory, legal, audit, or model-risk review still requires the customer/reviewer-executed signoff receipt and any required handoff package.\n\n## PR merge evidence helper\n\nUse `buildPrMergeEvidenceSummary` when a CI job, PR webhook, or internal portal route needs a deterministic Markdown and JSON summary for code review. The helper renders only explicit summary fields, session ids, approvals, reviewer rationale, closed-loop governance signal scores, intent scores, provenance query audit ids, and blast-radius summaries; it does not render raw prompts or source content. `prMergeEvidenceSummaryDigest` computes a canonical SHA-256 over the normalized summary fields, and the Markdown, GitHub PR comment body, and GitHub Check Run output include that digest so reviewers can bind the visible PR artifact back to the exact portal evidence summary.\n\n```js\nconst {\n  buildPrMergeEvidenceSummary,\n  prMergeEvidenceSummaryDigest,\n} = require('@autodevops/verifier-portal-client');\n\nconst summary = buildPrMergeEvidenceSummary({\n  repositoryName: 'payments-risk-service',\n  prNumber: 42,\n  sessions: [{ sessionId: 'verification-session-42', agentName: 'Claude Code' }],\n  approvals: [{\n    approvalId: 'approval-1',\n    status: 'approved',\n    toolName: 'SandboxExec',\n    decisionReason: 'Reviewer confirmed the drift signal is covered by the PR rationale.',\n    closedLoopSignals: [{\n      name: 'cognitiveDebt',\n      score: 82,\n      eventId: 'evt-cognitive-82',\n      evidenceSha256: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa',\n      generatedAt: '2026-06-16T11:30:00.000Z',\n    }],\n  }],\n  intents: [{ eventId: 'intent-score-1', fidelityScore: 91 }],\n  provenanceQueries: [\n    { auditId: 'query-originator-1', endpoint: 'originator', resultCount: 1 },\n    { auditId: 'query-lineage-1', endpoint: 'lineage', resultCount: 8 },\n    { auditId: 'query-blast-radius-1', endpoint: 'blast-radius/snapshot', resultCount: 1 },\n  ],\n  reviewEvidence: { correlationConfidence: 'direct', missingEvidenceReasons: [] },\n});\n\nconsole.log(summary.status);\nconsole.log(prMergeEvidenceSummaryDigest(summary));\nconsole.log(summary.markdown);\n```\n\nUse `buildPrMergeEvidenceSummaryFromPortalRows` when composing the same contract from existing portal rows such as `review_evidence_events`, `agent_activity_events`, `approval_requests`, and `provenance_query_audit`.\n\nWhen an approval carries trusted closed-loop signal scores such as `cognitiveDebt`, `intentFidelity`, or `approvalHistory`, the merge evidence check requires reviewer rationale by default once a signal is at or above threshold `70`. Closed-loop signals are included only when they carry a signal id, event id, or receipt id, a generated-at timestamp that is not later than the PR evidence summary, a valid SHA-256 evidence hash when supplied, and matching action/tool scope when `actionKey` or `toolKey` are present. The portal route accepts `closedLoopRationaleThreshold=<number>` and `requireClosedLoopRationale=false` for CI policy tuning. System-generated `policy_reason` text does not satisfy this requirement; the check expects reviewer decision rationale from the approval record.\n\nDirect and portal-row intent summaries are treated as review-safe only when their source evidence does not carry raw prompt, source-content, raw-output, tool-output, stdout/stderr, or secret fields. If those fields are present, the PR evidence keeps the event id and fidelity score but renders the generic intent-evidence fallback in Markdown and JSON.\n\nAfter building or installing the package, render the same contract from a JSON file in CI:\n\n```bash\nautodevops-pr-merge-evidence ./pr-evidence.json --format markdown\nautodevops-pr-merge-evidence ./pr-evidence.json --format json\n```\n\nThe renderer CLI exits `0` when evidence status is `pass` and `1` when evidence is `incomplete` or `fail`, so it can feed CI.\n\nThe portal also exposes a read-only route that resolves persisted review evidence, activity events, approvals, provenance-query audit rows, and blast-radius summaries into the same contract:\n\n```bash\ncurl \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\"\ncurl \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service&format=markdown\"\n```\n\nUse the merge-gate CLI when CI should fetch current portal evidence directly and fail the job unless the evidence status passes:\n\n```bash\nautodevops-pr-merge-gate \\\n  \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\" \\\n  --token \"$AUTODEVOPS_PORTAL_TOKEN\" \\\n  --format markdown \\\n  --output autodevops-pr-evidence.md\n```\n\nThe gate CLI requests JSON from the portal even when rendering Markdown, adds `Authorization: Bearer <token>` from `--token`, `AUTODEVOPS_PORTAL_TOKEN`, or `VERIFICATION_PORTAL_TOKEN`, and exits non-zero for `incomplete` or `fail` evidence.\n\nUse the GitHub comment CLI when CI should make the same evidence visible in code review:\n\n```bash\nautodevops-pr-github-comment \\\n  \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\" \\\n  --repo acme/payments-risk-service \\\n  --pr 42 \\\n  --github-token \"$GITHUB_TOKEN\" \\\n  --portal-token \"$AUTODEVOPS_PORTAL_TOKEN\"\n```\n\nThe comment CLI fetches the portal JSON evidence, renders the review-safe Markdown with a stable AutoDevOps marker, and creates or updates one GitHub PR comment through the GitHub REST API. Use `--dry-run` to print the comment body without a GitHub token, and `--fail-on-incomplete` when the comment job should also fail on incomplete evidence. The comment path is review visibility only; use the Check Run and branch-protection helpers below when merge policy should enforce the evidence.\n\nUse the GitHub Check CLI when CI should publish a Check Run status from the same portal evidence:\n\n```bash\nautodevops-pr-github-check \\\n  \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\" \\\n  --repo acme/payments-risk-service \\\n  --head-sha \"$GITHUB_SHA\" \\\n  --github-token \"$GITHUB_TOKEN\" \\\n  --portal-token \"$AUTODEVOPS_PORTAL_TOKEN\" \\\n  --fail-on-incomplete\n```\n\nThe check CLI maps `pass` to `success`, `incomplete` to `action_required`, and `fail` to `failure`, then creates or updates an `AutoDevOps PR evidence` Check Run. It requires a token that can write GitHub check runs. For webhook-driven BYOC deployments, use the portal route below.\n\nThe portal also exposes a GitHub pull-request webhook entrypoint for BYOC deployments that want a hosted-app style path:\n\n```text\nPOST /api/verification-portal/pr-evidence/github-webhook\n```\n\nConfigure `AUTODEVOPS_GITHUB_APP_WEBHOOK_SECRET`, `AUTODEVOPS_GITHUB_APP_TEAM_ID`, and either `AUTODEVOPS_GITHUB_APP_CHECK_TOKEN`, `AUTODEVOPS_GITHUB_APP_DRY_RUN=true`, or `AUTODEVOPS_GITHUB_APP_ID` plus `AUTODEVOPS_GITHUB_APP_PRIVATE_KEY` / `AUTODEVOPS_GITHUB_APP_PRIVATE_KEY_BASE64`. The route verifies `x-hub-signature-256`, accepts processable `pull_request` events, resolves PR evidence directly from the customer portal, exchanges GitHub App credentials for an installation token when needed, and creates or updates the `AutoDevOps PR evidence` Check Run. Live organization rollout and applied branch-protection validation remain separate setup steps.\n\nUse the branch-protection helper when operators need GitHub branch protection or rulesets to require the AutoDevOps check before merge:\n\n```bash\nautodevops-pr-branch-protection ruleset-payload --branch main --format json\nautodevops-pr-branch-protection classic-payload --format json\nautodevops-pr-branch-protection verify ./github-branch-protection-or-ruleset.json --format json\nautodevops-pr-branch-protection verify-github --repo acme/payments-risk-service --branch main --github-token \"$GITHUB_TOKEN\" --format json\nautodevops-pr-branch-protection apply-ruleset --repo acme/payments-risk-service --branch main --dry-run --format json\n```\n\nThe branch-protection helper emits copyable GitHub classic branch-protection and ruleset payloads for the `AutoDevOps PR evidence` Check Run, verifies exported GitHub JSON, can verify current repository branch protection/rulesets through the GitHub API, and can create or update the repository ruleset with `--dry-run` support. API commands accept `--github-token`, `GITHUB_TOKEN`, or GitHub App id/private-key/installation-id credentials. It does not install a hosted GitHub App, and live customer or organization rollout validation remains a separate setup proof.\n\nUse the PR rollout receipt creator/verifier when a live GitHub App or branch-protection rollout needs a machine-checkable artifact before customer-facing claims:\n\n```bash\nautodevops-pr-rollout-receipt \\\n  --preflight \\\n  --pr-evidence ./pr-evidence.json \\\n  --check-run-output ./check-run.json \\\n  --branch-protection-output ./branch-protection.txt \\\n  --portal-environment customer_cloud \\\n  --portal-team-id \"$AUTODEVOPS_TEAM_ID\" \\\n  --portal-pr-evidence-url \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\" \\\n  --repo acme/payments-risk-service \\\n  --branch main \\\n  --pr-number 42 \\\n  --head-sha \"$GITHUB_SHA\" \\\n  --proof-level live_deployed \\\n  --require-customer-cloud \\\n  --format json\nautodevops-pr-rollout-receipt \\\n  --pr-evidence ./pr-evidence.json \\\n  --check-run-output ./check-run.json \\\n  --branch-protection-output ./branch-protection.txt \\\n  --operator platform-security-reviewer \\\n  --portal-environment customer_cloud \\\n  --portal-team-id \"$AUTODEVOPS_TEAM_ID\" \\\n  --portal-pr-evidence-url \"https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42&repository=payments-risk-service\" \\\n  --repo acme/payments-risk-service \\\n  --branch main \\\n  --pr-number 42 \\\n  --head-sha \"$GITHUB_SHA\" \\\n  --webhook-delivery-id \"$GITHUB_DELIVERY_ID\" \\\n  --merge-gate-command \"autodevops-pr-merge-gate https://portal.example.com/api/verification-portal/pr-evidence?prNumber=42\" \\\n  --branch-protection-command \"autodevops-pr-branch-protection verify-github --repo acme/payments-risk-service --branch main\" \\\n  --proof-level live_deployed \\\n  --webhook-signature-verified \\\n  --merge-gate-blocks-incomplete-evidence \\\n  --no-raw-prompt-source-secret-in-outputs \\\n  --raw-prompt-omitted \\\n  --source-content-omitted \\\n  --secrets-absent \\\n  --github-token-absent \\\n  --preproduction-scope \\\n  --require-customer-cloud \\\n  --output ./pr-evidence-rollout-receipt.json\nautodevops-pr-rollout-verify ./pr-evidence-rollout-receipt.json --require-customer-cloud\n```\n\nThe receipt schema is `pr_evidence_rollout_receipt.v1`. The creator derives a receipt from PR evidence JSON, GitHub Check Run output, branch-protection verification output, redacted command evidence, and explicit operator safety/result assertions. Use `buildPrEvidenceRolloutReadinessReport` or `autodevops-pr-rollout-receipt --preflight` before writing a receipt to see missing customer-cloud portal context, webhook delivery/signature evidence, Check Run id or URL, Check Run action/head SHA evidence, PR evidence route pass status, Check Run digest binding, merge-gate command evidence, branch-protection command evidence, safety assertions, and redaction assertions. Preflight mode returns non-zero until the live-deployed receipt would validate, and it does not write `--output` even when one is supplied. A live receipt records the portal PR evidence URL, GitHub repository/PR/head SHA, webhook delivery id, Check Run id or URL, Check Run action, Check Run head SHA, Check Run conclusion, PR evidence summary digest, Check Run output digest, branch-protection mode and verification output, command `output_sha256` / `output_bytes` evidence, safety checks, result checks proving the webhook signature, PR evidence route, Check Run, digest match, merge gate, and branch-protection requirement all worked, optional artifact hashes, and a tamper-evident `receipt_hash` over the receipt content. Live rollout proof rejects missing or mismatched receipt hashes, dry-run Check Run output, Check Runs whose head SHA does not match the rollout receipt head SHA, Check Run evidence digests that do not match the PR evidence summary digest, missing, empty, or reused live command output hashes, and command evidence that embeds normalized raw stdout/stderr/output, prompt/source/source-code/file-content, object-body, tool-output, and secret/key/credential aliases at any depth. PR evidence route / merge-gate result claims require an AutoDevOps PR merge-gate command with `exit_code: 0`, and branch-protection result claims require an AutoDevOps branch-protection verifier command with `exit_code: 0`. The verifier also recomputes result checks from webhook delivery evidence, Check Run action/head SHA/id or URL, PR evidence and Check Run digest binding, targeted merge-gate and branch-protection command evidence, branch-protection verification output, safety flags, and live command output hashes/byte counts, so edited receipts cannot keep positive flags after removing those facts. Artifact paths must be relative paths inside the reviewed rollout evidence directory; absolute paths, URL-style paths, and `..` traversal are rejected. Fixture receipts can be allowed with `--allow-fixture-replay`, but they do not prove a live deployed GitHub App or customer/org branch-protection rollout.\n\nFor audit handoff, wrap the rollout receipt and its supporting files in a `pr_evidence_rollout_bundle.v1` manifest and verify the bundle before making a rollout claim. Live bundle validation requires the evidence package and evidence-package verification transcript, and also rejects a manifest whose `generated_at` predates the rollout receipt it wraps:\n\n```bash\nautodevops-pr-rollout-bundle ./pr-evidence-rollout-bundle.json --require-customer-cloud\nautodevops-pr-rollout-bundle ./pr-evidence-rollout-bundle.json --require-customer-cloud --format json\n```\n\nThe bundle verifier re-checks the embedded rollout receipt, artifact file hashes, portable receipt artifact paths, command `output_ref` coverage, command `output_sha256` to referenced-artifact SHA-256 matching, PR evidence summary digest/status/PR/head SHA, Check Run digest/action/head SHA/conclusion, branch-protection verification output, evidence package, and evidence-package verification transcript. The required live bundle artifacts are the rollout receipt, PR evidence summary JSON, Check Run output JSON, branch-protection verification output, evidence package, and evidence-package verification output; merge-gate, branch-protection command output, and Markdown artifacts can also be included when the receipt cites them.\n\n## Model-risk threshold signoff receipt creator/verifier\n\nUse `buildModelRiskThresholdSignoffReceipt` and `validateModelRiskThresholdSignoffReceipt` when a model-risk owner has reviewed the cognitive-debt monitoring thresholds, response procedure, and review cadence and needs a portable receipt before the team treats those thresholds as customer-executed control evidence. The builder derives the policy hash and result checks from explicit inputs; safety and customer-cloud claims remain explicit assertions. Use `buildModelRiskThresholdSignoffReadinessReport`, `formatModelRiskThresholdSignoffReadinessReport`, or `autodevops-model-risk-signoff-receipt --preflight` before writing the receipt to see missing customer-cloud context, team/owner identity, policy snapshot, owner signoff, monitoring evidence, command evidence, safety assertions, and result checks. For customer-cloud proof, command evidence is hash-only: it must include a zero exit code, output SHA-256, and non-zero output byte count; the hash must match the cited cognitive-debt export, the argv must reference that export URL, and the command record must not embed normalized raw stdout/stderr/output, prompt/source/source-code/file-content, object-body, tool-output, or secret/key/credential aliases at any depth. The verifier recomputes result checks from the policy hash, signoff freshness, owner identity, review cadence, response procedure, export URL, and export hash, so stale positive flags cannot hide missing export evidence or stale signoff.\n\n```js\nconst {\n  buildModelRiskThresholdSignoffReceipt,\n  buildModelRiskThresholdSignoffReadinessReport,\n  formatModelRiskThresholdSignoffReadinessReport,\n  validateModelRiskThresholdSignoffReceipt,\n} = require('@autodevops/verifier-portal-client');\n\nconst receipt = buildModelRiskThresholdSignoffReceipt({\n  proofLevel: 'live_portal',\n  environment: { type: 'customer_cloud', cloudProvider: 'aws' },\n  team,\n  modelRiskOwner,\n  policy,\n  signedAt,\n  responseProcedure,\n  reviewCadenceDays: 90,\n  evidence,\n  safetyChecks,\n});\n\nconst result = validateModelRiskThresholdSignoffReceipt(receipt, {\n  requireCustomerCloud: true,\n});\nconst readiness = buildModelRiskThresholdSignoffReadinessReport(receipt, {\n  requireCustomerCloud: true,\n});\n\nif (!readiness.ready) {\n  throw new Error(formatModelRiskThresholdSignoffReadinessReport(readiness));\n}\n```\n\nAfter building or installing the package, create and validate the same receipt as a CLI:\n\n```bash\nautodevops-model-risk-signoff-receipt \\\n  --preflight \\\n  --policy ./cognitive-debt-policy.json \\\n  --team-id team-payments-risk \\\n  --model-risk-owner-id model-risk-owner \\\n  --response-procedure \"Route critical alerts to model-risk review within one business day.\" \\\n  --review-cadence-days 90 \\\n  --deviation-queue-url https://autodevops.customer.example/verification-portal/deviations \\\n  --cognitive-debt-export-url https://autodevops.customer.example/api/verification-portal/developers/developer%3Adana/cognitive-debt/export \\\n  --cognitive-debt-export-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-description \"export cognitive-debt report\" \\\n  --command-argv '[\"curl\",\"-s\",\"https://autodevops.customer.example/api/verification-portal/developers/developer%3Adana/cognitive-debt/export\"]' \\\n  --command-exit-code 0 \\\n  --command-output-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-output-bytes 4096 \\\n  --proof-level live_portal \\\n  --environment customer_cloud \\\n  --require-customer-cloud \\\n  --preproduction-scope-only \\\n  --customer-owned-portal \\\n  --no-raw-prompts-or-source-content \\\n  --model-risk-owner-reviewed-thresholds \\\n  --response-procedure-documented \\\n  --output ./model-risk-signoff-receipt.json \\\n  --format json\nautodevops-model-risk-signoff-receipt \\\n  --policy ./cognitive-debt-policy.json \\\n  --team-id team-payments-risk \\\n  --model-risk-owner-id model-risk-owner \\\n  --response-procedure \"Route critical alerts to model-risk review within one business day.\" \\\n  --review-cadence-days 90 \\\n  --deviation-queue-url https://autodevops.customer.example/verification-portal/deviations \\\n  --cognitive-debt-export-url https://autodevops.customer.example/api/verification-portal/developers/developer%3Adana/cognitive-debt/export \\\n  --cognitive-debt-export-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-description \"export cognitive-debt report\" \\\n  --command-argv '[\"curl\",\"-s\",\"https://autodevops.customer.example/api/verification-portal/developers/developer%3Adana/cognitive-debt/export\"]' \\\n  --command-exit-code 0 \\\n  --command-output-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-output-bytes 4096 \\\n  --proof-level live_portal \\\n  --environment customer_cloud \\\n  --require-customer-cloud \\\n  --preproduction-scope-only \\\n  --customer-owned-portal \\\n  --no-raw-prompts-or-source-content \\\n  --model-risk-owner-reviewed-thresholds \\\n  --response-procedure-documented \\\n  --output ./model-risk-signoff-receipt.json\nautodevops-model-risk-signoff-verify ./model-risk-signoff-receipt.json --require-customer-cloud\nautodevops-model-risk-signoff-verify ./model-risk-signoff-receipt.json --format json\n```\n\nThe receipt schema is `autodevops.model_risk_threshold_signoff_receipt.v1`. The verifier checks the policy hash against the same `autodevops.cognitive_debt_monitoring_policy.v1` hash contract used by the portal, signer identity, response procedure, review cadence, computed signoff freshness from `signedAt + reviewCadenceDays` against `generatedAt`, customer-cloud proof marker, evidence URLs, command exit codes, output hashes, output byte counts, absence of normalized raw output/prompt/source/tool-output/secret/key/credential aliases at any depth in command evidence, and safety/result assertions. Preflight mode returns non-zero until the candidate signoff would validate and does not write `--output` even when one is supplied. Future-dated signoffs and signoffs older than the configured review cadence fail even when the receipt asserts `resultChecks.signoffCurrent: true`. Fixture replay validates receipt shape only; completed customer execution still requires a customer-cloud receipt signed by the model-risk owner.\n\n## Agent Trust Score threshold signoff receipts\n\nUse `buildAgentTrustThresholdSignoffReceipt` and `validateAgentTrustThresholdSignoffReceipt` when a model-risk owner needs to approve customer-specific `agent_trust_score.v1` thresholds without exposing proprietary scoring internals. Use `buildAgentTrustThresholdSignoffReadinessReport`, `formatAgentTrustThresholdSignoffReadinessReport`, or `autodevops-agent-trust-signoff-receipt --preflight` before writing the receipt to see missing customer-cloud context, team/owner identity, policy snapshot, calibration evidence, owner signoff, trust-score evidence, command evidence, safety assertions, and result checks. The receipt schema is `autodevops.agent_trust_threshold_signoff_receipt.v1`; it binds the signed threshold policy, evidence-window minimums, reviewed agent types, response procedure, evidence-package hash, and Agent Trust Score chapter hash. For customer-cloud proof, command evidence is hash-only: it must include a zero exit code, output SHA-256, and non-zero output byte count; the hash must match the cited evidence package or Agent Trust chapter, argv must reference the cited evidence URL, and the command record must not embed normalized raw stdout/stderr/output, prompt/source/source-code/file-content, object-body, tool-output, or secret/key/credential aliases at any depth. The verifier recomputes result checks from the policy hash, threshold order, calibration minimums, signoff freshness, owner identity, response procedure, evidence package hash, and trust-score chapter hash.\n\n```bash\nautodevops-agent-trust-signoff-receipt \\\n  --preflight \\\n  --policy ./agent-trust-policy.json \\\n  --team-id team-payments-risk \\\n  --model-risk-owner-id model-risk-owner \\\n  --response-procedure \"Route low-trust agents to model-risk review before sensitive actions.\" \\\n  --review-cadence-days 90 \\\n  --baseline-window-start 2026-06-01T00:00:00.000Z \\\n  --baseline-window-end 2026-06-16T00:00:00.000Z \\\n  --observed-event-count 42 \\\n  --observed-session-count 7 \\\n  --agent-count 2 \\\n  --reviewed-agent-types \"Claude Code,Cursor Agent\" \\\n  --benchmark-mode customer_internal \\\n  --agent-trust-scores-url https://autodevops.customer.example/verification-portal/agents \\\n  --evidence-package-id evidence-package-1 \\\n  --evidence-package-hash aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --agent-trust-score-chapter-hash bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb \\\n  --evidence-package-url https://autodevops.customer.example/api/verification-portal/evidence/export?scope=time_window \\\n  --command-description \"export evidence package with agent trust score chapter\" \\\n  --command-argv '[\"curl\",\"-s\",\"https://autodevops.customer.example/api/verification-portal/evidence/export?scope=time_window\"]' \\\n  --command-exit-code 0 \\\n  --command-output-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-output-bytes 8192 \\\n  --proof-level live_portal \\\n  --environment customer_cloud \\\n  --require-customer-cloud \\\n  --preproduction-scope-only \\\n  --customer-owned-portal \\\n  --no-raw-prompts-or-source-content \\\n  --methodology-internals-protected \\\n  --model-risk-owner-reviewed-thresholds \\\n  --response-procedure-documented \\\n  --output ./agent-trust-signoff-receipt.json \\\n  --format json\nautodevops-agent-trust-signoff-receipt \\\n  --policy ./agent-trust-policy.json \\\n  --team-id team-payments-risk \\\n  --model-risk-owner-id model-risk-owner \\\n  --response-procedure \"Route low-trust agents to model-risk review before sensitive actions.\" \\\n  --review-cadence-days 90 \\\n  --baseline-window-start 2026-06-01T00:00:00.000Z \\\n  --baseline-window-end 2026-06-16T00:00:00.000Z \\\n  --observed-event-count 42 \\\n  --observed-session-count 7 \\\n  --agent-count 2 \\\n  --reviewed-agent-types \"Claude Code,Cursor Agent\" \\\n  --benchmark-mode customer_internal \\\n  --agent-trust-scores-url https://autodevops.customer.example/verification-portal/agents \\\n  --evidence-package-id evidence-package-1 \\\n  --evidence-package-hash aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --agent-trust-score-chapter-hash bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb \\\n  --evidence-package-url https://autodevops.customer.example/api/verification-portal/evidence/export?scope=time_window \\\n  --command-description \"export evidence package with agent trust score chapter\" \\\n  --command-argv '[\"curl\",\"-s\",\"https://autodevops.customer.example/api/verification-portal/evidence/export?scope=time_window\"]' \\\n  --command-exit-code 0 \\\n  --command-output-sha256 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\n  --command-output-bytes 8192 \\\n  --proof-level live_portal \\\n  --environment customer_cloud \\\n  --require-customer-cloud \\\n  --preproduction-scope-only \\\n  --customer-owned-portal \\\n  --no-raw-prompts-or-source-content \\\n  --methodology-internals-protected \\\n  --model-risk-owner-reviewed-thresholds \\\n  --response-procedure-documented \\\n  --output ./agent-trust-signoff-receipt.json\nautodevops-agent-trust-signoff-verify ./agent-trust-signoff-receipt.json --require-customer-cloud\n```\n\nThe verifier checks threshold ordering, policy hash, signer identity, evidence-window minimums, evidence-package trust-score chapter hash, response procedure, review cadence, customer-cloud proof marker, command exit codes, output hashes, output byte counts, absence of normalized raw output/prompt/source/tool-output/secret/key/credential aliases at any depth in command evidence, and safety/result assertions. Preflight mode returns non-zero until the candidate signoff would validate and does not write `--output` even when one is supplied. Fixture replay validates the receipt shape only; completed customer execution still requires a customer-cloud receipt signed by the model-risk owner.\n\n## Regulated control evidence receipt creator/verifier\n\nUse `buildRegulatedControlEvidenceReceipt` and `validateRegulatedControlEvidenceReceipt` when a platform, security, or model-risk reviewer needs one top-level handoff artifact that binds the lower-level AutoDevOps proof outputs together. The builder derives artifact facts from `agent_activity.v1` conformance, a hash-bound compliance evidence pack, passing PR merge evidence, PR evidence rollout receipt, an independently verified evidence package, portal-client publication-readiness receipt, connector proof including its receipt hash, model-risk threshold signoff, Agent Trust Score threshold signoff, evidence object-anchor validation, and audit-chain verification inputs, while customer-cloud proof level and scope safety assertions stay explicit operator assertions. Validation recomputes every top-level `resultChecks.*` flag from those artifact summaries, so positive aggregate conformance, PR, rollout, evidence-package, connector, publication, signoff, object-anchor, audit-chain, or control-review flags cannot survive weakened artifact summaries. Use `buildRegulatedControlEvidenceReadinessReport`, `formatRegulatedControlEvidenceReadinessReport`, or `autodevops-control-evidence-receipt --preflight` before writing the receipt to see missing customer-cloud context, scope anchors, conformance","readmeFilename":"README.md","_rev":"1-87c8b576257f424f408dbc2792443bab"}