fix(core): resolve false-positive review findings

.changeset/review-css-source-order.md

@@ -0,0 +1,5 @@
+---
+"@forkpoint/agent-lighthouse-core": patch
+---
+
+Preserve document order between linked stylesheets and inline style blocks when resolving CSS-hidden content.

.changeset/review-ghost-controls.md

@@ -0,0 +1,5 @@
+---
+"@forkpoint/agent-lighthouse-core": patch
+---
+
+Keep missing-role findings for decorative descendants and for inline handlers that stop propagation inside controls. An observing handler, such as an analytics call, stays part of its control. Roles resolve case-insensitively to the first recognized token, and gridcell and scrollbar wrappers count as holding a control.

.changeset/review-inline-visibility.md

@@ -0,0 +1,5 @@
+---
+"@forkpoint/agent-lighthouse-core": patch
+---
+
+Resolve inline display and visibility declaration order and !important before hiding answer spans or content. Invalid values are dropped as a browser drops them, a visibility:visible descendant of a visibility:hidden block counts as rendered for text fragments, and CSS-hidden ghost content uses the same resolver for inline markers and stylesheet display rules.

.changeset/review-lastmod-evidence.md

@@ -0,0 +1,5 @@
+---
+"@forkpoint/agent-lighthouse-core": patch
+---
+
+Do not fail corroborated recent content edits as build stamps. Require page-date disagreement before reporting that pattern. A deploy-time Last-Modified header no longer vouches for a recent run of stamps; those URLs are unverifiable and warn.

.changeset/review-unread-sitemap-children.md

@@ -0,0 +1,5 @@
+---
+"@forkpoint/agent-lighthouse-core": patch
+---
+
+Decline discovery coverage findings when an index has unread child sitemaps, including an empty partial read and a child that already failed as a root.

docs/evidence/audits/answer-readiness/text-fragment-addressability.md

@@ -122,6 +122,26 @@ flyouts or a search panel; `stripe-com-pricing` pass → fail, whose three
 FAQPage answers are only in `display:none` accordion panels. That last move
 corrects a false pass.
 
+### Inline declaration order (2026-10-06)
+
+The shared visibility helper resolves duplicate inline `display` and
+`visibility` declarations before deciding whether text is hidden. The last
+declaration at the winning `!important` priority wins. Thus
+`display:none;display:block` keeps an answer searchable, while an earlier
+`display:none!important` still hides it from a later plain declaration.
+This does not add stylesheet specificity or block-layout computation.
+
+A declaration with an invalid value is dropped, as a browser drops it, so
+`display:none;display:nonee` stays hidden. `visibility` inherits and a
+descendant can set it back: an answer with `visibility:visible` inside a
+`visibility:hidden` block is rendered, and find-in-page reaches it. The
+nearest element that declares `visibility` decides. `visibility:collapse`
+hides like `hidden`. `display:none` still hides everything under it.
+Each element is judged on its own chain, so a visible answer under a hidden
+wrapper stays addressable. A value with `var()` is valid when parsed and
+overrides an earlier declaration; its result is unknown here, so it never
+counts as hiding.
+
 ## Deferred
 
 - The headless variant — re-running the matcher against the post-JS DOM to catch

docs/evidence/audits/content-extraction/css-hidden-ghost-content.md

@@ -112,9 +112,22 @@ never ranked against each other. A collapsed panel hidden by
 counted, as the mechanism requires. An override inside a media query does not
 cancel a base rule, so parallel desktop and mobile copies stay counted.
 
-Source order is the gatherer's order: inline `<style>` blocks first, then
-linked same-origin sheets. A linked sheet placed before an inline block in the
-document is read after it.
+Source order follows the document: inline `<style>` blocks and linked
+same-origin sheets keep their relative positions. A later inline block can
+override an earlier linked sheet, and the reverse order works the same way.
+The five-sheet cap and the URL safety checks remain in force.
+
+### Inline markers use the shared resolver (2026-10-06)
+
+The inline check that skips text Readability already drops matched
+`display:none` anywhere in the `style` attribute. Readability reads the
+resolved style, so `display:none;display:block` is kept and its text is
+ingested. The audit now resolves inline declarations with the same helper as
+`dom-visibility.ts`: the last valid declaration at the winning `!important`
+priority wins, and an invalid value is dropped. Stylesheet `display` rules
+use the same helper, so an invalid later value no longer cancels an earlier
+`display:none`. A `var()` value is valid when parsed, so it does cancel one:
+`display:none; display:var(--layout, block)` is not counted as hidden.
 
 ## Deferred
 

