Bitbucket

SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` - the same canon GitHub serves as Actions secrets and variables, in Bitbucket's dialect. `secured` IS canon's `masked`, so the two hosts cannot disagree about which of this organization's settings may be published, and `value` is `""` on a secured row because the vendored property description says so in as many words ("If the variable is secured, this will be empty") - canon holds NO value for a masked binding, so the empty string is composed at the boundary from the absence. `deployment_variable` at a deployment ENVIRONMENT, resolved through the same `envUuid` `/environments` publishes - so a uuid read off that list is one this row answers for

SERVED 2026-09-09: reader.listWorkflowSchedules(repo) (packages/artifact/src/reader.ts:2297), rendered as `pipeline_schedule` and validated against the vendored `paginated_pipeline_schedules`. `cron_pattern` is canon's (per_hour, hours_of_day, days_of_week) triple re-encoded as the seven Quartz fields the document asks for — lossless, and the conformance entry re-derives it; `target.ref_name` is the branch canon points at, and the test fetches it back through /refs/branches to prove it resolves (invariant #5). `enabled` is true because every schedule here started real runs. Answers the hello-15 generation gap on an older artifact rather than an empty envelope

SERVED 2026-09-09: reader.runsForSchedule(id) (packages/artifact/src/reader.ts:2839), reading workflow_run.schedule directly, as `pipeline_schedule_execution_executed` — the variant the vendored spec declares, whose only members are the discriminator and `pipeline`. Each pipeline is BYTE-IDENTICAL to what GET /pipelines/{uuid} serves for the same run (the conformance entry fetches it back and compares), and every run it returns carries event `schedule`. The errored variant is never emitted: canon records no schedule that failed to start a pipeline

SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` - the same canon GitHub serves as Actions secrets and variables, in Bitbucket's dialect. `secured` IS canon's `masked`, so the two hosts cannot disagree about which of this organization's settings may be published, and `value` is `""` on a secured row because the vendored property description says so in as many words ("If the variable is secured, this will be empty") - canon holds NO value for a masked binding, so the empty string is composed at the boundary from the absence. Addressed by the `bbUuid` the list publishes, so the id a caller walks to is the id this route accepts. A uuid this repository does not hold is Bitbucket's own 404

the step log has served reader.jobLogText(job) since #311; the row was still `generate` only because no conformance entry drove it

SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` - the same canon GitHub serves as Actions secrets and variables, in Bitbucket's dialect. `secured` IS canon's `masked`, so the two hosts cannot disagree about which of this organization's settings may be published, and `value` is `""` on a secured row because the vendored property description says so in as many words ("If the variable is secured, this will be empty") - canon holds NO value for a masked binding, so the empty string is composed at the boundary from the absence. The legacy team path addresses the WORKSPACE account, which owns every repository in this universe, so it answers `/workspaces/{workspace}/pipelines-config/variables` BYTE-IDENTICALLY through the same closure - the ruling `/teams/{username}/search/code` already set on 2026-09-12, and conformance asserts the two agree rather than letting two paths for one account drift

SERVED 2026-09-12 (hello-19 wave W-a) as Bitbucket's empty page at 200: this path addresses a PERSON, and no person in this universe owns a repository or runs a pipeline of their own - so there is nothing for a person-scoped pipeline variable to configure. The WORKSPACE's variables are deliberately NOT served here; that is what the `/teams/{username}` alias is for, and serving one under the other's name is the confusion the hello-19 seed brief flagged (§G5). UNGATED across generations, for the same reason `/users/{selected_user}/search/code` is: repository ownership is a property of the model rather than of a feature flag

SERVED 2026-09-12 (hello-19 wave W-a): `ci_binding` - the same canon GitHub serves as Actions secrets and variables, in Bitbucket's dialect. `secured` IS canon's `masked`, so the two hosts cannot disagree about which of this organization's settings may be published, and `value` is `""` on a secured row because the vendored property description says so in as many words ("If the variable is secured, this will be empty") - canon holds NO value for a masked binding, so the empty string is composed at the boundary from the absence. Addressed by the uuid the list publishes

generate — new canon entity PipelineSshKey

generate — new canon entity PipelineSshKey

generate — new canon entity ActionsCache

generate — new canon entity Runner

derive — reader.listTestCases(repo) (packages/artifact/src/reader.ts:2308) joined to reader.testResultsForJob(job) (:2320): canon.TestCase (packages/canon/src/ci-config.ts:156) is the DEFINITION and TestResult is this job's run of it. The 2026-09-09 serving wave did NOT build this row, and the reason is a spec gap rather than canon: the vendored swagger declares a 200 with NO content block and NO test_* component for it, and Atlassian publishes no response body for it anywhere a capture could cite. Atlassian's own KB names three summary fields (number_of_test_cases, number_of_failed_test_cases, number_of_successful_test_cases, in a working jq example) and nothing more, so any further field would be invented — which is what invariant #4 forbids and what the DECISIONS §P17 Wave B `shape` pattern requires documented evidence to avoid. The row needs a CAPTURE, not a canon entity

refuse — REFUSED 2026-09-12 (hello-19 wave W-a) with Bitbucket's own 404: no uuid resolves over the empty collection its list half answers - see that row

generate — new canon entity PipelineOidcConfig

generate — new canon entity Runner

SERVED 2026-09-12 (hello-17): one default reviewer, addressed by the account UUID, the Atlassian account id or the nickname — the three spellings this host resolves users by, and the nickname because the parameter is literally named for a username and a client that read one off the list will send it. Somebody who is not on the rule is Bitbucket's own 404, which conformance drives. An artifact that predates the domain answers the hello-17 generation gap: an empty default-reviewer list would say this repository automatically requests nobody, which is a claim about how this team reviews rather than about the snapshot the caller pinned.

SERVED 2026-09-12 (coverage wave W3): the documented 302 to `/file-conflicts/{baseTip}..{head}`. The revspec names the two TIPS and never the merge base, which is the whole judgment on this row: a merge base conflicts with the head on nothing by construction, so a redirect naming it would always answer an empty page. The base tip is the merge commit's first parent on a merged pull and the base branch's head on an open one - the same instant reader.pullDiffRange resolves the base from

refuse — this universe accepts no writes, so no merge was ever queued and no task id relates to this pull request - Bitbucket's own 400 for such a task id is the whole answer (the operation declares 400/403/409 and no 404, and its 400 description IS the ruled condition: "If the provided task ID does not relate to this pull request"; founder ruling 2026-09-03 on proposal 1 of coverage/reviews/2026-09-03-bitbucket-refuse-shapes.md, superseding the 404 read from the Jira async-job precedent)

generate — new canon entity PullTask

SERVED 2026-09-09 (hello-16): the caller's own workspace membership — reader.listMemberships("org", org) (reader.ts:2961) narrowed to whoever GET /user resolves to. `owner` exactly when the role catalog gives that role `org:admin`, which is a rung the ARTIFACT carries rather than a table copied into the renderer; conformance recomputes it. `collaborator` is never produced, because nobody in this universe is outside the workspace — every person carries member = 1 — and Atlassian is removing the role from the API anyway. Conformance asserts this single row is byte-identical to /user/workspaces/{workspace}/permission

SERVED 2026-09-09 (hello-16): the caller's effective workspace role as one `workspace_membership` — reader.membershipFor("org", org, person) (reader.ts:2977), byte-identical to the single row /user/permissions/workspaces returns and asserted so. A workspace slug this host does not serve is the ordinary 404, checked separately from the generation gap so a typo never reads as a missing generation

SERVED 2026-09-12 (hello-18): the same workspace hook by its braced uuid, byte-identical to the row the list publishes. A repository hook's uuid is Bitbucket's 404 here, which conformance drives from both sides. Gated on hasWebhookFilters()

SERVED 2026-09-12 (coverage wave W3): registered beside the green `/workspaces/{workspace}/members` and, like `/user`, never asserted until now: renderMembership over the person a uuid or login names. Conformance asserts the user and workspace it names are the artifact's own

SERVED 2026-09-09 (hello-16): every (person, repository) EFFECTIVE permission in the workspace. Every member appears on every repository and that is not padding — canon's `member` role carries `repo:write` and this workspace owns every repository, so every member really can push to each one; a shorter list would be a different claim. `repo:maintain` collapses UP to Bitbucket's `admin` rather than to `write`, because branch restrictions and repository configuration — what canon's `maintainer` is FOR — are what Bitbucket's admin grants and its write does not; conformance asserts at least one row is therefore HIGHER than the person's org role alone gives, which is what makes canon's repository-scoped memberships visible on this host at all

SERVED 2026-09-12 (coverage wave W3): the ONE project every repository has advertised in its `project` member since wave A, expanded from condensedProject to the full shape. It is deliberately NOT canon's hello-16 `namespace`: repository.project is condensed-project on all 127 registered pins, so a list naming the namespace would not contain the project each repository says it belongs to, and `/projects/{key}/deploy-keys` - green since the hello-15 wave on the condensed key - would answer for a key the list omits. The namespace reaches GitLab as a SUBGROUP, the surface it was modelled for. `description`, `updated_on` and `is_private` are omitted because canon says nothing about any of them

SERVED 2026-09-09 (hello-16): the workspace's system signing key — the `gpg` credential canon puts on the MACHINE ACCOUNT, which the entity itself explains: "a workspace signing key is the ORG's key, not a person's, and the bot is the only principal in this universe that could hold an org-wide one" (packages/canon/src/credentials.ts). It is therefore served HERE and excluded from /users/{selected_user}/gpg-keys, so the workspace's key is never published as somebody's own — conformance asserts both halves. The vendored swagger declares a 200 with NO content block (a documented Bitbucket spec gap), and the operation's own description — "in most cases a single key is returned; during a key rotation period, two keys may be returned" — describes a COLLECTION, so it is this host's ordinary paginated envelope and the shape assertion is the gate. No armored block is served, for the reason /users/{selected_user}/gpg-keys states

SERVED 2026-09-12 (hello-18): Bitbucket's webhook_subscription over canon's webhook_subscription, which hello-18's features.webhookFilters widened from PagerDuty's three account scopes to the three a repository host publishes at — so a repository hook and a workspace hook are ONE object at two scopes, which is exactly why Bitbucket's own subject_type is an enum of those two words. THE EVENT NAMES ARE THIS RENDERER'S TRANSLATION, not canon's: canon's vocabulary is neutral because three renderers read that table, and Bitbucket spells the same six deliveries ref.pushed -> repo:push, change.opened -> pullrequest:created, change.merged -> pullrequest:fulfilled, issue.opened -> issue:created, issue.closed -> issue:updated and build.completed -> repo:commit_status_updated. Two of those needed an argument and both are recorded: Bitbucket publishes no `issue:closed` at all, and closing an issue IS an `issue:updated` in its vocabulary; and a build result on Bitbucket IS a commit status, reported by creating one when the build starts and UPDATING it when it finishes, which is the half canon records. Conformance re-derives the mapping independently of the renderer and asserts every served name is one the vendored enum publishes. `subject` is the condensed repository this host already serves at its own address, so a hook and the thing it is installed on cannot disagree (invariant #5), and conformance asserts the workspace's hook is NOT listed here. `secret_set` is FALSE and is sent, because canon states there is no signing secret; `secret` itself is never sent, which is also what real Bitbucket does. Gated on hasWebhookFilters(); an older artifact answers the named hello-18 webhook gap rather than an empty envelope, because an empty envelope there would say this team wires up nothing

SERVED 2026-09-12 (coverage wave W3): `type` alone, which is the vendored schema's only required member and the whole of what this universe knows. `override_settings` enumerates the settings a repository has taken control of from its project; canon models no per-repository setting at all - every repository reports the same merge strategies and the same branch model because both are derived rather than stored - so there is nothing overridden to enumerate. Sending `{}` would claim the same thing less clearly and inventing booleans for settings canon does not carry is a placeholder

SERVED 2026-09-12 (hello-17): one group's explicit permission on this repository, addressed by the TEAM SLUG this host publishes everywhere else. Re-slugging the team name here would mint a second identity for one team and the two could then disagree, so `slug` is canon's own and `full_slug` is Bitbucket's `workspace:group` form built from the two slugs. hello-17 `grants` (decisions/2026-09-11-2304) lets a Membership name a TEAM as its principal: the team that owns the most components of a repository holds `maintainer` on it and a team that owns none but reviews it holds `member`, with ownership derived from the commit histogram. A Bitbucket GROUP is canon's TEAM on this host, so a group's explicit permission IS a team-principal grant. A slug that names no team, and a team that holds no grant on this repository, are both Bitbucket's own 404 — the rule the user twin follows, because `none` is what a WRITE removes a grant with and not what a read returns for somebody who holds nothing. Conformance drives both negatives. Answers the honest 404 on an artifact with no team grant, because the parent list is empty there and no group_slug resolves

SERVED 2026-09-09 (hello-16): one explicit grant, addressed by the account UUID or Atlassian account id this host already resolves users by — reader.membershipFor("repo", repo, person) (reader.ts:2977). A person with no explicit grant on this repository is Bitbucket's own 404 rather than a `permission: "none"` row: `none` is what a WRITE removes a grant with, and their effective permission is still published by /workspaces/{workspace}/permissions/repositories/{repo_slug}. Conformance asserts both halves against the same artifact

SERVED 2026-09-09 (hello-16): the workspace-scoped replacement Bitbucket points the deprecated /user/permissions/repositories at, and the same effective permissions — this workspace owns every repository the artifact carries, which is a fact about the universe rather than a shortcut: the resolution still goes through the workspace, so a slug that names none 404s. Conformance asserts the two bodies agree

generate — new canon entity Snippet

generate — new canon entity Snippet

generate — new canon entity Snippet

generate — new canon entity Snippet

generate — new canon entity Snippet

generate — new canon entity Snippet

generate — new canon entity RepoSubscription

SERVED 2026-09-12 (coverage wave W3): the paths BOTH sides changed since their merge base, to different content - reader.treeFiles() over the same git blobs `/diff/{spec}` reads. A path one side left alone merges cleanly and a path both sides changed identically merges cleanly, so neither is reported, and `scenario` is delete_modify/modify_delete/content read off which side dropped the file. `message` is omitted: Bitbucket fills it from its merge engine and this host runs none. The 200 is a page envelope with no required member, so a spec whose sides merge cleanly is an honest empty page rather than an invented conflict

SERVED 2026-09-12 (coverage wave W3): a git format-patch series, raw text - the vendored operation declares a 200 with no content at all, so every line is asserted instead: the `From <sha>` lines are reader.commitsOnlyIn(source,destination) in git's own oldest-first order, the `From:`/`Date:`/`Subject:` headers are the commit's own author and instant, and each patch body IS the text `/diff/{sha}` serves for that commit. `Mon Sep 17 00:00:00 2001` is git's fixed mbox sentinel rather than a date, and the `-- <git version>` trailer is omitted because no git produced this patch

SERVED 2026-09-09: reader.listCheckoutKeys(repo) (packages/artifact/src/reader.ts:2351). canon.CheckoutKeyType is literally "deploy-key" (packages/canon/src/ci-config.ts:221); the served `key` and `comment` reassemble CheckoutKeyRow.public_key exactly, and the conformance entry base64-decodes the blob and SHA-256s it back to the artifact's own fingerprint_sha256 — which is what separates a key from a string shaped like one. `last_used` is omitted because canon records no use of any key

SERVED 2026-09-09: the PROJECT-scoped view of the same rows — reader.listCheckoutKeys(repo) over the repositories this workspace's project holds, as `project_deploy_key` (which names its project and, unlike the repository shape, carries no `repository`). The project key is condensedProject's, the same value every repository object has advertised since Wave A, so a caller who read `project.key` off a repository can address this route with it. Answers the hello-15 generation gap on an older artifact

SERVED 2026-09-12 (coverage wave W3): the single-object twin of the list above, resolved by the key every repository publishes (the projectCtx `/projects/{key}/deploy-keys` already uses). Conformance asserts the by-key object is the listed object and that an unknown key is still Bitbucket's 404

NO TEAM HOLDS A GRANT ON THE WORKSPACE'S PROJECT, and this is the NARROWER reason that replaces the 2026-09-10 ruling. That ruling gave two grounds — canon binds a person to a container and never a team to one, and the project (canon's `namespace`) carries no membership row — and hello-17's `grants` makes BOTH false: a team can be a principal, and the subgroup has a roster. What is still true is where canon writes team grants: the rule measures component ownership per REPOSITORY, and the subgroup owns no repository (founder ruling F1, hello-16), so reader.teamGrants("namespace", ns) is genuinely empty. Bitbucket's own answer is the paginated empty page at 200, and it is READ rather than hard-coded — the query is the thing that has to say so. Falsifiable from the side that is left: the conformance entry asserts team grants EXIST in this universe (so the empty is not vacuous) and that none of them scopes to the namespace, and fails the day one does. RULED empty by the hello-17 bitbucket wave, 2026-09-12, superseding the 2026-09-10 ruling on this row

SERVED 2026-09-12 (hello-17): one person's explicit permission on the project, addressed by the account UUID or Atlassian account id this host already resolves users by — reader.namespaceMembers(ns) narrowed to that person. THE hello-16 ASK IS ANSWERED: that wave said the row needed "a namespace-scoped membership, the same canon the GitLab subgroup wave (#431) left open", and hello-17's `grants` writes five. A person who is not on the subgroup's roster is Bitbucket's own 404 rather than a `permission: "none"` row; their workspace standing is still published by /workspaces/{workspace}/permissions, and conformance drives both. Answers the honest 404 on an artifact whose namespace has no member

generate — hello-17's `grants` IS in canon and the REPOSITORY twin went `derive` on 2026-09-12 — but this operation addresses ONE group's permission on the PROJECT, and the project's group list is still empty: canon writes team-principal grants at repository scope only, because the rule measures component ownership and the subgroup owns no repository (founder ruling F1). No `group_slug` can ever return 200, so there is nothing for conformance to validate and the row answers the honest coverage 404 rather than being `empty` itself — a single-object operation has no empty collection to serve. THE ASK: a team-to-container grant at NAMESPACE scope, which needs the subgroup to own a repository. Reported by the 2026-09-12 bitbucket hello-17 serving wave

generate — new canon entity BranchingModel

generate — new canon entity BranchingModel

generate — new canon entity BranchingModel

refuse — no Atlassian Connect app is installed on this workspace; these routes are addressed to an installed app's own key scope and Bitbucket answers 404 to a caller that is not that app (the ruled Jira Connect/Forge precedent, coverage/reviews/2026-09-01-jira-modes.md row 1)

refuse — no Atlassian Connect app is installed on this workspace; these routes are addressed to an installed app's own key scope and Bitbucket answers 404 to a caller that is not that app (the ruled Jira Connect/Forge precedent, coverage/reviews/2026-09-01-jira-modes.md row 1)

generate — new canon entity SecurityFinding

generate — new canon entity SecurityFinding

SERVED 2026-09-09 (hello-16): a person's ACCESS keys — reader.credentialsForPerson(user, "ssh-auth") (reader.ts:3016). Canon's `ssh-signing` rows are deliberately excluded and this host publishes them nowhere: a key authorised to push and a key trusted to attest authorship are different grants (packages/canon/src/credentials.ts), Bitbucket Cloud has one account SSH surface and it is the ACCESS one, and serving a signing key here would assert a grant nobody made. The served `key` and `comment` are a SPLIT of the artifact's single OpenSSH line, so they can never describe different bytes, and conformance re-hashes the served line and asserts it reproduces the artifact's own `fingerprint_sha256` — the check a client runs with `ssh-keygen -lf`

SERVED 2026-09-09 (hello-16): a person's PERSONAL OpenPGP keys — reader.credentialsForPerson(user, "gpg") (reader.ts:3016). `key_id` and `fingerprint` are the artifact's own, and conformance RECOMPUTES the fingerprint from the packet the way GnuPG does (SHA-1 over 0x99‖len‖body) and checks the key id is its last eight bytes. The armored `key` is NOT served: a transferable OpenPGP key needs a user id and a self-signature, a self-signature needs a private half this universe never generated, and the field is opt-in on Bitbucket's own operation — #430's `raw_key: null` reasoning in Bitbucket's spelling, asserted ABSENT rather than left to be noticed. The WORKSPACE key is excluded here and served once at /workspaces/{workspace}/settings/gpg/public-key. `deviation` rather than green: the vendored schema types `parent_fingerprint` `string` while its own description says the value is null unless the key is a subkey, and every key here is a primary key

SERVED 2026-09-12 (coverage wave W3): the route was REGISTERED in wave A and never asserted, which is the whole of this row: renderUser(viewer()), the workspace's founding member. Conformance now asserts it is that person, that `/2.0/users/{uuid}` renders the identical account, and that `/2.0/user/emails` carries the same person's address - the caller-scoped surfaces on this host all report one identity or two of them describe two accounts

SERVED 2026-09-09 (hello-16): one of the caller's addresses by its text, byte-identical to the row the list serves — conformance follows `links.self` from every list row and compares. An address the caller does not hold is Bitbucket's own 404. Same spec gap as the list: no 200 is declared, so the shape assertion is the gate

SERVED 2026-09-12 (coverage wave W3): the legacy team path addresses the WORKSPACE account, which owns every repository in this universe, so it answers `/workspaces/{workspace}/search/code` byte-identically - conformance asserts exactly that, rather than letting two paths for one account drift

SERVED 2026-09-12 (coverage wave W3): a case-insensitive substring match over the same git blobs `src` serves - the honest thing a replica holding the real files can say, and one a caller can reproduce by fetching them. Results are repository-major then path because Bitbucket ranks by relevance and this host cannot, so the same query always paginates identically. `query_substituted` is a knowable false: an unimplemented modifier is an explicit 400 rather than a silent rewrite, and only `repo:`, `project:` and `ext:` are implemented. `content_matches` carries one entry per matching LINE, with segments that reassemble the line exactly, because this host has no context window to claim around a match

generate — new canon entity BranchRestriction

hello-13's Download canon: the newest release publishes a tarball and a .sha256sums, so the download area lists real files with real sizes and download counts

derive

refuse — no Atlassian Connect app is installed on this workspace; these routes are addressed to an installed app's own key scope and Bitbucket answers 404 to a caller that is not that app (the ruled Jira Connect/Forge precedent, coverage/reviews/2026-09-01-jira-modes.md row 1)