diff --git a/apps/web/src/lib/api.ts b/apps/web/src/lib/api.ts
index 2d4731b..a391b7b 100644
--- a/apps/web/src/lib/api.ts
+++ b/apps/web/src/lib/api.ts
@@ -1,15 +1,12 @@
 /**
  * API client utilities for the web app.
  *
- * BUG: imports `useThrottle` from @e2e/utils, but that hook was renamed to
- * `useDebounce`. This causes a TypeScript error and a runtime crash.
- *
- * Fix: change the import to `useDebounce`.
+ * The debounce hook exported by @e2e/utils is `useDebounce` (previously named
+ * `useThrottle`). It is re-exported below as `useSearchDebounce`, the name the
+ * rest of the app consumes.
  */
 
-// BUG: useThrottle no longer exists — was renamed to useDebounce
-import { useThrottle } from "@e2e/utils"
-import { formatDate, formatAUD } from "@e2e/utils"
+import { useDebounce, formatDate, formatAUD } from "@e2e/utils"
 
 export const BASE_URL = process.env.API_URL ?? "http://localhost:3000"
 
@@ -28,5 +25,5 @@ export async function fetchPosts() {
 // Re-export formatting utilities used throughout the app
 export { formatDate, formatAUD }
 
-// Re-export the debounce hook (currently broken import)
-export { useThrottle as useSearchDebounce }
+// Re-export the debounce hook under the name used across the app
+export { useDebounce as useSearchDebounce }
diff --git a/packages/ui/src/components/Button/Button.tsx b/packages/ui/src/components/Button/Button.tsx
index af65c97..a78331a 100644
--- a/packages/ui/src/components/Button/Button.tsx
+++ b/packages/ui/src/components/Button/Button.tsx
@@ -14,16 +14,17 @@ type Props = {
   "aria-label"?: string
 }
 
+const FALLBACK_ICON_LABEL = "Button"
+
 /**
  * Button component.
  *
- * BUG: When `iconOnly` is true, the button renders without visible text.
- * An `aria-label` is required for screen reader accessibility (WCAG 2.1 SC 4.1.2),
- * but the component does not enforce or warn about its absence.
- *
- * The test in Button.test.tsx checks that an icon-only button has an accessible name.
- * Fix: throw/warn in development when `iconOnly && !aria-label`, or always render
- * the aria-label attribute when iconOnly is true.
+ * An icon-only button renders no visible text, so it must carry an `aria-label`
+ * to expose an accessible name to assistive technology (WCAG 2.2 SC 4.1.2
+ * Name, Role, Value). When `iconOnly` is set we always emit an `aria-label`:
+ * the caller-supplied value, a string child if one is present, or a generic
+ * fallback. A development-time warning is issued when no explicit label was
+ * given so the omission is caught during authoring rather than by an audit.
  */
 export function Button({
   children,
@@ -34,13 +35,26 @@ export function Button({
   onClick,
   "aria-label": ariaLabel,
 }: Props) {
+  let accessibleLabel = ariaLabel
+
+  if (iconOnly && !accessibleLabel) {
+    accessibleLabel = typeof children === "string" && children.trim() !== "" ? children : FALLBACK_ICON_LABEL
+
+    if (process.env.NODE_ENV !== "production") {
+      console.warn(
+        `Button: an icon-only button was rendered without an "aria-label". ` +
+          `Falling back to "${accessibleLabel}". Provide an explicit aria-label ` +
+          `describing the action (WCAG 2.2 SC 4.1.2).`,
+      )
+    }
+  }
+
   return (
     <button
       className={`btn btn-${variant}`}
       disabled={disabled}
       onClick={onClick}
-      // BUG: aria-label is not applied when iconOnly is true and no ariaLabel is passed
-      // The component should enforce aria-label for icon-only buttons
+      aria-label={accessibleLabel}
     >
       {icon && <span className="btn-icon">{icon}</span>}
       {!iconOnly && children}
diff --git a/packages/ui/src/components/DataTable/DataTable.tsx b/packages/ui/src/components/DataTable/DataTable.tsx
index 429a6e3..f5126f3 100644
--- a/packages/ui/src/components/DataTable/DataTable.tsx
+++ b/packages/ui/src/components/DataTable/DataTable.tsx
@@ -13,29 +13,35 @@ type Props<T extends Record<string, unknown>> = {
   columns: Column<T>[]
 }
 
+type SortState<T> = {
+  key: keyof T | null
+  dir: SortDir
+}
+
 /**
  * DataTable with client-side sorting.
  *
- * BUG: The sort handler has a stale closure — it captures `sortDir` at the
- * time the handler is created, so toggling sort direction does not work
- * correctly after the first click. The second click always sorts in the same
- * direction as the first.
+ * Sort key and direction are kept together in a single piece of state and
+ * updated with the functional form of `setState`. Because the two fields are
+ * always read and written as a unit, an update derives from the latest
+ * committed value rather than from whatever was captured when the handler was
+ * created, and the updater stays pure — which keeps behaviour consistent under
+ * StrictMode double-invocation and concurrent rendering.
  *
- * Fix: use the functional form of setState — `setSortDir(prev => ...)` —
- * so the toggle always reads the current value.
+ * This is a robustness and consistency improvement rather than a fix for an
+ * observed defect: the previous two-`useState` version behaved correctly for
+ * the click sequences the test suite exercises.
  */
 export function DataTable<T extends Record<string, unknown>>({ data, columns }: Props<T>) {
-  const [sortKey, setSortKey] = useState<keyof T | null>(null)
-  const [sortDir, setSortDir] = useState<SortDir>("asc")
+  const [sort, setSort] = useState<SortState<T>>({ key: null, dir: "asc" })
+  const { key: sortKey, dir: sortDir } = sort
 
-  // BUG: stale closure — sortDir is captured at handler creation time
   const handleSort = (key: keyof T) => {
-    if (sortKey === key) {
-      setSortDir(sortDir === "asc" ? "desc" : "asc") // BUG: reads stale sortDir
-    } else {
-      setSortKey(key)
-      setSortDir("asc")
-    }
+    setSort((prev) =>
+      prev.key === key
+        ? { key, dir: prev.dir === "asc" ? "desc" : "asc" }
+        : { key, dir: "asc" },
+    )
   }
 
   const sorted = sortKey
diff --git a/packages/utils/src/format/date.ts b/packages/utils/src/format/date.ts
index 609e46c..c9bfc73 100644
--- a/packages/utils/src/format/date.ts
+++ b/packages/utils/src/format/date.ts
@@ -1,21 +1,26 @@
 /**
  * Date formatting utilities.
  *
- * BUG: formatDate passes `'en-AU'` as the locale but then uses a US-style
- * format string option (`month: 'numeric'` before `day: 'numeric'`), which
- * produces MM/DD/YYYY output instead of DD/MM/YYYY for Australian dates.
+ * Australian dates are day-first: D/MM/YYYY. The day is rendered without a
+ * leading zero (1/03/2024, 15/06/2024) while the month keeps two digits.
  *
- * Fix: use `dateStyle: 'short'` with `'en-AU'` locale, which correctly
- * produces DD/MM/YYYY, or explicitly set `day: 'numeric', month: 'numeric', year: 'numeric'`
- * and rely on the locale to order them correctly.
+ * ICU pads the day to two digits for `en-AU` even with `day: 'numeric'`, so the
+ * parts are assembled explicitly here rather than relying on that behaviour.
+ * Using `formatToParts` keeps the locale in charge of field order and
+ * separators while letting us normalise the day, and avoids substituting a
+ * different locale (e.g. en-NZ) purely to get the desired padding.
  */
+const DATE_PART_OPTIONS: Intl.DateTimeFormatOptions = {
+  day: "numeric",
+  month: "2-digit",
+  year: "numeric",
+}
+
 export function formatDate(date: Date): string {
-  // BUG: explicit field order overrides locale ordering — produces M/D/YYYY not D/M/YYYY
-  return new Intl.DateTimeFormat("en-AU", {
-    month: "numeric",
-    day: "numeric",
-    year: "numeric",
-  }).format(date)
+  return new Intl.DateTimeFormat("en-AU", DATE_PART_OPTIONS)
+    .formatToParts(date)
+    .map((part) => (part.type === "day" ? String(Number(part.value)) : part.value))
+    .join("")
 }
 
 export function formatDateTime(date: Date): string {
diff --git a/packages/utils/test/bun-types.d.ts b/packages/utils/test/bun-types.d.ts
new file mode 100644
index 0000000..0c8952f
--- /dev/null
+++ b/packages/utils/test/bun-types.d.ts
@@ -0,0 +1,12 @@
+// Ambient type reference for Bun's built-in modules (notably `bun:test`).
+//
+// `bun-types` is a declared devDependency but is not published under
+// `node_modules/@types`, so TypeScript does not pick it up automatically and
+// every `import ... from "bun:test"` fails to resolve with TS2307.
+//
+// This lives in the test tree rather than under `src/` so the Bun globals it
+// pulls in are scoped to test compilation, and any build that compiles only
+// `src/` does not inherit them. The conventional home would be
+// `"types": ["bun-types"]` in tsconfig.json; it is declared here instead to
+// keep the build configuration untouched.
+/// <reference types="bun-types" />