feat(jira): read a ticket and its comments from Jira Cloud

docs/plan.md

@@ -61,8 +61,8 @@ The first milestone is a walking skeleton (`skeleton`): one feature on a throwaw
 | `gates` | The repo's gate, a new setting: the user's command that checks the repo's code, which the engineer's handover, QA's approval and the lead's final report run in the feature's worktree, and which refuses the handover while it fails; `baton start` and `baton feature start` refuse a repo without one, and the guard denies a role's `create` and `edit` in baton's config folder (decision 56, risk 13) | Done (#38) |
 | `adf` | `internal/adf`: the Atlassian Document Format, the JSON of a Jira ticket's description and comments, as Markdown to read: the walk over a document's nodes, and the inline text, with its marks, mentions, emoji, dates, cards and attachments; a node without a rule of its own shows its content, or the text that stands in for it (decision 57, fact 39) | Done (#39) |
 | `adf-blocks` | `internal/adf`'s blocks: headings, lists and task lists, code blocks, quotes and panels, rules, tables and expands (decision 57) | Done (#40) |
-| `jira-text` | `internal/jira`'s ticket: the fields of a Jira ticket that baton shows, as Jira's REST API gives them, and the ticket as Markdown to read: its key and summary, type, status and parent, then its description, subtasks, links and comments (decision 58, fact 40) | In review (#41) |
-| `jira-client` | `internal/jira`'s client: a ticket and all its comments from Jira Cloud's REST API, through Atlassian's gateway with the user's email and scoped token, and the site's cloud ID from the site (decision 6, fact 13) | Todo |
+| `jira-text` | `internal/jira`'s ticket: the fields of a Jira ticket that baton shows, as Jira's REST API gives them, and the ticket as Markdown to read: its key and summary, type, status and parent, then its description, subtasks, links and comments (decision 58, fact 40) | Done (#41) |
+| `jira-client` | `internal/jira`'s client: a ticket and all its comments from Jira Cloud's REST API, through Atlassian's gateway with the user's email and scoped token, and the site's cloud ID from the site, which gets neither (decision 59, facts 13 and 41) | In review (#42) |
 | `jira` | `baton jira <KEY>`: the ticket as text, in the orchestrator's pane, with Jira's site and email from the config file and the read-only token from the Keychain (decision 6) | Todo |
 | `deliver-github` | `baton deliver` for GitHub: push the branch and open the pull request with `gh`, the lead's final report as its body | Todo |
 | `close` | `baton feature close <slug>`: ends the feature's session; keeps its branch and, unless asked, its worktree | Todo |
@@ -140,6 +140,7 @@ Checked on 2026-10-31 with Copilot CLI 1.0.105 and tmux 3.8, unless a fact says
 38. **What makes git's pushes and gh fail** (git 2.56.0, gh 2.103.2 and Copilot CLI 1.0.105, on 2026-11-04, in throwaway folders, against `.invalid` hosts and local paths). git reads the settings that `GIT_CONFIG_COUNT` counts in `GIT_CONFIG_KEY_<n>` and `GIT_CONFIG_VALUE_<n>` after its config files, and those of `git -c` after them; it reads the count as C's `strtoul` does, so it takes ` 1` and `+1`, and fails with 128 on `x`, and on `-1` (`too many entries`). A push to a remote's URL takes the `url.<base>.pushInsteadOf` rule whose prefix matches the most of the URL, and of equal ones the rule whose base git read first, or else an `insteadOf` rule; a remote's push URL (`remote.<name>.pushurl`) skips the `pushInsteadOf` rules, but not the `insteadOf` ones. Since git 2.46 (its release notes), an empty `pushurl` clears the remote's push URLs that git read before it, so its pushes go to its URL; an older git takes it for one more push URL, and still pushes to the others. git takes a URL for a path on the machine when it has no colon, or a slash before its first colon, or starts with `file://`; `https://…`, `ssh://…`, `git@host:repo`, `host:repo` and `[::1]:repo` leave the machine. A push to `<helper>::<url>`, whose remote helper `git-remote-<helper>` isn't there, fails with 128 and `git: 'remote-<helper>' is not a git command`, before any network. `git send-pack` takes its URL as it is, with no rule: it went on to look the host up. `git config --get-regexp` exits with 1 when no setting matches. Copilot's `bash` tool adds three settings of its own after those that it inherits, `safe.bareRepository=explicit`, `credential.interactive=never` and `core.fsmonitor=false`, and raises `GIT_CONFIG_COUNT` to match; it keeps `GIT_CONFIG_PARAMETERS`, and reads `BASH_ENV` only with its `bashEnv` setting, off by default, which `--bash-env` saves in the user's config (`copilot help config`). With `GH_CONFIG_DIR` under a file, such as `/dev/null/x`, every `gh` command, `--version` and `auth` too, fails before it starts, with 1 and `failed to create root command: failed to read configuration: open /dev/null/x/config.yml: not a directory`, and writes nothing; with an empty folder, gh still takes the user's login from the Keychain (gh's source). Copilot CLI takes its GitHub token from `COPILOT_GITHUB_TOKEN`, then `GH_TOKEN`, then `GITHUB_TOKEN`, then its own login, which `copilot login` keeps in the Keychain, and last from `gh auth token` (`copilot help environment`, and GitHub's docs on its authentication). The belt (decision 55) was checked with `baton feature start` on a tmux server of its own, with a stand-in `copilot`, and once with the real one, offline (`COPILOT_OFFLINE`) with a stand-in model on 127.0.0.1, for 0 AI credits. In the lead's pane, pushes to `origin`, whose push URL the belt had cleared, and to typed `https` and scp-like URLs failed, pushes to a local remote and to a typed path went through, `gh --version` failed, and copilot's `bash` added its three settings after the belt's; the orchestrator's pane kept `GH_TOKEN`.
 39. **The Atlassian Document Format** (Atlassian's docs, and its `@atlaskit/adf-schema` and `@atlaskit/editor-common` packages on npm, on 2026-11-04). Jira's REST API v3 gives a ticket's description and comments as ADF: a JSON tree of nodes, each with a `type`, and as the type needs, `content`, `attrs`, `text` and `marks`. ADF's JSON schema lists ten inline nodes, which flow in a line of text: `text`, `date`, `emoji`, `hardBreak`, `inlineCard`, `mention`, `placeholder`, `status`, `inlineExtension` and `mediaInline`; the rest are blocks. A task item, a decision item and a media's caption hold inline nodes as they are, not in a paragraph, and a task list holds task items, block task items and task lists. A `date`'s `timestamp` is a string of milliseconds since the epoch, which Atlassian's own renderer shows as the day in UTC (`timestampToIsoFormat`), though the docs' example, `1582152559`, reads as seconds. A `mention`, a `status` and an extension carry their text in `attrs.text`, an `emoji` in `attrs.text` or `attrs.shortName`, a card its address in `attrs.url`, and a `media` its alternative text in `attrs.alt`, and an external one its address in `attrs.url`.
 40. **A ticket in Jira's REST API v3** (Jira Cloud's OpenAPI spec and the API's introduction, on 2026-11-04). `GET /rest/api/3/issue/<KEY>` gives the ticket's `key`, and the `fields` that its `fields` parameter names, comma-separated. A ticket's `issuetype` and `status` each hold a `name`, and its `issuelinks` hold each link's `type`, with the text for either side, such as `is blocked by` (`inward`) and `blocks` (`outward`), and the other ticket, as `inwardIssue` or `outwardIssue`, with its `key` and its `fields`, `summary` and `status` among them. The spec gives no shape for the `parent` and `subtasks` fields, which Jira's clients read as such tickets too, with a key and fields (ankitpokhrel/jira-cli's types). `GET /rest/api/3/issue/<KEY>/comment` gives a page of comments, with `startAt`, `maxResults`, 100 by default, and `total`, which can change between pages, so that a page can come empty; `orderBy=created` gives them oldest first. A comment holds its `author`, with a `displayName`, its `body` in ADF, and `created`, an ISO 8601 time in the site's time zone, such as `2021-01-17T12:34:00.000+0000`. `encoding/json/v2` matches names by their case, so baton spells Jira's: `issuetype` and `issuelinks`, not the `issueType` and `issueLinks` of some clients, which `encoding/json` matches whatever the case.
+41. **A site's cloud ID** (Atlassian's support article on finding a site's cloud ID, on 2026-11-04). `https://<site>.atlassian.net/_edge/tenant_info` gives the site's cloud ID, which the gateway's addresses hold (fact 13), as one line of JSON, `{"cloudId":"<cloud ID>"}`. The article has it opened in a browser, and doesn't say whether a site answers without a login: baton sends none, which a first live check of Jira will show to work, or not.
 
 ## 3. Design
 
@@ -219,7 +220,7 @@ Every change takes an exclusive lock on the feature (`flock` on its `lock` file,
 }
 ```
 
-**Jira** (decisions 6, 57 and 58). `baton jira DEMO-1` prints the ticket as Markdown: its key, summary, type, status and parent, then its description (the Atlassian Document Format turned into Markdown by `internal/adf`), subtasks, links and comments. It reads the token from the Keychain with `/usr/bin/security`, and the site's `cloudId` from the site.
+**Jira** (decisions 6, 57, 58 and 59). `baton jira DEMO-1` prints the ticket as Markdown: its key, summary, type, status and parent, then its description (the Atlassian Document Format turned into Markdown by `internal/adf`), subtasks, links and comments. It reads the token from the Keychain with `/usr/bin/security`, and the site's cloud ID from the site, without a login, so that the token goes to Atlassian's gateway alone.
 
 **Delivery.** `baton deliver <slug>` pushes the branch and opens the pull request against the base branch, titled from the brief, with the lead's final report as its body: on GitHub with `gh pr create`, on Bitbucket Cloud with its REST API and a token from the Keychain. It never merges.
 
@@ -287,6 +288,7 @@ Decisions marked **lead's call** are the lead's, for the user's end review. The
 56. **A repo's gate checks the code before each handover that vouches for it** (lead's call, flagged; the user's call, 2026-11-04, for its `//nolint:gosec`; decisions 13, 34, 49 and 52, fact 16, risk 13). The config file's `gate`, a setting like the others (decision 49), is the user's command that checks the repo's code, such as `mise run check`. The engineer's handover, QA's approval and the lead's final report run it, since each of these roles vouches for the code that it hands on; the rejections, the reviewer's approval, which follows QA's on the same code, the lead's brief and the orchestrator's moves don't. baton reads the gate at each of these handovers, for the repo of the role's folder, and runs it with `/bin/sh -c` in the feature's worktree, wherever in the repo the role runs baton, with baton's environment, the belt's in a role's pane (decision 55), nothing on its input, and its output and its errors on baton's output, in order, after a line that names the gate and the folder, so the role reads what failed. It runs once baton has checked the move and the role's open question on the feature as it stands, so a move that baton refuses runs no gate, and without the feature's lock, so that the other roles' `baton wait` and `baton status` don't wait for it; baton checks the move again under the lock when it writes the handover. A gate that fails refuses the handover, which changes nothing: the role fixes what failed, or, for QA, rejects with the failures. The journal logs the gate that a handover ran, with the handover. The gate has no time limit, since a check can take minutes; Ctrl-C or a hangup stops it, as it stops baton (decision 42): baton kills the gate's shell, and Ctrl-C reaches the commands that the shell started too, but a signal to baton alone leaves them to run to their end. Every repo needs a gate, so that none is forgotten: `baton start`, when it makes the orchestrator's session, and `baton feature start` refuse a repo without one, and say where to set it; `"gate": "true"` checks nothing, for a repo that has no checks. A gated handover refuses too, if the user takes the gate out while a feature runs; the others still go. The config file refuses a gate that is only spaces, and one that starts with `-`, which `sh -c` reads as its own options (bash, dash and zsh all do). The gate is a command line by design, the user's own, from the config file, which only the user writes, so its one place to run carries `//nolint:gosec` for G204, with its reason; decision 34's reason, arguments that no shell reads, doesn't fit it. The guard denies a role's `create` and `edit` in baton's config folder (decision 52), so a role's file tools can't change the gate, and a config folder that isn't there holds nothing, as no feature runs without the file; a role's `bash` still can, and a role can weaken the checks that the gate runs from inside the repo, such as its `mise.toml` (risk 13). Rejected: running the gate in the role's working folder, which may be any folder of the repo; a time limit, which would fail a slow but sound check; a repo without a gate, which would make the gate easy to forget; and gating QA's rejection, which reports a failure rather than vouching for the code.
 57. **A ticket's text as Markdown, through `internal/adf`** (lead's call, flagged; decision 6, fact 39). `internal/adf` renders a ticket's ADF as Markdown for the orchestrator and the user to read, which takes far fewer tokens than the JSON, and which nobody needs to render: so the text stays as Jira has it, with no escapes, but for a `|` in a table's cell. Strong, em, strike, code and links show as Markdown's marks, code innermost and a link outermost, and the other marks, such as underline and colours, leave the text plain; code that holds backticks gets a longer fence. A mention, an emoji, a status, a card and an extension show their text or their address, a date its day in UTC, as Jira shows it, and a file or an image `[attachment]`, with its alternative text or its address, since text can't show it (fact 39). A node without a rule of its own, such as one that a later ADF adds, shows its content, or the text that stands in for it, so that each of a ticket's words reaches the orchestrator; a run of inline nodes in a block makes a paragraph. The blocks keep their shape. A heading keeps its level, from 1 to 6. Lists keep their nesting, and an item's blocks stand on the lines under its marker; a task shows as `- [ ]` or `- [x]`, and a decision as a bullet. A code block keeps its language, in a fence that its code can't end. A quote and a panel show as a quote, without the panel's kind, a rule as `---`, and an expand, which Jira shows folded, as its title in bold above its content. A table becomes a Markdown table: its first row is the header, since a Markdown table needs one; each row is as wide as the widest; and each cell stays on one line, with `<br>` for a line break and `\|` for a `|`. The converter came to about 240 lines, so it came in two steps, `adf`, the walk and the inline text, and `adf-blocks`, the blocks' structure, ahead of `jira`, so that each stays near 150 lines. Rejected: handing the orchestrator the ADF itself, which costs it many more tokens to read.
 58. **A ticket as Markdown, with what the orchestrator plans from** (lead's call, flagged; decisions 6 and 57, fact 40). `internal/jira` gives the orchestrator a ticket as Markdown, as `internal/adf` gives its text: the key and the summary as its title; its type, its status and its parent, if it has one, in a list; then its description, its subtasks, its links and its comments, oldest first, each under a heading of its own, and a part that the ticket lacks not at all, heading and all. A subtask, a link's other ticket and the parent show their key, summary and status, and a link its type from the ticket's side, such as `blocks DEMO-4` or `is blocked by DEMO-5`. A comment's heading names its author, or `Someone` when Jira names nobody, and its time as Jira gives it. Left out for now: the people on the ticket, its priority, labels and sprint, which a plan rarely needs, and a site's own fields, such as acceptance criteria, whose IDs differ from site to site, so that a setting would have to name them. Jira's part came in three steps, `jira-text`, `jira-client` and `jira`, so that each stays near 150 lines.
+59. **The token goes to Atlassian's gateway alone** (lead's call, flagged; decision 6, facts 13, 40 and 41). `internal/jira`'s client reads the site's cloud ID from the site's `tenant_info` without a login, takes it only as a UUID, in its usual form, and sends the user's email and token to `api.atlassian.com` alone, so that a wrong site in the config gets no token. It takes a ticket's key in any case, but only as a project's key, a dash and a number, which it sends in capitals, as Jira's keys are, so that a key can't change the address. It asks Jira for the fields that baton shows alone, and reads the comments oldest first, a page at a time, until it has as many as Jira counts, or a page comes empty. It reads at most 16 MiB of an answer. When Jira refuses, the error gives the status and the messages that the answer holds, Jira's `errorMessages` or the gateway's `message`, or the status alone for an answer that isn't JSON, such as a proxy's page. Rejected: the cloud ID in the config file, which the user would have to look up; the first page of comments alone, which would leave out the latest of a long discussion.
 
 ## 5. Risks
 
@@ -314,5 +316,5 @@ Decisions marked **lead's call** are the lead's, for the user's end review. The
 - Copilot CLI: `copilot --help` and `copilot help config|environment|permissions|sandbox` (1.0.105); the hooks reference, the plugins overview, the CLI plugin reference, the custom agents reference and the CLI's authentication page on docs.github.com; the Agent Plugins 1.0.0 schema at agent-plugins.org; the `agent-wake` spike (facts 3 to 10); the `live-run` step (facts 26 to 30).
 - git's manual and its 2.46 release notes, and gh's source, v2.103.2 (fact 38).
 - tmux 3.8 manual and its `spawn.c`; [tmux/tmux-builds](https://github.com/tmux/tmux-builds); GitHub's [runner images](https://github.com/actions/runner-images).
-- Jira Cloud REST API v3 (its OpenAPI spec and its introduction, on 2026-11-04) and Bitbucket Cloud REST API 2.0 reference; ankitpokhrel/jira-cli's types (fact 40).
+- Jira Cloud REST API v3 (its OpenAPI spec and its introduction, on 2026-11-04), Atlassian's support article "How to Find Your Atlassian Cloud Site's Cloud ID" (fact 41) and Bitbucket Cloud REST API 2.0 reference; ankitpokhrel/jira-cli's types (fact 40).
 - Bakhyard's AGENTS.md (the pipeline baton runs), nudge (this repo's rules, CI and gates), zeroshot (ideas only, fact 16).