Distillation

Date: July 21, 2026

• 🟡 (16:27) [tool result] Open issues mentioning workspace/monorepo/multi-product: #842 OPEN "Support Cloudflare deploy target + prefixed multi-product releases (for getsentry/toolkit)" (enhancement, opened 2026-07-15); #649 OPEN "Add workspaces support for dotnet/nuget" (opened 2025-12-04); #394 OPEN "Resume publishing a Rust crates workspace" (Improvement, opened 2025-08-12).
• 🟡 (16:27) [tool result] No existing design-doc directory found; checked repo root listing (astro.config.mjs, dist, node_modules, package.json, pnpm-lock.yaml, public, src, tsconfig.json) plus a plans-style directory containing timestamped markdown files (e.g. 1774618266665-eager-rocket.md ... 1784109577263-shiny-knight.md).
• 🟡 (16:27) Assistant flagged tension between "redesign as workspaces first" and "add a selector now" — noted a correct single-file multi-product model needs action-layer changes (issue title, publish-state key, craft targets scoping) beyond just the code selector, and proposed confirming the split with user before writing code.
• 🔴 (17:02) [decision] User decided: Park PR #844 — fold its bot/review fixes plus the multi-product model entirely into a new workspaces redesign (answer to "How should open PR #844 be handled?").
• 🔴 (17:02) [decision] User decided: Reuse the existing "workspace" term for the new selector/mechanism rather than introducing a new term like products/packages/releaseGroups (answer to "What selector term/mechanism should we introduce?").
• 🟡 (17:02) Assistant noted reusing "workspace" requires reconciling two concepts: existing config.workspaces boolean on the npm target + expandWorkspaceTargets/NpmTarget.expand (same-version npm package expansion) vs. a new top-level workspaces: key for independently-versioned products — designed as one coherent "workspaces" concept with npm case as a sub-mode.
• 🟡 (17:02) [tool result] Todo list created (4 items): 1. Write workspaces redesign design doc (schema, selector, action-layer, term reconciliation, folds in #844 fixes) — in_progress, high priority; 2. Review design doc with user before implementation — pending, high; 3. Park PR #844 (mark draft/closed with pointer to redesign) after design agreed — pending, medium; 4. Implement per agreed design (separate phase) — pending, low.
• 🟡 (17:04) [tool result] Verified craft/src/config.ts:555-599 — isExpandableTarget() (checks for static expand method on target class) and expandWorkspaceTargets() (lines 577-599): takes TargetConfig[], lazy-imports getTargetByName from './targets' to avoid circular dependency, rootDir = getConfigFileDir()||process.cwd(), calls targetClass.expand(target, rootDir) per target if expandable (e.g. npm workspace expansion), else passes target through unchanged.
• 🟡 (17:04) [requested-review] Assistant wrote design doc to .opencode/plans/workspaces-redesign-design.md, chosen as version-controlled location per user's stated preference for durable artifacts.
• 🟡 (17:05) [tool result] Todo list updated: item 1 (write design doc) → completed; item 2 (review design doc with user) → in_progress; items 3-4 unchanged (pending).
• 🟡 (17:05) Assistant summarized design doc crux: (1) "workspace" term reuse requires disambiguating new top-level workspaces: (named, independently-versioned release units) from npm target's existing workspaces: true field (package discovery within a target) — no schema clash but docs must disambiguate; (2) real risk is action/publish-issue layer — publish-request pipeline disambiguates products only by version+subdirectory path, and single-file selector would collide on issue title (action.yml:241 format publish: <repo><subdir>@<version>), craft targets checklist, and publish-state key (publishState.ts:87) — matches reviewer's "publish repo" concern; (3) top-level CraftProjectConfigSchema is not .passthrough() so workspaces: must be added explicitly to schema, fully backward-compatible when absent.
• 🟡 (17:05) Assistant proposed rollout plan: PR A = salvage non-controversial #844 fixes (changelog try/catch guard, opaque-prefix findReleaseBranches, prefix-aware read paths) — small, mergeable now; PR B–E = schema + resolver + --workspace selector → prepare/publish threading → action-layer keying → docs; #844 parked (draft + pointer to design doc).
• 🟡 (17:05) Assistant posed 4 open questions needing user's call before coding: 1. Issue-title format for a workspace (publish: <repo> [<ws>] @<ver> vs <repo>#<ws>@<ver> vs reuse path/SUBDIRECTORY convention); 2. Config shape (shared top-level default target set + per-workspace overrides, vs all targets must live under a workspace once workspaces: present); 3. getsentry/publish accept-side (keep issue title parseable by appending workspace with no accept-side change, vs changing both sides); 4. Migration (support both single-file and per-.craft.yml models, or deprecate per-file one).
• 🟡 (17:05) Assistant offered recommended defaults if user doesn't want to answer inline: append [<ws>] to issue title (stays backward-parseable); allow shared base + per-workspace overrides; append-only approach so no accept-side change needed; support both single-file and per-file models with per-file soft-deprecated.