AppSurface package chooser

Generated from packages/package-index.yml and evaluated project metadata. Do not edit this file by hand.

AppSurface is a coordinated .NET 10 package family. Start with the package that matches the app you're building, then add optional modules only when your app needs them.

All direct-install packages and tools currently target net10.0. Published library rows use dotnet package add; in .NET 10, dotnet package add and dotnet add package are equivalent. Tool rows use dotnet tool install. Public previews marked publication held are source-only and intentionally have no install command.

Web app

Install this first for a normal ASP.NET Core app with AppSurface modules when you want the base web startup pipeline and either one-canonical-document browser-local presentation preferences or host-owned request-aware selection of registered theme pairs. Choose exactly one theme-document adapter; request-aware selection requires a scoped policy over already-authorized host context. Add opt-in health/readiness probes, protected preview named deploy evidence with a bounded result envelope, conventional browser affordances, PWA install metadata, application badging, push-worker plumbing, server-known push-readiness posture evidence, or authenticated config-audit diagnostics before layering on optional UI or docs packages.

dotnet package add ForgeTrust.AppSurface.Web

What you get: Base ASP.NET Core hosting; one selected theme-document adapter (browser-local Light/Dark preference or host-owned registered-pair selection); deterministic CSP hash/nonce support for browser preferences; opt-in public /health and /ready ASP.NET Core health-check probes; pre-routing and endpoint-aware middleware composition; endpoint composition; opt-in protected single-evaluation and bounded aggregate named-canary endpoints with typed and declared bounded response evidence plus fixed completion telemetry; conventional browser error-page hooks; opt-in PWA manifest/head/diagnostic/shared-worker endpoints; default-off page and active-worker application-badging adapters; explicit offline behavior; push-event plumbing; an inert service-worker registration helper; the privacy-safe IPwaPushReadinessProvider contribution point for readiness-posture evidence; opt-in authenticated config audit diagnostics endpoint mapping; and the core AppSurface web module contract.

Not included: Tenant lookup, authentication or authorization, mapping storage, tenant-key normalization, cookies, account/device synchronization, response-cache partitioning or invalidation, consent policy, server-side preference reads, Canary triggers, retries, polling, caller workflow/CI policy, readiness effects, a health-check adapter, authorization policy definitions, or automatic classification/redaction of application-authored canary evidence; OpenAPI generation, Scalar UI, RazorWire reactive UI, Tailwind build integration, AppSurface Docs host, browser-specific install or permission UI, push subscription persistence or delivery, broad offline route/app-data caching, or automatic diagnostics exposure.

Read next: Package-first quickstart

Composed local proof: Product readiness lab shows how the web, auth, flow, DurableTask-facing, Aspire, and Postgres product-state pieces fit together without claiming production hosting or Durable Task storage ownership. Its paired AppHost verify profile starts local Postgres and fails if the Postgres product-state row does not become proven-locally.

Release and readiness:

• Release hub keeps the public release story, adoption risk, and policy links in one place.
• current release note is the current package-facing story for this coordinated release.
• Unreleased proof artifact shows what is queued for the next coordinated version.
• CHANGELOG.md is the compact ledger for tagged and in-flight package changes.
• Pre-1.0 upgrade policy explains the current stability contract before v1.0.0.

Also building...

