Repository navigation
feat(share): prepare review content before opening a link - #7542
Conversation
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 2 important · 0 nits
The hook placement is correct: after the record is saved, after the takedown short-circuit, and before linkOn or the first audience change. Retry reuses the registration. The server routes match EF master (GET /v1/hyperframes/projects/<id>/storyboard, and PUT …/review-projects/<id>/composition, which needs manage and the storyboards flag). Two contract gaps are noted inline. CI is green on bb0865f, and the 25 kernel tests pass locally.
Scope
Audited all 5 files, openLink, applyFirstAudience, heldInstead, oneAtATime and withProjectShareLock, plus the EF route and logic files for the two new client methods. Reentrancy was confirmed with a local probe: a nested oneAtATime call on the same path hung.
— Genesis
What
Add an optional
beforeOpen(projectId)hook to the shared review kernel. Expose authenticated storyboard read and composition binding methods on the review client.Why
A host with a synced storyboard needs to bind and validate its content after review registration and before making the link accessible. The shared kernel owns the project lock, durable registration and audience changes, so the host needs an explicit point in that sequence.
Related work
The CLI share work in #7135 also uses the shared kernel.
How
After persisting the review ID and checking the current share for a takedown, call the optional hook under the existing project lock only for first opening or reopening a revoked link. Already-open links return their status without preparing again. The hook must stay short and must not call same-project review-lock operations because the lock is not reentrant. A rejection stops link and audience changes. Retrying uses the recorded project ID. Hosts that omit the hook keep their existing flow.
Test plan