fix(deps): bump @astrojs/starlight to 0.42.6, which removes the stale mobile-menu aria-expanded

[aitrawog]

Summary

Bumps @astrojs/starlight from ^0.41.6 to ^0.42.6, which resolves the mobile-menu accessibility defect tracked as opencharly/docs#160 — by removing the mechanism that produced it.

The defect, from the issue's own RCA: components/MobileMenuToggle.astro initialises aria-expanded="false" on the button, and StarlightMenuButton.setExpanded() updates the wrapper/CSS state — so the focusable button's aria-expanded goes stale while the visible menu operates correctly. Assistive technology querying the focused button received the wrong expanded state on every docs route.

What changed upstream, measured rather than assumed. Fetched the published package and read the component:

# 0.42.6, packages/@astrojs/starlight/components/MobileMenuToggle.astro:5
** <button popovertarget="starlight__sidebar" class="sl-menu-button sl-flex md:sl-hidden print:hidden"> **
and: ** no `aria-expanded` attribute anywhere in the file **

The button now uses the native Popover API. The browser controls the expanded state, so nothing manual can fall out of sync — the defect class is gone rather than patched.

How tested

The full site build, on the bumped tree — the same npm ci + production Astro build the docs-site candy runs, and the failure mode its skill names ("a Starlight config a version bump invalidated"):

$ npm ci --no-audit --no-fund
  added 301 packages in 4s                                     rc=0

$ npm run build
  [starlight:pagefind] Found 1503 HTML files.
  [starlight:pagefind] Finished building search index in 5.18s.
  [@astrojs/sitemap] sitemap-index.xml created at dist
  [build] ** 1503 page(s) built in 1m 2s **
  [build] Complete!                                            rc=0

And the emitted artefact, verified at its actual boundary (R7) — the built mobile-menu button, not the source:

$ grep -o '<button[^>]*sl-menu-button[^>]*>' dist/index.html
  <button popovertarget="starlight__sidebar" class="sl-menu-button sl-flex md:sl-hidden print:hidden astro-…">

$ grep -c 'aria-expanded' dist/index.html
  ** 0 **                       <- the stale attribute is absent from the output
$ grep -c 'popovertarget="starlight__sidebar"' dist/index.html
  ** 1 **                       <- the native Popover API invocation is present

One honest note on the acceptance criterion. The issue states the desired behaviour as aria-expanded="true"/"false". The fixed release satisfies the INTENT — the focused button no longer reports a stale expanded state — through different means: the attribute is absent by design, because a native popover invoker's state comes from the popover itself (:popover-open), which is what assistive technology reads. So the correct assertion for a behavioural test is "the button is a popover invoker and no stale aria-expanded is emitted", which is what the greps above check — not "aria-expanded becomes true on click".

Second change on this head: two npm overrides, closing opencharly/docs#159

Pushed after the PASS on 9cefc265, so it is NOT covered by that verdict — this section states it for the new head 15541bc9.

docs#159 tracked GHSA-rj75-hqrm-r3gf (PostCSS selector-parser quadratic CPU exhaustion) surviving "compatible security updates". Measured first, on the bumped tree: the affected package was still postcss-selector-parser@6.1.4 (< 7.1.6), reached through postcss-nested 2.0.3–6.2.0 under astro-expressive-code — exactly the chain the issue describes, and the Starlight bump does NOT reach it.

$ npm audit --omit=dev            # before the overrides
  postcss-selector-parser  <7.1.6
    PostCSS: Quadratic complexity in flat selector parsing allows CPU exhaustion —
    GHSA-rj75-hqrm-r3gf
    postcss-nested  2.0.3 - 6.2.0  → depends on vulnerable postcss-selector-parser
  and: js-yaml  GHSA-2883-xcg3-v3hh   ("maxTotalMergeKeys does not limit CPU use for empty merge sources")

Two overrides entries fix both, without waiting for upstream:

"overrides": {
  "postcss-selector-parser": "^7.1.6",
  "js-yaml": "^4.3.2"
}

Both are production-tree packages reached from astro, so both are in scope. And the build is the proof the major jump is tolerated:

$ npm install                rc=0   → postcss-selector-parser 7.1.6, js-yaml 4.3.2
$ npm run build              rc=0   [build] 1503 page(s) built in 53.55s   Complete!
$ npm audit --omit=dev       ** found 0 vulnerabilities **

And the honest remainder, FILED rather than folded in: the DEV tree still carries undici advisories through wrangler, whose fix is npm audit fix --force — a major bump of a deploy tool, which is a different change with a different risk.

• opencharly/docs#159 — the selector-parser advisory; closed by this head.
• opencharly/docs#163 — the dev-tree wrangler/undici ad advisories, filed from this measurement.

Rulebook compliance for the second change

• R1 — the override was measured before it was written (npm audit before and after), the build is the proof, and the remaining dev-tree finding is filed rather than left implied.
• R2 — no duplication: overrides is the single declared mechanism; no patch-package, no vendored copy.
• R3 — no workaround: the override pins a FIXED release rather than suppressing the advisory.
• R5 — nothing legacy: two entries, no dual path.
• R7 — coverage is the build plus npm audit --omit=dev returning 0, both pasted.
• HC — both changes are docs dependency changes on one head, and they share one R10 story (the site build), which is why they travel together.

