Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/admin/dashboard/static/css/dashboard.css`:
- Around line 2238-2243: The 16×16 control (the rule with width: 16px; height:
16px; border-radius: 4px; border: 1px solid color-mix(...); background:
transparent) has a too-small hit area on touch — keep the 16px visual but add a
larger, invisible hit target with a pseudo-element (e.g., ::before or ::after)
that is position: absolute, centered with negative offsets or increased inset to
expand the clickable area, has transparent background, and pointer-events: auto;
ensure the original element remains visually 16×16 and retains its
border/background while the pseudo-element increases the interactive size.

In `@internal/app/app.go`:
- Around line 730-739: dashboardFallbackModeValue currently returns any
non-empty string from cfg.Fallback.DefaultMode, which can expose unsupported
modes in the UI; change it to validate the normalized mode against the allowed
values ("auto" and "manual") and return config.FallbackModeOff for any other
value. Update dashboardFallbackModeValue to normalize the mode (as it already
does), then if mode == "auto" return config.FallbackModeAuto, else if mode ==
"manual" return config.FallbackModeManual, otherwise return
config.FallbackModeOff so that it matches the behavior of
fallbackFeatureEnabledGlobally().

---

Outside diff comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 20-31: The form is initializing features.fallback to true for all
new execution plans so hidden fallback toggles get persisted even when
FEATURE_FALLBACK_MODE is off; change the initialization in executionPlanForm
(and the other form defaults around the indicated blocks) to set
features.fallback = false for new plans, and update buildExecutionPlanRequest to
only carry a persisted fallback value when the form was hydrated from an
existing plan (e.g., detect hydration via a flag like isHydrated or by checking
if an existing plan object was loaded) so hidden fallback values are not
implicitly enabled for newly created workflows.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/admin/dashboard/static/js/modules/audit-list.js`:
- Around line 36-38: The current flow awaits
this.prefetchAuditExecutionPlans(this.auditLog.entries) inside the outer
try/catch so any rejection clears this.auditLog; instead, split the prefetch
into its own try/catch: after successfully setting this.auditLog (and after
parse), check typeof this.prefetchAuditExecutionPlans === 'function' and then
call and await it inside a nested try/catch that catches and logs the error (or
handles it) without rethrowing, so failures in prefetchAuditExecutionPlans do
not reset or modify this.auditLog or affect the successful fetch/parse path.

In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 201-239: executionPlanPreview currently calls
executionPlanSourceGuardrails which coerces blank/whitespace step strings into
0, causing previews to disagree with submit-time validation in
buildExecutionPlanRequest/validateExecutionPlanRequest; fix by reusing the same
submit-time parsing logic (or at minimum trim the step strings before Number()
conversion) inside executionPlanPreview (and the parallel hydration code paths)
so blank or whitespace-only step values remain invalid and preview/hydration
match buildExecutionPlanRequest/validateExecutionPlanRequest behavior.
- Around line 437-456: fetchExecutionPlanRuntimeConfig never uses the request
timeout/AbortController used by fetchExecutionPlansPage, so a hung
/admin/api/v1/dashboard/config fetch can stall refreshes; update
fetchExecutionPlanRuntimeConfig (and the similar block around lines 573-577) to
create an AbortController, pass its signal into fetch, start a timeout (matching
the workflow list timeout used by fetchExecutionPlansPage) that calls
controller.abort(), and clear the timeout on success/failure so the fetch will
fail fast and not block execution plan updates.
- Around line 855-883: The responseSuccess calculation in epRuntimeFromEntry
incorrectly treats only 200 as success; update responseSuccess (and consequently
aiSuccess) to consider any 2xx HTTP status as successful by checking that
statusCode is a finite number and 200 <= statusCode < 300 (ensure null/undefined
statusCode remains treated as non-success). Modify the expression that defines
responseSuccess inside epRuntimeFromEntry to use that range check so
201/204/etc. are classified as successes.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 814-843: executionPlanAuditChart can be called with source ===
null which causes executionPlanChartModel to suppress audit/async nodes; modify
executionPlanChartModel (or callsite) so the audit path is forced for
audit-chart rendering: update executionPlanChartModel(source, runtime, options)
to respect an explicit options.forceAudit (and options.forceAsync if needed) or
have executionPlanAuditChart call executionPlanChartModel with { forceCache:
true, forceAudit: true, forceAsync: true }; ensure the computed properties
showAudit and showAsync use options.forceAudit/options.forceAsync or fall back
to epHasAudit(source)/epHasAsync(source) so the Audit Log node is always shown
for executionPlanAuditChart.

In `@internal/admin/dashboard/templates/audit-pane.html`:
- Line 5: The "Copy Body" button lacks an explicit button type which can cause
it to act as a submit inside forms; update the button element that calls
copyAuditJSON (the button with class "pagination-btn" and
`@click.prevent`="copyAuditJSON({{.}}.copyBody, $event)") to include type="button"
so it does not trigger form submission.

In `@internal/admin/dashboard/templates/pagination.html`:
- Around line 5-6: The pagination buttons currently lack an explicit type and
will default to type="submit"; update the two button elements (the ones with
class "pagination-btn" and click handlers `@click`="{{.}}PrevPage()" and
`@click`="{{.}}NextPage()") to include type="button" so they never trigger form
submission when rendered inside a <form>, keeping existing :disabled bindings
({{.}}.offset, {{.}}.limit, {{.}}.total) and click handler names unchanged.

---

