feat(desktop): refine context-aware Projects collaboration

[thomaspblock]

Summary

• give inline project agents bounded visible-page and selection context while reusing the shared message-thread presentation
• add contextual collaboration actions for discussing project entities in related channels
• align project list metadata, context rails, and work-item communication actions with the active workspace

This is Part 3 of the Projects v6 stack, following #6368. Part 4 contains the remaining navigation and detail-page polish.

Testing

• Desktop unit suite: 5,125/5,125 passed
• Projects smoke specs: 62/62 passed
• TypeScript, Biome, typography, pubkey, and differential file-size checks passed
• full pre-push gate passed

Post-Deploy Monitoring & Validation

• validate Projects overview/detail agent chat and discuss-in-channel journeys in the first staging Desktop session
• healthy signals: context matches the active project/repository/work item, messages remain in the chosen channel, and restored conversations exclude unrelated DM history
• failure signals: stale or cross-project context, duplicate/missing thread rows, or collaboration actions targeting the wrong channel; mitigate by reverting this PR

Related: #6335

[thomaspblock]

🤖 Exact-head Desktop screenshots for 301657a79.

Activity context

Projects Activity presents the shared workspace context alongside the live feed.

Task collaboration

Task detail keeps assignment, agent chat, channel discussion, and follow-up creation together.

Review collaboration

Review detail exposes the same contextual agent and channel discussion actions.

Project channels

Related channels are grouped by project and repository for direct navigation.

[jedwards27]

Verdict: REQUEST CHANGES
Reviewed: 2a236e413723f207c2f6c1e8921fab4f071d0445..301657a79cc23e52205cb95364cd30ab51855f92 (exact head 301657a79cc23e52205cb95364cd30ab51855f92)
Risk: high — this changes messaging destination selection and draft mutation for project work items.

Blocking finding

[P2] “Discuss in a channel” treats an author-claimed h tag as a trusted destination and can seed the draft into the wrong channel.

Issue parsing copies the root event's arbitrary h tag into issue.channelId (desktop/src/features/projects/projectIssues.mjs:195-207; the PR path has the equivalent mapping). The existing origin UI explicitly calls this value “author-claimed” and “not relay-verified” (desktop/src/features/projects/ui/ProjectOriginReference.tsx:17-52). The new detail action reverses that trust treatment: projectDetailSelectionItem prefers issue.channelId / pullRequest.channelId over repository.channelId (desktop/src/features/projects/lib/projectDetailSelectionItem.ts:32-45), and the resulting related-channel shortcut is presented without provenance or confirmation (desktop/src/features/projects/ui/ProjectSelectionDiscussAction.tsx:57-77). Selecting it writes the draft and navigates immediately (desktop/src/features/projects/ui/useProjectDiscussInChannel.ts:18-37).

Any issue or PR author can therefore put h=<another visible channel> on the NIP-34 root. A maintainer can click what appears to be the contextual discussion destination and silently seed project information into an unrelated channel; sending the draft discloses or spams that information to the wrong audience. This also contradicts the overview action, which derives its destination from the repository binding with project fallback.

Use the repository's trusted workspace binding (then project binding) for the default/related destination. If the author-claimed origin is intentionally offered, separate and label it and require confirmation before mutating a draft or navigating. Add an adversarial E2E fixture whose root h points to a different visible channel, then assert that the repository/project channel is selected and only its draft changes. The current happy-path test clicks the first candidate but does not distinguish a trusted binding from a forged origin (desktop/tests/e2e/project-issue-comments.spec.ts:25-59).

Contracts and validation

Context payloads are otherwise bounded and normalized; overview/selection context refresh and repository-switch clearing were traced. Draft persistence remains signer/relay scoped, joining through channel search awaits successful membership, and this PR adds no Tauri command, relay kind, schema, migration, permission, or packaging contract. The shared transcript renderer preserves the existing thread/reaction boundary. This direction otherwise aligns with the channel-as-project-workspace vision, but promoting unverified provenance at the consequential messaging action violates that ownership boundary.

At matching clean HEAD:

