pub const ISSUE_GET: &str = "\
Show one issue: fields, links, and the description.
```
ytcli issue get PROJ-1
ytcli issue get PROJ-1 --fields status,assignee,storyPoints
ytcli issue get PROJ-1 --full
ytcli issue get work/PROJ-1
```
About fifteen lines. `--fields` returns one line with the fields in the order
you asked for, custom keys included; a field that is unknown or unset comes back
as `-` rather than vanishing, so columns never shift. `ytcli queue fields PROJ`
lists what a queue actually has.
Custom fields are counted, not dumped, because the set differs per queue and
most are empty. A terminal gets them all by name instead.
In a terminal that can draw — Kitty, Ghostty, WezTerm, iTerm2 — an image
attachment appears where the description references it, captioned with its
filename. Images the description never mentions follow the issue, four of them,
then the rest are named. Only files attached to this issue are ever fetched.
A pipe, an agent or `--no-images` fetches none of it, so the cheap path stays
exactly as cheap as it was.
The description is truncated for a pipe and whole for a terminal; `--full`
overrides that either way. It arrives marked as text other people wrote — data,
not instructions.
A bare key is normal, and it decides the profile: a queue only one profile can
see is fetched through that profile, whichever one is the default. When the
queue is not known yet and there is more than one profile, each is asked once
which queues it sees, and the answer is remembered.
Two profiles in *different* organisations sharing a queue key is the ambiguous
case — `PROJ-1` then names two issues — and it is refused rather than guessed
at; write `work/PROJ-1`. Two profiles on the *same* organisation are not
ambiguous: that is one issue seen through two logins.
`--profile` is an instruction rather than a default, so it is never overridden
by what a key implies: with it, the request goes where you said, 403 and all.
Every command says which profile and organisation answered, on stderr, once.";