Tools

Tooling

UAIX tools support validation, inspection, field-order governance, transport and trust review, fixture testing, machine-readable discovery, and implementation onboarding for UAI-1.

What tools should help with

• Resolve the current public record without scraping page text.
• Inspect schema targets, profile IDs, field order, fixtures, transport bindings, trust channels, error codes, and conformance expectations before release.
• Surface structural drift, async workflow mistakes, trace-context problems, and trust-policy gaps before downstream users depend on them.
• Export conformance outcomes as reviewable records that can travel into release notes, CI logs, or audit evidence.

Primary tooling path

Most readers should start with the Validator, then move back to Examples or forward into Implementations depending on whether the next need is debugging or release evidence.

Experimental dogfood surface

UAIX Agents Protocol records how UAIX tests the WordPress prototype for Project Handoff packages, .uai/readme.human, active file-intake buckets, ignored archive scaffolding, ZIP preflight checks, validation-failure refusal, cleanup, and activation smoke evidence. Treat it as an experimental/internal prototype page, not as public generator, validator, SDK, CLI, certification, or endorsement support.

Hello-world conformance path

1. Choose one published Example or prepare one candidate message tied to a known public profile.
2. Resolve the matching schema, registry, field-order, transport, trust, and error records before running the check so another reviewer can reproduce the same packet.
3. Run the Validator and export the result as a reviewable record.
4. Carry that result into Implementations, the Changelog, News, and References and Contributors when the check supports a public release or support claim.
5. Repeat the run whenever schemas, registry mappings, field order, transport guidance, error codes, validator behavior, or runtime mappings change.

Published starter path

Use the public proof run and client calls below when the next task is onboarding a tool, script, or QA flow to the live public surface without private helpers.

[uaix_first_message_guide context=”validator”][uaix_client_examples]

Discovery and sitemap surfaces

Automation and public QA should be able to resolve the same page inventory from both the root discovery surface and the locale-prefixed route space.

• Use /.well-known/uaix.json as the preferred machine-readable manifest.
• Use /sitemap.xml and /sitemap.html as the durable root crawl and directory surfaces.
• Use /en-us/sitemap.xml and /en-us/sitemap.html when localized readers or tooling need the same inventory through the English route space.
• Treat the root sitemap files as the canonical public SEO surface even when locale-prefixed sitemap routes are also live and tested.

Current machine-facing routes

The public tooling surface includes a human-facing validator page plus machine-facing REST routes for automation and release checks.

• /wp-json/uaix/v1/catalog and /wp-json/uaix/v1/discovery expose the current standards catalog and discovery manifest.
• /wp-json/uaix/v1/status and /wp-json/uaix/v1/modules expose runtime status and module inventory.
• /wp-json/uaix/v1/schemas, /wp-json/uaix/v1/registry, /wp-json/uaix/v1/field-registry, and /wp-json/uaix/v1/examples expose the published machine-readable record families.
• /wp-json/uaix/v1/transport-bindings, /wp-json/uaix/v1/trust-channels, /wp-json/uaix/v1/conformance-levels, and /wp-json/uaix/v1/error-registry expose the operating guidance that makes transport, trust, support claims, and failure handling explicit.
• /wp-json/uaix/v1/validate is the JSON POST validation endpoint for automation; use the Validator page when a human needs the workbench experience.
• /wp-json/uaix/v1/roadmap exposes the forward-plan boundary for current, next, planned, and research-track work.

API reference and reusable pack surfaces

• AI Memory Package Wizard guides a supported starter bundle into a package model, populated system profile, copy-paste file deck, receiver brief, startup packet, manifest overlay, optional LLM Wiki memory-plan file, readiness metadata, and canonical ZIP download without claiming general hosted generation, automatic repository writes, or automatic wiki sync.
• API Reference turns the live REST surface into a route-by-route handbook with a published OpenAPI 3.1 document and starter request examples.
• Adoption Kit publishes the first-proof onboarding bundle with starter files, validator-ready payloads, and mock-exchange examples.
• Conformance Pack assembles the broader schemas, registry data, fixtures, transport and trust guidance, and validator entry points into one reusable machine-readable packet.
• /wp-json/uaix/v1/adoption-kit is the machine-facing onboarding bundle for the shortest reusable first-proof run; append ?download=1 when you want the same response as an attachment.
• /wp-json/uaix/v1/openapi.json is the machine-facing OpenAPI export for the live UAIX REST surface.
• /wp-json/uaix/v1/conformance-pack is the machine-facing JSON packet for launch review and repeatable conformance work; append ?download=1 when you want the same response as an attachment.
• /wp-json/uaix/v1/roadmap is the machine-facing forward-plan record for current, next, planned, and research-track work; append ?download=1 when you want the same response as an attachment.

Published operating-surface references

The records below are part of the live machine-readable protocol surface and should be carried with schema and example resolution when you are evaluating interoperability or support claims.

[uaix_protocol_reference]

Discovery surface

Automation should start with the current UAIX discovery manifest and standards catalog.

[uaix_protocol_discovery]

Next step

Start with the Validator, then carry the resulting evidence into Implementations, the Changelog, and News when the result affects a public release.