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

Inline comments:
In `@docs/design/operations.md`:
- Around line 969-973: The admonition block starting with '!!! note "Status"' is
being treated as an indented code block by markdownlint MD046; fix it by adding
a blank line after the admonition line and removing the leading indentation on
the paragraph lines so the body is a normal paragraph (i.e., change the indented
lines under '!!! note "Status"' to dedented text with a blank line separating
them from the '!!! note' line).

In `@web/src/__tests__/components/ActiveTasksSummary.test.ts`:
- Around line 90-97: The test name is misleading because it never triggers a
click; update the test for clarity by renaming it from "navigates to /tasks when
\"View all\" is clicked" to something like "renders link to /tasks" (keeping the
existing assertions that check wrapper.find('a').attributes('href') ===
'/tasks'); alternatively, if you want true click behavior, change the test to
trigger a click on the found link (use wrapper.find('a').trigger('click') or
call the Router pushMock and assert pushMock was called) — locate the test in
ActiveTasksSummary.test.ts where pushMock, ActiveTasksSummary, and
wrapper.find('a') are used and apply one of these two fixes.
- Line 6: The test declares pushMock (const pushMock = vi.fn()) and calls
pushMock.mockClear() but never asserts on it; either remove the unused pushMock
declaration and the corresponding pushMock.mockClear() call, or keep pushMock
and add explicit assertions (e.g., expect(pushMock).toHaveBeenCalledWith(...) or
toHaveBeenCalledTimes(...)) where router navigation should be validated; locate
the pushMock symbol and update the test accordingly (delete both the declaration
and mockClear() if not testing navigation, or add assertions in the relevant
test case if navigation behavior is intended to be verified).

In `@web/src/__tests__/components/AgentCard.test.ts`:
- Around line 14-19: The test uses an invalid collaboration value and a type
cast workaround: replace the 'cooperative' + "as never" in the personality
object with a valid CollaborationPreference literal (one of 'independent' |
'pair' | 'team', e.g., 'team'), remove the "as never" cast, and ensure the
entire test object is typed with "satisfies AgentConfig" so the compiler
enforces the AgentConfig contract (locate the personality object in
AgentCard.test and update its collaboration field and type assertion
accordingly).

In `@web/src/__tests__/components/AgentMetrics.test.ts`:
- Line 18: The test uses an invalid collaboration value and a bogus type
assertion; in web/src/__tests__/components/AgentMetrics.test.ts locate the test
object where the collaboration property is set (property name "collaboration")
and remove the "as never" assertion and replace the string 'cooperative' with a
valid CollaborationPreference such as 'pair' or 'team' so the value matches the
allowed union ('independent' | 'pair' | 'team').

In `@web/src/__tests__/components/ApprovalActions.test.ts`:
- Around line 122-125: The test currently selects the reject reason textarea by
taking the last textarea node which is fragile; update the ApprovalActions
component to add a stable attribute (e.g., data-testid="reject-reason" on the
reject reason <textarea>) and then change the test in ApprovalActions.test.ts to
find that textarea via wrapper.find('[data-testid="reject-reason"]') (or
equivalent test selector) and call setValue('Not ready for production') on it;
this replaces the textareas[textareas.length - 1] selection with a robust
selector tied to the reject reason element.

In `@web/src/__tests__/components/ApprovalDetail.test.ts`:
- Around line 44-53: Tests only check static labels; update them to assert the
actual formatted timestamps are rendered by importing the same formatter and
comparing against the component output. In the ApprovalDetail tests (the cases
that render created_at, expires_at and decided_at), import formatDate (or the
module used by ApprovalDetail) and assert wrapper.text() (or a specific selector
like wrapper.find('[data-test="created_at"]').text()) contains
formatDate(mockApproval.created_at), formatDate(mockApproval.expires_at), and
formatDate(mockApproval.decided_at) respectively; apply the same change to the
tests around lines 71-79 so each test checks the formatted value, not just the
label.

