From 91e9616decc799824af5401225aa52a806d75b05 Mon Sep 17 00:00:00 2001 From: Bakhomious Basta Date: Wed, 4 Nov 2026 21:04:51 +0100 Subject: [PATCH] feat(jira): show a ticket as Markdown internal/jira gets a ticket's fields as Jira's REST API v3 gives them, and renders the ticket as Markdown for the orchestrator to read: its key and summary, type, status and parent, then its description, subtasks, links and comments, each under its own heading, and nothing for a part that the ticket lacks (decision 58, fact 40). The plan splits the jira step in three: jira-text, jira-client and jira. --- docs/plan.md | 12 +- internal/jira/testdata/DEMO-1.comments.json | 38 ++++++ internal/jira/testdata/DEMO-1.json | 87 +++++++++++++ internal/jira/testdata/DEMO-1.md | 34 +++++ internal/jira/testdata/DEMO-6.comments.json | 1 + internal/jira/testdata/DEMO-6.json | 12 ++ internal/jira/testdata/DEMO-6.md | 4 + internal/jira/ticket.go | 130 ++++++++++++++++++++ internal/jira/ticket_test.go | 61 +++++++++ 9 files changed, 375 insertions(+), 4 deletions(-) create mode 100644 internal/jira/testdata/DEMO-1.comments.json create mode 100644 internal/jira/testdata/DEMO-1.json create mode 100644 internal/jira/testdata/DEMO-1.md create mode 100644 internal/jira/testdata/DEMO-6.comments.json create mode 100644 internal/jira/testdata/DEMO-6.json create mode 100644 internal/jira/testdata/DEMO-6.md create mode 100644 internal/jira/ticket.go create mode 100644 internal/jira/ticket_test.go diff --git a/docs/plan.md b/docs/plan.md index 5cfde2a..3e8ef44 100644 --- a/docs/plan.md +++ b/docs/plan.md @@ -60,8 +60,10 @@ The first milestone is a walking skeleton (`skeleton`): one feature on a throwaw | `belt` | Risk 2's second belt, in a role's pane: settings in the environment of the role's `copilot`, which each command and script there inherits, so that git's pushes out of the machine fail, sent by `pushInsteadOf` rules to a remote helper that doesn't exist, with a rule for each remote's URL and the remotes' push URLs cleared, and `gh` fails, its config folder under `/dev/null`; the pane goes without the GitHub tokens of the user's environment, and `copilot` gets `GH_TOKEN`'s or `GITHUB_TOKEN`'s as `COPILOT_GITHUB_TOKEN`, for its own login (decision 55, fact 38, risk 2) | Done (#37) | | `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) | In review (#40) | -| `jira` | `baton jira `: the ticket as text, from Jira's REST API with a read-only token in the Keychain (decision 6) | Todo | +| `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` | `baton jira `: 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 `: ends the feature's session; keeps its branch and, unless asked, its worktree | Todo | | `deliver-bitbucket` | `baton deliver` for Bitbucket Cloud: push the branch and open the pull request with the REST API, a token in the Keychain | Todo | @@ -137,6 +139,7 @@ Checked on 2026-10-31 with Copilot CLI 1.0.105 and tmux 3.8, unless a fact says 37. **The user's answer to a `preToolUse` hook's `ask`** (Copilot CLI 1.0.105, on 2026-11-03, checked live). In an interactive session under `--allow-all`, the answer `{"permissionDecision":"ask","permissionDecisionReason":…}` holds the tool and shows the "Hook permission request" of fact 4 in the pane: the reason, the tool's name and its arguments as JSON, and "Do you want to allow this tool call?". Yes runs the tool; No is a field for what the agent should do instead, which does nothing while it's empty. After a No, the agent gets `Denied by user via preToolUse hook prompt: ` with the reason, and `The user provided the following feedback: ` with the text; copilot puts a full stop after the reason, so a reason that ends in one shows two. The input's `sessionId` is the name of the session's folder in `$COPILOT_HOME/session-state/`. Without `COPILOT_ALLOW_ALL`, the folder-trust question still shows under `--allow-all` (fact 9), and the footer shows `Allow All`, where fact 27's showed `Manual Approval`. The live check ran the orchestrator's pane with Claude Haiku 5.5, the plugin of `guard-orchestrator` and a throwaway `COPILOT_HOME`, in a throwaway repo without a remote, on a tmux server of its own, for 0.32 AI credits: the guard asked about `git push --dry-run`, which the check declined with feedback, and about `baton feature start`, which it allowed, and whose script ran but failed with `baton: command not found`, since baton wasn't on the live pane's `PATH`; a `create` in the session's `files/` folder ran, and one in the repo was denied. 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_` and `GIT_CONFIG_VALUE_` 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..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..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 `::`, whose remote helper `git-remote-` isn't there, fails with 128 and `git: 'remote-' 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/` 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//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. ## 3. Design @@ -216,7 +219,7 @@ Every change takes an exclusive lock on the feature (`flock` on its `lock` file, } ``` -**Jira** (decisions 6 and 57). `baton jira DEMO-1` prints the ticket's summary, type, status, 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 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. **Delivery.** `baton deliver ` 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. @@ -283,6 +286,7 @@ Decisions marked **lead's call** are the lead's, for the user's end review. The 55. **A role's pane runs with a second belt** (the user's call, 2026-11-04, for the git and `gh` parts; lead's call, flagged, for the rest; decisions 9, 17, 52 and 54, facts 28 and 38, risk 2). The guard sees only what a command shows (risk 2), so `baton pane` gives a role's `copilot` settings in its environment, which each command and script that the role runs inherits, whatever runs it, and which make git's pushes out of the machine and `gh` fail. For git, after the settings that `GIT_CONFIG_COUNT` counts in baton's own environment, which it keeps, it adds a `pushInsteadOf` rule for each character that starts a URL that leaves the machine, a letter, a digit or `[`, which sends the push to `baton-blocks-push::`, a remote helper that doesn't exist, so that git fails before any network and names baton's belt; a rule that keeps `file://` URLs as they are; and, for the remotes in git's config for the repo, the user's own config included, as the pane finds them when it starts, a rule for each remote's URL that leaves, which beats the user's own rules for a shorter prefix, and an empty `pushurl` for each remote with a push URL that leaves, which clears its push URLs, so that its pushes go to its URL. A git before 2.46, which can't clear them, gets an `insteadOf` rule for each such push URL instead, which also blocks fetches from the URLs that start with it (fact 38). Pushes to a path on the machine, `file://` URLs among them, still work, and fetches, pulls and clones don't change. For `gh`, `GH_CONFIG_DIR` names a folder under `/dev/null`, so that every `gh` command fails before it starts and never reaches the user's login in the Keychain, as it would with an empty folder (fact 38). The pane goes without `GH_TOKEN`, `GITHUB_TOKEN`, `GH_ENTERPRISE_TOKEN` and `GITHUB_ENTERPRISE_TOKEN`, which other tools would use; but `copilot` takes its own login from `GH_TOKEN` or `GITHUB_TOKEN`, or, after its own login, from `gh` (fact 38), so it gets the first of the two that is set as `COPILOT_GITHUB_TOKEN`, unless that is set already, and a user whose `copilot` logs in only through `gh` runs `copilot login` once (README). `baton pane` makes the belt before it waits, and fails when it can't: when git can't read the repo's config or its own version, or when `GIT_CONFIG_COUNT` is a count that git reads but Go doesn't, such as ` 1`, since baton can't tell then where to put its settings. The orchestrator's pane goes without the belt, since the user approves its outward actions there (decision 54). The costs: a push to a relative path that starts with a letter or a digit, such as `git push backup.git`, fails too, as does one to a git server on the machine by its URL, such as `http://localhost/…`; and the roles lose `gh`'s reads, which their prompts don't ask for. Like the guard, the belt stops a role's mistakes, and what the guard can't see, not a role that sets out to get past it (risk 2). Rejected: an empty `GH_CONFIG_DIR` folder, which leaves `gh` the user's login in the Keychain; `BASH_ENV`, which `copilot` reads only with a setting of the user's (fact 38); `copilot`'s deny rules, which match the command that the bash tool runs, as the guard does, not what it runs in turn (fact 28); and `copilot`'s command sandbox, whose policy, such as whether commands reach the network, lives in the user's settings, which each of their `copilot` sessions shares (risk 2). 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 `
` 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. ## 5. Risks @@ -310,5 +314,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 and Bitbucket Cloud REST API 2.0 reference. +- 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). - Bakhyard's AGENTS.md (the pipeline baton runs), nudge (this repo's rules, CI and gates), zeroshot (ideas only, fact 16). diff --git a/internal/jira/testdata/DEMO-1.comments.json b/internal/jira/testdata/DEMO-1.comments.json new file mode 100644 index 0000000..1746bba --- /dev/null +++ b/internal/jira/testdata/DEMO-1.comments.json @@ -0,0 +1,38 @@ +{ + "comments": [ + { + "id": "30001", + "author": {"accountId": "000000:00000000-0000-0000-0000-000000000001", "displayName": "Ann Example", "active": true}, + "body": { + "type": "doc", + "version": 1, + "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Which browsers do we support?"}]}] + }, + "created": "2026-10-30T09:15:00.000+0100", + "updated": "2026-10-30T09:15:00.000+0100", + "jsdPublic": true + }, + { + "id": "30002", + "body": { + "type": "doc", + "version": 1, + "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Safari, Chrome and Firefox."}]}] + }, + "created": "2026-10-30T10:02:11.000+0100", + "updated": "2026-10-30T10:02:11.000+0100", + "jsdPublic": true + }, + { + "id": "30003", + "author": {"accountId": "000000:00000000-0000-0000-0000-000000000002", "displayName": "Bo Example", "active": true}, + "body": {"type": "doc", "version": 1, "content": []}, + "created": "2026-10-31T08:00:00.000+0100", + "updated": "2026-10-31T08:00:00.000+0100", + "jsdPublic": true + } + ], + "maxResults": 100, + "startAt": 0, + "total": 3 +} diff --git a/internal/jira/testdata/DEMO-1.json b/internal/jira/testdata/DEMO-1.json new file mode 100644 index 0000000..8c6a8af --- /dev/null +++ b/internal/jira/testdata/DEMO-1.json @@ -0,0 +1,87 @@ +{ + "expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations", + "id": "10001", + "self": "https://api.atlassian.com/ex/jira/0f1e2d3c-4b5a-4987-8a6b-5c4d3e2f1a0b/rest/api/3/issue/10001", + "key": "DEMO-1", + "fields": { + "summary": "Let users sign in with a passkey", + "issuetype": {"id": "10004", "name": "Story", "subtask": false, "hierarchyLevel": 0}, + "status": { + "id": "3", + "name": "In Progress", + "statusCategory": {"id": 4, "key": "indeterminate", "name": "In Progress"} + }, + "parent": { + "id": "10010", + "key": "DEMO-10", + "fields": { + "summary": "Sign-in without passwords", + "status": {"id": "3", "name": "In Progress"}, + "issuetype": {"id": "10000", "name": "Epic", "hierarchyLevel": 1} + } + }, + "description": { + "type": "doc", + "version": 1, + "content": [ + { + "type": "paragraph", + "content": [ + {"type": "text", "text": "Users sign in with a "}, + {"type": "text", "text": "passkey", "marks": [{"type": "strong"}]}, + {"type": "text", "text": " instead of a password."} + ] + }, + { + "type": "bulletList", + "content": [ + { + "type": "listItem", + "content": [ + {"type": "paragraph", "content": [{"type": "text", "text": "Offer a passkey after sign-in"}]} + ] + }, + { + "type": "listItem", + "content": [ + {"type": "paragraph", "content": [{"type": "text", "text": "Keep the password as a fallback"}]} + ] + } + ] + } + ] + }, + "subtasks": [ + { + "id": "10002", + "key": "DEMO-2", + "fields": {"summary": "Store the passkeys", "status": {"name": "To Do"}, "issuetype": {"name": "Subtask"}} + }, + { + "id": "10003", + "key": "DEMO-3", + "fields": {"summary": "Show the passkey prompt", "status": {"name": "Done"}, "issuetype": {"name": "Subtask"}} + } + ], + "issuelinks": [ + { + "id": "20001", + "type": {"id": "10000", "name": "Blocks", "inward": "is blocked by", "outward": "blocks"}, + "outwardIssue": { + "id": "10004", + "key": "DEMO-4", + "fields": {"summary": "Retire the passwords", "status": {"name": "To Do"}} + } + }, + { + "id": "20002", + "type": {"id": "10000", "name": "Blocks", "inward": "is blocked by", "outward": "blocks"}, + "inwardIssue": { + "id": "10005", + "key": "DEMO-5", + "fields": {"summary": "Pick a passkey library", "status": {"name": "Done"}} + } + } + ] + } +} diff --git a/internal/jira/testdata/DEMO-1.md b/internal/jira/testdata/DEMO-1.md new file mode 100644 index 0000000..794d7ca --- /dev/null +++ b/internal/jira/testdata/DEMO-1.md @@ -0,0 +1,34 @@ +# DEMO-1: Let users sign in with a passkey + +- Type: Story +- Status: In Progress +- Parent: DEMO-10: Sign-in without passwords (In Progress) + +## Description + +Users sign in with a **passkey** instead of a password. + +- Offer a passkey after sign-in +- Keep the password as a fallback + +## Subtasks + +- DEMO-2: Store the passkeys (To Do) +- DEMO-3: Show the passkey prompt (Done) + +## Links + +- blocks DEMO-4: Retire the passwords (To Do) +- is blocked by DEMO-5: Pick a passkey library (Done) + +## Comments + +### Ann Example, 2026-10-30T09:15:00.000+0100 + +Which browsers do we support? + +### Someone, 2026-10-30T10:02:11.000+0100 + +Safari, Chrome and Firefox. + +### Bo Example, 2026-10-31T08:00:00.000+0100 diff --git a/internal/jira/testdata/DEMO-6.comments.json b/internal/jira/testdata/DEMO-6.comments.json new file mode 100644 index 0000000..161f6f4 --- /dev/null +++ b/internal/jira/testdata/DEMO-6.comments.json @@ -0,0 +1 @@ +{"comments": [], "maxResults": 100, "startAt": 0, "total": 0} diff --git a/internal/jira/testdata/DEMO-6.json b/internal/jira/testdata/DEMO-6.json new file mode 100644 index 0000000..7876cb0 --- /dev/null +++ b/internal/jira/testdata/DEMO-6.json @@ -0,0 +1,12 @@ +{ + "id": "10006", + "key": "DEMO-6", + "fields": { + "summary": "Tidy the README", + "issuetype": {"name": "Task"}, + "status": {"name": "To Do"}, + "description": null, + "subtasks": [], + "issuelinks": [] + } +} diff --git a/internal/jira/testdata/DEMO-6.md b/internal/jira/testdata/DEMO-6.md new file mode 100644 index 0000000..e423a6b --- /dev/null +++ b/internal/jira/testdata/DEMO-6.md @@ -0,0 +1,4 @@ +# DEMO-6: Tidy the README + +- Type: Task +- Status: To Do diff --git a/internal/jira/ticket.go b/internal/jira/ticket.go new file mode 100644 index 0000000..43c2f5f --- /dev/null +++ b/internal/jira/ticket.go @@ -0,0 +1,130 @@ +// Package jira reads a Jira Cloud ticket, which the orchestrator plans from, and gives it as +// Markdown to read (decisions 6 and 58). +package jira + +import ( + "cmp" + "slices" + "strings" + + "github.com/codedogapp/baton/internal/adf" +) + +// Ticket is a ticket as Jira's REST API gives it, with the fields that baton shows, and its +// comments, oldest first. +type Ticket struct { + Key string `json:"key"` + Fields Fields `json:"fields"` + Comments []Comment `json:"-"` +} + +// Fields are the fields of a ticket that baton shows. +type Fields struct { + Summary string `json:"summary"` + Type Named `json:"issuetype"` + Status Named `json:"status"` + Parent Issue `json:"parent"` + Description adf.Node `json:"description"` + Subtasks []Issue `json:"subtasks"` + Links []Link `json:"issuelinks"` +} + +// Named is a type or a status, which a ticket shows by its name. +type Named struct { + Name string `json:"name"` +} + +// Issue is another ticket that a ticket names, such as its parent or a subtask. +type Issue struct { + Key string `json:"key"` + Fields struct { + Summary string `json:"summary"` + Status Named `json:"status"` + } `json:"fields"` +} + +// Link links a ticket with another, its inward or its outward ticket, and its type says how, from +// the ticket's side: such as "blocks" for its outward ticket, and "is blocked by" for its inward. +type Link struct { + Type struct { + Inward string `json:"inward"` + Outward string `json:"outward"` + } `json:"type"` + Inward Issue `json:"inwardIssue"` + Outward Issue `json:"outwardIssue"` +} + +// Comment is a comment on a ticket: who wrote it, when, as Jira gives the time, and its text. +type Comment struct { + Author struct { + Name string `json:"displayName"` + } `json:"author"` + Created string `json:"created"` + Body adf.Node `json:"body"` +} + +// Markdown renders the ticket as Markdown to read: its key and summary, its type, status and +// parent, then its description, subtasks, links and comments, each under its heading. A part that +// the ticket lacks shows nothing, not even its heading. +func (t Ticket) Markdown() string { + fields := t.Fields + + about := "- Type: " + fields.Type.Name + "\n- Status: " + fields.Status.Name + if fields.Parent.Key != "" { + about += "\n- Parent: " + fields.Parent.line() + } + + comments := make([]string, len(t.Comments)) + for i, comment := range t.Comments { + author := cmp.Or(comment.Author.Name, "Someone") + comments[i] = join("### "+author+", "+comment.Created, adf.Markdown(comment.Body)) + } + + return join( + "# "+t.Key+": "+fields.Summary, + about, + section("Description", adf.Markdown(fields.Description)), + section("Subtasks", list(fields.Subtasks, Issue.line)), + section("Links", list(fields.Links, Link.line)), + section("Comments", join(comments...)), + ) + "\n" +} + +// section gives a part of the ticket under its heading, or nothing for an empty part. +func section(heading, text string) string { + if text == "" { + return "" + } + + return "## " + heading + "\n\n" + text +} + +// join joins the parts that aren't empty, with a blank line between them. +func join(parts ...string) string { + return strings.Join(slices.DeleteFunc(parts, func(part string) bool { return part == "" }), + "\n\n") +} + +// list renders items as a bullet list, a line each. +func list[T any](items []T, line func(T) string) string { + lines := make([]string, len(items)) + for i, item := range items { + lines[i] = "- " + line(item) + } + + return strings.Join(lines, "\n") +} + +// line shows a ticket that another names by its key, summary and status. +func (i Issue) line() string { + return i.Key + ": " + i.Fields.Summary + " (" + i.Fields.Status.Name + ")" +} + +// line shows a link from the ticket's side, by its type and the other ticket. +func (l Link) line() string { + if l.Inward.Key != "" { + return l.Type.Inward + " " + l.Inward.line() + } + + return l.Type.Outward + " " + l.Outward.line() +} diff --git a/internal/jira/ticket_test.go b/internal/jira/ticket_test.go new file mode 100644 index 0000000..e34b6a1 --- /dev/null +++ b/internal/jira/ticket_test.go @@ -0,0 +1,61 @@ +package jira_test + +import ( + "encoding/json/v2" + "io/fs" + "os" + "strings" + "testing" + + "github.com/codedogapp/baton/internal/jira" +) + +func TestMarkdown(t *testing.T) { + testdata := os.DirFS("testdata") + + golden, err := fs.Glob(testdata, "*.md") + if err != nil || len(golden) == 0 { + t.Fatalf("no tickets in testdata: %v", err) + } + + for _, name := range golden { + key := strings.TrimSuffix(name, ".md") + t.Run(key, func(t *testing.T) { + var ticket jira.Ticket + decode(t, testdata, key+".json", &ticket) + + var page struct { + Comments []jira.Comment `json:"comments"` + } + + decode(t, testdata, key+".comments.json", &page) + ticket.Comments = page.Comments + + want := string(read(t, testdata, name)) + if got := ticket.Markdown(); got != want { + t.Errorf("Markdown() =\n%s\nwant:\n%s", got, want) + } + }) + } +} + +// decode reads a file of testdata as JSON into v. +func decode(t *testing.T, testdata fs.FS, name string, v any) { + t.Helper() + + if err := json.Unmarshal(read(t, testdata, name), v); err != nil { + t.Fatalf("decode %s: %v", name, err) + } +} + +// read returns a file of testdata. +func read(t *testing.T, testdata fs.FS, name string) []byte { + t.Helper() + + data, err := fs.ReadFile(testdata, name) + if err != nil { + t.Fatal(err) + } + + return data +}