Jira

the team table the renderer already renders as projects

no board in this site has a quick filter - a quick filter is a named JQL clause somebody added to a board, canon carries no per-board clause list and this universe records no such act; 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) and RE-WORDED A SECOND TIME 2026-09-14 (hello-20 wave W-jira), the mode unmoved both times. The first re-word moved the sentence off "this universe accepts no writes", which hello-18's savedFilters domain had made false. The second removes the clause it moved ONTO - "a quick filter is part of a board's CONFIGURATION, and canon models none of it" - because hello-20's boards domain lands the COLUMNS half of exactly that list (decisions/2026-09-14-0233): /rest/agile/1.0/board/{boardId}/configuration now publishes a real column layout and a real estimation field, so "canon models none of a board's configuration" is no longer true. The narrower fact is, and it is all this row ever needed: NO QUICK FILTER EXISTS. Trap 30's exact case - a ruling's supporting clause falsified by an unrelated domain landing

canon releases and milestones, projected onto the project as Jira versions

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

refuse — no board in this site has a quick filter - a quick filter is a named JQL clause somebody added to a board and canon carries no per-board clause list, 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) and RE-WORDED A SECOND TIME 2026-09-14 (hello-20 wave W-jira), the mode unmoved both times, for the reason the list half's own entry gives: hello-20's boards domain lands the columns half of the board CONFIGURATION this ruling used to rest on, and the narrower fact - no quick filter exists - is the one that survives it

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

the two custom fields (customfield_10016 story points, customfield_10020 sprint) and their single global context

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 two custom fields (customfield_10016 story points, customfield_10020 sprint) and their single global context

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover. THE VENDORED $ref IS ATLASSIAN'S OWN BUG AND THIS ROW SERVES THE READ SHAPE INSTEAD: the operation declares PageBeanFieldConfigurationDetails, whose element component has two properties and marks BOTH writeOnly true (it is the body a CREATE takes) and carries no id, while the operation's own 200 EXAMPLE shows {id, name, description, isDefault} - which is FieldConfiguration. Serving the write DTO would publish a configuration a caller cannot then address at /fieldconfiguration/{id}/fields, which is invariant #5 broken by transcription, so conformance validates the values against FieldConfiguration and the envelope by hand

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

the six-state workflow the renderer already serves, plus the issue_transition canon that walks it

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira) RATHER THAN RULED, and the ruling's own fact is the answer: nobody in olympus-labs changed the workflow editor (batch F1, ruling group R8), so it is the one a Jira Cloud site is created with - NEW, one of the two members the response's own enum has. No UserPreference entity is needed for a preference nobody set

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

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 — RULED 2026-09-14 (hello-20 wave W-jira, AUTONOMOUS - the direct corollary of founder ruling F5 rather than a new claim about this universe): no workflow scheme in this site has a draft. A draft workflow scheme exists only as the copy Jira makes while somebody EDITS an active scheme, and olympus-labs uses Jira's defaults and has edited nothing; three of the four draft operations declare that exact condition in as many words ("the original active workflow scheme does not have a draft"). The scheme ITSELF is served at /rest/api/3/workflowscheme/{id} by the same wave, and this row is parent-guarded on it, so a ruling about a draft is only ever given about a scheme this site really has

refuse — RULED 2026-09-14 (hello-20 wave W-jira, AUTONOMOUS - the direct corollary of founder ruling F5 rather than a new claim about this universe): no workflow scheme in this site has a draft. A draft workflow scheme exists only as the copy Jira makes while somebody EDITS an active scheme, and olympus-labs uses Jira's defaults and has edited nothing; three of the four draft operations declare that exact condition in as many words ("the original active workflow scheme does not have a draft"). The scheme ITSELF is served at /rest/api/3/workflowscheme/{id} by the same wave, and this row is parent-guarded on it, so a ruling about a draft is only ever given about a scheme this site really has

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 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

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 deployment's own terminal state in canon — a deployment that ran was allowed through

the git canon — repositories, branches, commits and pull requests

generate — tier and componentType now have a source (canon Service.tier maps to Tier 1..3, and every canon service is componentType Service), but avatarUrl and description still have none: this Jira host serves a project component with only its name and assignee type, never a description, and serves avatars only for users and projects, never for a service, so answering would invent both; re-checked 2026-10-27

