docs planning STATIC_LANDING_PLAN

P25 — Static abastevo landing page

State: PLANNED, specification revision 2 (2026-10-05). Publication scope: LOCAL_ONLY. Authority: maintainer requested a separate phase for a professional, attractive, simple landing page, restrained calls to action, professional SEO, a GitHub link and a Play Store link after the app is published. Stack confirmed by the maintainer: static HTML, static CSS and plain TypeScript 7.0.2 compiled to JavaScript. Revision 2 incorporates the maintainer-requested review of revision 1 (legal destinations, owner decisions, hosting, icons/social/headers, visual contract, content, verification tooling and delivery cost); it changes the specification only.

This document owns the landing specification; ROADMAP owns task IDs. PROGRESS owns execution state. Planning does not implement the site, open remote issues/PRs, publish a wiki, deploy a website or release the app/backend.

Scope and entry

P25 is an independent website workstream outside the Android/backend release chain. Existing G09-LOCAL integration satisfies the inherited integration-first boundary. P25 can be implemented locally without waiting for G09 certification or Play Store availability. It neither blocks nor accepts G09, P10-T09, G24 or historical G18; iOS remains deferred. Public app/pilot availability claims follow their actual owning release evidence.

Use codex/phase-25-static-landing-plan for this local planning change. Future authorized implementation uses one phase branch codex/phase-25-static-landing and sequential P25-T01–T05 tasks under DELIVERY_WORKFLOW. Create milestone/issues/draft PR only when delivery is authorized; use a worktree if another effort occupies the checkout. No dates, traffic, ranking, budget costs or remote identifiers are invented.

Expected implementation areas: landing/, bounded landing selection/checks in scripts/quick-verify.sh and its existing gate-selection tests, a scoped CI integration if needed, and landing evidence/docs. Existing mobile/backend modules, com.anpfuel, applied migrations and MIT notices are preserved. No API, database, account, geolocation, analytics, payment, form service, CMS or new backend is needed.

Delivery shape and cost control. The default is landing/ inside this repository under the existing quick-verification gate with path-based selection; unknown paths remain refused. A separate landing repository (as the Zaflas reference uses) is a documented alternative that requires an explicit maintainer request and its own plan; it is not assumed. To avoid ceremony out of proportion to a small site: T01 is one short contract document and no code; the <head> metadata skeleton lands in T02 so T04 completes and validates it rather than introducing it; there is one specialized exit check and one finish run per phase.

Owner decisions and prerequisites

These inputs are pending and not invented. Each has a need-by point; none blocks local implementation unless stated.

ID	Decision / input	Why it matters	Need by
D-L01	Repository identity — RESOLVED 2026-10-05 by observation (see contract): the old name redirects (HTTP 301) to the public MIT repository AlexandreZanata/abastevo, which is the canonical GitHub destination. The local origin still uses the old name (works through the redirect).	One consistent name across README, site links, JSON-LD sameAs, store listing and brand search.	Done; the repository website field is set at publication.
D-L02	Canonical domain. Maintainer selects one stable HTTPS origin (a Brazilian .com.br is a natural candidate). Name/trademark availability is checked by the owner; this plan makes no availability claim.	Canonical, og:url, sitemap, JSON-LD IDs, redirects.	Public-artifact acceptance and publication. Local previews use explicit nonpublic configuration.
D-L03	Static host. See Hosting and response policy.	Response headers, redirects, real 404, preview noindex, cache.	T01 records the criteria; the choice is needed before publication.
D-L04	Public contact channel (role mailbox or the repository issue tracker) for privacy, deletion and security reports. No personal mailbox is assumed.	Required by the legal destinations (B-BR-L07) and security.txt.	Before the legal pages are accepted.
D-L05	Wireframe and token approval — RESOLVED 2026-10-05: wireframes and tokens reviewed and approved by maintainer.	“Beautiful” must be agreed before it is built.	Done (T01).
D-L06	Delivery shape (see Scope and entry). Default: landing/ in this repository.	Gate selection and CI scope.	T01.
D-L07	Crawler policy for AI/LLM crawlers and optional llms.txt. Normal search crawlers stay allowed. Default direction for an open, free project: allow reading/citation; the final choice is recorded.	robots.txt content and optional discovery file.	T04.
D-L08	Store listing details (public URL, package identity) after app publication.	Replaces the prelaunch notice (B-BR-L03).	Follow-up task, not P25 acceptance.

