Add Phase 4 community validation packet

CHANGELOG.md

@@ -13,6 +13,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and
 - Add backward-compatible cost, timeout, and freshness metadata to agent-job results.
 - Add a default-deny action-control schema, deterministic evaluator, documentation, and synthetic dry-run and authorized-action examples.
 - Add a deterministic local Virtuals ACP public-evidence verification service with a bounded request schema, conforming job-result receipts, hidden offering metadata, timeout/retry behavior, and synthetic buyer/provider lifecycle fixtures.
+- Add a network-free community-validation harness, bounded result schema, external tester protocol, feedback template, and unsent upstream-review and sponsorship-request drafts.
 
 ### Security
 

README.md

@@ -88,6 +88,8 @@ For deterministic dry-run and default-deny approval decisions, see [docs/action-
 
 For the selected Phase 3 Virtuals ACP job, see [docs/virtuals-acp-evidence-service.md](docs/virtuals-acp-evidence-service.md), `schemas/acp-evidence-request-v1.schema.json`, and `agentic_commerce.acp_evidence`. Local mode simulates a buyer/provider evidence-verification lifecycle, emits a conforming job-result receipt, and performs no wallet, payment, signing, inference, or network operation.
 
+For network-free external testing, public-safe result records, and draft upstream review questions, see [docs/community-validation.md](docs/community-validation.md), [docs/upstream-review-requests.md](docs/upstream-review-requests.md), and `scripts/run_community_validation.py`. Generated validation records are not uploaded automatically and default to no public-sharing approval.
+
 For silent compatibility drift detection and bounded weekly project evidence, see [docs/automation.md](docs/automation.md). These helpers are read-only and never perform GitHub mutations.
 
 At the 2026-07-11 compatibility check, the datanet and pod catalogs were live. The documented public stats route returned HTTP 404, so `status` and `snapshot` correctly returned partial result code `2` while preserving catalog data. The upstream pods route also ignored its requested page size; the client applies the requested limit after a capped download.

docs/README.md

@@ -5,6 +5,8 @@
 - [Agent job result schema](provenance-schemas.md#agent-job-result-v1)
 - [Dry-run and approval controls](action-controls.md)
 - [Virtuals ACP public-evidence reference service](virtuals-acp-evidence-service.md)
+- [Community validation protocol](community-validation.md)
+- [Upstream review request drafts](upstream-review-requests.md)
 - [Read-only maintenance automation](automation.md)
 - [Release process](releasing.md)
 

docs/community-validation.md

@@ -0,0 +1,143 @@
+# Community validation protocol
+
+## Purpose
+
+Phase 4 tests whether the toolkit is useful to people outside its maintainers. This protocol gives external users a reproducible, network-free way to exercise the Phase 3 Virtuals ACP reference service and return bounded public evidence.
+
+Running the protocol does not contact Reppo, Virtuals, GitHub, a wallet, an inference provider, or any other remote service. Nothing is uploaded automatically.
+
+## What the harness checks
+
+`scripts/run_community_validation.py` exercises four synthetic behaviors:
+
+1. the published evidence bundle produces a passing receipt and exit code `0`;
+2. a provenance mismatch produces a completed finding and exit code `2`;
+3. bounded retry exhaustion produces a sanitized failed receipt and exit code `1`;
+4. the passing flow remains local, zero-cost, and explicitly simulated.
+
+The result conforms to `schemas/community-validation-result-v1.schema.json`. It intentionally excludes usernames, hostnames, architecture, local paths, wallets, accounts, raw logs, and environment variables.
+
+## Tester protocol
+
+### 1. Use a clean public checkout
+
+Clone the public repository or update an existing public-only checkout. Do not run this protocol from a directory containing copied private artifacts.
+
+Record the public revision:
+
+```bash
+git rev-parse --short=12 HEAD
+```
+
+### 2. Run the complete repository checks
+
+```bash
+PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=src python3.11 -B \
+  -m unittest discover -s tests -q
+python3 scripts/check_public_boundary.py .
+git diff --check
+python3 -m compileall -q src scripts tests
+```
+
+No package installation is required for the runtime harness. The complete schema-contract tests require the repository's documented development environment.
+
+### 3. Generate the bounded validation result
+
+The maintainer should assign a non-personal validation ID such as `community:test-run:001`. Do not put a name, email address, account ID, wallet address, hostname, or local directory in the ID.
+
+```bash
+PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=src python3.11 -B \
+  scripts/run_community_validation.py \
+  --validation-id community:test-run:001 \
+  --revision YOUR_PUBLIC_REVISION \
+  --pretty > community-validation-result.json
+```
+
+Expected command exit code: `0`.
+
+Expected result:
+
+- top-level `status` is `passed`;
+- all four checks have `status: pass`;
+- `errors` is empty;
+- both `sharing` flags are `false`.
+
+The false sharing flags are deliberate. Generation is not publication approval.
+
+### 4. Review before sharing
+
+Open `community-validation-result.json` and verify that it contains no:
+
+- local or home-directory path;
+- username, hostname, email address, or contact detail;
+- account, wallet, transaction, or payment identifier;
+- credential, token, cookie, environment variable, or raw log;
+- private project name, communication, research, or report.
+
+After completing that human review, a tester who chooses to submit the record may set:
+
+```json
+"sharing": {
+  "reviewedForSensitiveData": true,
+  "publicSubmissionApproved": true
+}
+```
+
+Do not change those flags on another person's behalf.
+
+### 5. Provide bounded feedback
+
+Use `examples/community-validation/feedback-template.md`. A tester may submit the reviewed JSON and feedback through a public GitHub issue or pull request when the maintainer opens an approved collection channel.
+
+Until such a channel exists, keep the result local. Do not send it through private communications for later copying into this repository.
+
+## What counts as an external test user
+
+A Phase 4 test counts only when all of the following are true:
+
+- the person is not acting as the toolkit maintainer for that run;
+- they run the protocol against a public revision;
+- the machine-readable result passes the schema contract;
+- they provide at least one concrete observation in the feedback template;
+- they intentionally approve any public submission;
+- the maintainer records a public evidence link after review.
+
+Expressions of interest, maintainers running the harness three times, copied results, or unpublished private feedback do not count toward the roadmap target.
+
+Recommended tester mix:
+
+1. one schema consumer;
+2. one command-line user working from a fresh checkout;
+3. one ACP builder able to assess the offering and lifecycle mapping.
+
+## Maintainer evidence table
+
+Do not add a row until public evidence exists.
+
+| Validation ID | Public revision | Tester perspective | Result evidence | Feedback evidence | Counted |
+|---|---|---|---|---|---|
+
+The table must link only to intentionally public artifacts. It must not record private contact details or summarize private conversations.
+
+## Decision criteria
+
+After at least three qualifying tests and upstream review attempts, record one outcome:
+
+- **continue** — repeat use and a concrete next integration need are demonstrated;
+- **narrow** — schemas or inspection are useful, but a live ACP provider is not justified;
+- **archive** — external reproduction or demand is not demonstrated.
+
+Inference credits alone cannot determine the outcome.
+
+## Sponsorship gate
+
+Do not request inference sponsorship until:
+
+- three external test users have qualifying public evidence;
+- Reppo and Virtuals review requests have been made through approved public channels;
+- a real inference-backed next step is identified;
+- expected usage has been measured or bounded without inventing demand.
+
+The current local service uses no inference, so it provides no evidence for a credit amount. Any later request should state an exact 60-day term, a hard total cap, periodic caps, permitted public workloads, data-retention terms, revocation conditions, expiry behavior, and the absence of any assumed token launch, exclusivity, wallet custody, or private-data access.
+
+Record the outcome even if no applicable program exists, terms are unsuitable, or sponsorship is unnecessary.

docs/upstream-review-requests.md

@@ -0,0 +1,155 @@
+# Upstream review request drafts
+
+These are review drafts, not evidence that outreach occurred. Sending a request, opening an issue, or submitting a pull request is a separate human-approved action.
+
+Before using either draft:
+
+1. verify all linked artifacts are present on the public default branch;
+2. rerun the relevant live compatibility check;
+3. remove observations that are stale or cannot be reproduced;
+4. use an upstream project's preferred public contribution channel;
+5. record only public response links in this repository.
+
+## Reppo builder review
+
+### Suggested title
+
+```text
+Feedback request: public inspector behavior and portable provenance contracts
+```
+
+### Draft
+
+```text
+We maintain the independent Agentic Commerce Toolkit, which includes a
+standard-library, read-only inspector for Reppo's documented public catalog
+endpoints and portable source-manifest / agent-job-result schemas.
+
+Project:
+https://github.com/nccrypto/agentic-commerce-toolkit
+
+Inspector documentation:
+https://github.com/nccrypto/agentic-commerce-toolkit/blob/main/docs/reppo-inspector.md
+
+Provenance contracts:
+https://github.com/nccrypto/agentic-commerce-toolkit/blob/main/docs/provenance-schemas.md
+
+We would value upstream review of four bounded questions:
+
+1. Are the public endpoint boundaries and partial-result semantics still
+   consistent with the intended public API?
+2. Is preserving upstream objects inside a stable outer envelope preferable
+   to normalizing their internal field names?
+3. Are the source-manifest and agent-job-result contracts useful for public
+   agent workflows consuming Reppo data?
+4. Did our freshly reproduced compatibility observations identify a current
+   documentation or API-behavior gap that should be reported separately?
+
+The inspector has no authentication, write, wallet, or transaction support.
+Its CI tests use synthetic fixtures and do not contact live services.
+
+We are requesting technical feedback, not endorsement. We will record any
+limitations or corrections in the public project.
+```
+
+### Required fresh evidence
+
+Do not mention an unavailable route, ignored pagination parameter, or other behavior unless it has been rerun immediately before outreach and recorded without private logs or credentials.
+
+## Virtuals ACP builder review
+
+### Suggested title
+
+```text
+Feedback request: local ACP public-evidence provider and receipt mapping
+```
+
+### Draft
+
+```text
+We maintain the independent Agentic Commerce Toolkit and have implemented a
+network-free Virtuals ACP reference provider for one bounded job: public
+evidence verification.
+
+Project:
+https://github.com/nccrypto/agentic-commerce-toolkit
+
+Reference-service documentation:
+https://github.com/nccrypto/agentic-commerce-toolkit/blob/main/docs/virtuals-acp-evidence-service.md
+
+Synthetic offering:
+https://github.com/nccrypto/agentic-commerce-toolkit/blob/main/examples/virtuals-acp-evidence/offering-v1.example.json
+
+The buyer supplies a source manifest plus an agent-job result. The provider
+checks contract shape, provenance linkage, and public HTTPS source policy,
+then returns the existing agent-job-result contract as a machine-readable
+receipt.
+
+Local mode simulates open → budget_set → funded → submitted → completed, but
+performs no ACP authentication, registration, signing, wallet operation,
+payment, settlement, inference, or network request. The offering example is
+hidden and has not been registered.
+
+We would value review of five bounded questions:
+
+1. Do the requirement and deliverable shapes map cleanly to the current ACP
+   offering model?
+2. Is reusing a structured agent-job result as the provider receipt practical?
+3. Does the documentation distinguish simulated lifecycle states clearly
+   enough from live on-chain settlement?
+4. What boundary would you recommend for a future adapter to acp-cli or
+   acp-node-v2 while keeping the verifier itself deterministic and testable?
+5. Is this provider-side evidence job sufficiently distinct from existing
+   evaluator/recompute examples?
+
+We are requesting technical feedback, not endorsement, credits, listing, or
+promotion. Corrections and limitations will be recorded publicly.
+```
+
+## Upstream contribution rule
+
+A review request is not permission to create unrelated upstream work. Open an issue or pull request only when a fresh, reproducible observation identifies a concrete documentation, compatibility, or interoperability gap. If no useful contribution is warranted, record that outcome instead of manufacturing activity.
+
+## Review evidence record
+
+Do not populate this table with private messages or contact information.
+
+| Upstream | Public request URL | Public response URL | Material correction or recommendation | Status |
+|---|---|---|---|---|
+| Reppo | — | — | — | not sent |
+| Virtuals | — | — | — | not sent |
+
+## Bounded 60-day sponsorship request outline
+
+This outline is intentionally incomplete until community testing demonstrates an inference-backed need.
+
+```text
+Subject: Bounded 60-day public integration validation request
+
+Shipped evidence:
+- public repository and release/commit;
+- qualifying community-validation evidence;
+- upstream technical review links;
+- exact proposed inference-backed workload;
+- measured or conservatively bounded usage.
+
+Requested term:
+- exactly 60 days;
+- exact total credit cap: TO BE DERIVED FROM MEASURED USAGE;
+- exact daily or weekly cap: TO BE DERIVED FROM MEASURED USAGE;
+- permitted use: public toolkit validation workload only;
+- automatic expiry after the term;
+- no production-wallet custody or private-data processing.
+
+Terms to clarify:
+- eligible models and endpoints;
+- telemetry and data retention;
+- rate limits and revocation;
+- unused-credit expiry;
+- attribution requirements;
+- whether exclusivity, token launch, deposits, or other obligations apply.
+
+The toolkit does not assume approval, renewal, endorsement, or future credits.
+```
+
+Record one public outcome: accepted, declined, no applicable program, unsuitable terms, unnecessary, or deferred for insufficient demand.

examples/README.md

@@ -5,5 +5,6 @@
 - [Agent job result](agent-job-result/README.md)
 - [Dry-run and approval controls](action-control/README.md)
 - [Virtuals ACP public-evidence service](virtuals-acp-evidence/README.md)
+- [Community validation](community-validation/README.md)
 
 Tested, public-source-only examples live here.

examples/community-validation/README.md

@@ -0,0 +1,20 @@
+# Community validation examples
+
+Phase 4 uses these public-safe artifacts to collect reproducible external testing evidence:
+
+- `test-result-v1.example.json` — deterministic output from the network-free validation harness;
+- `feedback-template.md` — bounded qualitative feedback with an explicit public-sharing review.
+
+Generate a fresh local result from the public repository root:
+
+```bash
+PYTHONDONTWRITEBYTECODE=1 PYTHONPATH=src python3.11 -B \
+  scripts/run_community_validation.py \
+  --validation-id community:test-run:001 \
+  --revision YOUR_PUBLIC_REVISION \
+  --pretty > community-validation-result.json
+```
+
+Generated records default both sharing flags to `false`. See [`docs/community-validation.md`](../../docs/community-validation.md) before changing or submitting them.
+
+The committed example is synthetic maintainer evidence that the harness works. It does not count as one of the three required external users and does not claim upstream review, endorsement, sponsorship, or live ACP execution.