Distillation

Date: Aug 27, 2026

• 🟡 (14:29) Assistant performed an adversarial design review of the publish/workspace-action-propagation changes and issued a DO-NOT-MERGE verdict.
• 🟡 (14:29) Review finding 1 (CRITICAL): CI can approve a different ref than Publish executes because the mutable issue-body branch field is separate from the SHA validated by the poller and the branch derived from check suites. publish/.github/workflows/ci-poller.yml:107-154 validates the body SHA then independently derives a branch; publish/.github/workflows/publish.yml:144-184 checkout permits only the default branch or protected allowlist. Recommended binding branch, SHA, and CI status into one authenticated immutable request record; publish must reject branch/SHA mismatches and require CI success for the exact checked-out branch head.
• 🟡 (14:29) Review finding 2 (HIGH): workspace classification occurs too late for publish-state setup. Inputs are parsed before target checkout in publish.yml:134-136; Set targets derives workspace/state path from those inputs in publish.yml:186-234. Craft keys publish state by both cwd and active workspace (craft/src/commands/publish.ts:726-730, src/utils/publishState.ts:82-99), so a suffix initially parsed as a path and later classified as a root workspace can pre-seed a different state file, allowing checked targets to be republished. Recommended resolving one validated { branch, path, workspace } object after checkout and using it consistently for state setup, cd, CRAFT_WORKSPACE, and Craft invocation; add exact state-filename parity tests for new-workspace and legacy-path requests.
• 🟡 (14:29) Review finding 3 (HIGH): compact titles collide with legacy path releases. publish: getsentry/repo/cli@1.2.3 is ambiguous between legacy path cli and workspace cli. Craft deduplicates by title alone (craft/action.yml:270-276) and reuses/overwrites a matching issue (craft/action.yml:348-356); Publish also serializes by title (publish.yml:6-10). This permits a new workspace request to reuse a legacy issue with different semantics; issue listing defaults to 30 results. Recommended using a versioned authenticated request identity in addition to title for issue lookup/reuse, never converting a field-less legacy issue into a new request, querying beyond the default issue-list limit, and retaining legacy requests exclusively on legacy branch/path flow.
• 🟡 (14:29) Review finding 4 (HIGH): proposed title grammar cannot express all currently valid workspace names. Workspace keys allow arbitrary strings (craft/src/schemas/project_config.ts:208-232); action validation permits safe Unicode (craft/action.yml:74-82, tests src/__tests__/action.test.ts:135-143); existing title JSON supports spaces, quotes, slashes, and Unicode (publish/src/modules/__tests__/details-from-context.js:104-161), while the current path grammar only accepts [\w./-]+ (publish/src/modules/details-from-context.js:24-45). Recommended defining a bijective shared encoding for trailing workspace segments, or rejecting unsupported names at configuration/action boundaries with documented migration; workspace names must not be normalized before lookup.
• 🟡 (14:29) Review finding 5 (MEDIUM): ambiguity guards lack a defined enforcement boundary. Craft supports workspace github.projectPath overrides (craft/src/config.ts:106-149), and the action lacks a path/workspace mutual-exclusion check before side effects (craft/action.yml:74-94, 170-200). Recommended making the first action step reject non-root path combined with workspace; validating every workspace declaration that sets github.projectPath, including unselected workspaces; and adding regressions for direct and inherited GitHub configuration, reusable-workflow inputs, and failure with no side effects.
• 🟡 (14:29) Review finding 6 (MEDIUM): legacy detection needs an unambiguous structured body marker. Current parser treats every suffix as a path (publish/src/modules/details-from-context.js:24-54), and a loose body regex could match changelog text or let legacy issues enter new branch/config resolution. Recommended using a dedicated versioned metadata section whose presence alone enables new behavior; missing metadata must preserve current title parsing, checkout fallback, cwd, and state identity byte-for-byte.