Point your Jira client (e.g. jira.js Version3Client, python jira) at https://jira.sandboxapis.dev as the host. Paths mirror {site}.atlassian.net — rest/api/3 + rest/agile/1.0; the removed old /search family serves 410 like live Jira, use /rest/api/3/search/jql.
Coverage badge
Deep250/328 · 76%
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.
jira.sandboxapis.devServed & verified
187 / 57%
Answering with real universe data, each response checked against Jira's published spec by the conformance suite on this build.
The full read API
328
Every read surface Jira publishes, deferred long tail included, minus the rows excluded by policy. Writes are out of scope: this universe is read-only.
Not served yet
141
Each returns an explicit, provider-shaped coverage error naming the gap — never invented data.
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://jira.sandboxapis.dev/rest/api/3/myself"Verified drop-in clients
No client library is version-pinned against Jira yet, so this page claims none. What is asserted is the wire: every response above is validated against Jira's own published spec by the conformance suite. Client pins live in coverage/client-pins.yaml and are added as each SDK joins the suite.
02 / Coverage by family
All 328 rows the coverage manifest carries for Jira, 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.
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.
328 read surfaces in 57 families
the team table the renderer already renders as projects
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
no board in this site has a quick filter CONFIGURED - a quick filter is part of a board's CONFIGURATION, and canon models none of it: the board this host renders is a team plus the saved filter it is defined by, and nothing in this universe carries the per-board clause list a quick filter is one of; Jira's own answer for a board with none is an empty page bean (total 0, values []) at 200. RULED by the founder 2026-09-12; RE-WORDED 2026-09-12 (hello-18 wave W-b, AUTONOMOUS RULING, seed brief F2) with the mode unmoved - the sentence used to rest on "this universe accepts no writes", and hello-18's savedFilters domain mints filters nobody typed, so that argument would have ruled out the eight /rest/api/3/filter/ rows this same wave serves. A BoardConfig entity (quick filters, columns, estimation field, ranking field) was deferred on its own merits and is not in hello-18
the same board/sprint/epic listings agile/1.0 already serves green
canon releases and milestones, projected onto the project as Jira versions
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. A board in this site IS defined by its filter — the savedFilters pass mints one board filter per team that tracks work — so this route answers with the one board whose filter the caller named, narrowed off renderBoard so the two routes cannot disagree about its name. A filter no board is built on (the personal and organization-wide ones) answers Jira's empty page bean: a true statement about a real filter rather than an absence
the same board/sprint/epic listings agile/1.0 already serves green
the same board/sprint/epic listings agile/1.0 already serves green
the same board/sprint/epic listings agile/1.0 already serves green
the same board/sprint/epic listings agile/1.0 already serves green
the same board/sprint/epic listings agile/1.0 already serves green
generate — new canon entity BoardConfig
generate — new canon entity BoardConfig
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
refuse — no board in this site has a quick filter CONFIGURED - a quick filter is part of a board's CONFIGURATION and canon models none of it, so no quickFilterId resolves; Jira's own answer is its 404 for the quick filter. RULED by the founder 2026-09-12; RE-WORDED 2026-09-12 (hello-18 wave W-b, AUTONOMOUS RULING, seed brief F2) with the mode unmoved, for the reason the list half's own entry gives
generate — new canon entity BoardConfig
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the status/type/priority/resolution vocabulary the renderer already serves green
the two custom fields (customfield_10016 story points, customfield_10020 sprint) and their single global context
neither custom field this replica serves is an option field — customfield_10020 is an array of Greenhopper sprint blobs and customfield_10016 is a number — so their one context has no select-list option to list; the registry is fixed at compile time and this universe accepts no writes. RULED by the founder 2026-09-09
neither custom field this replica serves carries a default value — customfield_10020 is an array of Greenhopper sprint blobs and customfield_10016 is a number, the registry is fixed at compile time and this universe accepts no writes — and Jira's own description says so for this route: 'If no defaults are set for a context, nothing is returned'. RULED by the founder 2026-09-09
the same two fields carry no default grouped by context either, so the page that groups them has nothing to group; the registry is fixed at compile time and this universe accepts no writes. RULED by the founder 2026-09-09
the two custom fields (customfield_10016 story points, customfield_10020 sprint) and their single global context
the two custom fields (customfield_10016 story points, customfield_10020 sprint) and their single global context
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
refuse — neither custom field this universe defines (customfield_10016, customfield_10020) is a select field, so no option id can ever resolve — Jira's own 404 is the only possible answer
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
the six-state workflow the renderer already serves, plus the issue_transition canon that walks it
the six-state workflow the renderer already serves, plus the issue_transition canon that walks it
the six-state workflow the renderer already serves, plus the issue_transition canon that walks it
the six-state workflow the renderer already serves, plus the issue_transition canon that walks it
generate — new canon entity Scheme
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
generate — Atlassian's built-in rule catalogue: the static-vendor class ruled 2026-09-09 (#408) — a canon constant + compile-time table on a later generation
generate — new canon entity UserPreference
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
STALE REASON ("new canon entity UserPreference"): the 10-row `jira.navigator-columns` catalog ships from hello-16 on and app.ts already serves it at /rest/api/3/settings/columns. Nobody in this site has set columns of their own, and real Jira answers this route with the SITE DEFAULT for a user who has configured none — so the list is the true answer rather than an absence, and conformance asserts the two routes agree row for row
STALE REASON ("new canon entity PersonCredential"): `person_credential` ships from hello-16 on and carries 22 `kind="email"` rows over 17 people with an `is_primary` flag; the vendored UnrestrictedUserEmail shape is {accountId,email} and both fields map onto person.id and the primary address — the same column GitHub's `shapeEmail` reads, so the two hosts cannot name different addresses for one canonical person
STALE REASON ("new canon entity PersonCredential"): `person_credential` ships from hello-16 on and carries 22 `kind="email"` rows over 17 people. A DELIBERATE DIVERGENCE FROM THE VENDORED COMPONENT, recorded in renderer-jira/src/app.ts: the document declares the same single `UnrestrictedUserEmail` object for the bulk operation as for the single one while typing its own `accountId` parameter as an ARRAY, so the body served is {"emails": [...]}, which real Jira Cloud returns and which validates against the declared component (additionalProperties: true, no required member)
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the person table — the same users /rest/api/3/user already renders
the workflow_run / job / deployment canon
the workflow_run / job / deployment canon
the deployment's own terminal state in canon — a deployment that ran was allowed through
the git canon — repositories, branches, commits and pull requests
the git canon — repositories, branches, commits and pull requests
THE RENDERER JUDGMENT THE 2026-09-09 REASON LEFT OPEN IS TAKEN: Jira Ops' `IncidentData` projects onto canon.Incident with nothing invented. All ten required members have a source — schemaVersion is the document's own enum, id/summary/description/createdDate come off the row, affectedComponents is the one component it broke, status is derived from resolved_epoch, updateSequenceNumber is lastUpdated in millis, and url points at pd.sandboxapis.dev/incidents/{id}, the PagerDuty resource that serves the same row. `associations` names the tracker issue this host itself answers, which is the four-hop cross-check. Gated on the incident domain (hello-12+)
generate — required tier/componentType/avatarUrl/description have no canon source — generate
generate — new canon entity FeatureFlag
generate — new canon entity DevOpsWorkspace
generate — new canon entity PostIncidentReview — the B1.0 incident domain
refuse — no issue and no version in olympus-labs carries a remote link - a remote link is an application link to an object in another Atlassian product and this site has no linked Confluence, no linked Bitbucket and no app, so no link id resolves and Jira's own 404 is the whole answer. RULED by the founder 2026-09-12
generate — new canon entity DevOpsWorkspace
generate — new canon entity DevOpsWorkspace
generate — new canon entity SecurityFinding
reader.refCatalog("jira.project-types"); the four keys are the projectTypeKey enum the vendored description declares, so the {projectTypeKey} routes are total over this list. licence: FACTUAL, WITH ONE FIELD OMITTED — key, formattedKey and descriptionI18nKey are functional product identifiers and carry no authorship, but icon is a base64 Adobe-Illustrator SVG, which is Atlassian ARTWORK. ProjectType declares NO required properties in the vendored description, so a response without icon is a legal one and that is what this row will serve. 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("jira.project-types") by key; a fifth spelling is Jira's own 404 rather than a coverage miss. licence: FACTUAL, WITH ONE FIELD OMITTED — key, formattedKey and descriptionI18nKey are functional product identifiers and carry no authorship, but icon is a base64 Adobe-Illustrator SVG, which is Atlassian ARTWORK. ProjectType declares NO required properties in the vendored description, so a response without icon is a legal one and that is what this row will serve. 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("jira.project-types") by key, the accessible twin of the by-key row and the same object. licence: FACTUAL, WITH ONE FIELD OMITTED — key, formattedKey and descriptionI18nKey are functional product identifiers and carry no authorship, but icon is a base64 Adobe-Illustrator SVG, which is Atlassian ARTWORK. ProjectType declares NO required properties in the vendored description, so a response without icon is a legal one and that is what this row will serve. 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("jira.project-types") - the same four, because this site models neither a licence nor a create permission to narrow them by, and deciding at render time that a type is unavailable would be a fact nothing in canon states. licence: FACTUAL, WITH ONE FIELD OMITTED — key, formattedKey and descriptionI18nKey are functional product identifiers and carry no authorship, but icon is a base64 Adobe-Illustrator SVG, which is Atlassian ARTWORK. ProjectType declares NO required properties in the vendored description, so a response without icon is a legal one and that is what this row will serve. 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)
no project category is defined in this Jira site - olympus-labs runs one project and a category is an administrator grouping over many; Jira creates none with a site and its own answer for a site with none is [] at 200. RULED by the founder 2026-09-12
a pure function over the project keys canon already carries
a pure function over the project keys canon already carries
a pure function over the project keys canon already carries
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — data classification is an Atlassian Guard / Premium feature this site does not have, and Jira answers 403 to a token without the classification scope
refuse — data classification is an Atlassian Guard / Premium feature this site does not have, and Jira answers 403 to a token without the classification scope
refuse — no project category is defined in this Jira site - olympus-labs runs one project and a category is an administrator grouping over many, so no category id resolves and Jira's own 404 for a category that is not found is the whole answer. RULED by the founder 2026-09-12
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
generate — new canon entity EntityProperty
generate — new canon entity EntityProperty
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
reader.refCatalog("jira.events") in id order. licence: FACTUAL — the response is {id, name} event-type names ("Issue Created", "Issue Updated" in the vendored description's example), an enumeration of Jira's own notification triggers. 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)
the field registry in packages/renderer-jira/src/metadata.ts crossed with the issue-type vocabulary
issue_transition rows plus the six-state workflow vocabulary
the field registry in packages/renderer-jira/src/metadata.ts crossed with the issue-type vocabulary
the field registry in packages/renderer-jira/src/metadata.ts crossed with the issue-type vocabulary
the field registry in packages/renderer-jira/src/metadata.ts crossed with the issue-type vocabulary
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
the canon component rows the project's issues already reference
the canon component rows the project's issues already reference
the canon component rows the project's issues already reference
the canon component rows the project's issues already reference
the canon component rows the project's issues already reference
canon releases and milestones, projected onto the project as Jira versions
canon releases and milestones, projected onto the project as Jira versions
canon releases and milestones, projected onto the project as Jira versions
canon releases and milestones, projected onto the project as Jira versions
no issue and no version in olympus-labs carries a remote link - a remote link is an application link to an object in another Atlassian product and this site has no linked Confluence, no linked Bitbucket and no app; Jira's own answer for an issue with none is [] at 200. RULED by the founder 2026-09-12
canon releases and milestones, projected onto the project as Jira versions
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The filter object: id, name, owner, the baked jql verbatim, viewUrl, searchUrl, favourite, favouritedCount, sharePermissions from the share scope and Jira's empty FilterSubscriptionsList. description, approximateLastUsed, editPermissions and sharedUsers are OMITTED rather than invented — canon records none of the four and only name is required
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The same array Filter.sharePermissions carries, from saved_filter.share_scope: private is Jira's empty list, org is one loggedin permission (its own word for every logged-in user, where global would include anonymous access this site does not have), team is a project permission naming that team's project
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The single read off that same list — the conformance entry discovers the id THROUGH the list route and asserts the object comes back identical, so the id the list hands out is the id this route accepts. A private filter has no permission, so every id 404s there, which is the operation's own declared answer
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. PRIVATE, and the artifact says so: every filter a person saved FOR THEMSELVES — kind = mine, the only kind the pass mints per person — carries share_scope = private, and the wider ones are wide because of what they ARE. The conformance entry asserts that link rather than the constant
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The CALLER's stars: saved_filter.favourite records the owner's star (1 when the filter selects work in an active sprint), and Jira documents Filter.favourite as the calling user's, so this list is the filters this replica's viewer owns AND starred. Non-empty at both windows because that viewer owns the organization-wide filter
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. listSavedFilters("jira", caller) — the filters this replica's viewer OWNS, which is what the operation asks for; includeFavourites=true is honoured and adds the ones they starred, all of which they already own
SERVED 2026-09-12 (hello-18 wave W-b): canon.SavedFilter landed with features.savedFilters (decisions/2026-09-12-1139-hello-18-saved-filters.md) — a query whose CLAUSES are canon's and whose TEXT the compiler bakes per host, so saved_filter.query is already JQL on a `jira` row and WIQL on an `ado` one. The paged search over every filter in the site, with filterName, accountId, id and projectId answered from canon and the documented orderBy set. FilterDetails.favourite is FALSE on every row and that is the document's own reading — it is defined as "by any users, NOT including the filter owner", and the only star canon records is the owner's, which favouritedCount (defined as including the owner) carries instead
refuse — no filter in this site carries a column configuration of its own - a filter's columns are set by its owner in the issue navigator, canon's saved_filter records a QUERY and not a column set, and this universe accepts no writes; Jira's own answer for a filter with none is the 404 this operation declares in as many words ("Returned if a column configuration is not set for the filter"). THE SIBLING ROUTE GOES THE OTHER WAY AND THE DOCUMENT IS WHY: /rest/api/3/user/columns is a derive row serving the SITE DEFAULT because real Jira falls back to it for a user who configured none, and this operation declares no such fallback. The default columns a filter's results are viewed with are still readable, at /rest/api/3/settings/columns and /rest/api/3/user/columns. RULED 2026-09-12 (hello-18 wave W-b, autonomous)
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
refuse — no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; the LIST is an honest empty at 200, so this replica is plainly allowed to read schemes and an id over that empty collection can only be Jira's own 404. RULED by the founder 2026-09-12
refuse — no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; the LIST is an honest empty at 200, so this replica is plainly allowed to read schemes and an id over that empty collection can only be Jira's own 404. RULED by the founder 2026-09-12
refuse — no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; the LIST is an honest empty at 200, so this replica is plainly allowed to read schemes and an id over that empty collection can only be Jira's own 404. RULED by the founder 2026-09-12
generate — new canon entity Dashboard
generate — new canon entity Dashboard
generate — new canon entity EntityProperty
generate — new canon entity EntityProperty
generate — new canon entity Dashboard
generate — new canon entity Dashboard
generate — new canon entity Dashboard
no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; Jira creates no issue security scheme with a site and its own answer for a site with none is {"issueSecuritySchemes": []} at 200 (an empty page bean on the paged siblings). RULED by the founder 2026-09-12
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
refuse — no issue security scheme exists in this Jira site - canon models no issue-level security and every issue in the one project is visible to every member; the LIST is an honest empty at 200, so this replica is plainly allowed to read schemes and an id over that empty collection can only be Jira's own 404. RULED by the founder 2026-09-12
generate — new canon entity Scheme
the status/type/priority/resolution vocabulary the renderer already serves green
the projects the authenticated persona belongs to, ordered by their newest issue activity
generate — new canon entity Scheme
the global-settings flags follow what this universe actually serves (voting, watching, attachments, sub-tasks, time tracking)
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. attachmentsForIssue() and attachmentsForIssueComment() — the files on a Jira ISSUE and on its comments, and only those: the support desk's 35+ files stay unreachable here because listAttachments() is scoped away from the engineering parents and these accessors are scoped away from the desk's. id, filename, author, created, size, mimeType and a content url that resolves; thumbnail only on an image, omitted rather than nulled so no published url dangles
no attachment in this universe is an ARCHIVE - the operation itself declares the empty answer ("if an empty list is returned in the response, the attachment is empty, corrupt, or not an archive") and every canon.AttachmentKind is text a theme can WRITE: a YAML snippet, an SVG, a CSV, a log excerpt, a stack trace and a HAR summary, not one of them a ZIP. So the empty entry list is Jira's own true answer here, carrying the AttachmentMetadata this host publishes beside it. RULED 2026-09-12 (hello-18 wave W-b, autonomous), on the operation's own declared semantics
no attachment in this universe is an ARCHIVE - the operation itself declares the empty answer ("if an empty list is returned in the response, the attachment is empty, corrupt, or not an archive") and every canon.AttachmentKind is text a theme can WRITE: a YAML snippet, an SVG, a CSV, a log excerpt, a stack trace and a HAR summary, not one of them a ZIP. So the empty entry list is Jira's own true answer here, carrying the contents and nothing else, which is the documented difference from the human form. RULED 2026-09-12 (hello-18 wave W-b, autonomous), on the operation's own declared semantics
SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. The bytes themselves: attachment.body, whose size_bytes and sha256 the compiler measured off exactly these bytes and which the conformance entry re-hashes. redirect=false serves them at 200; the default is Jira's 303 to /secure/attachment/{id}/{filename} — Jira's own non-REST download path, the /secure/useravatar precedent, so no endpoint is invented inside /rest/api/ (invariant #2) and the Location resolves (invariant #5)
SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. A SETTING rather than a file, which is why this is the one row of the family that is NOT gated on the generation: enabled reads hasAttachmentParents() — the same fact /rest/api/3/configuration's attachmentsEnabled now reads, so the two routes cannot disagree — and is honestly false on every pin. uploadLimit is Jira Cloud's own fixed 10 MB, the same class of provider constant as the status ids this renderer already carries
SERVED 2026-09-12 (hello-18 wave W-b): the Attachment widening landed with features.attachmentParents (decisions/2026-09-12-1148-hello-18-attachment-parents.md) — six ALTERs appending issue/issue_comment/pull/alert/namespace/person to the hello-15 attachment table, so a file now hangs off the engineering records this host publishes. The image itself: screenshot-svg is the one kind carrying width/height, and an SVG is a vector document, so serving it as its own thumbnail scales to whatever the client renders at and invents no pixel. A file that is NOT an image answers Jira's declared 404 for "the requested thumbnail cannot be downloaded" even with fallbackToDefault=true, because Jira's default thumbnail is Atlassian ARTWORK and this replica reproduces none of it (the same licence finding the system-avatar rows made)
reader.refCatalog("jira.system-avatars") filtered by type, with the four urls composed onto /secure/useravatar?avatarId=&avatarType= (the operation's own example path, which this host already serves) and answered with identiconPng - this universe's own bytes, never Atlassian's artwork. licence: NO GRANT NEEDED — Avatar requires only id in the vendored description and urls are RELATIVE paths on this host, so the BYTES behind them are this universe's own: PersonAvatar has been canon since hello-13 and identiconPng already rasterises byte-identical avatars for GitHub, GitLab, Jira and ADO (packages/conformance/src/parity/avatar-parity.test.ts). Atlassian's artwork is never reproduced. 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)
STALE REASON: the 2026-09-09 ruling deferred this row on "answered with this host's own identicons on hello-16 (refCatalogs, in flight)" and hello-16 landed it — the 32-row `jira.system-avatars` catalog ships from hello-16 on and app.ts already serves the same rows at /rest/api/3/avatar/{type}/system. `system[]` comes off the catalog and `custom[]` is honestly empty: a custom avatar exists only because somebody uploaded a picture and this universe accepts no writes
STALE REASON: the 2026-09-09 ruling deferred this row on "answered with this host's own identicons on hello-16 (refCatalogs, in flight)" and hello-16 landed it — the 32-row `jira.system-avatars` catalog ships from hello-16 on and app.ts already serves the same rows at /rest/api/3/avatar/{type}/system. `system[]` comes off the catalog and `custom[]` is honestly empty: a custom avatar exists only because somebody uploaded a picture and this universe accepts no writes
refuse — these routes return PNG bytes rather than JSON, and the artifact carries no image data for a person or a project
refuse — these routes return PNG bytes rather than JSON, and the artifact carries no image data for a person or a project
refuse — these routes return PNG bytes rather than JSON, and the artifact carries no image data for a person or a project
the field registry in packages/renderer-jira/src/metadata.ts — every field is on every project here
the field registry in packages/renderer-jira/src/metadata.ts
the field registry in packages/renderer-jira/src/metadata.ts
no field has ever been deleted in this universe — the field registry is fixed at compile time and this universe accepts no writes — so the field trash is truthfully an empty page
the field registry in packages/renderer-jira/src/metadata.ts
SERVED 2026-09-10 (hello-16): the role-name → project-role-URL map, over reader.listMembershipRoles() in catalog order. Canon's five MembershipRoleKeys map to Jira's project-role vocabulary in one place (renderer-jira/src/roles.ts). A pre-hello-16 pin answers the named access generation gap (noRoles)
SERVED 2026-09-10 (hello-16): one ProjectRole with THIS project's actors — reader.listMemberships("team", team) filtered to the role and to state=active, because an invitation is not yet an actor. A Jira project is a canonical team here, so the project roster genuinely differs from the site one
SERVED 2026-09-10 (hello-16): ProjectRoleDetails over reader.listMembershipRoles() — the catalog without its actors, which is what this operation is for. `currentMember=true` is honoured against reader.listMemberships("team", team) rather than dropped; `admin` is the role's own team:admin rung
SERVED 2026-09-10 (hello-16): the site-wide role catalog — reader.listMembershipRoles(), each with its DEFAULT actors, which Jira defines as the site-wide assignment a new project starts from and canon holds as reader.listMemberships("org", org). A pre-hello-16 pin answers the named access generation gap (noRoles)
SERVED 2026-09-10 (hello-16): the single read off that same catalog, addressed by the id /rest/api/3/role publishes
SERVED 2026-09-10 (hello-16): the same ProjectRole document /rest/api/3/role/{id} serves — both carry the role's default actors from reader.listMemberships("org", org), which is what the vendored description says each of them is for
the same board/sprint/epic listings agile/1.0 already serves green
the same board/sprint/epic listings agile/1.0 already serves green
no issue and no version in olympus-labs carries a remote link - a remote link is an application link to an object in another Atlassian product and this site has no linked Confluence, no linked Bitbucket and no app; Jira's own answer for an issue with none is [] at 200. RULED by the founder 2026-09-12
SERVED 2026-09-12 (hello-17): one link with BOTH ends named, from canon's issue_link — the entity the 2026-09-01 classification called "the A7 wave's" and hello-17's features.issueLinks delivered. One row per adjacent pair inside one (epic, sprint) group, `blocks` when the earlier issue closed strictly before the later one opened and `relates` otherwise (decisions/2026-09-11-0200-hello-17-review-policy-social-graph-and-issue-links.md). inwardIssue IS THE SOURCE: the vendored IssueLink labels inwardIssue with the type's `inward` string and outwardIssue with its `outward`, and a link renders on one issue by dropping that end — substituting the description's own getIssueLink example (type Duplicate, inwardIssue PR-3, outwardIssue PR-2) that reads "PR-3 Duplicates PR-2" and "PR-2 Duplicated by PR-3", which is the only assignment of the two that says one thing. So the prerequisite is inwardIssue and its successor outwardIssue. Each end carries the four `Fields` this replica can answer from canon (summary, status, priority, issuetype), byte-identical to what /rest/api/3/issue/{key} prints for the same issue. Older artifacts answer the noIssueLinks generation-gap 404 naming generation hello-17 — never Jira's entity 404, which would be an answer about the id where the truth is that the universe has no links to have ids
SERVED 2026-09-12 (hello-17): {issueLinkTypes: [...]}, the two relationships this site defines, id-ordered. TWO AND NOT FOUR: canon's kind vocabulary is closed at blocks|relates|duplicates|parent and this universe writes rows for the first two only — canon marks no duplicate anywhere, and its parentage runs issue -> EPIC, which is not an issue, so a `parent` row would be a reference that does not resolve in the table its column names. A catalogue advertising a type nothing can be is invariant #5 from the other end (the TYPE_DEFS rule renderer-ado takes), so it publishes exactly the kinds canon produces and grows on its own the day canon produces a third. THE VOCABULARY IS JIRA CLOUD'S SHIPPED DEFAULTS, NOT THE DOCUMENT'S EXAMPLE: IssueLinkType declares four strings and no enum, and the description's only concrete vocabulary is an illustrative example on getIssueLinkTypes ({id 1010, inward "Blocked by", name "Blocks", outward "Blocks"}) that no Jira Cloud site actually serves — every Cloud site is created with "blocks"/"is blocked by" and "relates to"/"relates to", which is what a client's UI and a human's JQL meet, so that is what an exact mirror serves. The divergence is recorded in packages/renderer-jira/src/issue-links.ts and in the decision entry. `[]` is not the answer on an older artifact: it would say this SITE defines no link types, a claim about the host (the noRefCatalogs precedent), so those answer the named generation gap
SERVED 2026-09-12 (hello-17): the same catalogue row by id, byte-identical to the one the list publishes — conformance asserts both types both ways. An id the catalogue does not carry is Jira's own 404 and not a coverage miss: the catalogue resolved and this id is not in it. Older artifacts answer the noIssueLinks generation gap, like the list
refuse — no issue and no version in olympus-labs carries a remote link - a remote link is an application link to an object in another Atlassian product and this site has no linked Confluence, no linked Bitbucket and no app, so no link id resolves and Jira's own 404 is the whole answer. RULED by the founder 2026-09-12
refuse — Advanced Roadmaps is a Jira Premium feature this site does not have; all five operations declare a 403 described as "Returned if the site has no premium edition of Jira or if the user does not have the Administer Jira global permission" - the ruled ground verbatim - so Jira answers 403, not 404, to plans reads on a site without the edition (founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-jira-refuse-shapes.md)
refuse — Advanced Roadmaps is a Jira Premium feature this site does not have; all five operations declare a 403 described as "Returned if the site has no premium edition of Jira or if the user does not have the Administer Jira global permission" - the ruled ground verbatim - so Jira answers 403, not 404, to plans reads on a site without the edition (founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-jira-refuse-shapes.md)
refuse — Advanced Roadmaps is a Jira Premium feature this site does not have; all five operations declare a 403 described as "Returned if the site has no premium edition of Jira or if the user does not have the Administer Jira global permission" - the ruled ground verbatim - so Jira answers 403, not 404, to plans reads on a site without the edition (founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-jira-refuse-shapes.md)
refuse — Advanced Roadmaps is a Jira Premium feature this site does not have; all five operations declare a 403 described as "Returned if the site has no premium edition of Jira or if the user does not have the Administer Jira global permission" - the ruled ground verbatim - so Jira answers 403, not 404, to plans reads on a site without the edition (founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-jira-refuse-shapes.md)
refuse — Advanced Roadmaps is a Jira Premium feature this site does not have; all five operations declare a 403 described as "Returned if the site has no premium edition of Jira or if the user does not have the Administer Jira global permission" - the ruled ground verbatim - so Jira answers 403, not 404, to plans reads on a site without the edition (founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-jira-refuse-shapes.md)
no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found", and its answer for an entity that carries none is the empty `{"keys": []}` this operation declares. RULED by the founder 2026-09-12
the same board/sprint/epic listings agile/1.0 already serves green
refuse — no entity in this Jira site carries an app property - entity properties are written only by Connect/Forge apps through the API and olympus-labs installs none, and this universe accepts no writes; Jira's own answer for a property key that is not set is 404 "The property key was not found". RULED by the founder 2026-09-12
the group table the renderer already renders (site group + one per team)
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
nobody in olympus-labs logs time - the generator writes an estimate on an issue (issue.estimate) and never a worklog, so no work log has ever been created, updated or deleted in this universe; Jira's own answer for an issue with none is {"worklogs": [], "total": 0} at 200 and for the updated/deleted feeds an empty values list with the window's until time. RULED by the founder 2026-09-12
nobody in olympus-labs logs time - the generator writes an estimate on an issue (issue.estimate) and never a worklog, so no work log has ever been created, updated or deleted in this universe; Jira's own answer for an issue with none is {"worklogs": [], "total": 0} at 200 and for the updated/deleted feeds an empty values list with the window's until time. RULED by the founder 2026-09-12
nobody in olympus-labs logs time - the generator writes an estimate on an issue (issue.estimate) and never a worklog, so no work log has ever been created, updated or deleted in this universe; Jira's own answer for an issue with none is {"worklogs": [], "total": 0} at 200 and for the updated/deleted feeds an empty values list with the window's until time. RULED by the founder 2026-09-12
refuse — nobody in olympus-labs logs time - the generator writes an estimate on an issue (issue.estimate) and never a worklog, so no work log has ever been created and no worklog id resolves; Jira's own 404 for a worklog that is not found is the whole answer. RULED by the founder 2026-09-12
the field registry in packages/renderer-jira/src/metadata.ts
issue_transition rows plus the six-state workflow vocabulary
refuse — this universe accepts no writes, so no asynchronous job was ever queued and no task id can resolve — Jira's own 404 for an unknown task is the whole answer
the person table — the same users /rest/api/3/user already renders
refuse — no person in olympus-labs has set a Jira user preference - canon records no per-user Jira setting and this universe accepts no writes; the key parameter is required and Jira's own answer for a key the caller has not set is 404 "The preference with the given key does not exist" (/mypreferences/locale stays served: it is the site locale, not a preference). RULED by the founder 2026-09-12
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
the issue table through the covered JQL engine
refuse — Atlassian removed GET /rest/api/3/search (CHANGE-2046) and the renderer already answers 410 Gone — the provider's own refusal, mirrored
time tracking is not in use in this Jira site - no worklog exists and issue.estimate is a story-point estimate rather than a time estimate; Jira's own answer when no time tracking provider is selected is 204 No Content with an empty body. RULED by the founder 2026-09-12
generate — new canon entity Worklog — the time-tracking configuration follows it
generate — new canon entity Worklog — the time-tracking configuration follows it
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity Scheme
generate — new canon entity IssueWatch
generate — new canon entity IssueWatch
the covered JQL grammar and its values
the permission vocabulary /rest/api/3/mypermissions already answers
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
refuse — Jira restricts the webhook registry to the Connect or OAuth 2.0 app that registered the webhooks - the operation returns only the CALLING APP's webhooks - and this replica is called with no app context, so Jira's own 403 for a non-app caller is the whole answer. RULED by the founder 2026-09-12
refuse — Jira restricts the webhook registry to the Connect or OAuth 2.0 app that registered the webhooks - the operation returns only the CALLING APP's webhooks - and this replica is called with no app context, so Jira's own 403 for a non-app caller is the whole answer. RULED by the founder 2026-09-12
refuse — the sandbox token is a project-member token, not a Jira site admin — /rest/api/3/mypermissions already answers ADMINISTER havePermission=false, and real Jira Cloud answers 403 to this route for such a token
generate — A WIDENING, NOT A BUILD: canon.AdminAuditEvent exists (packages/canon/src/support-desk.ts:690) and its own doc comment calls it "GENERIC by construction". The action vocabulary (AuditAction, :602), the change vocabulary (AuditChangeSlot, :633), the target vocabulary (AuditTargetKind, :611) and the RFC 5737 source-address rule (AuditSourceBlock, :652) all shipped, and Zendesk serves the table today (reader.listAuditEvents(), ruled 2026-09-07). TWO things are missing and neither is the entity: git-host members on AuditTargetKind, and a generation that WRITES personActor — the field is declared for exactly this wave and "this generation writes none" (:695-697)
refuse — data classification is an Atlassian Guard / Premium feature this site does not have, and Jira answers 403 to a token without the classification scope
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
the person table — the same users /rest/api/3/user already renders
reader.refCatalog("jira.navigator-columns"); every value is a field /rest/api/3/field already serves. licence: FACTUAL — the response is {label, value} over field ids this host already serves ("issuekey", "summary" in the vendored description's example). 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)
refuse — this universe accepts no writes, so no asynchronous job was ever queued and no task id can resolve — Jira's own 404 for an unknown task is the whole answer
the label table
refuse — this universe accepts no writes, so no asynchronous job was ever queued and no task id can resolve — Jira's own 404 for an unknown task is the whole answer
generate — new canon entity ProjectSetting
generate — new canon entity ProjectSetting
refuse — no Connect or Forge app is installed on this site; these routes are addressed to an installed app's own scope and Jira answers 401/404 to a caller that is not that app
refuse — this universe accepts no writes, so no asynchronous job was ever queued and no task id can resolve — Jira's own 404 for an unknown task is the whole answer
generate — new canon entity Scheme
03 / What's simulated
Every Jira call resolves against the same simulated data set every other provider serves. Counted from the jira-v3-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.
The same issue key and summary, the same story-point estimate, the same changelog instants in the same order, and the same comment count and comment instants as Linear serves for that issue; per team, the board's sprint names and start/end dates equal Linear's cycle names and windows, and a sprint's issue keys equal that cycle's.
Against Linear · parity/tracker-parity.test.ts
The changelog instants for an issue equal the revision instants Azure Boards serves for the same work item, and `customfield_10016` equals its `StoryPoints`.
Against Azure DevOps · parity/tracker-parity.test.ts
The issue at hop 2 of the four-hop walk carries the key and summary the Slack thread opened about, the estimate and status Linear serves, and resolution instants that bracket the GitHub pull request's merge — on the live hosts and on the frozen `-g6` pins.
Against Slack, Linear, GitHub, GitLab · parity/pinned-cross-category.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.
jira-v3.snap.sandboxapis.devgeneration 1v3not in this generationjira-v3-g10.snap.sandboxapis.devgeneration 10v3servedjira-v3-g11.snap.sandboxapis.devgeneration 11v3servedjira-v3-g2.snap.sandboxapis.devgeneration 2v3servedjira-v3-g3.snap.sandboxapis.devgeneration 3v3servedjira-v3-g5.snap.sandboxapis.devgeneration 5v3servedjira-v3-g6.snap.sandboxapis.devgeneration 6v3servedjira-v3-g8.snap.sandboxapis.devgeneration 8v3servedjira-v3-g9.snap.sandboxapis.devgeneration 9v3servedNeed an endpoint that is not served yet?
Every row Jira'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.