Product rules before behavior

• B-BR-L01 — Truthful product presentation: use the approved lowercase abastevo name and existing brand. Describe demonstrated features with their limitations. Community observations and dated ANP references remain distinct; never imply ANP affiliation, guaranteed current prices, coverage everywhere, automatic trusted publication, guaranteed savings or production certification. Label future capability explicitly.
• B-BR-L02 — Restrained navigation: present one clear product explanation and ordinary links. No urgency/countdown, popup, signup wall, notification request, autoplay, repeated purchase/download banners or sticky conversion bar. A visitor can understand the project without taking an action.
• B-BR-L03 — Honest store state: before a verified public listing, show plain text “Em breve na Google Play”; no disabled/fake download link, invented release date or unofficial APK fallback. After the maintainer supplies the public listing, verify its app/package identity and replace the notice with one normal “Ver na Google Play” link or the official badge (single placement). Preserve com.anpfuel; do not derive or publish an unverified store URL from the package alone.
• B-BR-L04 — Essential content is static: product copy, headings, GitHub/store links, legal/help destinations and SEO metadata exist in delivered HTML. With JavaScript disabled or failing, the page remains usable and links still work. TypeScript only enhances optional interactions; it does not fetch or inject essential content.
• B-BR-L05 — Evidence-based SEO: publish accurate visible content and consistent metadata. Never copy another organization's identity, rating, review count, testimonials, social profiles or availability. Structured data cannot contain unverified facts. SEO acceptance means a technically prepared site, not a promised Google position or indexation date.
• B-BR-L06 — Minimal data surface: no cookies, third-party trackers, remote font calls, location collection or visitor accounts in this phase. Any privacy/help text describes actual behavior and links to maintained project material; do not present a draft policy as legally approved. Hosting access logs are reviewed when hosting is selected.
• B-BR-L07 — Required public legal and help destinations: the site publishes, as static pages reachable from the footer, a privacy page (/privacidade/), an account/data deletion request page (/excluir-conta/), community terms (/termos/) and the contact channel from D-L04. Content is derived from the maintained security/privacy plan, location/media policy, free account access and community moderation; it states the actual current behavior, retention and rights workflow and marks not-yet-shipped features as such. The wording difference between the README/media policy (all photo copies within 24 hours) and the older 14-day sanitized-evidence line is resolved in the T01 contract: the media policy supersedes it, and public wording is labelled as project policy until release evidence exists. A Google Play listing for an app with accounts and user-generated content is expected to need a privacy-policy URL, a web deletion destination and a data-safety declaration; T01 verifies the current Play Console policy text, records source and date, and repeats the check at listing time. The plan does not assert current policy wording. Pages are not presented as legally approved.

Use cases:

• BUC-L01: a visitor opens /, understands what abastevo does, reads how community and ANP sources differ, and finds the project links without registering or granting permissions.
• BUC-L02: a visitor opens the confirmed GitHub repository from an ordinary HTML link, using keyboard or touch, with JavaScript enabled or disabled.
• BUC-L03: a visitor sees the honest prelaunch notice; after an authorized listing update, the same section leads to the verified public Play Store app. Missing/invalid configuration keeps the prelaunch state; it never produces an empty or unsafe link.
• BUC-L04: a crawler or link-preview client receives the page copy, canonical URL, description, social metadata and factual JSON-LD in the initial HTML response, without executing JavaScript.
• BUC-L05: a visitor or store reviewer opens privacy, deletion and terms pages from the footer without JavaScript, reads the current behavior in plain language and finds the contact channel.