• Add ForgeTrust.AppSurface.Config.LocalSecrets after Config when local development secrets need source-aware diagnostics before a remote vault exists, including trusted Linux secret-tool resolution for nonstandard installs.
• Add ForgeTrust.AppSurface.Config.GoogleSecretManager after Config when production-like Google Cloud hosts should read mapped AppSurface config secrets from Secret Manager with fail-closed diagnostics.
• Add ForgeTrust.AppSurface.Auth when reusable modules need host-neutral auth results or app-owned identity mapping boundaries without taking a web or persistence dependency; use the Auth adoption ladder when choosing among auth packages.
• Add ForgeTrust.AppSurface.Auth.AspNetCore after ForgeTrust.AppSurface.Auth when ASP.NET Core host policies should flow into AppSurface auth results or Minimal API ProblemDetails responses; use the Auth adoption ladder and run the Auth Web/RazorWire proof.
• Add ForgeTrust.AppSurface.Auth.AspNetCore.DevAuth after ForgeTrust.AppSurface.Auth.AspNetCore only for Development hosts or explicit local/proof environments that need fake local personas to prove AppSurface policy results; use the Auth adoption ladder to keep DevAuth separate from Auth.Testing.
• Add ForgeTrust.AppSurface.Auth.AspNetCore.Oidc after ForgeTrust.AppSurface.Auth.AspNetCore when a host wants AppSurface-named cookie/OIDC schemes while preserving ASP.NET Core ownership of middleware, defaults, and provider behavior; use the Auth adoption ladder before copying OIDC proof code.
• Add ForgeTrust.AppSurface.Auth.Aspire.Keycloak in AppHost/dev/test projects only when a real local OIDC provider proof should pair with ForgeTrust.AppSurface.Auth.AspNetCore.Oidc; use the theme lifecycle guide and Auth adoption ladder to keep it separate from DevAuth, OIDC registration, and Auth.Testing.
• Add ForgeTrust.AppSurface.Auth.Testing to integration test projects when AppSurface Auth.AspNetCore policy results need deterministic personas and canonical assertions; use the Auth adoption ladder to keep Auth.Testing separate from local DevAuth runtime personas.
• Add ForgeTrust.AppSurface.Intelligence when you want vendor-neutral product event contracts and optional host-owned analytics sinks.
• Add ForgeTrust.AppSurface.Observability when an AppSurface app should send logs, traces, and metrics to Aspire or an OTLP collector.
• Add ForgeTrust.AppSurface.Flow when you want generated-case typed process graphs, inferred port mapping, and local runner tests.
• Add ForgeTrust.AppSurface.Flow.DurableTask after ForgeTrust.AppSurface.Flow when a typed process needs durable execution.
• Add ForgeTrust.AppSurface.Workers when worker chains need durable claim, completion, and projection-repair contracts without taking a runtime or persistence dependency.
• Add ForgeTrust.AppSurface.Workers.DurableTask after ForgeTrust.AppSurface.Workers and ForgeTrust.AppSurface.Flow.DurableTask when worker contracts should be driven by Durable Task orchestration decisions.
• Add ForgeTrust.AppSurface.Durable for portable durable authoring and registration; no runtime starts until the host installs a provider explicitly.
• Reference the Provider SPI only when implementing or hosting a durable runtime; applications normally depend on ForgeTrust.AppSurface.Durable alone, while retention implementers and operators may also need ForgeTrust.AppSurface.Durable.Provider for the application-authorized retention contracts.
• Add the PostgreSQL provider when one database must atomically own Work, explicit one-transition Flow state, Work-first Schedule storage, versioned W3C causal evidence, and verified per-Flow retention. Start with the local PostgreSQL tutorial: generate a reviewed script and preflight with appsurface durable schema, apply only with an explicit migration-owner environment variable, then use the verified retention guidance and explicit AddWorkerHost() path when those capabilities are required.
• Start with ForgeTrust.AppSurface.Console for CLI commands or worker-style processes that should share AppSurface module composition.
• Add ForgeTrust.AppSurface.Dependency.Autofac when your app already uses Autofac and your modules need Autofac-specific registrations.
• Add ForgeTrust.AppSurface.Deployment directly only when authoring a deployment provider or inspecting portable deployment intent; normal Aspire consumers receive it transitively.
• Add ForgeTrust.AppSurface.Deployment.GcpCloudRun beside the Aspire package when an existing Cloud Run migration job should move from duplicated deployment mapping to deterministic publish artifacts and read-only parity proof.
• Start with ForgeTrust.AppSurface.Evidence.Contracts only when building a consumer-owned EvidenceHost integration or gate; most adopters should begin with the EvidenceHost guide and public CLI.
• Add ForgeTrust.AppSurface.Evidence.Planner after the contracts package only for a custom CI integration that needs explainable policy resolution without the AppSurface CLI.
• Use ForgeTrust.AppSurface.Evidence.Cli only as the internal workflow behind a custom AppSurface CLI composition; normal CI users should follow the EvidenceHost guide.
• Add ForgeTrust.AppSurface.Evidence.Aspire only to test or CI composition for explicit resource-backed evidence; keep application AppHosts and runtime projects unaware of it.
• Start with ForgeTrust.AppSurface.Aspire for distributed app-model projects and service-default composition; add a provider package when the same AppHost topology should publish deployment artifacts through native Aspire commands.
• Add ForgeTrust.AppSurface.Aspire.Testing to tests for profile-based AppHosts; native AppHosts should continue using Aspire's native testing API.
• Add ForgeTrust.AppSurface.Web.Push when the shared PWA worker needs a protected standards-based subscription and delivery rail while the host retains product policy and storage; the package contributes redacted readiness evidence that appsurface pwa verify --surface push|all can validate without claiming browser or delivery success.
• Add ForgeTrust.AppSurface.Web.Scalar after ForgeTrust.AppSurface.Web.OpenApi when you want a hosted API reference UI.
• Add ForgeTrust.RazorWire when you want reactive Razor UI, Turbo-style streams, server-rendered islands, lifecycle-safe app-authored root or page-lifecycle behaviors, local declarative form interactions, or passive auth-result UI projection.
• Add ForgeTrust.RazorWire.Auth.AspNetCore after ForgeTrust.RazorWire and ForgeTrust.AppSurface.Auth.AspNetCore when Razor views should project host policy results without owning auth enforcement.
• Add ForgeTrust.AppSurface.Web.Tailwind when you want Tailwind without a separate Node.js asset pipeline.
• Install ForgeTrust.AppSurface.Cli when you want appsurface release compose to keep concurrent changes out of a shared changelog, appsurface canary poll, appsurface docs, appsurface pwa verify install or server-known push-readiness posture evidence, explicit appsurface durable schema deployment checks, private coverage commands, explicit macOS LocalSecrets migration, or declared secret-transfer workflows without running from source. Release composition writes only an explicit --output --apply destination; repository release preparation and publication remain separate. Durable script stays offline; online operations resolve only a named environment variable and apply requires --apply. Verify tool installs with appsurface --version or dotnet tool run appsurface --version for local manifests. PWA evidence is not scoring or delivery proof.

