# Website build: playbooks Generated from the canonical manifest. Do not edit this file. Bare skill paths in the included instructions resolve from the canonical skill directory. For uploads, locate the named source section in these bundles; request an attachment when absent. Project paths resolve only in the authorized website workspace. See [host setup and evidence](../COMPATIBILITY.md). ## Contents - [playbooks/choose-stack.md](../../skills/website-build-skill/playbooks/choose-stack.md) - [playbooks/data-and-templates.md](../../skills/website-build-skill/playbooks/data-and-templates.md) - [playbooks/image-pipeline.md](../../skills/website-build-skill/playbooks/image-pipeline.md) - [playbooks/self-hosted-fonts.md](../../skills/website-build-skill/playbooks/self-hosted-fonts.md) - [playbooks/embed-facades.md](../../skills/website-build-skill/playbooks/embed-facades.md) - [playbooks/security-headers.md](../../skills/website-build-skill/playbooks/security-headers.md) - [playbooks/structured-data-and-llms.md](../../skills/website-build-skill/playbooks/structured-data-and-llms.md) - [playbooks/performance-budgets.md](../../skills/website-build-skill/playbooks/performance-budgets.md) - [playbooks/accessibility.md](../../skills/website-build-skill/playbooks/accessibility.md) - [playbooks/research-and-memory.md](../../skills/website-build-skill/playbooks/research-and-memory.md) - [playbooks/deploy-and-operate.md](../../skills/website-build-skill/playbooks/deploy-and-operate.md) - [references/stacks/static-html.md](../../skills/website-build-skill/references/stacks/static-html.md) - [references/stacks/scripted-static.md](../../skills/website-build-skill/references/stacks/scripted-static.md) - [references/stacks/framework.md](../../skills/website-build-skill/references/stacks/framework.md) ## Source: playbooks/choose-stack.md # Choose the smallest stack Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: what is the least machinery that meets the approved brief? ## Establish requirements Require accepted research, a confirmed brief, and a named mockup selection. List routes, content editor, publishing frequency, repeated structures, state, authentication, secrets, integration needs, localization, and maintenance owner. Separate request-time requirements from operations that can happen during a build. A framework preference is a preference, not proof of a runtime requirement. ## Follow the decision tree ```text Server secrets, authenticated state, or request-time behavior? Compare a small separate endpoint with an application framework. Select a framework only if the remaining application requirements earn it. Otherwise, repeated pages with shared structure or derived metadata? Yes: scripted static builder with validated records and shared templates. No: static HTML, CSS, and only the JavaScript the approved experience uses. Before adding another layer, name the requirement still unmet. ``` - Static HTML: load references/stacks/static-html.md for files, preview, and checks. - Scripted static: load references/stacks/scripted-static.md for data-derived routes. - Framework: load references/stacks/framework.md for server/client and runtime boundaries. ## Compare costs and exits For each candidate, name its dependency, supported version, build/runtime needs, host constraints, upgrade path, editor workflow, and removal path. Evaluate APIs against official documentation opened in this engagement. Payments may use a hosted checkout. MDX may compile to static pages. Neither capability universally requires a particular framework. Do not add a CMS, analytics service, or paid dependency without an approved need. ## Work a small example An invented workshop has a home page, visit page, and quarterly article series. Repeated articles share title, summary, image, and canonical metadata. A scripted static builder can derive articles and discovery files from one record. A private member area would add a server-state requirement that needs a new comparison. Do not silently extend the original stack decision to cover the member area. ## Record and verify Write site-work/stack.md with requirements, rejected alternatives and reasons, selected recipe, dependencies, host, source claim IDs, and exact editing/build commands. Have another author add a representative next item from those instructions. Verify the new route, navigation, canonical, sitemap, and discovery entry together. Apply checklists/build.md B01 and B03 before accepting the decision. ## Failure modes - Familiarity: choosing a framework before reading requirements or selecting a mockup. - Hidden server: static output depends on an undocumented secret-bearing process. - Editorial duplication: each new record needs manual changes in multiple metadata lists. - Unsupported API: copying a remembered version without a current source check. ## Source starting points Open the selected framework and host's official versioned documentation. Inspect real source files at a recorded repository revision and check its license. The three local stack references are recipes to validate, not platform support claims. ## Source: playbooks/data-and-templates.md # Make repeated pages data changes Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: how can another author add the tenth item without copying a page? ## Separate responsibilities - Data: authored content and stable identities, owned independently of layout. - Validation: required fields, types, uniqueness, URLs, dates, and relationships. - Rendering: shared templates and context-specific serialization. - Output: generated pages and discovery artifacts, never edited as source. - Deployment: an allowlist of checked output, with private work files excluded. ## Define the record contract Name an immutable record ID and a unique normalized route slug. Require title, useful body, and publication state inputs needed for that content type. Mark optional provider IDs and assets explicitly optional. Define the accepted identifier grammar from the provider's current official source. Trim before validating. Whitespace-only identifiers are absent, not valid values. Reject malformed required fields with record ID and field name before rendering. Omit missing optional controls and list omissions in the build report. ## Compute state once Define publicationState(record, clock, timezonePolicy) as a pure decision. Use its result for page headings, badges, buttons, indexes, feeds, and discovery output. Use an explicit clock and timezone policy; do not infer dates from the build machine. Test immediately before, at, and after each release boundary. A static page changes state only after rebuilding. Name the rebuild trigger or human owner. ## Keep helpers narrow | Helper | Contract | Adverse input | | --- | --- | --- | | esc | Escape text or quoted attribute metacharacters after string normalization. | Quotes, ampersands, angle brackets. | | jsonLd | Serialize valid JSON and escape literal less-than characters for a script element. | Script-terminator text followed by markup. | | safeUrl | Parse, normalize, and allow only schemes/origins appropriate to the URL role. | A script URL, control characters, or an unexpected origin. | | publicationState | Return one state and its allowed actions using the explicit clock. | A release boundary with an absent provider ID. | Use structural DOM/template APIs when available; do not concatenate untrusted attributes. Escaping is not URL validation, and safe JSON is not HTML sanitization. For rich HTML, use a reviewed sanitizer with a narrow allowlist or render text instead. ## Work a small example ```text record: workshop-introduction slug: workshop-introduction state: published provider_id: empty expected page: visible article, no provider link, no player, omission in build report expected discovery: the article route only if it satisfies the public-content rules ``` Validate the ID before constructing a URL, not after interpolating it into a suffix. Never render an empty href, a fragment stand-in, or an empty provider URL as recovery. A valid optional ID enables its control only when the shared state permits it. ## Derive related outputs Generate route HTML, titles, descriptions, canonical URLs, social metadata, structured data, sitemap, and llms.txt from the same validated records. Sort deterministically. Use content or transformation identities for generated asset names. Exclude drafts and private records consistently from navigation and discovery. Keep Optimizer's authored inputs immutable when Builder integrates a revision. ## Verify the generated artifact Run checklists/build.md B02 through B07 on rendered HTML. Exercise quotes, ampersands, angle brackets, script terminators, rejected schemes, empty and whitespace IDs, duplicate slugs, long copy, missing assets, and boundary dates. Prove hostile text stays text, valid JSON parses, and unsafe actions are absent. Add one representative record and inspect every derived surface. Rebuild unchanged inputs twice and investigate output differences. ## Failure modes and sources - Late validation: malformed data reaches templates before a meaningful error. - Split state: badges and buttons each implement a separate date condition. - Safe-looking source: only the template is checked while generated HTML is broken. - Quiet omission: optional data disappears without an author-visible report. Open the chosen template engine's escaping documentation, the URL API documentation, and https://html.spec.whatwg.org/multipage/scripting.html for script parsing context. Record source-opening evidence before relying on an implementation detail. ## Source: playbooks/image-pipeline.md # Deliver images for their actual slots Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: how do images remain useful and sharp within the route's loading budget? ## Inventory before transforming Record source identity, rights evidence, intrinsic dimensions, image role, focal point, crop intent, background/transparency, decorative status, and alt-text intent. Preserve authorized originals and required notices under Graphics ownership. Strip unnecessary sensitive metadata from public exports without altering the original. Unknown rights block release of that asset. ## Choose transformations Measure layout slots at representative widths and display densities. Generate AVIF and WebP candidates using the selected supported sharp version. Retain a browser-usable original-format fallback for the same composition. Do not ship an unsuitable source format as the fallback solely because it is original. Record a conversion when the master is a design file rather than a web image. Compare compression by inspecting edges, small text, gradients, and the intended crop. Quality and width settings are choices to measure, never universal defaults. ## Define a deterministic pipeline ```text input: original bytes + crop + widths + quality settings + encoder version process: validate -> orient -> crop -> resize -> encode -> inspect output: content-keyed variants + actual dimensions + byte sizes + manifest invalidate: any input bytes, settings, crop, or encoder version changes ``` Use a documented TypeScript build script with sharp as a declared build dependency. Read current API documentation before implementing format options. Reject enlargements that cannot meet the approved visual requirement. Rebuild from source rather than recompressing already compressed derivatives. ## Connect markup to layout Use picture sources for AVIF and WebP with an img fallback. Set srcset widths from actual exports and sizes from the rendered CSS slots. Set width and height from the real file and reserve the matching aspect ratio. Do not claim dimensions from a requested export setting without inspecting the result. Give meaningful images task-relevant alternatives; use empty alternatives for decoration. ## Protect the first screen Identify the likely LCP image from the real route and a measurement trace. Make the important image discoverable in initial HTML and avoid lazy loading it. Lazy load appropriate below-fold images and test behavior with JavaScript unavailable. Avoid preloading every image; verify that a critical preload matches the selected resource. ## Verify and hand off Inspect desktop/mobile crops and representative density combinations in a browser. Record the selected resource, actual dimensions, byte size, request timing, and visual result. Compare the route budget before and after the pipeline change. Measure each social card independently and pass its actual dimensions to Optimizer. Graphics hands an immutable export revision and rights ledger to Builder. Apply checklists/brand-and-mockups.md BM07 and checklists/performance-seo.md PS03. ## Failure modes and sources - Mismatched sizes: the browser fetches a large variant for a narrow slot. - Crop loss: the focal subject disappears on mobile. - False dimensions: one social-card size is copied across unequal files. - Nondeterminism: unchanged originals churn names and invalidate caches. Open https://sharp.pixelplumbing.com/ and the selected browser image guidance. Record the exact API version, actual source access, and inspected export results. ## Source: playbooks/self-hosted-fonts.md # Serve licensed fonts from the site Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: how can the chosen type remain legible without a third-party font request? ## Verify the exact rights Identify font family, version, source file, and license text. Check web embedding, redistribution, and proposed subsetting separately. Preserve required notices with the authorized woff2 files. A screenshot or a public font download is not evidence of those rights. Unknown rights keep the font out of the release; use an approved fallback for drafts. ## Map type roles to files List body, heading, UI, and emphasis roles with used weights and styles. Include only faces the selected design actually needs. Test required language glyphs before subsetting; do not remove content's characters. Confirm the fallback has usable shapes, metrics, and coverage. Do not rely on synthetic weight or style when the approved design needs a real face. ## Define loading behavior ```css @font-face { font-family: 'Project Sans'; src: url('/assets/fonts/project-sans-regular.woff2') format('woff2'); font-weight: 400; font-style: normal; font-display: swap; } body { font-family: 'Project Sans', system-ui, sans-serif; } ``` This is a file naming and loading example, not a supplied or licensed font. Choose display behavior for the content and test the fallback-to-loaded transition. Use metric overrides only after measuring the actual fallback and loaded face. Preload only critical faces with correct type and cross-origin fetch behavior. Confirm the preload and CSS reference resolve to the same resource. ## Verify failure and delivery Block font requests and complete the primary journey using fallbacks. Inspect all font requests and redirects; keep them on approved first-party origins. Use font-src 'self' in the site's tailored CSP and test the enforced response. Record layout shift, line wrapping, missing glyphs, and weight/style selection. Check long copy and translated content when applicable. Apply checklists/performance-seo.md PS03 and checklists/brand-and-mockups.md BM07. ## Failure modes and sources - License mismatch: desktop use is mistaken for web redistribution permission. - Hidden external load: imported CSS contacts a font provider. - Duplicate transfer: a mismatched preload fetches a face twice. - Fragile layout: loaded type hides a broken fallback. Open the font's actual license and current font loading documentation at https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face before implementation. No third-party font binaries ship with this skill. ## Source: playbooks/embed-facades.md # Load providers after deliberate activation Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: how can a visitor choose a player without paying its cost on arrival? ## Validate the control Require a valid provider ID and an allowed destination before rendering a facade. Use the selected provider's current identifier and URL requirements. An absent or whitespace-only ID omits the entire control and records the omission. Do not replace it with a dead iframe, empty suffix, or empty link. ## Render a local first state Show a local authorized poster, a useful description, and a real button. Reserve player space using actual aspect ratio to prevent layout shifts. Give the button an accessible action name, not only a play-shaped icon. Keep a safe outbound link available when loading or embedding fails. Do not fetch provider posters, preconnect, or inject provider SDKs before activation. ## Implement a bounded state transition ```text idle -> deliberate button activation -> loading -> ready loading -> error -> retry or safe outbound fallback ready + repeated activation -> no second iframe invalid identifier -> no facade and no outbound provider control ``` Create the iframe only on intentional keyboard or pointer activation. Set its title, reviewed source, and minimum necessary permissions. Select sandbox behavior from the provider's actual requirements and test it. Keep focus predictable while replacing content and announce loading/error states. Do not remove the focused button without a deliberate focus destination. Provide a no-JavaScript path to the approved outbound destination. ## Verify the network boundary Start a clean browser session without cached provider resources. Inspect requests before activation: no iframe, poster, script, or provider connection. Activate by keyboard and pointer in separate checks. Inspect requests, layout stability, focus, error recovery, and repeated activation. Test with production CSP and network failure, including blocked third-party cookies. Record exact route, candidate, environment, request log, and results. Apply checklists/build.md B04 and checklists/performance-seo.md PS03. ## Failure modes and sources - Cosmetic facade: a hidden iframe already fetched the provider. - Remote poster: the first state still contacts the provider. - Lost focus: swapping markup strands a keyboard user. - Overbroad policy: frame permissions allow unrelated origins or capabilities. Open the chosen provider's official embedding documentation and current browser iframe documentation. Retain the source ledger and network inspection evidence. Click-to-play is a performance/privacy boundary, not proof of consent compliance. ## Source: playbooks/security-headers.md # Tailor headers to the real response Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: which restrictions fit the site's actual host, resources, and endpoints? ## Inventory before configuring List every script, stylesheet, image, font, media source, frame, connection, and form target. Record exact origins, inline blocks, required permissions, and the user task each serves. Remove unused resources before adding allowances. Map normal HTML, redirects, errors, static assets, proxies, and function responses separately. Verify HTTPS readiness and recovery before enabling long-lived HSTS. ## Review the starter assumptions These starters assume HTTPS, self-hosted resources, no inline scripts or styles, no third-party frames or APIs, and no need for another site to frame this site. They are UNVERIFIED configuration proposals, not deployed or scanned examples. Keep existing redirects, rewrites, and unrelated settings while merging the rules. The supplied HSTS preset is max-age=63072000; verify the chosen policy and readiness. Never add includeSubDomains without an HTTPS inventory of every affected subdomain. Never enable preload as incidental cleanup; it needs a separate explicit decision. ## Select the static host format ### Vercel static deployment Merge this proposal into vercel.json, then inspect actual response coverage. ```json { "headers": [{ "source": "/(.*)", "headers": [ {"key": "Content-Security-Policy", "value": "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests"}, {"key": "Strict-Transport-Security", "value": "max-age=63072000"}, {"key": "X-Content-Type-Options", "value": "nosniff"}, {"key": "X-Frame-Options", "value": "DENY"}, {"key": "Referrer-Policy", "value": "strict-origin-when-cross-origin"}, {"key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()"} ] }] } ``` Starting source: https://vercel.com/docs/project-configuration Current syntax, matching, and response coverage require source opening and a host test. ### Cloudflare Pages static output Place this proposal in the deployed static directory as _headers. ```text /* Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests Strict-Transport-Security: max-age=63072000 X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: strict-origin-when-cross-origin Permissions-Policy: camera=(), microphone=(), geolocation=() ``` Starting source: https://developers.cloudflare.com/pages/configuration/headers/ Verify the current documented exclusion of function responses; set and test their headers in the response path rather than assuming this static file covers them. ### Netlify static output Place this proposal in the publish directory as _headers. ```text /* Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests Strict-Transport-Security: max-age=63072000 X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: strict-origin-when-cross-origin Permissions-Policy: camera=(), microphone=(), geolocation=() ``` Starting source: https://docs.netlify.com/manage/routing/headers/ Verify current behavior for proxies, functions, and edge functions separately. Static rules alone cannot be treated as proof of headers on every response class. ## Adapt CSP to actual resources Add reviewed exact frame-src origins for authorized embeds and connect-src origins for APIs. Retain object-src 'none', a reviewed base-uri, form-action, and framing policy. Avoid wildcard script origins and production unsafe-eval. Self-host fonts and use local-poster embed facades to keep the resource graph small. Static inline blocks need hashes of their exact served bytes when a hash policy is chosen. Regenerate hashes when bytes change and test the final artifact, including line endings. A nonce design needs unpredictable per-response values shared by the header and allowed blocks. Do not reuse a fixed nonce in static output or publish cached nonce-bearing HTML blindly. Do not copy a strict static CSP onto a framework and assume hydration still works. Read the selected framework's current CSP guidance and inspect emitted scripts. Safe JSON serialization remains required even when CSP is enforced. ## Verify the policy, then the journey Use an actual GET response and preserve status, redirect chain, relevant headers, and URL. Avoid relying on HEAD alone when the host handles it differently. Check normal HTML, redirect responses and destinations, errors, assets, and functions. Require exactly one intended enforced CSP per response, with no accidental duplicate policy. Report-only CSP helps diagnosis but cannot satisfy the enforced-policy gate. Exercise navigation, forms, fonts, images, authorized players, and payments when applicable. Inspect browser violations with production policy active and retain functional evidence. Run securityheaders.com against the exact authorized public URL and save its dated result. Require A or A+ plus working journeys; a grade alone cannot prove application security. If the scanner cannot run, record UNVERIFIED and leave its required gate blocked. ## Record exceptions and recovery Write site-work/qa/security-headers.md with candidate identity, origin inventory, config revision, response matrix, browser results, scanner receipt, and remaining failures. An exception needs scope, reason, owner, expiry, and evidence; do not silently lower a gate. Keep the prior known-working configuration and an authorized rollback procedure. New resources or endpoints invalidate affected header checks before release. Apply checklists/security.md S01 through S08. ## Failure modes - Duplicate CSP: intersecting policies silently break allowed behavior. - Partial coverage: a static header file leaves function errors unprotected. - Scanner substitution: an A grade hides broken forms or authorization gaps. - Premature HSTS: unready subdomains become inaccessible for returning browsers. - Hash drift: minification changes inline bytes after policy generation. ## Source: playbooks/structured-data-and-llms.md # Keep discovery content truthful Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: can people and machines read the same useful facts from every public route? ## Model identity and route intent Start from owner-approved facts, not schema examples copied from another site. Name a canonical HTTPS URL, stable entity IDs, route purpose, and intended indexing state. Use Person, Organization, or ProfilePage only when the actual visible identity fits. Do not invent affiliations, reviews, prices, availability, or contact information. Connect page and entity records with stable @id references and explicit relationships. ## Keep answers visible Write the direct answer near its question, then support it with useful detail and sources. Make a section understandable outside surrounding navigation without losing its conditions. Do not repeat keywords at the expense of task completion. Use FAQPage only for genuine visible questions and answers where appropriate. Current consumer eligibility requires a same-day source check; valid vocabulary does not prove a consumer offers a rich result or that the site qualifies for it. ## Validate structured data Derive structured data from the same validated record that supplies the visible page. Serialize with the script-safe helper described in data-and-templates.md. Run syntax/vocabulary validation separately from the relevant consumer's eligibility test. Inspect actual generated HTML, not only a JSON source file. Compare each marked-up claim to visible content, owner facts, and the route state. Unknown support stays UNVERIFIED and cannot become a ranking or citation promise. ## Generate discovery files ```text validated route registry -> initial HTML, title, description, canonical, social metadata -> truthful structured data -> sitemap of intended canonical public URLs -> llms.txt navigation map with useful summaries and source links ``` Use one inclusion rule for drafts, private routes, duplicates, redirects, and removed pages. Generate rather than maintain a second manual list of public content. Treat llms.txt as navigation assistance; do not claim that it is required for AI ranking. Differentiate search crawling, model training, and user-triggered retrieval where current consumer documentation makes those distinctions. Preserve the owner's explicit policy. Use IndexNow only when the selected endpoint and current support are verified and submission is already authorized. File generation does not authorize network submission. ## Work a small example An invented studio's workshop page states what is taught, who it suits, and how to inquire. Its schema contains only those approved visible facts. A cancelled workshop changes shared state, visible actions, and discovery output together. No sold-out badge or signup link remains because a second metadata list was forgotten. ## Verify and hand off Optimizer owns route-map.json, metadata.json, structured-data.json, answers.md, llms.txt, and sitemap.xml under site-work/optimization/. Builder integrates an immutable revision and regenerates the release candidate. Optimizer then checks intended-public routes, initial HTML, response status, robots, canonical parity, inbound links, sitemap membership, and actual social-image dimensions. Check origin responses with relevant bot agents separately from third-party cached cards. Verify analytics at the intended receiving property before claiming an event arrived. Record missing indexing or field data as UNVERIFIED with a follow-up owner. Apply checklists/performance-seo.md PS05 through PS10. ## Failure modes and source starting points - Schema theater: a validator result is offered as proof that all facts are true. - Stale metadata: content changes but canonical, card, or description does not. - False AI promise: a crawler request or llms.txt file is presented as a citation. - Silent policy change: robots directives change without the owner's instruction. Open https://schema.org/docs/schemas.html for vocabulary. Open https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data for consumer guidance and https://developers.google.com/search/updates for changes. Open https://developers.google.com/search/docs/appearance/ai-features and https://llmstxt.org/ to distinguish consumer requirements from proposal semantics. These links are research starting points, not receipts of an opening in this engagement. ## Source: playbooks/performance-budgets.md # Measure the experience against explicit budgets Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: is the site fast enough for its visitors' routes, devices, and primary tasks? ## Set route budgets before implementation Select representative routes: the main entry, a repeated content page, and the heaviest journey. Record viewport, device/CPU/network profile, cache state, tool version, and route state. Choose transfer, script, image, and third-party budgets from actual content and audience needs. Name the owner, rationale, method, and exception process for each budget. Do not invent a universal byte allowance or silently enlarge a missed target. ## Separate proposed targets from evidence The method proposes a Lighthouse mobile performance median of at least 90 per route. The field baseline to revalidate is p75 LCP at most 2.5 seconds, INP at most 200 ms, and CLS at most 0.1, assessed separately by device class and reporting window. These numeric baselines are UNVERIFIED for the current engagement until the authoritative source is opened and its source date, access date, release, and applicability are recorded. Do not cite this playbook as proof of current external thresholds. Lab scores diagnose a controlled run. They do not establish real-user p75 or interaction quality. A new site can lack sufficient field observations; record UNVERIFIED, the follow-up owner, when to check again, and the intended data source. Do not invent a field PASS. ## Run a repeatable lab series 1. Build the identified candidate and serve its production output. 2. Fix the environment, route state, and cold-cache conditions for the series. 3. Run three comparable mobile Lighthouse measurements for each representative route. 4. Retain every raw report, run timestamp, environment, and command. 5. Use a calculator or runner to compute the median; retain its inputs and result. 6. Compare the result to the recorded budget and investigate the causes of misses. Discard a run only for an evidenced invalid measurement, preserve it with the reason, and rerun under the same conditions. Never select only the best report. Budget exceptions need a named decision, remaining impact, and evidence, not a disguised PASS. ## Diagnose and improve Use the trace to identify hero discovery delays, blocking resources, image overfetch, font swaps, third-party work, and unnecessary JavaScript. Test a bounded change and compare the same route under the same conditions. Use image-pipeline.md, self-hosted-fonts.md, and embed-facades.md for focused corrections. Keep animation optional, honor reduced motion, and suspend decorative work in hidden tabs. Check useful initial content and the primary navigation with JavaScript disabled. ## Work a small example A route loads its local poster immediately but delays the third-party player until activation. Compare cold traces before and after the facade change. Inspect the pre-click request log and test keyboard activation before accepting the gain. A smaller transfer with a broken player fails the journey gate. ## Save the evidence Write site-work/qa/build/performance.md with artifact identity, route budget table, raw report paths, computed medians, field-data status, failures, and follow-up owners. Apply checklists/performance-seo.md PS01 through PS04. Unknown tool access leaves measurement UNVERIFIED with commands for a capable runner. ## Failure modes and source starting points - Lab/field substitution: a single score is called real-user performance. - Cherry picking: the best of several runs replaces the recorded series. - Budget drift: limits change after a failure without a reviewable decision. - Optimized screenshot: interactivity, reduced motion, and hidden-tab work go unchecked. Open https://web.dev/articles/defining-core-web-vitals-thresholds for field definitions. Open https://developer.chrome.com/docs/lighthouse/performance/performance-scoring for the chosen Lighthouse version and score interpretation. Keep source-opening receipts separate from site measurement reports. ## Source: playbooks/accessibility.md # Test whether people can complete the task Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: can the site's primary journey work across input and perception needs? ## Establish the target Start with the method's WCAG 2.2 AA baseline and verify the current W3C release, applicable target level, and relevant criteria as of ASK DATE before relying on it. Record a newer applicable release or erratum without silently changing an approved target. Name each critical journey and its routes, controls, errors, and completion state. Require manual evidence for every critical journey as well as automated checks. ## Use meaningful structure Choose headings for hierarchy, landmarks for page regions, links for navigation, and buttons for actions. Give controls names that make sense out of context. Use native controls when they meet the need and test any custom control fully. Expose expanded/selected/invalid state and relationships accurately. Do not use an icon, color, or positional instruction as the only meaning. ## Exercise keyboard and focus Navigate from entry through completion using keyboard only. Test menus, dialogs, validation errors, dismissal, retry, and success. Record visible focus, logical order, no trap, and restoration after closing overlays. Confirm focused content is visible and not hidden behind sticky UI. Test the escape path and focus destination when asynchronous content replaces a control. ## Compute contrast Use a calculator or runner with actual foreground and background inputs. For translucent layers, gradients, or images, compute the rendered composition and inspect the relevant worst-case locations and control states. Record font size/weight, criterion, threshold, unrounded ratio, method, and result. The baseline text thresholds are 4.5:1 for normal text and 3:1 for qualifying large text; verify the authoritative criteria and qualification rules before applying them. Evaluate meaningful control boundaries and focus under their applicable criteria. A color pair with no computed ratio is UNVERIFIED and cannot pass. Never round a failure upward or silently change an approved brand role to claim success. ## Test communication and recovery Associate labels and descriptions with inputs; preserve useful entered data on errors. Explain each error, its location, and a practical way to recover. Test status announcements with a named screen reader/browser combination. Inspect image alternatives for their actual purpose, with empty alternatives for decoration. Provide required media alternatives and usable controls. Automated semantics checks supplement actual assistive-technology journeys. ## Check reflow and motion The method proposes widths of 320, 390, 768, and 1280 CSS pixels for layout checks. Test text zoom at 200% and reflow separately against the applicable criteria. Record unintended horizontal scrolling, clipped controls, or hidden content. Check target size and spacing against the verified criterion, not a remembered number. Honor reduced motion and provide pause controls where required. Do not make information available only through animation, hover, or precise pointing. Inspect flashing hazards and preserve useful content without JavaScript. ## Work a small example A dialog opens from an inquiry button, traps no user, names its purpose, and can close. A missing required field exposes a linked error and preserves the other entries. After closing, focus returns to the inquiry trigger. Capture each transition and its result, not only the default dialog screenshot. ## Verify and remediate Write site-work/qa/accessibility.md and site-work/qa/contrast.md. For each result record route/state, candidate, tool/environment, criterion, inputs, observed behavior, evidence, impact, owner, and retest result. Apply checklists/accessibility.md AX01 through AX08. Re-run failed journeys after fixes; keep meaningful regressions for repeatable failures. Do not call an automated scanner a conformance certificate. Unavailable checks remain UNVERIFIED with a precise test and capable runner handoff. ## Failure modes and source starting points - Visual guess: a brand-colored button is called accessible without calculation. - Mouse-only evidence: keyboard and error recovery remain untested. - Scanner certificate: no violations is mistaken for complete conformance. - Incomplete composition: opacity or image background is omitted from ratio inputs. Open https://www.w3.org/TR/WCAG22/ and current W3C release information. Open https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html for text contrast, with separate relevant criteria for controls and focus. Record actual source access before adopting the baseline in a project. ## Source: playbooks/research-and-memory.md # Research and memory Establish the engagement date, build the evidence library, then release work. ## ASK DATE rule - Meaning: ASK DATE is the date the user makes the request, fixed at engagement start. Research must reflect what is available as of that date, with later checks explicitly dated inside the same engagement. It is never the model's training cutoff, a hardcoded prompt year, or the last library's date. - First action: establish it before research or intake questions. Never ask the user what the date is, in any phrasing. Never infer it from the model's own knowledge. An environment-supplied date and a remembered date may feel alike to the model; only external provenance counts. - Ownership: Researcher alone records it once in `site-work/research/library/scope.md`. A later role reads that record instead of independently resetting it. Installing a skill is not the start of a website request. **Date-source ladder.** Try in this order and stop establishing the date at the first successful rung. Record failed/unavailable earlier rungs and the successful rung's raw evidence. Capturing the first HTTP header remains a cross-check after an earlier rung succeeds; it does not restart the ladder or a later day's engagement. 1. **Host environment (`host-environment`).** Use a current date explicitly injected by the host into this request/session. Record the exact supplied value and its host-context location. A date the model believes it remembers, an old saved session's date, or a date typed by the user is not host evidence. Preserve any supplied timezone; do not invent a time of day when only a date is supplied. 2. **System clock (`system-clock`).** Through an available command runner, execute `date -u '+%Y-%m-%dT%H:%M:%SZ'`. Expected output is one UTC line shaped `YYYY-MM-DDTHH:MM:SSZ`; take its `YYYY-MM-DD` part as the date and preserve the whole output. On a Windows-only runner, use `powershell -NoProfile -Command "[DateTime]::UtcNow.ToString('yyyy-MM-ddTHH:mm:ssZ')"` with the same output shape. Unsupported or failed execution advances the ladder, never invents output. 3. **HTTP response (`http-date`).** Capture the raw `Date` response header on the first URL fetch of this run, including requested URL, final URL, status, raw header and any cache/Age evidence. Its expected HTTP-date shape is `Day, DD Mon YYYY HH:MM:SS GMT`. Parse that server-supplied value and normalize to UTC. Where command execution is available, `curl --silent --show-error --dump-header - --output /dev/null ''` shows response headers; retain only date provenance fields, never cookies or credentials. A fetch API that hides headers cannot satisfy this rung; missing, malformed or demonstrably stale cached headers advance it. Do not claim every fetch tool exposes a usable header or fabricate one from page content. 4. **Filesystem (`filesystem-mtime`).** If writing and metadata reading are available but command execution is not, write a new scratch file at `site-work/research/library/.ask-date-probe` and read its modification timestamp through the file tool. Record the exact raw mtime, timezone/precision, relative path and fresh-write result; derive the date from that timestamp. Reusing an old file's mtime does not count. If metadata cannot be read, advance the ladder. Remove only this owned scratch file if supported; it is never deployed or published. 5. **Derived floor (`derived-floor`).** If none of the earlier rungs is available, take the most recent credible publication/update date actually visible in sources opened this run. Record `ASK DATE: derived-floor ` with source URLs, observed date text and why it is credible. Collect only the minimum source evidence needed to establish this rung before the full research pass. Future scheduled dates, snippets, model knowledge and guessed dates are not observations. This is a lower bound, not proof of the actual day: research is current at least to that date, and currency beyond it is unproven. Every output opens with `Research as of derived-floor ; currency beyond this floor is unproven.` Every gate repeats that qualification; never silently promote it to an exact date. As more credible source dates are opened during initial establishment, take the latest before finalizing the one scope record; retain the candidate trail. 6. **Nothing available (`unavailable`, never a successful date rung).** No host date, command execution, usable URL fetch or filesystem means no current research capability either. Write or return `query-plan.md` and `unresolved-claims.md`, state the tool limit, and record the research gate BLOCKED. If URLs can be opened but no credible publication date or earlier rung can be obtained, date provenance is still BLOCKED. A missing date is not a separate softer exception, and cannot be solved by asking the user. **Cross-check, and never let a fetched source move the date.** A first-fetch HTTP Date comes from a server you do not control, and the first source of a run can be chosen by whatever you were pointed at. Treat it as evidence, never as authority. - **A local rung wins.** When a host date or a system clock is available, it sets ASK DATE. A disagreeing HTTP Date is recorded as a discrepancy with both values; it does not become the chosen rung and does not change ASK DATE. - **A fetched date later than the local clock is rejected.** No source knows the future. Record it as `rejected: future http-date`, keep the local rung, and treat that source as unreliable for dating anything else it says. - **A fetched date earlier than the local clock** is usually a cached or proxied response. Record it, keep the local rung, and prefer a direct fetch for anything date-sensitive. - **Only when rungs 1 and 2 are both unavailable** can `http-date` be the chosen rung, and then it needs corroboration: a second HTTP Date from an independent host, agreeing within 24 hours. Without that second source, do not adopt it; fall through to `derived-floor` and carry its qualification. - **A clock error is established, not assumed.** Two independent fetched sources agreeing with each other and disagreeing with the local clock by more than 24 hours is the only evidence that promotes a correction, and the correction is an explicit recorded decision that invalidates dependent receipts. Never a silent reset, and never averaged. - Normal passage of days in an engagement is not a conflicting start timestamp. **Why this rule is shaped this way.** Preferring the server unconditionally lets a single attacker-controlled page set ASK DATE into the future, after which every genuine access date looks stale and the research gate blocks the engagement. A source supplies evidence about itself; it never supplies authority over your own state. **Record once in scope.md.** Required date fields, before other scope assumptions: ```text ASK DATE: ASK DATE rung: ASK DATE evidence: ASK DATE precision: ASK DATE timezone: ASK DATE attempts: ASK DATE cross-check: Engagement: ``` - Validity: require a real calendar date and raw evidence matching the allowed rung. No missing date or rung, no assumed date, no `assumed`, `from memory`, or `user-supplied` rung. Model confidence and user confirmation cannot replace the ladder. - Source discipline: training memory is never research. A claim without a source URL and access date is a failure however confidently stated. Keep the existing search, opened-source, disagreement, evidence/inference, and unresolved-claim standards alongside this rule. - Two dates: each claim has `published: ` (label which when known) and `accessed: `, plus URL and supporting passage/revision. The publication date is the source's fact; the access date is when the agent opened it. Unknown publication dates stay `published: unknown`. Do not infer them from content, URL, copyright footer or HTTP Date. - Current access: `accessed` must be ASK DATE or later inside the same engagement, backed by a source-opening receipt. A date after the actual observation is fabrication. Preserve timezone/date precision and link the session/tool result; merely typing a recent date is not access evidence. - Derived-floor access: where the ladder proves only a floor, record `accessed: derived-floor ` with the actual source-opening event/sequence and `exact access date: unavailable`. Compare known lower bounds without claiming a precise wall-clock date. All such outputs and gate records retain the floor qualifier. A time-sensitive decision needing a proven exact day stays BLOCKED until that evidence exists; the qualified mode never claims exact-day currency. Other claims may pass the qualified gate with fresh source-opening evidence, all checks satisfied, and the floor limitation in the receipt. - Coverage: each applicable domain needs at least one actually opened, access-dated source and claim mapping; record its publication/update date or unknown separately. NOT APPLICABLE needs a project-specific reason. A bare URL, empty file or unresolved actionable claim does not meet coverage. - Opener: every library Markdown file, including scope, ledgers and domain checklists, starts with `Research as of `. The value is the exact stored ASK DATE, including the derived-floor qualification when applicable. Later access dates belong to claims, not a rewritten engagement start. YAML handoffs carry the date, rung, precision and gate qualification in their check evidence and limitations. **Freshness windows relative to ASK DATE.** These are the repo's conservative reuse defaults and triggers, not vendor promises that a fact cannot change. For a newly checked domain, the first due date is ASK DATE plus the window; a later actual check advances the next due date from that check. Store both the concrete due date and its offset from ASK DATE using date tooling. At or beyond expiry, recheck before reliance. A shorter known vendor change date or relevant version release wins. Same-day means that within one engagement, reuse the receipt when reliance falls on the same UTC calendar date as its `fetched_at`. Fetch again when reliance falls on a later calendar day or a change trigger fires, even within the same day. It does not grant 24 hours from a late check. In derived-floor mode, re-open fast-domain sources in the current work session and recheck them at every resumed session because elapsed days cannot be proved. This can satisfy only a visibly qualified lower-bound gate; it never proves same-calendar-day currency. A decision explicitly requiring that proof stays BLOCKED. | Domain | Freshness window relative to ASK DATE | Why this window and what triggers an earlier recheck | | --- | --- | --- | | 1. Reference codebases and real implementations | 30 days for pattern comparisons; verify revision and maintenance status at first reuse. | Structural lessons outlast releases, but a moving branch may change the inspected implementation. New revision, license or security advisory triggers a recheck. | | 2. Stacks and frameworks | 7 days for landscape comparisons; same-day check for selected versions, APIs, deprecations and support. | Framework releases and exact API contracts can change within a build; confirm the current supported version before coding against it. | | 3. Design | 365 days for typography, colour theory, gestalt and grids; 90 days for awards, trends and anti-trends. | Fundamentals decay slowly; examples and trends need a fresher view. Award selection always covers the last two to three years relative to ASK DATE. | | 4. Graphics skills | Same-day check for tool capabilities, pricing, commercial rights per tier and destination specs; 90 days for export craft. | Product tiers, safe zones and rights can change without changing a tool's name; stable compression principles need less repetition. | | 5. UI and UX | 180 days for tested interaction principles; 30 days for browser/device interaction behavior. | Task and recovery principles persist; platform behavior changes. A new input mode, audience or observed usability failure triggers a recheck. | | 6. Accessibility | 365 days for fundamentals; current-version check at first reliance and after 30 days. | Age alone does not invalidate contrast or keyboard principles. Confirm the current standard release, target level and relevant errata as of ASK DATE, and again before applying any newly discovered release. | | 7. Performance | 30 days for measurement strategy; same-day check for CWV thresholds, metric definitions and selected tooling. | Loading principles are durable, while current metric semantics and measurement tools can change; distinguish field evidence from lab results. | | 8. SEO | 7 days for general documented behavior; same-day check for search features, schema eligibility and indexing interfaces. | A supported feature can retire or change independently of basic crawlability; platform announcements trigger immediate recheck. | | 9. AEO and AI citation | Same-day check for crawler policies, citation behavior, search behavior and proposal adoption. | Consumer behavior and documentation change quickly and evidence is incomplete; a prior observation never proves present citation behavior. | | 10. Security | 7 days for the threat landscape; same-day check for advisories, host header/CSP syntax and scanner criteria. | Structural escaping remains useful, but new exposure or configuration behavior can invalidate a safe-looking baseline. Surface changes trigger immediate review. | | 11. Hosting, deploy and DNS | Same-day check for platform capabilities, plan prices/restrictions, header syntax and deploy configuration; 90 days for DNS fundamentals. | Commercial limits and deployment contracts change quickly; name-resolution principles change slowly. Recheck the actual target before release. | | 12. Measurement | 30 days for setup and interpretation guidance; same-day check for selected event APIs, consent settings and receiving-property behavior. | Statistical caveats persist; vendor interfaces and active configuration do not. Changed instrumentation or property triggers verification. | | 13. Legal, kept light | Same-day check for exact font/stock/AI tool licenses and intended-use rights; 30 days for background guidance. | Rights attach to a particular asset, version and tier; a previously allowed use is not evidence for a new use. Changed terms or jurisdiction triggers review. | | 14. Languages and coding practice | Same-day check for selected language, runtime and framework versions, Baseline status of features in use, and security advisories; 30 days for testing, linting and tooling guidance; 365 days for fundamentals such as semantic HTML and structural escaping. | Language support, framework idioms and advisories can change during a build; stable semantics and escaping principles need less repetition. A selected-version, browser-target or security change triggers an earlier recheck. | - Versioned standards: identify the authoritative current release as of ASK DATE and at each scheduled refresh; record release/version, target level, source and applicability. An old but still-current standard is not stale merely because its publication is old. A new relevant release triggers review before reuse even inside a nominal window. - Staleness artifact: generate this full table into `staleness.md`, add all applicable claims, original accesses, last revalidations, window/expiry, trigger, reason, owner and dependent receipts. Name the earliest-expiring applicable domain (all ties), its window, and concrete recheck date with the ASK DATE-relative expression. Same-day domains are due before use that day. Do not average domain windows or let a slow domain hide a fast subclaim. **Prior-library revalidation pass.** A library from another engagement is stale until this pass completes against the new ASK DATE, even if it contains useful work. 1. Read the previous scope ASK DATE and every per-claim access date first. Preserve them as history before recording the new engagement's date evidence. Start the new research gate BLOCKED; an old PASS does not transfer. 2. Map every potentially relied-on claim to its domain window and the current brief. Compare the original/last genuine check with the new ASK DATE using date tooling; inspect change triggers and current version status. 3. For elapsed windows or changed scope/version, reopen authoritative sources and fully recheck the claim. For a claim still inside its window, allow a lighter confirmation of the original source, version and applicability instead of repeating the entire research sweep. It still needs a real source open during this engagement to earn a current `accessed` date; a desk review alone cannot meet the acted-on claim gate. 4. List every reused claim in `staleness.md` with claim ID, `original accessed`, original scope date, window, decision (`rechecked`, `reused within window`, `superseded`, or `blocked`), reason, supporting current source-opening receipt and revalidation date. Update its current `accessed` only after that source opening. Historical dates remain visible as history, never passed off as current evidence. 5. Finish all domain dispositions and relied-on claims, then rewrite library opening lines to the new ASK DATE and evaluate the gate. A new scope record may be established first with BLOCKED status; it cannot certify the untouched old library. Files containing unresolved material label it clearly and no dependent decision is released by a stamp alone. 6. Without web access, retain the old evidence as historical, produce `query-plan.md` and `unresolved-claims.md`, and keep the gate BLOCKED. An existing library does not waive current-source access or staleness checks. **Downstream top-ups and multi-day engagements.** Every role follows the same rule, starting with the library scope record. Its `top-up.md` records each claim's source date, URL, actual current-engagement access and any original access plus revalidation decision. Reviewer returns those fields in its read-only packet. Training-memory claims and unrevalidated prior-run dates fail identically for all roles. Send canonical corrections to Researcher and pause affected decisions. ASK DATE remains the engagement start across days and sessions. Record later checks with their own access dates, do not restamp the start. If a fast domain's window elapses, recheck before its facts are relied on again, including before release. Invalidate dependent gate receipts until the refresh evidence is accepted. **No search, no current-research pass.** Without live web access, produce or return `query-plan.md` and `unresolved-claims.md`, state the limitation, and leave the gate BLOCKED whether the library is absent, old, or freshly stamped. Training knowledge, user-supplied dates and a list of intended queries cannot satisfy the gate. A research packet can be useful without being complete; never label it PASSED. **Failure modes.** Record stale reuse, restamping without revalidation, missing or invented date provenance, asking the user for a date, confident undated claims, invented publication dates, unqualified derived floors, expired multi-day claims, and capability-free passes as findings. Their tell is missing or contradictory scope/source-opening/revalidation evidence, not the prose's apparent confidence. ## Build research that someone can apply Question: which facts change this site's design, implementation, or release? - Standards: search dated claims, open each cited source, and preserve source and access dates separately. - Areas: execute every numbered domain in prompts/01-website-deep-research.md. - Depth: examine actual repository files at an identified revision, not only project descriptions. - Interpretation: turn each brief word into a testable visual decision and an alternative. - Evaluation: compare evidence of user task completion separately from aesthetic preference. - Extraction: separate observed values, inferred roles, approved rules, and unresolved conflicts. - Save: write the library and propose durable memory as two separate destinations. - Close: report surprising findings with claim IDs, then request only still-missing design inputs. - Order: Researcher is agent one; no downstream role starts until its disk library passes. ## Write a claim ledger Use templates/evidence.md for each claim that could change a decision. Record claim ID, domain, statement, URL, source date and kind, actual access event, supporting passage or repository revision, applicability, confidence, and dependents. A search result is a discovery lead. Open its source before recording it as evidence. Label evidence, inference, proposed default, measurement, and UNVERIFIED separately. A proposed default can guide a draft only when no blocked external claim supports it. Use this exact table header in `sources.md`; keep applicability and evidence kind in the per-claim record. Escape literal pipes in table cells with a backslash. ```text | Claim ID | Domain | Statement | URL | Published | Accessed | Status | Dependents | | --- | --- | --- | --- | --- | --- | --- | --- | ``` Use stable `CLAIM-` IDs containing only letters, digits, underscores and hyphens. Status is `OPENED` only with a receipt, otherwise `UNVERIFIED`. A `Verified` label without a receipt fails the gate; it cannot stand in for proof of a fetch. **Fetch receipts.** At fetch time, write one receipt per cited claim's opened source to `research/library/receipts/.md`, relative to `site-work/`. Never reconstruct receipts later or mark a claim OPENED from memory or a search snippet. Search results are discovery leads; the page itself must be fetched. The receipt starts with the library's dated opener, followed by these plain fields: ```text url: fetched_at: tool: result: published: excerpt: | ``` Indent each excerpt line by two spaces. Include quoted page date text in the excerpt when claiming a publication/update date; otherwise use `unknown`. The row's Published value must match the receipt's published value exactly. Optional milliseconds in fetched_at use three digits before Z. If the environment cannot supply a UTC timestamp, leave that claim UNVERIFIED; never invent precision. An existing qualified ASK DATE does not authorize a fabricated fetch timestamp. **Check before reliance.** Use this checker ladder: 1. `website-build-skill check-library /site-work`, when that command is on PATH. 2. Otherwise `npx -y website-build-skill@ check-library /site-work`, where `` is read from the installed `manifest.json`. Never write the literal version into prose, or it goes stale on every bump. 3. From a repository checkout: `node bin/website-build-skill.mjs check-library `. 4. When no rung can run, meaning no shell, no PATH command and npx fails or has no network: Reviewer records the five-rule manual equivalent. Also record each rung tried, with its command, exit code and output, as the reason. For every rung that runs, save the command, exit code and output. PASS still needs exit 0 from a mechanical rung, or a recorded manual equivalent for rung 4. Acted-on UNVERIFIED claims still keep research acceptance BLOCKED. Save the ladder evidence with the research gate evidence. Exit 0 means receipt consistency, not proof that a passage is true or supports a decision; exit 2 reports problems, one per line. The checker lists UNVERIFIED rows even when it exits 0. Any acted-on UNVERIFIED claim keeps research acceptance BLOCKED. For rung 4, Reviewer records the same five checks in checklists/research.md by hand. Independent AD09 re-fetching remains required. Example: a provider's paid-tier export right needs the exact tier's current terms, the asset's origin, intended use, a source-opening receipt, and required notices. A review of the provider's image quality cannot establish any of those rights. When sources disagree, record both claim IDs, dates, scopes, and the affected decision. Do not average incompatible claims or pick the most convenient answer. Prefer the authoritative source for the exact version or tier, and record why. If evidence cannot settle a material conflict, block that decision with a next action. ## Choose where the work is saved Read outputRoot and optional outputStorage from the install receipt before the first write. Reuse that choice without asking again. If it is absent, ask the human using templates/install-choice.txt: an Obsidian vault folder, local folder, Notion export, or another local destination. An explicitly accepted default uses the website project folder; a missing answer is not consent. Researcher records the root and any export target in site-work/research/library/scope.md beside ASK DATE. Every project path, including site-work/, resolves inside that root. Later roles read this record instead of choosing again. An Obsidian vault and a plain folder both work directly, because the library is Markdown on disk. Notion is an export destination, never the working copy: the research gate, the prior-library pass and every role read their own files back by path, and a page in a workspace API cannot serve that read-back. Keep the working copy on disk and export the finished library, recording the export the same way as any other save, with status and read-back. Announce that split when Notion is chosen, and record which destination holds the authoritative copy. Confirm the root is writable by writing `/site-work/research/library/scope.md` and reading it back before the sweep begins. ## Produce the complete library All paths below belong to the user's authorized project, never the installed skill. They resolve inside the workspace root the human chose; site-work/ is a name under it, not a fixed location. Researcher owns the library and its revisioned research receipts. Library Markdown, including each domain checklist, uses the mandatory dated opener. ```text site-work/ research/ library/ Researcher-owned canonical library. README.md Dated index, headline findings, role reading map. scope.md ASK DATE, ladder rung/raw evidence, workspace root, request, tools, applicability. coverage.md Fourteen domains, files, checklist and source coverage. 01-codebases-and-stacks.md Domains 1 and 2; code reads and current stacks. 02-design-and-experience.md Domains 3 and 5; design and UI/UX. 03-graphics-and-rights.md Domains 4 and 13; graphics and light legal. 04-accessibility-and-performance.md Domains 6 and 7; standards and measurement. 05-search-and-answers.md Domains 8 and 9; SEO and AEO. 06-security-and-delivery.md Domains 10 and 11; threats, hosts, deploy, DNS. 07-measurement-and-operations.md Domain 12; analytics and operational follow-through. 08-languages-and-code.md Domain 14; language support, coding practice and verification. sources.md Claim IDs, opened URLs, source/access dates, scope. receipts/ .md Per-claim page fetch fields and verbatim supporting excerpt. disagreements.md Conflicting sources, affected decisions, dispositions. query-plan.md Search questions and missing-source actions. unresolved-claims.md UNVERIFIED claims and blocked downstream decisions. how-to-read-a-brand-kit.md Evidence into checkable design decisions. website-qa-checklist.md Cross-domain blocker-first index of applied checks. surprises.md Short findings and implications for the user. staleness.md Fourteen freshness windows relative to ASK DATE, earliest expiry, reuse decisions. learning.md Opened evidence, learned rules, applied checklist IDs. recipes.md Commands that actually ran, with tool version and what they produced. memory-proposal.md Durable rules and location, not a completed save. memory-receipt.md Save status, destination, read-back or pending action. checklists/ 01-codebases.md Inspected source, license, complexity, reuse. 02-stacks.md Version/API evidence and justified dependencies. 03-design.md Brand interpretation, tokens, three directions. 04-graphics.md Per-tier rights, sizes, safe zones, inspected exports. 05-ui-ux.md Task journeys, state coverage, mobile recovery. 06-accessibility.md Computed contrast and manual assistive-tech checks. 07-performance.md Field/lab distinction and repeatable budgets. 08-seo.md Crawl, canonical, schema, linking, sitemap. 09-aeo.md Quotable answers, entities, crawler evidence. 10-security.md Input/secret boundaries, host CSP, adverse cases. 11-hosting.md Preview, DNS, HTTPS, rollback, plan restrictions. 12-measurement.md Receiving-property proof and interpretation limits. 13-legal.md Font, stock, AI imagery, trademark evidence. 14-code.md Supported features, tests, tooling, dependencies and secure code. coordinator/ Coordinator top-ups, flags, learning and QA receipts. designer/ Designer top-ups, flags, learning and QA receipts. graphics/ Graphics top-ups, flags, learning and QA receipts. builder/ Builder top-ups, flags, learning and QA receipts. optimizer/ Optimizer top-ups, flags, learning and QA receipts. handoffs/ researcher/ Versioned research gate receipts to Coordinator. review/ Coordinator captures read-only Reviewer returns. / Findings, research packet, handoff, capture envelope. MEMORY.md Coordinator's consolidated durable-memory proposal. ``` - Coverage: map all fourteen domains to grouped files, source claims, checks, and downstream owners. - Exclusions: survey every domain; justify any project-specific NOT APPLICABLE check. - Checklists: each domain check names criterion, method, expected evidence, claim IDs, owner, status, and exclusion reason. - Blockers: website-qa-checklist.md collects unresolved critical checks before quality scoring. - Learning: reopen written files and record which rules change the handoff. - Recipes: when a command works, paste it into recipes.md with the tool and version it ran on, the input it took, and the output it produced. A later role runs the recorded command instead of re-deriving flags. A recipe is a record of one run, not a guarantee for a different version: re-check it against the installed tool before relying on it, exactly as with any example command. - Read-back: verify the saved revision and links before issuing a research receipt. - Privacy: keep runtime research, source assets, and private scope out of deployment output. ## Learn, ingest, then top up Every downstream role starts with its WHAT YOU MUST LEARN filenames. Read the actual library, its current revision, and the applicable domain checklists. Record opened files, learned rules, changed assumptions, and applied check IDs in learning.md. Top up only remaining questions in that role's domain using current source openings. Read library/recipes.md before deriving an image, font, or build command, and append any command you got working, with its tool version and result, in the same pass. Write README.md, sources.md, top-up.md, flags.md, learning.md, applied-checklists.md, memory-proposal.md, and memory-receipt.md in the role's owned research directory. Reviewer returns these bodies read-only for unchanged Coordinator capture. Send wrong or stale canonical claims to Researcher by claim ID, dated counterevidence, affected decisions, and paused receipts. Only Researcher revises the shared library. A new brief, host, tier, dependency, brand decision, or source correction invalidates all affected downstream receipts until the relevant checks run again. In SOLO, read the same full role bodies and do the same research and learning. Write and reopen a self-handoff at every boundary using templates/handoff.yaml. Name in framing_reset which prior assumption or design attachment you release. Keep approved requirements; do not treat your previous suggestion as a user decision. ## Save durable rules separately Keep volatile versions, prices, rights, and platform behavior in the dated library. Propose durable rules such as computed contrast, three mockups, evidence-backed claims, smallest justified stack, source-safe rendering, and different-family review. Record the library location and refresh procedure so a later session can find it. Use supported memory or project instructions only within existing authorization. Record status as saved, declined, unsupported, or pending, with the exact destination. For saved, record the operation receipt and read back the persisted content. If save or read-back fails, record the failure and keep the proposal available. Session context and an agent saying it learned something are not durable storage. Coordinator may consolidate proposals into site-work/MEMORY.md without changing another role's receipt or upgrading a pending save into a success. ## Continue without durable memory Return a reattachment packet containing the brief, capability limits, library revision, claim/source ledger, staleness schedule, approvals, stage status, and latest handoffs. Include complete named bodies when the receiver cannot open file paths. Tell the user which project mechanism can save the packet and which files to reattach. Reopen the received files at the next session and run the prior-library or resumed-session freshness procedure as appropriate. Missing disk persistence still blocks research. Optional memory being unsupported does not invalidate a verified disk library. ## Working with the tools you have | Tool | What it enables | Next step when it is absent | | --- | --- | --- | | Web search | Current-to-ASK-DATE research and revalidation, including a prior library. | Clarify the request, review supplied sources and plan queries. Return `query-plan.md`, `unresolved-claims.md`, and a BLOCKED receipt; current research resumes with web evidence. | | URL retrieval | Raw-URL bootstrap and opened-source citations. | Use a pasted or uploaded core method and ask the human for self-contained bundles. Cite sources after opening them. | | File writing | Saved disk research and a local install confirmed by read-back. | Draft prompts, specifications and named file bodies. Return downloadable files or copyable labeled blocks for saving and read-back. | | Persistent memory | Durable memory across future sessions. | Continue the current-session workflow and project documents. Return a `MEMORY.md` proposal plus explicit save/reattach steps. | | Image generation/viewing | Three inspected visual mockups and visual approval. | Plan the brief and wireframes. Return a Designer handoff with required assets and criteria; complete visual approval after inspecting the images. | | Code execution/browser | Measured contrast, functional tests, lab scores and live QA. | Draft implementation and a test plan. Return commands and exact expected evidence for a capable runner; record measured results after execution. | | Separate workers | TEAM jobs and concurrent workers with verified independence. | Run sequential SOLO jobs, role learning and saved self-handoffs. Return a SOLO capability receipt and role-boundary packets. | | Independent model family | The independent adversarial gate. | Run an internal critique and prepare a review packet. Return AUDIT_BRIEF plus an immutable artifact for another family; that review completes the independent gate. | | Deploy access | Production release and live verification. | Prepare a reviewable local/preview artifact where available. Return an operations doc and authorized operator handoff for release and live checks. | Check each tool separately. A working URL reader still needs separate browser, image inspection, response-header and calculator checks. After installing role definitions, verify running workers, tool permissions and the actual model families. Record a session probe and result for host loading, orchestration, isolation, memory and deployment before relying on each capability. ## Verify and hand off Apply checklists/research.md AD01 through AD08, then R01 through R06. Save the producer receipt and have Coordinator reopen its artifacts before acceptance. Independent AD09 runs later, before shipment, rather than blocking agent one's start. Every receipt names the library revision, scope provenance, relied-on claims, source-opening evidence, earliest expiry, next owner, and unresolved limitations. All applicable checks must pass; a persuasive summary does not replace the evidence. ## Failure modes - Decorative research: no claim-to-decision map or usable domain checklist. - False persistence: a proposal or inaccessible filename is called a saved library. - Scope drift: a downstream role quietly selects a new tier or host without research. - Stale handoff: a changed claim leaves dependent PASS receipts untouched. - False independence: another persona in the same family approves its own work. ## Source and verification status This playbook defines the method's evidence policy, not a claim about a live platform. Source URLs and access events are recorded at runtime using templates/evidence.md. External facts not opened and checked in the engagement remain UNVERIFIED. Never report a measured, saved, installed, or deployed result without evidence. ## Source: playbooks/deploy-and-operate.md # Promote an exact, operable release Date rule: [establish ASK DATE and revalidate claims](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Source status: external facts and example commands are UNVERIFIED until checked for the chosen version and engagement. Record opened URLs, source dates or unknown, actual access dates, and supporting evidence. Question: can a cold reader release, verify, and recover this site from one document? ## Establish release authority and identity Require the brief, user selection, current research, QA receipts, independent review, and ROUND 1 dispositions with regressions on the final candidate. Name target account, project, domain, operator, and authorized action. Existing explicit authorization is sufficient within its scope. If authority is missing, finish the reviewable candidate before asking at that boundary. Do not infer permission to buy services, create accounts, change unrelated DNS, or rotate keys. Record source revision, build environment, immutable artifact digest, and preview identity. If review fixes changed the candidate, retain the reviewed predecessor, explained diff, post-fix harness, and final digest. Unexplained changes invalidate affected evidence. Identify a known-working rollback artifact and its documented restoration command. An initial release needs an explicit safe recovery plan when no predecessor exists. ## Prepare and promote Build cleanly using the documented command and locked dependencies where applicable. Inspect the actual upload allowlist for research, private assets, credentials, and unrelated files. Test the preview's routes and production configuration before promotion. Promote the checked bytes rather than rebuilding from a moving source revision. Record the command/action, actual response, deployment identifier, timestamp, and public URLs. A successful command is evidence of a deploy operation, not a working public journey. ## Verify the live release Check HTTPS, canonical hosts, redirects, intended routes, error paths, and assets. Complete the primary journey, including validation, submission, and recovery. Inspect actual CSP and other headers on all response classes. Check canonical metadata, social images, sitemap, llms.txt, and intentional exclusions. Inspect mobile and desktop behavior with production CSP enforced. Separate social-bot origin responses from third-party preview-cache results. Verify analytics at the intended property; loading a script does not prove receipt. Record absent field observations as UNVERIFIED with a follow-up owner. If a critical check fails, use the authorized recovery plan and verify the restored journey. Record both the failure and recovery evidence; do not hide rollback under a release PASS. Apply checklists/ship.md SH01 through SH10, including distinct pre-promotion and live phases. ## Write one complete operations document Builder writes SITE_OPERATIONS.md in the authorized implementation root. Use templates/site-operations.md and replace blank contract fields with actual evidence. Keep these sections in order: 1. What and why: purpose, audience, primary action, and deployed identity. 2. Trigger: manual or scheduled content, build, and release events with owners. 3. Invocation chain: editing through validation, build, preview, promotion, and verification. 4. Dependencies: versions, host, integrations, credentials by mechanism only. 5. Reads: content, assets, tokens, environment names, and approved external resources. 6. Writes: generated output, deployed targets, logs, and runtime side effects. 7. The closed loop: watcher, expected signal, cadence, recipient, and response. 8. Failure modes: symptoms, diagnosis, recovery, and escalation owner. 9. Run-and-verify by hand: exact working commands, success evidence, and rollback. 10. Source of truth: source, deployed artifact, research/approval revisions, and maintenance owner. Name what watches the site, including nothing. Silence is not a monitoring plan. Include enough content-editing and recovery detail to avoid requiring a second document. Every untested command or procedure says UNVERIFIED and names the settling test. Never write secret values, authenticated URLs, or personal credentials into the document. ## Maintain the result Record who adds content, approves brand changes, updates dependencies, and checks measurements. Scheduled publication requires an actual trigger; date-dependent templates do not self-run. Revalidate expired host, license, security, and search facts before later releases. Re-run checks affected by changed content, resources, forms, or dependencies. Keep rollback identities and retention limitations explicit. ## Failure modes and sources - Artifact drift: deploying unreviewed files after a green harness. - False live proof: command success replaces browser and response evidence. - Missing loop: nobody receives an alert or knows how to run a manual check. - Untested recovery: a rollback command is documented as verified without a run. Open the selected host's current deployment, promotion, and recovery documentation. Record version, plan restrictions, actual access evidence, and authorized runtime receipts. No host procedure is assumed to work because this package describes it. ## Source: references/stacks/static-html.md # Static HTML recipe Date rule: [ASK DATE and source evidence](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Use this recipe only after accepted research and a named visual mockup selection. Example commands and host/runtime support are UNVERIFIED until executed or sourced for the chosen project. Save actual results; never claim this recipe was deployed. Use for a small information site without repeated publishing or application state. ## File responsibilities ```text site/ index.html Main audience/action page. visit/index.html Deliberate second route when the brief needs it. assets/styles.css Approved tokens, layout, states, responsive rules. assets/site.js Optional interaction only. assets/images/ Approved measured exports with required notices. assets/fonts/ Licensed woff2 and license notices if used. robots.txt Owner-approved crawl policy. sitemap.xml Intended canonical public routes. llms.txt Truthful navigation map. 404.html Useful error and recovery page. SITE_OPERATIONS.md Complete operational handoff, excluded from upload if private. ``` Choose the selected host's static header configuration separately. Keep source and output identical only while this remains a genuine no-build site. Deployment uses an explicit file allowlist, not every file in the workspace. ## Preview and check From the approved site directory, a local preview example is: ```sh python3 -m http.server 8000 --bind 127.0.0.1 ``` Open the local root and every intended route in a browser. This preview does not prove production redirects, custom error handling, HTTPS, or headers. Inspect those separately on the authorized host preview and final release. There is no package installation or build command required by this recipe. Record any added tool as a project-specific dependency with a reason. ## Verify the contract - Build: run checklists/build.md against source and browser DOM, including missing optional IDs. - Accessibility: complete keyboard/error journeys and computed contrast checks. - Performance: retain the declared cold mobile series and all reports. - Discovery: inspect initial HTML, canonicals, internal links, route map and metadata parity. - Security: inspect actual host headers, enforced-policy behavior, and scanner evidence. - Release: apply checklists/ship.md to the exact uploaded files and independent review. ## Add the next page A unique second page can be authored directly with the same approved styles. When repeated structure or metadata requires recurring copy/edit work, revisit the scripted-static recipe before duplicating a growing set of pages. Record how shared navigation and discovery files remain consistent in the interim. ## When to move to a bigger stack Browser JavaScript cannot safely store server secrets or enforce private authorization. Use a separately justified endpoint or reconsider the framework branch for server state. Scheduled changes require a real editing/release trigger; static files do not self-update. Move validated content into records before repetition creates divergent page state. ## Research starting points Read the selected host's static routing/headers documentation and the current HTML standard. Inspect a real no-build repository at an identified revision and check its license. Use playbooks/choose-stack.md for the recorded decision and rejected alternatives. ## Source: references/stacks/scripted-static.md # Scripted static recipe Date rule: [ASK DATE and source evidence](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Use this recipe only after accepted research and a named visual mockup selection. Example commands and host/runtime support are UNVERIFIED until executed or sourced for the chosen project. Save actual results; never claim this recipe was deployed. Use when many pages share structure and must derive metadata from the same records. ## File responsibilities ```text src/data/ Authored records and route registry. src/render/ Shared escaping, URL, JSON and state helpers. templates/ Page and component rendering. scripts/build.ts Validate, render, derive discovery, report omissions. scripts/images.ts Deterministic authorized image transformations. public/ Approved static files copied to output. test/ Data boundaries, rendered adverse cases, route parity. dist/ Generated deployable output, never hand edited. package.json Exact project scripts and declared dependencies. package-lock.json Reproducible dependency resolution when npm is selected. SITE_OPERATIONS.md Content, build, release, verify and recovery in one file. ``` Builder owns implementation and generated output. Graphics supplies versioned assets; Optimizer supplies versioned discovery inputs. Do not let integrations overwrite their authored sources. ## Define the command contract ```text npm ci Install the project's reviewed locked dependencies. npm run build Validate -> images -> render -> discovery -> inspect/report. npm test Run meaningful boundary and generated-output checks. npm run preview Serve the built output for local browser verification. ``` These commands are a proposed project contract, not scripts supplied by this skill. Builder must implement and verify the scripts and document the actual TypeScript runtime. Use the chosen runtime's supported compilation/execution path after a current-source check. Vite is optional when bundling or development behavior serves a named requirement. Sharp is a build dependency when the image transformation pipeline needs it. Do not introduce a client framework merely to map records to HTML. ## Build deterministically Validate required fields, route uniqueness, URLs, dates, and relations before rendering. Compute publication state once with an explicit clock/timezone and named rebuild trigger. Generate HTML, metadata, social inputs, schema, sitemap, and llms.txt from validated records. Omit absent optional provider controls and report the omission. Sort output and use stable content/transformation asset identities. Exclude site-work, originals not intended for publication, credentials, and scratch files. ## Prove the next-item workflow Add one invented valid record in a disposable copy, run the clean command chain, and inspect the new route and every derived surface. Confirm no template or separate metadata list needed manual edits. Remove the demonstration record before the real release and rebuild its exact candidate. Keep adverse cases for quotes, script terminators, unsafe schemes, empty IDs, duplicate slugs, missing assets, long copy, and publication boundaries. Apply checklists/build.md and the remaining QA/security/ship gates. ## When to move to a bigger stack A generated page changes only when rebuilt and promoted. A browser interaction cannot keep a private server credential. Move to a justified endpoint or framework when request-time/authenticated state needs it. Keep records and pure rendering helpers separable so the content is portable. ## Research starting points Read current runtime, template library, sharp, optional bundler, and selected host docs. Inspect actual build/helper/test files in reference repositories at recorded revisions. Use playbooks/data-and-templates.md and image-pipeline.md for acceptance contracts. ## Source: references/stacks/framework.md # Framework recipe Date rule: [ASK DATE and source evidence](../../skills/website-build-skill/playbooks/research-and-memory.md#ask-date-rule). Use this recipe only after accepted research and a named visual mockup selection. Example commands and host/runtime support are UNVERIFIED until executed or sourced for the chosen project. Save actual results; never claim this recipe was deployed. Use when named application requirements earn a server/client framework. ## Justify the runtime Compare a small endpoint with a full application for each server requirement. Name authentication state, server secrets, request-time behavior, integration needs, content authoring, deployment runtime, and maintenance owner. Select supported versions from current official documentation and actual source inspection. MDX or payments may support this decision but do not mandate a particular framework. ## Map responsibilities ```text routes/ Framework-native route files after version verification. server/ Authorized secrets, validation, integrations, access checks. components/ Shared presentation and bounded client interactions. content/ Validated authored data and owner-approved entity facts. public/ Approved images, local fonts, discovery/static assets. test/ Server boundaries, rendering, state and primary journeys. framework configuration Verified runtime, output, routing and security behavior. dependency lock Reproducible chosen toolchain. SITE_OPERATIONS.md One complete run/release/verify/recovery document. ``` These are responsibility names, not invented vendor directory requirements. Use the actual framework's versioned directory and API contracts. Keep server secrets out of public environment variables, serialized props, and client bundles. Authorize each private action on the server; hiding a button is not access control. ## Establish the command contract Record exact dependency installation, development, type-check, test, production build, production preview/start, deploy and rollback commands for the chosen host/version. Do not paste generic commands as successful runs. Require a clean production build and the same output/runtime class used for release. Record environment variable names, purpose, scope, and injection mechanism without values. Verify build-time versus request-time behavior, caching, route fallback and error handling. ## Render safely and usefully Keep useful initial HTML and truthful per-route metadata. Validate data, URL schemes and required identifiers before rendering controls. Use safe script-bound JSON serialization even if the framework escapes normal text. Test server/client state parity and boundary dates with an explicit timezone policy. Keep client work small; add it for actual interaction rather than all page content. ## Verify the application surface - Access: test unauthenticated and wrong-authority requests on each protected action. - Inputs: test malformed bodies, rejected URLs, uploads and third-party responses where applicable. - Rendering: run build B04/B05 and discovery parity against actual production output. - CSP: inspect emitted inline content and test an exact hash or per-response nonce design. - Responses: check normal, redirect, error, asset and dynamic/function headers separately. - Journey: complete mobile/desktop, keyboard, failure/retry and reduced-motion paths. - Release: freeze a candidate, obtain different-family read-only review, reproduce findings, verify fixes, then promote the checked artifact within existing authorization. ## When to move to a bigger stack More runtime means more dependency, patching, secret, and operational responsibility. Record the upgrade cadence, watchers, failure recipient, and tested recovery commands. Keep content portable and isolate external integrations behind narrow interfaces. A supported framework name does not prove that a selected host tier runs its features. ## Research starting points Open the chosen framework's current routing, rendering, security, environment, and CSP docs. Open the target host's current runtime/plan constraints and deployment/recovery docs. Compare a real application repository at an inspected revision, with its license recorded.