docs/evidence/audits/machine-discovery/discovery-index-coverage.md

@@ -119,7 +119,7 @@ Content-page scans do not infer a mount. Origin files, origin probes, feed disco
 
 ### Partial sitemap reads decline the verdict (2026-10-06)
 
-The shared sitemap walk keeps at most 500 entries and reads at most 10 child sitemaps. When it stops early, a page missing from the entries it kept may still be listed in the part it skipped. The audit now returns `na` for that case instead of `fail` or `warn`. A page found in the partial read still passes, and a page missing from a complete read still fails.
+The shared sitemap walk keeps at most 500 entries and reads at most 10 child sitemaps. When it stops early, a page missing from the entries it kept may still be listed in the part it skipped. The audit now returns `na` for that case instead of `fail` or `warn`. Unread children of ordinary origin-level indexes also make coverage incomplete. This includes a failed fetch, malformed child, or nested index beyond the walk limit. The guard applies even when the readable portion contains no URLs. A child that already failed as a root, or under another index, still counts as unread when it is listed again. A page found in the partial read still passes, and a page missing from a complete read still fails.
 
 The trigger was a large retail site. Its index lists a 2455-URL product sitemap before a one-URL sitemap that holds the homepage. The product file filled the cap, and the audit failed the homepage as unindexed.
 

docs/evidence/audits/machine-discovery/sitemap-lastmod-verifiability.md

@@ -23,7 +23,7 @@ Cross-validates every sampled sitemap <lastmod> against three independent page-l
 
 ## Claimed mechanism (falsifiable)
 
-Google states it uses <lastmod> 'if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate'. lastmod is therefore a conditional signal, which engines silently discard on divergence. It is also the only freshness hint a pull-based AI crawler gets from a sitemap. Falsifiable claim: if sampled lastmod values disagree with all available page-level evidence (HTTP Last-Modified, JSON-LD dateModified, article:modified_time) for a material fraction of URLs, the sitemap's freshness channel is inert and re-crawl scheduling degrades to organic rediscovery. Two pathologies are specifically detectable. First, more than 90% of URLs share one identical lastmod equal to the last deploy date. That is a build stamp rather than a content date, and per Google's 'copyright date is not significant' rule it is exactly the disqualifying pattern. Second, a lastmod in the future relative to crawl time, which is always invalid.
+Google states it uses <lastmod> 'if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate'. lastmod is therefore a conditional signal, which engines silently discard on divergence. It is also the only freshness hint a pull-based AI crawler gets from a sitemap. Falsifiable claim: if sampled lastmod values disagree with all available page-level evidence (HTTP Last-Modified, JSON-LD dateModified, article:modified_time) for a material fraction of URLs, the sitemap's freshness channel is inert and re-crawl scheduling degrades to organic rediscovery. A recent cluster of lastmod values is consistent with a build stamp only when page dates also disagree. A batch of genuine edits can produce the same cluster. The distribution alone proves no defect. A lastmod in the future relative to crawl time is invalid.
 
 ## Evidence
 
@@ -38,7 +38,7 @@ Screaming Frog, Sitebulb, Semrush and Ahrefs surface lastmod presence and can fl
 
 ## Implementation sketch
 
-1. Fetch robots.txt Sitemap: directives plus /sitemap.xml, /sitemap_index.xml; recurse <sitemapindex> one level. 2) Validate each lastmod parses as W3C Datetime (YYYY-MM-DD or full RFC3339); count malformed. 3) Reservoir-sample 30-50 URLs across all child sitemaps. 4) For each: GET, capture the Last-Modified response header; parse all JSON-LD blocks for dateModified/datePublished; parse <meta property="article:modified_time"> and <meta name="last-modified">. 5) Per URL compute min absolute delta between sitemap lastmod and any available page signal. 6) Report: %future-dated (FAIL if >0), %malformed, distribution entropy of lastmod values (FAIL if the modal value covers >90% of sampled URLs AND that value is within 3 days of the crawl date), and %URLs whose delta exceeds 7 days against every available signal (FAIL if >20%). 7) Report separately the %URLs with no page-level signal at all — that is an actionable sub-finding (add dateModified to JSON-LD) rather than a lastmod failure.
+1. Fetch robots.txt Sitemap: directives plus /sitemap.xml, /sitemap_index.xml; recurse <sitemapindex> one level. 2) Validate each lastmod parses as W3C Datetime (YYYY-MM-DD or full RFC3339); count malformed. 3) Reservoir-sample 30-50 URLs across all child sitemaps. 4) For each: GET, capture the Last-Modified response header; parse all JSON-LD blocks for dateModified/datePublished; parse <meta property="article:modified_time"> and <meta name="last-modified">. 5) Per URL compute min absolute delta between sitemap lastmod and any available page signal. 6) Report: %future-dated (FAIL if >0), %malformed, the largest cluster within a one-hour window (build-stamp context only when it covers >90% of sampled URLs, falls within 3 days of the crawl date, and the page-date divergence threshold is exceeded), and %URLs whose delta exceeds 7 days against every available signal (FAIL if >20%). 7) Report separately the %URLs with no page-level signal at all — that is an actionable sub-finding (add dateModified to JSON-LD) rather than a lastmod failure.
 
 ## Example failure
 
