@ipul-labs/forge 1.15.0 → 1.15.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ipul-labs/forge",
-  "version": "1.15.0",
+  "version": "1.15.1",
   "description": "AI-powered code change & deploy control panel — connects Claude, GitLab, and Kubernetes",
   "type": "module",
   "main": "server/forge/routes.js",

package/server/forge/core/ForgeAgent.js

@@ -438,6 +438,7 @@ export class ForgeAgent {
 			title: mrTitle,
 			explanation,
 			changes,
+			removals = [],
 			cost: cost2 = 0,
 			inputTokens: it2 = 0,
 			outputTokens: ot2 = 0,
@@ -451,6 +452,12 @@ export class ForgeAgent {
 			type: "log",
 			message: `Proposed ${enrichedChanges.length} change(s): ${enrichedChanges.map((c) => `${c.repo}:${c.file} (${c.action})`).join(", ")}`,
 		});
+		if (removals.length > 0) {
+			emit({
+				type: "log",
+				message: `⚠ ${removals.length} removal(s) declared: ${removals.map((r) => `${r.file}: ${r.what}`).join("; ")}`,
+			});
+		}
 
 		const result = {
 			issue,
@@ -458,6 +465,7 @@ export class ForgeAgent {
 			explanation,
 			reasoning,
 			changes: enrichedChanges,
+			removals,
 			repos: this.allRepos,
 		};
 		emit({ type: "result", data: result });

package/server/forge/core/prompts.js

@@ -307,22 +307,29 @@ ${ciContext.trim()}`
 		? `"feat: add browseable mixes section with platinum-gated publishing"`
 		: `"fix: resolve token refresh race condition in AuthService"`;
 
+	const collateralGuard = `COLLATERAL DAMAGE GUARD — read BEFORE writing any "proposed" content:
+Your default when modifying a file is to PRESERVE every existing line that is not directly related to the issue. Do not silently remove, reorganize, or simplify wrapper elements, imports, sibling components, or unrelated UI features (version displays, badges, icons, etc.).
+If you believe existing code MUST be removed or restructured for the change to work, you MUST declare each removal in the top-level "removals" array. Each entry needs: the file path, a short description of what was removed, and why the removal is necessary. An empty "removals" array (or omitting it) means "I preserved everything unrelated."
+The reviewer will see these as warnings and must acknowledge them before the change can be committed — so never silently drop existing functionality.`;
+
 	const discipline = isFeature
 		? `Feature implementation rules (read BEFORE writing any change):
 1. Follow the issue specification precisely. If the issue says to modify a specific file, modify that file. If it says to create a new file, create it. Do NOT invent changes the issue doesn't ask for.
 2. When the issue references existing components or patterns to reuse, base your implementation on the existing patterns in the "Relevant files" section.
 3. For new files, follow the naming conventions, import style, and structure of the existing codebase.
 4. Be aware of existing routes, tabs, and UI sections that may OVERLAP with what you're implementing. If the issue creates a new "/mixes" route, check whether the codebase already has mixes-related UI elsewhere (e.g. a tab inside another page) and note any conflict in "explanation".
-5. In your "explanation", state (a) which existing patterns you followed, (b) what new files you created, and (c) any conflicts or considerations the reviewer should know about.`
+5. In your "explanation", state (a) which existing patterns you followed, (b) what new files you created, and (c) any conflicts or considerations the reviewer should know about.
+6. ${collateralGuard}`
 		: `Root-cause discipline (read BEFORE writing any change):
 1. Identify the ORIGIN of the bad value, not just where it's observed. If a guard, assertion, or validation is failing, trace the value one or two frames up and name the caller that produced the bad input.
 2. A fix that only makes an error message clearer (e.g. replacing \`assertIsDefined(x)\` with \`if (!x) toast.error(…)\`) is NOT a fix — it is a symptom suppressor. Reject it and propose the upstream fix instead.
 3. In your "explanation", state (a) where the bad value originates, (b) why the fix closes the reported symptom end-to-end, and (c) what would have to be true for the reported error to still appear after your change.
-4. If the origin is in a file that was not selected in pass 1, your "changes" should include that file. Do not constrain yourself to only the files listed under "Relevant files" when doing so would force a symptom-level patch.`;
+4. If the origin is in a file that was not selected in pass 1, your "changes" should include that file. Do not constrain yourself to only the files listed under "Relevant files" when doing so would force a symptom-level patch.
+5. ${collateralGuard}`;
 
 	return `Respond with ONLY a raw JSON object — no markdown, no prose, no code fences.
 
-Schema: {"title": "${titlePrefix}: concise description of the actual change (max 72 chars)", "explanation": "...", "changes": [{"repo": "<repo id>", "file": "...", "action": "modify|create|delete", "proposed": "<full file content>", "summary": "..."}]}
+Schema: {"title": "${titlePrefix}: concise description of the actual change (max 72 chars)", "explanation": "...", "changes": [{"repo": "<repo id>", "file": "...", "action": "modify|create|delete", "proposed": "<full file content>", "summary": "..."}], "removals": [{"file": "...", "what": "short description of removed code", "why": "reason this removal is necessary"}]}
 
 ${isFeature ? "Implement this feature." : "Propose a targeted fix for this issue."}