SEO Answer Visibility

Shared work cycle

After the guard returns run, read WORK-CYCLE.md and your entry in work-profile.json. Apply the contract's work-cycle extension to work selection, scoped blockers, progress evidence and claim recovery. Before closing, write the progress receipt, then the normal run record, then finish the claim with its token. Preserve the remaining budget on a resume. A same-period run with a claim overrides only the legacy Step 0.2 exit/reset. All pause, release and browser guards still apply.

Answer visibility

Run node scripts/guard.mjs seo-answer-visibility --json first. A non-run verdict has already been recorded; exit without reading the rest of the kit. For a run verdict read CONTRACT.md, ROLE.md, CAPABILITIES.md, AEO-PLAYBOOK.md and your SCHEDULE.md row in full. This routine inherits every contract guard, status, state schema, mutex rule and output writer boundary. Never infer a time, budget or cadence from this document.

0. Begin a recoverable run

Read your row and compute its period key using the contract rules and local clock. Read state/seo-answer-visibility.json. Apply the contract's once-per-period check and atomic state update, recording last_period, started, the run id and progress before external work. A real guard run returns an atomic claim. Preserve its token and apply WORK-CYCLE.md recovery rules; an inspection with --no-record reserves nothing. Use the established mutex/stale-lock rules before browser work, and release only the lock you own on every exit. Do not modify another routine's state, schedule or active lock.

Resolve capabilities live. Prefer a confirmed connected read route, then an approved browser session, then a dated member-supplied observation. CAPABILITIES.md is the only vendor-to-capability map. No connector purchase, install, account creation, authentication or credential entry. An unavailable route is an explicit gap, not zero visibility. Read-only observation includes submitting the approved public buyer question to an existing authorized search/chat surface; never include private client notes, secrets or unpublished strategy in that question. Do not use a route whose use requires accepting terms or an unapproved paid action.

Read strategy/properties.md, strategy/answer-map.md, strategy/topic-map.md, the published ledger, the previous answer report, current observations and board/board.json. If properties are missing, record failed with intake as the blocker. If the answer map is missing, file one deduplicated research card for intake; continue an owned-page eligibility review, but never invent the client's target audience or question set.

1. Check eligibility and factual consistency

Pick the highest-priority owned target pages from the answer map within the remaining budget. Read their HTTP status, canonical, visible answer text, internal entry links and available robots/directive evidence. Record the exact URL, date, method and finding. Compare organization and service facts to the approved evidence in the map. A missing capability is unknown, not a failed SEO check. Stage one specific correction per observed problem; never alter robots, CDN, schema, a public profile or a live page from this routine.

2. Sample actual answers

Work the fixed question set in stable id order, resuming coverage without exceeding the row budget. Follow the AEO-PLAYBOOK observation contract exactly. Distinguish each consumer surface from any API route. Capture the answer and its cited links, not just a search snippet about an answer. If a mode does not use retrieval, label it and keep it out of grounded-search comparisons.

Write each observation as a validated UTF-8 JSONL line once, with a stable id of run id + question id + surface. On retries, check that id before appending. Save only the evidence needed to verify the claim, strip secrets and unrelated account information, and reference its local path. Never overwrite earlier observations. Login walls stop work on that surface immediately; record blocked-login using the contract and continue file work if possible. No captcha retries, session sharing or attempts to evade platform limits.