Package matrix

Swipe to compare package details on narrow screens.

Support and proof-host surfaces

Support and runtime packages

• ForgeTrust.AppSurface.Evidence.Coverage: Private coverage execution implementation restored only through first-party AppSurface CLI and Evidence workflow packages; it is not a direct-install integration surface. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.ReleaseContracts: Transitive release metadata contracts used by ForgeTrust.AppSurface.Docs and repository release tooling. Restore it through those packages rather than installing it directly. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Runtime.linux-arm64: Direct/compatibility Tailwind standalone runtime for Linux Arm64 build hosts. It is no longer restored through ForgeTrust.AppSurface.Web.Tailwind. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Runtime.linux-x64: Direct/compatibility Tailwind standalone runtime for Linux x64 build hosts. It is no longer restored through ForgeTrust.AppSurface.Web.Tailwind. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Runtime.osx-arm64: Direct/compatibility Tailwind standalone runtime for macOS Arm64 build hosts. It is no longer restored through ForgeTrust.AppSurface.Web.Tailwind. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Runtime.osx-x64: Direct/compatibility Tailwind standalone runtime for macOS x64 build hosts. It is no longer restored through ForgeTrust.AppSurface.Web.Tailwind. Release: support runtime; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Runtime.win-x64: Direct/compatibility Tailwind standalone runtime for Windows x64 build hosts. It is no longer restored through ForgeTrust.AppSurface.Web.Tailwind. Release: support runtime; not applicable; notes.

Docs and proof hosts

• ForgeTrust.AppSurface.Docs: Reusable docs package for harvesting repository docs into an AppSurface Docs UI, with source harvesting, search, release archives, diagnostics, and a shared semantic System/Light/Dark theme-pair adapter for package-owned docs chrome. This is a real package, but it is a proof-host surface rather than the default first install for general AppSurface apps. Its exact coordinated GHSA-pgww-w46g-26qg graph is AngleSharp [1.7.1], HtmlSanitizer [9.2.995], and AngleSharp.Css [1.0.1]. Stable verification requires every package dependency container to contain each identity exactly once with its exact bracketed version, and the independent locked consumer proof must resolve the freshly packed Docs artifact plus this exact graph. The Docs dependency security boundary covers rendered package-documentation fragments, not general UGC or host CSP. Release: proof host; not applicable; notes. Start here: AppSurface Docs README
• ForgeTrust.AppSurface.Docs.Standalone: Thin export host for serving or exporting AppSurface Docs. Treat it as a proof host and example app, not a package you install into another project. Release: publication held; proof host; not applicable; notes. Start here: Standalone host README

