apps/ui/src/components/views/settings-view/providers/opencode-settings-tab.tsx (1)

6-6: Same shared-package import guideline applies here.
As per coding guidelines, ...

apps/ui/src/components/views/settings-view/providers/cursor-settings-tab.tsx (1)

15-15: Same shared-package import guideline applies here.
As per coding guidelines, ...

graph-layout-bug.md-1-203 (1)

1-203: This file appears to be internal debugging notes rather than finished documentation.

The commit bundles multiple unrelated changes (TypeScript error fixes, Claude agents, RPM installation docs, and this debugging document). While docs/install-fedora.md is legitimate project documentation, graph-layout-bug.md contains unfinished investigation questions, hypotheses, and code snippets typical of developer working notes.

Consider one of the following:

• Convert to a GitHub issue to track the graph layout bug if still relevant
• Remove entirely if the bug has been resolved
• Move to a dedicated docs/troubleshooting/ directory if this is intended as long-term developer documentation (currently no such directory exists)

apps/ui/src/components/views/board-view/components/selection-action-bar.tsx-55-58 (1)

55-58: Guard Verify when no handler is provided.
If onVerify is undefined, the dialog confirms a no-op. Disable the action (and guard the handler) to avoid dead clicks.

🔧 Suggested fix

  const allSelected = selectedCount === totalCount && totalCount > 0;
+ const canVerify = selectedCount > 0 && !!onVerify;

  const handleConfirmVerify = () => {
    setShowVerifyDialog(false);
-   onVerify?.();
+   if (!onVerify) return;
+   onVerify();
  };
...
          {mode === 'waiting_approval' && (
            <Button
              variant="default"
              size="sm"
              onClick={handleVerifyClick}
-             disabled={selectedCount === 0}
+             disabled={!canVerify}
              className="h-8 bg-green-600 hover:bg-green-700 disabled:opacity-50"
              data-testid="selection-verify-button"
            >

Also applies to: 110-118, 186-218

apps/ui/src/components/views/board-view.tsx-719-747 (1)

719-747: Guard bulk verify to only affect waiting_approval items.
If selection state ever desyncs, this could accidentally verify non‑waiting items. A narrow filter keeps the bulk action safe.

🛠️ Proposed fix

-      const featureIds = Array.from(selectedFeatureIds);
+      const featureIds = Array.from(selectedFeatureIds).filter((id) =>
+        hookFeatures.some(
+          (feature) => feature.id === id && feature.status === 'waiting_approval'
+        )
+      );
+      if (featureIds.length === 0) {
+        toast.info('No waiting approval features selected');
+        return;
+      }
@@
-  }, [currentProject, selectedFeatureIds, updateFeature, exitSelectionMode]);
+  }, [currentProject, selectedFeatureIds, hookFeatures, updateFeature, exitSelectionMode]);

apps/ui/src/components/views/board-view.tsx-954-978 (1)

954-978: Add error handling and clear pending plan on project change.

The loadSavedPlan async function lacks error handling and should log failures. More importantly, the guard || pendingBacklogPlan blocks loading a new project's saved plan if a plan from the previous project remains set. Pending backlog plans should be cleared when currentProject changes to ensure each project can load its own saved plan.

🛠️ Proposed fix (error handling)

     const loadSavedPlan = async () => {
+      try {
         const api = getElectronAPI();
         if (!api?.backlogPlan) return;
 
         const result = await api.backlogPlan.status(currentProject.path);
         if (
           isActive &&
           result.success &&
           result.savedPlan?.result &&
           result.savedPlan.result.changes?.length > 0
         ) {
           setPendingBacklogPlan(result.savedPlan.result);
         }
+      } catch (error) {
+        logger.error('Failed to load saved backlog plan:', error);
+      }
     };

For the project switch issue, consider either clearing pendingBacklogPlan when currentProject changes (add a separate effect), or restructure the guard to allow loading when switching projects even if a stale plan exists.

apps/ui/src/components/views/settings-view/providers/provider-toggle.tsx-17-36 (1)