refuse — no DevOps or Security workspace is linked to this site - a linked workspace exists only because an Atlassian app connected a provider's workspace to the site, olympus-labs installs no Connect or Forge app (the ruled 2026-09-01 class this host already refuses fourteen rows on) and this universe accepts no writes. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8) AS AN HONEST EMPTY, AND SERVED AS A REFUSAL INSTEAD, on the vendored document rather than on a second opinion: both stores declare minItems 1 on workspaceIds, so an empty list fails the operation's own 200 schema and "there are none" is not a sentence either API can say. The 404 both declare - "No data found for the given workspace ID" - is the answer that is left, and it is the same one their by-id twin gives, in the same bare-array-of-{message} envelope renderer-jira/src/ops.ts has sent on /rest/operations/1.0/incidents/{incidentId} since wave W4. The fact the founder ruled did not move; only the shape it can be said in did

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 — no DevOps or Security workspace is linked to this site (see /rest/security/1.0/linkedWorkspaces, which answers the honest empty), so no workspace id resolves and the store's own answer is the 404 it declares - "No data found for the given workspace ID". RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8). THE ENVELOPE IS THIS FAMILY'S OWN, a bare array of {message} rather than the platform's {errorMessages, errors}: renderer-jira/src/ops.ts has sent exactly that shape on /rest/operations/1.0/incidents/{incidentId} since wave W4

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)

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

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

scratch — ACCEPTED into the per-key 24-hour overlay for a scratch-enabled key: Jira's bare 204, after which the issue's `status` (and its `statusCategory`), `resolutiondate` and `updated` read from the overlay's latest transition for this key, and `GET …/transitions` offers the moves out of the NEW state - so a client walking the workflow continues from its own last move. The transition must be one the six-state workflow allows from the state this key sees (`issueTransitions`, the same list the GET serves); any other id is Jira's own 400 (`Transition id 'X' is not valid for this issue.`), and a body without `transition.id` is Jira's own 400 (`Missing 'transition' identifier`). `fields` and `update` are REFUSED with Jira's own 400 (`Field 'x' cannot be set. It is not on the appropriate screen, or unknown.`) because every transition here carries no screen (`hasScreen: false`) - a 204 that silently ignored a `resolution` would hand back a transition the caller believes set one (invariant #4). The merged state reaches every surface that reads it: the issue bean, the agile and software issue listings, an epic's `done` flag, a version's unresolved count and the bulk-transition offer. The changelog (inline, dedicated and bulk) and JQL do NOT merge in this phase and say so with `X-SandboxAPIs-Scratch: unmerged`. Past the key's row cap or the per-project cap is Jira's documented 413. Without a scratch-enabled key this path is the read-only 403, byte for byte.

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, 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)

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

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

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, and NEITHER PARENT THESE FOUR HANG UNDER EXISTS AT ALL: nobody has built a dashboard to hold a dashboard ITEM, and nobody in olympus-labs logs time, so no worklog has ever been created. That is why both halves of both pairs refuse rather than splitting the way wave W4's seven property pairs did: the split rule (decisions/2026-09-12-0348) requires the parent to RESOLVE, an empty key list here would assert that a dashboard item or a worklog exists and holds nothing, and Jira's own answer for the missing parent is its 404. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8)

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover. THE ONE ROUTE IN THE FAMILY THAT IS A SUBTRACTION, and it is what says the screen is a fold rather than a copy of the field registry: the fields that can be ADDED are the registry minus the ones the screen carries, which is the five this host COMPUTES (status, created, updated, resolutiondate, project) - a create screen offering to set an issue's created date is not a thing Jira has ever shown

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

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

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 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. 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. 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

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

nobody in olympus-labs has built a dashboard - a dashboard is a layout somebody arranged for themselves, this universe records no such act and accepts no writes, and the gadget catalogue a dashboard is built out of is Connect/Forge app modules on a site that installs none (the ruled 2026-09-01 class this host already refuses fourteen rows on); Jira's own answer for a site with none is an empty page at 200. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8) - the identical ruling sentry's dashboard rows took on 2026-09-12

nobody in olympus-labs has built a dashboard - a dashboard is a layout somebody arranged for themselves, this universe records no such act and accepts no writes, and the gadget catalogue a dashboard is built out of is Connect/Forge app modules on a site that installs none (the ruled 2026-09-01 class this host already refuses fourteen rows on); Jira's own answer for a site with none is an empty page at 200. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8) - the identical ruling sentry's dashboard rows took on 2026-09-12

refuse — no entity in this Jira site carries an app property, and NEITHER PARENT THESE FOUR HANG UNDER EXISTS AT ALL: nobody has built a dashboard to hold a dashboard ITEM, and nobody in olympus-labs logs time, so no worklog has ever been created. That is why both halves of both pairs refuse rather than splitting the way wave W4's seven property pairs did: the split rule (decisions/2026-09-12-0348) requires the parent to RESOLVE, an empty key list here would assert that a dashboard item or a worklog exists and holds nothing, and Jira's own answer for the missing parent is its 404. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8)