Content and visual direction

Portuguese (Brazil) first, lang="pt-BR". Initial scope is the main landing page, the three legal/help pages required by B-BR-L07 and a static 404. Do not create a blog, city doorway pages, translation system or app dashboard for SEO alone. Optional later educational pages are described under Later content phase.

Recommended section order:

1. Compact header: approved logo/name and at most three anchors, such as “Como funciona”, “O projeto” and “Aplicativo”. Navigation remains visible or uses a native accessible pattern without depending on JS.
2. Calm introduction: one H1 and a short paragraph explaining the product. Initial copy direction: “abastevo: preços de combustíveis com a comunidade”. Explain community contributions and dated ANP reference underneath, with availability wording matched to release evidence. Show “Ver no GitHub” as an ordinary link; a store link appears only in the published state.
3. Illustrative source comparison (the product differentiator): a static HTML/CSS card pair, for example “Comunidade — observado há algumas horas” beside “Referência ANP — semana de pesquisa”, showing source, date and condition. It is labelled “Exemplo ilustrativo com dados fictícios”, contains no real station or price, is not a functional widget and exposes a text alternative that states it is illustrative.
4. “Como funciona”: three short steps for consulting available information, checking source/date/condition, and contributing through the app when available. These are explanations, not functional website widgets.
5. “Para quem é” (include only if copy is verified): three short profiles such as private driver, ride-app driver and small fleet operator. Factual wording, no savings promise (B-BR-L01).
6. “O projeto”: transparent source distinction, free community participation, a link to source code and a “Privacidade em resumo” block of short statements matched to the legal pages (browsing without account or GPS, limited photo retention as stated by the reconciled policy, no trackers on this website, open source). No invented user counts, price samples, partner logos or testimonials. If an app image helps, use a real screenshot from a verified revision with synthetic data and a clear illustrative caption; otherwise use approved brand artwork and the comparison card.
7. “Aplicativo”, “Acompanhe o projeto” and brief questions: Android/store state, project status, source/freshness and contribution basics. Following the project needs no signup: ordinary links to the repository, its releases page and the repository releases Atom feed (verify the feed URL for the confirmed repository). The page collects no email. Native <details> is sufficient for optional FAQ disclosure; no FAQ rich-result promise. FAQ questions follow real search intent where the product supports the answer, for example how to find a station's fuel price, what the ANP weekly survey is, the difference between a community observation and an ANP reference, and (only if the app's calculator behaves as described) how to compare ethanol and gasoline. Answers cite official sources where used and never promise “cheapest near me”.
8. Quiet footer: GitHub, privacy, account deletion, terms, contact, source attribution (ANP data with a link to the official source), “Código aberto sob licença MIT”, “Não afiliado à ANP”, and trademark references (TRADEMARKS). When the listing exists, include the attribution required by Google's brand guidelines (to be copied from the guideline current at that time).

Visual direction: white/light surfaces, existing blue/green mark, dark readable text, generous whitespace, consistent spacing and a restrained type scale. Reuse the abastevo palette/identity rather than Zaflas colors. Start with system fonts; if a brand typeface is later approved, self-host a Latin-subset WOFF2 with font-display: swap and never call remote font services. One column on small screens and modest content width on desktop. Avoid giant photographic hero backgrounds, carousels, excessive cards, decorative motion and a theme switch unless evidence of need changes the scope.

Visual contract (T01 output, D-L05). Before coding, produce low-fidelity wireframes for 375 and 1280 CSS pixels (static artifact reviewed by the maintainer) and a frozen token set: palette with measured contrast ratios against their backgrounds, type scale, spacing scale, radii and minimal shadows. Implementation follows the approved tokens; changes go back through this contract. Automatic dark appearance through prefers-color-scheme (no switch) is deferred: the approved wordmark is navy and no dark-background logo variant exists, so P25 ships a light scheme only (T01 contract).