@@ -56,10 +56,10 @@ Tier per evidence policy: **scored** — grade A meets the A/B bar required for
 
 The two audits ask different questions and must not be collapsed into one:
 
-| Audit                                             | Question                  | Fails when                                                                                      |
-| ------------------------------------------------- | ------------------------- | ----------------------------------------------------------------------------------------------- |
-| `machine-discovery/sitemap-lastmod`               | Is `lastmod` **present**? | The sitemap omits it, or omits it on most URLs.                                                 |
-| `machine-discovery/sitemap-lastmod-verifiability` | Is `lastmod` **true**?    | The values that exist contradict the pages, are future-dated, or are one deploy stamp repeated. |
+| Audit                                             | Question                  | Fails when                                                                                                          |
+| ------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `machine-discovery/sitemap-lastmod`               | Is `lastmod` **present**? | The sitemap omits it, or omits it on most URLs.                                                                     |
+| `machine-discovery/sitemap-lastmod-verifiability` | Is `lastmod` **true**?    | The values that exist contradict the pages, are future-dated, or repeat a deploy stamp that contradicts page dates. |
 
 A sitemap can pass the first and fail this one, which is the common case: the
 CMS emits `lastmod` on every URL and rewrites all of them on every build.
@@ -105,7 +105,7 @@ The trigger was a large retail site. Its product pages publish no modification t
 
 ### A build stamp is one run, not one string (2026-10-06)
 
-The claim is "one identical lastmod equal to the last deploy date". The audit compared lastmod strings exactly. A generator that writes the clock per URL spreads one run over seconds, and exact matching saw every value as different. One large retail site stamped 2451 product URLs between 09:57:16 and 09:57:33 on one day. The audit now counts the largest group of sampled values inside a one-hour window. The 90% share and the 3-day recency rules are unchanged. Values hours apart still count as separate dates.
+The claim is "one identical lastmod equal to the last deploy date". The audit compared lastmod strings exactly. A generator that writes the clock per URL spreads one run over seconds, and exact matching saw every value as different. One large retail site stamped 2451 product URLs between 09:57:16 and 09:57:33 on one day. The audit now counts the largest group of sampled values inside a one-hour window. The 90% share and the 3-day recency rules are unchanged. Values hours apart still count as separate dates. The correction below limits how this pattern affects the verdict.
 
 ### `Last-Modified` corroborates but cannot contradict (2026-10-06)
 
@@ -125,6 +125,32 @@ an article meta date is judged as before, against every signal it has.
 
 No corpus or bare-site verdict moved: the corpus fixtures carry no sitemap.
 
+### A date cluster needs contradictory evidence (2026-10-06)
+
+Six real edits within 25 minutes can each agree exactly with the page's
+`dateModified`. The one-hour rule previously failed that fully corroborated
+sample as a build stamp. A cluster now adds build-stamp context only when
+more than 20% of comparable page dates also diverge by over seven days.
+A corroborated batch passes. Missing page dates keep the existing
+unverifiable warning and never prove a build stamp. Future dates and
+contradictory content dates still fail. This corrects the implementation
+sketch against the existing source requirement: the timestamp must describe
+the significant content update, not follow any required publication cadence.
+
+### A deploy-time header cannot vouch for a stamp run (2026-10-06)
+
+The cluster rule above left one gap. A static host can write every
+`lastmod` at build time and send the deploy time as `Last-Modified`. The two
+agree to within minutes, so every URL counted as corroborated and the audit
+passed. That agreement shows when the build ran, not when the content
+changed.
+
+When the sample has the stamp shape — over 90% in one recent one-hour run —
+the header is no longer compared. Content dates still corroborate or
+contradict as before. A URL with only the header becomes unverifiable, so
+the site gets the existing warning, not a pass and not a fail. Outside that
+shape the header corroborates exactly as before.
+
 ## Deferred
 
 - **Only the first level of a `<sitemapindex>` is walked**, per the shared

