Add copyable links for channel messages and thread roots

[PollyBot13]

Add copyable links for channel messages and thread roots

Problem

Search can find messages and navigate inside the current client, but users and
agents do not have a general message action for copying a stable citation.
Explaining why a decision was made still requires vague directions or copied
text rather than a permission-checked link to the source.

ClickClack already has canonical public route IDs for workspaces, channels,
DMs, and thread roots. This issue extends M public route IDs/resolution to
supported channel root messages, without assigning citation routes to replies
or adding DM citations, and exposes a bounded citation surface without making
content public.

This is an incremental building block for externally managed workrooms, such as
one channel per pull request: integrations, humans, and agents can cite the
durable ClickClack discussion while workflow authority remains external.

Proposed behavior

• Add Copy link to channel root-message and thread-root action menus.
• Newly copied URLs use public route IDs, never internal IDs.
• Assign immutable M route IDs to supported channel root messages on creation
  or migration/backfill. Replies do not receive citation route IDs; existing DM
  thread routes remain compatible but are not exposed by this feature.
• Every channel-root citation uses the existing canonical
  /app/{workspace_route_id}/{message_route_id} form. M is the immutable
  public identity of the root, independent of whether replies exist; there is
  no second channel-query citation form.
• Opening the route resolves the parent conversation, loads around and
  highlights the root, and opens the thread pane when the root currently has
  replies. Adding the first reply never changes the copied URL or canonical
  route.
• Copy an absolute canonical URL built from the configured public frontend origin plus the canonical route; never derive deployment origin ad hoc.
• Existing permission checks remain authoritative; links grant no access.
• An authorized soft-deleted channel root opens the existing tombstone and its
  thread when requested. Missing and unauthorized targets return the same
  not-found response and reveal no existence.

Scope

• Cross-store M assignment/resolution for all supported channel roots,
  canonical link construction, and action-menu UI.
• Route resolution, around-message loading, and thread opening for the
  canonical root form.
• Clipboard success/failure feedback with an accessible focused selectable-URL
  fallback, plus browser tests.

Non-goals

• Public shares, previews/unfurls, cross-workspace access, exports, special
  citation formatting, new DM citation actions/routes, or individual
  thread-reply links in the first version.

Acceptance criteria

• Copied links contain only canonical public route IDs.
• A permitted second user opens the target in the correct channel/thread.
• An outsider learns no additional target existence.
• Authorized soft-deleted roots open as tombstones; missing, removed-member,
  guest-forbidden, and outsider requests share one not-found contract.
• Archived channels remain addressable under their current permissions.
• Clipboard failure exposes a keyboard-accessible focused selectable URL.
• The configured public frontend origin produces correct absolute canonical URLs.
• Search and direct navigation continue to work.
• The same copied URL remains canonical before and after the first reply;
  legacy thread-root routes retain their path and behavior.
• Built-app browser proof covers copy/open/highlight and denied access.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 1, 2026, 7:47 PM ET / 23:47 UTC.

Summary
Keep this issue open. Current main intentionally provides public routes only after a root becomes a thread or a thread is opened, and message actions copy message text rather than a canonical URL. The linked open implementation at #128 owns delivery, so the remaining gate is maintainer approval of its durable route-identity and existing-store migration contract.

Reproducibility: not applicable. This issue requests a new canonical citation capability rather than reporting failed existing behavior. Current-main source confirms the requested behavior is intentionally absent.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should ClickClack make every supported channel root receive a durable public M route ID at creation, with a migration/backfill for existing stores, so it can be cited before any reply exists?	Sponsor eager channel-root citations: Approve the durable identity and backfill contract, then review the linked PR’s migration, authorization, and browser coverage as the implementation path.

Why: This is a new persistent public-identity contract, not a repair to an existing broken behavior; it determines upgrade behavior and the long-term URL surface.

Next step
The linked open PR already owns implementation; maintainer approval of the persistent route-identity and upgrade contract is required before any further repair work.

Review details

Best possible solution:

Adopt one documented, permission-checked canonical URL contract for channel-root citations only if maintainers approve eager root identities and a tested, idempotent existing-store backfill; then land the linked PR or a narrower successor.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this issue requests a new canonical citation capability rather than reporting failed existing behavior. Current-main source confirms the requested behavior is intentionally absent.

Is this the best way to solve the issue?

Unclear: the linked PR is a concrete path and supplies real-store/browser proof in its body, but its eager persistent route-ID and migration behavior needs maintainer product approval before it is the accepted solution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked implementation changes when persistent M route IDs are assigned and backfills existing SQLite and PostgreSQL stores; maintainers need an explicit compatibility decision before treating that contract as settled.

Codex review notes: model internal, reasoning high; reviewed against 4843afe2e8eb.

Label changes

Label justifications:

• P3: This is a new usability and citation capability, not a confirmed regression or urgent availability issue.
• impact:ux-friction: Without stable copied URLs, users and agents must cite message content through copied text or navigation instructions.

Evidence reviewed

What I checked:

• Current menu copies text, not a link: The message-row clipboard handler writes only message.body, and the touch action sheet labels that action “Copy text”; current main therefore does not expose the requested canonical-link action. (apps/web/src/components/messages/MessageRow.svelte:285, 4843afe2e8eb)
• Current channel roots deliberately receive route IDs lazily: Current SQLite route tests assert that a new channel root has no route ID, receives its M identity after the first reply, and can also receive one when its thread is opened. This conflicts with the issue’s requested eager, stable channel-root identity. (apps/api/internal/store/sqlite/route_ids_test.go:200, 4843afe2e8eb)
• Existing public routes already fail closed: The route resolver checks message access before resolving legacy thread routes and returns no row for invalid, unauthorized, reply, or missing targets; current tests also verify unauthorized public route access returns not found. (apps/api/internal/store/sqlite/routes.go:119, 4843afe2e8eb)
• Linked implementation is still open: The supplied GitHub context identifies feat: add copyable message citation links #128 as an open, clean, closing implementation for this issue, with its exact head based on current main. It has not merged, so this issue must remain open until that work is accepted or replaced. (98044b55ba89)
• Feature-history signal: Recent history shows Shakker maintaining the action-menu and copy-result behavior; commit 3876973 introduced copy-result handling and later action-menu fixes continue through aca7fac. (apps/web/src/components/messages/MessageRow.svelte:275, 387697330e78)
• Maturity scorecard unavailable: The required maturity shortlist helper could not find qa/maturity-scores.yaml in this checkout, so no maturity label is selected.

Likely related people:

• Shakker: Recent history covers the current clipboard and action-menu behavior, including the user-visible copy result and subsequent menu interaction fixes. (role: recent message-action contributor; confidence: high; commits: 387697330e78, aca7fac054e2; files: apps/web/src/components/messages/MessageRow.svelte, apps/web/src/components/messages/MessageActionSheet.svelte)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.