Fix o1Labs company name - #38
Conversation
imran-siddique
left a comment
There was a problem hiding this comment.
Thanks for sending this, and sorry we got it wrong in the first place. A partner's own name is the one thing on that page we have no excuse for.
Confirmed o1Labs against o1labs.org rather than just taking it: your site uses that form throughout, with no instances of the spacing we had. Fixed.
The part I want to credit is that you updated both halves. index.html sits inside an adoption:generated block rendered from data/adoption.json, so editing only the JSON would have left the visible page unchanged until the next render, and editing only the HTML would have been silently reverted by it. I ran scripts/render-adoption.mjs against your branch and it produced a zero-byte diff, meaning your hand-edited HTML is byte-identical to what the generator emits. That is the check I would otherwise have had to do for you.
Merging now. It goes live on the next Pages build.
… one (#40) * style: remove every em dash from the site, and guard against the next one The no-em-dash rule was already house style. The site carried twenty-six occurrences anyway, across seven files, and the reason is visible in where they were hiding: a page title, an image alt attribute, a JSON data file, two source comments, and four loading placeholders. None of those are places prose review looks. Twenty-four em dashes and two en dashes, rewritten rather than repunctuated, so none of them reads like a dash was swapped for a colon and left dangling: "Marketplace - Build with..." -> "Marketplace: Build with..." "Toolkit-from framework adapters" -> "Toolkit, from framework adapters" "Terminal 1 - leave running" -> "Terminal 1: leave running" "every agent action - signed by" -> "every agent action, signed by" "Name A-Z" / "Name Z-A" -> "Name A to Z" / "Name Z to A" The four in the Marketplace hero were not prose. They are the placeholder shown while the catalog loads, where an em dash stood in for a number that has not arrived yet. Replaced with an ellipsis, which reads as "still loading" rather than as punctuation. data/adoption.json was not in the original sweep because it arrived in #38 while this was in progress, which is the argument for the check rather than against it. tools/check-dashes.js runs in CI on every PR. It builds its offender table from code points rather than literals, because a checker containing the characters it bans reports itself, and the fix somebody reaches for at that point is an exemption for the checker. schema/ is exempt, deliberately: those files are byte-for-byte mirrors of trace-spec enforced by schema-parity, so a dash there is an upstream fix followed by a re-sync, and failing CI here for something CI here cannot act on only teaches people to ignore it. The same workflow now runs marketplace/marketplace.test.js, which covers the escaping and URL-scheme guards added in #31 after the catalog was found to be rendered from remote JSON without them. It was never wired to a workflow, so it has been passing or failing unobserved since. schema/trace-v0.2.json is re-synced from trace-spec rather than hand-edited, because schema-parity is a byte comparison and a partially-updated mirror is not a mirror. That pulls in more than the two descriptions: the published copy had already drifted, and the scheduled parity check has been RED since 2026-08-24. Anything fetching the canonical $id URL to validate a Trust Record has since been validating against a schema missing $defs/canonicalizableValue, the safe-integer maxima on iat, and the references block. The re-sync fixes that too. Upstream: agentrust-io/trace-spec#228. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014NL8o3PXq6kfs2SdmBv6ak * fix(schema): re-sync the two revocation mirrors as well The parity job guards three published schemas as a set, and all three had drifted. Cleaning only trace-v0.2.json left the job red for the other two, which is both a broken check and a half-fix: the revocation schemas are published at the same $id pattern and fetched by the same verifiers. The drift is three "maximum": 9007199254740991 constraints, the safe-integer bounds upstream added alongside the ones in trace-v0.2.json. Until now the published copies accepted revocation records carrying integers no JSON parser round-trips reliably. No dashes in either file, which is why the original sweep did not reach them. Re-synced from upstream rather than hand-patched, for the reason in the previous commit: parity is a byte comparison and a partially-updated mirror is not a mirror. Both $id values verified unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014NL8o3PXq6kfs2SdmBv6ak --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Thanks for adding us 🙏 just a quick fix to align the company name