Outside diff comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 267-279: The helper executionPlanSourceGuardrails currently
filters guardrails with Number.isFinite, which still allows non-integer and
negative values (e.g., -1, 1.5); change the final filter to require
integer-only, positive steps (e.g., replace .filter((step) =>
Number.isFinite(step.step)) with .filter((step) => Number.isInteger(step.step)
&& step.step > 0)) so executionPlanPreview and openExecutionPlanCreate (which
reuse this helper) will only render guardrails that match
validateExecutionPlanRequest’s integer-only constraints.
- Around line 402-439: The current includeFallback logic preserves a hidden
fallback flag when an existing plan is edited and the scope is retargeted;
update buildExecutionPlanRequest so includeFallback is true only if the failover
controls are visible (executionPlanFailoverVisible()) OR the current form
explicitly contains a user-set features.fallback and the user has not retargeted
the scope (compare the current provider/model to the original
this.executionPlanForm.scope_provider/scope_model to detect retargeting);
reference buildExecutionPlanRequest, executionPlanFormHydrated,
executionPlanFailoverVisible, and features.fallback when making this change so
hidden fallback bits are not carried to a new scope.

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 407-445: buildExecutionPlanRequest currently only preserves
plan_payload.features.fallback when this.executionPlanFormHydrated is true,
which drops an explicitly disabled fallback when saving a fresh (non-hydrated)
form that matches the active workflow; update the includeFallback logic to also
preserve the existing fallback when the current scope matches
executionPlanHydratedScope (use the sameHydratedScope boolean and check
Object.prototype.hasOwnProperty.call(features, 'fallback')) even if
executionPlanFormHydrated is false, so payload.plan_payload.features.fallback is
set whenever the active workflow has a defined fallback; add a regression test
covering the non-hydrated save path (exercise executionPlanSubmitMode +
buildExecutionPlanRequest for a fresh form whose scope equals
executionPlanHydratedScope to assert fallback is preserved).

---

Duplicate comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 664-719: The fetchExecutionPlanVersion function leaves
executionPlanVersionRequests[normalizedID] pinned if a fetch stalls; mirror the
abort/clear-timeout pattern used elsewhere by creating an AbortController, pass
its signal into fetch('/admin/api/v1/execution-plans/' +
encodeURIComponent(normalizedID), { headers: this.headers(), signal }), start a
timeout that calls controller.abort() and deletes
executionPlanVersionRequests[normalizedID], clear that timeout when the request
completes successfully or errors, and ensure the existing finally block still
deletes executionPlanVersionRequests[normalizedID]; keep using
cacheExecutionPlanVersion, cacheMissingExecutionPlanVersion and
handleFetchResponse exactly as currently used for success/404/401/error
branches.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/admin/dashboard/static/js/modules/execution-plans.js`:
- Around line 764-807: fetchExecutionPlanVersion is missing an
AbortController/timeout and can hang; modify the async request block in
fetchExecutionPlanVersion to create an AbortController, pass its signal into
fetch, and set a 10_000 ms setTimeout that calls controller.abort(); clear the
timeout when fetch completes (in try/catch/finally) to avoid leaks; ensure the
abort is handled similarly to other fetches (call handleFetchResponse for
non-ok/401/404 as before or treat abort as null) and keep the existing cleanup
that deletes this.executionPlanVersionRequests[normalizedID].

In `@internal/admin/handler.go`:
- Around line 27-33: The handler currently exposes runtimeConfig as
map[string]string on the handler struct which makes the /dashboard/config
response shape open-ended; replace that with a named, strongly-typed response
struct (e.g., DashboardConfigResponse with the six explicit fields) and update
the handler method that serves /dashboard/config to populate and return that
struct, keeping any internal allowlist/filtering logic inside the handler (do
not expose the map). Update other usages of runtimeConfig in the file to
construct or read the typed struct as needed and apply the same change where
runtimeConfig is used in the other referenced blocks (the other handler methods
around the same file) so serialization, docs, and type safety are preserved.

In `@internal/app/app_test.go`:
- Around line 79-85: The test builds a config where ResponseCacheConfig.Simple
is assigned a value but that field is declared as a pointer
(*config.SimpleCacheConfig); change the composite literal to provide a pointer
by using &config.SimpleCacheConfig{...} for the Simple field (inside the Cache:
config.CacheConfig block), keeping the nested Redis:
&config.RedisResponseConfig{ URL: "redis://localhost:6379" } as-is so the types
match and the test compiles.

In `@internal/app/app.go`:
- Around line 724-727: dashboardFallbackModeValue currently reads only
cfg.Fallback.DefaultMode so the dashboard can show "off" even when per-model
overrides enable fallback; update
dashboardRuntimeConfig/dashboardFallbackModeValue to compute visibility using
the same logic as fallbackFeatureEnabledGlobally (i.e., treat any per-model
override of manual/auto as enabling fallback) rather than only DefaultMode, and
apply the same change to the other uses of dashboardFallbackModeValue in the
surrounding block (the code noted around dashboardRuntimeConfig and the related
742-755 region) so the dashboard visibility matches the compiled execution plan
behavior.
- Around line 789-790: The function simpleResponseCacheConfiguredFromResponse
dereferences cfg.Simple without guarding against nil; update it to first check
cfg.Simple != nil (and still check cfg.Simple.Redis != nil) before accessing
Redis.URL so deployments that omit the simple-cache block won't panic—i.e.,
change the conditional in simpleResponseCacheConfiguredFromResponse to ensure
cfg.Simple and cfg.Simple.Redis are non-nil and that Redis.URL is non-empty (use
strings.TrimSpace) so responseCacheConfigured() can safely call it.