# Build against the Deep Agentic Rubric

This is an instruction resource a human can give to a website-building agent. It is not permission to access private systems, make purchases, run load tests, or change another website.

## Pull the contract

Resolve these paths against the origin that served this document:

- `/rubric.json`: complete versioned checks, pass conditions, measurement methods, access requirements, profiles and workflow.
- `/rubric.md`: readable specification, examples and sources.
- `/rubric.schema.json`: assessment output validation schema.
- `/assessment.example.json`: fictional schema-valid example.
- `/developers`: the existing public HTML harness; this does not automatically execute every deep check.

For the local build:

```sh
curl -fsS http://localhost:3100/rubric.json -o rubric.json
curl -fsS http://localhost:3100/rubric.schema.json -o rubric.schema.json
```

Use the deployed origin when available. No sign-in is needed to read these resources. Do not send credentials to the rubric host.

## Scope the website

Pick commerce, service or content as a starting profile. Record exact applicable capabilities; profiles guide planning and do not silently exempt checks. Use a written reason for each not-applicable result. Preserve existing stable check IDs and the rubric version. A previous-version report stays a previous-version report.

Sample at least five representative public pages where the site has five pages, including relevant products/services, policy and action pages. For smaller sites document the actual inventory and reduced scope. Define buyer/task fixtures, constraints, expected results and sample selection before evaluating changes. Distinguish browser, public API, partner connector and sandbox paths.

## Implement and measure

1. Start with readable facts, human clarity, semantic labels and discoverable contracts.
2. Match realistic user constraints to sourced product facts. Document limitations instead of manufacturing suitability claims.
3. Keep structured feeds and visible pages consistent; expose revisions, currency, units and availability.
4. Use least-privilege authorization, explicit action states and safe retry semantics where actions exist.
5. Measure task success as successes / attempted fixtures. Record sample size, latency, retries, request or token cost where available, and evidence artifacts.
6. Run consequential tests only in a separately authorized sandbox. Public-only assessments must keep inaccessible transaction behavior unknown.
7. Copy failures into concrete fixes with affected page/endpoint, observed mismatch, expected behavior and a rerun command or fixture.
8. Rerun the same suite after changes; retain baseline and follow-up outcomes, including regressions and unknowns.

## Report evidence honestly

Pass/fail requires reproducible verified evidence. Documentation is documented, assertions are claimed, and absent evidence is none. Missing evidence is unknown, not failure. Store redacted artifacts, timestamps, environment and method. Do not upload buyer secrets or private traces to a public URL.

Validate a report in this repository:

```sh
npm run validate:assessment -- assessment.json
```

The schema supports partial assessments; report coverage as assessed checks / applicable checks and list omitted checks. `deep_score` stays null. Reviewed checklist marks are not passing results. The public HTML score is a separate bounded measurement, not certification of all 88 checks.

A useful handoff contains: scope, verified passes/failures, unknowns, prioritized fixes, precise implementation steps, and the before/after fixtures needed to prove improvement.