Point your GitHub client (e.g. Octokit) baseUrl/baseUrl at https://gh.sandboxapis.dev — a bare env-var swap. Paths, JSON, and headers mirror api.github.com.
Coverage badge
Deep409/650 · 63%
The share of read rows with a final answer — served and verified, a deviation, retired upstream, or a reviewed empty/refusal. Computed in the coverage manifest, copied here.
gh.sandboxapis.devServed & verified
327 / 50%
Answering with real universe data, each response checked against GitHub's published spec by the conformance suite on this build.
The full read API
650
Every read surface GitHub publishes, deferred long tail included, minus the rows excluded by policy (1). Writes are out of scope: this universe is read-only.
Not served yet
313
Each returns an explicit, provider-shaped coverage error naming the gap — never invented data. 10 endpoints were retired by GitHub itself and are served only on snapshots pinned before that date — not a gap on our side.
01 / The swap
No SDK of ours, no shim, no recorded fixtures. The same client library you already use, one environment variable different.
curl https://gh.sandboxapis.dev/repos/olympus-labs/parthenonVerified drop-in clients
@octokit/rest22.0.1gh2.98.0renovate44.39.2The versions the conformance suite drives against this host on every build — pinned in coverage/client-pins.yaml, and watched weekly for upstream releases, because a client library moving without us is how a shipped integration breaks silently.
02 / Coverage by family
All 651 rows the coverage manifest carries for GitHub, deferred long tail included and nothing capped. Open a family, or filter by path to find the exact endpoint your client calls.
Status — what a conformance test found
Mode — what kind of answer a row gets
A row with no mode shown has not been judged yet. Modes are the manifest's own words, from coverage/MODES.yaml; every empty and refuse carries a written reason and a review date before it counts as final.
Held — buildable, deliberately not built yet
held is a label, not a mode and not a status. A held row is one somebody looked at, judged buildable, and left with the blocker named — so it is not covered, counts against the ratio above exactly like any other unbuilt row, and still answers the coverage 404. It buys nothing; it only tells you why.
Badge — where Deep starts
REST + GraphQL + git rows that are not `excluded`. Write operations are NOT rows (DECISIONS 2026-09-01 decision 9): they are counted in meta.write_operations and never enter this ratio.
651 read surfaces in 51 families
reader.refCatalog("github.runner-images-github-owned"); every row carries source: github and none of them is on the partner catalogue. licence: FACTUAL — the ids are operating-system distribution names and versions ("ubuntu-20.04" on platform "linux-x64" in actions-hosted-runner-curated-image), which carry no authorship. Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
reader.refCatalog("github.runner-images-partner") - the one catalogue in this domain with a theme leg, since source: partner names third-party vendors. licence: NO GRANT NEEDED — source: "partner" names third-party vendors, which is exactly the objection the /vendors ruling met, and it settled it by making the catalogue FICTIONAL. No vendor's data is copied, so nothing has to be licensed. Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
reader.refCatalog("github.runner-machine-sizes") in ord order (smallest first, which key order would reverse). licence: FACTUAL — the response is hardware numbers ({id: "8-core", cpu_cores, memory_gb, storage_gb} in actions-hosted-runner-machine-spec), which carry no authorship. Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
reader.refCatalog("github.runner-platforms"); every platform an image names is asserted to be one this list offers. licence: FACTUAL — the response is an enumeration of operating-system/architecture identifiers ("linux-x64", "win-x64" in the vendored description's own example), which carries no authorship. Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; served as `organization-actions-secret`, so `visibility` is published and `selected_repositories_url` only on a `selected` row - a link on an `all` row would advertise a route that answers 409. NO `value` MEMBER IS SERVED AND NONE EXISTS: `actions-secret` declares a name and two dates, `ci_binding.value` is NULL on every masked row, and conformance asserts the property is absent from every served secret rather than trusting the schema, which sets no `additionalProperties: false`
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; a name the list published, never a name recomputed from the theme's pool. A name this organization does not hold is GitHub's own 404
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the repositories the secret actually reaches - `all` reaches every one, `private` the private ones, `selected` the named ones. The vendored operation declares NO 409 on the secret form (only the variable form does), so this answers the 200 whatever the visibility, and conformance fetches every repository it names to prove the link resolves
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the scope's own 32 X25519 public-key bytes, base64-encoded, and its monotonic `key_id`. THE PUBLIC HALF IS REAL AND THERE IS NO PRIVATE HALF - this universe accepts no writes, so nothing is ever encrypted to these bytes; conformance base64-decodes them and asserts the length is 32 rather than accepting any string
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; `organization-actions-variable`, whose `value` IS declared and is READ from the artifact row canon's `value_source` names - the telemetry exporter's endpoint and its protocol - so the setting and the thing it configures cannot drift apart
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; a name the list published. A name this organization does not hold is GitHub's own 404
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The vendored operation declares a 200 AND a body-less 409 - "Response when the visibility of the variable is not set to `selected`" - and BOTH branches have a row in this universe, which is the vendored document specifying what the organization has to look like. This one answers the 200: the organization's OTLP protocol variable is `selected` to the repository whose collector agent is configured for that wire format. The `agents` twin answers the 409
SERVED 2026-09-09: the SIXTH download redirect, on the founder-ruled 2026-09-02 pattern — the documented 302 to the service host, and the bytes behind it. reader.artifactContent(artifactId) (packages/artifact/src/reader.ts:2825) is the artifact's canonical content, packed by buildZip (packages/renderer-github/src/archive.ts:181) under ArtifactRow.path with the run's completion epoch as the mtime, so the archive is byte-identical on every request. `archive_download_url` on every artifact object has pointed here since Phase C, and conformance follows THAT url. `zip` is the only archive_format GitHub accepts; anything else is its 404. Answers the hello-15 generation gap rather than redirecting to an empty zip
every workflow run in this universe has reached a terminal conclusion, so no concurrency group is active; the check goes red the day canon grows an in-flight run
hello-13 JobLog carries this job's log text; the documented 302 is simulated in-app (founder ruling 2026-09-02) — the Location names a signed route on the service host that serves those exact bytes as text/plain
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the ORGANIZATION secrets this repository can see, and the visibility rule that decides which lives in `reader.orgBindingsVisibleToRepo` rather than in four renderers. Served as the PLAIN `actions-secret`, not the organization form - the vendored operation names that component here - so no `visibility` is published on this surface even though the rows are the organization's
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the organization variables this repository can see, through the same reader rule as its secret twin
no workflow run in this universe ever waited for an approval — all 398 `workflow_run` rows carry a terminal `conclusion` and the table has no pending state; GitHub's own answer for a run with no approval history is `[]` at 200. RULED by the founder 2026-09-12
hello-13 JobLog carries every job's log text, so the attempt's zip is a container around canon; the documented 302 is simulated in-app (founder ruling 2026-09-02) and an attempt number this run never had stays a plain 404
the per-run twin of the repository concurrency-group list, held to the same fact: every workflow run has reached a terminal conclusion, so none holds a concurrency group
hello-13 JobLog carries every job's log text, so the run's zip is a container around canon, one member per job; the documented 302 is simulated in-app (founder ruling 2026-09-02)
no workflow run in this universe ever waited for an approval — all 398 `workflow_run` rows carry a terminal `conclusion` and the table has no pending state; GitHub's own answer for a run with no approval history is `[]` at 200. RULED by the founder 2026-09-12
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the repository's OWN secrets. Two of them are backed by a `person_credential` this organization really issued - the registry pull token and the integration-suite token, whose two dates are the ROTATION PAIR canon records - so their instants are facts rather than plausible numbers
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; a name the list published
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `actions` family is canon's `pipeline` audience; the repository scope's own 32 public-key bytes
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The repository's own published settings: its default branch and the tree path the orb document really sits at, both READ from the rows they name so a client that follows either finds the thing it points at
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. A name the list published
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. One scope per name `deployment.environment` actually carries, dated to the FIRST deployment to it. The environment has to resolve through the same derivation `/environments` publishes, so one named there is one this row answers for and one that is not is the ordinary 404
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. A name the list published
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The environment scope's own 32 public-key bytes
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The environment's own name, published - and READ from the scope's `environment` column, which is a name copied out of the deployments rather than authored, so the two surfaces cannot name the environment two different things
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. A name the list published
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity HostedRunner
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
generate — new canon entity ActionsCache
refuse — the name half of the concurrency-group pair: with no group active, GitHub answers 404 for the group that does not exist
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity ActionsPolicy
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
generate — new canon entity Runner
the org list is the one org this universe carries
SERVED 2026-09-09 (hello-16): the pending org memberships WITH `failed_epoch` — reader.listMemberships("org", org) (reader.ts:2961). The failure is the clock's: `failed_epoch` IS `expires_epoch`, so nothing had to be invented to make an invitation fail and `failed_at` can never precede the offer — conformance asserts both, and that every row carries the reason the host printed
SERVED 2026-09-09 (hello-16): the pending org memberships WITHOUT `failed_epoch` — reader.listMemberships("org", org) (reader.ts:2961). An invitation is a membership that has not happened yet (`state: pending`, which is GitHub's own word for it on `team-membership`), so one column discriminates this surface from /orgs/{org}/failed_invitations and conformance asserts nothing appears on both. `login` and `email` are the pair GitHub types nullable on BOTH members because an invitation names a person or an address; canon sets exactly one, and the entry asserts the biconditional
SERVED 2026-09-09 (hello-16): the team a pending membership is scoped to — reader.listMemberships over org, team and repository scope (reader.ts:2961). A team-scoped invitation names its team and an organization-scoped one grants none, which is what `team_count` on the invitation object already says; conformance follows `invitation_teams_url` from every invitation and asserts the count and the list agree. An invitation id nobody holds is GitHub's own 404, not an empty list
membership check over team_member
SERVED 2026-09-09 (hello-16): reader.membershipFor("org", org, person) (packages/artifact/src/reader.ts:2977), validated against the vendored `org-membership`. Canon's five role keys collapse to GitHub's two — `owner` and `admin` both report `admin`, which is what GitHub itself reports for an organization owner — and `state` is canon's own word for the same fact. `permissions` is OMITTED rather than invented: its one member is `can_create_repository` and canon records no such grant. A login the organization does not carry is GitHub's own 404, which is what /orgs/{org}/members/{username} already answers for it
NOBODY IN THIS UNIVERSE IS OUTSIDE THE ORGANIZATION. The 2026-09-01 classification guessed the opposite — 'canon already marks outside contributors (Person.member = false)' — and no row satisfies it: every person carries member = 1, so `orgMembers()` and `listPeople()` return the same set and the outside-collaborator list is truthfully empty. It is also the fact the collaborator endpoints already publish, since `/repos/{o}/{r}/collaborators?affiliation=outside` answers `[]` for the same reason. Falsifiable: the day the generator gives the org a contributor with member = 0, this row goes red rather than hiding them. RULED by the founder 2026-09-09
SERVED 2026-09-09 (hello-16): reader.listMemberships("org", org) (reader.ts:2961), narrowed to the active rows whose `publicized` bit is set. `publicized` is the ONE drawn preference in the access domain (the `disableSsh` exception) and is roughly half the roster, so this is neither the member list under a second name nor an empty one — the conformance entry asserts both bounds against /orgs/{org}/members and that every public login is a member. Paginated with GitHub's Link header, walked to the last page
SERVED 2026-09-09 (hello-16): reader.membershipFor("org", org, person) (reader.ts:2977). GitHub answers this operation with a STATUS and no body — its documented 204 when the membership is public and its 404 when it is not — so the conformance entry asserts the three-way outcome (public 204, member-who-does-not-publicise 404, stranger 404) rather than a schema
immutable releases are not enabled on olympus-labs/parthenon — its three `release` rows carry no immutability marker and canon has no repository release-immutability setting; GitHub's own answer for a repository where immutable releases are not enabled is 404 with no body (the spec's own 404 description), and the ORGANIZATION's selected-repository list is therefore an empty `{total_count: 0, repositories: []}` at 200. RULED by the founder 2026-09-12
SERVED 2026-09-09 (hello-16): reader.membershipsForPerson(athena) (reader.ts:2969) narrowed to org scope — athena is the caller GET /user already reports, and conformance asserts the two agree. `?state=` is really honored: the pending page is empty rather than the active row, and a value outside the enum is an explicit 400 instead of an unfiltered 200 (DECISIONS 2026-08-21)
SERVED 2026-09-09 (hello-16): the same membership addressed by organization — reader.membershipFor("org", org, athena) (reader.ts:2977), byte-identical to the row the listing serves. An organization this host does not serve is GitHub's own 404
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.orgWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. The account-wide feed, a DIFFERENT row from PagerDuty's account-scoped subscription - which is why canon's filter vocabulary carries both scopes and why listWebhookSubscriptions() is scoped to the alerting kinds in the same PR as the widening.
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.orgWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. `org-hook` is a DIFFERENT schema from `hook` and the differences are honoured: it declares neither test_url nor last_response, so neither is emitted even though the row carries the delivery columns.
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.orgWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. The same `webhook-config` the repository pair serves, off the organization's own row - and conformance asserts the two scopes advertise DIFFERENT delivery URLs, because canon picks the receiver by scope.
no artifact in this universe is attested — all 392 `artifact` rows are plain workflow-run uploads with no provenance bundle and none of the three workflows (`ci`, `lint`, `release`) runs an attestation step; GitHub's own answer for a subject digest with no attestations is `{attestations: []}` at 200 (the spec's 200 has NO required member). The operation also declares a 404 and the ORCHESTRATOR RULED the 200: a digest is a content address rather than a resource id, so asking about an artifact nobody signed is a well-formed question whose answer is "none". RULED by the founder 2026-09-12
no artifact in this universe is attested — all 392 `artifact` rows are plain workflow-run uploads with no provenance bundle and none of the three workflows (`ci`, `lint`, `release`) runs an attestation step; this operation's own 200 is a bare array of the repositories that have attestations, so its empty answer is `[]` rather than the `{attestations: []}` envelope the by-digest reads carry. RULED by the founder 2026-09-12
nobody is blocked in this universe: the org's cast is its own employees and the outside contributors it works with, and a block only exists because someone created it
STALE REASON ("new canon entity IssueType"): there is no entity to build. GitHub's issue type is a NAME plus a nullable description, and the set this organization offers IS `select distinct kind from issue` — a closed canon vocabulary (bug, feature-request, incident, question, task) present in every generation. Conformance cross-checks the published list against every issue's kind in BOTH directions, so a type nothing can be and a kind nothing advertises are each red
SERVED 2026-09-09 (hello-16): reader.listMembershipRoles() (reader.ts:2985) in GitHub's `{total_count, roles}` envelope. Five catalog ROWS rather than an enum rendered at request time: the vendored `organization-role` REQUIRES a `permissions` array, and a permission list composed inside a renderer is a fact invented at serving time. `permissions` is canon's closed `scope:level` vocabulary, which the schema types `array<string>` with no enum; `base_role` is GitHub's own enum and is read off the same list's repository rung, so the two cannot disagree — conformance recomputes it
SERVED 2026-09-09 (hello-16): the same catalog row by id — reader.listMembershipRoles() (reader.ts:2985) addressed by githubId(MembershipRoleRow.id), byte-identical to the row the catalog serves. An id the catalog does not carry is GitHub's own 404
no team holds a custom organization role: the access domain attaches a role to a PERSON on their own membership (reader.listMemberships, packages/artifact/src/reader.ts:2961) and to nothing else, which is the same statement `user-role-assignment.assignment: direct` and its empty `inherited_from` make from the other side on the sibling row served 2026-09-09. SERVED 2026-09-10 as GitHub's empty array, behind the hello-16 generation gate and behind the role guard — an id the catalog does not carry is still GitHub's own 404 — RULED EMPTY by the founder 2026-09-10
SERVED 2026-09-09 (hello-16): the active org memberships whose role is this catalog row's key — reader.listMemberships("org", org) (reader.ts:2961). Conformance asserts the holders of all five roles TOGETHER are exactly the member list, so the catalog partitions the organization rather than covering part of it. `maintainer` and `reader` have no holders at org scope — maintainer is repository-scoped here and this universe has no outside contributor — which is a fact about the organization, not a gap
SERVED 2026-09-12 (hello-17): reader.credentialRequests() behind reader.hasCallerCredentials(), validated against `organization-programmatic-access-grant-request`. THE hello-16 ASK IS ANSWERED: that wave said canon modelled no pending token request, and hello-17 adds "pending" to CredentialState with a request_reason column (decisions/2026-09-11-0151) — the org's newest engineer asks for the scope their first blocked act needed, at the instant of that act. THE ROWS ARE REACHABLE THROUGH ONE ACCESSOR AND NOWHERE ELSE: credentialScope() excludes `pending` from credentialsForPerson and listCredentials, so /orgs/{org}/personal-access-tokens cannot serve a request as a grant by forgetting a filter, and conformance asserts the two ledgers share no token_id and no id. `token_expired: false`, `token_expires_at: null` and `token_last_used_at: null` are not defaults — the generator throws if a pending row carries an expiry, an end or a use, because a request has never been a token. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-12 (hello-17): what the requested token would reach. `repository_selection` is `all` for the reason the granted twin gives — canon's personal-token acts as its owner everywhere its owner can act and carries no scope_ref, and every repository here belongs to the organization — so the answer is the organization's repositories through the same orgReposResponse /orgs/{org}/personal-access-tokens/{pat_id}/repositories uses. One request, one answer, and the two routes cannot describe different repositories; conformance asserts they agree and that an unminted pat_request_id is a 404. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-09 (hello-16): reader.listCredentials("personal-token") (reader.ts:3026), validated against `organization-programmatic-access-grant`. Every repository in this universe belongs to the organization, so every personal token that reaches a repository reaches an organization resource and no scope filter had to be invented to decide which tokens count. Canon's provider-neutral `TokenScope`s are mapped ONCE, in packages/renderer-github/src/render-credentials.ts, into GitHub's fine-grained `{organization, repository, other}` permission spelling (the WorkflowStateKey precedent), and the table is TOTAL — an unmapped scope throws rather than being silently dropped. METADATA ONLY: a token's value is shown once at creation by the provider we replicate reads of, so canon holds none (the PagerDuty routing-key rule, DECISIONS 2026-09-03) and conformance asserts no served byte is shaped like one
SERVED 2026-09-09 (hello-16): what a granted token reaches. `repository_selection` is `all` on every grant — a personal token acts as its owner wherever its owner can act and carries no `scope_ref` — so the answer is the organization's repositories through the same shaper /orgs/{org}/repos uses, and conformance asserts the two lists are identical. `pat_id` is the GRANT's own id and not the token's: the two are distinct numbers on one object, and the entry asserts the token id does NOT address it
no ruleset exists at either scope — canon's only ref-protection rows (`protected_ref`, 2) are scoped to `namespace-001`, a container GitHub has no counterpart for, and repo-01 carries an empty `namespace` column; classic branch protection on `main` (branch.protected=1, served by render-protection.ts) is GitHub's OTHER mechanism and does not imply a ruleset, so GitHub's own answer for a scope with no rulesets is `[]` at 200. RULED by the founder 2026-09-12
no ruleset exists at either scope — canon's only ref-protection rows (`protected_ref`, 2) are scoped to `namespace-001`, a container GitHub has no counterpart for, and repo-01 carries an empty `namespace` column; classic branch protection on `main` (branch.protected=1, served by render-protection.ts) is GitHub's OTHER mechanism and does not imply a ruleset, so GitHub's own answer for a scope with no rulesets is `[]` at 200. RULED by the founder 2026-09-12
no security managers are configured: `membership` records what each membership GRANTS and MEMBERSHIP_PERMISSIONS (packages/canon/src/access.ts) has no security rung at all — org, team, repo and namespace, five levels each — so naming a team here would hand it a grant nothing in this universe made. SERVED 2026-09-10 as GitHub's empty array, behind the hello-16 generation gate; falsifiable the day canon confers the authority — RULED EMPTY by the founder 2026-09-10
generate — new canon entity GitHubApp
generate — new canon entity RepoSettings
generate — new canon entity Attestation
generate — new canon entity Attestation
generate — new canon entity Attestation
refuse — the id half of the org block pair: with nobody blocked, GitHub answers 404 to the per-user block check
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity ApiRequestStat
generate — new canon entity IssueField
generate — new canon entity CustomProperty
generate — new canon entity CustomProperty
generate — new canon entity CustomProperty
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity NetworkConfiguration
generate — new canon entity NetworkConfiguration
generate — new canon entity NetworkConfiguration
generate — new canon entity Webhook
generate — new canon entity Webhook
SERVED 2026-09-12 (hello-17 `repoOwnership`): {errors: []} for a file that EXISTS and PARSES. hello-17 puts .github/CODEOWNERS in the tree (decisions/2026-09-11-2256 — one line per subsystem naming the team the service catalogue says is paged for it, at GitHub's own canonical location, which is also the cheapest placement in a content-addressed tree). THE FILE IS PARSED, NOT ASSUMED: packages/renderer-github/src/render-codeowners.ts reads the blob and checks the two things this artifact can ground — an owner token that is not @login, @org/team or an address is GitHub's `Invalid owner`, and one that names no team, login or address this host carries is its `Unknown owner` — and emits nothing else, because inventing GitHub's wording for a rule we cannot evaluate would be a placeholder wearing an error's clothes. A hard-coded empty array would assert the file parses without ever opening it, so conformance re-reads the blob, asserts it carries rules, resolves every @org/team against /orgs/{org}/teams and asserts every owned path prefix has files under it. On an artifact whose tree carries no CODEOWNERS the row answers the hello-17 generation gap rather than GitHub's 404, because a repository without the file and a universe that predates it deserve different sentences (noRepoLicense's argument one generation on)
no repository in this universe is a fork and none has been forked: the org owns every repo and there is no account outside it to fork into
SERVED 2026-09-12 (hello-17 `repoOwnership`): the content-file object for tools/README.md, read through the same fileAt/shapeContentFile path /repos/{o}/{r}/contents/{path} uses — one blob, one answer, whichever route asks, which conformance asserts by comparing the two objects. hello-17 puts a README inside a directory for the first time (decisions/2026-09-11-2256): tools/ holds probe/ and report/, both real programs with real source in the tree, so every sentence in the document names something a caller can open — which is the whole reason a folder README is safe to write (invariant #5), and conformance checks it. A DIRECTORY WITH NO README IS GITHUB'S OWN 404 and carries no coverage header: /readme/src is a fact about that directory rather than a gap, and conformance asserts both. An artifact whose tree carries neither ownership file answers the hello-17 generation gap instead, because on it NO directory has a README and the row is unanswerable rather than negative
the file model already carries the tree, so the archive is a ustar+gzip container around the same blobs the contents endpoints and the git transport serve; the documented 302 is simulated in-app (founder ruling 2026-09-02) and the Location names the resolved commit sha
STALE REASON ("new canon entity RepoTopic"): there is no entity to build. `repo.topics_json` holds the list and `shapeRepo` has published it inside the repository object since GitHub coverage began; `topic`'s one required member is `names`, and conformance asserts the standalone list and the embedded one agree
the zip half of the tarball row: the same tree, the same blobs, deflated into a zip container; the documented 302 is simulated in-app (founder ruling 2026-09-02)
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.repoWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. The repository object has advertised `hooks_url` since wave A and it finally resolves; conformance walks the page and asserts it.
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.repoWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. Byte-identical to the object the list publishes - one shaper - and the ORGANIZATION's hook id 404s here, which is the scope separation reader.repoWebhooks() enforces one layer down.
SERVED 2026-09-12 (hello-18 serving wave W-c): off `webhook_subscription`'s hello-18 git-host scopes (features.webhookFilters) through reader.repoWebhooks(), gated on hasWebhookFilters() so hello-17 and all eighty-one -g8..-g11 pins name the generation instead of claiming this organization configured no webhook. Canon stores NEUTRAL event names and this renderer spells them GitHub's way - ref.pushed->push, change.opened/change.merged->pull_request, issue.opened/issue.closed->issues, build.completed->check_run - many-to-one because GitHub subscribes by event NAME and puts the verb in the payload's `action`. `config` is the same object the hook embeds: url is the delivery_url column, insecure_ssl is READ OFF that URL's scheme, secret is GitHub's own eight-asterisk redaction (the renderer-circleci signing_secret precedent - canon stores no secret because every host redacts it), and content_type is json because these receivers are the org's own ReceiverSlots, into which PagerDuty and CircleCI already deliver JSON and can deliver nothing else.
no artifact in this universe is attested — all 392 `artifact` rows are plain workflow-run uploads with no provenance bundle and none of the three workflows (`ci`, `lint`, `release`) runs an attestation step; GitHub's own answer for a subject digest with no attestations is `{attestations: []}` at 200 (the spec's 200 has NO required member). The operation also declares a 404 and the ORCHESTRATOR RULED the 200: a digest is a content address rather than a resource id, so asking about an artifact nobody signed is a well-formed question whose answer is "none". RULED by the founder 2026-09-12
STALE REASON ("new canon entity IssueType"): there is no entity to build. GitHub's issue type is a NAME plus a nullable description, and the set this organization offers IS `select distinct kind from issue` — a closed canon vocabulary (bug, feature-request, incident, question, task) present in every generation. Conformance cross-checks the published list against every issue's kind in BOTH directions, so a type nothing can be and a kind nothing advertises are each red
no ruleset exists at either scope — canon's only ref-protection rows (`protected_ref`, 2) are scoped to `namespace-001`, a container GitHub has no counterpart for, and repo-01 carries an empty `namespace` column; classic branch protection on `main` (branch.protected=1, served by render-protection.ts) is GitHub's OTHER mechanism and does not imply a ruleset, so GitHub's own answer for a scope with no rulesets is `[]` at 200. RULED by the founder 2026-09-12
no ruleset exists at either scope — canon's only ref-protection rows (`protected_ref`, 2) are scoped to `namespace-001`, a container GitHub has no counterpart for, and repo-01 carries an empty `namespace` column; classic branch protection on `main` (branch.protected=1, served by render-protection.ts) is GitHub's OTHER mechanism and does not imply a ruleset, so GitHub's own answer for a scope with no rulesets is `[]` at 200. RULED by the founder 2026-09-12
no ruleset exists at either scope — canon's only ref-protection rows (`protected_ref`, 2) are scoped to `namespace-001`, a container GitHub has no counterpart for, and repo-01 carries an empty `namespace` column; classic branch protection on `main` (branch.protected=1, served by render-protection.ts) is GitHub's OTHER mechanism and does not imply a ruleset, so GitHub's own answer for a scope with no rulesets is `[]` at 200. RULED by the founder 2026-09-12
refuse — no GitHub security product is enabled on olympus-labs/parthenon — canon carries no security-finding entity and no code-security configuration, and the org's only repository is private; GitHub's own answer for a repository not enabled with vulnerability alerts is 404 with no body (the spec declares only 204 and 404 for this operation). RULED by the founder 2026-09-12
refuse — immutable releases are not enabled on olympus-labs/parthenon — its three `release` rows carry no immutability marker and canon has no repository release-immutability setting; GitHub's own answer for a repository where immutable releases are not enabled is 404 with no body (the spec's own 404 description). The renderer answers the `basic-error` body every GitHub 404 on this host carries, pointing at THIS operation's docs page: the spec declares no schema for the 404, and GitHub's API never sends a bodyless one. RULED by the founder 2026-09-12
generate — new canon entity SecurityConfiguration
refuse — no GitHub security product is enabled on olympus-labs/parthenon — canon carries no security-finding entity and no code-security configuration, and the org's only repository is private; GitHub's own answer for a repository not enabled with vulnerability alerts is 404 with no body (the spec declares only 204 and 404 for this operation). RULED by the founder 2026-09-12
generate — new canon entity Autolink
generate — new canon entity Autolink
generate — new canon entity CustomProperty
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity Ruleset
generate — new canon entity Webhook
generate — new canon entity Webhook
issue lists across the repo, org and authenticated persona
issue lists across the repo, org and authenticated persona
assignable users are the repo's collaborators; assignment is already on the issue
assignable users are the repo's collaborators; assignment is already on the issue
assignable users are the repo's collaborators; assignment is already on the issue
SERVED 2026-09-12 (hello-17): reader.linksFor(issue) narrowed to `blocks` rows whose TARGET is this issue — the prerequisites that finished before it started. hello-17 `issueLinks` (decisions/2026-09-11-0200) groups issues by (epic, sprint) — a team's slice of one storyline inside one iteration, the tightest grouping the tracker already holds — and writes ONE row per adjacent pair, whose kind the dates decide: `blocks` when the earlier issue closed strictly before the later one opened, `relates` otherwise. One row per pair is what makes "no link is its own inverse" true by construction rather than by a filter, and the direction is read off source/target. Conformance re-derives the canon rule on the wire: every blocker must be closed, and closed strictly before the asking issue was created. A pull-request number carries no dependency and is GitHub's 404, because canon links issues to issues
SERVED 2026-09-12 (hello-17): the same rows read from the other end — `blocks` links whose SOURCE is this issue. hello-17 `issueLinks` (decisions/2026-09-11-0200) groups issues by (epic, sprint) — a team's slice of one storyline inside one iteration, the tightest grouping the tracker already holds — and writes ONE row per adjacent pair, whose kind the dates decide: `blocks` when the earlier issue closed strictly before the later one opened, `relates` otherwise. One row per pair is what makes "no link is its own inverse" true by construction rather than by a filter, and the direction is read off source/target. Conformance asserts the pair agrees: the issue a blocked_by row names must report blocking the issue that named it, which is the one-row-per-pair claim checked from both sides
olympus-labs defines no issue field — canon's only custom-field table (`custom_field`, 8 rows) is scoped to `incident`, so no issue can carry a value for one; GitHub's own answer for an issue with no field values is `[]` at 200. RULED by the founder 2026-09-12
no issue in this universe carries a Copilot suggestion — canon's AI telemetry attributes work to commits (`ai_commit`, 110), pulls (`ai_pull`, 14) and sessions (`agent_session`, 72) and never to an issue; GitHub's own answer for an issue with no suggestions is `[]` at 200. RULED by the founder 2026-09-12
the timeline is the projection of comments, events, transitions and cross-references canon already carries
repo-wide issue comments over issue_comment (122-hit demand cluster, telemetry 2026-09-01)
issue events over the canonical event log and issue_transition
issue events over the canonical event log and issue_transition
labels over issue_label/label
issue lists across the repo, org and authenticated persona
generate — hello-17's `issueLinks` IS in canon and the two DEPENDENCY rows went `derive` on 2026-09-12 — but this operation asks for an issue's PARENT ISSUE, and canon has no issue-to-issue parentage. Its parentage runs issue.epic -> EpicId and epic.parent -> EpicId, and an Epic is its own entity in its own table, so an issue_link row of kind `parent` would point at an id that does not resolve in the table its column names: invariant #5 broken to fill an enum (decisions/2026-09-11-0200 checked this and ruled it out in as many words). THE ASK: issue-to-issue parentage, i.e. an epic that is also an issue, or a parent column on Issue. `parent` stays in the closed kind vocabulary so the column can say it the day canon can — a closed enum with an unused member is a vocabulary, a ROW with an invented relationship is a placeholder, and only the second is forbidden. Reported by the 2026-09-12 GitHub hello-17 serving wave
generate — hello-17's `issueLinks` IS in canon and the two DEPENDENCY rows went `derive` on 2026-09-12 — but sub-issues are the child half of issue-to-issue parentage, which canon does not have: parentage runs issue.epic -> EpicId, and an Epic is its own entity rather than an issue, so a sub-issue list would either be empty for every issue or would name epics through a column that says `issue`. THE ASK: issue-to-issue parentage. Ruling it `empty` would make a missing relation look like a fact about this organization's tracker, so it answers the honest coverage 404 instead. Reported by the 2026-09-12 GitHub hello-17 serving wave
the person table already answers the user list, the by-account-id read and the hovercard
the caller-scoped twin of the org block list, held to the same fact: nobody is blocked in this universe
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(athena, "email") (reader.ts:3016) — athena is the caller GET /user reports. `verified` is `state === active`, a column rather than a decision, so an address canon ever revokes stops being verified in the same edit. `visibility` is `private` on the primary address and null on every other, which is GitHub's own shape and agrees with what /users/{username} publishes: the `users.noreply` form, which is exactly what GitHub shows for a person whose addresses are private
SERVED 2026-09-12 (hello-17): reader.followers(athena) behind reader.hasSocialGraph(), shaped as `simple-user` through the same shaper /orgs/{org}/members uses, so a login here is a login that fetches. hello-17 `socialGraph` (decisions/2026-09-11-0200) derives the follow graph from the review log and draws nothing: a reviewer follows the author whose changes they read, and an author follows back ONLY a reviewer who APPROVED. Without that second, narrower rule the graph would be the symmetric closure of the review graph wearing two columns, so `followers` and `following` are genuinely different lists rather than one list served twice. The same person_follow table answers GitLab's /users/{id}/followers, which is the cross-host parity that provider's coverage reason already committed to. Conformance asserts this list and /users/athena/followers are the same list, and that every follower reports following the caller from the other end. An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-12 (hello-17): reader.following(athena) behind reader.hasSocialGraph(). hello-17 `socialGraph` (decisions/2026-09-11-0200) derives the follow graph from the review log and draws nothing: a reviewer follows the author whose changes they read, and an author follows back ONLY a reviewer who APPROVED. Without that second, narrower rule the graph would be the symmetric closure of the review graph wearing two columns, so `followers` and `following` are genuinely different lists rather than one list served twice. The same person_follow table answers GitLab's /users/{id}/followers, which is the cross-host parity that provider's coverage reason already committed to. Conformance asserts this list and /users/athena/following are the same list. An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-12 (hello-17): GitHub's 204 when the edge exists and its 404 when it does not, with no body either way. The 404 is a fact about the graph rather than a coverage miss, so it carries no coverage header; conformance drives a person the caller does follow, a member she does not, and a login nobody carries, so a green is not "this route says yes to everything". An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-12 (hello-17): reader.credentialsForPerson(athena, "gpg") behind reader.hasCallerCredentials(), validated against `gpg-key` and serving a real OpenPGP v4 packet whose long key id a client can recompute from the packet body. hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. ONE SHAPE FOR BOTH SURFACES: GitHub publishes `gpg-key` on the caller's list and on /users/{username}/gpg_keys, so this row reuses that shaper rather than writing a second one, and conformance asserts the two lists are byte-identical. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-12 (hello-17): the caller's own GPG key by its number, the same object the list publishes (conformance compares them field for field). hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-12 (hello-17): reader.credentialsForPerson(athena, "ssh-auth") behind reader.hasCallerCredentials(), validated against `key`. hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. A `key` SHAPER HAD TO BE WRITTEN FOR THIS ROW and deliberately did not exist before (decisions/2026-09-09-2008 recorded its absence: it would have been code for a response nothing could produce). Its four judgments are facts rather than defaults: `read_only: false` because canon's `ssh-auth` kind is the key its owner PUSHES with (the opposite reading `shapeDeployKey` makes for the opposite kind), `verified` off the state column exactly as shapeEmail reads it, `last_used` off canon's own epoch, and the material split by the same splitSshLine /users/{username}/keys uses — so the caller's view and the public view of one row cannot describe different bytes, which conformance asserts. `url` is this host's own by-id route, which answers. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-12 (hello-17): the caller's own key by its number, through the same reader.credentialsForPerson(athena, "ssh-auth") read the list uses, so the two are the SAME object field for field (conformance compares them). hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. A key id that belongs to somebody ELSE is GitHub's 404 here rather than that person's key, which is the whole difference between this operation and /users/{username}/keys — conformance walks hermes's ids and asserts every one 404s. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
NO ADDRESS IN THIS UNIVERSE IS PUBLIC, and that is a property of the credential canon rather than of who the caller is. packages/renderer-github/src/render-credentials.ts decides `visibility` from a COLUMN — "private" on the primary address and null on every other, which is GitHub's own shape — and /users/{username} publishes {login}@users.noreply.sandboxapis.dev from the other side, which is exactly what GitHub shows for a person whose addresses are private. The publicly-visible subset of anybody's addresses here is therefore genuinely empty, and GitHub's own answer for a caller who publishes none is [] at 200. SERVED 2026-09-12 (hello-17 GitHub wave) behind reader.hasCredentials() — the domain that decides the answer, not hello-17's caller half, because the claim holds on a hello-16 artifact exactly as it does on a hello-17 one. Falsifiable: the conformance entry's expectsEmpty fails the day canon gives an address a public visibility, and it also asserts the caller DOES hold addresses, so an empty page cannot go green on a universe with no email canon. This supersedes the 2026-09-09 ruling that the emptiness was "about the caller": hello-17 makes the caller the template's first persona structurally (decisions/2026-09-11-0151), and the visibility column was always the thing deciding this row. RULED empty by the hello-17 GitHub wave, 2026-09-12 — flagged for founder confirmation in the PR
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(athena, "social") (reader.ts:3016). Two providers, and the omissions are the design (packages/canon/src/credentials.ts): a row claiming a large proprietary network would carry a URL at somebody else's live service, naming an account that either does not exist or belongs to a real person. Both values resolve inside this organization's own domain, and conformance asserts the caller's list and /users/athena/social_accounts are byte-identical
SERVED 2026-09-12 (hello-17): reader.credentialsForPerson(athena, "ssh-signing") behind reader.hasCallerCredentials(), validated against `ssh-signing-key`. hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. A SIGNING KEY IS A SEPARATE GRANT FROM AN AUTHENTICATION KEY and canon models it as a separate CredentialKind for that reason, so this list and /user/keys must not share material — conformance asserts no key appears on both, because a replica that served one list from both would be asserting a grant nobody made. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
SERVED 2026-09-12 (hello-17): the caller's own signing key by its number, the same object the list publishes. hello-17 `callerCredentials` (decisions/2026-09-11-0151) replaces the credential pass's activity thresholds with a rule — THE FOUNDING MEMBER HOLDS ONE OF EVERY CREDENTIAL KIND THIS ORGANIZATION ACCEPTS — and makes the founding member the TEMPLATE'S FIRST PERSONA, which is the login VIEWER_LOGIN resolves to. That is what answers the hello-16 ask on this row ("the authenticated persona holds none of this kind"), and it answers it structurally rather than by moving a threshold until it happened to catch her. A hello-16 artifact answers the hello-17 generation gap and NOT hello-16's: it HAS the person_credential table — somebody else's keys are served off it — and none of these rows, which is why the gate is reader.hasCallerCredentials() and not reader.hasCredentials().
the person table already answers the user list, the by-account-id read and the hovercard
no artifact in this universe is attested — all 392 `artifact` rows are plain workflow-run uploads with no provenance bundle and none of the three workflows (`ci`, `lint`, `release`) runs an attestation step; GitHub's own answer for a subject digest with no attestations is `{attestations: []}` at 200 (the spec's 200 has NO required member). The operation also declares a 404 and the ORCHESTRATOR RULED the 200: a digest is a content address rather than a resource id, so asking about an artifact nobody signed is a well-formed question whose answer is "none". RULED by the founder 2026-09-12
SERVED 2026-09-12 (hello-17): anybody's followers, off the same reader.followers() read the caller's list uses. hello-17 `socialGraph` (decisions/2026-09-11-0200) derives the follow graph from the review log and draws nothing: a reviewer follows the author whose changes they read, and an author follows back ONLY a reviewer who APPROVED. Without that second, narrower rule the graph would be the symmetric closure of the review graph wearing two columns, so `followers` and `following` are genuinely different lists rather than one list served twice. The same person_follow table answers GitLab's /users/{id}/followers, which is the cross-host parity that provider's coverage reason already committed to. THE ORG LOGIN IS A VALID {username} AND FOLLOWS NOBODY — the rule /users/{org}/repos already follows, because a 404 here would say the account does not exist while /users/{org} says it does — and conformance asserts the organization account answers [] at 200. An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-12 (hello-17): anybody's following list, off reader.following(). hello-17 `socialGraph` (decisions/2026-09-11-0200) derives the follow graph from the review log and draws nothing: a reviewer follows the author whose changes they read, and an author follows back ONLY a reviewer who APPROVED. Without that second, narrower rule the graph would be the symmetric closure of the review graph wearing two columns, so `followers` and `following` are genuinely different lists rather than one list served twice. The same person_follow table answers GitLab's /users/{id}/followers, which is the cross-host parity that provider's coverage reason already committed to. Conformance walks the whole roster and checks every edge from both ends, which is what proves followers and following are two reads of one asymmetric table rather than one list served twice. An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-12 (hello-17): GitHub's 204/404 pair for any ordered pair of people. Nobody follows themselves — person_follow has no self-edge by construction — and conformance asserts the self-check is a 404, which is where that construction shows on the wire. An artifact that predates the domain answers the hello-17 generation gap: [] there would assert that nobody in THAT universe follows anybody, a statement its canon never made.
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(person, "gpg") (reader.ts:3016). `public_key` is a REAL OpenPGP v4 Ed25519 public-key packet body and `key_id` its long id, derived the way GnuPG derives them; the conformance entry parses the packet and checks the version byte, the algorithm and the id's shape rather than trusting the encoder. `raw_key` is null and `emails` is EMPTY for one reason: a transferable key needs a user id and a self-signature, both of which need a private half this universe never generated — so neither is served rather than being faked. `can_sign`/`can_certify` true and both encryption flags false are facts about Ed25519, checkable from the material
the person table already answers the user list, the by-account-id read and the hovercard
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(person, "ssh-auth") (reader.ts:3016) in GitHub's `key-simple` shape — the id and the material, with no comment, which is what the public listing carries. Conformance decodes the blob to a 51-byte ssh-ed25519 wire key and re-hashes it to the artifact's own fingerprint_sha256, so `ssh-keygen -lf` on the served line reproduces the served fingerprint. The organization login is a valid {username} here and answers with nothing, the rule /users/{org}/repos already follows
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(person, "social") (reader.ts:3016) — the same rows /user/social_accounts serves for the caller, which conformance asserts are byte-identical for the same person
SERVED 2026-09-09 (hello-16): reader.credentialsForPerson(person, "ssh-signing") (reader.ts:3016). A SEPARATE endpoint from /users/{username}/keys because it is a separate grant — a key authorised to write and a key trusted to attest authorship are different things — and conformance asserts no key appears on both lists, because serving one list from two addresses would assert a grant nobody made
refuse — the id half of the caller block pair: with nobody blocked, GitHub answers 404 to the per-user block check
the feed document is a set of URLs computed from the authenticated persona and the repos they can see
generate — new canon entity Notification
generate — new canon entity Notification
generate — new canon entity Notification
generate — new canon entity Notification
generate — new canon entity Star
generate — new canon entity RepoSubscription
generate — new canon entity RepoSubscription
generate — new canon entity Star
generate — new canon entity Star
generate — new canon entity RepoSubscription
generate — new canon entity Star
generate — new canon entity RepoSubscription
generate — new canon entity GitHubApp
generate — new canon entity Webhook
generate — new canon entity Webhook
generate — new canon entity Webhook
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
generate — new canon entity GitHubApp
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
refuse — the org is neither a GitHub Marketplace listing nor a purchaser, and GitHub answers 404 to marketplace reads for an account with no listing
generate — new canon entity GitHubApp
no repository in this universe carries a `.devcontainer`, so the repo's devcontainer list is truthfully empty
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
generate — new canon entity CodespacesConfig
generate — new canon entity CodespacesConfig
generate — new canon entity CodespacesConfig
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
refuse — no persona in this universe launches a Codespace: every Codespaces object exists only because a write created one, and this universe accepts no writes
derive — served on the pins frozen before the retirement; the live host refuses it (meta.retired_meaning)
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer. The identical ruling already governs every sibling under this prefix (see `github|rest|GET|/enterprises/{enterprise}/teams`, reviewed 2026-09-01); serving a Copilot report here would require minting the enterprise those fifteen rows deny. RULED by the founder 2026-09-09
generate — new canon entity CopilotPolicy
generate — new canon entity CopilotPolicy
generate — new canon entity CopilotPolicy
generate — new canon entity CopilotPolicy
SERVED 2026-09-09 (hello-16): the pending TEAM memberships — reader.listMemberships("team", team) (reader.ts:2961), rendered in the `organization-invitation` shape the operation declares. The invitee is somebody this organization already knows, so `login` is set and `email` is null, and the same row answers /orgs/{org}/teams/{team_slug}/memberships/{username} with `state: pending`
SERVED 2026-09-09 (hello-16): reader.membershipFor("team", team, person) (reader.ts:2977), validated against `team-membership`. `state: pending` is real on this universe — one person is on a team's roster by invitation and not yet by membership — and /orgs/{org}/teams/{team_slug}/invitations serves that same row from the other side
teams, their repo grants and the caller's own team list, over team/team_member
the org's teams are flat — four discipline teams, none nested under another — so a team's child-team list is truthfully empty
teams, their repo grants and the caller's own team list, over team/team_member
SERVED 2026-09-09 (hello-16): the same list through the legacy team id — teamByLegacyId plus reader.listMemberships("team", team) (reader.ts:2961). Conformance asserts the legacy and slug forms are byte-identical
team members over team_member, addressed by legacy team id
team members over team_member, addressed by legacy team id
SERVED 2026-09-09 (hello-16): the same row through the legacy team id — teamByLegacyId (render-access.ts) plus reader.membershipFor("team", team, person) (reader.ts:2977). `url` is the address the caller used, and conformance asserts the legacy and slug forms agree about role and state
teams, their repo grants and the caller's own team list, over team/team_member
teams, their repo grants and the caller's own team list, over team/team_member
the legacy id-addressed twin of the team child-team list, held to the same fact: the org's teams are flat, so no team has a child
teams, their repo grants and the caller's own team list, over team/team_member
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
generate — new canon entity Package
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; served as `organization-actions-secret`, so `visibility` is published and `selected_repositories_url` only on a `selected` row - a link on an `all` row would advertise a route that answers 409. NO `value` MEMBER IS SERVED AND NONE EXISTS: `actions-secret` declares a name and two dates, `ci_binding.value` is NULL on every masked row, and conformance asserts the property is absent from every served secret rather than trusting the schema, which sets no `additionalProperties: false`
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; a name the list published, never a name recomputed from the theme's pool. A name this organization does not hold is GitHub's own 404
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; the repositories the secret actually reaches - `all` reaches every one, `private` the private ones, `selected` the named ones. The vendored operation declares NO 409 on the secret form (only the variable form does), so this answers the 200 whatever the visibility, and conformance fetches every repository it names to prove the link resolves
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; the scope's own 32 X25519 public-key bytes, base64-encoded, and its monotonic `key_id`. THE PUBLIC HALF IS REAL AND THERE IS NO PRIVATE HALF - this universe accepts no writes, so nothing is ever encrypted to these bytes; conformance base64-decodes them and asserts the length is 32 rather than accepting any string
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; `organization-actions-variable`, whose `value` IS declared and is READ from the artifact row canon's `value_source` names - the telemetry exporter's endpoint and its protocol - so the setting and the thing it configures cannot drift apart
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience - GitHub's newest family, whose vendored operations mirror the Actions ones byte-for-byte and reuse the identical components; a name the list published. A name this organization does not hold is GitHub's own 404
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. THE 409 BRANCH of the same operation, and the only answer this organization can give it: its one coding-agent variable is the workspace the agent operates in, which every repository sees, so its visibility is `all`. The vendored 409 declares no body and neither does this. The `actions` twin answers the 200, so the two rows together exercise both branches the document declares
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience; the ORGANIZATION secrets this repository can see, and the visibility rule that decides which lives in `reader.orgBindingsVisibleToRepo` rather than in four renderers. Served as the PLAIN `actions-secret`, not the organization form - the vendored operation names that component here - so no `visibility` is published on this surface even though the rows are the organization's
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience; the organization variables this repository can see, through the same reader rule as its secret twin
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience; the repository's OWN secrets. Two of them are backed by a `person_credential` this organization really issued - the registry pull token and the integration-suite token, whose two dates are the ROTATION PAIR canon records - so their instants are facts rather than plausible numbers
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience; a name the list published
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The `agents` family is canon's `coding-agent` audience; the repository scope's own 32 public-key bytes
SERVED 2026-09-12 (hello-19 wave W-a) as GitHub's empty envelope at 200: this organization hands its coding agent ONE setting at the REPOSITORY scope and it is a SECRET - the push token the agent runs with - so there is no repository-scoped variable to publish. The one published agent setting, the workspace it operates in, is ORGANIZATION-scoped and reaches this repository through `/repos/{owner}/{repo}/agents/organization-variables`, which is green; duplicating it here would publish one setting as two. The route is the SAME code as its `actions` twin, so the day canon gives the agent a repository variable this row stops being empty on its own, and conformance drives it (`expectsEmpty`) rather than asserting nothing
refuse — REFUSED 2026-09-12 (hello-19 wave W-a) with GitHub's own 404: no name resolves over the empty collection its list half answers - see that row. Ungated across generations, because "this repository holds no coding-agent variable" is as true on all 127 registered pins as it is on hello-19
STALE REASON ("new canon entity Board"): a projectsV2 PROJECT is not a board. It is a titled, dated container of issues with an owner, a creator and an open/closed state, which is canon's `epic` exactly (22 rows) — the same entity renderer-linear/src/pm.ts already publishes as a Linear project. The BOARD (its views, columns and field definitions) is the part canon still lacks and no row here publishes one. Gated on hello-16's portfolio columns, four of which are REQUIRED members of `projects-v2`
STALE REASON ("new canon entity Board"): a projectsV2 PROJECT is not a board. It is a titled, dated container of issues with an owner, a creator and an open/closed state, which is canon's `epic` exactly (22 rows) — the same entity renderer-linear/src/pm.ts already publishes as a Linear project. The BOARD (its views, columns and field definitions) is the part canon still lacks and no row here publishes one. Gated on hello-16's portfolio columns, four of which are REQUIRED members of `projects-v2`
STALE REASON ("new canon entity Board"): the items of an epic ARE its issues (reader.epicIssues()), and each item's `content` is the object `/repos/{owner}/{repo}/issues/{issue_number}` already serves — so the two cross-check. Every item is an `Issue`: canon attaches a pull request to an issue rather than to an epic, and a draft issue exists only because somebody typed one into a project
STALE REASON ("new canon entity Board"): the items of an epic ARE its issues (reader.epicIssues()), and each item's `content` is the object `/repos/{owner}/{repo}/issues/{issue_number}` already serves — so the two cross-check. Every item is an `Issue`: canon attaches a pull request to an issue rather than to an epic, and a draft issue exists only because somebody typed one into a project
no person in this organization owns a project — all 22 `epic` rows carry a `team` and belong to one of the four teams, never to an individual; GitHub's own answer for a user who owns no projects is `[]` at 200. The ORGANIZATION's list is served with real content in the same wave, which is what makes this an answer rather than a gap. RULED by the founder 2026-09-12
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
generate — new canon entity Board
the changed-file list and the merge check are computable from the PR's commits and git trees
the changed-file list and the merge check are computable from the PR's commits and git trees
a single review and its comments over review/review_comment
NO REVIEW COMMENT IN THIS UNIVERSE BELONGS TO A REVIEW. `review_comment.review` is NULL on every one of the 100 rows, which is why `shapePullReviewComment` has always rendered `pull_request_review_id: null` — so a review's comment list is empty BY THE DATA, and the response agrees with the comments' own bodies rather than contradicting them. The comments themselves are served and non-empty at `/pulls/{n}/comments`; only the review→comment edge is missing, and attaching a pull request's comments to its single review would invent a relationship canon never recorded. Falsifiable: the day the generator links a comment to a review, this row goes red. RULED by the founder 2026-09-09
no pull request in this universe is stacked on another — all 24 `pull` rows carry `base_branch='main'` and no pull's base is another pull's head (0 rows on that self-join); GitHub's own answer for a repository with no stacks is `[]` at 200. RULED by the founder 2026-09-12
generate — new canon entity PullStack
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
SERVED 2026-09-12 (hello-19 wave W-a) as GitHub's empty envelope at 200, by FOUNDER RULING F3 (2026-09-12): olympus-labs runs no private package registry, so a dependency bot has nothing private to reach and this organization holds no Dependabot secret. The SCOPE is real - canon mints it and `.../dependabot/secrets/public-key` is green beside this row, exactly as GitHub publishes a Dependabot public key whether or not a secret exists - and the empty list is only an honest `[]` once something says the scope exists, which is why this row is gated on `hasCiBindings()` and answers the generation on an older artifact. `compiler/src/hello19.test.ts` coherence check 9 asserts the emptiness in canon at both windows, so the ruling is falsifiable the day this organization gains a private registry
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The Dependabot scope's own 32 X25519 public-key bytes. GREEN even though the collection beside it is empty by founder ruling F3, because that is exactly what GitHub does: the key is what a client would encrypt a NEW secret to, so it is published whether or not one exists
SERVED 2026-09-12 (hello-19 wave W-a) as GitHub's empty envelope at 200, by FOUNDER RULING F3 (2026-09-12): olympus-labs runs no private package registry, so a dependency bot has nothing private to reach and this repository holds no Dependabot secret. The SCOPE is real - canon mints it and `.../dependabot/secrets/public-key` is green beside this row, exactly as GitHub publishes a Dependabot public key whether or not a secret exists - and the empty list is only an honest `[]` once something says the scope exists, which is why this row is gated on `hasCiBindings()` and answers the generation on an older artifact. `compiler/src/hello19.test.ts` coherence check 9 asserts the emptiness in canon at both windows, so the ruling is falsifiable the day this organization gains a private registry
SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` + `ci_binding_scope` - the settings and credentials this organization hands its pipelines. GitHub publishes ONE object as two URL families, so a secret is a binding whose value may not be published and a variable is one whose value may; canon carries exactly that boolean (`masked`) and this row is the same read with a different filter. The Dependabot scope's own 32 X25519 public-key bytes. GREEN even though the collection beside it is empty by founder ruling F3, because that is exactly what GitHub does: the key is what a client would encrypt a NEW secret to, so it is published whether or not one exists
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
generate — new canon entity SecurityFinding
generate — new canon entity SecurityConfiguration
refuse — REFUSED 2026-09-12 (hello-19 wave W-a) with GitHub's own 404: no name resolves over the empty collection founder ruling F3 leaves at this scope - olympus-labs runs no private package registry. Ungated across generations, because the absence is true on every artifact this project has produced
refuse — REFUSED 2026-09-12 (hello-19 wave W-a) with GitHub's own 404: the secret whose repositories this asks for does not exist - see the by-name row beside it
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
refuse — REFUSED 2026-09-12 (hello-19 wave W-a) with GitHub's own 404: no name resolves over the empty collection founder ruling F3 leaves at this scope
generate — new canon entity Discussion
generate — new canon entity Board
the protection document already shapes required_signatures and the status-check contexts from real check runs (render-protection.ts)
the protection document already shapes required_signatures and the status-check contexts from real check runs (render-protection.ts)
refuse — no branch in this repository restricts who may push — canon's only two `protected_ref` rows are scoped to `namespace-001` and repo-01 carries an empty `namespace` column, so the document shapeBranchProtection publishes (render-protection.ts:37) has no `restrictions` object; GitHub's own answer for a protected branch with no push restrictions is 404. RULED by the founder 2026-09-12
refuse — no branch in this repository restricts who may push — canon's only two `protected_ref` rows are scoped to `namespace-001` and repo-01 carries an empty `namespace` column, so the document shapeBranchProtection publishes (render-protection.ts:37) has no `restrictions` object; GitHub's own answer for a protected branch with no push restrictions is 404. RULED by the founder 2026-09-12
refuse — no branch in this repository restricts who may push — canon's only two `protected_ref` rows are scoped to `namespace-001` and repo-01 carries an empty `namespace` column, so the document shapeBranchProtection publishes (render-protection.ts:37) has no `restrictions` object; GitHub's own answer for a protected branch with no push restrictions is 404. RULED by the founder 2026-09-12
refuse — no branch in this repository restricts who may push — canon's only two `protected_ref` rows are scoped to `namespace-001` and repo-01 carries an empty `namespace` column, so the document shapeBranchProtection publishes (render-protection.ts:37) has no `restrictions` object; GitHub's own answer for a protected branch with no push restrictions is 404. RULED by the founder 2026-09-12
neither `production` nor `staging` restricts which branches may deploy to it — all 22 `deployment` rows name a ref that already exists in `branch`, and canon carries no per-environment branch policy; GitHub's own answer for an environment with no policies is `{total_count: 0, branch_policies: []}` at 200 (this operation nests the same empty page under `custom_deployment_protection_rules`). RULED by the founder 2026-09-12
neither `production` nor `staging` restricts which branches may deploy to it — all 22 `deployment` rows name a ref that already exists in `branch`, and canon carries no per-environment branch policy; GitHub's own answer for an environment with no policies is `{total_count: 0, branch_policies: []}` at 200 (this operation nests the same empty page under `available_custom_deployment_protection_rule_integrations`). RULED by the founder 2026-09-12
neither `production` nor `staging` restricts which branches may deploy to it — all 22 `deployment` rows name a ref that already exists in `branch`, and canon carries no per-environment branch policy; GitHub's own answer for an environment with no policies is `{total_count: 0, branch_policies: []}` at 200 (this operation nests the same empty page under `branch_policies`). RULED by the founder 2026-09-12
generate — new canon entity EnvironmentProtectionRule
generate — new canon entity EnvironmentProtectionRule
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
generate — new canon entity Gist
refuse — a source import exists only because someone started one, and this universe has never run one — but GitHub removed the Source Import API on 2024-04-12, before the 2026-03-10 generation every gh pin emulates, so no pin serves it and every host answers GitHub's own deprecated 404 naming the GitHub Importer (meta.retired_meaning)
refuse — a source import exists only because someone started one, and this universe has never run one — but GitHub removed the Source Import API on 2024-04-12, before the 2026-03-10 generation every gh pin emulates, so no pin serves it and every host answers GitHub's own deprecated 404 naming the GitHub Importer (meta.retired_meaning)
refuse — a source import exists only because someone started one, and this universe has never run one — but GitHub removed the Source Import API on 2024-04-12, before the 2026-03-10 generation every gh pin emulates, so no pin serves it and every host answers GitHub's own deprecated 404 naming the GitHub Importer (meta.retired_meaning)
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
refuse — a migration or a source import exists only because someone started one; this universe has never run either, so GitHub answers 404 for the job that was never created
generate — new canon entity BillingPeriod
generate — new canon entity Subscription
generate — new canon entity Subscription
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
generate — new canon entity BillingPeriod
no commit in this universe carries a comment (DECISIONS 2026-08-20 [commit-detail] decision 2), so the repository-wide commit-comment list is truthfully empty
no commit in this universe carries a comment: review conversation happens on the pull request, and canon has no commit-comment entity (DECISIONS 2026-08-20 [commit-detail] decision 2)
refuse — the id half of the commit-comment pair: with no commit comment in this universe, no comment id can resolve
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
generate — new canon entity CopilotSpace
the community profile is which of README/LICENSE/CONTRIBUTING/CODE_OF_CONDUCT the tree actually holds
every statistic is an aggregation over commits (authors, weeks, additions/deletions)
every statistic is an aggregation over commits (authors, weeks, additions/deletions)
every statistic is an aggregation over commits (authors, weeks, additions/deletions)
every statistic is an aggregation over commits (authors, weeks, additions/deletions)
every statistic is an aggregation over commits (authors, weeks, additions/deletions)
generate — new canon entity RepoTraffic
generate — new canon entity RepoTraffic
generate — new canon entity RepoTraffic
generate — new canon entity RepoTraffic
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityFinding
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityConfiguration
generate — new canon entity SecurityFinding
search over the artifact rows the other search endpoints already query
search over the artifact rows the other search endpoints already query
search over the artifact rows the other search endpoints already query
generate — new canon entity RepoTopic
this universe's CI records a per-job conclusion and nothing finer, so a resolving check-run id answers 200 [] while a bogus one still 404s (DECISIONS 2026-08-20 [commit-detail], verdict b)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — GitHub Classroom is a separate product with its own teacher accounts; this universe has no classroom, and every classroom object exists only because a teacher created it — and GitHub sunset Classroom itself on 2026-08-28, so live hosts answer its own 410 while the gh pins, which all emulate the pre-sunset 2026-03-10 generation, keep this refusal (meta.retired_meaning)
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refuse — olympus-labs is a standalone organization, not an enterprise account, so no enterprise slug in this universe resolves — GitHub's own 404 for an unknown enterprise is the whole answer
refs resolve against the branch/commit tables the git transport already serves
refs resolve against the branch/commit tables the git transport already serves
refuse — EVERY TAG IN THIS UNIVERSE IS LIGHTWEIGHT. A canonical `release` carries tag, body, author, created_epoch and tag_commit, but no tag OBJECT and therefore no object sha — and `{tag_sha}` is the only way this operation is addressed, so no sha can ever resolve. The project already ruled this in packages/renderer-github/src/git/objects.ts (`repoRefs`): 'Tags are LIGHTWEIGHT (a ref straight at a commit), which is what the artifact actually models … Inventing an annotated tag object here would mint a sha no other endpoint serves.' The Azure DevOps twin (`.../annotatedtags/{objectId}`) was ruled the same way in #419. GitHub answers 404 for a git object it does not hold, which is the whole answer. RULED by the founder 2026-09-09
generate — new canon entity PagesSite
generate — new canon entity PagesSite
generate — new canon entity PagesSite
generate — new canon entity PagesSite
generate — new canon entity PagesSite
generate — new canon entity PagesSite
release assets over the release the tag already resolves to (14-hit demand cluster, telemetry 2026-09-01)
release assets over the release the tag already resolves to (14-hit demand cluster, telemetry 2026-09-01)
repo collaborators are the teams with access plus the outside contributors canon already marks (Person.member = false)
repo collaborators are the teams with access plus the outside contributors canon already marks (Person.member = false)
repo collaborators are the teams with access plus the outside contributors canon already marks (Person.member = false)
no pending repository invitations in this universe: reader.listMemberships(repo, repo) (reader.ts:2961) holds six rows and every one is `active` — the repository roster is the approvers whose organization role is a plain member, plus the CI identity, and all of them were GRANTED rather than offered. SERVED 2026-09-10 as GitHub's empty array, behind the hello-16 generation gate and behind the repository guard — an unknown repository is still GitHub's own 404 — RULED EMPTY by the founder 2026-09-10
no pending repository invitations in this universe: reader.membershipsForPerson(athena) (reader.ts:2969) carries no pending repository row, because nobody here has been offered a repository. It is the caller's side of /repos/{owner}/{repo}/invitations and answers the same fact, so conformance asserts the two agree. SERVED 2026-09-10 as GitHub's empty array, behind the hello-16 generation gate — RULED EMPTY by the founder 2026-09-10
no interaction limit is active anywhere in this universe — olympus-labs is a private organization whose one repository is private (repo.visibility='private'), so there is no drive-by traffic to limit and nobody has set one; GitHub's own answer for a scope with no active limit is `{}` at 200 (the spec's 200 has no required member). RULED by the founder 2026-09-12
no interaction limit is active anywhere in this universe — olympus-labs is a private organization whose one repository is private (repo.visibility='private'), so there is no drive-by traffic to limit and nobody has set one; GitHub's own answer for a scope with no active limit is `{}` at 200 (the spec's 200 has no required member). RULED by the founder 2026-09-12
no interaction limit is active anywhere in this universe — olympus-labs is a private organization whose one repository is private (repo.visibility='private'), so there is no drive-by traffic to limit and nobody has set one; this operation's own 200 is an ARRAY of the users who may bypass the cap, so its empty answer is `[]` rather than the `{}` the three limit reads carry. RULED by the founder 2026-09-12
no interaction limit is active anywhere in this universe — olympus-labs is a private organization whose one repository is private (repo.visibility='private'), so there is no drive-by traffic to limit and nobody has set one; GitHub's own answer for a scope with no active limit is `{}` at 200 (the spec's 200 has no required member). RULED by the founder 2026-09-12
generate — new canon entity InteractionLimit
reader.refCatalog("github.api-versions") in the artifact's own ord order (newest first), and the version this host stamps into x-github-api-version is asserted to be one of them. licence: FACTUAL — the response is a list of API version DATES (gh api /versions returns ["2026-03-10","2022-11-28"]), which carries no authorship, and this host already declares the version each pin emulates. Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
generateheld · data-licensing — static provider catalog, and NOT `derive`: `derive` is defined in this file as computed from artifact rows that already exist, and a vendor catalog is not an artifact row. LICENCE: NO GRANT — the response is ASCII art of the Octocat, which is GitHub artwork and a GitHub trademark. The per-item licence finding is coverage/reviews/2026-09-09-hello-15-stale-reasons-git-hosts.md §5.3, and §5.4 records why the label waited for a shard arm
generateheld · data-licensing — static provider catalog, and NOT `derive`: `derive` is defined in this file as computed from artifact rows that already exist, and a vendor catalog is not an artifact row. LICENCE: NO GRANT — the response is one of GitHub's design aphorisms, creative prose GitHub publishes under no licence. The per-item licence finding is coverage/reviews/2026-09-09-hello-15-stale-reasons-git-hosts.md §5.3, and §5.4 records why the label waited for a shard arm
ContentReaction is canon as of hello-15 (features.contentReactions); reactionsFor() answers it and shapeReaction renders GitHub's closed eight-value content enum over the SAME rows GitLab serves as award emoji. The parent resources now carry the reaction-rollup GitHub embeds
ContentReaction is canon as of hello-15 (features.contentReactions); reactionsFor() answers it and shapeReaction renders GitHub's closed eight-value content enum over the SAME rows GitLab serves as award emoji. The parent resources now carry the reaction-rollup GitHub embeds
ContentReaction is canon as of hello-15 (features.contentReactions); reactionsFor() answers it and shapeReaction renders GitHub's closed eight-value content enum over the SAME rows GitLab serves as award emoji. The parent resources now carry the reaction-rollup GitHub embeds
ContentReaction is canon as of hello-15 (features.contentReactions); reactionsFor() answers it and shapeReaction renders GitHub's closed eight-value content enum over the SAME rows GitLab serves as award emoji. The parent resources now carry the reaction-rollup GitHub embeds
refuse — no commit in this universe carries a comment (DECISIONS 2026-08-20 [commit-detail] decision 2; `/repos/{owner}/{repo}/comments` is already an armed honest empty in honest-empties.ts), so no `comment_id` can ever resolve and GitHub's own answer for a commit comment that does not exist is 404 — the row waits on a CommitComment, not on ContentReaction, whose 80 rows already answer GitHub's other four reaction operations. RULED by the founder 2026-09-12
generate — new canon entity SecurityAdvisory
generate — new canon entity SecurityAdvisory
generate — new canon entity SecurityAdvisory
generate — new canon entity SecurityAdvisory
generate — new canon entity SecurityAdvisory
THE MANIFESTS NEVER CHANGE BETWEEN COMMITS. hello-9's scaffold writes package.json, pnpm-lock.yaml, go.mod/go.sum and requirements.txt from constants, so every commit in a repository carries byte-identical dependency declarations and the diff between any two refs is genuinely empty — GitHub returns the same `[]` for a comparison that adds and removes nothing. This is not the SBOM being unavailable: `/dependency-graph/sbom` serves the real package list (#418), and this row says only that the list did not MOVE. Falsifiable: the day the generator varies a manifest across commits, a comparison spanning that change stops being empty and the row goes red. RULED by the founder 2026-09-09
the SBOM is the repo's own manifests and lockfiles, which hello-9 generates for real (DECISIONS 2026-08-22 [compiler/gen-9])
generate — needs a gateway download route (service-own endpoint) — later. The DATA is already served: `/dependency-graph/sbom` returns the real SPDX document (#418). This pair is the request-then-download flow, and its second half is a 302 to bytes on the SERVICE host, so it needs a route in packages/gateway rather than more renderer. Minting an `sbom_url` that 404s would be a placeholder link (invariant #4). RULED by the founder 2026-09-09
generate — needs a gateway download route (service-own endpoint) — later. The DATA is already served: `/dependency-graph/sbom` returns the real SPDX document (#418). This row's 201 hands back an `sbom_url` the fetch-report row must then serve, so the two land together or neither does. RULED by the founder 2026-09-09
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
generate — new canon entity SecurityFinding
fetch negotiation; non-delta packfile v2, side-band-64k, shallow/deepen/unshallow. No partial clone (filter), no protocol v2
ref advertisement, pkt-line; ?service=git-upload-pack only — dumb HTTP is not served and 404s
read-only — NOT A READ, and in the manifest for the one reason this mode exists - clients demonstrably probe it, because `git push` is what a developer types next after a clone that worked. The read-only 403 IS its final response (invariant #3) rather than a gap waiting on anything: renderer-github/src/git/routes.ts:120 answers the advertisement `?service=git-receive-pack` with readOnly(c, "push to this repository (git-receive-pack)") and the POST is deliberately given NO route at all (routes.ts:134), so both halves of a push refuse identically. The row is `excluded` and never joins the badge denominator, which is what this mode has meant since A0.1 - the zendesk /api/v2/users/me/session/renew precedent (founder ruling 2026-09-06), applied to the fleet's only other excluded row that is a WRITE rather than a scope decision. CLASSIFIED 2026-09-13 (the unjudged-47 pass) and NOT re-ruled: the row's own curated note in git-transport.ts has said exactly this since the transport shipped (DECISIONS 2026-08-23); the mode word was simply never written down beside it. NO NUMBER MOVES - an excluded row is counted in the generation report's (excluded) column either way, and the report's `read-only` column reads 0 whenever the mode is used correctly
reader.listLicenses() reads license_catalog (a compile-time table, never a renderer constant) and render-catalogs.ts shapes license-simple over it; node_id is minted with artifact's own nodeId("License", key) except mit, whose api.github.com value the repository object has published since Wave A. licence: FREE — the thirteen bodies GitHub serves (gh api /licenses: agpl-3.0, apache-2.0, bsd-2-clause, bsd-3-clause, bsl-1.0, cc0-1.0, epl-2.0, gpl-2.0, gpl-3.0, lgpl-2.1, mit, mpl-2.0, unlicense) are meant for verbatim redistribution and several say so in their own header — the GPL family carries "Everyone is permitted to copy and distribute verbatim copies of this license document", CC0-1.0 and Unlicense are public-domain dedications, Apache-2.0 ships an APPENDIX instructing reproduction; the key/spdx_id/permissions metadata comes from github/choosealicense.com, which is MIT (gh api repos/github/choosealicense.com/license). Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
reader.license(key) reads license_catalog and render-catalogs.ts shapes the full license component; the body is the artifact's body column byte for byte, upstream's [year]/[fullname] placeholders included. licence: FREE — the thirteen bodies GitHub serves (gh api /licenses: agpl-3.0, apache-2.0, bsd-2-clause, bsd-3-clause, bsl-1.0, cc0-1.0, epl-2.0, gpl-2.0, gpl-3.0, lgpl-2.1, mit, mpl-2.0, unlicense) are meant for verbatim redistribution and several say so in their own header — the GPL family carries "Everyone is permitted to copy and distribute verbatim copies of this license document", CC0-1.0 and Unlicense are public-domain dedications, Apache-2.0 ships an APPENDIX instructing reproduction; the key/spdx_id/permissions metadata comes from github/choosealicense.com, which is MIT (gh api repos/github/choosealicense.com/license). Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
SERVED 2026-09-09 (hello-16): the LICENSE blob `features.repoLicense` put in every tree, read through the same fileAt/shapeContentFile path /repos/{owner}/{repo}/contents/LICENSE uses, so the two cannot describe different bytes. The `license` object is the one `shapeRepo` has published since Wave A (MIT_LICENSE in packages/renderer-github/src/render.ts), which closes the inconsistency the 2026-09-01 reason named: the repository object and this row can no longer name different licences, and conformance asserts they are byte-identical AND that both match the artifact's own /licenses catalogue row for `mit`. The served body carries no upstream `[year]`/`[fullname]` placeholder. `_links.self`, `_links.git` and `download_url` all resolve on this host — the last over the `/{owner}/{repo}/raw/{ref}/{path}` path this renderer has advertised on every content-file since SPEC rev 7 and now answers. `license.url` still points at the /licenses catalogue, which is the CATALOGUE wave's coverage and answers the honest coverage 404 until it lands. An older artifact answers the hello-16 generation gap rather than GitHub's no-licence 404, which would contradict the `license: MIT` the repository object serves on the same host
generate — new canon entity PrivateRegistryConfig
generate — new canon entity PrivateRegistryConfig
generate — new canon entity PrivateRegistryConfig
generate — new canon entity SecurityCampaign
generate — new canon entity SecurityCampaign
generateheld · data-licensing — static provider catalog, and NOT `derive`: `derive` is defined in this file as computed from artifact rows that already exist, and a vendor catalog is not an artifact row. LICENCE: NO USABLE GRANT, and the CC BY 4.0 premise is out of date — EthicalSource/contributor_covenant's only LICENSE.md is the Hippocratic License 3.0, and the other body GitHub serves is the Django Code of Conduct, CC BY-SA 4.0, whose ShareAlike reciprocity cannot travel into a compiled artifact this service publishes. The per-item licence finding is coverage/reviews/2026-09-09-hello-15-stale-reasons-git-hosts.md §5.3, and §5.4 records why the label waited for a shard arm
generateheld · data-licensing — static provider catalog, and NOT `derive`: `derive` is defined in this file as computed from artifact rows that already exist, and a vendor catalog is not an artifact row. LICENCE: NO USABLE GRANT, and the CC BY 4.0 premise is out of date — EthicalSource/contributor_covenant's only LICENSE.md is the Hippocratic License 3.0, and the other body GitHub serves is the Django Code of Conduct, CC BY-SA 4.0, whose ShareAlike reciprocity cannot travel into a compiled artifact this service publishes. The per-item licence finding is coverage/reviews/2026-09-09-hello-15-stale-reasons-git-hosts.md §5.3, and §5.4 records why the label waited for a shard arm
SERVED 2026-09-09: reader.listCheckoutKeys(repo) (packages/artifact/src/reader.ts:2351), validated against the vendored `deploy-key` component. packages/canon/src/ci-config.ts:236 names THIS endpoint as the reason a checkout key's public half is publishable at all; `key` is the ssh-ed25519 material and `title` its OpenSSH comment, and the conformance entry re-hashes the decoded blob to the artifact's own fingerprint_sha256. `read_only` is true because a CI checkout key clones, and `last_used` is null because canon records no use. Paginated with GitHub's Link header, walked to the last page in conformance; answers the hello-15 generation gap on an older artifact rather than an empty array
SERVED 2026-09-09: the same key by id — reader.listCheckoutKeys(repo) (packages/artifact/src/reader.ts:2351) addressed by githubId(CheckoutKeyRow.id), byte-identical to the row the list serves. An id nothing holds is GitHub's own 404
reader.listGitignoreTemplates() reads gitignore_template; every one of the 163 names it lists resolves at {name}, which conformance follows one by one. licence: CC0-1.0 — github/gitignore publishes its templates under the Creative Commons Zero v1.0 Universal public-domain dedication (its own LICENSE file; gh api repos/github/gitignore/license returns spdx_id CC0-1.0). Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
reader.gitignoreTemplate(name) reads gitignore_template and serves the file's bytes verbatim; the lookup is case-sensitive, as upstream's own file names are. licence: CC0-1.0 — github/gitignore publishes its templates under the Creative Commons Zero v1.0 Universal public-domain dedication (its own LICENSE file; gh api repos/github/gitignore/license returns spdx_id CC0-1.0). Older pins answer the refCatalogs generation-gap 404 rather than an empty catalogue, which on these rows would be a false claim about the HOST. SERVED 2026-09-09 (hello-16)
generateheld · data-licensing — static provider catalog, and NOT `derive`: `derive` is defined in this file as computed from artifact rows that already exist, and a vendor catalog is not an artifact row. LICENCE: NO GRANT — the response is a map of roughly 1,870 shortcodes whose VALUES are github.githubassets.com URLs for GitHub's own image assets, which this project holds no grant to redistribute and which would also hand a caller live github.com URLs from a sandbox host. The per-item licence finding is coverage/reviews/2026-09-09-hello-15-stale-reasons-git-hosts.md §5.3, and §5.4 records why the label waited for a shard arm
03 / What's simulated
Every GitHub call resolves against the same simulated data set every other provider serves. Counted from the gh-2026-03-g11 artifact (universe generation 11):
Each line below is one assertion in the conformance suite named beside it — run on every build, over one artifact, through the real renderers. Nothing is claimed here that no expect checks.
Every pull request in the repository has ONE head-branch name: this host's `head.ref` and GraphQL `headRefName`, GitLab's `source_branch` and `sourceBranch`, Bitbucket's `source.branch.name` and Azure DevOps' `refs/heads/…` `sourceRefName` all print the same string, and that string resolves as a real branch.
Against GitLab, Bitbucket, Azure DevOps · parity/branch-parity.test.ts
The engineer a Salesforce Case was escalated to is a member of this organization and fetchable as a user here — the one place this org's go-to-market cast and its engineering roster share a human, which is why the CRM host reports the FACT of an escalation and never invents a custom field naming the person.
Against Salesforce · parity/crm-parity.test.ts
For one commit sha, the pull requests it is attributed to, the CI job names and their pass/fail verdicts, and the per-file added/deleted counts are identical to what Bitbucket serves for the same sha.
Against Bitbucket · parity/commit-detail-parity.test.ts
Milestone numbers and their created/updated instants are identical to GitLab's, on the live generation and on the frozen-pin generation both.
Against GitLab · parity/milestone-parity.test.ts
The organisation was created at ONE instant: `/orgs/{org}`, GitLab's group, Linear's `organization.createdAt` and the Zendesk account's own locale records all return it, and every Linear team carries the same one.
Against GitLab, Linear, Zendesk · parity/org-member-parity.test.ts
Every identity the AI-telemetry hosts bill for resolves as a user here with the same name; Cursor's reported commit hashes fetch here with the same sha and an author login equal to the reported email's localpart; and a finished Cursor agent's PR URL is a pull request here whose head branch is the branch the agent reported.
Against Anthropic, Cursor, Devin, OpenAI, Codex Analytics · parity/m3-parity.test.ts
The commit a Sentry stack frame resolves against is a commit this host serves, and the source lines Sentry ships in that frame's `context` are the bytes this host returns for that file at that sha.
Against Sentry · parity/incident-parity.test.ts
One incident walked over four hosts — the Slack thread, the Jira and Linear issue, the pull request here and the GitLab merge request — carries the same issue key, the same branch name and the same 40-character head SHA, on the live hosts and on the frozen `-g6` pins.
Against Slack, Jira, Linear, GitLab · parity/pinned-cross-category.test.ts
The Actions run on a commit is the same build CircleCI reports for that commit: the same head SHA, the same job names with the same pass/fail verdicts, the same head branch, and an `actor.login` equal to the user CircleCI's workflow names as `started_by`.
Against CircleCI · parity/ci-parity.test.ts
05 / Pinned snapshots
Each pin regenerates byte-identically on every request, so a test written against one never drifts. Generations are DIFFERENT universes, not versions of one — never swap a suffix expecting the same data.
gh-2026-03.snap.sandboxapis.devgeneration 12026-03-10not in this generationgh-2026-03-g10.snap.sandboxapis.devgeneration 102026-03-10servedgh-2026-03-g11.snap.sandboxapis.devgeneration 112026-03-10servedgh-2026-03-g2.snap.sandboxapis.devgeneration 22026-03-10servedgh-2026-03-g3.snap.sandboxapis.devgeneration 32026-03-10servedgh-2026-03-g5.snap.sandboxapis.devgeneration 52026-03-10servedgh-2026-03-g6.snap.sandboxapis.devgeneration 62026-03-10servedgh-2026-03-g8.snap.sandboxapis.devgeneration 82026-03-10servedgh-2026-03-g9.snap.sandboxapis.devgeneration 92026-03-10servedNeed an endpoint that is not served yet?
Every row GitHub's manifest carries is on this page, so “not here” is an answer rather than a gap in the rendering. Tell us which path and which client, and it moves up the queue — the order is set by what people ask for.