Context
crit share (CLI) and the browser Share button use different code paths to build the share payload:
- CLI:
runShare → loadCommentsFromCritJSON — reads from .crit.json on disk
- Browser:
handleShare → buildShareFromSession — reads from in-memory Session struct
Both should produce identical payloads, but since they're separate implementations, they drift:
Suggested approach
Have handleShare read from the persisted .crit.json (same as CLI) instead of building from the in-memory session. The review file is already written on every comment change with a 200ms debounce, so it's always current.
Alternatively, extract a shared collectSharePayload(critPath, filePaths) that both paths call.
Benefit
Single source of truth for share payload construction. Fixes like #297 and features like #291 only need one code change instead of two.
Found while setting up e2e integration tests for the share flow.
Context
crit share(CLI) and the browser Share button use different code paths to build the share payload:runShare→loadCommentsFromCritJSON— reads from.crit.jsonon diskhandleShare→buildShareFromSession— reads from in-memorySessionstructBoth should produce identical payloads, but since they're separate implementations, they drift:
buildShareFromSessionmissess.reviewComments(CLI path includes them)Suggested approach
Have
handleShareread from the persisted.crit.json(same as CLI) instead of building from the in-memory session. The review file is already written on every comment change with a 200ms debounce, so it's always current.Alternatively, extract a shared
collectSharePayload(critPath, filePaths)that both paths call.Benefit
Single source of truth for share payload construction. Fixes like #297 and features like #291 only need one code change instead of two.
Found while setting up e2e integration tests for the share flow.