Distillation

Date: Jul 21, 2026

• 🔴 (16:04) [tool-result] Confirmed branch feat/prefixed-tags via git status; working tree shows modified .lore.md, untracked .craft-issue-842-plan.md and .opencode/ directory, plus source dirs (artifact_providers, commands, config.ts, index.ts, instrument.ts, logger.ts, mocks, schemas, status_providers, targets, tests, types, utils).
• 🟡 (16:04) Assistant created a 10-item todo list to track investigation: (1) grep 'workspace' across repo [in_progress], (2) config schema & loading, (3) prepare command flow, (4) publish command flow, (5) publish_repo/publish issue/action.yml, (6) CLI entry & yargs, (7) version/tag utilities, (8) precedents for grouping/per-target overrides, (9) tests needing change, (10) write structured report.
• 🟡 (16:05) [tool-result] Repo-wide grep for "workspace" (100+ matches) revealed craft ALREADY has an npm/yarn/pnpm workspace concept, but scoped to package publishing/dependency-graph ordering, not release versioning:
  • src/config.ts:572 — comment noting extension point "to implement their own expansion logic (e.g., npm workspace expansion)".
  • src/commands/publish.ts:671 — comment "// Expand any npm workspace targets into individual package targets".
  • src/commands/targets.ts:12 — comment "// Expand workspace targets (e.g., npm workspaces)" (site of expandWorkspaceTargets-style logic).
  • src/utils/workspaces.ts — dedicated module with: WorkspacePackage type incl. workspaceDependencies: string[] (line 26); WorkspaceDiscoveryResult type ("type of workspace manager detected", line 31); PnpmWorkspaceConfig interface for pnpm-workspace.yaml (line 37, workspaces?: string[] | { packages?: string[] } line 45); extractWorkspacesGlobs() (line 97) pulling globs from package.json workspaces field; discovery logic collecting workspace package names/locations then resolving deps in a second pass filtered against known workspace names (lines 115-145); npm/yarn discovery via resolveWorkspaceGlobs() (line 181); pnpm discovery via reading pnpm-workspace.yaml at line 198; a top-level "discover all workspace packages" function supporting npm/yarn (package.json workspaces field) and pnpm (pnpm-workspace.yaml), returns null if not a workspace (lines 228-253); filterWorkspacePackages() for include/exclude patterns (line 334); topological sort of workspace packages by dependency graph with circular-dependency detection (lines 360-393).
  • CHANGELOG.md: PR #805 (npm target tolerates workspace:* deps in version bump + bun.lock patching, by @BYK), PR #645 ("feat(npm): Add workspaces support", by @BYK), PR #392 ("fix(crates): Resume workspace publish", by @jan-auer).
  • README.md:44 lists "Workspace Support - Handle monorepos with NPM/Yarn workspaces"; README.md:69 npm target row noted "(with workspace support)".
  • blog-post-draft.md: example config workspaces: true (line 133); claims "~200 line reduction in config, with automatic dependency ordering" reading package.json workspaces config (lines 106-137).
  • Tests: src/commands/tests/targets.test.ts:40 "lists targets without expansion when no workspaces", line 55-57 "lists expanded workspace targets" using { name: 'npm', workspaces: true }; src/tests/versionBump.test.ts:218+ extensive suite "workspace:* handling (issue #804)" covering npm --workspaces version bump propagation and bun.lock patching edge cases (non-greedy regex [^{}]*? fix, versionless workspace boundary handling).