Not in the direct-install matrix

• ForgeTrust.AppSurface.Auth.Aspire.Keycloak.RealmReadyWorker: Private Keycloak readiness worker payload; consume it only through ForgeTrust.AppSurface.Auth.Aspire.Keycloak. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Flow.Generators: Private source generator and diagnostics used by ForgeTrust.AppSurface.Flow; consume it only through the packed Flow package. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Durable.PostgreSql.TestHost: Internal executable test helper; it is not a hosted runtime, production worker, or package adoption surface. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Durable.PostgreSql.V2WorkHarness: Internal mixed-version compatibility harness; it is not a package, hosted runtime, or adoption surface. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.Tasks: Private compiled MSBuild task used by ForgeTrust.AppSurface.Web.Tailwind; consume it only through the packed Tailwind package. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Web.Tailwind.CacheTestHost: Non-packable child-process fixture that proves Tailwind cache locking, atomic publication, and recovery after owner death. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.AppSurface.Docs.ConsumerFixture: Non-packable ASP.NET Core consumer fixture used by AppSurface Docs HTTP and Playwright regression tests. Release: publication held; excluded; not applicable; notes.
• ForgeTrust.RazorWire.Cli: Held out of the direct-install chooser with publish_decision: do_not_publish until issue #171 lands real .NET tool packaging and stable install guidance. Its proof-only tool package bundles its coordinated dependency graph for artifact verification, but that proof is not authorization to publish it; see the CLI boundary. Release: publication held; excluded; not applicable; notes.

Maintainer notes

• Edit packages/package-index.yml when the public package story changes.
• Follow the PackageIndex release-guidance maintainer guide when changing generated package README release policy, variants, or markers.
• Review package readiness evidence when deciding whether the package manifest, release metadata, blockers, and dependency evidence are ready for release review.
• Package readiness evidence is package-index review evidence. Per-version release consistency lives in releases/v{version}.evidence.json and is validated by the release cockpit.
• Follow the coordinated release-links guide: use release_track: coordinated for the frozen tree-local current pointer, or release_track: explicit with release_notes_path for a package-specific historical story.
• Keep publish_decision and expected_dependency_package_ids in packages/package-index.yml aligned with the package artifact workflow so the chooser and release contract share one package source of truth.
• Keep tool_command_name aligned with each published .NET tool project's ToolCommandName so package validation, pre-publish coverage proof, and post-publish smoke tests run the command users will type. Tool smoke tests install the package, run --help, then require --version to match the package SemVer exactly, including stable or prerelease labels and excluding any leading v or build metadata. The command name value must be one file-name-safe command token, not a path: no whitespace, path separators, reserved ./.. segments, trailing periods, Windows reserved device names or dotted aliases, control characters, or Windows-invalid file-name characters.
• Run dotnet run --project tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj -- generate after changing package classifications, package READMEs, product families, release-guidance variants, readiness blockers, or readiness notes; it reports changed and managed README-region counts.
• Run dotnet run --project tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj -- verify before review to confirm package-index outputs and managed README guidance are current without writing files.
• Run dotnet run --project tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj -- verify-packages --package-version 0.0.0-ci.local before publishing changes that affect package metadata, project references, Tailwind runtime payloads, the packaged release-note or coverage CLI, or the Docs parser and sanitizer graph. This pre-publish workflow installs the packed ForgeTrust.AppSurface.Cli tool from local artifacts, previews and writes a consumer release compose note, runs the packaged coverage semantic proof plus coverage merge, a passing coverage gate, and an intentionally failing coverage gate, then writes the private coverage-cli-consumer-proof.md and public-safe coverage-cli-consumer-proof.evidence.json. It also restores the freshly packed ForgeTrust.AppSurface.Docs artifact in an independent locked consumer and writes docs-package-consumer-proof.md; either failed proof blocks the publish manifest.
• Run dotnet run --project tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj -- gate before publishing rebrand or release metadata changes.
• Keep packages/README.md.yml hand-authored so AppSurface Docs metadata, trust-bar copy, and section placement stay intentional.