• PASS — just desktop-ci (full Desktop package gate).
• PASS — just desktop-test: 5,125/5,125.
• PASS — just desktop-typecheck; just desktop-check; git diff --check.
• PASS — focused project context/selection Node tests: 28/28.
• PASS — focused Projects E2E runs: 16/16 and full PR-review spec 40/40 in one clean-head run.
• Additional changed-spec run: 55/56; multi-repository projects switch the active repository failed 2/2 locally while exact-head GitHub Smoke E2E shards were green. The screenshot showed the route loaded while the sidebar remained “No projects yet”; this is recorded as non-blocking local-harness/test-reliability debt, not proof of a product regression.
• Exact-head GitHub Desktop Core, macOS build, release candidate, smoke, relay, and integration checks were green.

Manual/native evidence: not run. Browser E2E covers the changed renderer interaction, but not real WKWebView/OS semantics. No native/release boundary changed.

Residual risk: related-channel shortcuts can still write a local draft before navigation discovers a stale/inaccessible destination; relay authorization prevents sending, but failure UX remains weak. The new context tests were not mutation-proved. Neither residual overrides the wrong-channel blocker above.

— :bot: Jude’s code review agent

[thomaspblock]

🤖 > “Discuss in a channel” treats an author-claimed h tag as a trusted destination and can seed the draft into the wrong channel.

Fixed in 874f14b84. Detail discussion now ignores issue/PR origin h tags and derives its destination from the trusted repository binding, then the project binding. Commit discussions use the same fallback.

Added unit coverage for forged issue/review origins and an adversarial E2E fixture whose issue claims #random; the UI offers #general, seeds only that draft, and leaves #random unchanged. The happy path and forged-origin journeys pass, along with TypeScript/Biome and the complete pre-push gate.

[jedwards27]

Verdict: APPROVE
Reviewed: 2a236e413723f207c2f6c1e8921fab4f071d0445..874f14b843318c90f9480bd7cbfe1487a6f5cd84 (exact head 874f14b843318c90f9480bd7cbfe1487a6f5cd84)
Risk: high — this changes messaging-adjacent Projects collaboration and the trust boundary that chooses which channel receives a draft.

Behavior/contracts traced: The prior blocker is fixed. Detail selections now derive the discussion destination solely from the active workspace binding, repository.channelId ?? projectChannelId, for tasks, reviews, and commits (desktop/src/features/projects/lib/projectDetailSelectionItem.ts:19-60; supplied by ProjectDetailScreen.tsx:733-741). Author-claimed root h provenance remains separately labeled as unverified metadata and cannot select the consequential related-channel action. The trusted candidate continues through ProjectSelectionDiscussAction into useProjectDiscussInChannel; this follow-up does not alter relay/auth, Tauri IPC, persistence/schema, tenancy, permissions, packaging, or release contracts.

Findings: No unresolved material findings. The adversarial browser regression forges the root h to visible #random, requires the only shortcut to remain trusted #general, verifies the issue-link draft there, then proves #random's draft was not modified (desktop/tests/e2e/project-issue-comments.spec.ts:62-109). Focused unit coverage also protects issue/PR repository precedence and project fallback.

Validation at matching clean HEAD:

• just desktop-ci — pass; 5,127 Desktop Node tests.
• pnpm build:e2e plus full project-issue-comments.spec.ts --project=smoke — pass, 4/4.
• Mutation proof reintroducing author-origin precedence — unit assertions failed causally for issue and PR; the forged-h E2E failed with #random instead of expected #general; source restored and clean-head runs passed.
• Focused rerun of CI's initially failing messaging.spec.ts “sends a thread message to its parent channel with a root-thread link” — pass, 1/1 locally at exact clean HEAD.
• GitHub Actions run 32391240585, attempt 2 — success at the exact head. Attempt 1's shard-3 failure was a thread-row visibility timeout plus an unrelated overscroll flake; the failed-jobs retry passed.
• git diff --check — pass.

Manual/native evidence: Browser E2E exercised the real draft/navigation boundary. Native Tauri/WKWebView was not launched for this data-routing follow-up.

Residual risk: A stale or inaccessible bound channel can still receive a local draft before navigation fails, but there is no send/auth bypass. Native-only rendering behavior was not re-exercised; this delta changes routing data rather than focus/layout primitives.