stack/skills/ms-frontend-design/references/site-completeness.md

Site completeness

Scope and inventory (MUST)

For a new public site or complete public-site redesign, implement the baseline below, reusing valid existing pages and integrations. These are this skill's delivery requirements; the presence of a row does not imply a universal legal obligation. For internal tools, targeted repairs, and prototypes, apply the scope rules in SKILL.md. Existing organization-wide privacy or support destinations may be linked when they actually cover this service.

Keep a compact inventory: item, route or location, applicability, verified content source, implementation, and verification result. A missing business fact is unresolved work, not a reason to mark a required page inapplicable. Ask for necessary facts while building the rest. Do not publish placeholders as finished business or policy content.

ID	Item and applicability	Required implementation	Acceptance check
SITE-01	404: every routed site/app	A recognizable not-found view with explanation, useful home/navigation links, and the normal accessible shell where appropriate. Preserve the unknown URL instead of silently redirecting to home.	Open an unknown nested URL directly and by client navigation. Check recovery links; verify HTTP 404 on the serving layer where supported. A static SPA that returns 200 must disclose that hosting limitation.
SITE-02	About: public-site baseline	A dedicated page explaining who operates the site, its purpose, and relevant factual background, linked from navigation or footer.	Route loads directly; identity agrees with Contact, privacy, and footer. No invented team, credentials, statistics, or endorsements.
SITE-03	Contact: public-site baseline	A dedicated page with at least one real, owner-supplied contact method. Implement all supplied, intended public methods: email, phone, address, support URL, or verified social links as appropriate.	Check mailto/tel/link destinations and accessible names; display a readable/copyable address or number. Do not invent missing methods or publish private contact details.
SITE-04	Contact form: when included	Working delivery integration, labels, minimal required fields, useful validation, pending/error/success states, duplicate-submit protection, and privacy information at collection. A working direct contact method is an acceptable alternative when a form is not required.	Use a mock or authorized test destination to verify success and failure; preserve recoverable input on error. Never display success after only a timer, or send live messages without authorization.
SITE-05	Privacy notice: public-site baseline; also wherever personal data is collected	A discoverable page covering the service's actual processing, with additional notice at collection points. Follow the privacy section below.	Compare text against forms, analytics, embeds, accounts, hosting/logging, and service providers. No generic claims of collecting nothing without evidence.
SITE-06	Cookie/storage information and consent: according to actual technologies and applicable rules	Inventory cookies and similar storage/access technologies, purposes, providers, and duration. Implement the consent behavior below where consent is required; disclose exempt use appropriately.	Inspect actual requests and storage in a fresh session, after each choice, and after withdrawal. A visible banner alone does not pass.
SITE-07	Shared footer: public-site baseline	About, Contact, Privacy, applicable policy and cookie-preference links, actual rights-holder name, and dynamic copyright. Use a shared component/configuration so routes agree.	Follow every link from an ordinary page and the 404 view; test wrapping, keyboard access, and year behavior. No empty hrefs or placeholder links.
SITE-08	Error recovery: where runtime operations can fail	A suitable route/component fallback with recovery navigation, retry only when meaningful, and no sensitive diagnostics in public copy.	Exercise a failed request or rendering failure; the user can recover without losing avoidable input. Do not label permission/network errors as 404s without a deliberate access-disclosure policy.
SITE-09	Page identity and navigation: all full sites	Accurate page titles, document language, meaningful headings, navigation/current-location cues, and supplied site identity assets. For indexable public pages, add appropriate descriptions and intended canonical URLs.	Test direct loads, reloads, deep links, back/forward, internal links, and titles after navigation. Do not index private content; robots directives are not access control.
SITE-10	Additional policies and help: business-dependent	Implement applicable terms, refunds/returns/shipping, subscription cancellation, account recovery/deletion, accessibility/help, or jurisdiction-specific business disclosures when the service needs them. Reuse accurate existing policies.	Map each item to an actual business feature or applicable requirement. Verify destinations and promised workflows; obtain missing factual terms instead of inventing them.

PRIV-01 — Truthful privacy information (MUST when applicable)

Establish the operator/controller and privacy contact, what data is collected, purposes and legal bases, recipients, retention periods or criteria, relevant international transfers, and applicable rights and complaint routes. Address indirect collection or automated decisions where used. Inform people at collection and link the full notice. Use clear language for the audience.

Use verified operational facts and supplied policy decisions; an agent must not invent a lawful basis, retention promise, jurisdiction, or legal entity. If these facts are missing, prepare a clearly identified draft and list the missing inputs. Do not mark policy content ready to publish until resolved. A privacy page and banner do not establish legal compliance by themselves.

Source: EDPB guidance on transparency and individual rights. Check current applicable requirements for the actual operator and audience; this is a content and implementation checklist, not a universal policy text.

CONSENT-01 — Consent that controls behavior (MUST where required)

Cookie and similar-technology rules arise from applicable ePrivacy/national rules as well as GDPR where personal data is processed. Determine applicability from the technology, purpose, and jurisdiction; do not assume every site needs a banner or that a technology called "analytics" is automatically exempt.

This skill uses the following implementation defaults for consent-required use:

• Block consent-required scripts, embeds, pixels, requests, and storage until the relevant affirmative choice. Cover tag managers and indirect loaders.
• Offer equally accessible Accept all, Reject nonessential, and Preferences controls in the initial interface. No preselected optional purposes, implied consent from scrolling/dismissal, or visually suppressed refusal.
• Explain purposes/providers and distinguish necessary use from optional use. Enable only selected purposes, and persist the choice with a policy/config version and appropriate lifetime. Use the minimum consent record needed.
• Provide a persistent Cookie preferences link. Withdrawal stops future consent-required activity and clears controlled optional storage where possible; handle already-loaded integrations and reload if needed. Do not imply withdrawal reverses earlier disclosures to third parties.
• If consent storage or the consent manager fails, leave optional activity off while keeping core content usable. Reconcile expired choices and changed purposes before enabling affected integrations.

Verify fresh visit, reject, selective accept, accept all, reload, withdrawal, expired/changed preference, and unavailable storage. Inspect network activity and storage, not just the controls. Check keyboard operation and narrow layouts. If there is no consent-required use, record that finding; do not add tracking or an unnecessary consent interruption just to satisfy a checklist.

Sources: CNIL cookie guidance, CNIL implementation guidance, CNIL consent guidance. The defaults above are engineering choices supporting consent; validate jurisdiction-specific details against current regulator guidance.

YEAR-01 — Shared dynamic copyright (MUST for current copyright notices)

Derive the current year from a shared date source/component and use it in the footer and every other current copyright notice, including shared layouts and generated templates in scope. Never scatter hard-coded current-year strings. Use the actual rights-holder name. Include a start-year range only when that start year is verified; render one year when start and current years match.

Choose an update mechanism appropriate to the stack: request-time rendering, client refresh with consistent initial hydration, or automatic static rebuild and cache refresh across the year boundary. A build-time date without a rollover/update mechanism can become stale. Ensure a readable fallback in the supported no-JavaScript experience and avoid server/client timezone mismatch.

Check December 31 and January 1 with a controlled clock, including cached/static output and each shared placement. State the timezone used. Do not change real publication dates, policy effective/review dates, historical notices, or third-party attribution years just because the calendar changed.