Finishing details: scroll-margin-top on in-page anchors, smooth scrolling only without a reduced-motion preference, a simple print stylesheet, visible high-contrast focus ring and touch targets of at least 44 CSS pixels where feasible.

Acceptance includes 320, 375, 768, 1024 and 1440 CSS-pixel widths; 200% zoom; readable text without horizontal overflow; visible keyboard focus; skip link; logical landmarks/headings; descriptive link text/alt text; WCAG AA contrast targets; sufficient touch targets; and reduced-motion preferences. One H1 is a readability/accessibility convention, not a claimed ranking shortcut. Actual visual/browser evidence is collected during implementation, with manual browser review in the final owed manual batch if the existing user directive still applies; no Android emulator/device run is introduced here.

Static architecture and toolchain

Proposed layout, not existing implementation:

landing/
  static/index.html
  static/privacidade/index.html
  static/excluir-conta/index.html
  static/termos/index.html
  static/404.html
  static/robots.txt
  static/sitemap.xml
  static/llms.txt                 # optional, D-L07
  static/.well-known/security.txt # needs D-L04
  static/site.webmanifest
  static/assets/styles.css
  static/assets/brand/...         # favicon set, app icons, social image
  static/_headers, _redirects     # or host-equivalent; see Hosting
  src/main.ts
  tsconfig.json
  package.json
  package-lock.json
  scripts/build.mjs
  scripts/check.mjs
  tests/...
  README.md
  dist/                 # ignored generated deploy artifact

Use ordinary handwritten HTML/CSS and browser DOM APIs. Compile TS locally to an ES module loaded with type="module"; JSON-LD uses its own static application/ld+json script. No React, Astro, Svelte, Tailwind, component framework, runtime library or bundler is needed. Node/npm is build/check tooling only; the published site is files served by any suitable static host. Do not import the reference repository's admin server, framework or deployment configuration.

TypeScript 7.0.2 is confirmed by the maintainer and its official release was verified on 2026-10-05. At P25-T02, verify the actual registry package/artifact, binary name, supported tsconfig options and defaults (they may differ from 5.x examples), pin the exact version without a range, commit the lockfile, select and record a supported Node version, and prove compiler output. Record dependency need, MIT license and scoped security review; no dependency is installed by this plan. If the exact version is unavailable in the execution environment, record the failure and resolve it before accepting T02; do not silently substitute a version.

Compiler settings: strict typing, DOM types, explicit module/target selection for the frozen browser support, noEmitOnError, root src/ and generated output under dist/assets/. A minimal build copies authored static files and compiles TS; any necessary host-specific URL substitution happens at build time with missing/invalid-value checks. Essential HTML is never client-rendered. dist/ contains no TS sources, server code, private configuration or source maps by default; building twice from the same inputs yields the same artifact. Set store state in authored/build-time static content and verify every affected visible/metadata location together. The build fingerprints CSS, JS and image file names with a content hash and rewrites references, so long-lived immutable caching is safe while HTML stays short-lived.

Use of TypeScript. TypeScript is a requirement of the stack, and every use must remain an optional enhancement. Candidate interactions, each independently testable and harmless without JS: highlight the active in-page section in the header (IntersectionObserver, respecting reduced motion); a “copy repository link” helper with a plain-link fallback; an unobtrusive “back to top”. Select only those the approved wireframe needs. Build/check scripts may also be authored in TypeScript and compiled by the same toolchain if that keeps the toolchain single.

GitHub destination: https://github.com/AlexandreZanata/abastevo (D-L01 resolved; the previous repository name redirects to it). Open links in the same tab by default; if a new tab is chosen, communicate that behavior and use rel="noopener noreferrer". Store URL, final domain and hosting provider are pending owner inputs (D-L02, D-L03, D-L08), required only for their respective activation/publication steps. Existing test/staging endpoints are not assumed to be the landing's canonical address.