docs/evidence/audits/operability-safety/ghost-clickable-element-ratio.md

@@ -116,14 +116,25 @@ link's text.
 Two rules now hold for an element whose only signal is a name or a cursor:
 
 - **It holds a control.** An element that contains `a[href]`, `button`,
-  `select`, `textarea`, `summary`, a non-hidden `input`, or any declared
-  `role` is layout around that control, and is not a ghost.
+  `select`, `textarea`, `summary`, a non-hidden `input`, or an interactive
+  widget role is layout around that control, and is not a ghost. Decorative
+  and structural roles such as `presentation`, `none`, `img` and `status`
+  do not supply an action.
 - **It sits inside a control.** An element inside a link, a button, a
   `summary` or a widget role is part of that control. A click on it is the
   control's click.
 
 An inline handler (`onclick` and the rest) is the element's own action. It
-still flags the element whatever it contains or sits in.
+still flags the element whatever it contains. Inside a control it counts
+only when it stops the event: `stopPropagation`, `stopImmediatePropagation`
+or `cancelBubble`. Any other handler, such as an analytics call, runs and
+lets the click reach the control, so the element stays part of it.
+
+Role names match as the ARIA role attribute is read: case-insensitive, and
+the first token that names a concrete role wins. `role="link button"` is a
+link, and `role="img button"` is an image, not a control. A wrapper around
+a `gridcell` or a `scrollbar` holds a control too. `progressbar` is a widget
+role but takes no input, so it is not one.
 
 Verdicts that moved in the real-page corpus, all from wrappers and inner
 labels: `barclays-co-uk-current-accounts`, `capitalone-com-savings`,

packages/core/src/audits/answer-readiness/text-fragment-addressability.test.ts

@@ -30,6 +30,25 @@ function faqJsonLd(answer: string) {
 
 const SIMPLE = `<main><h2>What is resoling?</h2><p>${ANSWER}</p></main>`;
 
+it("addresses a FAQ answer restored by the last inline declaration", () => {
+  const result = run(
+    `<h2>Resoling</h2><p style="display:none;display:block">${ANSWER}</p>`,
+    faqJsonLd(ANSWER),
+  );
+  expect(result.status).toBe("pass");
+});
+
+it.each([
+  `<div style="visibility:hidden"><section style="visibility:visible"><h2>Resoling</h2><p>${ANSWER}</p></section></div>`,
+  `<h2>Resoling</h2><div style="visibility:hidden"><p style="visibility:visible">${ANSWER}</p></div>`,
+])(
+  "addresses a visible answer inside a visibility:hidden block: %s",
+  (body) => {
+    const result = run(body, faqJsonLd(ANSWER));
+    expect(result.status).toBe("pass");
+  },
+);
+
 describe("TextFragmentAddressabilityAudit", () => {
   const audit = new TextFragmentAddressabilityAudit();
 

packages/core/src/audits/answer-readiness/text-fragment-addressability.ts

@@ -82,7 +82,9 @@ function blockRuns(page: PageContext): BlockRun[] {
     }
     const tag = (node as { tagName?: string }).tagName?.toLowerCase();
     if (!tag || UNRENDERED.has(tag)) return;
-    const own = rendered && !notRendered($, node);
+    // notRendered walks the ancestors itself. A visibility:visible child of
+    // a visibility:hidden block renders, so the parent's state cannot decide.
+    const own = !notRendered($, node);
     const block = $(node).is(BLOCK_SELECTOR);
     if (block) flush();
     for (const child of (node as Element).children ?? []) walk(child, own);
@@ -121,13 +123,15 @@ function answerAfter(page: PageContext, heading: Element): string | undefined {
   const $ = page.$;
   const next = $(heading).next();
   if (next.length === 0 || next.is("h1,h2,h3,h4,h5,h6")) return undefined;
-  if (notRendered($, next.get(0)!)) return undefined;
 
   const leaves = (next.find(BLOCK_SELECTOR).toArray() as Element[])
     .filter((el) => $(el).find(BLOCK_SELECTOR).length === 0)
     .filter((el) => !notRendered($, el))
     .map((el) => normalize($(el).text()))
     .filter(Boolean);
+  // A hidden wrapper can still hold a visibility:visible leaf, so only a
+  // wrapper with no rendered leaf is skipped whole.
+  if (leaves.length === 0 && notRendered($, next.get(0)!)) return undefined;
 
   let span = "";
   if (leaves.length === 0) {