In `@web/src/__tests__/components/BudgetConfigDisplay.test.ts`:
- Around line 65-70: The test "shows reset day" currently asserts
wrapper.text().toContain('1') which is a false positive because the page shows
"$1,000.00"; update the assertion to target the reset-day element specifically:
mount BudgetConfigDisplay with mockConfig and assert the text of the reset-day
node (e.g., wrapper.find('[data-testid="reset-day"]') or
wrapper.findComponent/selector that renders the reset day) equals or contains
'1'; if no stable selector exists, add a data-testid or class in the
BudgetConfigDisplay markup to uniquely identify the reset-day element and use
that in the test.

In `@web/src/__tests__/components/RecentApprovals.test.ts`:
- Around line 79-86: The test name in the RecentApprovals unit test is
misleading: it claims navigation occurs on click but only asserts the anchor's
href; rename the it(...) description to reflect that it verifies the link
destination (e.g., change "navigates to /approvals when \"View all\" is clicked"
to "renders \"View all\" link with href /approvals" or similar) in the
RecentApprovals test so the test name matches the assertion on
link.attributes('href').

In `@web/src/__tests__/composables/useLoginLockout.test.ts`:
- Around line 4-10: The test currently mocks Vue's onUnmounted to a no-op which
prevents the interval cleanup path from running; remove or stop mocking
onUnmounted and instead ensure the registered unmount callback runs — either
mount a tiny harness component and call wrapper.unmount() in the test or capture
the callback passed to onUnmounted and invoke it manually to verify
clearInterval(clockTimer) is called; update the useLoginLockout.test to exercise
the real onUnmounted behavior so the interval cleanup path is tested
(references: onUnmounted, clearInterval, clockTimer, wrapper.unmount).

In `@web/src/__tests__/views/AgentProfilesPage.test.ts`:
- Around line 90-94: The test "shows loading skeleton when store is loading and
no agents" currently only checks wrapper.text(); update it to assert the actual
loading skeleton is rendered by checking for the specific skeleton indicator in
AgentProfilesPage (e.g., use wrapper.findComponent(LoadingSkeleton).exists() or
wrapper.find('[data-testid="loading-skeleton"]').exists() or
wrapper.find('.skeleton').exists()). Replace the generic
expect(wrapper.text()).toBeTruthy() with an assertion that the skeleton element
exists and/or is visible so the test verifies the intended UI state while the
store is loading.