17-36: Add an accessible name for the Switch.
The Label isn’t associated with the Switch, so assistive tech may announce it as unnamed. Add id/aria-labelledby (or aria-label) to ensure accessibility.

♿️ Proposed fix

 export function ProviderToggle({ provider, providerLabel }: ProviderToggleProps) {
   const { disabledProviders, toggleProviderDisabled } = useAppStore();
   const isDisabled = disabledProviders.includes(provider);
+  const labelId = `provider-toggle-${provider}-label`;
+  const switchId = `provider-toggle-${provider}`;

   return (
     <div className="flex items-center justify-between p-4 rounded-xl bg-accent/20 border border-border/30">
       <div className="flex items-center gap-3">
@@
         <div>
-          <Label className="text-sm font-medium">Show {providerLabel} in model dropdowns</Label>
+          <Label id={labelId} htmlFor={switchId} className="text-sm font-medium">
+            Show {providerLabel} in model dropdowns
+          </Label>
           <p className="text-xs text-muted-foreground mt-0.5">
             {isDisabled
               ? `${providerLabel} models are hidden from all model selectors`
               : `${providerLabel} models appear in model selection dropdowns`}
           </p>
         </div>
       </div>
       <Switch
+        id={switchId}
+        aria-labelledby={labelId}
         checked={!isDisabled}
         onCheckedChange={(checked) => toggleProviderDisabled(provider, !checked)}
       />
     </div>
   );
 }

docs/install-fedora.md-371-388 (1)

371-388: Same URL placeholder issue in the manual update section.

Line 387 has the same <version> placeholder problem as noted earlier in the installation section.

📝 Suggested fix

 # Or reinstall latest release
 sudo dnf remove automaker
-sudo dnf install https://github.com/AutoMaker-Org/automaker/releases/latest/download/Automaker-<version>-x86_64.rpm
+# Download the latest .rpm from https://github.com/AutoMaker-Org/automaker/releases
+# Then install with: sudo dnf install ./Automaker-<VERSION>-x86_64.rpm

docs/install-fedora.md-44-58 (1)

44-58: The /latest/download/ URL pattern doesn't support version placeholders.

The GitHub releases /latest/download/ endpoint serves the actual latest release file, not a versioned path. Users cannot substitute <version> in this URL.

Either use the pattern for a specific version download or document how to find the actual filename.

📝 Suggested fix

-sudo dnf install https://github.com/AutoMaker-Org/automaker/releases/latest/download/Automaker-<version>-x86_64.rpm
+# Replace VERSION with actual version (e.g., 0.11.0)
+sudo dnf install https://github.com/AutoMaker-Org/automaker/releases/download/v<VERSION>/Automaker-<VERSION>-x86_64.rpm
+
+# Or download from the releases page and install locally (recommended)

Or alternatively, if electron-builder produces a predictable filename without version:

-sudo dnf install https://github.com/AutoMaker-Org/automaker/releases/latest/download/Automaker-<version>-x86_64.rpm
+sudo dnf install https://github.com/AutoMaker-Org/automaker/releases/latest/download/Automaker-x86_64.rpm

apps/ui/src/components/views/board-view/dialogs/backlog-plan-dialog.tsx-461-461 (1)

461-461: Button label may be misleading.

The button label changed from "Generate Plan" to "Apply Changes", but at this point (input mode), the user is actually initiating plan generation, not applying changes. "Apply Changes" is more appropriate for the review mode. Consider keeping "Generate Plan" or using something like "Create Plan".

apps/server/src/routes/settings/routes/update-global.ts-61-76 (1)

61-76: Validate serverLogLevel before persisting settings.

If a client sends an unsupported value, it can be stored while the runtime log level remains unchanged. Consider rejecting invalid values before updateGlobalSettings to avoid state mismatch.

Proposed guard before persisting

