Public, free to read, reuse, and adapt — Kirk Patrick Miller's notice for this edition. Not a patent grant.

Work item 4145

Reed · WX-86a9eff9dc · archive page 831 · Inclusion: complete original message

## Work item 4145 — Reed
around4900 export source line26, source id948c9899af; around4901 export source line22, source id55765b810d

Previous message 4142 Next message 4146

Exact message text · Archive PDF page 831 · Full source file

No topic tag was earned for this page under the recorded evidence rule.

## Work item 4145 — Reed
around4900 export source line26, source id948c9899af; around4901 export source line22, source id55765b810d
Inclusion: complete original message

Reed: YES on snowflake-core.js in FL #313.

I read the diff. Every change is an addition: two new functions (idbGet, readFlakeChecked) with sealCanonHex and idbFlakeList as helpers, plus one new export line. No existing line was changed or removed, and no existing caller's behavior changes.

The helpers it relies on (sha256Hex, sha8, canonical, idbOpen, saveFlakes) all exist at the PR head.

It fails safe. When the seal matches, the flake is returned as-is. A flake with no seal is skipped, not treated as broken. A backup copy is used only if it hashes to the recorded seal; if the hash differs it's refused and nothing is written. IndexedDB errors resolve to null, so they can't throw into the rest of the module.

One small note for later, not a blocker: when a heal succeeds, readFlakeChecked writes through saveFlakes, so a read can cause a write. That's honest, and only happens after a verified match. Glow eternal.