Remove DebugBuild dependency from UpstreamMerge build

UpstreamMerge now only depends on cascading UpstreamMerge builds from
dependent repos. Claude resolves conflicts without building - the PR
build handles compilation. Also added rm/mv tools for file operations.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: gfraiteur

src/PostSharp.Engineering.BuildTools/ContinuousIntegration/TeamCity/Generation/TeamCitySettingsFile.cs

@@ -208,24 +208,18 @@ private static TeamCityBuildConfiguration CreateUpstreamMergeConfiguration( Prod
         // Use Claude Dockerfile for upstream merge to enable AI-assisted conflict resolution
         var claudeDockerSpec = product.DockerSpec?.WithClaudeDockerfile();
 
-        // Get the same build dependencies as DebugBuild (artifact dependencies from upstream repos)
-        var debugConfigurationProperties = new ConfigurationProperties( product, BuildConfiguration.Debug );
-
-        // Also add dependencies on UpstreamMerge of dependent repos (for cascading merge)
-        var upstreamMergeDependencies =
+        // Dependencies on UpstreamMerge of dependent repos (for cascading merge order)
+        // No DebugBuild dependencies - Claude only does git merge and conflict resolution,
+        // it doesn't compile. The PR build will handle compilation with appropriate artifacts.
+        var snapshotDependencies =
             product.ParametrizedDependencies
                 .Where( d => d.Definition.GenerateSnapshotDependency && d.Definition.ProductFamily.UpstreamProductFamily != null )
                 .Select( d => d.Definition )
                 .Select( d => new TeamCitySnapshotDependency(
                     d.CiConfiguration.UpstreamMergeBuildType,
                     true,
-                    FailureAction: FailureAction.AddProblem ) );
-
-        // Combine: DebugBuild dependencies (for artifacts) + UpstreamMerge dependencies (for cascading)
-        var snapshotDependencies = debugConfigurationProperties.SnapshotDependenciesForBuildConfiguration
-            .Concat( upstreamMergeDependencies )
-            .DistinctBy( d => d.ObjectId )
-            .OrderBy( d => d.ObjectId );
+                    FailureAction: FailureAction.AddProblem ) )
+                .OrderBy( d => d.ObjectId );
 
         var upstreamMergeConfiguration = new TeamCityBuildConfiguration(
             "UpstreamMerge",

src/PostSharp.Engineering.BuildTools/Utilities/ClaudeCodeHelper.cs

@@ -84,10 +84,10 @@ public static bool TryResolveMergeConflicts(
         // --output-format stream-json: Stream JSON events in real-time
         // --verbose: Show full turn-by-turn output
         // --allowedTools: Tools Claude can use, with Bash patterns specified inline
-        // Bash patterns: git commands and ./build.sh commands are allowed (NO dotnet - must use build.sh)
+        // Bash patterns: git commands (including rm for file removal) and mv for moving files
         // The prompt is sent via stdin to avoid command line length limits
         var claudeArgs = "-p --output-format stream-json --verbose --model opus " +
-                         "--allowedTools \"Edit\" \"Read\" \"Bash(cd *)\" \"Bash(git *)\" \"Bash(./build.sh *)\" \"Grep\" \"Glob\"";
+                         "--allowedTools \"Edit\" \"Read\" \"Write\" \"Bash(cd *)\" \"Bash(git *)\" \"Bash(rm *)\" \"Bash(mv *)\" \"Grep\" \"Glob\"";
 
         console.WriteMessage( $"Invoking Claude Code with args: {claudeArgs}" );
         console.WriteMessage( $"Working directory: {workingDirectory}" );
@@ -440,11 +440,11 @@ private static string BuildMergeConflictPrompt( string sourceBranch, string targ
             This is a NON-INTERACTIVE session - you must complete the task without asking questions.
 
             ## Your Goal
-            Resolve all merge conflicts so the code builds successfully.
+            Resolve all merge conflicts so the merge can proceed. You do NOT need to build - the PR build will verify compilation.
 
             ## Generated Files (can be ignored)
             The following files are auto-generated. If they have conflicts, you can resolve them by keeping EITHER version
-            (preferably the current/HEAD version), then they will be regenerated in step 3.
+            (preferably the current/HEAD version). They will be regenerated when the PR build runs.
             - Build.ps1
             - DockerBuild.ps1
             - Dockerfile
@@ -472,42 +472,25 @@ Resolve all merge conflicts so the code builds successfully.
             d) Edit the file to remove ALL conflict markers and leave only the resolved code
             e) Run `git add <file>` to mark it as resolved
 
-            ### 3. Regenerate scripts
-            After resolving all conflicts semantically, run `./build.sh generate-scripts` to regenerate the generated files.
-            Then run `git add .` to stage the regenerated files.
-
-            ### 4. Build and verify (conditional)
-            **SKIP THIS STEP** if the ONLY files with conflicts were:
-            - Generated files (listed above) - they will be regenerated by `generate-scripts`
-            - Version files (`*.version.props`, `Directory.Packages.props`, `global.json`)
-            - Files containing only version number changes
-
-            In these cases, `generate-scripts` is sufficient - no build needed.
-
-            **OTHERWISE**, if any source code files (*.cs, *.csproj, etc.) had conflicts, run `./build.sh build` to ensure the code compiles.
-            If there are build errors or warnings, fix them and rebuild.
-
-            ### 5. Final check
+            ### 3. Final check
             Run `git status` to confirm all conflicts are resolved and files are staged.
 
             ## Conflict Resolution Rules
             - **Package versions**: When there's a conflict in package/dependency versions (in Directory.Packages.props, .csproj, etc.), always choose the HIGHER version number
             - **Code conflicts**: Analyze the intent of both changes and merge them logically
-            - **Generated files**: Keep HEAD version, they will be regenerated
+            - **Generated files**: Keep HEAD version, they will be regenerated by the PR build
 
             ## Important Constraints
             - Do NOT run `git commit` - leave that to the calling process
             - Do NOT run `git push`
-            - Do NOT run `dotnet build` for the first build - it will FAIL. Always use `./build.sh build` as the first build.
-              When a specific project fails, you can iterate with `dotnet build` for this specific project. To continue with other projects, do `./build.sh build`.
-            - Do NOT modify files that don't have conflicts unless needed to fix build errors
+            - Do NOT build the code - the PR build will handle compilation
+            - Do NOT modify files that don't have conflicts
             - If you encounter a conflict you cannot resolve confidently, resolve it to the best of your ability and note it in your output
 
             ## Success Criteria
             - All conflict markers removed from all files
             - All previously conflicting files staged with `git add`
-            - `./build.sh generate-scripts` completed successfully
-            - If code changes were involved: `./build.sh build` completes successfully with no errors or warnings
+            - `git status` shows no unmerged files
 
             ## Output Format
             At the very end of your work, write a conclusion block in this exact format:
@@ -519,8 +502,6 @@ Then run `git add .` to stage the regenerated files.
             Files resolved:
             - file1.cs: [brief description of resolution]
             - file2.csproj: [brief description of resolution]
-
-            Build status: [PASSED/SKIPPED (version-only changes)/FAILED with brief note]
             ===END_CONCLUSION===
             ```