Issue #674 packaged coverage proof

Keep the local and packaged coverage questions separate. For repository readiness, use coverage run --dry-run → coverage run → coverage gate: this proves selected VSTest projects produce normal AppSurface artifacts and satisfy the repository thresholds. For a packed CLI candidate, use PackageIndex verify-packages: its default collector proof selects exactly one manifest-bound Smoke.Tests report, validates owned Smoke.Calculator class, line, and branch facts in raw Cobertura, copies and hashes that shard, merges it, and independently validates retention in merged Cobertura. This is an owned fixture proof, not certification of arbitrary consumer application graphs.

The assurance boundary is explicit: --coverage-driver msbuild is VSTest artifact compatibility only; coverage merge is external-shard fan-in only; and --no-clean is an intentional retention escape hatch whose preserved reports or patch-target files may be stale. Native Microsoft Testing Platform (MTP) is a separate runner/integration boundary. Do not switch drivers to satisfy the proof when MTP is selected or runner/package facts conflict; classify the boundary and use a separate MTP path or issue.

The CLI emits schema-versioned coverage-project.json beside each per-project report with schemaVersion, normalized solution-relative projectPath, and CLI-owned slug. PackageIndex accepts only regular manifests up to 16 KiB and the bounded Coverlet/ReportGenerator Cobertura subset required by the fixture (coverage, sources, source, packages, package, classes, class, methods, method, lines, line, conditions, and condition), with DTD/entity rejection, a 1 MiB document limit, depth 32, and 10,000 elements. The proof requires one Smoke package, one Smoke.Calculator class, a normalized Smoke/Calculator.cs filename, positive line hits, and the Sign line-7 two-branch invariant in both raw and merged reports.

Publish coverage-cli-consumer-proof.evidence.json beside the existing private Markdown report. Evidence schema 1 is public-safe and allowlists the verdict, package identity and optional digest, configured driver boundary, raw and merged outcomes with optional artifact-relative paths and invariant IDs, the optional raw SHA-256, plus bounded failures with code, scope, cause, next action, and evidence-relative path. Every unavailable optional field is omitted rather than emitted as null. The raw and merged outcomes, not the configured driver boundary, state whether a semantic stage actually ran. It excludes command arguments and full invocation traces, working directories, NuGet sources/configuration, absolute paths, raw XML, credentials, and arbitrary output. Readers reject unknown required structure and unsupported major versions.

When upgrading Coverlet, ReportGenerator, or the runner, capture one isolated generated-fixture raw/merged pair, confirm the bounded subset and semantic invariants, run the focused PackageIndex fixture suite and verify-packages, then update the versioned schema/subset documentation and consumers together. An unsupported shape is a tool-compatibility result; a valid shape with missing or zero expected semantics is a coverage defect. See the CLI coverage proof-level and manifest contract.

Issue #682 package proof

Use this sequence for the coordinated #682 parser and sanitizer graph. Run it sequentially: later inspection and install steps consume artifacts produced by earlier steps.

First prove the required asset tools are callable, then create work and artifact directories outside the checkout:

set -euo pipefail

node --version
pnpm --version

APPSURFACE_REPO_ROOT="$(git rev-parse --show-toplevel)"
APPSURFACE_682_WORK="$(mktemp -d "/tmp/appsurface-682-work.XXXXXX")"
APPSURFACE_682_ARTIFACTS="$(mktemp -d "/tmp/appsurface-682-artifacts.XXXXXX")"
APPSURFACE_682_VERSION="0.2.0-preview.682"

Keep both temporary roots external. The repository build intentionally reads its centrally managed versions through --repo-root, but temporary consumer projects, tool manifests, and installs must not inherit the checkout's Directory.Packages.props; otherwise the proof can fail with unrelated central-package-management errors or accidentally reuse source policy instead of the packed contract. Preserve both paths when a step fails so the report and packages remain inspectable.

