Mention tasks in any chat surface - #93
Conversation
Typing # in a composer offers open tasks first and inserts the task key, the same reference every other surface already writes. Message rendering recognises a key that names a real task and makes it a live link to it, so a task an agent cited is as clickable as one a person typed.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 547e494c74
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| /// The shape of a key: the workspace prefix is configurable, so this matches | ||
| /// `ACME-7` as readily as `PW-42` and the caller decides which keys are real. | ||
| export const TASK_KEY = /(?<![\w-])([A-Za-z][A-Za-z0-9]*-\d+)(?![\w-])/; |
There was a problem hiding this comment.
Workspaces can validly configure a task prefix beginning with a digit because update_workspace retains any nonempty ASCII-alphanumeric prefix, producing keys such as 2FA-1 or 123-4. This pattern requires the first character to be a letter, so those real tasks can be selected by the new composer menu but remain plain text in desktop messages. Match an alphanumeric leading character or tighten the server-side prefix validation consistently.
Useful? React with 👍 / 👎.
| onClick={(event) => { | ||
| event.stopPropagation(); | ||
| options.onTask?.(taskId); |
There was a problem hiding this comment.
When a known task key is used as an explicit Markdown link label, such as [PW-42](https://example.com), renderInline nests this clickable span inside the generated anchor. stopPropagation() does not cancel the anchor's default action, so clicking the key both navigates the app to the task and opens the external URL in a new tab. Prevent the default action or avoid task-link behavior inside explicit link labels.
Useful? React with 👍 / 👎.
1 participant
Tasks were only reachable from a message when the relay attached a task card. Typing a task key was plain text everywhere.
Composing —
#in a composer opens the same menu@uses, listing tasks (open work first, then most recently touched; matches key or title). Picking one inserts the bare key, e.g.PW-42. Desktop and mobile.Reading — the desktop markdown renderer recognises a key that names a real task and renders it as a link to that task. That covers every surface that renders a message (channels, task discussions, threads, search) without threading anything through, and it also lights up keys agents and the CLI already write. An unknown key like
PW-999orUTF-8stays plain text.No wire, relay or storage change: the mention is just the key in the message body, so it means the same thing to every client.
Skipped: mobile does not render the link yet (its markdown does not render
@handlespecially either), and run steering inputs have no autocomplete. Add both if they get asked for.Checks:
client/mentions.test.ts(ranking + key shape) added to the mobile test run — 13/13 pass;tsc --noEmitclean for desktop and mobile; desktopvite buildclean.