bug: netlify - Publish missing static metadata #5

Describe the bug

The supplied audit reports production 404s for robots.txt, sitemap.xml and manifest.json. They were located under src/app/public/, outside Vite’s active root public/ directory.

PR #344 adds the three files at the active location. Source originals remain. Build and local-preview evidence is now recorded; hosted-preview and production acceptance remain outstanding.

To Reproduce

1. Inspect the source and active public directories.
2. Run npm run build and inspect dist/ for all three documents.
3. Request each metadata endpoint on preview and production.
4. Record status, content type and body; check for SPA fallback HTML.

The original audit reported production 404s. The 18 October verification report subsequently records production 404s for the crawler files and HTML instead of the manifest; a fresh deployment audit is still required.

Expected behavior

All three endpoints serve the intended metadata documents with appropriate content types. Canonical URLs and referenced resources are valid.

Screenshots

See the supplied audit; no additional screenshot supplied.

WordPress Environment

Not applicable: React/Vite static site on Netlify.

Device and Browser Info

The original audit used curl. No browser or Lighthouse verification evidence supplied.

Additional Context

Current PR head: 80fb295. The three metadata files now use the canonical book-site domain and branding. service-worker.js remains untouched; PWA integration requires a separate decision.

The committed verification report records a successful production build, 12 passing Bats checks and correct local-preview responses for all three files. This does not establish hosted deployment success.

Required follow-up

• Rebase the PR branch onto the latest develop, as requested, before treating the work as ready.
• Audit the resulting head again: changed-file scope, CI/check failures, review state, build output and hosted-preview/production responses.
• Record the rebased revision and fresh results before closure.

The PR already targets develop, but its head lacks the latest develop commit 4ecdb26. The reported origin from main is not verified; recovered history shows the first PR commit directly follows earlier develop commit 243c867. No rebase has been performed.

Acceptance criteria

• Add all three metadata files to Vite’s active public directory.
• Leave the service worker outside this change.
• Metadata contents, canonical URLs and referenced resources reviewed in the committed verification report.
• All three files demonstrated in production build output in the committed verification report.
• Verify preview response bodies and content types, without SPA fallback HTML.
• Confirm production endpoints after deployment.

Linked Stories/Tasks/PRs

Implementation: PR #344, retaining its existing closing link.

The earlier comparator, CI-reporter/labelling edits and broad changelog cleanup were removed from the current net diff. Comparator findings in the earlier review are resolved/outdated. Current checks still fail for the missing comparator helper, labelling clone command and changelog check publication; these require a fresh audit after rebasing.

Milestones & Timeline

Existing estimate L; no deadline or milestone requested.

Definition of Ready (DoR)

• Reported symptoms and expected behaviour documented.
• Reproduction procedure and environment documented.
• Audit and implementation PR linked.
• Production metadata failure reproduced in the 18 October verification report; fresh deployment verification remains outstanding.

Definition of Done (DoD)

• Metadata implementation committed in the linked PR.
• CHANGELOG.md entry prepared; content validation reports no failures, although check publication fails.
• All acceptance criteria demonstrated.
• Relevant PR findings resolved and approval obtained.
• PR merged and deployment verified before closure.
• Branch deleted after merge.

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom.
• Implementing target: this metadata issue, synced with GitHub issue 5. No parent epic identified.
• Allowed closing targets: none newly approved. Preserve the existing GitHub closing reference in fix: netlify - Publish static metadata and repair CI checks #344; it does not establish completion. Native Linear association is not established by that reference.
• Branch state: unresolved; neither existing branch recommended for reuse until delivery scope is agreed.
• Branch: PR 344 uses fix/static-metadata-changelog-consolidation, head ec7477ae5ad1d1a3f8980b9f299618e0ebb3525f. Competing fix: netlify - Publish missing static metadata #342 uses fix/static-metadata-public-directory, head 89ef4175c64e201d295203692714525298a606d2. Do not rename either or create a third branch.
• Base: both target develop, checked at 4ecdb26d9655a48bf000a7c89da2f70383edce87. Earlier rebase-pending wording is not a current audit.
• Naming policy: local guide/validator at the checked develop revision and organisation strategy at 8f28eca80bff198879f7aaf496717dc0551bb32e; fix/ fits the publication defect, not docs/.
• PR template: shared organisation bug template, consistent with checked routing. Routing suggestions do not establish automatic template loading.
• Evidence conflict: PR 344’s current seven-file diff retains ancillary comparator/CI changes and substantial changelog deletion. Crawler files reference ashshaw.com; the manifest retains makeup branding. The previously claimed verification report was unavailable at this head. Returned checks contain no failures, but do not establish correct content, approved scope, review approval or deployment acceptance.
• Constraints: no automatic reuse, rename, rebase, force-push, merge, deployment, closing-link change or CI repair.

Expected file changes

Provisional plan, conditional on delivery-PR selection and exact-content approval. Existing paths verified at PR 344 head ec7477ae5ad1d1a3f8980b9f299618e0ebb3525f; existence is not edit approval.

Coverage and verification-report paths remain unresolved; no new paths, moves or deletions proposed. Original metadata copies, service-worker integration, application routes and generated output remain excluded. Ancillary CI/comparator scope and protected CHANGELOG.md deletion require separate decisions. Centrally managed workflows are not routine agent-edit targets. Hosted-preview and production bodies/content types remain acceptance gates.

Unanswered clarification questions

These questions clarify delivery and acceptance evidence. Historical build, branch and review statements are not assumed to describe the current revision.

1. Which PR and head revision are the intended delivery source?
2. What fresh changed-file, CI and review evidence resolves the conflicting recorded scope and branch statements?
3. What canonical site origin and manifest identity are approved?
4. What hosted-preview and production evidence confirms the intended metadata files have correct bodies and content types rather than SPA fallback responses?
5. Who accepts the metadata content and deployed verification evidence before closure?