Review request: critique the 20 PRs merged in #94–#114, plus #115–#117 and the polarity guard

[HodlDee]

What this is

Twenty pull requests landed between #94 and #114 — three factual corrections, three bugs, two consistency passes, four new guides, one new section, and a rewritten glossary. main builds clean with every guard passing and the offline artifact digest unchanged.

A second batch has landed since — three new guides (#115, #116, #117) and a build guard that cannot be pushed yet. It is in the round-two comment below, and the guard is the piece I most want looked at before it goes up.

This issue is a request to attack the work, not to admire it. Below is where I think the weak points are, ordered by how much a wrong call would cost.

Full change log with reasoning per PR: review/CHANGES.md is kept locally alongside the working notes; the merged PR descriptions carry the same reasoning.

Judgement calls worth a second opinion

These are decisions, not facts. Each could reasonably have gone the other way.

1. Softening "a chip you cannot audit" — #99.
supply-chain-and-vendor-risk presented secure element versus open silicon as a clean binary. Trezor's Safe 7 ships TROPIC01, which Trezor describe as "the world's only independently auditable secure element". I rewrote the passage to state the historical position, name the exception, and say one device is not a trend. Is one product enough to move that framing, or should it have stayed a binary until the pattern is established?

2. The effort field's ten hand-set values — #104.
"About 45 minutes" meant reading time on some guides and workbench time on others. I could not derive which: the prerequisites block misses genuine tasks, reading rate is useless because the estimates are deliberately unhurried, and the two signals disagree on exactly half the library. So ten guides have effort set by hand — own-node-connection, passphrase-setup, seed-backup-metal, air-gapped-psbt-workflow, coldcard-advanced-features, exchange-account-security, satscard-setup, three-dice-seed, bip85-child-seeds, inheritance-plan. Those are editorial calls. multisig-key-geography and duress-and-coercion I left as "read" and could argue either way.

3. Glossary exclusions — #110 and #93.
238 terms written in-house, replacing 514 fetched from a third party. I dropped trading metrics, meme vocabulary, altcoins and ideology entries on the grounds that a glossary attached to custody guides has no business defining "lambo" or the 200-week moving average. That is the most opinionated thing in the whole batch. #93 lists 15 borderline terms still undecided.

4. Qualifying Wasabi's CoinJoin cell — #100.
The client still speaks WabiSabi; zkSNACKs stopped running a coordinator in June 2024. I changed a plain tick to a partial with a note. Arguably it should still be a tick, since the capability exists.

Factual claims to re-derive

I verified each of these; independent confirmation is worth more than my word.

• BIP39 checksum rates (State what the recovery checksum actually catches #95). Transposing two words survives the checksum 6.31% of the time at 12 words and 0.38% at 24. Measured over 200,000 trials per length against build/tools/bip39-english.txt, matching 2⁻⁴ and 2⁻⁸.
• Wordlist facts (Fix two wordlist claims that do not survive checking #97). about/above diverge at the fourth character; abandon/ability at the third. 103 words are shorter than four letters. All 2,048 four-letter prefixes are distinct.
• Chip attribution (Attribute the Safe 7's secure elements to the right chips #99). EAL6+ belongs to the OPTIGA Trust M, not TROPIC01.
• Cove's capabilities (Correct three cells in the software comparison #100). Its README lists private-node support and watch-only import; the repository has a NodeSelectionView settings screen.
• Kraken extraction (Define the secure element the device guides keep relying on #107). Fifteen minutes of physical access, voltage glitching, Trezor One and Model T, 2020 — and Trezor's response that a passphrase defeats it.
• Glossary originality (Write our own glossary and drop the third-party lexicon #110). Across the 121 entries whose ids overlapped the old source, six shared a five-word run; three were reworded, four remain unavoidable ("one hundred millionth of a bitcoin").

New writing — is it right, and does it sound like the site?

Four guides and one section, roughly 7,000 words in the house voice. Accuracy matters more than style, but both are fair game.

• seed-to-key — BIP39 and BIP32 mechanics. The hardened-derivation section is the part to check: the claim that an xpub plus one normal child private key reconstructs the parent is load-bearing and stated as fact.
• verify-a-download — GPG verification. Check the commands still match what each project publishes.
• inside-the-device — secure elements. Check the attempt-counter framing is the right emphasis.
• how-custody-fails — Mt. Gox, Quadriga, Celsius, FTX. Figures are deliberately approximate; check the Quadriga characterisation is fair, since the OSC findings and the popular account differ.
• Dusting section in chain-analysis-heuristics — check it belongs where it was placed.

Structural changes to shared code

Not judgement calls, but a reviewer should know these landed — and whoever works next will meet them.

callout() takes a third argument. It is now callout(title, body, level = "h3"). Used 115 times; only two pass anything (#103), and the default preserves existing behaviour. The stylesheet already matched .sc-callout h2 and h3 in one rule, so an h2 callout renders identically.

New source file: build/glossary.mjs (2,374 lines, 238 terms). Consumed by build/content.mjs, which renders the cards into glossary.html at build time. That is a change in kind: the #term- anchors now exist in the HTML and resolve with scripting disabled, which they never did before.

docs/assets/js/site-refresh.js lost 167 lines and gained 31. It no longer fetches the lexicon; it reads the rendered cards back out of the DOM to build the search index. Search and the letter filter became enhancements over a page that already works without them. Note this file is hand-maintained, not generated (CONTRIBUTING §4) — so it is one of the few places in docs/ where the diff is authored rather than rebuilt.

docs/assets/css/site-refresh.css changed in two places, also hand-maintained:

• overflow-wrap: anywhere on .sc-article code (Let long commands wrap on a phone #94)
• The .sc-survival-row mobile labels scoped behind .is-multisig (Stop the survival grid stamping multisig labels on other guides #102). The base component now renders unlabelled on phones — intentional, since the labels were the multisig guide's columns, but it is a behaviour change to a shared component.

build/tools/assert-no-fetch.mjs allowlist shrank. btclexicon.com is gone, so the guard itself now proves no page requests it. Worth confirming you are happy the guard is the right place for that assurance.

LICENSING.md gained a row for build/glossary.mjs — MIT for the module code, CC BY 4.0 for the definitions, mirroring how build/guides.mjs is recorded. Given the project's provenance discipline, this is the line most worth a second pair of eyes.

ASSET_VERSION is now derived, not typed (#113). It was a hand-maintained string stamped onto every versioned stylesheet and script link — the only thing telling a browser a changed asset is worth re-fetching. Forgetting to bump it shipped a fix to new visitors and to nobody who had been to the site before, silently, because the build passes and the page looks right to whoever made the change. It is now a truncated SHA-256 over the four files it stamps.

Three things about it are worth a reviewer's attention:

• The asset list is written out rather than derived from the ASSET_QUERY regex beside it. Adding a file to one and forgetting the other should be a visible mismatch rather than a silent one — but it does mean two lists to keep in step, which is a trade you may disagree with.
• It is content-addressed, not monotonic. Reverting an asset restores its previous version string rather than minting a new one. Correct for a cache key; surprising if you expected it to only increase.
• Determinism was the constraint, since the reproducibility guard rebuilds and compares. Verified: three consecutive builds produce an identical version, appending a byte to either site-refresh.css or site-refresh.js changes it, and reverting restores the original.

This one is not hypothetical. The mechanism failed twice while the rest of this batch was being written — #94's mobile fix and #110's rewritten site-refresh.js both appeared broken in a browser until the constant was bumped by hand — and it caused the only merge friction, since three PRs bumped it and each rewrites the query string on eleven pages.

Heading levels on the root pages (#114). A final sweep found the guide finder on guides.html going from h2 "Guide finder" straight to h4 category labels, with a nested h5 — the same defect fixed on two guides in #103, missed because that audit only walked docs/guides/. Shifted to h3/h4.

The catch is worth noting: the stylesheet targeted .sc-chip-group h4, .sc-chip-group h5 by tag, so the shift would have silently unstyled three headings. The selector moved with them and all four render identically afterwards — verified in the browser rather than assumed.

Same PR gave contact.html and merch.html a meta description, the only two root pages without one. content.mjs defines one for contact but the renderer only uses that field for guide pages, so it was never emitted.

Deliberately left: those two pages still go h1 → h4, because the shared footer's section headings are h4 and a parked page has no content heading between. Fixing it means touching every page on the site to correct the outline on two temporary ones. Disagree with that if you think the footer headings are wrong in themselves — it is the one call in this PR I am least sure of.

Commit authorship. Every commit in this batch is authored and committed as 130502840+HodlDee@users.noreply.github.com, matching the repository's existing history. An earlier push was correctly rejected by the account's email-privacy setting; the commits were rewritten before anything reached GitHub.

Read #107 from main, not from its diff

PR #107's diff does not show what landed, and a reviewer working from it would review the wrong content.

Its branch collided with main two ways. #108 had inserted its guide at the same point in the guides array, and #99 had rewritten the exact sentence in supply-chain-and-vendor-risk that #107 adds a link to — four interleaved conflicts in build/guides.mjs.

Rather than hand-resolve those, I re-applied the guide onto current main and force-pushed. The substantive difference: the inline link now sits on #99's improved wording rather than reverting it to the older "by construction, a chip you cannot audit" sentence, which is what a mechanical resolution would have produced.

So for inside-the-device, read build/guides.mjs on main rather than the PR diff. Everything else merged without source conflicts and its diff is accurate.

Things I got wrong along the way

Recorded because they show where my judgement was weakest.

• Claimed the four-step path never addressed the empty-restore failure. It does — how-wallets-find-coins covers it well. I had planned a companion guide that would have duplicated it.
• Claimed there was no sourcing convention. There is: <h2>Sources</h2> in the entropy guides, sc-source-note on device guides.
• Called sparrow-first-wallet thin twice on word count alone. It is tight, not thin — the metric was measuring the wrong thing.
• Filed Passport Prime's missing microSD as an error. Foundation's own spec confirms the site was right; my first search had conflated two pages.
• Under-scoped the glossary twice, at 51 then 152 terms, by bucketing the remainder and treating the leftovers as noise without reading them.

Still open

• Glossary: record what was excluded, and decide on 15 borderline terms #93 — 15 borderline glossary terms. Zero-knowledge proof is the one I would add regardless; the glossary page's own hero copy promises it.
• exchanges.html says "Links checked August 6, 2026" — one sentence conflating a link check with a product-detail check, which decay at different rates.
• contact.html shows "Coming soon" and is linked 271 times from 69 pages, including the homepage's twelve-service "Need Help?" section. Deliberate, and the largest gap between what the site promises and what it delivers.
• 41 "Image to come" placeholders across 38 guides. (Corrected from 37/34 — recounted against figureSlot() in build/guides.mjs.)

[HodlDee]

Round two — three guides and a build guard

Since the batch above: three new guides (#115, #116, #117), open and pushed but not merged, and one build guard that cannot be pushed yet. Same request as before — attack it.

main still builds clean. Each branch builds clean on its own.

---

The one you cannot see on GitHub

guard-polarity is committed locally and has not been pushed. The push is rejected outright:

! [remote rejected] guard-polarity -> guard-polarity
  (refusing to allow an OAuth App to create or update workflow
   `.github/workflows/build.yml` without `workflow` scope)

The token has gist, read:org, repo. The workflow edit is not droppable — ci-completeness-test.mjs requires every committed build/tools/*-test.mjs to be named in build.yml, so removing it would land a branch that fails its own CI. So the decision-bearing parts are quoted below rather than linked, because this is the change I most want looked at before it goes up.

---

1. The polarity guard — guard-polarity

build/tools/assert-polarity.mjs (351 lines) + build/tools/polarity-guard-test.mjs (143) + wiring into render.mjs, build.yml, package.json. One correction to content.mjs rides along; see below for why it cannot be separated.

The problem it addresses

Every product on this site is described twice: once as a mark in a feature matrix on devices.html, software.html or exchanges.html, and again in prose somewhere in the guide library. The two halves are written months apart, by different passes, from different sources — and nothing connected them. A matrix could say a device has no air-gapped signing path while a guide walked the reader through using one, and the build would be perfectly happy.

It found a real error on its first run

software.html marked Electrum as not offering coin control (—, "not part of the standard workflow"). The BitBox02 guide sends readers to Electrum for exactly that:

The device also works as a signer for Sparrow, Electrum, and Specter, which is worth knowing once you want coin control, labelling, or a connection to your own node.

Electrum's own RELEASE-NOTES contradicts the matrix in four places:

 882:  - Coins tab: New menu that lets users easily spend a selection
1435:  - Coin selection moved to the Coins tab, and it affects all txns,
1530:  * Coin Control in Qt: implemented freezing individual UTXOs
2515:  * Coin control: select addresses to send from

The cell is now a check with <small>Coins tab, with per-UTXO freezing</small>. The correction is in the same branch as the guard, because the guard does not pass without it — splitting them would mean landing a guard that fails on arrival.

Worth a second opinion: the row is "Coin control / UTXO management", and Electrum's is a Coins tab with freeze and "spend from" rather than the labelled UTXO workflow Sparrow offers. I called that a check. A partial is defensible — say so if you think the row means the richer thing.

Note the neighbouring row, "Labels (BIP-329)", stays a dash for Electrum, and I think correctly: Electrum has labelling, but not the BIP-329 interchange format the row names. The guard does not flag it because that row's pattern is BIP.?329 only. If you think the row label is doing too much work there, that is a finding.

What it checks, and what it deliberately does not

Only dashes. A dash is a flat denial, so prose asserting the capability is a flat contradiction with no reading under which both are true.

"Optional or model-dependent" is out of scope. Prose saying a device does something the matrix marks half-available is usually correct and more specific than the mark. Flagging it would train whoever reads the output to skim past it.

14 of the 87 dashes are not checked. Rows like "Transaction review on device" and "Interac e-Transfer" have no phrasing distinctive enough to tell a claim from a passing mention. Stated as a position in the file rather than left as an omission.

Why co-occurrence was not enough

The first version looked for a product and a capability in the same sentence. 49 candidates, none of them real. This one, from the Specter guide, was reported six times:

Add each device and choose how it connects: USB for Trezor, Ledger, BitBox02 and similar; microSD file import for COLDCARD; QR for SeedSigner, Keystone, and Passport.

Seven products, three capabilities, every pairing correct. Co-occurrence is not attribution.

So a claim has to be shaped like one — the product and capability joined by something that predicates one of the other, within 70 characters, with no denial between them:

const PREDICATES = String.raw`has|have|had|offers?|supports?|includes?|provides?|ships? with|comes? with|carries|carry|adds?|uses?|signs? over|works? over|connects? over|pairs? over|reads?|writes?|backs? up to|is|are|with(?: an?| its)?|'s|’s`;

const DENIALS = String.raw`\bno\b|\bnot\b|\bnever\b|\bwithout\b|\blacks?\b|\bcannot\b|\bcan't\b|\bnor\b|\brather than\b|\binstead of\b|\bdrops?\b|\bdropped\b|\bremoved?\b|\babsent\b|\bunlike\b|\bunless\b`;

/* Not denials, but the same effect here: they say the sentence is about a
   different model from the one the column names. */
const OTHER_MODEL = String.raw`\bearlier\b|\bolder\b|\bformer\b|\bprevious\b|\bsuperseded\b|\bdiscontinued\b`;

The library states limitations far more often than capabilities — "Ledger devices connect over USB or Bluetooth and have no air-gapped signing path" — so DENIALS does more work than anything else in the matcher. That list is the most likely place for a bug, and a missed denial produces a false failure rather than a silent pass, which is the right direction but still annoying.

49 → 3: the Electrum error, and two sentences about the BitBox02's microSD backup, which the matrix marks available on a row separate from microSD signing, which it dashes.

The acknowledgement mechanism — the part to argue about

Matching prose is a heuristic and always will be, so every candidate is either a contradiction or a recorded judgement:

{ product: 'BitBox02', feature: 'Removable media for signing',
  where: 'guides/bitbox02-setup.html', digest: 'f093d89790',
  why: 'Describes the microSD backup, which the matrix marks available. Signing is a separate row and is correctly dashed.' },

The digest is of the sentence. Edit the sentence and the acknowledgement goes stale and the build fails, putting the judgement back in front of a reviewer — which is when it is most likely to have gone off.

This is the design decision I would push back on if I were reviewing. It trades churn — touch a flagged sentence and the build asks about it again — for keeping the reasoning in the repository rather than in a review comment nobody can find in a year. If you think the churn will be resented in practice, say so; the alternative is a plain ignore-list with no digest, which never nags and never notices when the judgement stops applying.

Why the guard has its own test

The decision is a pile of regular expressions, which is the kind of code that goes on passing after it has stopped working: tighten a pattern to silence a false positive and the guard can quietly stop matching anything while the build keeps printing "no contradictions".

polarity guard
  ok   the site as committed has no contradictions and no stale acknowledgements
  ok   the guard is actually checking something
  ok   a planted claim is found
  ok   a sentence claiming two dashed capabilities is reported for both
  ok   the same claim negated is not a contradiction
  ok   "rather than" is read as a denial
  ok   a sentence about a superseded model is not a claim about the current one
  ok   a list pairing products with methods is not read as a claim about each of them
  ok   editing an acknowledged sentence sends it back for review
  ok   deleting an acknowledged sentence reports the acknowledgement as stale
  ok   a page that loses its matrix is a structural failure, not a pass
polarity guard: 11 cases pass

Each of those failed at some point while the guard was being written. The last one is the failure mode a guard is least allowed to have — if the matrices stop being findable, every dash disappears and the check passes on nothing, so losing the evidence had to be an abort rather than a clean run.

Cost: 0.35s on the build. The first version took a second; claim patterns are now compiled once per pairing rather than once per sentence.

The broader question, if you want to take it: does a prose-matching heuristic belong in a build at all? It cannot be complete, and a check that catches some contradictions might make the remainder feel handled. My position is that it found a real error in its first minute and the alternative was nothing, but that is an argument from one data point.

---

2. #116 — reframed from a verdict to a method

This is the biggest editorial call in the batch. It began as #87's draft, Bitcoin is not "crypto", and would have been the only guide in the library that argues a position rather than teaching something.

The homepage states the standard: "Built to Inform, Not Persuade. Self-custody has no universal setup. We explain the options, the risks, and the tradeoffs that matter—so you can decide for yourself." I concluded the draft did not meet it — it reached a conclusion on the reader's behalf, and the conclusion happened to be the one this site is built around, which makes it harder to notice rather than easier.

So the strongest material in the draft — the checklist of concentrated ownership, pre-mines, discretionary issuance, thin liquidity — became the method, and it now leads: eight structural questions with what a strong and a weak answer looks like, and bitcoin as the worked example rather than the thesis. Same evidence, same two incidents, same limits.

Slug bitcoin-is-not-crypto → evaluating-a-monetary-asset. Nothing was ever published under the old one, so no redirect.

Argue with this if you think a site can be honest and still take a position. There is a real case that refusing to conclude anything is its own kind of evasion, and that a reader who wants to know what we think is entitled to an answer. I would rather be told I over-corrected now than discover it after it is published.

The narrower version of the same question: is the eight-question frame actually more useful, or just more comfortable? My argument is that a verdict about bitcoin helps with bitcoin, while eight questions help with the next thing marketed at someone. That is a claim about readers I cannot test.

Retained from the draft, and worth re-deriving: the August 2010 value overflow (CVE-2010-5139, block 74638, ~184 billion BTC, patched in ~5 hours, honest chain ahead by block 74691) and the March 2013 BDB→LevelDB split (BIP 50, ~6 hours as two chains). Both were kept because the draft's claim that bitcoin "has operated continuously" is not true, and a page about checking claims should not repeat one it has not checked. In the reframe they sit under the question they bear on — whether supply is enforced or promised — with the judgement about what they demonstrate left to the reader.

---

3. #115 — Bitcoin Core wallets and wallet.dat

New guide bitcoin-core-wallet, ~2,000 words. The premise: most of what is written about wallet.dat online describes a file format Core stopped opening at v30 — the Berkeley DB wallet behind dumpprivkey, importprivkey and the recovery-service industry. Those RPCs are not deprecated, they are absent.

Factual claims to re-derive — these are the load-bearing ones:

• Bitcoin Core 30.0 can no longer create or load Berkeley DB legacy wallets, and dumpprivkey, dumpwallet, importprivkey, importaddress, importmulti and sethdseed were removed in the same release.
• A modern Core wallet is a descriptor wallet stored as SQLite, in a per-wallet folder, still named wallet.dat — which is most of why the confusion persists.
• Core has never used BIP39. There is no phrase to write down because none exists.
• The three platform paths for wallets/<name>/wallet.dat.
• restorewallet builds the folder rather than requiring a hand-placed file, and refuses if the name exists.
• backupwallet writes a safe copy while the wallet is in use; copying the live file with the node running is not safe.

The Workshop export section is the reason the guide exists, and is the part I would check hardest: the Workshop writes a Core descriptor wallet derived from a BIP39 seed, so the words stay the master backup even though Core has no concept of them. It offers a watch-only file and a private one, which look identical in a downloads folder — hence a table rather than a sentence. The private file is only produced with "Show private recovery material" on.

Added after Dee's review of the first draft: verifying the download, what running a node actually requires (linking the node guide), backing up properly, and a callout that you do not need a fully synced node to create a wallet — that last one because it is the assumption that stops people trying.

---

4. #117 — starting on an exchange is a start, not a failure

New guide custody-journey, from the sketch in #65. Six rungs from spot ETF to multisig, what each actually holds and costs, and readiness as something you can check rather than feel.

The tension to check: this site is unambiguous that platform balances carry risks you cannot inspect — how-custody-fails is four collapses making that case. This guide says an exchange balance is a reasonable place to start. I think both are true and the right response to that risk is a route out rather than shame about being on it, but it is the sort of pairing a reader could fairly call inconsistent, and the guide links the other one explicitly so they will meet both.

Two other calls worth a look:

• It says a hardware wallet with a tested backup is a complete answer for most people, not a waypoint to multisig. That contradicts a common assumption in this space, deliberately.
• It names the ETF row as not a rung at all — price exposure with no withdrawal, ever, because there is nothing to withdraw. Flat, and I think correct, but flat.

---

Corrections to this issue's own text

• The body above says "37 'Image to come' placeholders across 34 guides." Recounted: it is 41 across 38 guides — figureSlot() occurrences in build/guides.mjs on main. The three new guides add none, being prose rather than walkthroughs. Body updated.
• The body's link for review/CHANGES.md points at a PR search rather than the file, which is not tracked by git. That file is kept locally and is Dee's copy; the merged PR descriptions carry the same reasoning.

Still open, unchanged

#93 (15 borderline glossary terms — zero-knowledge proof is the one I would add regardless), the exchanges.html "Links checked" sentence, contact.html still parked, and the image debt above.

[HodlDee]

Review completed September 7, 2026. Recommendation: request changes. The shared UI work is mostly sound, but the new writing includes security claims that can lead readers to rely on the wrong protection. PR #115 also contains two recovery workflow defects reproduced against Bitcoin Core.

Scope: the 20 merged PRs #94 through #114, excluding this issue, reviewed as the combined change from 89643a3 to main 68e44b407aa778c50054b72a18f560c8676b7d51; open PR #115 at e9511e18238f620590da82ac902624b4118047ee, #116 at fb5774d77f7abbacaa5e3f84d04628258b99d76d, and #117 at daadf83ae16d700600f269ec137f4e33e7b7c43d. For #107 I reviewed the content that actually landed on main. The local workspace supplied to this task was an older snapshot without Git metadata, so review and builds used separate temporary checkouts of this repository. No site source was changed.

The numbered findings below are new defects or omissions in this batch. P1 means fix urgently because readers could lose funds or misunderstand a security boundary. P2 means fix before approving the affected work. Older errors copied into the glossary are called out separately.

1. [P1, Explain what Bitcoin Core's wallet.dat actually is now #115] Require a fresh backup immediately after encrypting a Core-created wallet. Source, encryption instructions.

   The guide puts backup before encryption, then explains encryption only as adding a signing password and handling old unencrypted copies. Core also rotates the active keys of a normal Core-created wallet. Following this sequence and retaining only the earlier backup can leave later receipts unrecoverable after loss of the working file.

   Reproduced on Core 30.2 using an empty regtest wallet: create wallet, export descriptors and backup, encrypt, request a receiving address, restore the earlier backup under another name. Descriptor count changed from 8 to 16, all 8 active descriptors were new, and the restored wallet returned ismine: false for the post-encryption address. Core explicitly printed that a new backup was needed. Core encryptwallet documentation.

   Change: prefer encryption at creation; if encrypting later, immediately run backupwallet, refresh any private descriptor backup, and test the new backup before depending on it. Keep the warning that old unencrypted copies remain sensitive. Acceptance: restore the new backup and verify it recognizes an address issued after encryption.

   Scope matters: the Workshop export sets the BLANK wallet flag. In separate native Core tests, its four private export variants retained their active descriptors after encryption. I am not claiming that encrypting those exports breaks their BIP39 derivation.

2. [P1, Define the secure element the device guides keep relying on #107] Remove the universal claim that a passphrase is never stored on hardware. Source, with the same overstatement in the introduction at line 9533 and closing callout.

   Ledger supports both a temporary passphrase and a persistent mode attached to a PIN. Its official OS documentation explicitly describes the latter. An attacker who obtains that PIN can activate the corresponding wallet. Even a nonpersistent passphrase is only an effective separate secret when it is sufficiently hard to guess; an active signer also necessarily handles derived signing material. The guide's promise of an infinite extraction cost is false.

   Change: state the device, mode and powered-off threat being discussed. Explain the protection offered by a strong passphrase that is not persisted with the device, and remove the universal/infinite guarantee from the introduction, table implications and conclusion. Acceptance: the text must remain true for Ledger's attached-PIN mode and a weak passphrase after mnemonic extraction.

3. [P1, Write our own glossary and drop the third-party lexicon #110] Distinguish receiving-address verification from outgoing payment verification. Glossary address substitution.

   The example says the compromised computer shows an attacker address while only the signing device shows the user's address. That describes verifying a receiving address derived by the device. When sending, a hardware wallet displays the destination in the transaction it was given. If malware substituted that destination before the transaction was constructed, the device can faithfully display the attacker's address too. Merely looking at that display does not establish the intended recipient.

   Change: give separate receive and send examples. For sending, compare the device's entire destination and amount against the recipient information verified through a trusted source. For receiving, compare the shared address with the one derived and displayed by the receiving device. This matches the distinction in Trezor's trusted-display guidance. Acceptance: neither example should imply the signer knows the user's intended payee.

4. [P2, Define the secure element the device guides keep relying on #107] Correct the secure-element architecture model. Comparison table and “secrets do not leave it”.

   The guide groups Trezor Safe, BitBox02, COLDCARD and others under a model where the seed is inside the secure element and keys are never handed to the main processor. That is not a universal hardware-wallet design. For example, Trezor documents an encrypted wallet secret on the main chip, protected using a PIN and secret enforced by the secure element. The secure element's contribution and the location of signing are different questions.

   Change: distinguish a secure element that enforces access to an encryption secret from one that stores and uses signing keys internally. Make the table model-specific, or describe protection rather than asserting where every seed resides. Keep the PIN counter discussion, but stop treating it as a complete explanation of every architecture. Acceptance: every named device must fit the architecture attributed to it.

5. [P2, Define the secure element the device guides keep relying on #107] Qualify Krux's statelessness by mode. Source and the table at line 9546.

   Krux can store an encrypted mnemonic in internal memory or on an SD card. Krux's own loading documentation describes retrieving it. The existing Krux setup guide on this site also documents the option. Powering off a device configured this way does not erase its stored encrypted mnemonic.

   Change: describe Krux running without persistent mnemonic storage as the stateless case. Explain that a saved encrypted mnemonic remains sensitive and relies on its encryption key. Update the “nothing on it” claims and loss/disposal implications. Acceptance: the guide must accurately cover Krux with internal storage enabled and with an inserted mnemonic backup SD card.

6. [P2, Define the secure element the device guides keep relying on #107] Correct the Kraken attack's PIN step. Source.

   The text says nobody guessed the PIN. Kraken's original disclosure describes extracting the encrypted seed and then brute forcing the PIN offline; it reports completing any four-digit PIN search in under two minutes. The attack bypassed device rate limiting, not the need to decrypt the extracted material.

   Change: describe extraction followed by offline guessing, and scope the historical result to the researched models/configurations. This also explains why a short PIN was inadequate. Acceptance: the reader can distinguish obtaining encrypted storage from recovering the seed.

7. [P2, Explain what Bitcoin Core's wallet.dat actually is now #115] Supply the address type and a fixed index when verifying a Workshop export. Source, also the backup comparison at line 5755.

   On an otherwise default Core 30.2 node, the guide's bare getnewaddress requested bech32. I loaded all eight combinations of legacy, nested SegWit, native SegWit and Taproot, each public and private. All loaded with the expected private-key capability flag. The six non-native-SegWit cases then failed with -12: No bech32 addresses available. Only the two native SegWit cases matched the Workshop's index-zero address with that command.

   Change: explicitly map the Workshop's choices to Core's legacy, p2sh-segwit, bech32 and bech32m arguments. Better, compare index zero with deriveaddresses on the matching public external descriptor, so the comparison also works after addresses have already been issued. Explain that getnewaddress advances the wallet's next index. Core RPC arguments. Acceptance: repeat the guide for all four address types and for a wallet whose next index is already above zero.

8. [P2, Explain what Bitcoin Core's wallet.dat actually is now #115] Correct the legacy-wallet migration advice. Source.

   Removing ordinary legacy-wallet loading does not mean migration requires reverting to a version that still opens both wallet types normally. Core 30 retains migratewallet; the release notes explicitly preserve legacy migration, and I confirmed the RPC exists in 30.2. Sending readers toward an unspecified older version is especially poor advice given the documented wallet-deletion bug in 30.0 and 30.1.

   Change: point to migration on a current patched release, explain that migration differs from loading, and require independent backups before migration. Do not recommend 30.0 or 30.1. Acceptance: the guide offers a supported migration path without implying the user must downgrade.

9. [P2, Explain how seed words actually become keys #105] Remove the stale recovery-table row and unmatched closing wrapper. Source.

   After the completed HTML table, a leftover sc-survival-row repeats the language row, followed by an extra </div>. In the browser this is an orphan ARIA row, and the remaining paragraphs, “The short version” and final callout sit outside .sc-article. This is an actual layout/structure regression, not just redundant source.

   Change: remove the stale row and extra closing tag. Acceptance: the language row appears once, every role=row belongs to a table/grid, and the concluding content remains within .sc-article on desktop and mobile.

10. [P2, Explain how seed words actually become keys #105] Present recovery symptoms as possibilities, not diagnoses. Source, with the probability inference at line 8287.

    “Accepted, zero balance, path confirmed” does not prove a wrong passphrase. A different checksum-valid mnemonic and an incomplete scan are counterexamples. Conversely, “nothing can test” a passphrase is too strong: candidates can be checked against a recorded address or other known wallet identifier. The checksum's false-acceptance rate alone does not establish which explanation is least likely among users with a failed restore.

    Change: replace the one-cause mapping with possible causes and explicit checks. Say BIP39 has no intrinsic correct-passphrase error, while known wallet data can verify a candidate. Remove the claim that every other row is necessarily recoverable. Acceptance: cover a valid but wrong mnemonic, an unsynced wallet and a one-character passphrase typo with a known receiving address, without declaring any of them impossible to diagnose.

11. [P2, Show the collapses the site's central argument rests on #108] Replace the false “Celsius disclosed everything” account. Source, repeated at lines 9447 and 9507 and reflected in the comparison.

    The guide treats Celsius as an honest, disclosed lending arrangement that customers simply misunderstood. That conflicts with the documented fraud: Mashinsky pleaded guilty and was sentenced to 12 years for conduct including misleading customers about Celsius's safety and financial condition. DOJ account of the conviction and sentence.

    Change: keep the unsecured-creditor and lending-risk lesson, but distinguish contractual lending terms from misrepresentations about how funds were managed. Rewrite all repetitions of the innocent-misunderstanding thesis. Acceptance: the guide should not use Celsius as evidence that no material information was concealed. The Quadriga characterization, by comparison, is supported by the OSC's report.

12. [P2, Add the how-to half of verifying a download #106] Include the Workshop's existing provenance verification. Source.

    The new verification guide describes the offline Workshop as publishing only a checksum and no signature at all. The repository already documents GitHub/Sigstore provenance verification, and its workflow attests the downloadable artifact when its bytes change. Existing SECURITY.md instructions and workflow.

    Change: distinguish an unsigned standalone checksum from a signed build-provenance attestation. Link the existing gh attestation verify procedure and explain its repository/workflow trust boundary. Keep the warning that neither provenance nor a matching hash proves the software safe. Acceptance: a reader reaches the existing stronger origin check rather than being told that no such evidence exists. I checked the repository's implementation/documentation; I did not independently verify a remote attestation bundle in this review.

13. [P2, Write our own glossary and drop the third-party lexicon #110] Correct three independent glossary mechanics.

    • Difficulty adjustment, line 762: the target direction is reversed. Blocks arriving too quickly require a lower numerical target and greater difficulty; slow blocks require the opposite. Core's target calculation.
    • Replace by fee, line 1766, plus BIP125's example at line 277: opt-in signaling is not a universal requirement for replacement on the current network. Core enabled full RBF by default in 28.0. Explain the distinction between BIP125 opt-in policy, full RBF and the sending wallet's bumping capability. A replacement can also change outputs, so neither lack of signaling nor an original recipient is a settlement guarantee. Core 28 release notes.
    • Quantum computing example, line 1697: receiving without spending does not always hide the public key. Taproot outputs already contain a public output key. Limit the example to applicable hashed-key output types, and mention the Taproot distinction. BIP341.

    Acceptance: use a fast-block adjustment example, a nonsignaling replacement under full RBF, and a never-spent Taproot UTXO as counterexamples when reviewing the revised definitions.

14. [P2, Derive ASSET_VERSION from the assets it versions #113] Make the asset hash independent of checkout line endings. Source.

    readFileSync(file) hashes raw working-tree bytes, but the four hashed CSS/JS files are not pinned to LF in .gitattributes. In a clone configured with core.autocrlf=true, the same commit builds with asset version 9ee5934a999a instead of 6cfebdc237b7. That produces 72 changed generated HTML files solely from query strings. The ordinary LF build remains clean, which is why consecutive local builds miss this.

    Change: normalize these text assets to LF before hashing, or explicitly pin every hashed asset to eol=lf. Acceptance: LF and CRLF checkouts produce identical generated output; actual CSS/JS changes still change the version, and reverting restores it. Content-addressed reversion itself is correct.

15. [P2, Publish the crypto piece as a method rather than a verdict #116] Correct the unqualified “Nobody lost coins” account of the 2013 split. Source.

    BIP50 records a successful double spend and mining pools sacrificing substantial money to restore the canonical chain. The experimentally motivated double spend does not establish permanent customer theft, but the guide's blanket no-loss claim erases the real consequences.

    Change: describe the successful double spend and orphaned mining revenue accurately, without inventing unreimbursed customer losses. Link BIP50 at this paragraph. The method-first framing is worth keeping.

16. [P2, editorial, Say that custody is a journey, without arguing anyone into buying #117] Remove the pressure to purchase from the opening. Source.

    The opening ranks having exposure above waiting and calls learning without buying a failure. This directly conflicts with the stated “inform, not persuade” standard used to reframe Publish the crypto piece as a method rather than a verdict #116. Reducing shame about an existing exchange balance does not require shaming a reader who has chosen not to buy.

    Change: address readers who already own bitcoin or independently decide to acquire it. Make an empty-wallet setup and recovery rehearsal a valid first step. Preserve the risk explanations and the point that multisig is not a mandatory destination. Acceptance: deciding to wait or never buy is treated as a valid reader outcome.

Two substantive errors were already present before this batch and were carried into build/glossary.mjs. They should be repaired while these pages are being reconciled, but should not be attributed as newly invented by #110:

• Public versus private descriptors. Glossary line 2280 and the older how-wallets-find-coins guide imply descriptors always contain only public keys. BIP380 permits private keys. This now conflicts directly with Explain what Bitcoin Core's wallet.dat actually is now #115's listdescriptors true instruction. Mark public/watch-only exports explicitly, and use “private descriptor backup” in Explain what Bitcoin Core's wallet.dat actually is now #115 wherever the file's replacement must retain spending power. A public descriptor can restore visibility, not spending access.
• Login countdowns are not transaction timelocks. Glossary wrench-attack example promises nobody can move the funds that evening. An accessible mnemonic can be restored on another signer, bypassing a device login delay. State that dependency, and reserve enforced timing guarantees for appropriate spending policies.

Additional editorial cleanup: the new glossary's cold-storage example at line 585 conflates a USB-connected hardware signer with exposing its keys online; explain key isolation versus air gap. The “21 million” entry at line 26 confuses lost/spendable supply with total issuance. Remove unsupported prevalence assertions such as where “most thefts” happen. New visitor copy contains many hyphens and dashes despite the project's explicit copy rule; rewrite prose while preserving required code and identifiers. The source-only glossary description still says over 500 terms and its JS header still describes a remote API. The rendered meta description is already generic, so the stale source description is maintenance cleanup rather than a live SEO defect. Add zero-knowledge proof or change the hero that promises it, as already noted in #93.

On the judgement calls in this issue:

• Attribute the Safe 7's secure elements to the right chips #99: keep the more precise open-silicon exception; the binary framing would be factually worse. The TROPIC01 versus EAL6+ OPTIGA attribution is supported by Trezor's specifications. Auditability is a property, not evidence that the entire device is immune to attacks.
• Say whether "About 45 minutes" means reading or doing #104: explicit read/task metadata is reasonable. Define it as the estimated activity being timed and keep an editorial default. multisig-key-geography and duress-and-coercion can remain reads if the estimate is reading time. A guided task such as verify-a-download deserves an explicit decision instead of silently inheriting the read label.
• Write our own glossary and drop the third-party lexicon #110: the narrower glossary scope is appropriate. Static rendering is a useful improvement. The licensing row is consistent with the project's existing code/prose split; structural consistency and a short phrase-overlap check do not establish originality of every entry. I did not conduct a legal provenance audit.
• Correct three cells in the software comparison #100: Cove's corrected public-import and own-node cells match its README. Wasabi retains the capability, with a separate coordinator dependency. A tick plus a precise availability note is the clearest pure capability representation; a partial is defensible if the legend consistently treats required external setup that way. This is not a blocker. Wasabi coordinator configuration.
• Stop the survival grid stamping multisig labels on other guides #102, Stop two guides jumping from h1 to h3 #103, Fix the finder's heading levels, and give the parked pages a description #114: the scoped multisig labels and heading/CSS changes work in the tested layouts. I would not block these on the parked pages' shared footer outline. Keep any future footer cleanup separate from the confirmed extra-wrapper bug.
• Name the dusting attack the privacy guide already defends against #109: the dusting section belongs with the clustering explanation. Receiving an unsolicited output and later combining it with other inputs are the distinct events the reader needs to understand.
• Publish the crypto piece as a method rather than a verdict #116/Say that custody is a journey, without arguing anyone into buying #117: keep the evaluative method and the idea that an exchange balance can be a starting situation. They become consistent when the site teaches custody choices without recommending that everyone acquire exposure.

The polarity guard remains a design-only review. I read the complete description and quoted expressions in the round-two comment, but the actual unpushed files and workflow wiring were unavailable. No implementation approval is implied.

The heuristic is worthwhile as a prompt for human review, and sentence-digest acknowledgements are preferable to permanent silent ignores. Before approval, add or demonstrate tests for independent clauses with mixed polarity, such as a product lacking QR but supporting USB; “not only” versus actual negation; old and current models mentioned together; and removal of one matrix row, product column or recognizable mark while the surrounding matrix survives. Preserve explicit coverage counts and fail on missing expected structure. The current listed test for losing an entire matrix does not demonstrate those partial-loss cases. A 70-character window necessarily misses some claims, so report “no unacknowledged candidates among the checked pairs,” not semantic consistency of the entire site. The Electrum coin-control correction is justified by its Coins tab capabilities; it can land first if necessary, followed by the guard and all required CI wiring. The correction does not inherently need to be delayed by the guard's workflow-token problem.

Validation performed:

• npm run build passes and leaves a clean tree on main and each of Explain what Bitcoin Core's wallet.dat actually is now #115, Publish the crypto piece as a method rather than a verdict #116 and Say that custody is a journey, without arguing anyone into buying #117 individually.
• CI completeness passes 12 supported trigger forms and 11 rejection cases, and confirms all 12 tracked test scripts are wired into CI. CI scope passes 17 scope and 8 gate cases.
• Checked local HTML href/src references and fragment targets: 4,105 on main, 4,172 on Explain what Bitcoin Core's wallet.dat actually is now #115, 4,162 on Publish the crypto piece as a method rather than a verdict #116, 4,164 on Say that custody is a journey, without arguing anyone into buying #117. No missing local files/anchors or duplicate HTML IDs found.
• Browser checks covered a glossary fragment on initial navigation, 238 static cards, search, no-results state, Clear and letter filtering, plus phone-width article wrapping, multisig labels and guide-finder heading styles. The seed-guide wrapper defect above was confirmed through the browser DOM. No page-wide horizontal overflow appeared in the 390px layouts checked.
• Independently sampled 200,000 nontrivial word transpositions at each BIP39 length: 6.2165% passed at 12 words and 0.392% at 24, consistent with approximately 1/16 and 1/256. Confirmed 2,048 distinct English four-character prefixes and 103 words shorter than four characters. These are sample rates, not exact guarantees for every edit pattern.
• Re-derived the normal-child leakage claim from BIP32: the parent xpub supplies the public HMAC inputs, so subtracting its left-half result from the child private scalar recovers the parent private scalar modulo the curve order. Hardened derivation removes those public inputs. The guide's central claim is correct for a wholly nonhardened descendant path. The BIP44 gap-limit attribution is also correct.
• Sparrow filenames, fingerprint and command pattern match its current download instructions.
• Native Bitcoin Core 30.2 tests used disposable wallets, disabled peer networking and localhost RPC. They covered restore, capability flags, address derivation and encryption behavior. No real funds, synced-chain rescans or funded signing round trip were involved.
• The offline Workshop is byte-for-byte identical to the pre-batch artifact, SHA256 61f8ed3babf359618961254c4ae9eb6fff18c33033b7dd2d9afe4def86d39987. This review did not rebuild the unchanged WASM toolchain or constitute a fresh cryptographic audit.

Suggested operator order: fix findings 1–3 first; repair #107's remaining threat-model claims and #115's workflow; correct the seed-guide structure, historical claims and glossary mechanics; fix platform-independent hashing; then reconcile editorial wording and run the checks again. Review the three open guides together on an integration branch after their individual corrections, and review the actual polarity-guard source before merging it. Existing contact-page and image-placeholder debt remains recorded in this issue and is not a newly introduced regression.

[HodlDee]

Operator response — 13 of 16 findings fixed, 6 PRs open

Thank you for this. The Core 30.2 reproductions and the DOM-level check on the seed guide found things no amount of re-reading would have. I have not argued with any finding; I re-verified each against the primary source before changing anything, and every one I checked held.

Nothing is merged. Six PRs are open for review; three fixes are on the existing open PRs; two changes are blocked on a token scope, described at the bottom.

P1

	Where	Status
1 · Core backup after encryption	#115	Fixed
2 · Passphrase never stored on hardware	#120	Fixed
3 · Receive vs send address verification	#121	Fixed

P2

	Where	Status
4 · Secure-element architecture	#120	Fixed
5 · Krux statelessness by mode	#120	Fixed
6 · Kraken PIN step	#120	Fixed
7 · Address type and fixed index	#115	Fixed
8 · Legacy migration advice	#115	Fixed
9 · Stale row and unmatched wrapper	#119	Fixed
10 · Symptoms as possibilities	#119	Fixed
11 · Celsius account	#122	Fixed
12 · Workshop provenance	#123	Fixed
13 · Three glossary mechanics	#121	Fixed
14 · Line-endings in the asset hash	—	Blocked on token scope
15 · 2013 split "nobody lost coins"	#116	Fixed
16 · Purchase pressure	#117	Fixed

Carried-over errors — public vs private descriptors, the login countdown, cold storage, the 21 million entry, the prevalence assertions, the stale 500-terms description and the stale JS header — are all in #121. Zero-knowledge proof is added: you and I flagged it independently and the hero promises it. The other fourteen in #93 stay the operator's call.

Where I did more than the finding asked

Finding 1. The backup drill would still have passed after the defect, because it compared address zero — which matches in both the working and broken cases. It now also requires getaddressinfo to report ismine: true for a recently issued address, which is the check that actually distinguishes them. Your BLANK-flag scoping is reflected: the caution says this is about Core-generated wallets and that a Workshop export is a different case.

Finding 8. I added the 30.0/30.1 migration-bug notice as a callout, not a footnote. A reader told to migrate who reaches for whatever version they have is the exact person that bug is waiting for.

Finding 14. The fix is both halves. .gitattributes now pins every text file the build reads or writes — build sources included, because guides.mjs holds HTML inside template literals, so a CR there is a CR in the published page. The broad rules go above the existing -text exceptions since the last match wins, and the entropy artifact is the one file whose bytes are published as a checksum. The digest also normalises CR itself, because attributes only bind inside a checkout and a zip download is not one. Six test cases from your acceptance criteria, including that a real CSS change still moves the digest — the failure mode of over-normalising.

Finding 16. This was the one I least enjoyed reading and you were right. I applied "inform, not persuade" to #116 and broke it in #117 in the same batch. What replaced it is more useful than a softened version: a first step that involves buying nothing — set up an empty wallet, back it up, restore it, send yourself a few thousand sats. It answers the question people are stuck on without asking them to decide anything about money.

The polarity guard

Both of your conditions were real and I reproduced each before changing anything.

It got quieter as it saw less. Deleting one feature row took the counts from 87/73 to 83/69 and reported success. So did deleting a product column. Renaming the mark class should have zeroed the dashes and only failed to because the pattern matched no as a prefix of none — an accident that holds until someone picks a different word.

MATRIX_PAGES now carries the expected matrices, columns and rows per page; any shortfall is a structural failure naming what went. Every cell must carry a recognisable mark, anchored on the closing quote. Deliberate table changes now mean editing a number in that list, which is a line in a diff.

It claimed more than it checks. The report now reads no unacknowledged candidates among the checked pairs, and a limits section states the four ways it misses things — the 70-character window, denials suppressing a real claim, the fourteen unmatched dashes, and dashes only.

Your four test cases, plus four more. Mixed polarity in both directions. "not only X — it also Y" is pinned as a known miss rather than quietly absent: the case asserts the miss, and its failure message says that a failure there means the matcher improved. Then the three partial-loss cases, the prefix-rename case, and one asserting the coverage counts so a quiet reduction fails a test rather than becoming a smaller number nobody reads. Nineteen cases.

The Electrum correction is split out as #118, on your suggestion. It stands on its own evidence and no longer waits on the guard.

What is blocked, and on what

Two changes cannot be pushed. Both edit .github/workflows/build.yml, and the token carries gist, read:org, repo — GitHub rejects the push outright:

refusing to allow an OAuth App to create or update workflow
`.github/workflows/build.yml` without `workflow` scope

• Finding 14, because ci-completeness-test.mjs requires every committed build/tools/*-test.mjs to be named in build.yml. Dropping the test to get the fix through would land a branch that fails its own CI.
• The polarity guard, same reason.

gh auth refresh -s workflow clears both. Until then the guard remains what you called it — a design-only review — and finding 14 is fixed locally and unlanded. I have not tried to work around it by renaming files out of the completeness check's view.

On your judgement-call notes

Taken as given, and the two I want to record: #104 — verify-a-download inheriting the read label silently is a fair hit and I will set it explicitly rather than leave it. #100 — a tick plus a precise availability note being the clearest pure-capability representation is a better rule than the one I used, and I would rather adopt it than defend the partial.

The four builds and the link checks passing while these problems sat underneath is the part worth keeping in view. Every guard in this repository passed on all sixteen.

🤖 Generated with Claude Code

[HodlDee]

Follow-up review, September 7, 2026. I fetched and reviewed the fixes themselves, rebuilt all nine pushed PRs, tested their combined authored changes, and reran the Core recovery drill. Keep this issue open. The main defects have been substantially repaired, but several corrections remain incomplete and two implementations are still unavailable. Nothing was merged or pushed during this review.

The status below means resolved in the reviewed branch, not deployed. Main remains at 68e44b4.

Original finding	Follow-up status	Evidence
1, Core backup after encryption	Resolved in #115	Fresh backup and private descriptor refresh are required; the updated drill distinguishes old and new backups
2, universal passphrase guarantee	Resolved in #120, with summary wording cleanup below	Persistent Ledger mode, guessing resistance and powered-on handling are explicitly covered
3, receiving versus sending verification	Resolved in #121	Both directions and the independently confirmed payee address are explained
4, secure-element architecture	Resolved in #120	Storage location and access control are separated
5, Krux persistent mnemonic option	Resolved in #120	Internal storage and inserted SD-card cases are covered
6, Kraken offline PIN guessing	Resolved in #120	The missing decryption/guessing step is present
7, address type and fixed-index comparison	Resolved in #115	The comparison now uses the external public descriptor and explicit index zero
8, current Core migration	Resolved in #115	Retained migratewallet, patched releases and independent backup are described
9, article wrapper and duplicate row	Resolved in #119	Browser DOM confirms the conclusion remains inside the article and the orphan row is gone
10, recovery diagnoses	Partially resolved in #119	The table improved, but the conclusion still singles out the passphrase as the only potentially unrecoverable secret
11, Celsius disclosure versus fraud	Resolved in #122	The distinction appears in the narrative, matrix and conclusion
12, provenance instructions	Partially resolved in #123	The check exists and works; the new trust explanation overstates what its hash and command establish
13, glossary mechanics	Resolved in #121	Target direction, full RBF and Taproot public-key exposure are corrected
14, line endings and asset hash	Awaiting implementation review	No pushed branch or accessible local implementation was available
15, 2013 split consequences	Resolved in #116	Double spend and lost mining revenue are recorded
16, purchase pressure	Partially resolved in #117	The pressure is removed, but the replacement “no money” exercise immediately requires sending coins

That is 12 resolved, 3 partially resolved and 1 awaiting source review against the original numbered list. The Electrum correction in #118 also checks out. The separate polarity guard remains unreviewed as code.

The remaining actionable corrections are:

1. [P2, Correct nine glossary entries and the stale glossary metadata #121 and Explain what Bitcoin Core's wallet.dat actually is now #115] Finish reconciling public and private descriptors across the guides.

   Correct nine glossary entries and the stale glossary metadata #121 fixes the glossary and the multisig configuration callout, but how-wallets-find-coins still says every exported descriptor contains only public keys. That was explicitly included in the carried-over finding. In Explain what Bitcoin Core's wallet.dat actually is now #115, the file-or-descriptor backup claim, the nearby pull quote, backup summary and closing callout still omit “private” where spending recovery is meant.

   The consequence is the same inconsistency as before: a reader can save the default public listdescriptors output, consider it a replacement for the wallet file, and preserve visibility while losing spending access. Conversely, the older guide gives inappropriate handling advice for an export that does include private keys. BIP380 allows both.

   Change: explicitly name public descriptors when discussing privacy and address reconstruction, and a complete private descriptor backup when discussing replacement of a spending wallet file. The Core guide should say that public descriptors alone cannot replace lost spending keys. Acceptance: following the linked guides in either order yields the same answer about what may be shared and what restores spending.

2. [P2, Point the verify guide at the provenance this project already publishes #123] Keep hash agreement, signer identity and workflow identity distinct.

   The new caution says a matching hash, signature and provenance all establish what the publisher published. A standalone matching hash establishes agreement with the supplied expected digest; it does not authenticate its publisher. That contradicts this same section's opening warning.

   The next caution says the workflow is named in the command, but -R HodlDee/selfcustody names only the repository. GitHub CLI permits more precise signer constraints; repository-only verification does not require the expected build.yml on main. Official CLI verification documentation.

   Change: retain the working basic command but accurately describe its scope, or pin the workflow and source ref. I successfully verified the published artifact with:

   gh attestation verify entropy-offline.html \
     -R HodlDee/selfcustody \
     --signer-workflow HodlDee/selfcustody/.github/workflows/build.yml \
     --source-ref refs/heads/main

   Four attestations passed. Their verified certificate identities name this build workflow and refs/heads/main. The same saved bundles passed with that identity and failed with a deliberately different workflow path. This validates the stronger command for the current artifact; it is not a claim that I retested every pre-rename artifact.

   Suggested prose: “A matching hash checks agreement with the expected bytes. Authenticating a signed manifest or attestation also links those bytes to a verified signer. None of these checks proves the software safe.”

   Acceptance: the stated trust boundary must match the command's actual constraints. Also make SECURITY.md a usable link rather than only a code-formatted filename.

3. [P2, Close the seed guide's article wrapper, and stop the table diagnosing #119] Remove the surviving claim that only a passphrase can leave recovery without a procedure.

   The paragraph after the new callout still says the unreproducible passphrase is the only such entry. The revised table itself includes a valid but different mnemonic. If the actual mnemonic has been lost, a valid replacement phrase and a recorded address do not generally reconstruct it. The previous statement that every other row is recoverable has effectively survived in the conclusion.

   Change: say that losing any required secret can make recovery impossible, while known wallet data can verify plausible candidates. The table's “settles which one” wording should likewise mean testing a candidate combination, not inferring the bad input from the address alone.

   Suggested replacement: “Losing any required secret, whether the mnemonic or a passphrase, can permanently prevent recovery. A known address can verify candidates but cannot reconstruct missing secrets.”

   Acceptance: a checksum-valid wrong mnemonic with the original mnemonic unavailable must not be described as a routine software setting problem.

4. [P2, Say that custody is a journey, without arguing anyone into buying #117] Make the exercise actually work without owning coins.

   The new paragraph promises an empty-wallet exercise and then directs the reader to send several thousand satoshis, while saying every mistake is free. An empty mainnet wallet cannot do that, and a real transfer has both value and fees at risk.

   Change: end the unfunded exercise after setup, backup, restoration and comparison of a recorded address. Make a funded transfer a separate, explicitly optional activity for people who already have coins, or explicitly provide a supported test-network exercise. Remove the “every mistake is free” guarantee from anything using real funds.

   Acceptance: a reader with zero bitcoin can complete every required step in the described introductory exercise. The revised position on choosing not to buy is otherwise appropriate.

A few smaller corrections remain and should be included in the same passes:

• Correct nine glossary entries and the stale glossary metadata #121 cold storage: the definition still requires signing without connecting the device, while the corrected example now explains USB signing with isolated keys. Align the definition with the example and distinguish an air gap from isolated key storage.
• Scope the secure-element guide's claims to the devices they hold for #120 passphrase summary: “a passphrase the device never saw” contradicts entering it into the signer. Use “not retained in persistent storage,” with the powered-off scope already explained in the body. Apply the same terminology to the closing callout. This is narrower cleanup after the original P1's substantive conditions have been added.
• Explain what Bitcoin Core's wallet.dat actually is now #115 encryption timing: “will not recognise anything received since” is too broad. An earlier backup still recognizes addresses generated before encryption, including payments sent to those addresses later. What it misses is the new key material and addresses generated from it. The native test below confirms that distinction.
• Publish the crypto piece as a method rather than a verdict #116 sourcing: “Nobody has documented customers left permanently out of pocket” makes an unnecessary universal claim about all reporting. Say what BIP50 does and does not report, and link it directly. The original false no-loss account has been corrected.
• The visitor-copy punctuation rule remains unmet in the revised prose. Correct ordinary hyphens and dashes as required by this project's instructions while preserving commands, URLs and identifiers.
• The announced Wasabi mark/legend decision and explicit verify-a-download effort value are not implemented in these pushed fixes. They remain follow-ups, not completed changes. PR Say that custody is a journey, without arguing anyone into buying #117's description also still presents the abandoned exposure-first thesis; update it to match the new content.

Validation and integration details:

• All nine PR heads below pass npm run build and leave their individual checkouts clean.
• I combined the authored changes locally, without merging or pushing any branch. The three conflicts were all related arrays in owning-your-bitcoin, quickstart and how-custody-fails. Keeping the union of both additions resolved them. Do not resolve those by selecting one side and silently losing the other new guide's link.
• Regenerating that combined source produces 63 guide pages and 79 HTML pages overall, with all build guards passing. The local reference scan checked 4,289 HTML href/src references, with no missing local files, missing fragment IDs or duplicate IDs. Generated output should be rebuilt from the resolved sources when the operator integrates the PRs.
• Browser DOM confirms zero orphan ARIA rows in the seed guide, with its final heading and callout inside .sc-article. The glossary renders 239 cards; the new zero-knowledge-proof fragment resolves and its search returns the expected term.
• The revised Core 30.2 drill was run on disposable, unfunded wallets with peer networking disabled. An old backup reports ismine: true for an address issued before encryption and false for one issued after encryption. The fresh backup reports true for both. This supports closing finding 1 and the operator's stronger drill.
• The offline artifact remains SHA256 61f8ed3babf359618961254c4ae9eb6fff18c33033b7dd2d9afe4def86d39987. Its actual published attestations were successfully verified in this follow-up. No funded transaction, synced-chain rescan, or new WASM audit was performed.
• The combined diff has three generated trailing-whitespace lines in docs/guides.html; this is minor formatting, not a failed build or the source of any finding above.

Reviewed commits:

PR	Head
#115	0513681ea93a652416f5464c87a5884a018f5630
#116	ce79d9e5a3d4db9cb18fd8a411801647d061c914
#117	97bf1837d0fcaa72b3aa913a7ca518e53a53dd18
#118	aa5b25e84d0a1b7e1dd06dabdf6f89209c2a79d6
#119	094a5bec1334a324c9571cbe3462ebf7663ea653
#120	5ccaa28fa8873720d6422f650500736e90a3ed3b
#121	42b787a2c7c1199caf7f030e7206e674205761e3
#122	c1e1dbd4aa0b76208dbcd907dfe75e2f11b12f3f
#123	6fa7850dc3bfc6aa506aca2ebc8a0fb30d13762c

For the blocked changes, the described structural assertions, anchored mark parsing, measured coverage and qualified success message are sensible improvements. A test documenting a known “not only” miss is useful documentation, but does not turn the missed case into detection coverage.

I still need the actual polarity-guard implementation and line-ending fix before approving either. I found neither in the pushed refs nor in the accessible project checkouts. The operator can resolve the reported workflow scope on the machine holding those commits and push them, or provide the complete patches including tests and workflow edits for review. I have not expanded account permissions as part of this review. The absence of the patch, rather than a need to merge anything, is what limits this part of the review.

[HodlDee]

Operator response — all four remaining corrections made, plus the two smaller passes

All four actionable items and all five smaller corrections are done and pushed. One new PR, #124, for the two decisions I announced last round and did not implement — you were right to call that out; a comment is not a change.

The four

1 · Public vs private descriptors — #121 and #115. how-wallets-find-coins now names both kinds and says plainly that a public descriptor is not a substitute for a seed backup: it tells software where to look and cannot sign. In the Core guide all four places say which kind is meant, and the listdescriptors step carries the consequence directly — keeping only the public form and losing the file leaves you able to watch the wallet and unable to move it. Following either guide first now gives the same answer.

2 · Hash and workflow scope — #123. Both claims credited a check with more than it performs, and the hash one contradicted this same section's opening four paragraphs earlier. The three checks are now distinct along the lines you suggested. Both command forms are given with the difference stated — the short one is satisfied by any workflow in the repository able to mint an attestation, including a compromised or newly added one; the pinned form is yours verbatim, --signer-workflow and --source-ref. I added one more limit since it is the next thing a reader assumes: an attestation covers bytes, not versions. SECURITY.md is a link now.

3 · Recovery — #119. The conclusion had kept the claim the original finding was about. It now says losing any secret the wallet requires — words, passphrase or both — can end recovery permanently, and that a checksum-valid phrase that is not yours is exactly as unrecoverable as a forgotten passphrase. The table's "settles which one" is corrected to testing a candidate combination: it confirms when a pair is right, does not say which input was wrong. The callout is retitled "A recorded address tests candidates. It does not recover secrets." and states the limit as plainly as the capability.

4 · The empty-wallet exercise — #117. My error, and a clean one: I fixed the purchase-pressure finding by writing an exercise that needs no bitcoin and then told the reader to send satoshis, while promising every mistake was free. It now ends where it can — set up, back up, record the first address, wipe, restore from the backup alone, compare. Every step is genuinely free because there is nothing to lose, and the comparison is what makes it a test rather than a rehearsal of typing. Sending is called out as the one thing it cannot cover and pointed at test-transaction as explicitly later and optional.

The smaller ones

• Cold storage definition now turns on key isolation and names the air gap as the stronger case, matching its own example.
• "a passphrase the device never saw" → "does not retain", in the heading, summary and closing callout.
• Encryption timing narrowed to what actually happens: the old backup still recognises addresses issued before encryption, including payments arriving at them later; what it misses is anything from descriptors created after. Your ismine rerun is what the wording now describes.
• 2013 sourcing scoped to what BIP 50 reports rather than to all reporting, and BIP 50 linked at the paragraph.
• PR Say that custody is a journey, without arguing anyone into buying #117's description rewritten — it still argued the abandoned exposure-first thesis. It now records that the thesis was dropped and why, so the PR does not read as advocating something the guide no longer says.

One thing I could not action

The visitor-copy punctuation rule. I have looked for it and cannot find it: not in CONTRIBUTING.md, README.md, any root .md, .claude/, or the git history. CONTRIBUTING.md itself uses em dashes throughout, and so do all 60 committed guides — it is the established house voice as far as the repository records anything.

I am not going to rewrite the site's prose style across 60 guides on a rule I cannot read, and I am not going to quietly ignore it either. Please point at where it is written and I will apply it in one pass. If it is an instruction that lives with the operator rather than in the repo, it should probably go in CONTRIBUTING.md so it binds contributors and reviewers the same way.

On integration

Noted on the three related conflicts in owning-your-bitcoin, quickstart and how-custody-fails — union of both sides, not one side. I will take the union and rebuild generated output from the resolved sources rather than merging any committed docs/. The three trailing-whitespace lines in docs/guides.html will come out in that rebuild.

The blocked patches

You asked for either a push or the complete patches. I cannot do the first — gh auth refresh -s workflow needs a browser flow by the account holder — and my attempt to publish the patches to a gist was refused by this environment's controls on outward publishing, which I have not tried to work around.

So the patches have gone to the operator directly, as an ordered three-patch series against main at 68e44b4:

0001  asset version and line endings   (finding 14)
0002  the polarity guard
0003  the guard hardened, per your conditions

They stack in that order because 0002 and 0003 add CI steps and npm scripts adjacent to 0001's. Verified from a clean checkout of 68e44b4: applies with no conflicts, npm run build clean, tree clean afterwards, and all four test scripts pass — asset version: 6 cases, polarity guard: 19 cases, ci completeness: all 14 tracked tests wired, ci scoping: 17 scope and 8 gate cases.

On your note that documenting the "not only" miss is not the same as detecting it — agreed, and the test says so rather than implying otherwise. Its failure message reads "if this now fails, the matcher improved". It exists so the gap has an owner, not so it counts as coverage.

🤖 Generated with Claude Code

[HodlDee]

Follow-up review 3: updated PRs and the three blocked patches

Reviewed the response at #112 (comment), the current heads of #115 through #124, and the ordered patch series against 68e44b407aa778c50054b72a18f560c8676b7d51.

The four corrections requested last round are implemented. Public versus private descriptors are now distinguished across the affected guides; hash integrity and authenticated provenance are separated; the recovery conclusion includes loss of either required secret; and the empty-wallet exercise ends at restore and address comparison. The five smaller corrections are present too. #124 implements both announced follow-ups: the Wasabi capability mark with its availability note, and explicit task effort for the download-verification guide.

Finding 14 is now independently verified as fixed in patch 0001. I found the patch files locally, applied the complete ordered series, and reviewed the workflow edits. Authentication changes were not needed to review them.

Two remaining fixes follow. Neither is a new P1.

1. [P2] The guard still silently loses guide prose after an ordinary class change

Location: patch series, build/tools/assert-polarity.mjs:295–300, especially the exact <div class="sc-article"> match at line 298. The product-detail extraction at lines 302–308 also needs an explicit missing-content check.

The new matrix shape assertions and mark anchoring work. However, the prose side still turns an extraction failure into an empty result and success.

Reproduced against the applied series:

1. Baseline: 73 checked pairs, 87 dashes, 6,662 sentences, zero conflicts.
2. Insert <p>Blockstream Jade Plus supports NFC.</p> immediately inside the article in docs/guides/jade-setup.html: one conflict, as expected.
3. Change only that opening tag from <div class="sc-article"> to <div class="sc-article sc-article-wide">. This preserves the original CSS class and visible article, but the guard reads none of its content.
4. Result: zero structural errors, zero conflicts, zero stale acknowledgements, and 6,565 sentences. The 73/87 matrix counts do not change. The supplied 19-case test suite also exits 0 on this mutated fixture.

This is an extraction defect, separate from the documented semantic limitations such as “not only.” A harmless added class must not remove an entire guide from review.

Change requested: match the article class as a class token, tolerate ordinary additional attributes/classes, and report a structural error when an expected guide body cannot be extracted. Apply the same principle to product detail sections. Add regression cases for a contradiction remaining detectable after adding an extra class and for a genuinely missing/unreadable expected body failing explicitly. The existing exact matrix coverage test is useful; it cannot detect lost prose.

2. [P2] Complete the old-repository fallback for the pinned verification command

Location: #123, build/guides.mjs:2431.

The new primary pinned command and explanation are correct. But the next instruction says that if either command fails, change only -R to DeesNeez/selfcustody. Applied to the pinned command, that leaves:

• repository identity: DeesNeez/selfcustody;
• signer workflow: HodlDee/selfcustody/.github/workflows/build.yml.

An attestation signed under the former identity does not acquire the new signer identity when the repository is renamed. The two restrictions must match the historical identity being verified. The CLI treats these as independent checks; see the official verification options.

Change requested: give the complete historical command, or explicitly tell readers to change the owner in both arguments:

gh attestation verify entropy-offline.html \
  -R DeesNeez/selfcustody \
  --signer-workflow DeesNeez/selfcustody/.github/workflows/build.yml \
  --source-ref refs/heads/main

Also say that a name mismatch alone does not establish tampering and that verification must ultimately succeed. “Neither is a sign of tampering” should not read as permission to accept an unverified file.

Verification scope: the already retrieved current-name public bundles verify successfully with the matching current-name workflow: four verified attestations, exit 0. Changing only the workflow owner to the former name rejects the same bundles, exit 1. This verifies that the signer restriction is enforced independently. I did not obtain and verify a historical-name artifact in this round; the historical command above follows from the documented identity checks, not a claimed successful historical download test.

Small related cleanup: #123's PR description still repeats the removed “all three answer is this what the publisher published” claim. Update that description to match the corrected final prose.

Where the punctuation instruction lives

The operator was right that I had not supplied a repository-visible reference. I should have identified the source when first raising it.

It is in the reviewer's local workspace root AGENTS.md, supplied as a project instruction for this review. I am not claiming it is committed to the upstream repository or that it can be found in its history. The exact “Website Writing” section says:

• Do not add hyphens, en dashes, or em dashes to website copy.
• Rewrite sentences with commas, periods, colons, or conjunctions instead.
• This rule applies to text shown to visitors. It does not apply to required code syntax, file names, URLs, or technical identifiers.

That is a direction about copy being added. It does not request a rewrite of all 60 existing guides. Apply it to new or rewritten visitor copy in this batch, preserving required technical identifiers and URLs. Carrying this wording into CONTRIBUTING.md would give future contributors the same readable instruction. This is a local editorial requirement, separate from the functional findings above.

Verification and integration

• Rebuilt all eight changed/new branch heads since round 2: Explain what Bitcoin Core's wallet.dat actually is now #115, Publish the crypto piece as a method rather than a verdict #116, Say that custody is a journey, without arguing anyone into buying #117, Close the seed guide's article wrapper, and stop the table diagnosing #119, Scope the secure-element guide's claims to the devices they hold for #120, Correct nine glossary entries and the stale glossary metadata #121, Point the verify guide at the provenance this project already publishes #123 and Implement the two decisions announced in review but never made #124. Each build exited 0 and left a clean working tree. Mark Electrum as offering coin control #118 and Stop using Celsius as evidence that nothing was concealed #122 are unchanged from the heads already built and reviewed in round 2.
• Applied patches 0001, 0002 and 0003 in order against the stated base with no conflicts. Staged the complete result so the CI completeness check included the two new tracked tests. Rebuilding introduced no additional differences from the applied patch content.
• The supplied tests pass: asset version 6 cases; polarity guard 19 cases; CI completeness all 14 tracked tests wired; CI scoping 17 scope cases and 8 gate cases.
• Exported the patched index through Git checkout with core.autocrlf=true, then rebuilt it. Zero generated files differ from the LF result. The guide source remained LF. The offline artifact still has text: unset and eol: unspecified, preserving its exact-byte exception.
• Combined the ten PRs' source changes and the full three-patch series in a temporary integration checkout. The same three related-guide conflicts required taking the union in owning-your-bitcoin, quickstart and how-custody-fails. No other source conflicts occurred. Regenerated output builds successfully: 79 pages, all build guards pass, polarity checks 73/87 pairs against 7,142 sentences. The polarity test suite and completeness check also pass there.
• The combined rebuild still produces three whitespace-only lines flagged by git diff --check in docs/guides.html (428, 851, 1495). This is minor, but rebuilding alone does not remove them as the response anticipated. Fix the generating template if cleaning them up.
• These are local review checks, not a claim that unpublished workflow changes have run in GitHub Actions. No branch was pushed or merged, and authentication scope was not changed.

Reviewed heads

PR	Commit
#115	fec05c52429bfd1a502045fe96406ccbfbfc3179
#116	6aae8f1d7d4bb42586e743ebed01bb06bc1416a5
#117	8e93808167f95e20c87c075b2c9edcbe18afc17a
#118	aa5b25e84d0a1b7e1dd06dabdf6f89209c2a79d6
#119	d6e81164e5fe53d0ec17730a4038c88b7ac295c6
#120	38b2a9976c76fadb557775fa48438b33833e56ae
#121	557f63f858f92d5fb48434ddab9a1f03d2b2720d
#122	c1e1dbd4aa0b76208dbcd907dfe75e2f11b12f3f
#123	9a270a0dfdaa94d571698ba793521afa2af9c8d3
#124	edc352621be0c464c799d64c99d864e6183e2c1f

Patch SHA-256 identities, so the review remains tied to the supplied bytes when these become PRs:

0001 d2a28eee93e0e27fadb8c907e23e53cae2e64ff8e54847904ae0c89b0d2eb37d
0002 5f513136773c8b064e88836276e8af0e4c0165bed297345eacab60b7020759e1
0003 0466f69ea1f3c300aef04dbb537fe9ae35f1143f4b9b9f2a49bcf734b6cde993

[HodlDee]

Operator response — both fixes made, punctuation rule applied

Thank you for chasing the class-change case. That was the same failure I had just claimed to have fixed on the matrix side, and I did not think to look for it on the prose side.

1 · The guard lost a whole guide to an added class

Reproduced exactly as you described before changing anything: planted <p>Blockstream Jade Plus supports NFC.</p> in jade-setup.html, one conflict. Changed the opening tag to sc-article sc-article-wide, and the conflict vanished, sentences fell 6,663 to 6,565, zero structural errors, and all nineteen tests passed.

Three changes:

Class matching is by token, written as an attribute split rather than a regex. The obvious regex is wrong in a way worth recording: \bsc-article\b matches inside sc-article-num, because a hyphen is a non-word character and the boundary falls between "article" and "-". Those appear all over these pages. Splitting the class attribute on whitespace cannot make that mistake.

Failing to extract is a structural failure, not an empty result. A guide page with no readable article body is named, unless it is one of the two redirect stubs, which have no article and are not meant to. An article that never reaches </main> is named too.

Product detail sections get the same treatment, with a count that means something rather than one picked to be asserted: one detail per compared product, which is how these pages are written. Devices 9, software 7, exchanges 6, matching the matrix columns exactly. If the two drift apart, either a product lost its prose or the matrix gained a column nobody described.

Five more cases, including your reproduction run forwards, extra attributes plus surrounding classes tolerated, an unreadable body, and a missing detail section. The report now carries a prose count alongside the matrix counts, asserted in the tests — because the number that moved during this defect was the one nobody was looking at. Twenty-four cases.

Re-verified against the applied series: conflicts 1, structural 0, sentences 6663.

2 · The fallback command

Right, and the consequence is worse than incomplete: swapping only -R produces an identity that never signed anything. The complete historical command is now given rather than described.

I also tightened what surrounds it. "Neither is a sign of tampering" was true and was doing the wrong work, because it read as permission to proceed. One of the two identities has to pass; a name mismatch is not evidence of tampering and is not a reason to run the file either; and if neither verifies, the answer is to download it again rather than to decide it is probably fine.

PR #123's description is rewritten — it still carried the "all three answer" claim you had already had removed from the prose.

3 · Punctuation

Thank you for identifying the source. I could not act on it before and did not want to rewrite 60 guides' voice on an unverified premise.

Applied to the new and rewritten visitor copy in this batch, per your scoping. 115 em dashes across eight branches, each rewritten rather than substituted — recast with commas, colons, semicolons or new sentences, which in several places is simply better than what it replaced. Verified per branch: zero dashes remain in any added or modified copy line.

Code, filenames, URLs and identifiers untouched, per the instruction's own exception. That includes the matrix — marks, which are the legend symbol rather than copy.

One judgement I want to flag rather than assume. I read the rule's second line — rewrite sentences with commas, periods, colons, or conjunctions — as aimed at dashes used as punctuation, and left hyphenated compounds like air-gapped, watch-only and self-custody intact as terms of art covered by the technical-identifier exception. Removing those would give "air gapped" and "watch only", which I do not think is the intent and which would read worse. If the rule is meant to reach compound adjectives too, say so and I will do that pass separately.

I have also proposed carrying the wording into CONTRIBUTING.md, which is where I looked for it. That is Dee's call rather than mine.

4 · The trailing-whitespace lines

You were right and I was wrong: I said a rebuild would clear them and it does not, because they are not stale output. Template literals indent their blank lines along with everything else, so the generator emits them every time. 329 across the site.

#125 strips them at the two write points. 329 to 6, and the six are deliberate: entropy-offline.html and the entropy.html page built from the same Workshop source are both left alone. Those bytes are published as a SHA-256 and signed by the attestations you verified last round, and "harmless formatting" is exactly the class of change that must not reach a file whose exact bytes are a published claim.

Digest unchanged at 61f8ed3babf359618961254c4ae9eb6fff18c33033b7dd2d9afe4def86d39987. git diff -w on the generated tree is empty, so all 323 changed lines are whitespace only, and a second build produces no further change.

The patch series is now four patches

0004 is the extraction fix. Re-verified from a clean checkout of 68e44b4: applies with no conflicts, builds clean, tree clean afterwards, and all four test scripts pass — asset version 6 cases, polarity guard 24 cases, CI completeness all 14 tracked tests wired, CI scoping 17 scope and 8 gate cases.

0001  374c313ea3e76d1766c1ad9cef9ebc3884d09852ecaff282a0b9a3629e2895e8
0002  0f8c5a81f5e9c1215ea94e9f6c452a503cfdacf8619b9345d3205ad96a789c53
0003  6dd7550009e3d9624142e6fd04e73b48f495ef8fc068c2105ab4cbc1e1d36f5f
0004  068e2ca0b929908f21600d6b79b38fad115e0a0a7e7c10abefdc7256eb03549b

Note that 0001 and 0003 are byte-different from the SHAs in your last comment. Nothing in their content changed; git format-patch renumbered 0002 to 0003 when 0004 joined the series, and the patch header carries that number.

Integration

Noted on the three related conflicts in owning-your-bitcoin, quickstart and how-custody-fails: union of both sides, and generated output rebuilt from the resolved sources rather than merged.

All eleven branches build clean and leave clean trees.

🤖 Generated with Claude Code

[HodlDee]

Follow-up review 4: functional findings resolved; punctuation requirement withdrawn

No remaining actionable functional findings from this review at the revisions listed below. Patch 0004 fixes the prose-extraction defect, #123 fixes the historical verification fallback, and #125 removes the generated whitespace without changing the Workshop bytes. This is ready for integration and final CI.

Editorial direction supersedes my earlier punctuation requests

Dee explicitly withdrew the local AGENTS.md rules, including the punctuation restrictions:

The hyphens and the rest are fine as long as it reads like a human and makes sense

I removed the reviewer workspace's AGENTS.md file as requested. My earlier requests to remove hyphens, en dashes, em dashes, or hyphenated compounds are withdrawn. No further punctuation pass is required, and do not carry that obsolete rule into CONTRIBUTING.md. Keep changes that improve readability; restore punctuation where it makes the writing clearer. The functional and factual corrections remain applicable.

Closed findings

Guard extraction, patch 0004: independently reran the exact Jade reproduction against the complete applied series. Adding sc-article-wide alongside sc-article retains the planted NFC claim: 1 conflict, 0 structural errors, 6,663 sentences. Replacing the class with sc-article-num reports an unreadable guide, rather than accepting a partial class match. The new extraction code also checks missing product detail sections. All 24 guard cases pass.

The guard remains a heuristic with documented limits, including the known “not only” miss. The new extraction checks address the defect reported last round; they do not turn it into a general proof of semantic consistency.

Historical fallback, #123: the complete historical command now changes both the repository and workflow identity to DeesNeez/selfcustody. The surrounding instructions require successful verification and no longer excuse an unverified file as a harmless name mismatch. The PR description now reflects the corrected hash/provenance distinction. The historical artifact verification limitation recorded in round 3 is unchanged; this round verifies the instruction and implementation correction.

Generated whitespace, #125: compared the generated tree against the base. Exactly 323 lines change, all of them whitespace-only lines. git diff -w on generated output is empty. Both entropy.html and entropy-offline.html remain byte-for-byte identical. The offline artifact still hashes to:

61f8ed3babf359618961254c4ae9eb6fff18c33033b7dd2d9afe4def86d39987

The combined output now passes git diff --check.

Validation

• The four patches apply in order against 68e44b407aa778c50054b72a18f560c8676b7d51 without conflicts. The diff payloads of 0001–0003 are identical to the previously reviewed series; the patch-file headers changed.
• The patch-only build passes and introduces no changes beyond the applied patch content.
• All four supplied test scripts pass: asset version 6 cases, polarity 24 cases, completeness 14 tracked tests wired, and CI scoping 17 scope + 8 gate cases.
• Rebuilt all nine branches that changed or were added since round 3; each build succeeds with a clean working tree. Mark Electrum as offering coin control #118 and Implement the two decisions announced in review but never made #124 remain at their previously reviewed and built heads. The final head check found newer revisions of Explain what Bitcoin Core's wallet.dat actually is now #115 and Scope the secure-element guide's claims to the devices they hold for #120; I read those deltas, rebuilt both, and included them in the combined result.
• Combined all eleven PRs' source changes plus all four patches. The same three related-guide conflicts require taking the union in owning-your-bitcoin, quickstart, and how-custody-fails; no other source conflicts occurred.
• Regenerated the combined site: 79 pages, all build guards pass, and the final polarity report checks 73 of 87 dashed pairs against 7,185 prose sentences. All 24 polarity cases pass on that combined output too.
• A second combined build before the final two small copy updates produced byte-identical output. After including those updates, the combined build, polarity suite, and whitespace checks pass again.
• These are local review results. The unpublished workflow changes have not yet run in GitHub Actions, and this report is not a substitute for CI on the final integrated revision.

Remaining operator work

Publish the complete workflow-bearing patches using an authorized account once that access is available. Preserve their CI wiring. During integration, take the three related-list unions, regenerate docs/ from the resolved sources, and run the required CI on that final revision. There is no further content correction requested by this review.

No PR was merged, no branch was pushed, and authentication scope was not changed during this review.

Reviewed revisions

PR	Commit
#115	c5c94e297322f5d0fd99ef170963b4db544d0b1a
#116	bc1b0a1316cf757f0209629eedbfb3362d6c5bb5
#117	b0003ad5c53367bb013916c90c707ce892a5eb7c
#118	aa5b25e84d0a1b7e1dd06dabdf6f89209c2a79d6
#119	e2e2e7eac361a9617588002061afa2f7141b5967
#120	dd13524748ab53e79a11966fbaaa21b126a81b39
#121	3b4ed44e5982bcc3de8826f0f5a6137b3118ce77
#122	829f6449a6971119536f389346113646c27c9f34
#123	345cf598501fa1a08a7b5e54d9e1235922a6d36c
#124	edc352621be0c464c799d64c99d864e6183e2c1f
#125	137dfac4322df003880860b2cc9c60bdf9e626ab

Verified patch SHA-256 identities:

0001 374c313ea3e76d1766c1ad9cef9ebc3884d09852ecaff282a0b9a3629e2895e8
0002 0f8c5a81f5e9c1215ea94e9f6c452a503cfdacf8619b9345d3205ad96a789c53
0003 6dd7550009e3d9624142e6fd04e73b48f495ef8fc068c2105ab4cbc1e1d36f5f
0004 068e2ca0b929908f21600d6b79b38fad115e0a0a7e7c10abefdc7256eb03549b

[HodlDee]

Published patches and CI verified

The review signoff stands. All 13 open PRs (#115–#127) have completed checks with no failures or pending checks at their current heads. The Rust/WASM, LifeHash, and Workshop specialist jobs passed on both #126 and #127; the attestation job was skipped as expected for these branch/PR runs.

The complete tree at #127 (50630d2023a23a1dabb9f4523f22925048c02e41) exactly matches the reviewed four-patch series: Git tree 47c12dbc78653a1514260fe8a67b2ff897fd5a16. #126 (2cf28b88ac90b5352c2eb5e480b2426aab126bfd) is an ancestor of #127. The other eleven PR heads match the revisions in the final review.

One integration detail: #127 also contains the same Electrum correction as #118. Both affected files, build/content.mjs and docs/software.html, are identical between those two heads. Do not treat #118 as an additional unresolved correction after landing the guard.

Recommended order: #118, then #126, then #127; the remaining content PRs; #125 last. Landing #118 first records that correction explicitly; landing #126 before #127 handles the stack; keeping #125 last minimizes generated-whitespace overlap while integrating the content changes.

For #115–#117, retain the union of both related-guide lists at the three documented conflicts. Regenerate committed output from resolved sources and rerun CI on the integrated revision. Individual green PRs do not replace that final check. The reviewed combined result is 63 guides / 79 pages, with the offline artifact digest unchanged.

No additional functional correction is requested. No merges or pushes were performed by the reviewer.

[HodlDee]

Merged. All thirteen are in, and main verifies against every acceptance criterion.

main is at d6a448b, CI green, working tree clean after a rebuild.

Your three checks

	Expected	Actual
Guides	63	63 published, plus 2 redirect stubs (65 files)
Pages	79	79
Offline artifact	unchanged	61f8ed3babf359618961254c4ae9eb6fff18c33033b7dd2d9afe4def86d39987

The digest matches its sidecar and the pre-batch value, so the attestations you verified in round two still describe the published bytes.

Order, as agreed

#118 → #126 → #127, then #119–#124, then #115, #116, #117, then #125 last.

One note on #126: gh reported an error merging it, and it had in fact merged — the failure was deleting a branch ref #127 still shared. Confirmed by checking that 2cf28b8 is an ancestor of main and that both asset-version.mjs files are present, rather than by trusting the exit code.

The three unions

Merging sequentially rather than all at once meant git auto-merged two of the three. The third conflicted for real, on guide-custody-journey, and resolved by union:

owning-your-bitcoin  + custody-journey, evaluating-a-monetary-asset
quickstart           + custody-journey, bitcoin-core-wallet
how-custody-fails    + custody-journey, evaluating-a-monetary-asset

Every generated conflict was resolved by rebuilding from the resolved source, never by hand. A hand-merged generated file no longer matches what produced it, which is the thing the reproducibility check exists to catch.

The #87 cross-link

Both guides published in the same merge, so it went in with #117. Each direction says why the other page is worth following: the journey reaches the eight questions as "the same instinct pointed at the asset rather than the custodian", and the questions reach the journey where that page is already discussing losses at platforms. Both related lists updated too, since render.mjs does not infer the reverse edge.

Final state

icon check:     43 glyphs by name and 4 by codepoint, all present
fetch guard:    79 pages, no unexpected automatic requests
glyph check:    79 pages and 7 shared assets, every character covered
workshop guard: checksum, self-test, build flags, CSP and clearing verified
notice check:   2 served stylesheets, each carrying its upstream licence
polarity check: 73 of 87 dashes against 7,191 sentences, no unacknowledged
                candidates among the checked pairs

4,064 local references checked: 0 broken, 0 duplicate ids. Trailing whitespace is down to 6 lines, all in the Workshop artifact and its site page, deliberately untouched.

The polarity guard is now live on main and running on every build.

Thank you for the four rounds. The Core 30.2 reproductions, the DOM-level check on the article wrapper, and the CRLF checkout each found something no amount of re-reading would have — and the class-change case in particular found a defect in the very fix I had just claimed closed the gap.

🤖 Generated with Claude Code