• 🟡 (16:05) Assistant's interim finding: craft's existing "workspace" concept is entirely about npm/yarn/pnpm monorepo package publishing (dependency ordering, version bump propagation), NOT about the user's proposed feature (one repo releasing multiple independently-versioned products via a top-level product/workspace selector). No naming collision risk identified yet but term "workspace" is already heavily used for a different feature.
• 🟡 (16:05) [tool-result] Read src/config.ts key structures (file:line):
  • findConfigFile() (~line 61-98): builds probePath = path.join(currentDir, CONFIG_FILE_NAME) (line 73), warns "Reached maximum allowed directory depth" (line 86), throws ConfigurationError if not found (line 98).
  • getConfigFileDir() at line 110.
  • getConfiguration() uses _configCache, checked at line 148 (if (!clearCache && _configCache)).
  • loadConfigurationFromString() around line 174 does load(configContent) as Record<string, any> (YAML parse).
  • minVersion parsing/validation at lines 187-212: reads config.minVersion (line 187), parses via parseVersion() (line 200), throws if below threshold.
  • AUTO_VERSION_MIN_VERSION = '2.14.0' constant at line 249 — auto-versioning requires minVersion >= 2.14.0.
  • getVersioningPolicy() (~lines 262-287): returns 'manual' by default for backward compatibility, otherwise derived from minVersion.
  • getGlobalGitHubConfig() (~lines 287-324): checks _globalGitHubConfigCache (line 287), calls getConfiguration(clearCache).github (line 299), falls back to parsing git remote via GitUrlParse(defaultRemote.refs.push || defaultRemote.refs.fetch) (line 311), freezes cache result (line 324).
  • Comment at line 336: warns that if multiple github targets have differing prefixes, configuration handling logs a warning (line 349).
  • createArtifactProviderConfig-type function (~361-400) calls await getGlobalGitHubConfig() at line 374; branches include new GCSArtifactProvider(...) (line 387).
  • Status provider default logic ~line 412 sets statusProviderName = StatusProviderName.GitHub as default; switch default: case at line 424.
  • Changelog resolution function (~437-487): policy: ChangelogPolicy field (line 437), reads config.changelog.filePath (line 474), returns object including policy (line 487).
  • source type 'config' | 'auto-detected' | 'default' defined at line 499, used for releaseBranchPrefix resolution: 'config' source at line 524, 'auto-detected' at line 536; comment (~511) explains release branches must differ from main/master because GitHub Actions dist/ merging needs it.
  • Line 561: typeof targetClass === 'function' type-guard check.
  • Line 572 (already noted above re: workspace expansion) sits within a function whose @param targets The original list of target configs (line 574) — this is the target-list transformation extension point (expand/no-op).
• 🟡 (16:05) [tool-result] Read full src/schemas/project_config.ts (193 lines) — complete schema inventory:
  • Enums: ChangelogPolicy (Auto/Simple/None, marked DEPRECATED in favor of changelog.policy, lines 6-10); StatusProviderName (GitHub only, line 16); ArtifactProviderName (GCS/GitHub/None, lines 22-26); VersioningPolicy (Auto/Manual/CalVer, lines 35-38).
  • GitHubGlobalConfigSchema (lines 43-47): owner: string, repo: string, projectPath?: string.
  • TargetConfigSchema (lines 54-63): name: string, id?, includeNames?, excludeNames? — uses .passthrough() (line 61) to allow target-specific extra fields; this is the ONLY schema in the file using .passthrough().
  • TypedTargetConfig<T> utility type (lines 76-77) for strongly-typed target configs combining TargetConfig + target-specific fields.
  • BaseStatusProviderSchema (lines 82-85): name: enum(['github']), config?: record.
  • BaseArtifactProviderSchema (lines 92-95): name: enum(['gcs','github','none']), config?: record.
  • ArtifactPatternsSchema (lines 102-105): string | string[].
  • GitHubArtifactsConfigSchema (lines 111-113): union of ArtifactPatternsSchema or record mapping workflow names → patterns.
  • GitHubArtifactProviderConfigSchema (lines 120-122): { artifacts: GitHubArtifactsConfigSchema }.
  • CalVerConfigSchema (lines 131-141): offset?: number (default 14 days per doc comment), format?: string (default %y.%-m, supports %y/%m/%-m tokens).
  • VersioningConfigSchema (lines 148-151): policy?: enum(['auto','manual','calver']), calver?: CalVerConfigSchema.
  • ChangelogConfigSchema (lines 158-165): union of plain string or object { filePath?, policy?: enum(['auto','simple','none']), scopeGrouping?: boolean }.
  • CraftProjectConfigSchema (lines 170-191) — top-level schema is a PLAIN z.object (NOT .passthrough()), meaning unknown top-level keys are stripped/rejected. Fields: github?, targets?: TargetConfigSchema[], preReleaseCommand?, postReleaseCommand?, releaseBranchPrefix?: string, changelog?: ChangelogConfigSchema, changelogPolicy? (deprecated enum), minVersion?: string (regex /^\d+\.\d+\.\d+.*$/), requireNames?: string[], statusProvider?: BaseStatusProviderSchema, artifactProvider?: BaseArtifactProviderSchema, versioning?: VersioningConfigSchema, noMerge?: boolean (defaults true for compiled GitHub Actions with dist/ folder per comment lines 187-189).
• 🟡 (16:05) Assistant flagged key schema-extension-point finding for the workspaces feature design: since CraftProjectConfigSchema lacks .passthrough(), adding a top-level workspaces/product-selector key would require an explicit schema field (cannot rely on passthrough as done for TargetConfigSchema).