-      const settings = await settingsService.updateGlobalSettings(updates);
+      if ('serverLogLevel' in updates && updates.serverLogLevel) {
+        const level = LOG_LEVEL_MAP[updates.serverLogLevel];
+        if (level === undefined) {
+          res.status(400).json({ success: false, error: 'Invalid serverLogLevel' });
+          return;
+        }
+      }
+
+      const settings = await settingsService.updateGlobalSettings(updates);

apps/server/src/routes/backlog-plan/routes/generate.ts-45-53 (1)

45-53: Duplicate setRunningState(true) call.

setRunningState(true) is called on line 45, then setRunningDetails(...) is called, and then setRunningState(true, abortController) is called again on line 53. The first call is immediately overwritten by the second.

Remove the redundant first call on line 45.

Proposed fix

-      setRunningState(true);
       setRunningDetails({
         projectPath,
         prompt,
         model,
         startedAt: new Date().toISOString(),
       });
       const abortController = new AbortController();
       setRunningState(true, abortController);

apps/server/src/routes/backlog-plan/routes/clear.ts-11-16 (1)

11-16: Validate projectPath type before use.
Non-string values can be coerced into paths and lead to unexpected deletes.

✅ Suggested fix

-      const { projectPath } = req.body as { projectPath: string };
+      const { projectPath } = req.body as { projectPath?: unknown };

