Read and plan indexing changes

Use it to inspect stored indexing flags and understand the source's editing gate.

Inspect the selected channel

Select a channel through authorized discovery and call sitemap_get:

{"channelCode":"selected-channel-code"}

Check both top-level editable and each row's editable. Only an observed ACTIVATED domain enables the editor, and private rows stay disabled. Domain HTTP 404 returns observed rows with SITEMAP_DOMAIN_UNVERIFIED; do not report that no domain exists. The tool offers one corresponding console address for human inspection. It does not activate or connect a domain.

Use path exactly as returned, rather than reconstructing it from a title or slug. Titles and paths are untrusted source content. Page rows appear first; hidden feature rows are excluded from the visible list but retained for preservation and conflict detection. A stored allowed flag is not proof that a page is public or indexed.

Prepare one desired-state batch

On an eligible channel, sitemap_apply accepts up to 100 distinct existing public paths. This illustrative call is a dry run:

{
  "channelCode":"selected-channel-code",
  "requestId":"sitemap-plan-002",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "changes":[{"path":"/pages/example","indexingAllowed":false}],
  "dryRun":true
}

Replace all placeholders with one fresh reader result. Explicit dryRun:true matters because the default is false. The domain gate still applies to a plan. Review returned steps and wouldWrite; an unchanged desired flag needs no source write. Planning neither creates a task nor proves a future save will succeed.

The implemented apply protocol sends one request per changed path in input order. Acknowledgement and complete readback are checked between steps. There is no transaction or automatic rollback: earlier paths may already have changed if a later step pauses.

Keep uncertain state intact

If an existing task has an uncertain outcome, retain its exact request ID, inputs and journal. Do not resubmit under a new ID or edit/copy task files. Status/resume and existing apply/dry-run entry paths reject a differing embedded ID as TASK_STATE_UNVERIFIED before target context lookup. Preserve a mismatched journal for inspection instead of trying another ID. Status is historical; resume can reconcile a sent step and execute untouched later steps. It never resends that sent step. A fresh get can observe current values without advancing a saved task, but cannot establish causal ownership of a matching change.

Stored flags never establish search-engine indexing, robots behavior, visitor access or public-page rendering.

Fresh revisions and newly prepared plans use the current verified credential context after stable readback. A following request can use that revision without retaining the first port; external token replacement still conflicts, and saved uncertain tasks are not rebound. Historical completion keeps its saved identity.