Run the authoritative package workflow first:

dotnet run --project "$APPSURFACE_REPO_ROOT/tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj" -- \
  verify-packages \
  --repo-root "$APPSURFACE_REPO_ROOT" \
  --package-version "$APPSURFACE_682_VERSION" \
  --artifacts-output "$APPSURFACE_682_ARTIFACTS" \
  --artifact-manifest "$APPSURFACE_682_ARTIFACTS/package-artifact-manifest.json" \
  --report "$APPSURFACE_682_ARTIFACTS/package-validation-report.md" \
  --coverage-proof-work-dir "$APPSURFACE_682_WORK/coverage-cli-consumer-proof" \
  --coverage-proof-report "$APPSURFACE_682_ARTIFACTS/coverage-cli-consumer-proof.md" \
  --docs-proof-work-dir "$APPSURFACE_682_WORK/docs-package-consumer-proof" \
  --docs-proof-report "$APPSURFACE_682_ARTIFACTS/docs-package-consumer-proof.md"
unzip -p "$APPSURFACE_682_ARTIFACTS/ForgeTrust.AppSurface.Docs.$APPSURFACE_682_VERSION.nupkg" '*.nuspec'

The preview run proves the locked consumer restore and its exact resolved graph, but it deliberately does not evaluate the stable-only ASPKG139 dependency-container contract.

Before preparing the stable tag, repeat the proof with an unpublished stable candidate version so ASPKG139 is exercised:

APPSURFACE_682_STABLE_WORK="$(mktemp -d "/tmp/appsurface-682-stable-work.XXXXXX")"
APPSURFACE_682_STABLE_ARTIFACTS="$(mktemp -d "/tmp/appsurface-682-stable-artifacts.XXXXXX")"
APPSURFACE_682_STABLE_VERSION="0.2.0"
dotnet run --project "$APPSURFACE_REPO_ROOT/tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj" -- \
  verify-packages \
  --repo-root "$APPSURFACE_REPO_ROOT" \
  --package-version "$APPSURFACE_682_STABLE_VERSION" \
  --artifacts-output "$APPSURFACE_682_STABLE_ARTIFACTS" \
  --artifact-manifest "$APPSURFACE_682_STABLE_ARTIFACTS/package-artifact-manifest.json" \
  --report "$APPSURFACE_682_STABLE_ARTIFACTS/package-validation-report.md" \
  --coverage-proof-work-dir "$APPSURFACE_682_STABLE_WORK/coverage-cli-consumer-proof" \
  --coverage-proof-report "$APPSURFACE_682_STABLE_ARTIFACTS/coverage-cli-consumer-proof.md" \
  --docs-proof-work-dir "$APPSURFACE_682_STABLE_WORK/docs-package-consumer-proof" \
  --docs-proof-report "$APPSURFACE_682_STABLE_ARTIFACTS/docs-package-consumer-proof.md"
unzip -p "$APPSURFACE_682_STABLE_ARTIFACTS/ForgeTrust.AppSurface.Docs.$APPSURFACE_682_STABLE_VERSION.nupkg" '*.nuspec'

Inspect both Docs .nuspec files next. Every Docs dependency container must contain exact equality entries for AngleSharp [1.7.1], HtmlSanitizer [9.2.995], AngleSharp.Css [1.0.1]. The preview artifact confirms the locked consumer restore; the stable candidate also evaluates ASPKG139, which rejects a missing entry, duplicate, range, or different resolved graph. Both verify-packages runs independently restore the selected packed Docs artifact into a fresh locked consumer and record its project.assets.json, lock file, mapped NuGet.config, and exact resolved graph in docs-package-consumer-proof.md. Neither local proof publishes a package. Do not use VersionOverride or a widened range to make an incompatible graph restore.

Finally prove the excluded RazorWire tool explicitly; verify-packages does not select do_not_publish entries:

