docs(pcapkit,ci): cite the issue a defect belongs to, not the pull request (#719)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (comment/docstring-only diff; no code paths changed)

• make test passes, and a test case covers the change — targeted pytest per touched module, all green (see below); never ran the whole suite

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• docs — documentation only

---

Description of your pull request and other information

Implements the owner's ruling on #719: cite the issue a historic defect belonged to, not the pull
request that fixed it. 45 files: 34 under pcapkit/, 9 under tests/, 2 under .github/.
The tests/ half was not in the original scope and was added in review -- tests/ had never
been swept, and holds 97 verbatim lines across 52 files against pcapkit/'s 48 across 30, so
the unswept body was larger than the swept one. It turned up a quotation attributed to the owner
that exists in no thread, a second spliced from two, and a typo silently corrected under a
verbatim label.

• 92 real pull-request citations found in pcapkit/ (93 was the estimate; the gap is false-positive
  #NNN matches on RFC packet diagrams like DH GROUP ID #1 and hex format specs like
  {spi:#010x}, plus one cross-repo JarryShaw/DictDumper#125 citation that is itself an issue, not
  a PR, in its own tracker). All replaced with the issue each PR closed, or a plain description where
  none exists.
• 13 pull-request citations found in .github/workflows/, matching the estimate exactly.
• Several citations named two or three numbers for one claim where a PR closed multiple issues, or
  multiple PRs closed the same issue; deduplicated so the prose does not read "Option, chunk and block registries leak on lookup miss, the same way __proto__ did #425 and Option, chunk and block registries leak on lookup miss, the same way __proto__ did #425".
• All issue references left untouched.

Verified: tests/corekit, tests/vendor, tests/const, tests/foundation/registry,
tests/protocols/{application,link,misc,schema,transport,internet}, tests/utilities and
tests/project all pass against this worktree (confirmed via pcapkit.__file__). One real mismatch
surfaced along the way: pcapkit/vendor/reg/apptype/apptype.py and
pcapkit/const/reg/apptype/apptype.py must stay byte-identical in the generated get() region, and
a wrapping difference between my two edits broke that — caught by
test_enum_get_exception_provenance_923_unit.py, fixed, reverified. Both edited workflow YAML files
parse with yaml.safe_load before and after with unchanged key counts.

[JarryShaw]

NEEDS CHANGES at bd73c9927 — sonnet cross-review, round 5. One real defect, and a coverage gap
that matters more than the defect.

pcapkit/corekit/sentinels.py:459 cites the wrong issue for its ruling. It reads "The owner's
ruling on #937, verbatim" for the _ABSENT → ABSENT quote. The ruling was given on #719, and
#937 itself says so — I measured both channels: #937's body carries the quote exactly once, under
the caption **The owner's ruling, verbatim** (from #719):, so it re-quotes and attributes onward;
#719 has it twice, once as the owner's own comment and once as my recording of it. By this page's own
rule (documentation.rst:196-200 — cite the issue a rule was settled on) it must be #719. A worker is
re-pointing it; the neighbouring clause "#937 normalised every sentinel object" is a correct
descriptive claim and stays.

One correction to the review: it reported the quote as absent from #937 entirely. It is there once,
as the attributed re-quote. The conclusion is unaffected.

The partition disagreement resolves at 18/30, and the boundary is as fragile as suspected. Three
independent counts now agree on 48 occurrences across 30 files. On the claim/descriptive split it
measured 18/30 against the author's 17/31 and my earlier 13/35. The single site between 18 and 17 is
enum.py:87, whose sentence carries no #NNN of its own — the nearest number is 31 lines earlier, past
an intervening #775. It counts as a claim because it is checkable, and it checks out. So a regex keyed
to "#NNN near verbatim" would have dropped a real, verifiable claim.

The marker misses a family nearly as large as the one it catches. Searching the italic-quote pattern
instead found 16 sites across 5 issue numbers that attribute a quote to a #NNN with no "verbatim"
anywhere near it — invisible to every sweep so far. All 16 verified sound. That is luck rather than
coverage: a miscitation in this style would sit undetected indefinitely. A further tail
(enum.py:438,489,580,584,585) quotes "the ruling" with no number at all, so there is nothing to grep.
Both belong on #719 as scope, not here.

Spot-checks all sound: #911, #860 (and its const/ mirror), #882, #877 ×4, #842 ×2. Tests at this head
re-run independently — test_enum_get_exception_provenance_923_unit.py 33 passed / 6 subtests,
tests/vendor 9 passed, test_mh_unit.py 52 passed / 499 subtests. It caught the editable-install trap
first: PYTHONSAFEPATH=1 alone resolved pcapkit to the shared checkout on main, so it set
PYTHONPATH and reprinted pcapkit.__file__ before trusting a number.

UNVERIFIED: the 6 const/ mirrors of the unmarked family (confirmed by byte-identical text against
their vendor/ counterparts, not re-queried); the five numberless quotes; and the round-4 fixes, beyond
the diff showing them intact.

[JarryShaw]

sentinels.py fix pushed at c65f16074, and the sweep's scope turns out to have a hole twice the
size of the swept set.

The attribution now reads "the owner's ruling on GitHub issue #719, verbatim". I verified the pushed
diff myself: one file, 7 insertions / 7 deletions, the quote itself byte-unchanged and the paragraph
re-wrapped to the file's own ≤78-char prose width. The five other #937 mentions in the file are
descriptive claims about what #937 did — renamed the objects, dropped the underscore — and correctly
stay. tests/corekit/ 400 passed, 16 skipped, 658 subtests; pylint 9.77/10, its one finding
(R0903 on NoValueType) pre-existing and untouched.

tests/ was never in scope, and it holds more of this than pcapkit/ does. Measured just now:
96 verbatim occurrences across 52 files under tests/, against the 48 across 30 files that four
rounds of review swept. I found a defect there by accident while checking whether any test pinned the
citation I had just changed — tests/corekit/test_sentinel_exports_unit.py:49 carries the same quote
under the same wrong attribution to #937. A worker is now sweeping all 96, with the confirmed fix
first.

One ambiguous case I am not deciding — pcapkit/corekit/sentinels.py:490. It reads "see
:class:AbsentType's own docstring for why, per GitHub issue #937". The documented-privacy state it
describes is #719's ruling, but #937 is what carried it out, so "per #937" is defensible as naming the
executor. The rule on documentation.rst:196-200 points at #719. Which reading do you want — cite
where a ruling was given, or allow "per #NNN" to name the change that implemented it? It decides a
family of sites, not just this one.

CI at bd73c9927 was fully green (59 CheckRuns, 0 fail) before this push; review: pending holds for
the new head.

[JarryShaw]

The tests/ sweep found six more miscitations — and one quote that appears to have been invented.
f334953a8 on top of c65f16074, six files, +57/−56. The invented quote is the finding that matters, so
it leads.

A sentence presented as the owner speaking verbatim exists nowhere. Four times in
tests/const/test_const_enum_no_mint.py (lines 148, 594, 1290, 1540) the prose reads "the owner's
ruling, verbatim: "Preserve each branch's existing name argument exactly as the current code produces it
-- this change is about not registering, not about renaming anything."" I searched #775's full thread,
#847, #861 and #878 — body, issue comments, review comments, review bodies — and that text is in none
of them. The only near-match is PR #878's own body, written by the implementer, in materially
different words:

Preserving each branch's existing hex-suffixed name — required, since this change is about not
registering rather than renaming —

So a paraphrase of the pull-request author's prose has been dressed as a verbatim quotation from you, and
repeated four times. That is a different and worse defect than a miscitation: a wrong issue number
points somewhere checkable, while this points at something that was never said. It is also exactly what
the #949 ruling against quoting you was meant to prevent. The sweep escalated it rather than inventing a
citation, which was right. I am not fixing it until you say how — the honest options are to delete
the quotation marks and attribute the constraint to #878 as the implementer's own reasoning, or to drop
the sentence. tests/vendor/test_ipx_socket_unit.py:124 already carries the same constraint in the honest
form — paraphrased, unmarked, attributed to "the owner's ruling" — which is a useful model.

The six fixed sites are all the same shape as the one I confirmed earlier: the quote lives in the pull
request, not the issue it cites.

file	cited	actually in
test_sentinel_exports_unit.py:49	#937	#719
test_enum_lookup_reparent_930_unit.py ×4	#935	PR #940
test_mh_unit.py (second ruling)	#935	PR #940
test_vendor_snapshot_restore_unit.py:7	#872	PR #873
test_vendor_reg_apptype_generator_unit.py ×2	#860	PR #874
test_const_enum_no_mint.py:27	"decided on #775, carried out on #847"	reversed — settled on #847, confirmed on #775
test_const_enum_no_mint.py:1208	"#775's Q1 follow-up"	PR #838

The reversal is nicely evidenced: your own comment on #775 says the ruling discussion was in #847, and PR
#861's body independently states it the corrected way.

Tests at this head: tests/corekit 400 passed / 16 skipped, tests/vendor 118 passed, tests/const 299
passed / 40,424 subtests, test_mh_unit.py 52 passed / 499 subtests. Five pre-existing failures in
tests/protocols/internet/ are un-generated examples/captures/ fixtures, unrelated.

Still waiting on your two earlier calls: the sentinels.py:490 "per #NNN" reading, and now this.

[JarryShaw]

What exactly needs my decision and what's your recommendation?

[JarryShaw]

Four, and I have a recommendation for each. Shortest first.

1. #984's first commit subject (0d2a20cc8) still says "catch pytest-subtests-masked ordering
defects" — the claim its own second commit refutes. I already fixed the PR title.
Recommendation: do nothing, and squash-merge. The repo has squash_merge_commit_title = COMMIT_OR_PR_TITLE, so the subject landing on main comes from the corrected title. Rewriting the branch
costs a force-push to fix a line no one will read again.

2. The invented quote — 4 sites in tests/const/test_const_enum_no_mint.py (148, 594, 1290, 1540).
They say "the owner's ruling, verbatim:" and then quote a sentence that is in none of #775, #847, #861 or
#878. The only near-text is PR #878's own body, written by the implementer, in different words.
Recommendation: de-quote. Drop the quotation marks and the word verbatim, and state the constraint as
the reasoning recorded on #878 — which is what it actually is.
tests/vendor/test_ipx_socket_unit.py:124 already does exactly that and reads fine. The constraint itself
is true and the tests around it pass; only the attribution is false.

3. pcapkit/corekit/sentinels.py:490 — "see AbsentType's own docstring for why, per GitHub issue
#937". #719 gave the ruling, #937 carried it out. Recommendation: a two-way rule rather than a one-off
fix — if a sentence attributes a ruling, cite the issue where it was given; if it describes what
changed, cite the issue the change belongs to. By that test :490 is about the why, so it becomes #719.
This settles a family of sites, not one line.

4. #983, terse versus trimmed. Recommendation: keep terse — i.e. nothing changes. You ruled at
22:53Z that you prefer the output handled, and I think that still holds: trimmed prints the caller's frames
(7 lines plain, 14 chained) instead of 1 and 3, and it would discard a working, tested change for one line
removed from pcapkit/__init__.py:93. The chained and thread regressions the reviews found are already
fixed and measured. I raised trimmed only because I had not put it to you; I am not advocating it.

Say "all four as recommended" and I will take it, or override any one.

[JarryShaw]

1. sure, i'll squash merge;
2. de-quote, it might happened off the book. we can paraphrase them and still, avoid verbatim quotes.
3. sounds good with your plan
4. keep terse.

[JarryShaw]

NEEDS CHANGES at f334953a8 — opus, round 6. All seven fixes are sound. The verdict rests on four
things outside them, and the worst is a quote that was not merely miscited but altered.

Method worth stating, because the negative results depend on it: it pulled the whole repo comment corpus
— 2047 issue comments, 334 inline review comments, 981 issue/PR bodies = 3362 items — extracted all 170
quoted spans from 742 .py files, filtered to the 95 attributed to you or to a "ruling", and matched
each against the corpus. So "appears nowhere" means nowhere in 3362 items.

1. tests/corekit/test_sentinel_exports_unit.py:4-5 — wrong thread and the quote's meaning changed.
I verified both halves. You wrote, on #719 (05:07:50Z):

we should ONLY export the objects (like NULL) to __all__, and leave the types (like NullType) out.

The tree renders it, under "The owner's ruling, verbatim", as "…we should ONLY export the objects (like
NULL ) to users." — the second half deleted and __all__ replaced by users. That is not a
paraphrase slip: __all__ is a checkable claim about a module attribute, "users" is an interpretation. The
"to users" wording traces to #916's body, a derived issue re-quoting it. And it is cited to #911, which
was filed from that #719 comment — the exact pattern #937 had. tests/const/test_const_registry_protocol.py:1363
carries the same altered text.

2. The fabricated quote is confirmed as the only outright invention. It matches one item in 3362 —
my own comment reporting it. But its recommended remedy is better than mine: #878's body already says
the thing in quotable words, so quote that, verbatim, attributed to #878 as the implementing pull
request's own design note, rather than dropping to unquoted prose. It keeps a checkable referent, which is
the whole point of #719. Two hard constraints: the attribution must not say "the owner" or "ruling" — it is
the implementer's scope decision — and "verbatim" must not survive near it.

3. A third family: your typo is silently corrected under a verbatim label. On #860 you wrote "we need
register to properly create new entires". I re-derived the count and got 12 sites across 8 files,
not the 10 reported — apptype.py carries it twice in each of its two copies. Zero render your actual
word. Meaning-preserving, so low severity, but it shows "verbatim" is applied loosely well beyond the one
invented quote. This needs your call: restore the typo, mark it [sic], or de-quote.

4. Introduced by this commit — test_enum_lookup_reparent_930_unit.py:579. The fix changed the
sentence's subject to #940, but "the owner's final ruling there" still has #935 as its nearest
antecedent, so "there" is now wrong and contradicts its own opening. One word: "on #940".

On "per #NNN" it argues against my recommendation, and convincingly. Prose must point at three distinct
things — where a decision was settled, what carried it out, and where a defect was reported — and collapsing
them makes a reader hunting the rename land on a 61-comment prose sweep that does not contain it. So keep
#937 at sentinels.py:490; the defect is the preposition. Its rule: a sentence with "ruling" or
"verbatim" names the deciding thread; one with an action verb — "landed in", "renamed in", "filed as" — may
name the executing pull request, and "per" is reserved for the former. That is grep-checkable and
belongs on the conventions page. I withdraw my earlier recommendation in favour of it.

One more it flagged: pcapkit/ and tests/ now carry two different remedies for one defect class —
pcapkit/ says "in review of the work for #935", tests/ says "on pull request #940". Both honest, the
latter more checkable. One conventions line, or round 7 relitigates it.

UNVERIFIED by it: repo-wide PR review submission bodies (no bulk endpoint; it fetched all 15 cited threads
individually); commit messages; Discussions #106 and #251; and it ran no tests.

[JarryShaw]

All four taken. needs: decision is off #982 and #983, and #983's held cross-review is dispatched.

1. Squash merge — nothing to do; the corrected title is what lands.
2. De-quote and paraphrase, avoiding verbatim quotes. Taking your "it might happened off the book" as
   the general case rather than an excuse for the one site: a quote that cannot be produced from any thread
   is unverifiable even when it is a faithful record of something said elsewhere, so paraphrase is the only
   honest form. This reaches further than the four fabricated sites, and I am scoping it deliberately:
   this pull request fixes the sites it already touches, and I will file the full sweep as its own issue
   rather than letting docs(pcapkit,ci): cite the issue a defect belongs to, not the pull request (#719) #982 grow a third time. Round 6 counted 95 owner-attributed quote sites across
   tests/ and pcapkit/; converting them all is not a tail-end amendment to a citation fix.
3. Keep terse — confirmed, and the cross-review is now running on afa7435ac.

On 3, I have to flag a conflict rather than just take the approval, because you ruled before seeing a
refinement that arrived a minute later. Your "sounds good with your plan" answers the plan I posted at
02:37Z: a ruling cites where it was given, a change description cites the issue the change belongs to.
Round 6 then argued for something subtly different — keep #937 at sentinels.py:490, fix only the
preposition, and let action verbs ("landed in", "renamed in", "filed as") name the executing pull
request.

I withdrew mine in its favour too quickly. Its version conflicts with #719's own ruling, which is to
cite the issue and not the pull request — so "landed in PR #940" would reintroduce exactly what this PR
removes. The part of it worth keeping is the diagnosis: at :490 the defect really is "per" reading as
authority rather than provenance, not the number.

So unless you say otherwise I will take the #719-compliant merge of the two: a sentence attributing a
ruling names the deciding issue and may use "per"; a sentence describing what changed uses an action
verb and names the issue the change belongs to, never the pull request. That keeps your approval intact,
keeps #719 intact, and still fixes :490. One line on the conventions page, grep-checkable.

The typo family is resolved by your ruling 2 — paraphrase removes the question of whether to reproduce
entires, mark it [sic], or correct it silently. 12 sites across 8 files by my count, not the 10
reported; apptype.py carries it twice in each of its two copies.

[JarryShaw]

The de-quote work is pushed at 0a2fcc033 — 5 files, +40/−42, all under tests/. I verified it is
prose-only: tokenising each file with comments and docstrings stripped gives an identical sequence before
and after (5520, 11629, 7511, 3280, 1517 tokens). The fabricated text and the "to users" text are both now at
zero occurrences.

The fabricated quotation is gone from all four sites, replaced by paraphrase attributed to PR #878 as the
implementing change's own scoping — no "owner", no "ruling", no "verbatim" near any of them. The altered
quotation at two sites now says what #719 actually settled: a module's __all__ lists a sentinel's object,
never its type, with #911 named only as what carried it out.

It found and fixed something I had not briefed, which was the right instinct: a downstream sentence read
"which is what the ruling means by 'to users'" — a back-reference to wording the fix removes. Left alone it
would have pointed at nothing. That is this pull request's recurring failure mode and it caught it unprompted.

The 12-versus-8 count is now explained rather than just reconciled. The eight pcapkit/ sites keep the
phrase on one source line, so a plain grep finds them; the four in test files wrap it across a docstring line
break, so only a whitespace-flattened scan sees them. Both of my numbers were right, measuring different
things. The eight pcapkit/ sites are untouched as instructed — six sit in generated const/vendor pairs
that must stay byte-identical in their generated regions.

One claim I want independently confirmed before I rely on it. It reports 5 pre-existing failures in
tests/corekit under unittest discover — sentinel-identity assertions like <NO_DEFAULT> is not <NO_DEFAULT> — and demonstrated they are unaffected by swapping the files back to their original content and
getting an identical result (same 400 tests, same 5 ids, 210.0s vs 211.8s). That number matches the
limitation purge_modules's own docstring documents and matches what a #984 reviewer measured independently,
so it is almost certainly the known case rather than a new one — but "almost certainly" is why round 7 is
checking it rather than me asserting it.

Filed #987 for the rest, so this pull request does not grow a seventh time:
https://github.com/JarryShaw/PyPCAPKit/issues/987. It carries the measured scope — 95 owner-attributed
quote sites across tests/ and pcapkit/ — the three defect classes found inside that set, and the
remainders as a list rather than a search: the eight pcapkit/ typo sites, two further "I prefer (2) directly" quotations left here as out of scope, and pcapkit/corekit/sentinels.py:490 where "per #937" reads
as authority rather than provenance. It also records that the verbatim marker does not bound the
problem — 16 sites attribute a quotation to a #NNN with no marker near it, and five quote "the ruling"
with no number at all.

Round 7 is running on a different model from the author, briefed that a paraphrase is a new claim: a
plausible-sounding one that subtly misstates a ruling is worse than the quotation it replaced, because nothing
is left to check it against.

[JarryShaw]

NEEDS CHANGES at 0a2fcc033 — opus, round 7. Two findings, and both correct me rather than the worker.
I verified each at source before writing this.

1. "to users" was never fabricated — it is your wording, on #911. At 2026-09-29T05:14:12Z you wrote "The
general idea is that we only expose the final objects to users." So the original defect was a splice:
#719's export sentence with #911's tail, cited to one issue. I told you that quote had been "altered" and
that its meaning was changed. It was a mis-citation, and the right repair was re-citation, not paraphrase —
which has now deleted a verifiable quotation instead of fixing its pointer.

2. A fifth site of the fabricated ruling survives — and I held it up to you as the model. At
tests/vendor/test_ipx_socket_unit.py:124-125: "(the owner's ruling: preserve the existing name argument
exactly, this is about not registering, not about renaming)". I described that line to you as "the same
constraint in the honest form … which is the model". It is the same false attribution, merely unquoted.
A repo-wide grep confirms it: one survivor outside the repaired four. Being fixed now, along with one more:

3. The downstream edit I praised is grounded on the wrong ruling. test_sentinel_exports_unit.py:34-35
now says ABSENT staying out of __all__ is "consistent with the #719 ruling that only the object goes
in". There are two #719 rulings and it cites the one that argues the opposite — ABSENT is an object,
so read literally the export ruling puts it in. The ruling that actually supports the sentence is the
privacy one, quoted fifteen lines below in the same docstring. Being re-grounded.

Ten of the twelve changed passages are sound, including all four #878 paraphrases, the #719/#911 split
(#719 decides, #911 executes — your own thread says "Filed as #911"), and the antecedent fix at :579,
where the review confirmed option (2) was "delete both get overrides … rather than widening them". One
drifted: test_const_enum_no_mint.py:87-90 drops your load-bearing first sentence — "I think we should
not mint on get still actually" — and recasts get() coverage as an inference when you ruled it directly.

The tests/corekit 5 failures are confirmed pre-existing, and better than by a second run: purge_modules's
docstring documents exactly that count at b337cdbc2, and the token-identity proof shows no test reads the
prose that changed. One pre-existing imprecision in that docstring — the 5 span two classes, not one.

It also found three "I prefer (2) directly" quotations, not two. #987 updated.

One thing I want your view on, because it narrows your ruling and I think the narrowing is right. Its
proposed rule is paraphrase only what cannot be sourced; re-cite what can. The evidence for it is
concrete: paraphrase was a clear win on the fabrication, where nothing was checkable, and a clear loss on the
sentinel case and on #860, where your words were sourceable and are now gone — replaced by prose that presents
your direct ruling as an inference. Blanket paraphrase weakens the strong cases to repair the weak ones. Do
you want that narrowing? It changes #987's scope from "convert 95 sites" to "convert only what cannot be
sourced", which is a much smaller and better-aimed job.

[JarryShaw]

Both round-7 findings fixed at b13728402, verified prose-only by token identity (1517 and 1293 tokens,
unchanged on both files).

Zero survivors of the false attribution, re-derived at the ref rather than in my working tree — which
matters, because my first check found one and that was my own error: the main checkout sits on main,
where the fix does not exist. git fetch moves the remote ref and leaves the tree alone.

The fifth site now reads "PR #878 scoped the change this way: preserve the existing name argument exactly,
since this is about not registering rather than about renaming" — the house phrasing lifted from the four
repaired sites rather than freshly invented. And the ABSENT sentence is re-grounded, with a detail better
than what I asked for: instead of silently swapping the citation it now says why the export ruling does not
apply — "not under the export ruling, which argues the opposite for an object like this one, but under the
privacy ruling quoted below". A reader who wondered about the obvious objection gets it answered.

The tests/vendor failure it reported was #985, and it is no longer reachable — #986 merged as
6f41995b8, so this branch only needs main merged in. It flagged the failure plainly rather than reporting
clean, which was right.

This head is MERGEABLE/BEHIND and still carries needs: decision on the paraphrase-versus-re-cite
narrowing, so I am not calling it ready.

[JarryShaw]

what needs my decision and your recommendations?

[JarryShaw]

Do the narrowing.

[JarryShaw]

On second thought, narrowing does not help ppl w/n context to read them. Paraphrasing with context and references would be better actually.

[JarryShaw]

The narrowing is applied at 9bd738dd3 — 4 files, +37/−24, and I verified it prose-only by token identity
on each (5520, 11629, 7511, 1517, all unchanged).

Your words are back, cited where you actually said them. The export rule is now two quotations rather
than the splice the original had: #719's "we should ONLY export the objects (like NULL) to __all__,
and leave the types (like NullType) out", and separately your #911 framing "The general idea is that we
only expose the final objects to users." The prose says plainly that #911 is both the executor of #719's
ruling and the source of that second sentence, rather than hiding the dual role.

The #860 ruling is restored at all four sites with its first sentence intact — "I think we should not mint
on get still actually" — which the paraphrase had dropped, turning your direct ruling into a derivation.
Your typo is reproduced and marked [sic], which is the only honest form once it is a quotation again: it
keeps the text matchable against the thread and makes clear the spelling is yours rather than the repo's.

I checked the quotations against the threads myself rather than trusting the report. All six fragments
substring-match after normalising whitespace and reST markup: #719 ×2, #911 ×1, #860 ×3.

The four PR #878 paraphrases are untouched, correctly — that text exists in no thread, so there is nothing
to re-cite and paraphrase remains the only option there. One correction to my own check: I first counted
three of those four sites and briefly thought one had been lost. My pattern missed a line-wrapped instance at
:594. That is the second time a wrapped phrase has made two counts in this pull request disagree — the
12-versus-8 typo count was the first — so the lesson is now recorded: flatten whitespace before counting
anything in these files, and state the method beside the number.

tests/const 299 tests OK, test_conventions_doc_claims 38 OK, and tests/corekit's 5 failures match the
documented pre-existing baseline exactly.

Round 8 is running on a different model, briefed to check exactness rather than substring presence — the
original defect was a splice of two real sentences, so a quotation that drops a clause or joins two sentences
would reproduce it in a new place. It is also asked whether the inconsistency this creates is a defect worth
tracking: tests/ now carries a [sic] quotation while the eight pcapkit/ sites still silently render
entries. Those are out of scope here and tracked on #987.

[JarryShaw]

On second thought, narrowing does not help ppl w/n context to read them. Paraphrasing with context and references would be better actually.

We should keep the docs and comments like statements, not conversations. Verbatim quoting is making it read like a discussion, not a documentation.

[JarryShaw]

GOOD TO GO at 9bd738dd3 — opus, round 8. The commit itself is defect-free; the one required change was
in the pull-request body, and I have made it.

The body claimed its own scope falsely. It read "Scope is pcapkit/** and .github/workflows/** only"
while the pull request touches 45 files: 34 pcapkit/, 9 tests/, 2 .github/ — I counted via the
paginated files API. On a change whose entire subject is citation accuracy, merging a body that misdescribes
its own diff is self-undermining, and the body is what the merge records. It now states the real counts and
says why tests/ was added in review: that body had never been swept and is larger than the one that
was — 97 verbatim lines across 52 files against pcapkit/'s 48 across 30 — and it is where the fabricated
quotation, the splice, and the silent typo correction were found.

All 8 restored quotations are exact, not merely substring-matching — the check I asked for. No clause
dropped, no reordering, no elision, at any site. It also corrected two of my numbers: I said "six fragments,
#911×1, #860×3"; it is 8 spans across 6 docstrings, with #911 twice and #860 four times. My own prose said
"four sites" for #860, so I contradicted my own list.

The one deviation is honest and minor: your paragraph break between the first and second sentences of the
#860 ruling renders as a space. Three sentences, your order, nothing elided — materially unlike the original
bug, which spliced sentences from two different threads. A ¶ marker would be more faithful; not worth a
round.

Its judgement on why this round was clean is the part worth keeping, and it is not "the author was more
careful". Five of seven earlier rounds had a fix introduce a new false claim. This one introduced none
because the edit class changed: restoring verbatim text is copying from a fixed, checkable source, while
writing a paraphrase mints a fresh assertion that can only be judged by argument. The defect rate fell because
the work stopped being generative.

And the narrowing beat both blanket rules, argued from the diff rather than from plausibility. Blanket
paraphrase had introduced an attribution error while fixing one — converting your flat "I think we should
not mint on get" into an inference about what register can supply. It had also orphaned a reference that
restoration repaired: test_const_enum_builtin_parity.py's "the three" now has its antecedent back from your
"For all three". Blanket quoting would have failed at the four #878 sites, which have no thread to quote. The
narrowed rule is the only one of the three correct at every site, and its whole cost is four [sic]s.

Two things left for #987, both confirmed at their real counts. The eight pcapkit/ sites still render
entries silently — a defect of the same class, far milder, and deferred on a stronger ground than scope
tidiness: six are vendor/ templates or their generated const/ outputs, which must stay byte-identical in
their generated regions, so that is code-adjacent work. It also found the correct model already in-tree —
docs/source/changelog/1.5.0.rst:431 quotes the same ruling with an explicit ellipsis that elides the typo'd
clause. One cosmetic leftover at test_const_enum_no_mint.py:92 reads with its emphasis backwards now that the
quotation names get itself.

Labelled review: good-to-go. The head is BEHIND and needs main merged in, as #983 did.

UNVERIFIED by it: it did not re-run tests/const or tests/corekit, justified by the token stream being
identical so no test outcome can change; and it used docutils directly rather than the repo's Sphinx build, so
a bad :class: target would not be caught.

[JarryShaw]

Taken, and the previous commit goes the wrong way — review: good-to-go is reverted to review: pending.

Your ruling, paraphrased: narrowing does not help a reader without context, so paraphrasing with context
and references is better; and documentation should read like statements, not conversations — verbatim
quoting makes a docstring read like a discussion.

So 9bd738dd3 restored eight quotations in the wrong direction. But a plain revert would be wrong too,
because the paraphrase it replaced was also bad: it dropped the context that made the rule intelligible and
grounded one claim on the wrong ruling. A worker is writing the third form — the rule stated in our own
words, carrying the reason a reader needs, with the issue cited — which is neither of the two things tried
so far:

• the sentinel rule now says __all__ lists the object and leaves the type out and why — the types are
  not part of the public surface — settled on docs: sweep all prose for concision and accuracy, and drop timed context outside the changelog #719, implemented under fix(corekit): export only the sentinel objects, not their types #911;
• the minting rule says get() does not mint and only register() creates an entry, and why — only
  IANA-registered values are legitimate and get() has not enough information to construct one — settled
  on const: bring the 16 bespoke registries onto EnumRegistry, after fixing the base's str-key dispatch #860.

The [sic] markers go with the quotations; there is nothing to reproduce in a statement. The four #878
sites were already in this form and are untouched.

On missing your comment: the sweep ran and read all four channels. The gap is between reading and
posting. I read at the top of a tick, spent ten minutes verifying and dispatching, then posted — and your
13:12 comment landed in that window. I did it twice, and the second post granted a verdict your comment had
just invalidated. I had this exact rule already, from the same failure at 00:17Z, which tells me a rule
phrased as a reminder does not hold. The fix is mechanical: the channel re-read now goes in the same tool
call as the post, so a new comment aborts the post instead of being overwritten by it.

[JarryShaw]

The eight passages are statements now, at f24e030a0 — prose-only by token identity on all four files,
every [sic] gone with its quotation, no stranded fragments. tests/const 299 OK,
test_conventions_doc_claims 38 OK, tests/corekit 5 known pre-existing failures.

Each site carries the reason rather than just the rule: __all__ keeps the object and leaves the type out
because types are not public surface (#719 settled, #911 implementing); get() must not mint and only
register() creates an entry because only IANA-registered values are legitimate and get() has not enough
information to build one (#860). The four sites are worded differently per context rather than one paragraph
pasted four times, and the orphaned antecedent is fixed — "the three" now names Method, Command and
FEATCode.

But your ruling is wider than the eight sites I dispatched, and I would rather show you the number than
quietly scope it out. Measured just now in those same four files, classifying by whether the surrounding
prose attributes the quotation to you or to a ruling:

owner/ruling-attributed quoted spans still present:  15
other quotations (RFC text, code, ordinary prose):    9   <- not what the ruling is about

So those four files now read half as documentation and half as conversation — the eight converted sites
sit beside fifteen that still quote you, including "Take (b). Only register can mint.", "Q1 - bare it is."
and "Okay one module for all four it is." An earlier round flagged exactly this shape as a defect when it was
one site against three; it is now eight against fifteen, in the files this pull request touches.

My recommendation: convert those 15 inside #982 rather than deferring them. The inconsistency is worst
precisely where the change has already been made, a reader of these files is the one your ruling is about, and
#987 is then left with the rest of the tree rather than with a known mixture in four files that have had eight
review rounds. The cost is a ninth round on this pull request.

The alternative is to merge as it stands and let #987 take all 15, which gets #982 off the board sooner at
the price of shipping the mixture.

Which do you want? Labelled needs: decision; the other 9 quotations stay either way, since RFC text and code
are not the thing you ruled on.

[JarryShaw]

okay, convert those 15 inside #982

[JarryShaw]

NEEDS CHANGES at d4d7702f1 — opus, round 9. The paraphrasing is the best work in this pull request's
nine rounds. The one blocker is a wrong instruction of mine, and the repo already told me so.

My brief said to name the issue rather than the pull request everywhere. tests/ is exempt, in writing, in
this branch. docs/source/contributing/conventions/documentation.rst:203-210, which I verified myself:
the changelog and tests/ are both exempt because a substantial share of the pull requests cited under
tests/ close no issue at all, and where an issue does exist it frequently lacks the fact being cited,
which lives in the pull request's own body or review thread instead. That landed as db5631d4c in #980 —
which I coordinated and merged yesterday — and git merge-base --is-ancestor db5631d4c f24e030a0 is true, so
it was live in the tree for both content commits.

And the exemption's stated reason is exactly what happened. Three sites were re-pointed from PR #836 to
#808. I checked: #836's body says in bold that its two maintainer rulings went "beyond what #808 asked
for", and #808 has one comment and carries neither. So the tidier citation is a false pointer, not an
improvement. Being reverted at test_const_enum_builtin_parity.py:854,
test_const_enum_no_mint.py:128 and :2703, keeping the de-quoted wording.

The partial conversion also left the tree contradicting itself, which nobody had spotted: three PR #836
citations survive elsewhere, one of them a docstring title ten lines above a site re-pointed to #808 —
and that same docstring uses #808 for two other things, so a reader cannot tell which is which. Two further
marginal re-pointings go back the same way: the f-string convention lives on PR #783's review thread, not
on #759 (an unrelated __canonical__ bug), and the mint/unmint criterion on PR #847's, not #841.

What the round confirmed as good, with its own count. By a tokenize/ast sweep it measured 28
quotations removed across 20 locations — correcting both my 15 and the author's ~29, and locating the
discrepancy: no-mint is 12 not 10, and builtin-parity is 3 not 1, because two of its three use bare double
quotes rather than *"…"* markup. It proved prose-only more tightly than I did, by masking every string
literal and showing the token streams byte-identical.

No hollow conversions, nothing false, and three paraphrases are strictly more faithful than the quotations
they replaced because they recovered clauses the quotation had elided. It also fixed two pre-existing defects
in passing: a site that quoted an agent's #864 analysis while framing it as your ruling, and one that
conflated #864's ruling with #775's criterion.

On the agent-sourced reasons it flagged for you: its judgement is that the current state is honest and needs
no marking, because your terse ruling is cited as yours and the reason sits in a separate sentence making a
factual claim about the code — and that adding provenance apparatus would work against your instruction to read
as statements rather than discussion. I agree. The one tightening is registry:1512, which folds an agent gloss
inside "the owner ruled on #864 that…".

Memory recorded so I stop briefing against carve-outs: tests/ and the changelog are the whole exempt set.

[JarryShaw]

GOOD TO GO at 9d048d2d4. Round 9's blocker was these five citations and its own condition was that fixing
them would clear it. They are fixed, and I verified the content myself rather than relying on the worker —
which matters here, because it said plainly that it did not re-derive the thread evidence and worked from my
verification instead. That is the honest report, and it leaves me as the only check, so I re-checked.

Prose-only, proven: string-masked token identity holds on both files (5561 and 11697 tokens, sequences
identical), so nothing outside a string literal moved. 2 files, +5/−5.

The self-contradiction is gone. test_const_enum_builtin_parity.py:844's docstring title and :854 ten
lines below it now both say PR #836; test_const_enum_no_mint.py:2688 and :2703 likewise. The two marginal
ones follow the same rule — the f-string convention cites PR #783 where the ruling actually lives, and the
mint/unmint criterion cites PR #847 with #775 retained for where it was confirmed as core.

The surviving #808 citations are correct and deliberately untouched. At parity:364, :504, :581,
:585, :599, :847 and :852 they describe dropping the IntFlag base, which is genuinely what that issue
did — as distinct from the extension-refusal and |-decoding rulings, which happened on #836 beyond what #808
asked for. That distinction is now readable, where before the same docstring used #808 for both.

For the record on where the error came from: it was my brief, not the work. I instructed the issue-citation
convention everywhere, and tests/ is exempt in writing — in a file in this branch, from a change I
coordinated and merged the day before. Recorded as a memory so I stop briefing against carve-outs: tests/
and the changelog are the whole exempt set, and nothing else is.

Two non-blocking items round 9 raised, left as they are: GetContractTests's statement is thin because the
ruling it cites carried no reason and inventing one would be worse; and registry:1512 folds an agent's gloss
inside "the owner ruled on #864 that…", where splitting the sentence would be tidier. Neither is worth a tenth
round.

tests/const 299 OK at this head. Unpublished and otherwise untouched.