In `@web/src/__tests__/views/BudgetPanelPage.test.ts`:
- Around line 65-73: Update the test fixture for getBudgetConfig so it returns
the current BudgetConfig shape instead of the old *_usd keys: modify the vi.mock
for getBudgetConfig (in the test's vi.mock block) to resolve to an object with
keys like total_monthly, per_agent_daily_limit, per_task_limit, alerts, and
reset_day (and appropriate sample values) so the component under test (which
reads total_monthly, per_agent_daily_limit, per_task_limit, alerts, reset_day)
receives the correct shape; leave listCostRecords/getAgentSpending mocks as-is
unless they also require updated shapes.

In `@web/src/__tests__/views/SetupPage.test.ts`:
- Around line 13-25: The InputText mock (the defineComponent with props
including ariaDescribedby) currently does not pass ariaDescribedby through to
the rendered input; update the mock to map props.ariaDescribedby to the input's
aria-describedby attribute so tests can observe it. Then update the "shows
password mismatch error" test to assert that the two password inputs have
aria-describedby="setup-error" in addition to asserting the error message (use
the test's existing query helpers to locate the password inputs and check their
aria-describedby attribute). Ensure the prop name used in the mock
(ariaDescribedby) matches the attribute output (aria-describedby) and the test
looks for the setup-error id.

In `@web/src/components/common/StatusBadge.vue`:
- Around line 8-11: The prop typing for StatusBadge (defined via defineProps) is
too permissive and allows mismatched value/type combinations; create a
discriminated union type (e.g., StatusBadgeProps) that ties value to type (one
branch for { type?: 'status'; value: Status }, another for { type: 'priority';
value: Priority }, and { type: 'risk'; value: RiskLevel }) and use that in
defineProps so TypeScript enforces correct pairs; additionally, when doing the
dynamic lookup into statusColors in the default/status branch, guard the lookup
with Object.prototype.hasOwnProperty.call(statusColors, value) before accessing
to avoid runtime errors for mismatched values.

In `@web/src/components/dashboard/MetricCard.vue`:
- Line 25: The decorative icon in MetricCard.vue is exposed to assistive tech;
update the <i> element (the <i :class="[icon, 'text-lg']" /> in the MetricCard
component) to include aria-hidden="true" so screen readers ignore it (leave the
visual class binding intact and do not change semantics of the component).

In `@web/src/components/dashboard/SpendingSummary.vue`:
- Around line 14-25: The hourly buckets are built from a descending-sorted list
so slice(-24) ends up keeping the oldest buckets; change the sort to ascending
(sort by new Date(a.timestamp) - new Date(b.timestamp)) so Map insertion order
is chronological and slice(-24) returns the most recent 24 hours, and make
hourKey stable/lexicographically-sortable by zero-padding or using a YYYY-MM-DD
HH:00-style key (replace `${date.getMonth() + 1}/${date.getDate()}
${date.getHours()}:00` with a padded/ISO-like string) so ordering is reliable;
update references to sorted, hourlyData, hourKey, and entries accordingly.

In `@web/src/components/dashboard/SystemStatus.vue`:
- Around line 33-46: The persistence and message_bus rows in SystemStatus.vue
currently treat a missing health object as "Down"; update the rendering logic
for the two span elements referencing health?.persistence and
health?.message_bus so that when health is null/undefined they display "Unknown"
with a neutral/notice color (e.g., text-slate-400 or text-yellow-400) instead of
"Down", while preserving the existing green for true and red for false branches;
change both the displayed text and the :class ternaries for the Persistence and
Message Bus spans to explicitly handle health === null/undefined.

In `@web/src/components/tasks/KanbanColumn.vue`:
- Around line 17-22: The handleAdd function is using the internal
_underlying_vm_ property; change it to use the vue-draggable-plus API by
importing DraggableEvent from 'vue-draggable-plus', update the handleAdd
signature to handleAdd(event: DraggableEvent), and read the task from event.data
instead of event.item._underlying_vm_; then emit('task-added', task) as before
if task is defined.

In `@web/src/components/tasks/TaskDetailPanel.vue`:
- Around line 41-53: The watch on () => props.task only runs on changes, so
initial props.task isn't used to populate
editTitle/editDescription/editPriority/editing/showCancel/cancelReason; update
the watcher for props.task (the watch wrapping editTitle.value,
editDescription.value, editPriority.value, editing.value, showCancel.value,
cancelReason.value) to run immediately on mount by adding the immediate: true
option (or alternatively add an onMounted handler that performs the same
initialization) so the editable fields are populated when the component first
renders.
- Line 184: The Textarea for cancellation reason relies on placeholder text and
lacks an accessible label; update the TaskDetailPanel.vue markup so the Textarea
component bound to cancelReason has a proper label and programmatic association
(e.g., add a <label> element with descriptive text like "Cancellation reason"
and link it to the Textarea via id/for or provide an aria-label/aria-labelledby
prop on the Textarea component). Ensure the Textarea keeps placeholder and rows
but includes either an id="cancel-reason" and a matching <label
for="cancel-reason"> or an aria-labelledby that points to a visible label
element so screen readers announce a stable field name.

In `@web/src/utils/constants.ts`:
- Line 10: Frontend and backend WebSocket size limits are mismatched: update
either WS_MAX_MESSAGE_SIZE in web/src/utils/constants.ts or
_MAX_WS_MESSAGE_BYTES in src/ai_company/api/controllers/ws.py so both match
(choose to lower WS_MAX_MESSAGE_SIZE to 4096 if you prefer backend constraint,
or raise _MAX_WS_MESSAGE_BYTES to 131072 to allow larger messages); change the
numeric constant (WS_MAX_MESSAGE_SIZE or _MAX_WS_MESSAGE_BYTES) to the chosen
value, ensure any related validation/error messages reflect the new limit, and
run integration tests to verify no "Message too large" rejections occur.

In `@web/src/views/AgentDetailPage.vue`:
- Around line 52-58: The Back to Agents navigation uses a clickable Button with
`@click`="router.push('/agents')" which should be replaced with a RouterLink for
consistent, semantic navigation; update the AgentDetailPage.vue markup to use
<RouterLink> (or the project's router-link alias) with to="/agents", preserve
the visual styling/props currently used on the Button (icon, label/text, size
classes or text variant) by applying the same CSS classes or PrimeVue button
classes, and ensure the link has appropriate ARIA/role attributes if needed to
emulate button semantics while keeping keyboard/focus behavior native to links.

In `@web/src/views/MessageFeedPage.vue`:
- Line 69: The retry handler on ErrorBoundary is calling
messageStore.fetchMessages() with no args which loses the active channel filter;
change the `@retry` call to pass the current channel filter (e.g.
messageStore.fetchMessages(messageStore.activeChannel) or the prop/computed that
holds the active channel) so fetchMessages is invoked with the same channel
context; also ensure the fetchMessages signature (function name fetchMessages)
accepts and uses an optional channel parameter if needed.

In `@web/src/views/OrgChartPage.vue`:
- Around line 24-30: In retryFetch, the empty catch should record the caught
error for debugging: catch the error thrown by
Promise.all([companyStore.fetchDepartments(), agentStore.fetchAgents()]) and
call the app's debug logger (e.g., logger.debug or console.debug) with a short
context message mentioning retryFetch, companyStore.fetchDepartments, and
agentStore.fetchAgents while keeping the current behavior (do not rethrow
because ErrorBoundary/stores handle errors); if your project has a centralized
logger use that symbol, otherwise use console.debug.

In `@web/src/views/TaskBoardPage.vue`:
- Around line 144-157: The two view toggle buttons that update viewMode should
expose ARIA state so assistive tech knows they are mutually exclusive; update
the markup around the buttons (the enclosing div and the two buttons that set
viewMode) to include a logical container role (e.g., role="group" or
role="tablist") and add aria-pressed (or aria-selected if using role="tab")
bound to the expression (aria-pressed="viewMode === 'kanban'" and
aria-pressed="viewMode === 'list'"), plus descriptive aria-labels or
aria-labelledby for each button; ensure the reactive binding uses the same
viewMode symbol so screen readers get correct state updates.
- Around line 110-112: The current handleTaskMoved falls back to task.version ??
0 which can silently conflict with optimistic concurrency; change
handleTaskMoved to validate that task.version is present (not undefined/null)
before calling handleTransition (use the Task id and version fields), and if
version is missing, abort the transition and surface a clear error or trigger a
reload/fetch of the latest task instead of calling handleTransition(task.id, 0,
...); ensure this check references handleTaskMoved, handleTransition, Task and
TaskStatus so callers don't pass a fake 0 version to the backend.

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

Inline comments:
In `@web/src/__tests__/components/MetricCard.test.ts`:
- Around line 21-27: The test for MetricCard currently only checks that an <i>
exists which can yield false positives; update the test that mounts MetricCard
(props: title, value, icon) to assert the rendered <i> element includes the
expected classes from the icon prop (e.g., that the found element's
classes/`class` attribute contains both "pi" and "pi-users") before or as part
of the existence assertion so the test verifies the correct icon wiring.

In `@web/src/__tests__/components/OrgNode.test.ts`:
- Around line 100-103: The test computes deptBadge by filtering spans but never
asserts it; update the non-department test (in OrgNode.test.ts) to directly
assert that deptBadge is empty (e.g., expect(deptBadge).toHaveLength(0) or
expect(deptBadge.length).toBe(0)) immediately after const deptBadge =
spans.filter((s) => s.text() === 'Team') so the test will fail if a department
badge is mistakenly rendered; keep the existing wrapper.text() assertion as an
additional check.

In `@web/src/__tests__/components/RecentApprovals.test.ts`:
- Line 6: The test declares a mock called pushMock that is never asserted;
either remove the unused pushMock declaration and any vi.clearAllMocks/clear
calls related to it, or keep it and add assertions that the router navigation
was invoked (e.g., expect(pushMock).toHaveBeenCalledWith(...)) where
RecentApprovals triggers navigation; locate the pushMock variable in
RecentApprovals.test.ts and either delete its declaration and related cleanup or
add appropriate expect(...) assertions against pushMock to validate router.push
behavior.

In `@web/src/__tests__/composables/useLoginLockout.test.ts`:
- Around line 53-71: Tests in useLoginLockout.test.ts hardcode the lockout
thresholds (e.g., loops of 5 and timer 61_000) which will break when auth policy
constants change; import and use the shared auth constants LOGIN_MAX_ATTEMPTS
and LOGIN_LOCKOUT_MS in the test and replace the hardcoded loop counts and
vi.advanceTimersByTime values (use LOGIN_MAX_ATTEMPTS for loop iterations and
LOGIN_LOCKOUT_MS + 1 for the timer) when exercising recordFailure,
checkAndClearLockout, locked, makeAxiosError and useLoginLockout.

In `@web/src/components/budget/BudgetConfigDisplay.vue`:
- Around line 1-33: Add a data-testid to the Reset Day value element so tests
can target it reliably: update the template element that renders
config.reset_day (the <p class="text-sm font-medium text-slate-200"> showing
Reset Day) to include a descriptive data-testid (e.g.,
data-testid="budget-reset-day") so test suites can query that node directly.

In `@web/src/components/budget/SpendingChart.vue`:
- Around line 13-17: The date grouping in SpendingChart.vue currently uses new
Date(record.timestamp) and local getters (getFullYear/getMonth/getDate) which
shifts days by user timezone; update the grouping to use a UTC-based day key
(e.g., derive dayKey from record.timestamp using toISOString().slice(0,10) or
Date UTC getters) so props.records are aggregated consistently into dailyData
regardless of client timezone; replace the current dayKey construction where
dailyData.set(...) is called to use the UTC-derived string (referencing
props.records, record.timestamp, dayKey, and dailyData).

In `@web/src/components/dashboard/SpendingSummary.vue`:
- Around line 19-21: The hourKey creation is using a locale-dependent format;
replace the `${date.getMonth() + 1}/${date.getDate()} ${date.getHours()}:00`
construction with an ISO-style, zero-padded key (e.g.,
`${date.getFullYear()}-${mm}-${dd} ${HH}:00`) so the key is locale-independent
and sortable; update the code around the date variable and hourKey assignment
(where hourlyData.set(...) and record.timestamp/record.cost_usd are used) to
compute mm, dd, and HH with leading zero padding (padStart or equivalent) and
then use that ISO key when calling hourlyData.set.

In `@web/src/components/messages/MessageList.vue`:
- Around line 13-21: The watcher on props.messages measures isNearBottom after
awaiting nextTick which lets scrollHeight change and can miss users who were at
the bottom; instead, capture the near-bottom state before DOM updates by reading
listRef.value.scrollTop/scrollHeight/clientHeight into a boolean (e.g.,
wasNearBottom) prior to await nextTick(), then after nextTick check that stored
wasNearBottom and only then set listRef.value.scrollTop =
listRef.value.scrollHeight; update the watcher surrounding nextTick, listRef,
and isNearBottom to use this two-step measurement.

In `@web/src/components/tasks/TaskCreateDialog.vue`:
- Around line 103-108: Add aria-required="true" to the required form inputs so
screen readers know they're mandatory: update the InputText with id "task-title"
(v-model="title") and the Textarea with id "task-description"
(v-model="description") to include aria-required="true", and also add
aria-required="true" to the project selection control (the project field
referenced around line 123) so all three required fields (title, description,
project) expose their required state to assistive technologies.

In `@web/src/components/tasks/TaskDetailPanel.vue`:
- Around line 105-107: The edit-mode inputs lack accessible names; update
TaskDetailPanel.vue to add programmatic labels for the InputText, Textarea, and
Dropdown used with editTitle, editDescription, and editPriority: either add
unique id attributes (e.g., edit-title-input, edit-description-input,
edit-priority-select) and associate visible or offscreen <label for="...">
elements, or add explicit aria-label attributes on the InputText, Textarea, and
Dropdown components that reference their purpose (e.g., "Edit title", "Edit
description", "Edit priority"); ensure option-label/value usage for Dropdown
remains unchanged and that the ids/aria-labels map to the correct v-model
bindings (editTitle, editDescription, editPriority).

In `@web/src/router/index.ts`:
- Around line 20-74: Update the route definitions in router/index.ts for the
protected routes (the route objects named 'dashboard', 'org-chart', 'tasks',
'messages', 'approvals', 'agents', 'agent-detail', 'budget', 'meetings',
'artifacts', and 'settings') to include an explicit meta: { requiresAuth: true }
property on each route object; keep other properties (like props: true on
'agent-detail') unchanged so authGuard can read these flags and the routes
remain functionally identical.

In `@web/src/stores/auth.ts`:
- Around line 46-47: The check for expiresIn should reject non-finite values as
well as non-positive ones and the error message should be generic (not "Login
failed") because this path is used by both setup and login; update the
validation to ensure Number.isFinite(expiresIn) && expiresIn > 0 and when it
fails throw a neutral error like "Invalid session duration returned by server"
referencing the expiresIn variable so callers can diagnose the value.

In `@web/src/views/AgentDetailPage.vue`:
- Line 2: The component only fetches agent details inside the onMounted block so
when the route param name changes the displayed agent becomes stale; import and
use Vue's watch (add to the existing import alongside ref and onMounted) and
watch the route param (route.params.name or the local reactive name ref) to call
the same fetch function used in onMounted (e.g., fetchAgent or loadAgentDetails)
whenever name changes, ensuring you reuse the existing fetching logic and
cleanup any pending state if necessary.

In `@web/src/views/ApprovalQueuePage.vue`:
- Around line 97-106: The Dropdown control (the component instance using
v-model="statusFilter" with :options="statusOptions" and
`@change`="filterByStatus") is missing an accessible label; add an aria-label (or
aria-labelledby) attribute to that Dropdown instance (e.g., aria-label="Filter
by status" or reference an offscreen label element) so screen readers can
identify its purpose, ensuring the label text is concise and update any related
tests or docs that expect an accessible label for the status filter control.
- Around line 84-90: The catch in async function filterByStatus is currently
empty and swallows exceptions; update it to log the caught error when calling
approvalStore.fetchApprovals({ status: statusFilter.value }) so failures are
observable (keep the existing assumption that the store handles errors
internally but add a log statement in the catch that includes the error object
and context, e.g., "filterByStatus failed" and the error). Ensure you reference
the filterByStatus function and the approvalStore.fetchApprovals call while
adding the logging only in the catch block.
- Around line 64-82: The approve/reject handlers (handleApprove, handleReject)
and ApprovalActions component need an isLoading prop to prevent duplicate
requests; update ApprovalActions to accept an isLoading boolean and add
:disabled="isLoading" to the Approve button and :disabled="isLoading ||
!rejectReason.trim()" to the Confirm Reject button, then in ApprovalQueuePage
set a local loading state (e.g., isLoading or per-id loading) around the async
calls in handleApprove and handleReject (set true before awaiting
approvalStore.approve/reject and false in finally) and pass that state into the
ApprovalActions isLoading prop so buttons are disabled while the operation is
pending.

---

Duplicate comments:
In `@web/src/__tests__/components/ActiveTasksSummary.test.ts`:
- Line 6: The test declares an unused mock pushMock (const pushMock = vi.fn())
and only clears it; either remove the pushMock declaration/clear calls from
ActiveTasksSummary.test.ts to eliminate dead code, or add an assertion that
verifies router navigation by referencing pushMock (e.g.,
expect(pushMock).toHaveBeenCalledWith(...)) where the component triggers
navigation; update any beforeEach/afterEach that clears pushMock accordingly so
no orphaned setup remains.
- Around line 90-97: The test titled "navigates to /tasks when 'View all' is
clicked" is misleading because it only checks the anchor's href; rename the
it(...) description in ActiveTasksSummary.test.ts to accurately reflect the
assertion (e.g., "renders link to /tasks" or "has href to /tasks for View all")
so the test name matches the behavior verified (the code referencing
wrapper.find('a') and expect(link.attributes('href')).toBe('/tasks')).

In `@web/src/__tests__/components/AgentCard.test.ts`:
- Around line 14-19: The test fixture in AgentCard.test.ts uses an invalid
personality value and a cast "as never" which circumvents the AgentConfig type;
remove the "as never" cast and replace the invalid "collaboration" value with a
valid enum/union member that matches AgentConfig (or omit the field if optional)
in the personality object used by the test so the fixture conforms to
AgentConfig and surfaces real type errors.

In `@web/src/__tests__/components/AgentMetrics.test.ts`:
- Line 18: Test fixture sets collaboration: 'cooperative' as never which
bypasses types; remove the "as never" cast and replace the value with a valid
member from the collaboration enum/type (use the exported enum/union, e.g.
CollaborationPreference.Cooperative or the exact allowed string literal from the
CollaborationPreference type) in the AgentMetrics test fixture so the property
is type-correct and no unsafe casting remains.

In `@web/src/__tests__/components/ApprovalActions.test.ts`:
- Around line 122-125: The test selects the reject reason textarea by position
which is fragile; update the component to add a stable attribute (e.g.,
data-testid="reject-reason") on the reject reason textarea, then change the test
to find that element directly (replace the textareas[...] logic with
wrapper.find('[data-testid="reject-reason"]') and call .setValue('Not ready for
production') on that found node) so the test uses a robust selector; locate
usages around the rejectTextarea variable and the setValue call in
ApprovalActions.test.ts to apply this change.

In `@web/src/__tests__/components/ApprovalDetail.test.ts`:
- Around line 44-53: The tests for ApprovalDetail use only presence of labels
and should assert the actual formatted timestamps: update the 'renders
created_at date' and 'renders expires_at date' (and the similar block around
lines 71-79 for decided_at) to compute the expected formatted strings from the
same formatter used by the component (e.g., call the formatDate/time helper or
format mockApproval.created_at, mockApproval.expires_at, mockApproval.decided_at
the same way ApprovalDetail does) and assert
wrapper.text().toContain(expectedFormattedCreatedAt) /
toContain(expectedFormattedExpiresAt) / toContain(expectedFormattedDecidedAt)
instead of just checking 'Created'/'Expires'.

In `@web/src/__tests__/components/BudgetConfigDisplay.test.ts`:
- Around line 65-71: The test "shows reset day" in BudgetConfigDisplay.test.ts
currently uses expect(wrapper.text()).toContain('1') which is a false positive
because the currency "$1,000.00" contains "1"; update the assertion to target
the specific reset-day element instead (e.g., replace the generic text check
with expect(wrapper.find('[data-test="reset-day"]').text()).toBe('1') or
expect(wrapper.find('.reset-day').text()).toBe('1')), and if the component lacks
a stable selector, add a data-test="reset-day" attribute to the Reset Day
element in BudgetConfigDisplay so the test can reliably assert the exact reset
day value.

In `@web/src/__tests__/components/RecentApprovals.test.ts`:
- Around line 79-86: The test name claims a navigation on click but only checks
the anchor's href; update the test to match behavior: either rename the test to
"renders link to /approvals" if you only want to assert href, or actually
simulate the click and assert navigation. To simulate navigation, use
wrapper.find('a') to get the link, call await link.trigger('click') and then
assert pushMock was called with '/approvals' (or the router push method used in
your setup); reference the RecentApprovals component, the test block, and the
pushMock variable when making the change.

In `@web/src/__tests__/composables/useLoginLockout.test.ts`:
- Around line 4-10: The test currently mocks vue.onUnmounted as a no-op
(onUnmounted: vi.fn()) which prevents the composable useLoginLockout's cleanup
from running; change the mock to capture the registered unmount callback (e.g.
store it in a variable like unmountCb inside the test file when onUnmounted is
called), then add a test that calls useLoginLockout(), asserts that unmountCb is
a function, invokes unmountCb(), and verifies clearInterval was called (spy on
globalThis.clearInterval) so the composable's clearInterval(clockTimer) cleanup
is actually exercised.

In `@web/src/__tests__/views/AgentProfilesPage.test.ts`:
- Around line 90-94: The test "shows loading skeleton when store is loading and
no agents" is asserting generic text instead of the loading skeleton; update the
test for AgentProfilesPage to explicitly check for the skeleton element (e.g.,
query for the loading skeleton's test id or component name) after mounting;
locate the test block using the it(...) description and replace
expect(wrapper.text()).toBeTruthy() with an assertion that
wrapper.find('[data-testid="loading-skeleton"]') (or the actual skeleton
component selector used in the page) exists/is visible and that no agent rows
are rendered.

In `@web/src/components/common/StatusBadge.vue`:
- Around line 8-22: The props currently allow mismatched value/type pairs;
change the defineProps call to a discriminated union so type and value are
enforced together (e.g., { type: 'status', value: Status } | { type: 'priority',
value: Priority } | { type: 'risk', value: RiskLevel }), then update
getColorClass to rely on props.type narrowing (switch on props.type and use the
matching mapped color lookup: statusColors, priorityColors, riskColors) so
invalid combinations cannot be passed to getColorClass; reference defineProps,
props.type, props.value, and getColorClass when making these changes.

In `@web/src/components/tasks/KanbanColumn.vue`:
- Around line 17-22: The handler handleAdd is using the internal item property
_underlying_vm_ instead of the official vue-draggable-plus API; update handleAdd
to read the dragged payload from event.data (the DraggableEvent.data value),
cast/guard it as a Task if needed, and then emit('task-added', task) only when
that event.data is present—replace references to event.item._underlying_vm_ with
event.data and ensure the function signature/type reflects the DraggableEvent
shape.

In `@web/src/views/TaskBoardPage.vue`:
- Around line 110-112: handleTaskMoved currently passes task.version ?? 0 into
handleTransition which silently uses 0 when version is undefined; instead,
ensure we don't default to 0—either fetch or derive the authoritative version
before calling handleTransition or abort with a user-visible error/confirmation.
Update handleTaskMoved to check task.version (from the Task object or by
refetching the task via the store/API) and only call handleTransition when a
valid numeric version is present, otherwise surface a clear conflict/error path
so optimistic concurrency can't be silently violated; reference handleTaskMoved,
handleTransition, and task.version to locate the change.