Distillation

Date: July 21, 2026

• 🟡 (17:18) User asked for assistant's honest take: unify/adapt getsentry/publish to a single-file top-level workspace concept vs. double down on existing path-based solution; user stated their gut feeling is that a top-level target-agnostic workspace concept would be broadly useful long-term.
• 🟡 (17:18) Assistant recommended unifying on a single-file top-level workspaces: concept and adapting the publish repo, agreeing with user's instinct. Reasoning: path conflates physical directory layout with release identity; publishState.ts:16 comment ("to disambiguate monorepo subpaths") shows this was already patched around at the state-file layer; issue-title collision in action.yml:241 only avoided incidentally when subdirs differ — two products at same version/same dir would silently merge into one issue (initially characterized as "latent data-corruption bug").
• 🟡 (17:18) Assistant listed benefits of top-level workspace concept: target-agnostic (works across github tagPrefix and npm-package workspaces uniformly), makes release identity explicit (--workspace cli vs implicit first-github-target/current-subdir), composes cleanly with existing npm-package workspaces (different concept: release unit vs. shipped packages), and would directly address issues #649 (dotnet/nuget workspaces) and #394 (crates workspace resume).
• 🟡 (17:18) Assistant flagged real cost: must change getsentry/publish (separate repo, shared infra, own review/deploy cadence); issue-title format is a de-facto API that must stay backward-compatible for existing single-product repos. Mitigation proposed: make workspace component purely additive/optional in the issue title — single-product repos keep today's exact title, workspace releases append an identifier (e.g. publish: <repo> [<ws>] @<ver>); accept-side parser gets an optional capture group.
• 🟡 (17:18) Assistant proposed 4-PR sequence: (A) salvage 3 fixes from parked #844 (changelog guard, opaque-prefix, prefix-aware reads) — zero coupling, mergeable now; (B) top-level workspaces: schema + resolver + --workspace selector, fully backward-compatible when absent; (C) prepare/publish threading; (D) action-layer + getsentry/publish accept-side change, additive so single-product repos stay byte-identical — the one PR touching shared infra, isolated for easy revert. Assistant stated explicitly it would NOT ship the --workspace selector without the PR D action-layer fix, since that would silently collide in the publish pipeline.
• 🔴 (18:23) [answered-question] User answered assistant's question about how much PR D can toutouch getsentry/publish: "Additive change to publish is fine" — confirms additive/optional issue-title format approach is acceptable, not a hidden/smuggled marker.
• 🔴 (18:23) Design decisions locked per assistant: (1) Unify on top-level target-agnostic workspaces: (single file), adapt getsentry/publish additively; (2) reuse the term "workspace," disambiguated from npm-package workspaces; (3) additive issue-title format — single-product repos byte-identical, workspace releases append optional segment, accept-side parser gets optional capture group; (4) park issue #844; salvage its 3 fixes into PR A.
• 🟡 (18:23) Assistant updated the design doc to record these resolved decisions (edit applied successfully per tool result at 18:25).
• 🟡 (18:25) Assistant's next planned action: park #844 (convert to draft, post comment explaining pivot, reply to open review threads), then begin PR A (the 3 salvageable fixes).
• 🟡 (18:25) [challenged-claim] User pushed back on assistant's "latent data-corruption bug" claim, asking "How's this even possible??" — prompted assistant to verify against actual source code rather than repeat the research summary.
• 🟡 (18:27) Assistant confirmed mechanism in action.yml lines 241/247: title="publish: ${GITHUB_REPOSITORY}${SUBDIRECTORY}@${RESOLVED_VERSION}"; SUBDIRECTORY is empty when inputs.path == '.'; existing-issue lookup does gh -R "$PUBLISH_REPO" issue list --json title,... | jq ... select(.title == $t) | first — matched purely by title string. If two products released from repo root at the same version, titles are byte-identical, so the action finds the other product's open issue and takes the edit path, merging/overwriting the ### Targets checklist (action.yml:257-316) — preserving already-checked boxes from the other product while adding this product's targets, producing a scrambled union checklist that could lead to publishing a mix.
• 🟡 (18:27) [self-corrected] Assistant walked back the strength of its earlier "latent data-corruption bug" framing: not a live bug today because the current documented convention (one .craft.yml per product, each in its own path subdir) makes SUBDIRECTORY differ and titles differ, sidestepping the collision by construction. Requires three coinciding conditions to trigger: (1) two products configured at repo root with no distinct subdir, (2) same version, (3) both having open publish issues simultaneously. Reframed conclusion: path-as-identity is a structural weakness that is currently avoided by convention but becomes actively reachable under the new single-file workspaces: model unless PR D's additive title change (embedding workspace name, e.g. publish: <repo> [<workspace>] @<version>) ships alongside it — reinforcing why PR D is "non-negotiable" and why shipping --workspace without the action-layer fix was flagged as the one thing not to do.
• 🟡 (18:27) Assistant asked user whether to proceed with parking #844 and opening PR A (the three salvageable fixes).