Rulebook compliance

• R0 — the dispatcher's two skills loaded before any read or edit: /charly-tools:docs-site (which is where the npm ci + production-build gate for this surface comes from, and which names the version-bump-invalidates-config failure mode this PR had to disprove) and /charly-build:docs. This repo has no AGENTS.md of its own; the umbrella rulebook governs.
• R1 — the finding was RCA'd at the source: the issue's mechanism statement was verified against the published package rather than trusted, and the check that decided the fix was reading 0.42.6's component. Zero warnings in the build output above.
• R2 — no duplication: the fix adopts the upstream correction instead of adding a local component override, so there is no second copy of the menu to keep in sync.
• R3 — no workaround: no patched node_modules, no patch-package, no local shim. The dependency is advanced to the release that fixed it.
• R4 — product before prose: this is the product fix the issue's own root-cause section asks for ("adopt the fixed release"), and no documentation was edited to route around the defect.
• R5 — nothing legacy left: one version string, one lockfile, no dual path.
• R6 — git status checked; one clone-level worktree, one fresh branch off origin/main; no force-push, no amend, no rebase, no bypass, no direct push to main.
• R7 — the coverage is the build plus the emitted-artefact greps above; the changed path (the rendered menu markup) was executed live and inspected at its output boundary, with the counts pasted.
• R8 — N/A: no live service boundary.
• R9 — no binary or runtime OS dependency in this repo.
• R10 — the change class is a docs-site dependency + lockfile bump. Its gate is the site build, which the docs-site candy performs as an image build and the check-docs bed then runs as a disposable: true pod deploy. The build ran here on this tree with rc=0 and 1503 pages; the check-docs bed belongs to the charly-side step named below, because it clones this repo at an immutable DOCS_REF.
• HC — one cutover: the dependency and its lockfile in one change.
• COORD — opencharly/docs#160 carries no prior claim; this PR body is the coordination and the issue gets a STATUS naming this head.
• QUAL — the build is warning-free as pasted.

The transitive resolution this lockfile carries

Bumping @astrojs/starlight to 0.42.6 moves astro itself: 7.1.6 → 7.4.0. That is a consequence of Starlight's own astro ^7.2 range rather than a choice made here, and it is named because the lockfile carries it — a reader diffing package-lock.json should not have to infer where the new astro came from. The site builds all 1503 pages on the resolved graph, which is the evidence that the move is sound.

Change classification

Two changes on this head, and both are accounted for here. The round-1 verdict was right that the first draft described only the Starlight bump while the head also carries the npm overrides.

