Skip to content

Publish Discovery and Evidence problem identifiers and the Registry Record context and profile - #2

Merged
jeremi merged 7 commits into
mainfrom
dx/problem-pages
Sep 6, 2026
Merged

Publish Discovery and Evidence problem identifiers and the Registry Record context and profile#2
jeremi merged 7 commits into
mainfrom
dx/problem-pages

Conversation

@jeremi

@jeremi jeremi commented Sep 6, 2026

Copy link
Copy Markdown
Member

Publishes the Registry Discovery and Evidence problem identifiers (the site served only Relay's before), the Registry Record context and profile, and the context and profile identifier kinds, with a build-time check and a post-deployment smoke that every catalog problem URI resolves to a route. Six signed-off commits from the BReg and Evidence developer-experience review; registry-stack PR #850 carries the rest of that work.

Verification on the branch head: npm test exits 0 (node --test: 16 tests, 0 failed; npm run check; npm run check:problem-routes reports 40 catalog problem identifiers resolving to built routes and 10 artifact identifiers resolving to an artifact, a page and an immutable copy).

Advance the pinned Registry Stack commit to 9200b8403415a988e0dc1a
06c73df2e018af8db9, the newest ancestor of registry-stack main whose
identifier catalog already carries complete registry-discovery and
registry-evidence problem entries while predating the unrelated
"profile" identifier kind introduced later in registry-stack history
(not yet supported by this import pipeline).

public/problems/ previously served only registry-relay identifiers
even though the catalog also defines Discovery and Evidence problem
types, so every documented Evidence or Discovery problem URI resolved
to nothing. No generator changes were needed: scripts/build.mjs
already renders problem pages generically per product, so
re-importing the newer catalog and rebuilding is enough to publish
registry-discovery/ (4 identifiers) and registry-evidence/
(10 identifiers) alongside the existing registry-relay/ identifiers.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
scripts/check.mjs already proves src/catalogs/problems.json is the
exact set of problem entries in the vendored upstream catalog, and
that public/ is byte-for-byte what scripts/build.mjs produces from the
catalogs, so the guarantee already existed but only as the composition
of two indirect proofs.

Add scripts/check-problem-routes.mjs, which reads
src/upstream/catalog.v1.json directly and asserts, for every
kind: "problem" entry, that both its HTML and JSON route exist under
public/ and describe the same code and HTTP statuses. It needs no live
network access and no other check to have already run first. Wire it
into npm test so CI runs it on every pull request and on the deploy
workflow's pre-deploy build check.

The vendored catalog it reads is refreshed with
`npm run import:catalog -- <path> --source-revision <full-commit>`,
documented alongside the new check in the README.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
The existing smoke-live.yml and smoke:live only check a small
representative sample of identifiers, not every problem URI the
catalog defines.

Add scripts/smoke-problem-routes.mjs, which reads every active
kind: "problem" entry from the same vendored src/upstream/catalog.v1.json
scripts/check-problem-routes.mjs uses, fetches each one's canonical URI,
and fails if any response is not HTTP 200. Wire it as a step in
deploy-cloudflare-workers.yml right after the Cloudflare deploy step, so
a deployment that leaves a documented problem URI unreachable fails
loudly instead of surfacing later in the weekly representative smoke.

IDENTIFIER_BASE_URL overrides the target host the same way it does for
smoke-live.mjs, so this can run locally against a built public/ for
verification before it ever runs against the live host.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Registry Stack publishes a Registry Record v1 JSON-LD context and a
Registry Record v1 response profile. The importer refused the profile
kind outright, and the build gave a context whose URI carries no file
extension the same path for its artifact and its page, so neither kind
could reach the site.

Both kinds now import into their own source catalog, and one artifact
writer serves every identifier that publishes bytes: the artifact at the
canonical URI, the page beside it, and the immutable copy under the
digest path. Each published path names its own content type, so a
Markdown profile and a JSON-LD context are no longer served as JSON.
The route check derives those three routes from the vendored catalog and
fails when one is missing.

Pages for artifact identifiers no longer default their product to
Registry Relay, which linked Relay documentation from identifiers Relay
does not own.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Advance the pinned Registry Stack commit to
48e4b1cfd92d26eec42784ac2a626b787de3f396, the current main of that
repository, and re-import. The previous pin was chosen to predate the
"profile" identifier kind because the import pipeline refused it; the
pipeline now carries both artifact-backed kinds the BReg documentation
already links, so the pin no longer has to avoid them.

The catalog grows from 51 to 58 active identifiers: the JSON-LD context
"contexts/registry-record/v1" and the profile document
"profiles/registry-record/v1" appear for the first time, four schemas
join (three BReg authoring and runtime schemas plus the registry-record
schema), and one vocabulary joins. Every published record carries the
new source reference, so each identifier's page names the upstream file
it was generated from at the pinned commit.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
Cloudflare Pages combines every rule matching a path and joins repeated
header values, so an exact _headers rule for a schema path already
covered by the /schemas/*.json wildcard produced doubled headers (e.g.
Access-Control-Allow-Origin: *, *). Skip the exact rule when a static
rule already sets the same content type and cache value for that path.

Added scripts/build-headers.test.mjs, which builds the site and asserts
no path resolves to a duplicated header name across matching _headers
rules; it fails against the prior build.mjs and passes with the fix.
Ran npm test (16/16 passing) and npm run build, then verified the
regenerated public/_headers no longer emits an exact rule for schema
paths covered by the wildcard (e.g.
/schemas/breg/authoring/registry-module.v1alpha1.schema.json).

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 6, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-06T05:52:39.896309Z d5a4279 New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d4c28ff6e9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread scripts/build.mjs Outdated
The digest path of a published artifact serves the same bytes as its
canonical URI, and the README requires both to carry the content type the
kind defines. The immutable rule read the type from the file extension
instead, so every schema copy under artifacts/sha256/ was served as
application/json while its canonical URI served application/schema+json.
Derive the immutable rule from the kind, drop the extension table, and
pin the invariant with a test that compares both rules for every entry.

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>
@jeremi
jeremi merged commit 01acc15 into main Sep 6, 2026
1 check passed
@jeremi
jeremi deleted the dx/problem-pages branch September 6, 2026 05:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant