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

Inline comments:
In @.github/workflows/ci.yml:
- Around line 102-121: The current dashboard-lint job bundles both lint and
type-check, which hides type-check results on lint failure; split this into two
separate jobs: keep dashboard-lint to run only "npm run lint" in the web
working-directory and create a new dashboard-typecheck job that runs only "npm
run type-check" with the same runs-on, permissions, checkout and setup-node
steps (reuse the same setup-node/node-version/cache inputs). Then update the CI
gate (ci-pass) to include both dashboard-lint and dashboard-typecheck so lint
and type-check run in parallel rather than serially.

In `@web/index.html`:
- Around line 10-12: Add minimal fallback content inside the root container div
with id "app" so the page isn't blank if client bootstrap fails: update the <div
id="app"></div> element to include a short, user-friendly placeholder (e.g. a
"Loading…" message or a diagnostic note) that will be replaced when Vue mounts;
ensure you only change the markup inside the div (the element with id "app") and
do not modify the existing script tag or body classes.

In `@web/nginx.conf`:
- Around line 22-25: Update the comment that currently claims scheme-only
ws:/wss: sources are used to instead describe the actual emitted header from the
add_header Content-Security-Policy directive (it uses connect-src 'self'), and
explicitly note the WebSocket compatibility caveat: explain that 'self'
restricts to same-origin WebSocket connections but some browsers have
inconsistent support so you may need explicit host or scheme entries (ws: /
wss:) depending on target browsers; change the comment text around the
add_header Content-Security-Policy line to match this accurate behavior and
recommendation.

In `@web/src/__tests__/api/client.test.ts`:
- Around line 15-86: Add tests that cover the axios interceptors in
web/src/api/client.ts: create a test that sets a token in localStorage, obtains
the configured axios instance (exported as apiClient or obtained via the
module's setup function), simulate a request through the request interceptor and
assert the Authorization header contains `Bearer <token>`; and create a test
that simulates a 401 response through the response interceptor (mock a response
with status 401 or call the interceptor's error handler), spy on
localStorage.removeItem/clear and on window.location.assign (or the module
function that redirects) and assert the token is cleared and redirect is
invoked. Use jest.spyOn/mocks to inject the fake token and to invoke the
interceptor functions directly or by mocking axios.request to trigger the
interceptors so the tests exercise the auth header injection and the 401
token-clear/redirect branches.

In `@web/src/__tests__/components/EmptyState.test.ts`:
- Around line 5-38: Add a test in the EmptyState.test suite that mounts the
EmptyState component with the named "action" slot provided (use the same mount
helpers as other tests) and assert the slot content is rendered and accessible;
reference the EmptyState component and the "action" slot name so you locate the
slot implementation in EmptyState.vue lines ~18-19, then in the new test mount
EmptyState with props (e.g., title) and a slot template for "action" and assert
the rendered output contains the slot content and that it appears in the
expected DOM node (e.g., find by text or selector).

In `@web/src/__tests__/components/StatusBadge.test.ts`:
- Around line 5-26: Add assertions that verify the color-class applied for each
branch so the getColorClass() mapping is exercised; for each test that mounts
StatusBadge (the 'renders status value as label', 'renders priority type', and
'renders risk type' cases) add one assertion that the root element's class list
(wrapper.classes() or wrapper.attributes('class')) contains the expected CSS
class returned by getColorClass for the given props (e.g., the class for
'in_progress' when type is default/status, for 'critical' when type is
'priority', and for 'high' when type is 'risk'), or import/use the same mapping
used by getColorClass in StatusBadge.vue to derive the expected class names and
assert they are present.

In `@web/src/__tests__/composables/usePolling.test.ts`:
- Around line 14-112: Add a new test in
web/src/__tests__/composables/usePolling.test.ts that asserts usePolling(fn,
intervalMs) validates intervalMs and rejects invalid values: confirm that
calling usePolling with 0, a negative number, NaN, or Infinity either
immediately throws (or returns an object whose start() throws) — pick the
library's current error behavior — and assert an Error is thrown (e.g., with
toThrow()). Reference the usePolling symbol in the test and cover at least
intervalMs values 0, -100, NaN, and Infinity so this validation cannot regress.

In `@web/src/__tests__/stores/budget.test.ts`:
- Around line 24-48: Add unit tests in web/src/__tests__/stores/budget.test.ts
to cover the fetch action success and error paths for useBudgetStore: write
tests that call store.fetchConfig, store.fetchRecords(params), and
store.fetchAgentSpending(agentId) while mocking the API responses (both resolved
and rejected) and assert the store mutations (config, records, totalRecords,
agentSpending) and any error state/flags; also verify that handleWsEvent
continues to work when fetch actions have failed. Locate the store via
useBudgetStore and mock the underlying API/client used by those methods to
simulate 200 and error responses, then assert expected state transitions and
error handling for each method.

In `@web/src/__tests__/stores/tasks.test.ts`:
- Around line 157-186: Add failing-path tests for transitionTask and cancelTask
similar to updateTask's error test: for transitionTask, have
mockTransitionTask.mockRejectedValue(new Error('Conflict')) then call
useTaskStore(), await store.transitionTask('task-1', { target_status: 'assigned'
}) and assert the result is null and store.error equals the error message; for
cancelTask, have mockCancelTask.mockRejectedValue(new Error('Conflict')), call
store.cancelTask('task-1', { reason: 'done' }) and assert null result and
store.error === 'Conflict'. Ensure you reference the same helpers used in the
file (useTaskStore, mockTransitionTask, mockCancelTask, and store.error) and
match the pattern of the existing success tests.
- Around line 6-20: Remove the unused mock or add a test that exercises it:
either delete the mockGetTask declaration and its mapping inside the vi.mock
block (remove mockGetTask and the getTask: (...args) => mockGetTask(...args)
entry) to avoid an unused mock, or add a unit test that calls the store method
which triggers the tasks.getTask API (e.g., the store action or getter that
calls getTask) and assert mockGetTask was called; reference mockGetTask and the
mocked getTask to locate the code to change.

In `@web/src/api/client.ts`:
- Around line 8-12: BASE_URL may include a trailing slash or already contain the
"/api/v1" path which causes double slashes or duplicated segments when used in
apiClient; normalize BASE_URL before concatenation by trimming any trailing
slashes and removing any existing "/api/v1" suffix (or build the final origin
via a URL-join utility) so that baseURL for apiClient is always a single
canonical origin plus "/api/v1" (update the code that computes BASE_URL and the
apiClient.create baseURL to use the normalized value).

In `@web/src/api/endpoints/company.ts`:
- Around line 1-16: The three endpoint functions (getCompanyConfig,
listDepartments, getDepartment) call apiClient.get without preserving the
response envelope type, so update each call to pass the proper generic response
type to apiClient.get (e.g. ApiResponse<CompanyConfig> for getCompanyConfig,
PaginatedResponse<Department> for listDepartments, ApiResponse<Department> for
getDepartment) and keep using unwrap/unwrapPaginated to extract the payload;
this means changing the apiClient.get(...) invocations to
apiClient.get<ApiResponse<...>>(...) or
apiClient.get<PaginatedResponse<...>>(...) so TypeScript enforces the response
contracts at this boundary.

In `@web/src/api/endpoints/providers.ts`:
- Around line 1-12: The listProviders and getProvider functions currently return
the unwrapped backend response (via unwrap(response)) which can contain
sensitive api_key fields; update these functions to accept the raw response type
(e.g., RawProviderConfig / Record<string, RawProviderConfig>), then create and
return a sanitized object that omits api_key before returning to callers.
Concretely: in listProviders call unwrap(response) into a RawRecord, iterate
keys to copy each provider into a new Record<string, ProviderConfig> without the
api_key property; in getProvider call unwrap(response) into a RawProviderConfig
and return a ProviderConfig built by copying fields except api_key. Keep the new
Raw* types for the unsanitized shape and ensure the exported return types of
listProviders and getProvider remain ProviderConfig (sanitized).

In `@web/src/components/layout/ConnectionStatus.vue`:
- Around line 23-26: The current onMounted handler starts checkHealth via
setInterval which can launch a new checkHealth before the previous async call
finishes (causing concurrent requests and races); change the polling to
serialize calls by replacing the setInterval approach with a guarded loop or
recursive setTimeout: track an in-flight flag or await the previous checkHealth
promise before scheduling the next poll (use the existing symbols checkHealth,
pollTimer and HEALTH_POLL_INTERVAL), ensure pollTimer is set/cleared
appropriately and that onUnmounted still clears the timer to avoid leaks.

In `@web/src/components/layout/Sidebar.vue`:
- Around line 63-69: The collapse toggle button in Sidebar.vue (the <button>
element with `@click`="$emit('toggle')" and :aria-label bound to collapsed) is
missing an explicit type, which can cause it to act as a submit button when
placed inside a form; add type="button" to that button so it does not trigger
form submission when clicked and preserve its current click handling and aria
attributes.
- Around line 44-59: Buttons rendered from NAV_ITEMS in the Sidebar template can
accidentally submit a surrounding form because they lack an explicit type;
update the <button> elements used in the v-for (the one that uses NAV_ITEMS,
isActive(item.to) and `@click`="navigate(item.to)") to include type="button" so
they behave as non-submit controls and follow accessibility/best-practice
guidelines.

In `@web/src/composables/useAuth.ts`:
- Around line 14-17: The computed `canWrite` currently reads `store.userRole`
directly; change it to use the existing `userRole` computed ref by referencing
`userRole.value` instead, so update the `canWrite` function to read
`userRole.value` and check `(WRITE_ROLES as readonly
string[]).includes(userRole.value)` to keep consistency with the established
pattern while preserving the same behavior.

In `@web/src/composables/useOptimisticUpdate.ts`:
- Around line 15-20: execute currently allows re-entrant calls because pending
is shared; add a guard at the start of execute: if (pending.value) return null
(or throw) to prevent starting a second optimistic update while one is in
flight. For a more robust fix, also assign a local opId (e.g. const opId =
Symbol()) and store it on a shared currentOpId; in finally/rollback logic only
clear pending or run the rollback if currentOpId === opId so an older completion
cannot revert a newer optimistic state; reference execute, pending,
applyOptimistic, serverAction, and the rollback/finally block when making these
changes.
- Around line 28-34: The code currently logs raw error objects; change both
console.error calls to log only sanitized messages using getErrorMessage() (or
the already-set error.value) instead of dumping err or rollbackErr.
Specifically, inside useOptimisticUpdate where rollback?.() is caught, replace
logging of rollbackErr with a sanitized message via
getErrorMessage(rollbackErr); and replace the final console.error('Optimistic
update failed:', err) with console.error('Optimistic update failed:',
getErrorMessage(err)) or console.error('Optimistic update failed:', error.value)
after you assign error.value = getErrorMessage(err).

In `@web/src/composables/usePolling.ts`:
- Line 7: The usePolling function currently accepts intervalMs unvalidated which
allows 0, negative, NaN, or Infinity to create runaway polling; add validation
at the start of usePolling: define a MIN_POLL_INTERVAL constant (e.g. 100ms),
check Number.isFinite(intervalMs) and that intervalMs >= MIN_POLL_INTERVAL, and
if not either clamp intervalMs to MIN_POLL_INTERVAL or throw a clear error;
update all callers or document the behavior and use the validated/clamped value
in the polling loop (refer to usePolling and the variable intervalMs).

In `@web/src/main.ts`:
- Around line 33-36: The unhandledrejection handler registered via
window.addEventListener('unhandledrejection', ...) logs a sanitized reason but
does not cancel the browser's default reporting; update the handler to call
event.preventDefault() inside the listener (after capturing/sanitizing
event.reason with sanitizeForLog) so the browser does not also print the
original unsanitized rejection to the console; keep using
sanitizeForLog(event.reason) for the logged message.

In `@web/src/primevue-preset.ts`:
- Around line 1-12: Update the TypeScript import for PrimeVueConfiguration so it
matches PrimeVue 4.x exports: change the import source for the type used by
primeVueOptions from 'primevue' to 'primevue/config' (ensure the symbol
PrimeVueConfiguration is imported from 'primevue/config' and used to type the
exported primeVueOptions object).

In `@web/src/router/index.ts`:
- Around line 6-11: The inline PlaceholderHome component defined via
defineComponent (name: 'PlaceholderHome', render: ...) should be extracted into
its own file to keep views consistent and make future page additions easier;
create a new file under views (e.g., views/PlaceholderHome.vue or
views/PlaceholderHome.ts), move the defineComponent implementation there, export
it as the default, then import and use that component in web/src/router/index.ts
in place of the inline PlaceholderHome reference.

In `@web/src/stores/agents.ts`:
- Around line 40-52: The handler for the 'agent.hired' event currently casts
payload to AgentConfig after only validating name, id, role, and department
which can produce incomplete AgentConfig objects; update the logic in the
'agent.hired' case to either (a) validate all required AgentConfig fields
(level, status, personality, model, skills, memory, tools, hiring_date, etc.) on
payload before pushing to agents.value and incrementing total.value, ensuring
correct types/structures for arrays/objects, or (b) if the payload is partial,
call the existing API helper (e.g., fetchAgentById or similar) using payload.id
to retrieve the full AgentConfig and then append that returned object to
agents.value and increment total.value; ensure you no longer blindly cast
payload as AgentConfig and only push a fully-populated agent.

In `@web/src/stores/approvals.ts`:
- Around line 53-67: The handler handleWsEvent currently casts a partial payload
to ApprovalItem and pushes it into approvals.value on 'approval.submitted', but
only validates id, action_type, and title; update this by either validating all
required ApprovalItem fields (description, requested_by, risk_level, status,
task_id, metadata, created_at, etc.) on payload before casting and inserting
into approvals.value and incrementing total.value, or — preferably — call the
API to fetch the full approval record by payload.id (e.g., a getApprovalById /
fetchApproval function) inside the 'approval.submitted' case and push the
returned complete ApprovalItem into approvals.value and increment total.value
only after successful fetch; ensure you guard against duplicates using the
existing approvals.value.some check and handle fetch errors without inserting
incomplete objects.

In `@web/src/stores/auth.ts`:
- Around line 140-152: The changePassword function currently omits error
handling and lets exceptions bubble up; either add a try/catch like other
methods (e.g., fetchUser) to capture errors, set/loading state and surface a
normalized error or call an error handler, or explicitly document intent with a
comment above changePassword indicating errors are intentionally propagated to
the caller; update the function changePassword to mirror the pattern used by
fetchUser (catch error, optionally set an error store or rethrow a wrapped
error) or add the explanatory comment so maintainers know this behavior is
deliberate.
- Around line 78-99: Both setup() and login() duplicate the same post-auth
sequence (setting token, calling fetchUser, handling fetch errors by calling
clearAuth, checking !user.value, and toggling loading.value); extract that into
a private helper like performAuthFlow(authFn, flowName) and have setup and login
call it. The helper should set loading.value = true/false around the call, await
authFn() to get { token, expires_in }, call setToken(result.token,
result.expires_in), await fetchUser() with a try/catch that calls clearAuth()
and throws a flow-specific error string (use flowName in the message), check if
(!user.value) to clearAuth and throw the same message, and finally return the
auth result; replace the duplicated blocks in setup and login with calls to
performAuthFlow(() => authApi.setup(...), 'Setup') and performAuthFlow(() =>
authApi.login(...), 'Login').

In `@web/src/stores/budget.ts`:
- Around line 42-50: fetchAgentSpending currently doesn't manage the loading
state like fetchConfig/fetchRecords; set loading.value = true at the start of
fetchAgentSpending, and ensure loading.value = false is set in a finally block
after awaiting budgetApi.getAgentSpending so the UI sees a consistent loading
lifecycle; keep existing error handling (error.value = null before, error.value
= getErrorMessage(err) on catch) and reference the fetchAgentSpending function,
loading.value, error.value, budgetApi.getAgentSpending and getErrorMessage when
making the change.
- Around line 52-60: The handler handleWsEvent currently unsafely casts
event.payload to CostRecord; replace the double assertion with a runtime type
guard that verifies required fields (e.g., agent_id, cost_usd as number,
timestamp as string/number) and their types before treating payload as a
CostRecord, and only then update records.value and totalRecords.value
(respecting MAX_WS_RECORDS); implement the guard as a small function
(isCostRecord(payload): payload is CostRecord) and use it inside handleWsEvent
to guard the push to records.

In `@web/src/stores/company.ts`:
- Around line 16-38: fetchConfig and fetchDepartments can suffer from race
conditions where an earlier request finishes after a later one and overwrites
loading/error state; add a per-action request guard (e.g., configRequestId and
departmentsRequestId counters or per-action AbortController) that you
increment/create before awaiting the API call, capture the current id/controller
in a local variable, and only update
config.value/configError.value/loading.value (and
departments.value/departmentsError.value/departmentsLoading.value) if the
captured id/controller still matches the latest one when the promise resolves or
rejects; ensure the finally block also checks the guard so outdated requests
cannot flip loading flags.

In `@web/src/stores/messages.ts`:
- Around line 50-61: The WebSocket handler handleWsEvent currently increments
total when appending a message, which allows total to drift from the server
paginated count; change handleWsEvent to append incoming messages to
messages.value (respecting activeChannel and MAX_WS_MESSAGES) but do not modify
total on WS events, and if you need a client-side counter keep a separate
variable (e.g., sessionMessageCount) or update documentation to clarify that
total is strictly the server-side total and is only set from the paginated API
response.

In `@web/src/stores/providers.ts`:
- Around line 8-14: sanitizeProviders currently writes dynamic keys into a plain
object which allows prototype-pollution if a key like "__proto__" arrives;
change the accumulator to a dictionary with no prototype (use
Object.create(null)) and skip/deny unsafe property names (e.g., "__proto__",
"prototype", "constructor") when iterating Object.entries. In function
sanitizeProviders, create result via Object.create(null), check each key against
a small denylist before assigning, and continue to the next entry if matched;
still strip api_key as before and assign safe into result, returning the
prototype-free record.

In `@web/src/stores/tasks.ts`:
- Around line 57-68: The createTask function can double-count total when a
task-created WS event races with the API response; update createTask to check
whether tasks.value already contains the task id before appending and
incrementing total: after receiving task from tasksApi.createTask, if
tasks.value.some(t => t.id === task.id) then just return task (do not push or
increment total), otherwise push and increment; this keeps behavior consistent
with handleWsEvent and avoids the race window without changing WS logic.
- Around line 35-40: The hasActiveFilters function currently treats empty
strings as active because it only checks for undefined/null; update the
predicate used on Object.values(currentFilters.value) to also treat empty
strings (and ideally whitespace-only strings) as inactive. Specifically, in
hasActiveFilters replace the test (v !== undefined && v !== null) with a check
that additionally excludes string values that are empty or only whitespace
(e.g., ensure v is not '' or (typeof v === 'string' && v.trim() === '') ), so
currentFilters entries like { status: '' } are considered inactive.

In `@web/src/stores/websocket.ts`:
- Around line 176-196: The unsubscribe function currently removes tracked
subscriptions only when all of a subscription's channels are present in the
provided channels array (using channels.every), which prevents partial
unsubscriptions (e.g., unsubscribing "tasks" won't remove a subscription
["tasks","agents"]); change the predicate in both loops that iterate
activeSubscriptions and pendingSubscriptions to use some (e.g.,
subscription.channels.some(c => channelSet.has(c))) so any matching channel will
remove that subscription entry (and leave the socket.send logic intact), or if
exact-match behavior is intended, add a clear comment and/or adjust callers to
pass the full channel set instead; locate this change in the unsubscribe
function and update both loops using activeSubscriptions and
pendingSubscriptions.
- Around line 44-53: The connect function currently appends the JWT as a query
param to the WebSocket URL (see connect, currentToken, getWsUrl) which exposes
the token; change connect to first call a backend endpoint to exchange the JWT
for a short-lived one-time WS ticket (implement a helper like fetchWsTicket or
getWsTicket) using the existing token, then open the WebSocket to getWsUrl()
with that ticket (or no sensitive data in query) instead of the raw JWT; ensure
currentToken is kept client-side only, remove encodeURIComponent(token) usage in
the URL, handle failures from the ticket exchange (log/abort) and ensure the
ticket is single-use/short-lived on the backend so production logs no longer
contain the JWT.

In `@web/src/styles/theme.ts`:
- Around line 36-50: Replace the loose Record<string,string> with explicit union
key types: declare and export a type Status =
'created'|'assigned'|'in_progress'|'in_review'|'completed'|'blocked'|'failed'|'interrupted'|'cancelled'|'pending'|'approved'|'rejected'|'expired'
and change statusColors to Record<Status,string>; do the same pattern for the
other maps (e.g., priorityColors, riskColors) by adding appropriate union types
(Priority, Risk) and using Record<Priority,string> / Record<Risk,string> so
consumers get compile-time safety and IDE autocompletion.

In `@web/src/utils/constants.ts`:
- Around line 54-66: NAV_ITEMS is declared with as const but lacks an exported
reusable type; add and export a NavItem type so consumers can use it for
type-safe iteration or extension by deriving it from NAV_ITEMS (e.g., export
type NavItem = (typeof NAV_ITEMS)[number]) and update any consumers to import
NavItem where needed; ensure the new type is exported from the same module
alongside NAV_ITEMS.

In `@web/src/utils/errors.ts`:
- Around line 3-10: The custom type guard isAxiosError uses a manual property
check which can be brittle; replace its implementation to call Axios's official
helper (importing axios or the isAxiosError helper from 'axios') and return
axios.isAxiosError(error) so the function delegates to Axios internals for
accurate detection while preserving the exported function name isAxiosError.

In `@web/src/utils/format.ts`:
- Around line 27-35: The current check treats future timestamps (diffMs < 0) as
'just now'; change that to a safer fallback by returning formatDate(iso) for
negative diffs. Locate the time-diff logic using diffMs, diffSec, iso, date and
now, replace the early "if (diffMs < 0) return 'just now'" with "if (diffMs < 0)
return formatDate(iso)" so future/clock-skewed dates render as a formatted date
instead of "just now".

In `@web/src/views/LoginPage.vue`:
- Around line 21-33: The computed locked currently uses Date.now()
(non-reactive) so it won't update when the lockout expires; make the computed
depend on a reactive "now" ref that is updated on an interval so the UI
re-evaluates (e.g., create a ref now and update it with
setInterval/clearInterval on unmount), keep the existing checkAndClearLockout()
logic but ensure locked computed reads now and lockedUntil.value, and ensure the
interval is cleaned up in the component's teardown to avoid leaks so the Submit
button becomes enabled immediately when lockedUntil passes.

In `@web/src/views/SetupPage.vue`:
- Around line 20-33: The computed `locked` uses Date.now() directly so it
doesn't update reactively; change it to depend on a reactive clock (e.g., create
a `now` ref updated with setInterval or use a time composable) and use
`now.value` inside the `locked` computed so the button UI updates when the lock
expires; ensure the interval is started where these refs are defined and cleaned
up on component unmount, and leave `checkAndClearLockout`, `handleSetup`,
`lockedUntil`, `attempts`, and `error` logic unchanged except for replacing
Date.now() with the reactive `now` reference.