Bitbucket client handle + the `request` seam every atlassian.bitbucket.*
endpoint namespace is built on.

Bitbucket Cloud is a separate Atlassian service from Jira/Confluence: it lives
on a fixed host (https://api.bitbucket.org/2.0) and uses its own credentials
(see `atlassian.config/bitbucket-config`). Most resources are workspace- and
repository-scoped, so endpoint functions take `workspace` and `repo_slug` as
positional arguments and pass them in a path RELATIVE to the single API root:

  (require '[atlassian.bitbucket.client :as bitbucket])
  (def c (bitbucket/client))
  (bitbucket/request c {:method :get :path "/repositories/your-workspace"})
  (bitbucket/request c {:method :get
                        :path   "/repositories/your-workspace/your-repo/pullrequests"
                        :query  {:state "OPEN" :pagelen 25}})

There is a single API surface, so — unlike the Jira/Confluence clients — there
is NO `:api` routing key.

Pagination differs from Jira and Confluence. List responses are
`{:values [...] :page N :pagelen N :size N :next "<full-url>" :previous "<full-url>"}`.
The `:next` link is a COMPLETE absolute URL (not a cursor), so paging fetches it
directly; `next-url` extracts it and `request-url` fetches an absolute URL.

Bitbucket Commits API — endpoint fns over atlassian.bitbucket.client/request.

Bitbucket Deployments API: deploy keys, deployments, and environments.

Bitbucket Cloud Issue Tracker endpoint functions.

All operations are workspace- and repository-scoped. Every function takes
a `client` handle (from `atlassian.bitbucket.client/client`) as its first
argument, followed by required path params, then an optional `body` (for
write ops) and an optional `opts` map for query params.

Pagination: list responses return `{:values [...] :next "<full-url>" ...}`.
Pass `:page`, `:pagelen`, `:q`, `:sort`, `:fields` in `opts`; follow `:next`
via `atlassian.bitbucket.client/request-url`.

Bitbucket Pipelines API — CI/CD pipeline management, configuration, runners,
variables, SSH keys, caches, and OIDC identity.

Bitbucket Cloud Projects API — workspace-scoped project management.
All fns delegate to `atlassian.bitbucket.client/request`; no network is
touched at load time. Pagination responses include :values, :page, :pagelen,
:size, :next, :previous — follow :next via `bitbucket/request-url`.

Bitbucket Cloud pull-requests API endpoint functions.

All functions take a `client` (from `atlassian.bitbucket.client/client`) as
their first argument, followed by required path params positionally, then an
optional `body` (for write ops) and/or an `opts` map for query params.

Pagination: list endpoints return `{:values [...] :next "<full-url>" ...}`.
Pass `page`, `pagelen`, `q`, `sort`, `fields` in opts; follow `:next` via
`atlassian.bitbucket.client/request-url`.

Bitbucket refs, branch-restrictions, and branching-model endpoint functions.

Covers:
  - Branch restrictions  (/repositories/{workspace}/{repo_slug}/branch-restrictions)
  - Branching model      (/repositories/{workspace}/{repo_slug}/branching-model)
  - Refs / branches / tags (/repositories/{workspace}/{repo_slug}/refs/...)
  - Project branching model (/workspaces/{workspace}/projects/{project_key}/branching-model)

Every fn delegates to `atlassian.bitbucket.client/request`. There is a single
API surface — no :api key is used. Paginated list responses return
{:values [...] :next "<full-url>" ...}; follow :next via
`atlassian.bitbucket.client/request-url`.

Bitbucket Cloud Repositories API — repository management, downloads, forks,
permission configs, and watchers over the single Bitbucket API surface.

All fns take a `client` (from `atlassian.bitbucket.client/client`) as the
first argument. List endpoints return paginated responses of the shape
`{:values [...] :page N :pagelen N :size N :next "<full-url>" :previous "<full-url>"}`.

Bitbucket Search API — code search across teams, users, and workspaces.
All functions are GETs; pagination follows the standard Bitbucket pattern
({:values [...] :next "<full-url>" ...}). Pass query params via opts.

Bitbucket Snippets API — create, read, update, delete, and inspect snippets,
their comments, commits, diffs, and watchers.

Bitbucket Cloud Source / repository file-content endpoints.

All functions take a `client` handle (from `atlassian.bitbucket.client/client`)
as their first argument, then the required path params, then an optional `opts`
map for query params.

Pagination: list responses carry {:values [...] :next "<full-url>" ...}.
Follow :next with `atlassian.bitbucket.client/request-url`.

Bitbucket Users, GPG keys, and SSH keys endpoint functions.

Bitbucket webhooks API — subscription and event-type management.

All functions take a `client` as their first argument (from
`atlassian.bitbucket.client/client`). Path params are positional; query
params and optional options go in a trailing `opts` map (default `{}`).
Write operations accept a `body` map before the opts map.

Pagination: list responses return `{:values [...] :next "<full-url>" ...}`.
Pass `:page`, `:pagelen`, `:q`, `:sort`, `:fields` in `opts`; follow
`:next` via `atlassian.bitbucket.client/request-url`.

Bitbucket Cloud Workspaces API endpoints.

Generic Atlassian HTTP core — the ONLY namespace that touches the network.

Built on hato (an idiomatic Clojure wrapper over the JDK 11 java.net.http
client). This is a small, generic request engine, NOT a function-per-endpoint
wrapper: product surfaces (atlassian.jira.*, atlassian.bitbucket.*,
atlassian.confluence.*) build their typed functions on top of `request`.

A client handle is a plain map:

  {:http <hato client>   ; shared, reusable connection pool
   :auth "Basic ..."     ; Authorization header value
   :config {...}}         ; the resolving config (bases, product, etc.)

Tests never need this: they call the product functions with a stub `request`
fn, so nothing here requires live credentials to exercise.

Configuration + auth resolution for the Atlassian Cloud APIs.

Pure where it matters: this namespace reads environment variables (and an
optional local, gitignored `.env`) into compact config maps and reports
whether auth is ready WITHOUT making any network call. URL bases and the
Authorization header are constructed here so the HTTP layer stays a dumb
transport.

No secrets are ever written to tracked files. `.env` is gitignored.

Confluence client handle + the `request` seam every atlassian.confluence.*
endpoint namespace is built on.

Confluence Cloud exposes two REST surfaces on the same site, both authed with
the same API token as Jira (Basic email:token):

  :v2  (default)  -> /wiki/api/v2   modern, cursor-paginated, recommended
  :v1             -> /wiki/rest/api  legacy, still supported, has CQL search etc.

Endpoint namespaces are split by version (atlassian.confluence.v2.* and
atlassian.confluence.v1.*) and never build URLs themselves — they call
`request` with a path RELATIVE to the chosen API root:

  (require '[atlassian.confluence.client :as confluence])
  (def c (confluence/client))
  (confluence/request c {:method :get :path "/pages" :query {:limit 25}})          ; v2
  (confluence/request c {:api :v1 :method :get :path "/search" :query {:cql "type=page"}})

Pagination: v2 returns `{:results [...] :_links {:next "/wiki/api/v2/...?cursor=..."}}`.
Pass the `cursor` query param from the next link to page; `next-cursor` extracts it.

Confluence v1 admin endpoints: analytics, audit, long-running tasks,
relations, settings (look-and-feel, themes), space labels/themes, and templates.

Confluence v1 Content API — archive, blueprint, search, macro, permissions, versions, and body conversion.

Confluence v1 content-children / descendants / attachment operations.
All fns delegate to `atlassian.confluence.client/request` with :api :v1.

Confluence Cloud v1 Content Restrictions API.

Manage read/update restrictions on content by operation, group, and user.
All list endpoints accept an optional `expand` query param.

Confluence v1 Content States API endpoint functions.

Confluence v1 Content Watches API — watch status and watcher management
for pages, spaces, labels, and content.

Confluence v1 label endpoints: add/remove content labels, query label info.

Confluence v1 Search API — CQL-based search for content and users.

Confluence v1 Spaces API — create, update, delete spaces and manage space permissions/settings.

Confluence v1 Users and Groups API — groups, group members, users, and user properties.

Confluence v2 Attachment endpoints.

Confluence v2 blog-post endpoints.

Classification level operations for Confluence Cloud v2.

Confluence Cloud v2 Comments API — footer and inline comments.

Cursor-paginated list endpoints return {:results [...] :_links {:next ...}}.
Page with the `cursor` query param; use `atlassian.confluence.client/next-cursor`
to extract the cursor from a response.

Comment bodies use storage representation:
  {:body {:representation "storage" :value "<p>Hello</p>"}}

Confluence Cloud v2 Content Properties API.
Cursor-paginated list responses include :results and :_links {:next ...};
page with the `cursor` query param.

Confluence v2 Custom Content endpoint fns — one per operationId in v2-custom-content.edn.

Confluence v2 hierarchy endpoints: ancestors, descendants, children, and
direct-children for pages, databases, folders, whiteboards, smart links,
and custom content.

All list responses are cursor-paginated: {:results [...] :_links {:next ...}}.
Page with the `cursor` query param; use `atlassian.confluence.client/next-cursor`
to extract it from a response.

Confluence v2 Label endpoint fns — one per operationId in v2-labels.edn.

Miscellaneous Confluence v2 endpoints: admin key, likes, operations,
redactions, tasks, user access, and bulk user lookup.

Confluence Cloud v2 Pages API.

Cursor-paginated list endpoints return {:results [...] :_links {:next ...}}.
Page with the `cursor` query param; use `atlassian.confluence.client/next-cursor`
to extract the cursor from a response.

Page/blogpost bodies use storage representation:
  {:body {:representation "storage" :value "<p>Hello</p>"}}

Confluence v2 Space endpoint fns — one per operationId in v2-spaces.edn.

Confluence v2 Version endpoints — one fn per operation.

Atlassian Document Format (ADF) helpers.

Jira Cloud v3 takes and returns rich text as ADF — a nested JSON document
tree, not a string. Two directions live here:

 - `adf->text`  : best-effort flatten an ADF value to compact plain text for
                  reading (lossy: tables/media/mentions collapse to text).
 - `doc` / `text->adf` / `paragraph` : build minimal valid ADF documents for
                  write paths (create issue description, add comment, etc.).

Full-fidelity ADF is always reachable by passing your own document map to the
endpoint functions; these helpers just cover the common cases.

Jira Cloud Issue Attachments API endpoints.

All fns take a `client` (built with `atlassian.jira.client/client`) as their
first argument. Path params follow as positional args. Query params and
request body are passed via an optional trailing `opts` map.

Jira Cloud bulk issue operations.

All functions delegate to `atlassian.jira.client/request`. Build a client
with `(atlassian.jira.client/client)` and pass it as the first argument.

Write operations accept a `body` map and an optional `opts` map for query
params. Read operations accept an optional `opts` map.

Jira client handle + the `request` seam every atlassian.jira.* endpoint
namespace is built on.

A Jira client is an `atlassian.client` handle whose `:config` is a Jira config
map (see `atlassian.config/jira-config`). Build one from the environment with
`(client)`, or pass an explicit config to `(client cfg)`.

Endpoint namespaces never build URLs themselves — they call `request` with a
path RELATIVE to the API root and an optional `:api` selecting which Jira REST
surface to hit:

  (require '[atlassian.jira.client :as jira])
  (def c (jira/client))
  (jira/request c {:method :get :path "/issue/ABC-123"
                   :query {:fields "summary,status"}})

  ;; agile board endpoint:
  (jira/request c {:api :agile :method :get :path "/board"})

`:api` is one of :platform (default, /rest/api/3), :agile (/rest/agile/1.0),
or :software (/rest/software/1.0).

Jira Cloud issue comments and comment properties.

Covers two tag groups from the Jira Platform v3 REST API:
  - Issue comments      (/rest/api/3/issue/{issueIdOrKey}/comment, /rest/api/3/comment/list)
  - Issue comment properties (/rest/api/3/comment/{commentId}/properties/...)

Comment bodies are Atlassian Document Format (ADF). Use
`atlassian.jira.adf/text->adf` to build a valid body from plain text.

Jira Cloud Dashboard endpoints.

All functions take a client (built via `atlassian.jira.client/client`) as
their first arg and delegate to `atlassian.jira.client/request`.

Jira field configuration and field scheme endpoints.

Covers two API surface areas:
  - Field schemes      (/rest/api/3/config/fieldschemes/*)
  - Issue field configs (/rest/api/3/fieldconfiguration* and
                         /rest/api/3/fieldconfigurationscheme*)

All issue-field-configuration ops are marked DEPRECATED by Atlassian; they
still work and are included in full.

Jira Cloud REST API — Issue fields, custom field contexts, and custom field
options endpoint functions.

Every function delegates to `atlassian.jira.client/request`. Build a client
with `(atlassian.jira.client/client)` and pass it as the first argument.

Jira Cloud Filters + Filter Sharing API.

One public function per operation in /rest/api/3/filter. Build a client with
`atlassian.jira.client/client`, then call any function here with it as the
first argument.

Jira Cloud Issue Properties and Issue Type Properties endpoints.

Covers both issue-level and issue-type-level entity property CRUD, plus bulk
set/delete operations. All fns delegate to `atlassian.jira.client/request`.

Jira Issues API — one public fn per operation in the Issues group.

All fns take a `client` (built via `atlassian.jira.client/client`) as the
first arg, then required path params, then an optional `opts` map for query
params and/or a `body` map for write operations.

Description/comment fields that accept rich text expect ADF documents.
Use `atlassian.jira.adf/text->adf` to build one from a plain string.

Jira Cloud issue types, issue type schemes, and issue type screen schemes.

Covers:
 - Issue types       (/rest/api/3/issuetype)
 - Issue type schemes (/rest/api/3/issuetypescheme)
 - Issue type screen schemes (/rest/api/3/issuetypescreenscheme)

Jira issue links and remote issue links endpoints.

Covers three groups of operations:
  - Issue remote links  (/rest/api/3/issue/{issueIdOrKey}/remotelink)
  - Issue links         (/rest/api/3/issueLink)
  - Issue link types    (/rest/api/3/issueLinkType)

Miscellaneous Jira Cloud REST API endpoints.

Covers: announcement banners, application properties, application roles,
audit records, avatars, global configuration, Jira expressions, license
metrics, labels, preferences, redaction, server info, tasks, and webhooks.

Jira notification scheme endpoints.

Covers the /rest/api/3/notificationscheme surface: listing, creating,
updating, and deleting notification schemes, and managing individual
notifications within a scheme.

Jira Cloud permissions, permission schemes, and issue security schemes.

Covers:
 - /mypermissions, /permissions — current-user and all permissions
 - /permissionscheme — CRUD on permission schemes and grants
 - /issuesecurityschemes — CRUD on issue security schemes, levels, and members
 - /project/{id}/permissionscheme, /project/{id}/securitylevel — project-scoped ops

Jira Plans (Advanced Roadmaps) endpoint functions.

Covers plan lifecycle (create, get, update, archive, trash, duplicate) and
team membership within a plan (Atlassian teams and plan-only teams).

All functions take a client built with `atlassian.jira.client/client` as the
first argument.

Jira Cloud endpoints for issue priorities, priority schemes, issue
resolutions, and statuses.

All functions delegate to `atlassian.jira.client/request` and take a client
handle as their first argument (build one with `atlassian.jira.client/client`).

Jira Cloud Project Roles and Project Role Actors endpoints.

Covers the /rest/api/3/project/{projectIdOrKey}/role* and /rest/api/3/role*
surfaces for managing project roles, their members (actors), and global
default actors.

Jira Cloud project, component, version, category, and project-template endpoints.

One public fn per operation defined in resources/openapi/groups/projects.edn.
All functions delegate to `atlassian.jira.client/request`.

Jira Cloud screens, screen tabs, screen tab fields, and screen schemes.

Jira search and JQL endpoint functions.

Covers issue search, JQL autocomplete, JQL parsing/sanitization, and issue
navigator column settings from the Jira Cloud Platform REST API v3.

Jira Cloud Users, User Search, User Properties, and Groups endpoints.

One public fn per operation in resources/openapi/groups/users.edn. All fns
delegate to `atlassian.jira.client/request`.

Jira Cloud endpoint functions for issue watchers and votes.

Covers the Issue watchers and Issue votes API surfaces:
  - bulk-is-watching         POST /rest/api/3/issue/watching
  - get-votes                GET  /rest/api/3/issue/{issueIdOrKey}/votes
  - add-vote                 POST /rest/api/3/issue/{issueIdOrKey}/votes
  - remove-vote              DELETE /rest/api/3/issue/{issueIdOrKey}/votes
  - get-issue-watchers       GET  /rest/api/3/issue/{issueIdOrKey}/watchers
  - add-watcher              POST /rest/api/3/issue/{issueIdOrKey}/watchers
  - remove-watcher           DELETE /rest/api/3/issue/{issueIdOrKey}/watchers

Jira Cloud workflow, workflow-scheme, status, and status-category endpoints.

All functions take a `client` (from `atlassian.jira.client/client`) as their
first argument. Optional query params are passed via the trailing `opts` map.

Jira Cloud worklog, time-tracking, and worklog-property endpoint functions.

Covers:
 - Issue worklogs (CRUD, bulk delete/move, list by ID)
 - Worklog change feeds (deleted/updated since)
 - Time tracking configuration
 - Worklog entity properties

Every function takes a `client` built by `atlassian.jira.client/client` as
its first argument. Required path params follow; an optional `opts` map (query
params) or a `body` map (request body) trail at the end per the contract.