-      if (!projectPath) {
+      if (typeof projectPath !== 'string' || projectPath.trim().length === 0) {
         res.status(400).json({ success: false, error: 'projectPath required' });
         return;
       }

apps/ui/src/components/views/settings-view/components/import-export-dialog.tsx-41-57 (1)

41-57: Missing defensive check for response.settings.

If the API returns { success: true } without a settings field (e.g., due to server-side bug), JSON.stringify(response.settings) will produce "undefined" which may confuse users.

🔧 Suggested defensive check

 const loadSettings = async () => {
   setIsLoading(true);
   try {
     const response = await apiGet<SettingsResponse>('/api/settings/global');
-    if (response.success) {
+    if (response.success && response.settings) {
       const formatted = JSON.stringify(response.settings, null, 2);
       setJsonValue(formatted);
       setOriginalValue(formatted);
       setParseError(null);
+    } else if (response.success) {
+      toast.error('Settings data is empty');
     }
   } catch (error) {

apps/ui/src/components/views/graph-view/graph-canvas.tsx-424-439 (1)

424-439: Remove debug console.log statements before merging.

These console.log statements appear to be debugging artifacts and should be removed or replaced with the project's logger utility for consistency:

   const handleEdgesDelete = useCallback(
     (deletedEdges: Edge[]) => {
-      console.log('onEdgesDelete triggered', deletedEdges);
       deletedEdges.forEach((edge) => {
         if (nodeActionCallbacks?.onDeleteDependency) {
-          console.log('Calling onDeleteDependency from onEdgesDelete', {
-            source: edge.source,
-            target: edge.target,
-          });
           nodeActionCallbacks.onDeleteDependency(edge.source, edge.target);
         }
       });
     },
     [nodeActionCallbacks]
   );

If logging is needed for debugging, import and use createLogger from @automaker/utils/logger as used elsewhere in the codebase.

apps/ui/src/components/usage-popover.tsx (2)

327-328: Remove unused variables after refactor.

maxPercentage and isStale are no longer used since the trigger now derives these values from tabInfo. Consider removing them to avoid confusion.

-  const maxPercentage = Math.max(claudeMaxPercentage, codexMaxPercentage);
-  const isStale = activeTab === 'claude' ? isClaudeStale : isCodexStale;
-

---

336-354: Consider using useMemo for tab-derived state.

The helper function pattern works, but creating and invoking a function on each render is slightly verbose. A useMemo would be more idiomatic for derived state.

♻️ Optional refactor

-  // Determine which provider icon and percentage to show based on active tab
-  const getTabInfo = () => {
-    if (activeTab === 'claude') {
-      return {
-        icon: AnthropicIcon,
-        percentage: claudeMaxPercentage,
-        isStale: isClaudeStale,
-      };
-    }
-    return {
-      icon: OpenAIIcon,
-      percentage: codexMaxPercentage,
-      isStale: isCodexStale,
-    };
-  };
-
-  const tabInfo = getTabInfo();
+  // Determine which provider icon and percentage to show based on active tab
+  const tabInfo = useMemo(() => {
+    if (activeTab === 'claude') {
+      return {
+        icon: AnthropicIcon,
+        percentage: claudeMaxPercentage,
+        isStale: isClaudeStale,
+      };
+    }
+    return {
+      icon: OpenAIIcon,
+      percentage: codexMaxPercentage,
+      isStale: isCodexStale,
+    };
+  }, [activeTab, claudeMaxPercentage, codexMaxPercentage, isClaudeStale, isCodexStale]);

apps/ui/src/components/layout/project-switcher/project-switcher.tsx (1)

419-445: LGTM!

The Wiki button implementation is clean with proper feature flag gating and consistent styling patterns. The active state provides clear visual feedback, and the non-active state matches the Bug Report button styling.

One minor observation: the array syntax inside the cn() ternary works but could be simplified to template strings for consistency with other buttons in this file. This is purely stylistic and optional.

♻️ Optional: Simplify cn() ternary (stylistic)

               className={cn(
                 'w-full aspect-square rounded-xl flex items-center justify-center',
                 'transition-all duration-200 ease-out',
                 isWikiActive
-                  ? [
-                      'bg-gradient-to-r from-brand-500/20 via-brand-500/15 to-brand-600/10',
-                      'text-foreground',
-                      'border border-brand-500/30',
-                      'shadow-md shadow-brand-500/10',
-                    ]
-                  : [
-                      'text-muted-foreground hover:text-foreground',
-                      'hover:bg-accent/50 border border-transparent hover:border-border/40',
-                      'hover:shadow-sm hover:scale-105 active:scale-95',
-                    ]
+                  ? 'bg-gradient-to-r from-brand-500/20 via-brand-500/15 to-brand-600/10 text-foreground border border-brand-500/30 shadow-md shadow-brand-500/10'
+                  : 'text-muted-foreground hover:text-foreground hover:bg-accent/50 border border-transparent hover:border-border/40 hover:shadow-sm hover:scale-105 active:scale-95'
               )}

apps/ui/src/components/layout/sidebar/hooks/use-running-agents.ts (1)

67-81: Avoid duplicate initial fetches on mount.
The backlogPlan effect triggers a fetch on mount, but the autoMode effect already does this unconditionally, so this causes duplicate calls/logs.

♻️ Proposed change

-    fetchRunningAgentsCount();
-
     const unsubscribe = api.backlogPlan.onEvent(() => {
       fetchRunningAgentsCount();
     });

apps/server/src/routes/features/routes/bulk-delete.ts (1)

33-53: Prevent batch aborts on delete exceptions.

If featureLoader.delete can throw/reject, Promise.all will reject and return 500, skipping partial results. Consider per-item try/catch (mirroring bulk-update) so failures are isolated and reported per feature.

Proposed guard

-        const batchResults = await Promise.all(
-          batch.map(async (featureId) => {
-            const success = await featureLoader.delete(projectPath, featureId);
-            if (success) {
-              return { featureId, success: true };
-            }
-            return {
-              featureId,
-              success: false,
-              error: 'Deletion failed. Check server logs for details.',
-            };
-          })
-        );
+        const batchResults = await Promise.all(
+          batch.map(async (featureId) => {
+            try {
+              const success = await featureLoader.delete(projectPath, featureId);
+              if (success) {
+                return { featureId, success: true };
+              }
+              return {
+                featureId,
+                success: false,
+                error: 'Deletion failed. Check server logs for details.',
+              };
+            } catch (error) {
+              return {
+                featureId,
+                success: false,
+                error: getErrorMessage(error),
+              };
+            }
+          })
+        );

apps/ui/src/components/views/ideation-view/components/ideation-dashboard.tsx (1)

389-401: Snapshot discard targets when opening the confirm dialog.

confirmDiscardAll uses the live filteredSuggestions, so items that appear while the dialog is open can be discarded without the user explicitly confirming them. Capture the list at dialog open and reuse it for both the description and the actual deletion.

♻️ Suggested update

-  const [showDiscardConfirm, setShowDiscardConfirm] = useState(false);
+  const [showDiscardConfirm, setShowDiscardConfirm] = useState(false);
+  const [pendingDiscard, setPendingDiscard] = useState<
+    Array<{ jobId: string; suggestionId: string }>
+  >([]);

-  const handleDiscardAll = useCallback(() => {
-    setShowDiscardConfirm(true);
-  }, []);
+  const handleDiscardAll = useCallback(() => {
+    setPendingDiscard(
+      filteredSuggestions.map(({ suggestion, job }) => ({
+        jobId: job.id,
+        suggestionId: suggestion.id,
+      }))
+    );
+    setShowDiscardConfirm(true);
+  }, [filteredSuggestions]);

-  const confirmDiscardAll = useCallback(() => {
-    const count = filteredSuggestions.length;
-    for (const { suggestion, job } of filteredSuggestions) {
-      removeSuggestionFromJob(job.id, suggestion.id);
-    }
-    toast.info(`Discarded ${count} ${pluralizeIdea(count)}`);
-  }, [filteredSuggestions, removeSuggestionFromJob]);
+  const confirmDiscardAll = useCallback(() => {
+    const count = pendingDiscard.length;
+    for (const { jobId, suggestionId } of pendingDiscard) {
+      removeSuggestionFromJob(jobId, suggestionId);
+    }
+    setPendingDiscard([]);
+    toast.info(`Discarded ${count} ${pluralizeIdea(count)}`);
+  }, [pendingDiscard, removeSuggestionFromJob]);

-        description={`Are you sure you want to discard ${filteredSuggestions.length} ${pluralizeIdea(filteredSuggestions.length)}? This cannot be undone.`}
+        description={`Are you sure you want to discard ${pendingDiscard.length} ${pluralizeIdea(pendingDiscard.length)}? This cannot be undone.`}

Also applies to: 515-521

apps/ui/src/components/views/board-view/hooks/use-board-actions.ts (1)

345-354: Consider potential stale closure if features change during async operation.

The features array captured by the callback could become stale if features are modified by another operation while handleUpdateFeature is executing. For typical single-user scenarios this is unlikely to cause issues, but for robustness, you could use a ref or fetch fresh features from the store inside the callback.

apps/ui/src/components/views/board-view/dialogs/edit-feature-dialog.tsx (1)

166-182: Minor: allFeatures dependency may cause unnecessary effect runs.

If allFeatures gets a new reference on each parent render (common with selectors), this effect will re-run even when the actual feature list hasn't changed meaningfully. Consider memoizing allFeatures in the parent component or using a stable reference check.

apps/ui/src/components/views/board-view.tsx (1)

688-717: Consider deduplicating selectable-ID filtering logic.
allSelectableWaitingApprovalFeatureIds mirrors allSelectableFeatureIds almost exactly; extracting a shared predicate/helper would reduce drift risk over time.

apps/ui/src/components/views/board-view/hooks/use-board-persistence.ts (1)

34-46: Consider reducing log verbosity and avoiding potential PII exposure.

Logging the full result.feature object at info level may:

1. Expose sensitive data in feature descriptions (user input, requirements with PII)
2. Create verbose logs in production

Suggested improvement

-        logger.info('Calling API features.update', { featureId, updates });
+        logger.debug('Calling API features.update', { featureId, updateKeys: Object.keys(updates) });
         const result = await api.features.update(
           currentProject.path,
           featureId,
           updates,
           descriptionHistorySource,
           enhancementMode,
           preEnhancementDescription
         );
-        logger.info('API features.update result', {
-          success: result.success,
-          feature: result.feature,
-        });
+        logger.debug('API features.update result', {
+          success: result.success,
+          featureId: result.feature?.id,
+        });

apps/ui/src/components/views/settings-view/providers/codex-settings-tab.tsx (1)

8-8: Prefer shared-package imports over new relative paths.
Please re-export ProviderToggle via a shared package and import from @automaker/* instead of ./provider-toggle. As per coding guidelines, ...

apps/ui/src/components/views/board-view/dialogs/agent-output-modal.tsx (1)

283-317: Consider adding type safety for the backlog plan event.

The event parameter is typed as any on line 290. Consider defining a proper type for backlog plan events to improve type safety and enable better IDE support.

♻️ Optional: Add type definition

// Define near the top of the file or in a types file
type BacklogPlanEvent =
  | { type: 'backlog_plan_progress'; content?: string }
  | { type: 'backlog_plan_error'; error?: string }
  | { type: 'backlog_plan_complete' }
  | { type: string }; // fallback for unknown events

// Then use it:
const unsubscribe = api.backlogPlan.onEvent((event: BacklogPlanEvent) => {

docs/install-fedora.md (1)

286-299: Minor improvements for network troubleshooting commands.

1. ping claude.ai tests the marketing website, not the API endpoint. Consider using api.anthropic.com.
2. Echoing the API key value could expose it in shell history or logs. Consider just checking if it's set.

♻️ Suggested improvements

 # Test internet connectivity
-ping claude.ai
+ping -c 3 api.anthropic.com

 # Test API access
 curl -I https://api.anthropic.com

-# Verify API key
-echo $ANTHROPIC_API_KEY
+# Verify API key is set (without exposing the value)
+[ -n "$ANTHROPIC_API_KEY" ] && echo "API key is set" || echo "API key is NOT set"

apps/ui/src/components/views/board-view/dialogs/backlog-plan-dialog.tsx (1)

203-211: Add error handling for the clear API call.

The handleDiscard function calls backlogPlan.clear() but doesn't handle potential failures. While the UI state is reset regardless, a failed clear could leave stale data on the server.

Consider adding error handling

 const handleDiscard = useCallback(async () => {
   setPendingPlanResult(null);
   setMode('input');

   const api = getElectronAPI();
   if (api?.backlogPlan) {
-    await api.backlogPlan.clear(projectPath);
+    try {
+      await api.backlogPlan.clear(projectPath);
+    } catch (error) {
+      logger.warn('Failed to clear backlog plan from server', { error, projectPath });
+      // Non-critical: local state is already cleared
+    }
   }
 }, [setPendingPlanResult, projectPath]);

apps/ui/src/components/views/graph-view/hooks/use-graph-layout.ts (1)

22-23: layoutVersion returned as ref value won't trigger re-renders.

Returning layoutVersion.current directly means consumers won't re-render when the layout version changes, since ref mutations don't trigger React updates. If consumers need to react to new layouts, they should use layoutedElements.didRelayout instead, or the version should be stored in state.

If didRelayout is the intended signal for consumers (which it appears to be based on the code), consider documenting this or removing layoutVersion from the public API to avoid confusion.

Also applies to: 130-135

apps/server/src/routes/settings/routes/update-global.ts (1)

15-26: Prefer shared-package import for server runtime helpers.

setRequestLoggingEnabled is imported via a relative path. If this is part of the shared server surface, please re-export it from an @automaker/* package and import from there to match the repo import rules. As per coding guidelines, use shared package imports instead of relative paths.

apps/ui/src/components/views/graph-view/components/dependency-edge.tsx (1)

77-86: Consider gating debug logs or routing through the UI logger.

The new console logging is helpful during development but can be noisy in production. If there’s a client logger, consider using it or wrapping logs behind a dev-only check.

apps/server/src/routes/features/index.ts (1)

7-7: Use shared @automaker/* import path if available.
This new relative import appears to conflict with the project guideline to prefer shared package imports.

Based on coding guidelines, prefer @automaker/* if SettingsService is exposed there.

apps/server/src/routes/backlog-plan/common.ts (1)

76-88: Validate stored plan shape before returning it.
parsed?.result?.changes being truthy doesn’t guarantee it’s an array; downstream code may assume array semantics.

♻️ Suggested validation tweak

-    if (!parsed?.result?.changes) {
+    if (!Array.isArray(parsed?.result?.changes)) {
       return null;
     }

apps/server/src/routes/suggestions/generate-suggestions.ts (1)

154-158: Consider adding a fallback for unknown suggestion types.

If suggestionType is not one of the expected keys (features, refactoring, security, performance), typePrompts[suggestionType] returns undefined, and the fallback typePrompts.features is used. This is reasonable, but an explicit log warning would help debugging unexpected types.

💡 Optional: Add a warning for unknown suggestion types

+  if (!typePrompts[suggestionType]) {
+    logger.warn(`Unknown suggestion type "${suggestionType}", falling back to features`);
+  }
+
   const prompt = `${typePrompts[suggestionType] || typePrompts.features}

apps/ui/src/components/views/settings-view/event-hooks/event-hooks-section.tsx (3)

26-28: Consider adding a confirmation dialog before deleting hooks.

Deleting a hook is a destructive action that cannot be undone. A confirmation step would prevent accidental deletions, especially for complex webhook configurations.

💡 Suggested approach

Consider using a confirmation dialog or at least a window.confirm() before deletion:

 const handleDeleteHook = (hookId: string) => {
+  if (!window.confirm('Are you sure you want to delete this hook?')) {
+    return;
+  }
   setEventHooks(eventHooks.filter((h) => h.id !== hookId));
 };

Or better, use a proper confirmation dialog component for consistency with the rest of the UI.

---

179-182: Type assertions can be replaced with type guards or discriminated union access.

The inline type assertions (hook.action as { type: 'shell'; command: string }) work but are verbose. Since EventHook.action is likely a discriminated union, you can leverage the isShell check already performed.

💡 Cleaner access pattern

-        <p className="text-xs text-muted-foreground truncate">
-          {isShell
-            ? (hook.action as { type: 'shell'; command: string }).command
-            : (hook.action as { type: 'http'; url: string }).url}
-        </p>
+        <p className="text-xs text-muted-foreground truncate">
+          {'command' in hook.action ? hook.action.command : hook.action.url}
+        </p>

Or extract typed accessors based on the discriminated union if the types are defined that way.

---

188-198: Add accessible labels to icon-only buttons.

The edit and delete buttons use only icons without accessible text. Screen readers won't convey the button purpose.

♿ Add aria-labels for accessibility

-        <Button variant="ghost" size="icon" className="h-8 w-8" onClick={onEdit}>
+        <Button variant="ghost" size="icon" className="h-8 w-8" onClick={onEdit} aria-label="Edit hook">
           <Pencil className="w-4 h-4" />
         </Button>
         <Button
           variant="ghost"
           size="icon"
           className="h-8 w-8 text-destructive hover:text-destructive"
           onClick={onDelete}
+          aria-label="Delete hook"
         >
           <Trash2 className="w-4 h-4" />
         </Button>

apps/ui/src/components/ui/json-syntax-editor.tsx (1)

96-100: Consider using @codemirror/lang-json for stricter JSON validation.

The code uses StreamLanguage.define(javascript) from the legacy modes, which provides JavaScript syntax highlighting but lacks JSON-specific validation. Since this is a dedicated JSON editor component, using @codemirror/lang-json would enforce strict JSON parsing (no comments, no trailing commas) and provide built-in JSON linting via jsonParseLinter().

This matters if the editor should reject invalid JSON; the current approach accepts any JavaScript-like syntax. If lenient JSON5-like syntax is intentional, the current approach is acceptable.

apps/ui/src/components/views/settings-view/prompts/tab-configs.ts (1)

15-29: Prefer shared-package import for TabConfig.

This new file uses a relative import for TabConfig. If this type is meant to be shared across UI modules, please expose it via an @automaker/* package and import from there to align with the shared-package import rule.
As per coding guidelines, please avoid relative imports for shared types.

apps/server/src/routes/app-spec/generate-spec.ts (1)

18-20: Use shared-package import for settings helpers.

The updated import is still a relative path. If settings-helpers is a shared module, please expose it via an @automaker/* package and import from there to comply with the shared-package import rule.
As per coding guidelines, avoid relative imports for shared modules.

apps/server/src/routes/features/routes/generate-title.ts (1)

12-13: Use shared-package imports for settings helpers.

These new imports are relative. If settings-service or settings-helpers are shared modules, please expose them via @automaker/* and import from there.
As per coding guidelines, avoid relative imports for shared modules.

apps/ui/src/components/views/settings-view/prompts/prompt-customization-section.tsx (1)

31-44: Type safety reduced in updatePrompt signature.

The field parameter is now string instead of a typed key. While this is a reasonable tradeoff for the config-driven approach, runtime errors could occur if field names in TAB_CONFIGS don't match the actual interface properties.

Consider adding runtime validation or keeping a union type for field names if type safety is important here.

apps/ui/src/components/views/settings-view/prompts/components.tsx (1)

125-159: Type assertion could be improved with a type guard or safer access pattern.

The type assertion on line 149 (promptCustomization?.[category] as Record<string, CustomPrompt> | undefined) is necessary due to the dynamic category access, but could be fragile if the PromptCustomization structure changes.

Consider extracting this into a helper function for reusability and type safety:

function getCustomPromptValue(
  customization: PromptCustomization | undefined,
  category: keyof PromptCustomization,
  key: string
): CustomPrompt | undefined {
  const categoryData = customization?.[category];
  if (categoryData && typeof categoryData === 'object') {
    return (categoryData as Record<string, CustomPrompt>)[key];
  }
  return undefined;
}

apps/ui/src/components/views/graph-view/graph-canvas.tsx (1)

275-290: Consider adding a guard to prevent multiple concurrent layout operations.

The timeout-based layout triggering could potentially cause issues if the component re-renders multiple times rapidly. The cleanup function handles the timeout, but hasLayoutWithEdges.current is set synchronously before the timeout fires.

This is likely fine in practice, but for robustness:

   useEffect(() => {
     // Only run once: when we have nodes and edges but haven't done a layout with edges yet
     if (!hasLayoutWithEdges.current && layoutedNodes.length > 0 && layoutedEdges.length > 0) {
       hasLayoutWithEdges.current = true;
       // Small delay to ensure React Flow is mounted and ready
       const timeoutId = setTimeout(() => {
+        // Double-check we still have nodes/edges (component might have changed)
+        if (layoutedNodes.length === 0) return;
         const { nodes: relayoutedNodes, edges: relayoutedEdges } = runLayout('LR');

apps/server/src/services/auto-mode-service.ts (3)

789-790: Consider caching prompts when executing multiple pipeline steps.

getPromptCustomization is called at the start of executePipelineSteps, but executeFeature already fetched prompts earlier. If this method is called from executeFeature, the prompts are fetched twice.

Since prompts are used in the loop over steps, the current placement is reasonable for isolation. However, you could pass prompts as a parameter from the caller to avoid redundant settings reads.

---

2871-2908: Redundant prompt fetch in multi-agent task execution loop.

getPromptCustomization is called here (line 2872-2875), but prompts were already fetched earlier at line 582-583 in executeFeature. This results in an unnecessary settings read.

Consider passing the already-fetched prompts object through to this code path, or extract it to a variable accessible throughout the method.

♻️ Suggested approach

Since runAgent is called from executeFeature which already has prompts, you could:

1. Add prompts to the options parameter of runAgent
2. Or restructure to fetch prompts once at the top of executeFeature and pass them through

This would eliminate the redundant getPromptCustomization call and improve performance.

---

2992-3005: Same issue: redundant prompt fetch in single-agent fallback path.

This is the same pattern as the multi-agent path - getPromptCustomization is called again despite prompts being available from the outer scope.