mkdir -p "$APPSURFACE_682_ARTIFACTS/razorwire" "$APPSURFACE_682_WORK/razorwire-tool" "$APPSURFACE_682_WORK/razorwire-export"
dotnet pack "$APPSURFACE_REPO_ROOT/Web/ForgeTrust.RazorWire.Cli/ForgeTrust.RazorWire.Cli.csproj" \
  --configuration Release --no-restore \
  --output "$APPSURFACE_682_ARTIFACTS/razorwire" \
  /p:EnableRazorWireCliToolPackaging=true \
  /p:PackageVersion="$APPSURFACE_682_VERSION"
unzip -p "$APPSURFACE_682_ARTIFACTS/razorwire/ForgeTrust.RazorWire.Cli.$APPSURFACE_682_VERSION.nupkg" '*.nuspec'
dotnet tool install ForgeTrust.RazorWire.Cli \
  --tool-path "$APPSURFACE_682_WORK/razorwire-tool" \
  --source "$APPSURFACE_682_ARTIFACTS/razorwire" \
  --version "$APPSURFACE_682_VERSION"
"$APPSURFACE_682_WORK/razorwire-tool/razorwire" --help
"$APPSURFACE_682_WORK/razorwire-tool/razorwire" export --help
"$APPSURFACE_682_WORK/razorwire-tool/razorwire" export \
  --project "$APPSURFACE_REPO_ROOT/examples/razorwire-mvc/RazorWireWebExample.csproj" \
  --mode hybrid \
  --output "$APPSURFACE_682_WORK/razorwire-export"
test -f "$APPSURFACE_682_WORK/razorwire-export/index.html"

The tool package must have one DotnetTool package type, command razorwire, and no NuGet dependency group or <dependency> entries: its proof-only package bundles the closure under tools/**. Installation, both help surfaces, and the sample hybrid export must succeed. These checks do not change its excluded classification or publish_decision: do_not_publish, and the artifact must not be pushed.

Redistributed payloads

Use packages/third-party-payloads.yml when a package carries copied third-party payloads, native runtime binaries, minified browser runtimes, bundled tool payloads, or generated-first-party assets that need provenance evidence. Do not add normal NuGet dependencies to this inventory unless their files are copied into the package payload.

When adding a redistributed payload:

1. Add or update the package-local THIRD-PARTY-NOTICES.md file and pack it at package root with <None Include="$(MSBuildProjectDirectory)\THIRD-PARTY-NOTICES.md" Pack="true" PackagePath="" />. The notice must ship the applicable license/NOTICE text itself, or it must name upstream LICENSE/NOTICE files that are packed beside the redistributed payload; component metadata and marker strings alone are not sufficient redistributed-payload evidence.
2. Add a notices record in packages/third-party-payloads.yml with package_id, component, version, license, source_url, payload_patterns, notice_paths, and markers.
3. Add version_source_path and version_source_contains when the repo has a deterministic source of truth such as Directory.Packages.props, Web/package.json, or Tailwind.Common.props.
4. Use an audits record only for narrow generated-first-party evidence or provenance-backed dependency closures that are not notice records. Include applies_to, matched_rule, evidence_kind, source_paths, reviewed_on, source, and revalidate_when; add generated_paths whenever evidence_kind is generated_first_party so the waiver self-invalidates when source or generated outputs move. Audit applies_to patterns must not overlap notice-covered payload entries; the gate fails broad audits that could mask notice-required payloads.
5. Run dotnet run --project tools/ForgeTrust.AppSurface.PackageIndex/ForgeTrust.AppSurface.PackageIndex.csproj -- verify-packages --package-version 0.0.0-ci.local and fix any ASPKG### diagnostics. Payload diagnostics use Problem/Cause/Fix/Docs wording and link back to this section, and the package report shows covered/total suspicious payload counts beside the detailed payload evidence rows.

Examples already covered by the inventory: ForgeTrust.AppSurface.Cli bundles ReportGenerator under tools/**/reportgenerator/** and audits its SDK-produced .NET tool dependency closure; Tailwind runtime packages carry native Tailwind binaries under runtimes/*/native/**; ForgeTrust.AppSurface.Web.Tailwind notices its build-task CliWrap payload; ForgeTrust.AppSurface.Docs embeds the generated MiniSearch runtime and carries THIRD-PARTY-NOTICES.md; ForgeTrust.RazorWire notices its copied Turbo runtime and separately uses generated_first_party audit evidence for browser assets generated from first-party TypeScript.