# Agent integration verification

Requirement: `REQ-PRODUCT-AGENT-INTEGRATION`.

The package test packs the built package, installs that tarball offline in a temporary project, resolves its exported skill path and compares the installed skill against the maintained source. It extracts the skill's commands and runs project discovery, unattended guided setup with explicit answers, configuration checking and a preview build. An ordinary production check still rejects the draft. YAML parsing checks skill frontmatter and display metadata.

The integration-reference tests typecheck every advertised config path through the actual `SiteConfig` declaration and prove an invented field is rejected. They check requested/prerequisite separation, valid target/question IDs, unknown-answer defaults, detached snapshots and preservation of imported consent settings. The CLI test runs beside deliberately invalid private config and project code, verifies installed package version and no input reads/writes, and rejects unknown targets/options without echoing supplied markers.

Explicit scope selection tests cover document-only, agreement, cookie-control, media, translated-copy and discovery requests, with a backend selected independently. Unknown or declined answers select no work; translation selects no regional policy. Supporting work remains distinct when its own scope answer is declined. The selector rejects unknown IDs, malformed inputs and accessors without executing getters. The CLI reads only its explicitly named bounded JSON input, rejects oversized/non-file inputs, preserves existing project files and avoids reflecting private input in errors. Recorded scope never becomes a production-readiness declaration.

Read-only assessment tests reconcile a selected target with actual configuration and explicit practice answers. They exercise missing and empty control scopes, mandatory technology scope declarations, partial array coverage, task-specific answer templates, supported-but-unverified answers, conflicting public facts and shared wizard conflicts. Valid reviewed config still requires host verification; draft content remains separate. Saved report answers are regenerated through the shared engine. API tests reject accessors, custom serialization, cycles, sparse arrays and oversized data without calling user code. CLI tests reject symlinks, directories and malformed options, preserve all files and exclude the config body and private notes from the report. A report-producing exit code is not a readiness assertion.

The package build generates the authoring shape from the actual `SiteConfig` type through the pinned build-only TypeScript API. The JSON Schema uses [draft 2020-12](https://json-schema.org/draft/2020-12/json-schema-core) and local definitions; Ajv validates the full and selected schemas. Tests reject misspellings, missing required fields, wrong literal choices and mismatched storage-exception variants; mapped localization/Google keys remain complete. Every integration target path resolves, including array item fields. Selected output retains only referenced definitions and reports optional ancestors, conditionally available fields and alternative parents whose sibling relationships need inspection. A structurally valid unknown purpose reference deliberately passes shape validation and fails `validateSiteConfig`, proving these checks have different responsibilities. Offline package installation resolves the schema export and runs both CLI modes without TypeScript in the consumer runtime. Malformed paths/options expose no supplied marker and explicit project files remain untouched.

Assessment also runs a standalone validator compiled from that same generated schema at package build time. Ajv and TypeScript remain build-only dependencies. Tests distinguish a typo ignored by runtime projection from a structurally valid but semantically invalid purpose reference. Exact JSON Pointer paths include proper escaping; rejected values are omitted and diagnostics are bounded. Offline installed CLI execution exercises the generated validator without either build tool in the consumer.

Target scenarios cover missing form scope assessment and its four relevant questions, conditional terms/form dictionaries for valid non-English configurations, and an independent storage-exception request which never demands consent enrollment. These are minimum authoring requirements. Tests do not establish factual eligibility or replace `formPermissionGrantSupported` and real host behavior checks.

The website test follows every curated `llms.txt` target and local link in generated Markdown guides, checks their HTML alternate links, and verifies the public skill matches the same source. A mixed Markdown fixture covers nested image links, reference definitions, escaped labels, titles and unchanged inline/fenced code. Public asset requests require no operator/demo namespace, set no session cookie and reject writes. Only the explicitly selected skill files are included in the generated asset manifest.

These checks exercise documentation delivery and a real local CLI workflow. They do not evaluate an agent's reasoning, establish legal suitability, publish to npm, install a personal skill, provision resources or prove browser-crawler adoption. Existing controller, authoring, history and backend tests remain responsible for those implementations. Adopters decide their own CI and review workflow.

```sh
npm run build
node --test packages/notabenda/test/agent-integration.test.mjs packages/notabenda/test/integration-reference.test.mjs packages/notabenda/test/integration-assessment.test.mjs packages/notabenda/test/config-schema.test.mjs
node site/build.mjs
node --test site/test/agent-docs.test.mjs
python3 scripts/regulatory.py --check
```