Repository navigation
Gates for the developer guide defects Asciidoctor cannot see - #5669
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2da41dd8c7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
2da41dd to
28f950b
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 28f950b311
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 21e513112f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Cloudflare Preview
|
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
212956c to
6d0560c
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d0560cc05
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b96d1321a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
6108cad to
e113f04
Compare
b96d132 to
d82c0ea
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d82c0ea525
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
d82c0ea to
42189c3
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 42189c33d9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 89e588ddc8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b88150d821
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
b88150d to
5028cb2
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9e50cb8cc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6a8963d02a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 57212b7f43
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a6bd5197dc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a9c0b73136
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Compared 151 screenshots: 151 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
|
Compared 181 screenshots: 181 matched. |
Four checks, split out of the structural repairs they were written alongside so each can be reviewed on its own terms. Every one was verified to fail when the defect it describes is reintroduced, and to pass again when it is reverted. check-guide-structure.py -- every document is in the book or declared out of it; no chapter silently becomes a part, a subsection, or a duplicate; and, by rendering the book and reading its headings back, every included chapter's title survives into the output. That last check is what would have caught a whole chapter rendering as subsections of the one before it. check-guide-xrefs.py -- every internal link resolves, and none renders as a bare "[some-id]". Asciidoctor reports neither: a reference carrying link text renders as an ordinary link to nowhere. check-missing-code-blocks.py -- prose that promises a listing where a hole follows. 406 exist, from the snippet extraction in bbdc605, recoverable from bbdc605~1. check-guide-links.py -- links checked against the paths the site actually serves, derived from _redirects and the Hugo content tree and followed through every redirect rule to what it produces, rather than accepted for matching one. The two ratchets may only shrink; growing one needs --allow-new, so recording debt is deliberate rather than a side effect of regenerating. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The stacked content change restored the video capture constraints examples, so their baseline entries went stale and the ratchet refused to pass until they were removed. 406 to 402. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The outcome check compared counts of normalized headings at any depth, which a collision satisfies: "Analytics" is a chapter and also a subsection of Commerce, so the rendered book contains it twice. If the chapter were swallowed, the subsection kept the count at one and the check -- the central safeguard of this change -- passed. Measured on the current book: analytics appears twice at any level and once at chapter level; "getting started" four times at any level and never at chapter level. Manifest entries are now counted against chapter-level headings only. Nested fragments still use the any-level count, because their depth is whatever their parent gives them. Second finding: resolves() tried every matching redirect rule and passed if any chain worked. The host applies the FIRST match and stops, so a link matching an early rule that leads somewhere deleted would have passed on the strength of a later rule the reader never reaches. It now returns the first match's result. No guide link changes verdict today; the point is that the model matches the behaviour it claims to model. Also declined, with the reasoning left in the code rather than a review thread: adding Markdown's three-backtick fence to the literal-block list. The guide contains none, and validate-guide-snippets.py requires every listing to be [source,LANG] with a bare include:: inside ---- delimiters, so such a block would fail that gate before reaching this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
When the Javadoc derivation went in I let a class-use/ path through by stripping
the segment and validating the enclosing package, on the assumption that javadoc
emits usage pages alongside the types. It does not, unless asked: the generator's
invocation carries no -use, and run both ways on the same sources javadoc produced
0 class-use directories without it and 1 with it. So the leniency accepted links
to pages the build never writes.
That exemption was my own speculation rather than anything the guide needed --
it links to no class-use page at all -- and removing it needs no special case: the
path names a package that does not exist, which the existing check already
reports.
/javadoc/com/codename1/ui/class-use/Component.html old 0 -> new 1
/javadoc/com/codename1/ui/Component.html new 0
/javadoc/com/codename1/ui/package-summary.html new 0
Index and overview pages are still accepted, because those javadoc does emit
without being asked. Re-validated across the guide: 423 javadoc links, 0 rejected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e54e3f2ceb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Expected titles were built from walker.reachable, which holds each path once, so
a fragment two parents both include expected ONE title while rendering two. The
check asks whether a title appears at least as often as expected, so a swallowed
occurrence hid behind the surviving one. Counted per inclusion now.
Probed by reusing a fragment from a second parent with prose immediately before
the include:
old passed silently
new "appears 1 time(s) in the rendered book but 2 document(s) declare it"
and legitimate reuse -- the same fragment from two parents, both spaced properly
-- still passes. Note the spacing rule does NOT catch this shape: it fires when
the INCLUDED file ends mid-paragraph, and here it is the parent that puts prose
in front of the include.
Separately, check-guide-links.py indexes Ports/CLDC11/src as a Javadoc source
root, because build_javadocs.sh generates from it, but neither documentation
workflow listed it as a trigger -- only its sibling CodenameOne/src. Deleting or
renaming a linked CLDC type could therefore merge unvalidated, and the stale link
would surface in the next scheduled website build, after the fact. Added to both
the pull_request and push filters, next to the root it belongs beside.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bd3fb14d21
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A bracketed attribute line counted as the promised listing, so an anchor in front
of an ordinary paragraph -- [#next-section] and then prose -- suppressed exactly
the defect this gate exists to find. Attribute lines are stepped over now and the
block they attach to is what gets classified.
[#next-section] + prose old 0 -> new 1
[source,java] + ---- new 0
[cols="1,2"] + |=== new 0
A first attempt also stepped over block TITLES, on the same reasoning, and it was
wrong in a way the baseline caught immediately: 33 entries went stale. Reading
them showed why -- "Simple usage of the `Calendar` class looks something like
this:" followed by `.The Calendar component` and an image is a real hole, the
listing having been removed by the snippet extraction while the figure stayed. A
titled figure does not answer a promise of code, and treating the title as
decoration would have banked 33 genuine holes as fixed. Only bracket attributes
are skipped.
One behaviour does change with no instance behind it: an anchor followed by a
titled image now reports, where the anchor alone used to suppress it. That is the
consistent answer -- the 33 above are exactly the untitled-anchor version of the
same shape -- and the guide contains none either way.
Baseline unchanged at 402, none new, none stale.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 298265275b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… at one edge
package-frame.html is a pre-JDK-11 artifact and package-use.html needs -use,
which the generator does not pass -- the same reason class-use/ is not accepted.
Both sat in the accepted set on my assumption rather than on evidence. Running
javadoc --release 8 -protected over a one-class package writes exactly
package-summary.html and package-tree.html, so those two are what the set holds
now. The guide links to none of the four.
package-summary.html accepted
package-tree.html accepted
package-frame.html rejected
package-use.html rejected
The reuse fix in the previous round counted occurrences from the edges pointing at
a file, which stops one level short: a fragment two parents both include renders
twice, and so does everything IT includes, but _visit() returns early on the second
traversal so only one edge exists for each descendant. Occurrences are computed
across the whole graph now -- each node is the sum over its incoming edges of the
parent's count times the edge multiplicity, root = 1 -- with a guard against a
cycle asciidoctor would reject anyway.
Checked on a synthetic diamond (root->a, root->b, a->frag, b->frag, frag->desc):
frag and desc both come out at 2, a and b at 1, and a doubled single edge
propagates as 2. Then on the real book: adding a second parent for
Maven-Appendix-Goals takes it AND its appendix_goal_* descendants to 2, and
removing it returns them to 1.
Note the reviewer's route to this -- a conditional that swallows one occurrence --
is now refused outright wherever it appears, so the scenario is not currently
reachable. The count was still wrong, and it is cheap to be right.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7cbeee17c1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A path without .html was taken for an asset and accepted whatever it named, so
/javadoc/com/codename1/DefinitelyMissing/ passed on the strength of having no file
extension. A directory under the tree is now one of three things: the root itself,
one of javadoc's own asset directories, or a package -- and the package set is
already derived, so nothing new had to be modelled.
A page with no package component was taken for an index page and accepted for the
same reason, so /javadoc/DefinitelyMissing.html passed too. The set javadoc writes
at the root is finite; it is listed now, from a real run rather than from memory.
Four of the eleven -- constant-values, deprecated-list, serialized-form, search --
are emitted only when the sources give them something to hold, so they are
accepted without being required.
/javadoc/ accepted
/javadoc/index.html accepted
/javadoc/com/codename1/ui/ accepted
/javadoc/resources/glass.png accepted
/javadoc/DefinitelyMissing.html rejected
/javadoc/com/codename1/DefinitelyMissing/ rejected
/javadoc/com/codename1/impl/ARImpl.html rejected
Both hatches were mine, written when the derivation went in to avoid false alarms
on shapes I had not enumerated. Enumerating them costs a javadoc run. 423 links in
the guide, 0 rejected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d45e1dae50
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The trailing-slash rule asked whether _redirects spells the path out literally,
and three of its sources are wildcards that end in a slash -- /*.html/,
/blog/*.html/ and /demos/*/. So /download.html/, which that first rule really does
cover and really does serve, was reported as broken. A false positive on a working
route is the worse half of this gate's failure modes: it blocks the workflow on
prose nobody needs to change.
The sources are compiled a second time for this, anchored exactly rather than
with the "/?" the routing patterns carry. That leniency is right for asking "does
this resolve" and wrong for asking "does the table declare THIS spelling":
/*.html/ covers /download.html/ and does not cover /download.html, and a
slash-insensitive match cannot tell the two apart.
/download.html/ old 1 -> new 0 (wildcard covers it)
/videos.html/ new 0 (literal, as before)
/files/CodenameOneBuildClient.jar/ unchanged (nothing declares it)
/blog/ new 0 (a directory route)
One probe needed a second look: a real blog post with .html/ passed both versions,
because that post has its own literal rule in the table -- the wildcard is
belt-and-braces there rather than the thing being tested. /download.html/ is the
case with no literal behind it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 102bd459e3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Accepting anything whose first segment was legal/, resources/ or script-dir/ was
the last of the "looks about right" hatches: /javadoc/resources/does-not-exist.js
passed on the strength of the directory name.
The reviewer's suggestion is to validate the full path against the generated file
set, and that is the one option I will not take. Those directories hold javadoc's
own plumbing and their contents are version specific -- a JDK 17 run here writes
jquery-3.6.1.min.js, and the tree this actually gates is generated by JDK 25,
which ships a different one. Listing them would be asserting the contents of a
tree this repository does not build, and it would rot at the next JDK bump.
So a path into one is rejected instead. The guide links into none of them, and
documentation prose has no business pointing at javadoc's internals; if that ever
changes, the fix is to link to the documented page rather than to its stylesheet.
/javadoc/ accepted
/javadoc/index.html accepted
/javadoc/com/codename1/ui/ accepted
/javadoc/com/codename1/ui/Form.html accepted
/javadoc/resources/glass.png rejected
/javadoc/resources/does-not-exist.js rejected
423 guide links, 0 rejected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 79cb5e9dff
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Restricting the attribute skip to bracket lines last round introduced a false
positive: `.Example` in front of [source,java] stopped the walk, and a block title
is not a block start, so a perfectly good titled listing was reported as a missing
one. [[anchor]] had the same problem. Both are metadata attached to the block
below them and are skipped now.
Skipping titles is what I tried first last round and reverted, because it turned
33 baseline entries stale. The reason it did is the actual defect underneath:
image:: counted as an answer to a promise of CODE, so whether a hole was reported
depended on whether the figure happened to carry a title -- titled ones were
caught, untitled ones were not. A figure is not a listing either way, so image::
is out of the block set and the two cases agree.
That surfaces two holes that were hidden, and both are real:
Maps.asciidoc:132 "...for example \"try the native Google SDK,
then the web map, then the vector MapView\":"
followed by a screenshot
Miscellaneous-Features.asciidoc:465
"...use the Media, MediaManager and
MediaRecorderBuilder APIs to capture audio:"
followed by a screenshot
Baseline 402 -> 404. Growing a ratchet needs justification: these are not new
debt, they are debt that was being hidden by a rule that could not tell a figure
from a listing.
.Example + [source,java] + ---- old 1 -> new 0
[[sample]] + [source,java] old 1 -> new 0
.A figure + image:: unchanged, still a hole
Separately, a chapter whose own title sits inside a backend conditional has no
title in the branch that excludes it, and its body merges into whatever precedes
it -- which one render cannot show, since first_heading() reads the source and the
HTML render contains the title. Rather than render the book twice for a construct
the guide does not use (measured: zero headings inside a backend conditional), the
construct is refused.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: abdb22b6e6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
javadoc writes package-summary.html and package-tree.html into a package
directory and nothing else, so /javadoc/com/codename1/ui/ is a 404 however real
the package is. Accepting any directory whose package existed was the last of the
directory-shaped hatches. Only the tree root is a destination now: it does have an
index, and build.sh moves that aside to render a Hugo page in its place.
/javadoc/ accepted
/javadoc/com/codename1/ui/package-summary.html accepted
/javadoc/com/codename1/ui/Form.html accepted
/javadoc/com/codename1/ui/ rejected
/javadoc/com/codename1/Nope/ rejected
Measuring this nearly went badly. `grep -o 'javadoc/[^ \[]*/'` reports 40 package
directories, and every one is an artifact: the pattern matches the longest run
ending in a slash, so a class link like .../capture/Capture.html contributes
".../capture/". Extracting whole URLs instead gives 418 page links and 5 directory
links, and all five are /javadoc/ itself. I had a rewrite ready for those 40 --
it changed nothing only because its own pattern was stricter than the grep that
found them. No guide content is touched here.
Also worth recording from the same reading: JDK 25 puts javadoc's assets in
resource-files/, not the resources/ and script-dir/ that a JDK 17 run produces.
That is exactly why the previous commit rejects asset paths instead of listing
them -- a list taken from the JDK to hand would have been wrong on arrival.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c75a568ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…t agree
The refusal for attribute-built targets recognised link:{...} only, so
xref:{root}does-not-exist and <a href="{root}x"> slipped past it -- the same three
spellings the root-relative extractor already had to learn one at a time. All
three are refused now, from one pattern rather than three.
xref:{root}does-not-exist[label] old 0 -> new 1
link:{root}does-not-exist[label] unchanged
<a href="{root}x"> old 0 -> new 1
an ordinary URL new 0
And _visit() records the attributes of the FIRST inclusion and returns early on
every later one, so a fragment brought in twice -- once with leveloffset=+1, once
without -- was validated against whichever parent happened to come first, while
its heading rendered at two different depths and one of them could be a part
rather than a section. Attributes are collected per target now and a disagreement
is reported, which is the same answer this checker gives everywhere else it cannot
model two spellings of one thing.
included twice with different leveloffsets old 0 -> new 1
included twice with the same attributes new 0
Neither construct is in the guide: no attribute-built target of any spelling, and
no fragment with two parents at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b540251816
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A public type tagged @hidden gets no page at all -- confirmed by generating docs for a two-class package where the tagged one produced no HTML. Two such types sit outside com.codename1.impl and were therefore in the index: com.codename1.vpn.tunnel.TunnelBuffers and TunnelHost, both public, both marked "@hidden not part of the public API". A link to either would have passed. The tag is read from the ORIGINAL source at the declaration's offset, because blank_java_noise has erased the comment by the time the declaration is located, and both comment styles occur in this tree -- /** */ and the /// markdown form these two use. TunnelBuffers, TunnelHost no longer indexed VpnTunnel, TunnelConfiguration still indexed 1845 public types -> 1843 423 guide links, 0 rejected Measuring this went wrong twice before it went right, both times in the throwaway script rather than in the checker. First it looked for /** */ only and reported zero, missing both files because they use ///. Then, with /// handled, it still missed TunnelBuffers: the declaration regex matched the word "public" inside the sentence "it is hidden rather than public API", and [^;{]* happily spanned the newlines to the real declaration below. That is precisely the hazard blank_java_noise exists for, and the measurement was not using it -- so the real implementation locates the declaration in the blanked text and reads the comment from the original. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: abce72f96f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The spacing rule guarded one side only: it asked what FOLLOWS an include and how
the included file ends. Prose immediately BEFORE an include absorbs that file's
first heading just as surely, and the rendered-title check cannot see it when
another file shares the title -- "Getting started" is in this book three times, so
losing one still leaves the count above the single expected occurrence.
This is the finding I answered earlier by pointing at the cause-level rule, and I
was wrong: that rule does not cover this shape. It does now, with the same
exemptions, established the same way:
prose, no blank line SWALLOWED
prose, with leveloffset renders
blank line before renders
after a closed literal block renders
directly after a heading renders
directives between them SWALLOWED (they vanish; look past them)
A/B against the real book, putting prose in front of the Maven-Getting-Started
include:
headings for "Getting started" 4 -> 3 (one swallowed)
old gate passed
new gate fails
Only reported when the included file actually starts with a heading, which is what
there is to lose. That exempts the one instance in the guide today:
Advanced-Topics-Under-The-Hood puts ".Build hints" in front of
_generated-build-hints.adoc, and that file opens with comments and a table, so
nothing is absorbed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Compared 144 screenshots: 144 matched. |
|
Compared 148 screenshots: 148 matched. Benchmark Results
Detailed Performance Metrics
|
|
Compared 149 screenshots: 149 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
|
Compared 217 screenshots: 217 matched. |
|
Compared 143 screenshots: 143 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Split out of #5664 so the structural repairs there stop waiting on tooling review. Stacked on it, because these checks are written against a guide that #5664 fixes — run them on master and several fail by design.
Four checks. Each was verified to fail when the defect it describes is reintroduced, and to pass again when it is reverted.
check-guide-structure.pycheck-guide-xrefs.py[some-id]check-missing-code-blocks.pycheck-guide-links.pyHow the link checker decides
It does not carry a list of good links. It derives what the site serves and follows the rules to what they produce:
_redirectssources compiled to patterns, splat and:placeholderincluded, then followed to their destination rather than accepted for matching./*.htmlmatches every root-level.htmlpath there is, so a match proves nothing.url,slug,aliases— because 1055 of the 1262 content pages override their route withslug, and deriving it from the filename both invents routes and rejects real ones.buildDraftsandbuildFutureto false.index.htmlis not a route./developer-guide/derived from whatscripts/website/build.shrsyncs. Only/javadoc/stays exempt, because it is produced from the framework sources and cannot be enumerated here.Ratchets
check-missing-code-blocks.pyrecords 406 existing holes andcheck-guide-links.py38 bad links. Both are multisets — one line per occurrence, because a file naming the same bad URL twice has two problems.Both may only shrink. A fixed entry that is still baselined fails, so the ratchet actually banks its fixes; growing one requires
--allow-new, so recording new debt is deliberate rather than a side effect of regenerating.Where they run
developer-guide-docs.ymlruns all four.check-guide-links.pyalso runs fromwebsite-docs.yml, which triggers ondocs/website/**— a page renamed or re-slugged there breaks the guide, and putting those paths into the guide workflow would run the whole guide build, maven install and screenshot generation included, for every blog post the daily publisher pushes.The
docspaths filter now coversscripts/developer-guide/**rather than two named files, because a change to a script not in that filter started the workflow while skipping the steps that script governs.