refuse — nobody in olympus-labs has built a dashboard - a dashboard is a layout somebody arranged for themselves and this universe records no such act, so no dashboard id resolves and Jira's own answer is the 404 these operations declare. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8). The LIST half is the honest empty at /rest/api/3/dashboard

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover. THE CLIQUE'S ONE TIER-1 ROW: a project's notification scheme is the site default, because F5 says there is one of each kind and it binds everything

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

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 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. 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

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

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

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

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): 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 single read off that same catalog, addressed by the id /rest/api/3/role publishes

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): {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 no `issue_link` row says `parent`: until hello-23 canon's parentage ran issue -> EPIC only, which is not an issue, and hello-23's issue-to-issue parentage is a table of its own (`issue_parent`) rather than link rows, with Jira left unchanged by founder ruling F2b (re-worded 2026-10-27, decisions/2026-10-27-2222). 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

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)

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

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

the field registry in packages/renderer-jira/src/metadata.ts

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

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

SERVED 2026-09-14 (hello-20 wave W-jira) RATHER THAN RULED (batch F1, ruling group R8, "nobody logged time"): these are the SHARED time-tracking settings, which exist whether or not the feature is turned on, and TimeTrackingConfiguration requires all four of them - so an empty answer is not available and the honest one is the value a site nobody configured has: an eight-hour day, a five-day week, the pretty format and the minute as the unit a bare number is read in. A vendor constant of the class /rest/api/3/priority is already served from. The sibling /rest/api/3/configuration/timetracking still answers 204 "time tracking is disabled", and conformance asserts that it does

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover

SERVED 2026-09-14 (hello-20 wave W-jira) AND IT COST NO CANON AT ALL - the row moves from generate to derive with no IssueWatch entity anywhere, which decisions/2026-09-14-0315-hello-20-watch-graph.md calls "the Jira pair that needed no canon at all". An issue's WATCHERS are its own participants (Jira adds you to that list when you report an issue, are assigned it or comment on it), which is reader.issueWatchers() - a fold over issue, issue_assignee and issue_comment; an issue's VOTES are the thumbs-up reactions content_reaction has carried since hello-16, already reachable through reactionsFor("issue", id) with no new accessor. Storing either would be storing a join. DELIBERATELY UNGATED: both read tables every registered pin already carries, so a hello-20 gate here would withhold a true answer from all of them

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 — 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-14 (hello-20 wave W-jira). A WIDENING, AND THE TWO THINGS THE OLD REASON SAID WERE MISSING ARE BOTH PRESENT NOW: features.auditActor appends the git-host members to AuditTargetKind and writes admin_audit_event rows whose actor is a PERSON on the engineering roster - 91 of them at 90 d - into the table hello-15 created (decisions/2026-09-14-0144-hello-20-audit-actor.md). Every instant and every actor is read off a row that already existed: the organization's own creation, a team's earliest membership, a repository's first commit author, a membership's own addedBy, a protected ref's container, a credential's owner. THE RENDERER READS listPersonAuditEvents() AND NEVER THE BARE listAuditEvents(), which defaults to the support desk's register - a Jira host calling the bare one would publish a Zendesk instance's account audit log on an Atlassian surface. Gated on features.auditActor (hello-20+)

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

refuse — no project in olympus-labs has a sender email address configured - a project's sender address is set by an administrator in the project's own settings, this universe records no such act and accepts no writes; Jira's own answer for a project with none is the 404 this operation declares in as many words ("the project or project's sender email address is not found"). RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8). PARENT-GUARDED on the project through Atlassian's THIRD spelling of that path parameter ({projectId}), so a ruling about an address is only ever given about a project this site has

no project in this site carries a project FEATURE - project features are the per-project toggles a TEAM-MANAGED (next-gen) project has, and every project this host serves is company-managed: /rest/api/3/project/{projectIdOrKey} already publishes style "classic" and simplified false, so an ENABLED feature here would contradict what the project object says about itself one route over. Jira's own answer for a project with none is an empty features list at 200. RULED BY THE FOUNDER 2026-09-14 (batch F1, ruling group R8)

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

SERVED 2026-09-14 (hello-20 wave W-jira): canon.Scheme, canon.SchemeBinding and canon.ScreenField landed with features.jiraSchemes (decisions/2026-09-14-0218-hello-20-jira-schemes.md) - ten default configuration objects, every name ATLASSIAN'S own product label carried in canon rather than in a theme pack, and what each binds is what this host already answers: the workflow from /rest/api/3/workflow/search, the field registry from /rest/api/3/field, the permission vocabulary from /rest/api/3/permissions, the priority ladder from /rest/api/3/priority, the issue types from /rest/api/3/issuetype and the roles from /rest/api/3/role. FOUNDER RULING F5 (2026-09-14): "olympus-labs uses Jira's defaults - one scheme of each kind, the site default, binding everything". A DEFAULT SCHEME BINDS NOTHING PER ISSUE TYPE, which is the finding a re-derivation is most likely to get wrong: /workflowscheme/{id}/workflow answers issueTypes [] with defaultMapping true, and the two scheme families that name a catch-all spell its issue type the literal "default". Gated on features.jiraSchemes (hello-20+); every artifact before it answers the named scheme generation gap, which is what the 127 pins frozen before hello-20 serve, and what the live host served until the cutover