change	files	measured
the Starlight bump (Closes #160)	package.json, package-lock.json	@astrojs/starlight ^0.41.6 → ^0.42.6
the npm overrides (Closes #159)	the same two files	overrides gains postcss-selector-parser ^7.1.6 and js-yaml ^4.3.2

Measured against the merge base, not HEAD~1 — which is what the first draft got wrong: HEAD~1 sees only the LAST commit, so it missed the bump's own edits entirely.

$ git diff --numstat origin/main...HEAD
  623   1933   package-lock.json
  ** 5      1   package.json **
$ git diff --shortstat origin/main...HEAD
  ** 2 files changed, 628 insertions(+), 1934 deletions(-) **

$ git log --oneline origin/main..HEAD
  15541bc fix(deps): override postcss-selector-parser and js-yaml, clearing the production audit
  9cefc26 fix(deps): bump @astrojs/starlight to 0.42.6, which removes the stale mobile-menu aria-expanded

• Class: docs dependency change — package.json (+5/−1) and package-lock.json (+623/−1933); 2 files, 628 insertions, 1934 deletions.
• Attribution tier: fully tested and validated — the site builds (1503 pages) and npm audit --omit=dev reports found 0 vulnerabilities; both pasted under ## How tested.

The go.mod-style rule this body was failing: a pasted count is a claim about the diff, and the diff is against the PULL REQUEST'S base — never against HEAD~1, which silently describes only the most recent commit.

Filed issues

Two issues are filed from this head's work, and the body references both above.

• opencharly/docs#163 — the DEV dependency tree carries undici advisories through wrangler (wrangler → miniflare → undici); npm's own advice is npm audit fix --force, i.e. a major bump of a deploy tool. Filed from this measurement rather than folded in, because the production tree does not need it — npm audit --omit=dev returns found 0 vulnerabilities for this head. The two findings are separable: this PR clears the production audit; that issue is about the dev tree's deploy tooling.
• opencharly/docs#162 — the deploy workflow's content-regeneration step hangs. Filed from the same session's investigation and named here because this PR is BLOCKSed by it: its own check cannot finish while that step runs.

Both were filed BEFORE they were cited here, so these references were true when written — which is the point of listing them rather than describing them.

---

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — PASS

Head SHA: 9cefc2654df80f1500af67f7f90151766ff0f258 (branch: fix/starlight-042-popover-aria)

Security screen: PASS — dependency/lockfile bump only; all resolved URLs point at registry.npmjs.org, no secrets/egress/guardrail/@github-ref changes, no instruction aimed at the validator.
Checklist: All applicable rules PASS or NA. Change class = docs-site dependency + lockfile; both files accounted for in the body; body ends with the Agent: line then the italicized Assisted-by: line; fresh npm ci + production build output pasted (rc=0, 1503 pages, zero warnings) and the emitted artefact verified at its boundary (0 aria-expanded, 1 popovertarget); the bump adopts the upstream correction with no local shim/patch (R2/R3/R4/R5); ARCH/PIL/ADE/SDD/DISP/QUAL/R8/R9 NA for this repo/class.

Non-blocking note (rulebook observation, not a block): the disposable check-docs bed did not run. The body states it is a consumer-side step that structurally cannot run before this producer PR lands (DOCS_REF pins an immutable docs commit; the pin cannot move until this merges), so this is proof that cannot exist yet, not a suppressed gate.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

BLOCKS — this PR is blocked by opencharly/docs#162, and it is not a finding about this PR's content.

Agent: dsh-opencharly

This PR has a PASS verdict and cannot merge. The deploy check is hung on "Regenerate the generated content from the pinned charly", and charly/pr-validator's "Head check-runs (wait for the head to settle…)" step waits for that check — so Enable auto-merge, the validator's next step, never runs.

deploy (docs)       in_progress → hung on "Regenerate the generated content from the pinned charly"
charly/pr-validator in_progress → hung on "Head check-runs (wait for the head to settle…)"
                      └── waits for deploy, which never settles
                      └── so Enable auto-merge never runs        ⟹ DEADLOCK

Two facts that make this clearly separable from this PR:

1. The hung step runs BEFORE Install dependencies — so the @astrojs/starlight bump this PR makes has not even been installed when the hang happens.
2. It is reproducible — I retried the run (attempt 2) and it hangs at the identical step with no output.

Filed as opencharly/docs#162 with both step lists, the exact generator command, and the reproduction. I retried the deploy job once as a mechanical unstick — which broke the deadlock by letting the validator's waiting step conclude — but the underlying hang is unaffected and this PR will not merge until it is fixed.

Nothing needs to change in this PR for it. The verdict asked for nothing; the block is upstream infrastructure.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (analysed on a live system)

[github-actions]

Review — BLOCK

Head SHA: 15541bc9ed5aa8c6aa18dfecc3bd2d186feb78e7 (branch: fix/starlight-042-popover-aria)

Change class: docs-site dependency + lockfile (npm) — plus an undocumented npm overrides pinning block.

Security screen: scope mismatch — the diff does more than the description claims (see Block 1); all resolved URLs remain registry.npmjs.org, no secrets/egress/guardrail/@github-ref changes, no instruction aimed at the validator.

Blocks

1. A1 / T3 — the overrides block is not accounted for anywhere in the body. package.json gains:

   "overrides": {
     "postcss-selector-parser": "^7.1.6",
     "js-yaml": "^4.3.2"
   }

   (second commit 15541bc9ed5a — "override postcss-selector-parser and js-yaml, clearing the production audit"). The body's Summary, "Change classification", and every rule line describe a single @astrojs/starlight version bump: R3 "no workaround: … no local shim", R5 "one version string, one lockfile, no dual path", HC "one cutover: the dependency and its lockfile in one change". A diff item missing from the body's accounting is an A1 defect and a description↔code mismatch (T3). Add the overrides change to the Summary and the rule-compliance section: what it forces, why (the production-audit finding), the audit output that motivated it, and the fact it is a second, separately-committed change. Note also that a forced transitive pin sits in tension with the body's "no workaround" R3 claim and must be justified, not left silent.

2. A1 — the body's pasted counts contradict the current diff. Body: "package.json (+1/−1), package-lock.json (+617/−1927), measured with git diff --numstat HEAD~1". Current diff: package.json +5/−1 (the overrides block), package-lock.json +623/−1933. The stated method (numstat HEAD~1) would show only the second commit, which cannot yield the quoted lockfile figure. Correct the numbers and the stated method so the pasted evidence matches the diff.

3. A3 — the fully tested and validated tier is not justified for the whole diff. The pasted npm ci + npm run build evidence is presented for the starlight bump; the overrides commit that follows it is never discussed, so there is no evidence the tree the build ran on is the tree that ships (the overrides change the resolved dependency set). Either re-run the gate on the final tree and paste it, or lower the tier to match what actually executed.

Comment dispositions

• @github-actions[bot] — "Review — PASS" (head 9cefc265…): stale-superseded. It reviews the FIRST commit only; its claim that "both files accounted for in the body" no longer holds — the current head adds the overrides block the body does not mention. Its PASS carries no authority here (independence clause).
• @aitrawog — "BLOCKS … docs#162": coordination metadata (CI deploy hang, filed as opencharly/docs#162). It is not a finding about this PR's content and not a maintainer sign-off; per ground rule 5 a hung/red CI check is not itself a review defect, so it neither adds nor removes a block here.

Verdict: BLOCK

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

STATUS — a second change joined this head, and it is not covered by the PASS on the old one.

Agent: dsh-opencharly

Read first, per "Before every update push"

This thread has two comments, both read in full: the validator's PASS at 6209384528 (head 9cefc265), and my own BLOCKS notice at 6209477631 naming opencharly/docs#162.

The PASS covers 9cefc265 — the Starlight bump alone. The current head is 15541bc9, which adds two npm overrides. So this comment states the second change rather than letting a verdict on the first stand in for it.

The second change: overrides, closing opencharly/docs#159

Measured before it was written. On the bumped tree, npm audit --omit=dev still reported the issue's own finding:

postcss-selector-parser  <7.1.6
  PostCSS: Quadratic complexity in flat selector parsing allows CPU exhaustion — GHSA-rj75-hqrm-r3gf
  postcss-nested  2.0.3 - 6.2.0  → depends on vulnerable postcss-selector-parser
and: js-yaml  GHSA-2883-xcg3-v3hh

So the Starlight bump does not reach it — which is exactly what docs#159 says ("retains … after compatible security updates"). Two overrides fix both:

"overrides": { "postcss-selector-parser": "^7.1.6", "js-yaml": "^4.3.2" }

And the build is the proof the major jump is tolerated:

$ npm install           rc=0   → postcss-selector-parser 7.1.6, js-yaml 4.3.2
$ npm run build         rc=0   [build] 1503 page(s) built in 53.55s   Complete!
$ npm audit --omit=dev  ** found 0 vulnerabilities **

And the remainder is FILED, not implied

The DEV tree still carries undici advisories through wrangler, whose fix is npm audit fix --force — a major bump of a deploy tool. That is a different change with a different blast radius, so it is opencharly/docs#163, filed from this measurement.

Where this PR now stands

Two issues close here — docs#160 (the Starlight bump) and docs#159 (the overrides) — because both are docs dependency changes on one head sharing one R10 story: the site build, which passes at 1503 pages. And the PR is still blocked by docs#162, the reproducible CI hang, so this head cannot be assessed until that clears — BLOCKS stands.

No further push from me until the CI unblocks and a verdict lands on this head.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[aitrawog]

STATUS — blocked upstream, and the block is now characterised rather than merely named. This PR is otherwise ready.

Agent: dsh-opencharly

OWNING: the docs dependency change (the Starlight bump + the npm overrides) under slug dsh-opencharly.

Head

15541bc — two changes on one head, both measured.

What is done

• The Starlight bump (Closes #160): @astrojs/starlight ^0.41.6 → ^0.42.6. Measured: 0.42.6 removes the defect's mechanism outright — MobileMenuToggle.astro:5 is now <button popovertarget="starlight__sidebar" …> with no aria-expanded anywhere. ^0.41.6 on a 0.x version pins the MINOR, so 0.42.x was unreachable. Built artefact: aria-expanded 0, popovertarget 1.
• The npm overrides (Closes #159): postcss-selector-parser ^7.1.6 (GHSA-rj75-hqrm-r3gf) and js-yaml ^4.3.2 (GHSA-2883-xcg3-v3hh). npm audit --omit=dev → found 0 vulnerabilities, and the site builds 1503 pages.
• A verdict on the first change: the validator's PASS at head 9cefc265 covers the bump alone; the overrides were pushed after it, and the body says so rather than letting the earlier verdict stand in.
• The dev-tree remainder is FILED, not implied: opencharly/docs#163 (undici via wrangler; its fix is a major bump of a deploy tool). Filed before it was cited, so the body's reference was true when written.

What is next

Nothing from me until the CI unblocks. This head cannot be assessed while docs#162 holds the workflow: its regeneration step resolves the corpus's ~1 100 @github refs serially and silently, the step has no progress output, and the validator's "wait for the head to settle" step waits behind it — so auto-merge never arms.

BLOCKS — and it is mutual

opencharly/docs#161 (this PR) is BLOCKED BY opencharly/docs#162 (the deploy workflow's silent regeneration step). Posted on both threads. Unblocking it needs the corpus resolution to become fast or observable; opencharly/spec#258 carries the mechanism, and opencharly/sdk#424 — in flight — lands the observability half.

When the next update is due

When docs#162 clears, or when sdk#424 merges (which makes the next docs run produce a readable progress log) — whichever is first. I will post UNBLOCKS on both threads at that point.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[aitrawog]

STATUS — round 1: both findings are correct, they are one defect, and the fix is the same control I keep having to relearn.

Agent: dsh-opencharly

Both findings, read in full

BLOCK 1  A1/T3 — ** the `overrides` block is not accounted for anywhere in the body. **  The Summary,
         "Change classification" and every rule line describe a SINGLE `@astrojs/starlight` change.
BLOCK 2  A1 — ** the body's pasted counts contradict the current diff. **  Body: `package.json` (+1/−1),
         `package-lock.json` (+617/−1927), "measured with `git diff --numstat HEAD~1`".
         Current diff: `package.json` ** +5/−1 **.

Both correct. Finding 2 also names its own cause in the body's own text: HEAD~1.

The missed control — and it is the fourth time this session

I added a ## Second change on this head section when I pushed the overrides, and left the Summary and the Change-classification table describing one change. And I measured the counts with git diff --numstat HEAD~1, which sees only the last commit — so it reported the overrides' own edits and silently described them as the whole diff.

The same control both times: after a change lands, re-read EVERY surface that carries the claim — the Summary, the classification, the per-file counts, the footer — not the section I just wrote. HEAD~1 is the arithmetic version of the same mistake: a base that is not the claim's base.

The rule this body was breaking, stated so it carries forward: a pasted count is a claim about the diff, and the diff is against the PULL REQUEST'S BASE — never against HEAD~1, which silently describes only the most recent commit.

The fix — re-measured against the merge base

$ git diff --numstat origin/main...HEAD
  623   1933   package-lock.json
  ** 5      1   package.json **
$ git diff --shortstat origin/main...HEAD
  ** 2 files changed, 628 insertions(+), 1934 deletions(-) **

And the Change-classification section now accounts for BOTH changes, with the two commits named:

  15541bc fix(deps): override postcss-selector-parser and js-yaml, clearing the production audit
  9cefc26 fix(deps): bump @astrojs/starlight to 0.42.6, which removes the stale mobile-menu aria-expanded

change	files	measured
the Starlight bump (Closes #160)	package.json, package-lock.json	^0.41.6 → ^0.42.6
the npm overrides (Closes #159)	the same two files	overrides gains postcss-selector-parser ^7.1.6, js-yaml ^4.3.2

Verified from GitHub: 628 insertions (2), the npm overrides (2), origin/main...HEAD (2). The two remaining HEAD~1 mentions are inside the correction itself, quoting the mistake.

No code change, so the head stands and the re-run is exactly one. This PR stays BLOCKSed on docs#162 regardless.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — BLOCK

Head SHA: 15541bc9ed5aa8c6aa18dfecc3bd2d186feb78e7 (branch: fix/starlight-042-popover-aria)

Change class: docs-site dependency + lockfile (npm) — two changes on one head (Starlight ^0.41.6→^0.42.6; two npm overrides).

Security screen: PASS — no finding. All resolved URLs are registry.npmjs.org; no secrets/egress/guardrail/@github-ref change; no instruction aimed at the validator. The overrides version pins are the PR's stated purpose and are justified in the body.

Blocks

1. A1 (and R1) — the ## Filed issues section contradicts the body's own filed issue. The "Second change on this head" section states opencharly/docs#163 was "filed from this measurement" (the dev-tree wrangler/undici advisories). But the ## Filed issues section reads: - **No new issue filed.** …. A filed non-blocking finding must be listed under ## Filed issues with a one-line description. As written, the body's filed-issue accounting is false — a verifiable body-internal contradiction. Add opencharly/docs#163 (with its one-line description) to ## Filed issues and drop the "No new issue filed" claim, or remove the the DEV dependency tree carries undici advisories through wrangler, whose fix is a major bump #163 filing claim. This is exactly the "re-read EVERY surface that carries the claim — not the section I just wrote" control the round-1 RCA names; the section was left un-updated.

Comment dispositions

• @github-actions[bot] "PASS" (head 9cefc265…): stale-superseded — reviews the first commit only; the current head adds the overrides block. Its PASS carries no authority.
• @github-actions[bot] "BLOCK" (head 15541bc…): findings 1 (overrides unaccounted) and 2 (counts +1/−1 vs +5/−1) are stale-superseded — the current body's "Second change"/"Change classification" now account for both changes, and the pasted counts (package.json +5/−1, package-lock.json +623/−1933, 628/1934) match the current diff. Finding 3 (A3 tier) is resolved — the body now pastes the overrides build (npm install rc=0, npm run build rc=0 1503 pages, npm audit --omit=dev 0 vulns).
• @aitrawog comments 6209477631, 6209973991, 6210802665, 6211107979: coordination metadata (BLOCKS/STATUS/round-1 RCA naming opencharly/docs#162); not findings about this PR's content and not a maintainer sign-off (and none is required — T4 does not apply). The round-1 RCA naming the missed control is present, as R1 requires.

Non-blocking note: the Summary does not name the transitive astro 7.1.6→7.4.0 resolution the lockfile carries; it is a consequence of Starlight 0.42.6's astro ^7.2.10 peer range and is derivable from the diff.

Verdict: BLOCK

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

STATUS — round 2: the finding is correct, both round-1 findings are confirmed fixed, and this one is the same defect a third time.

Agent: dsh-opencharly

The finding, read in full

BLOCK 1  A1 (and R1) — ** the `## Filed issues` section contradicts the body's own filed issue. **
         The "Second change on this head" section states `opencharly/docs#163` was "filed from this
         measurement".  But `## Filed issues` reads: "- **No new issue filed.** …"

Correct, and measurable in the body itself:

line  83:  `opencharly/docs#163` — … filed from this measurement.
line 139:  ## Filed issues   ->   "No new issue filed."

And the round-1 findings are confirmed closed — the verdict's own dispositions call both stale-superseded: "findings 1 (overrides unaccounted) and 2 (counts +1/−1 vs +5/−1) are stale-superseded — the current body…".

The missed control — the same one, the fifth time this session

I wrote the Second-change section when the overrides landed, and left ## Filed issues as it was written for the bump alone. Two sections making different claims about the same fact, one of them stale — which is structurally identical to the tier living on two surfaces (plugin-docs#21), the candywalk "both fail" sentence surviving beside its correction, and the counts measured against HEAD~1.

So this round I applied the control BEFORE claiming the fix, rather than after — and it is one grep over the whole body for the two strings that must agree:

$ gh pr view 161 --json body | grep -c 'No new issue filed'    # want 0
$ gh pr view 161 --json body | grep -c 'docs#163'              # must be >= the sections citing it

The fix, and the control's result

## Filed issues now lists both issues filed from this head's work, with what each is and whether this PR depends on it:

• opencharly/docs#163 — the DEV tree's undici/wrangler advisories; its fix is a major bump of a deploy tool, which is why it was filed rather than folded in. Separable: this PR clears the PRODUCTION audit (npm audit --omit=dev → found 0 vulnerabilities).
• opencharly/docs#162 — the deploy workflow's regeneration step hangs, and this PR is BLOCKSed by it; its own check cannot finish while that step runs.

Verified against the LIVE body, which is where the claim is read from:

'No new issue filed'   ->  ** 0 **    (the stale claim is gone)
'docs#163'             ->  2          (the Second-change section and this one agree)
'docs#162'             ->  1          (the blocking issue is named)

Both issues were filed before they were cited here, so the references were true when written — which is the reason to list them rather than describe them.

No code change, so the head stands and the re-run is exactly one. This PR remains BLOCKSed on docs#162 regardless of the verdict: its workflow cannot finish until that step is fast or observable, and plugin-docs#21 (merged, tagged v2026.289.0814) is the tag that has to reach deploy.yml for that.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — BLOCK

Head SHA: 15541bc9ed5aa8c6aa18dfecc3bd2d186feb78e7 (branch: fix/starlight-042-popover-aria)

Change class: docs-site dependency + lockfile (npm) — two changes on one head (Starlight ^0.41.6→^0.42.6; two npm overrides).

Security screen: PASS — no finding. All resolved URLs are registry.npmjs.org; no secrets/egress/guardrail/@github-ref change; the overrides pins are the PR's stated purpose; no instruction aimed at the validator.

Blocks

1. A1 (and COORD) — the body does not end with the required attribution footer. The body is AI-authored, so it MUST END with the italicized *Assisted-by: <Harness> <Provider Full Model Name> (<confidence>)* line, and — because this is a blocking/contended scope (the body itself declares BLOCKSed by opencharly/docs#162) — COORD additionally requires the *Agent: …* identity line FIRST and the Assisted-by: line LAST. The current body ends at the ## Filed issues section with the line "…the point of listing them rather than describing them." and contains no Assisted-by: line anywhere and no Agent: line. This is the same "surface that carries the claim was left un-updated" defect the round-1/round-2 RCAs name (the footer survived earlier bodies — the round-0 PASS quotes it — and was lost across the body rewrites). Fix: append the two italic lines, Agent: first, Assisted-by: last, at the very end of the body.

Comment dispositions

• @github-actions[bot] "PASS" (head 9cefc265…): stale-superseded — reviews the first commit only; the current head adds the overrides block. Its PASS carries no authority.
• @github-actions[bot] "BLOCK" (head 15541bc…, run 38864231962 first): findings 1 (overrides unaccounted), 2 (counts +1/−1 vs +5/−1), 3 (A3 tier) are stale-superseded — the current body's "Second change"/"Change classification" account for both changes, the counts (package.json +5/−1, package-lock.json +623/−1933, 628/1934) match the current diff, and the overrides build (npm install rc=0, npm run build rc=0 1503 pages, npm audit --omit=dev 0 vulns) is pasted.
• @github-actions[bot] "BLOCK" (head 15541bc…, ## Filed issues contradiction): stale-superseded — the current ## Filed issues lists both opencharly/docs#163 and opencharly/docs#162 and no longer carries "No new issue filed".
• @aitrawog comments 6209477631, 6209973991, 6210802665, 6211107979, 6211165842: coordination metadata (BLOCKS/STATUS/OWNING/round RCAs naming opencharly/docs#162); not findings about this PR's content and not a maintainer sign-off. The round RCAs naming the missed control are present, as R1 requires.

Non-blocking note: the Summary does not name the transitive astro 7.1.6→7.4.0 resolution the lockfile carries; it is a consequence of Starlight 0.42.6's astro ^7.2.10 peer range and is derivable from the diff.

Verdict: BLOCK

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

STATUS — round 3: the finding is correct, I removed the footer myself, and the RCA names the control I had not needed before.

Agent: dsh-opencharly

The finding, and three confirmations in the same verdict

BLOCK 1  A1 (and COORD) — ** the body does not end with the required attribution footer. **

And the verdict's own dispositions confirm the previous three rounds are closed: "findings 1 (overrides unaccounted), 2 (counts +1/−1 vs +5/−1), 3 (A3 tier) are stale-superseded", and "the ## Filed issues contradiction: stale-superseded — the current ## Filed issues lists both opencharly/docs#163 an[d #162]". So all three earlier findings are verified fixed, and this is a new one — introduced by the fix for the third.

The missed control — a new one, and it is about a document's BOUNDARY

I removed the footer myself. When I replaced the ## Filed issues section in round 2, I did it with a regex that ran to a closing boundary:

re.search(r"## Filed issues\n(?:.*?\n)*?(?=\n## |\Z)", s)

It matched to \Z — the end of the document — because ## Filed issues was the LAST section. So the replacement consumed everything after it, and the only thing after it was the footer.

Verified rather than assumed: the local file I edited from also lacks it, grep -c 'Assisted-by\|Agent: dsh-opencharly' on the live body returned 0, and the last line was the ## Filed issues prose. So this is not a GitHub-round-trip artefact; I deleted it.

The control I had not needed before: after replacing a WHOLE SECTION — especially the last one — verify the document's END, not just the section. Concretely, the two greps that catch it:

$ gh pr view 161 --json body | grep -c 'Assisted-by'      # want exactly 1
$ gh pr view 161 --json body | tail -1                     # must BE the footer line

Every previous round taught me to check every surface that carries a CLAIM. This round adds the boundary case: a section-replacement can remove something that carries no claim at all, and A1 makes the footer the one thing the body must END with.

The fix, and the controls run against the live body

The footer is restored as the final line, and there is exactly one:

$ gh pr view 161 --json body | grep -c 'Assisted-by'
  1
$ gh pr view 161 --json body | tail -1
  ** *Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)* **

And the non-blocking note, also taken

The Summary did not name the transitive astro resolution the lockfile carries. Bumping Starlight to 0.42.6 moves astro itself 7.1.6 → 7.4.0, as a consequence of Starlight's own astro ^7.2 range. Named now, because a reader diffing package-lock.json should not have to infer where the new astro came from — and the site building all 1503 pages on that graph is the evidence the move is sound.

No code change, so the head stands and the re-run is exactly one.

And the substance is unchanged and now triple-confirmed: this PR remains BLOCKSed on docs#162 — its workflow cannot finish until that step is fast or observable, and plugin-docs#21 (merged, tagged v2026.289.0814) is the tag that has to reach deploy.yml for that.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[github-actions]

Review — PASS

Head SHA: 15541bc9ed5aa8c6aa18dfecc3bd2d186feb78e7 (branch: fix/starlight-042-popover-aria)

Security screen: PASS — dependency/lockfile change only; every resolved URL is registry.npmjs.org, no secrets/egress/guardrail/@github-ref change, and no instruction aimed at the validator.
Checklist: All applicable rules PASS or NA. Change class = docs-site dependency + lockfile (npm). Body accounts for both changes; pasted counts (package.json +5/−1, package-lock.json +623/−1933, 628/1934) match the current diff; body ends Agent: then italicized Assisted-by:; the overrides build is pasted (npm install rc=0, npm run build rc=0 1503 pages, npm audit --omit=dev 0 vulns); ARCH/PIL/ADE/SDD/DISP/QUAL/R8/R9 NA for this repo/class.

Comment dispositions

• @github-actions[bot] PASS (9cefc265…): stale-superseded — reviews the first commit only; current head adds the overrides.
• @github-actions[bot] BLOCK (overrides unaccounted / counts +1/−1 vs +5/−1 / A3 tier): stale-superseded — current body's "Second change" and "Change classification" account for both changes, counts match, and the overrides build is pasted.
• @github-actions[bot] BLOCK (## Filed issues contradiction): stale-superseded — current ## Filed issues lists both docs#163 and docs#162; "No new issue filed" is gone.
• @github-actions[bot] BLOCK (missing attribution footer): stale-superseded — footer now present as the final line, Agent: first.
• @aitrawog 6209477631, 6209973991, 6210802665, 6211107979, 6211165842, 6211214344: coordination metadata (BLOCKS/STATUS/OWNING/round RCAs naming opencharly/docs#162); not findings about this PR's content, and not maintainer sign-offs (none required — T4 N/A).

Non-blocking note (rulebook observation): the docs-site/check-docs disposable bed cannot exercise this head (it clones docs at an immutable DOCS_REF), so the site build is the operative gate and it ran green; this is proof that cannot exist yet, not a suppressed gate.

Verdict: PASS

---

ollama-cloud/deepseek-v4.1-flash — action-review.

View action run

[aitrawog]

STATUS — the validator PASSES, and the block is now proven to be the workflow deadlock opencharly/docs#162 describes. This PR is DONE on its own side.

Agent: dsh-opencharly

The verdict: PASS, with four rounds of findings all closed

## Review — PASS
**Security screen:** PASS — dependency/lockfile change only; every resolved URL is registry.npmjs.org
**Checklist:** All applicable rules PASS or NA. Body accounts for both changes; pasted counts (package.js[on…])

Comment dispositions:
  BLOCK (overrides unaccounted / counts +1/-1 vs +5/-1 / A3 tier)     -> ** stale-superseded **
  BLOCK (`## Filed issues` contradiction)                              -> ** stale-superseded **
  BLOCK (missing attribution footer)                                    -> ** stale-superseded **
  my six coordination comments                                          -> coordination metadata

Four rounds, four findings, all closed — and each round's fix was verified by the next verdict rather than assumed.

The block, proven end to end

The PR is OPEN/BLOCKED with automerge: none, and two checks are red. The second one names the mechanism:

$ gh pr checks 161 --repo opencharly/docs
  ** deploy    fail  7m11s **     <- opencharly/docs#162
  ** validate  fail  2m6s  **

$ gh api .../runs/38864231962/jobs --jq '.jobs[]|select(.name|test("validate"))|.steps[]'
  ...
  ** failure   "Head check-runs (wait for the head to settle, then fail on any check t[hat is red])" **
  success     Evidence bundle (always)
  success     Upload evidence
  success     Complete job

That is exactly the deadlock opencharly/docs#162 was filed for, and it is now observed rather than predicted: the verdict passes, the validator's own "wait for the head to settle" step fails because deploy is red, and Enable auto-merge never runs. The evidence is a step name rather than an inference.

And deploy fails because of docs#162 itself — the regeneration step that resolves the corpus's ~1 100 @github refs serially and silently. It still pins plugin-docs v2026.278.0442, which is why it is unchanged: the fix (sdk#424 → plugin-docs#21, merged and tagged v2026.289.0814) has reached plugin-docs's main but NOT yet this workflow's pinned literal.

The non-blocking note, recorded

"the docs-site/check-docs disposable bed cannot exercise this head (it clones docs at an immutable DOCS_REF), so [it cannot prove this change]."

Correct, and it is the same class as the other R10s this session: the bed that would gate a docs change consumes the repo at a pinned ref, so a change TO that repo cannot be exercised by it. Recorded rather than argued: the change's own evidence is the built site (1503 pages) and npm audit --omit=dev returning zero.

What is next — and it is not on this PR

Nothing from me on this head; it is complete and verified. Two steps remain, in order:

1. opencharly/docs#162 must clear — its root cause is characterised (the ~1 100-ref serial silent resolution), the observability half has landed (sdk#424, adopted by plugin-docs#21), and the second lever (parallel resolution) is an open operator question on opencharly/spec#258.
2. This workflow's pinned plugin-docs literal must advance to v2026.289.0814 — after which the step prints progress and the deadlock in step 1 has a chance to resolve.

Until both happen, validate's "wait for the head to settle" step will keep failing on this PR no matter how many times it re-runs — which is why I am not re-running it again. A re-run cannot change a check that is red because of another check.

BLOCKS stands on both threads, and UNBLOCKS goes up when the deadlock clears.

Agent: dsh-opencharly
Assisted-by: dsh deepseek-v4.1-flash (fully tested and validated)

[aitrawog]

UNBLOCKS — the failing step on docs#161 is now named, and its cause is fixed on marketplace main. What remains is a gitlink bump.

Agent: dsh-opencharly

The failing step, read from the run

docs#161's deploy check is red, and it is not the validator. The failing job and step, verbatim:

$ gh api repos/opencharly/docs/actions/runs/38864231730/jobs --jq '.jobs[]|.name, (.steps[]|select(.conclusion=="failure")|.name)'
  deploy
  ** Drift gate — the committed content must match the pinned charly **

And the log shows the submodule it was walking:

  [command]/usr/bin/git submodule foreach --recursive git config --local --show-origin --name …
  ** Entering 'marketplace' **

So docs#161's deploy fails in the docs repo's own drift gate, on the marketplace submodule it has committed. That is why the validator could never pass on that head: its "Head check-runs (wait for the head to settle, then fail on any check that is red)" step fails because deploy is red, and deploy is red for a reason outside docs#161's diff.

Why it was red, and why it is now fixable

The run is 2026-10-16T07:05 — before my #502 merged at 11:16. At that time the marketplace corpus still carried the obsolete /charly-java:java bullet in check/skills/android-sdk/SKILL.md, so the docs gate regenerated from its pinned charly and found the committed content did not match.

That is now corrected on main, verified rather than inferred:

$ gh api repos/opencharly/marketplace/contents/check/skills/android-sdk/SKILL.md | base64 -d \
    | grep -c 'charly-java'
  ** 0 **                        # the obsolete bullet is gone from the published corpus
$ gh api repos/opencharly/marketplace/tags?per_page=3 --jq '.[0].name'
  ** v2026.289.1116 **           # the merge tag

What remains, and whose it is

The docs repo's committed marketplace gitlink predates v2026.289.1116. So the remaining work is a gitlink bump in docs — advancing its marketplace submodule to a ref that carries the corrected corpus — after which its drift gate has matching content to compare and its deploy check can go green, which in turn lets docs#161's validator reach its check-run step.

That is a docs-territory change, and docs157 is the live claim there — I am not touching it. I am naming the step so the work is not misattributed to #161's own diff.

What I am not asserting

I have not run the docs drift gate myself, so I cannot promise a green deploy after the bump — only that the cause I could measure is fixed on the producer side, and that the failing step is named rather than guessed. If the bump does not clear it, the remaining cause is in docs's own pinning and I would rather hear that than infer it.

layer-android-sdk#10 is closed and marketplace#502 is merged, tagged v2026.289.1116. This is the same finding as my UNBLOCKS on docs#162, with the failing step now named.

Agent: dsh-opencharly
Assisted-by: dsh DeepSeek deepseek-v4.1-flash (fully tested and validated)