Skip to content
docs Explore the platform

ANTSAND · GUIDE

Validate and diagnose

> Production API availability: use /api/v1/help?view=guides and the resource operations catalog before following a recipe. Some localhost capabilities are not deployed yet; an absent operation is unavailable.

Validate at several boundaries

A successful API response proves that one operation completed. It does not prove that a page renders, that a form reaches the correct action, or that a private download is protected.

  1. Read the board and agent context to verify the owner, environment and supported operations.
  2. Inspect page-flow to connect the URL, HMVC action, section, template and source.
  3. Run the server patch dry-run and inspect its design review.
  4. Apply the reviewed patch and inspect the saved source.
  5. Generate the intended target and run verify-deployment.
  6. Open the rendered page and exercise its actual user flow.

Read-only inspection calls

Set API_URL to the API prefix, such as http://localhost/api/v1. Use the service origin configured by your operator.

Examplebash
curl --fail-with-body "$API_URL/databoards/$BOARD_ID" \
  -H "Authorization: Bearer $API_KEY"
curl --fail-with-body "$API_URL/databoards/$BOARD_ID/agent-context" \
  -H "Authorization: Bearer $API_KEY"
curl --fail-with-body "$API_URL/databoards/$BOARD_ID/page-flow" \
  -H "Authorization: Bearer $API_KEY"
curl --fail-with-body "$API_URL/databoards/$BOARD_ID/docs-publication" \
  -H "Authorization: Bearer $API_KEY"

The last endpoint is specific to a board with Docs collection bindings. It returns the owner-filtered public projection, not all private authoring content.

Server dry-run

This validates the patch in memory without saving it. It does not reserve a revision or prevent concurrent board edits.

Examplebash
curl --fail-with-body -X POST \
  "$API_URL/databoards/$BOARD_ID/patch/dry-run" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" --data-binary @change.patch.json

Diagnose the failing boundary

If a heading does not change, inspect its mapped source before editing CSS. If an action returns 404, inspect the route, module type, controller location, action name and ACL. If the mapper is empty, check saved collection bindings and ownership. If JSON parsing fails, inspect the response status and content type; an HTML login page is not JSON.

If generation succeeds but a link fails, test the destination directly as the intended user. For protected pages, also test as a guest and a different account.

Checks unavailable through HTTP

Internal regression tests are maintainer tools, not agent-callable operations. If the API lacks a required diagnostic, report that limitation rather than claiming the check passed. Record observable HTTP responses and rendered-page behavior separately.

Record evidence

Keep the patch, preflight result, target identifiers, deployment response and browser result. Report skipped checks explicitly. Never use a screenshot of a mocked page as evidence of an authenticated production flow.