Show related pull requests

[tirsen]

Why

Move the archived internal PR for session-related pull requests onto the current public Berd repository so users can see the PRs associated with a chat.

What

• Detect GitHub and Graphite pull request links in the active session transcript
• Show related PR identity, title, state, and check status in the Changes rail behind an opt-in experiment
• Fetch metadata through a bounded Tauri command backed by gh
• Extract a presentational pull-request list item for reuse by the stacked PR tracker

Risk Assessment

Low — the UI is behind the existing opt-in experiment, metadata access is bounded and read-only, and opening a row only launches its validated GitHub URL.

References

• Original archived PR: https://github.com/squareup/berd/pull/982
• Originating Buzz channel: cd8415a1-d910-4e0c-814c-42664d30a09e
• Reviewed LAWS/README.md and LAWS/CHAT.md; this feature does not change the durable chat queue, dispatch, steering, or activity-presentation invariants.

Generated with Codex

[loganj]

🤖 Carl here. Approved — no blocking or material findings.

I reviewed exact head 4d2efade31e3394a9a0c28fdae81067199e6c5d7 and traced the transcript scanner, GitHub/Graphite URL canonicalization and bounds, the Tauri gh execution boundary, experiment gating, query/render path, opener behavior, accessibility, and check-state classification.

The important security boundary holds: the backend independently requires an exact HTTPS GitHub host and PR path shape, reconstructs the canonical URL, invokes gh without a shell, bounds count/concurrency/time, disables prompting, and degrades to identity-only summaries on command or parse failure. Incremental scanning correctly excludes the live streaming message and rebuilds when previously scanned immutable message references change.

Mongo and Princess Donut independently reached the same no-finding verdict. Current GitHub checks are green at this exact head across frontend tests/build, frozen install, transcript virtualization, DCO, and Linux/macOS/Windows Rust jobs.

Non-blocking hardening only: a focused Rust assertion for traversal-shaped or encoded owner/repo segments would make the URL-parser security contract even more explicit, but the present validation and shell-free canonicalized invocation already prevent exploitation.

[loganj]

🤖 Carl here. APPROVE — no blockers or material findings.

Severity-ranked review

1. Blockers: none.
2. Material concerns: none. The security boundary holds: exact HTTPS GitHub URL validation and canonical reconstruction, shell-free bounded gh invocation, prompt disabling/timeouts/fallbacks, safe React rendering and opener input, and correct live-message/patched-history scan behavior.
3. Non-blocking hardening: consider adding a focused Rust parser test for traversal-shaped or encoded owner/repo segments. This would pin the security contract; it does not close a current exploit path.

Mongo, Princess Donut, and I independently reviewed exact head 4d2efade31e3394a9a0c28fdae81067199e6c5d7 and converged on the same verdict. The exact-head GitHub checks are green.