Hosting and response policy

The plan is host-neutral at the artifact level but the host determines what the site can enforce. Selection criteria, to be recorded in T01 and verified against each provider's current documentation at selection time (not asserted here): custom response headers (security headers, X-Robots-Tag for previews, per-path cache), redirects (HTTP→HTTPS, www→apex, trailing-slash policy), a real 404 status, automatic HTTPS, preview deployments, access-log/privacy posture, cost/limits and rollback to a previous immutable artifact.

Option	Direction
Static-site hosts with file-based _headers/_redirects style configuration (for example Cloudflare Pages or Netlify)	Preferred direction: meets the criteria without running a server. Verify the configuration syntax and limits at selection.
GitHub Pages	Simple and free, but custom response headers are not configurable as far as known; if chosen, verify the limitation and compensate with in-document metadata only, accepting weaker header coverage.
Self-managed server (Caddy, as in the reference)	Maximum control, ongoing maintenance and operations cost; only on explicit maintainer choice.

Header baseline for the chosen host (adapted from the reference's _headers, without copying its project-specific rules): X-Content-Type-Options: nosniff; Referrer-Policy: strict-origin-when-cross-origin; Permissions-Policy denying camera, microphone and geolocation (the site uses none); a strict Content-Security-Policy with default-src 'self' and no inline executable script (an application/ld+json block is data, not executed script); Strict-Transport-Security only after stable HTTPS is verified, with preload omitted unless consciously decided because it is hard to reverse; long immutable cache for fingerprinted assets and short revalidated cache for HTML. Preview deployments send noindex through the host or the HTML.

Reference review and SEO adaptation

Read-only reference: /home/iiii/ZAFLAS/zaflas-landing/, local HEAD 5216ebc75f3c5e72b4cbc17a0882ae2a22f645fa, inspected 2026-10-05. Observed source behavior, not a completed runtime audit or evidence of Google's ranking:

• src/components/seo/SeoHead.astro and src/lib/seo/meta.ts: consistent titles/descriptions, canonical absolute URLs, Open Graph/Twitter image metadata, theme-color, locale tags and optional image preload. Adapt the metadata contract into static HTML. Only prioritize a real above-the-fold image when needed; preload is not mandatory.
• astro.config.mjs and public/robots.txt: static output, sitemap discovery, language routes, excluded admin/API paths and explicit rules for AI crawlers. Adapt a small static sitemap and environment-specific indexing. There are no landing admin/API routes to exclude. Omit hreflang until real translated pages exist. Crawler rules follow D-L07.
• src/lib/seo/jsonld/* and tests/seo/jsonld.test.ts: structured entity IDs, graph relationships and automated assertions. Adapt factual JSON-LD and tests against emitted HTML. The reference software node includes a rating/count and an offer; its test asserts their presence, which does not establish provenance. These values are not transferable to abastevo.
• src/styles/tokens.css, src/components/pages/HomePage.astro and HeroSection.astro: spacing tokens, readable hierarchy, responsive imagery and section composition. Adapt the principles with the existing abastevo identity and a smaller page; the reference's broad hero, marketing sections and multiple CTAs are not required by this brief.
• public/_headers, public/site.webmanifest, favicon/app-icon set, public/llms.txt and deploy/Caddyfile: security/cache headers, install metadata, icon sizes, an LLM-oriented summary and apex/www redirect. Adapt the ideas per the sections above. Do not copy Zaflas-specific redirects, Markdown content negotiation, admin proxying or its content signal wording without an explicit decision.

Technical SEO acceptance:

1. Accurate unique title/description (title about 60 characters, description about 155, checked in the artifact test), one descriptive H1, semantic sections and meaningful crawlable <a href> links. Suggested title direction: “abastevo | Preços de combustíveis com a comunidade”; final copy follows T01 evidence. No meta keywords, keyword stuffing, fake coverage pages or copied marketing text.
2. Confirm one HTTPS canonical origin and trailing-slash policy before a public build. Align canonical, og:url, sitemap entries and JSON-LD IDs. Redirect equivalent host/HTTP variants at the selected host; serve a real 404 (helpful text and links to the home page and repository) rather than a universal 200. Local previews may use nonpublic configuration and must never ship placeholder URLs.
3. Production robots.txt exposes the actual sitemap and allows required HTML/CSS/JS/images. Sitemap lists only canonical indexable 200 pages (home, privacy, deletion, terms); omit fabricated lastmod. Preview HTML uses noindex (or host X-Robots-Tag) while remaining crawlable enough to see the directive; robots.txt blocking alone is neither a deindexing guarantee nor privacy protection. Public-build checks reject accidental noindex, staging URLs and placeholders.
4. Accurate Open Graph/Twitter title, description, absolute image URL and image alt text, og:locale pt_BR and twitter:card summary_large_image. The social image is owned/approved artwork of 1200×630 pixels, lightweight (target ≤300 KB), with a versioned file name so link-preview caches refresh. Preview rendering is checked for WhatsApp and Telegram (the dominant sharing channels in Brazil) as an owed manual observation; previews improve sharing, not rankings.
5. Icons and install metadata: SVG and ICO favicons, 180 px Apple touch icon, 192/512 px Android icons, site.webmanifest, and theme-color, generated from the approved brand assets under docs/assets/brand/ and recorded with their provenance. No new brand artwork is invented.
6. Begin with factual WebSite/WebPage/brand information. Add sameAs only for real profiles (the confirmed GitHub repository now; the store listing and social profiles when they exist). Add organization/person identity only when confirmed. Android MobileApplication/SoftwareApplication metadata may be added in the published state when supported by visible, verified facts, including the real listing; omit unknown offers/ratings/reviews. BreadcrumbList only if internal pages benefit. Missing evidence means no claim of software rich-result eligibility. FAQ is for visitors and has no rich-result acceptance requirement.
7. Optimize assets, reserve image dimensions, lazily load below-the-fold images and avoid third-party calls. Proposed project budgets, measured on the built page: compressed CSS ≤25 KiB, compressed JS ≤10 KiB, initial page transfer ≤500 KiB (including initially requested images). Mobile lab target: Lighthouse Performance ≥95 and Accessibility/Best Practices/SEO ≥95, with zero known serious accessibility defects. Freeze the tool version, viewport, throttling and report method before measuring; scores alone do not prove usability or indexation.
8. Target good Core Web Vitals: LCP ≤2.5s, INP ≤200ms and CLS ≤0.1 at the 75th percentile when field data exists. Use lab measurements diagnostically; Lighthouse TBT is not field INP. A new site without sufficient traffic has field evidence PENDING, not a fabricated pass.
9. Optional discovery files: llms.txt (short, factual and generated from the same approved copy) and /.well-known/security.txt with the D-L04 contact. Neither is a ranking factor; omit either if its prerequisite decision is missing.

Google sources checked 2026-10-05: SEO Starter Guide, canonical URLs, software app structured data, Core Web Vitals. These support discoverability and quality; they do not guarantee indexation, rich results or a search position.

Positioning strategy: clearly answer searches for “abastevo”, “aplicativo de preços de combustíveis” and “preços de combustíveis com a comunidade” in natural Portuguese copy. These are initial intent hypotheses, not measured keyword-volume research. Build consistency between the real GitHub project, site and future store listing (D-L01). Publish useful original explanations of source, date, coverage and price conditions, including the FAQ intents listed above. Do not promise “combustível mais barato perto de mim” without demonstrated location/coverage behavior. No purchased backlinks or mass-produced pages.

Legitimate discoverability actions, performed only at publication under explicit authorization: link the site from the repository README and set the repository website field; fill the website field in the Play listing; register the site in Google Search Console and Bing Webmaster Tools (importing from Search Console is sufficient); announce through relevant developer/Android communities in ordinary posts. Each is recorded as done/not done, never assumed.

Later content phase (NOT AUTHORIZED)

If, after publication, Search Console shows demand for educational queries, a separate phase may add three to five original evergreen guides (for example how the ANP weekly survey works, how to compare ethanol and gasoline with the calculation explained, and how to read a price's date/source/condition) linking discreetly to the app and repository. This requires its own explicit maintainer request and plan, no city doorway pages, no blog scaffolding and no generated mass content. It is not part of P25 acceptance.

Verification tooling

Baseline: Node's built-in test runner and assert for emitted-artifact contracts (static content without JS, links, metadata, JSON-LD, sitemap, robots, store states, indexing modes, fingerprinted references, headers file). Candidate development-only tools, each requiring recorded need, license and scoped security review at T02 before installation, and chosen minimally: an HTML validator, an accessibility engine for the built pages, an internal/external link checker, and the Lighthouse command line pinned to a recorded version. No tool is installed by this plan, and no result is claimed.

Sequential tasks and validation contract

All commands below under landing/ are planned interfaces, to be implemented and documented in P25-T02 before they can count as evidence. No script, browser run or check is claimed to exist/pass now. Prefer built-in Node test and assert facilities for emitted-artifact contracts; browser/lab tools, if needed, are dev-only and require the same need/license/security review.

• P25-T01 — Content, visual and decision contract (output: LANDING_CONTENT_CONTRACT and wireframes): one short document freezing B-BR-L01–L07/BUC-L01–L05, copy, section order, page inventory (home, privacy, deletion, terms, 404), verified-feature inventory, identity assets, both store states, the D-L01–D-L08 status, hosting criteria, the current Google Play policy check for legal destinations (source and date), the retention-wording reconciliation, and the approved 375/1280 wireframes and design tokens with contrast ratios. Record final-domain/hosting/listing inputs as pending where appropriate. Review links/claims against the current product/release evidence. Risk: docs. Output: bounded contract linked from the landing plan; no code.
• P25-T02 — Static foundation and reproducible compilation: create authored HTML (including the full <head> metadata skeleton and the page inventory), static CSS baseline, plain TS toolchain, build with content-hash fingerprinting, header/redirect source files for the selected host, and artifact checks. Include negative tests for missing/invalid public origin and store state/URL (HTTPS, expected play.google.com/store/apps/details route and confirmed package). Prove GitHub/store anchors, legal links and main copy exist without JS. Select the verification tooling with its review. Extend the existing unknown-path-refusing quick selection for landing/ with real landing checks and its selection regression tests; no docs-only classification for executable website assets. Ensure required Quick verification remains present. Risk: standard. Commands to implement: npm --prefix landing ci, npm --prefix landing run typecheck, npm --prefix landing run build, npm --prefix landing run check, npm --prefix landing test; use bash scripts/tests/test-gate-selection.sh for affected selection behavior after confirming its interface at task opening.
• P25-T03 — Visual polish, legal pages and progressive enhancement: implement responsive static CSS from the approved tokens with approved brand assets, the illustrative source comparison, privacy summary and follow-the-project links, the legal/help pages with reconciled wording, restrained interactions and accessible native patterns. Use TS only for the selected optional interactions; if none is needed, keep browser JS minimal. Validate supported browsers, responsive widths, keyboard/zoom/reduced-motion and JS failure. Add meaningful interaction regression tests only for introduced behavior; collect owed manual observations honestly. Risk: standard. Run T02 compile/build/check and affected tests, plus the documented scoped browser checks.
• P25-T04 — SEO, icons and indexing contracts: complete and validate initial-response metadata, factual JSON-LD, canonical/sitemap/robots/preview modes, icon set and manifest, versioned 1200×630 social image, security/cache headers, crawler policy (D-L07) and optional llms.txt/security.txt. Artifact tests cover malformed JSON-LD, mismatched origins, duplicate IDs, phantom store/rating claims, placeholders, broken local resources, wrong noindex state, title/description length bounds and header-file expectations. Validate generated HTML/XML and public artifact completeness. Use official schema validation without treating a missing unsupported rich-result type as a defect. Risk: standard. Run T02 checks plus scoped metadata/indexing tests against both prelaunch and published-state fixtures; synthetic fixtures prove rendering only, not a real store release.
• P25-T05 — Acceptance and publication handoff: validate final built artifact, performance budgets, browser/accessibility evidence and all BUC/store-state cases. Record exact revision, tools/configuration, results and outstanding field/manual/publication evidence (including WhatsApp/Telegram preview observation) in docs/release-evidence/p25-static-landing.md (future file). Prepare a static hosting, origin/redirect/cache/404/indexing and rollback runbook in landing/README.md, including the publication-time discoverability checklist and the store-activation steps (listing verification, single link/badge, attribution, JSON-LD, sitemap and Search Console resubmission); restore a prior immutable artifact to roll back. Risk: standard, with deployment kept separate. Public domain/hosting access and a verified artifact become prerequisites only for an explicitly authorized publication. No cloud service or hosting runtime is added merely to close local acceptance.

Per task: affected checks, git diff --check, scoped secret/private-data review, concise PROGRESS entry and an atomic task commit when authorized. The current docs-only planning change uses document/link/task checks only. Phase closure: specialized landing exit once, then the existing scripts/git-flow.sh finish --required "Quick verification" --pr <actual-number> interface once, only with authorized remote delivery and a real PR; verified head/base merge and separately scoped wiki snapshot. Never invent a PR number or bypass a missing landing/required check.

Exit and later activation

G25-STATIC-READY: T01–T05 acceptance demonstrated for a static artifact, truthful prelaunch state, legal destinations consistent with maintained policy and tested published-state rendering; manual evidence still owed under an active directive is recorded and prevents claiming full browser/usability acceptance. Distinguish LOCAL_DONE, INTEGRATED and WEBSITE_PUBLISHED. Real field metrics and Search Console remain pending until a public site produces evidence. This gate never certifies Android/backend production, deploys the site, proves Play policy compliance or proves Google ranking.

When website publication is explicitly authorized, select the actual static host and canonical domain, verify DNS/TLS/redirects/404/cache/headers and public indexing, and record the deployed artifact revision. Confirm the Search Console property, submit the real sitemap, inspect canonical/indexability and monitor impressions/clicks/queries when data appears. Search Console verification requires authorized owner access and is not a secret to place in general logs. Collect meaningful findings rather than declaring SEO complete from a lab score. No recurring automation is created by this plan.

When the app listing is supplied after publication, open a bounded follow-up task with its own acceptance and authorized delivery: verify app identity/public availability, update static links and availability copy/metadata together (single link or official badge, brand attribution, MobileApplication JSON-LD, sameAs, sitemap), re-check the current Play policy destinations, rerun affected checks, and publish the changed artifact only within the authorized scope. No polling, redirect service, backend coupling or site rebuild-on-every-app-run is needed.

Current local planning evidence: inspected clean main at b4754b21e4fd3c192ae69e6e42cfbac6fb0d5209, matching local origin/main; this includes merged P10 follow-up PR #105 beyond the earlier #104 current-state entry. No fetch/remote-state certification is inferred. Reference read-only; website implementation, dependency installation, browser acceptance and publication remain NOT RUN.

Planning validation: see the current PROGRESS entry for the latest document-check results of revision 2. No aggregate runtime/release gate is run for this documentation-only change.