@cat-factory/app 0.159.3 → 0.160.1

package/app/components/layout/IntegrationsHub.vue

@@ -137,6 +137,15 @@ const groups = computed<IntegrationGroup[]>(() => {
         onClick: () => go(ui.openVendorCredentials),
       },
     ],
+    // Personal (individual-usage) subscriptions are per-USER, so they live in My setup —
+    // but this hub is where people look first when connecting "their Claude plan". A quiet
+    // pointer link keeps them findable without a workspace-scoped row competing here.
+    footerLink: {
+      key: 'personal-subs',
+      icon: 'i-lucide-user',
+      label: t('layout.integrationsHub.items.personalSubs.label'),
+      onClick: () => go(() => ui.openVendorCredentials('personal')),
+    },
   })
 
   // --- Source control --------------------------------------------------------

package/app/components/panels/StepTestReport.logic.spec.ts

@@ -0,0 +1,49 @@
+import { describe, it, expect } from 'vitest'
+import { resolveVerdictMeta, UNKNOWN_VERDICT_COLOR, VERDICT_COLORS } from './StepTestReport.logic'
+import type { RequirementVerdictStatus } from '~/types/domain'
+
+/**
+ * The tester panel's requirement → evidence dots. The verdict is three-valued precisely so that
+ * "we didn't check" and "it's broken" never render the same; these pin that a FOURTH, unknown
+ * value cannot quietly join either camp.
+ */
+const LABELS: Record<RequirementVerdictStatus, string> = {
+  met: 'Met',
+  not_met: 'Not met',
+  not_covered: 'Not checked',
+}
+
+describe('resolveVerdictMeta', () => {
+  it('resolves each known status to its own label and colour', () => {
+    expect(resolveVerdictMeta('met', LABELS)).toEqual({ label: 'Met', color: '#22c55e' })
+    expect(resolveVerdictMeta('not_met', LABELS)).toEqual({ label: 'Not met', color: '#ef4444' })
+    expect(resolveVerdictMeta('not_covered', LABELS)).toEqual({
+      label: 'Not checked',
+      color: '#64748b',
+    })
+  })
+
+  it('gives the three known statuses three distinct colours', () => {
+    const colors = Object.values(VERDICT_COLORS)
+    expect(new Set(colors).size).toBe(colors.length)
+  })
+
+  it('falls back to the raw code for an unrecognised status', () => {
+    const meta = resolveVerdictMeta('inconclusive' as RequirementVerdictStatus, LABELS)
+    expect(meta).toEqual({ label: 'inconclusive', color: UNKNOWN_VERDICT_COLOR })
+  })
+
+  it('never lets an unrecognised status borrow a known colour', () => {
+    // The regression this guards: reusing `not_covered`'s grey made a contract violation read
+    // as "not checked", which is the one confusion the three-valued design forbids.
+    expect(Object.values(VERDICT_COLORS)).not.toContain(UNKNOWN_VERDICT_COLOR)
+  })
+
+  it('falls back when the status is known but its label is missing', () => {
+    const sparse = { met: 'Met' } as Record<RequirementVerdictStatus, string>
+    expect(resolveVerdictMeta('not_met', sparse)).toEqual({
+      label: 'not_met',
+      color: UNKNOWN_VERDICT_COLOR,
+    })
+  })
+})

package/app/components/panels/StepTestReport.logic.ts

@@ -0,0 +1,49 @@
+// Pure logic behind the tester panel's REQUIREMENT → EVIDENCE section (the in-app twin of the
+// PR verification report's section of the same name).
+//
+// Kept out of the SFC on the seam `ServiceSpecWindow.logic.ts` / `AppOverlayHost.logic.ts`
+// established, so the one rule worth pinning here — that an unrecognised status can never be
+// mistaken for a known one — is unit-testable without mounting Nuxt.
+import type { RequirementVerdictStatus } from '~/types/domain'
+
+/** How one verdict renders: its translated label and the dot colour beside it. */
+export interface VerdictMeta {
+  label: string
+  color: string
+}
+
+/**
+ * The colour an UNRECOGNISED status renders in. Deliberately distinct from all three known
+ * colours: an unknown status is a contract violation (version skew against a backend that grew
+ * a fourth one), not a fourth state, so borrowing `not_covered`'s grey would render "we have no
+ * idea" identically to "we didn't check" — precisely the collapse the three-valued verdict
+ * exists to prevent. Amber is the same "attention, but not a failure" tone the panel's severity
+ * scale already uses for `medium`.
+ */
+export const UNKNOWN_VERDICT_COLOR = '#f59e0b'
+
+/** Dot colour per known verdict. Exhaustive over the closed union (drift guard tier 2). */
+export const VERDICT_COLORS: Record<RequirementVerdictStatus, string> = {
+  met: '#22c55e',
+  not_met: '#ef4444',
+  not_covered: '#64748b',
+}
+
+/**
+ * Resolve one verdict's presentation. Labels are passed in already translated (this module is
+ * pure, so it holds no `t`), which also keeps the catalog keys literal at the call site where
+ * the typed-key drift guard can see them.
+ *
+ * An unrecognised status falls back to the raw code plus {@link UNKNOWN_VERDICT_COLOR}: showing
+ * the code is more useful to the person who has to explain the skew than any invented label,
+ * and the distinct colour stops it reading as one of the three real answers.
+ */
+export function resolveVerdictMeta(
+  status: RequirementVerdictStatus,
+  labels: Record<RequirementVerdictStatus, string>,
+): VerdictMeta {
+  const color = VERDICT_COLORS[status]
+  const label = labels[status]
+  if (!color || !label) return { label: status, color: UNKNOWN_VERDICT_COLOR }
+  return { label, color }
+}

package/app/components/panels/StepTestReport.vue

@@ -1,6 +1,7 @@
 <script setup lang="ts">
-import type { TestReport } from '~/types/domain'
+import type { RequirementVerdictStatus, TestReport } from '~/types/domain'
 import type { TesterStepState } from '~/types/execution'
+import { resolveVerdictMeta, type VerdictMeta } from './StepTestReport.logic'
 
 // A tester step's latest structured report (what was tested, the per-area outcomes,
 // the concerns it raised and the greenlight verdict) plus the fixer-loop phase.
@@ -22,6 +23,21 @@ const OUTCOME_COLOR: Record<string, string> = {
   failed: '#ef4444',
   skipped: '#64748b',
 }
+
+// Per-spec-requirement verdict labels, keyed by the requirement id the service's in-repo `spec/`
+// carries. THREE-VALUED on purpose: "we didn't check" and "it's broken" must never render the
+// same, which is the whole reason the tester reports the list. Exhaustive `Record` over the
+// closed union (drift guard tier 2) with literal `t()` keys, so a new status fails the
+// typecheck rather than rendering a raw enum value. Colours and the unknown-status fallback live
+// in the pure sibling, where the "never borrow a known colour" rule is unit-tested.
+const VERDICT_LABELS: Record<RequirementVerdictStatus, string> = {
+  met: t('panels.testReport.requirementVerdicts.met'),
+  not_met: t('panels.testReport.requirementVerdicts.notMet'),
+  not_covered: t('panels.testReport.requirementVerdicts.notCovered'),
+}
+function verdictMeta(status: RequirementVerdictStatus): VerdictMeta {
+  return resolveVerdictMeta(status, VERDICT_LABELS)
+}
 </script>
 
 <template>
@@ -65,6 +81,33 @@ const OUTCOME_COLOR: Record<string, string> = {
       </div>
     </div>
 
+    <!-- requirement → evidence, in-app twin of the PR verification report's section: which of
+         the service's written-down requirements this run actually ruled on, and what it saw -->
+    <div
+      v-if="report.requirementVerdicts?.length"
+      class="mb-3 space-y-1"
+      data-testid="test-report-requirement-verdicts"
+    >
+      <div class="text-[11px] text-slate-500">
+        {{ t('panels.testReport.requirementVerdicts.title') }}
+      </div>
+      <div
+        v-for="(verdict, i) in report.requirementVerdicts"
+        :key="i"
+        class="flex items-start gap-2 text-[12px]"
+      >
+        <span
+          class="mt-1 h-2 w-2 shrink-0 rounded-full"
+          :style="{ backgroundColor: verdictMeta(verdict.status).color }"
+        />
+        <span class="text-slate-300">
+          <span class="font-mono text-[11px] text-slate-400">{{ verdict.requirementId }}</span>
+          <span class="text-slate-500"> — {{ verdictMeta(verdict.status).label }}</span>
+          <span v-if="verdict.detail" class="text-slate-500"> · {{ verdict.detail }}</span>
+        </span>
+      </div>
+    </div>
+
     <div v-if="report.concerns.length" class="space-y-1">
       <div class="text-[11px] text-slate-500">{{ t('panels.testReport.concerns') }}</div>
       <div

package/app/components/providers/AiProviderOnboardingModal.vue

@@ -27,10 +27,23 @@ interface Route {
   title: string
   body: string
   cta: string
+  badge?: string
   onSelect: () => void
 }
 
+// The personal-subscription route leads: using an individual coding-plan subscription the
+// developer already pays for (Claude / ChatGPT-Codex / GLM) is the most common setup, and
+// it used to hide behind the generic "LLM vendors" route as the last tab, where new users
+// missed it. It deep-links straight onto the vendor modal's `personal` tab.
 const routes = computed<Route[]>(() => [
+  {
+    icon: 'i-lucide-user',
+    title: t('providers.onboarding.routes.personal.title'),
+    body: t('providers.onboarding.routes.personal.body'),
+    cta: t('providers.onboarding.routes.personal.cta'),
+    badge: t('providers.onboarding.routes.personal.badge'),
+    onSelect: () => go(() => ui.openVendorCredentials('personal')),
+  },
   {
     icon: 'i-lucide-key-round',
     title: t('providers.onboarding.routes.keys.title'),
@@ -85,7 +98,12 @@ const routes = computed<Route[]>(() => [
           >
             <UIcon :name="r.icon" class="mt-0.5 h-5 w-5 shrink-0 text-indigo-300" />
             <div class="min-w-0 flex-1">
-              <p class="text-sm font-semibold text-slate-100">{{ r.title }}</p>
+              <div class="flex items-center gap-2">
+                <p class="text-sm font-semibold text-slate-100">{{ r.title }}</p>
+                <UBadge v-if="r.badge" color="primary" variant="subtle" size="sm">
+                  {{ r.badge }}
+                </UBadge>
+              </div>
               <p class="mt-0.5 text-[13px] leading-relaxed text-slate-400">{{ r.body }}</p>
             </div>
             <UButton

package/app/components/providers/PersonalCredentialModal.vue

@@ -85,7 +85,9 @@ async function submit() {
 
 function goConnect() {
   personal.dismissPending()
-  ui.openVendorCredentials()
+  // Deep-link onto the personal tab: this CTA promises the individual-subscription connect
+  // form, and the modal's default tab is the (unrelated) workspace pool.
+  ui.openVendorCredentials('personal')
 }
 </script>
 

package/app/components/providers/VendorCredentialsModal.vue

@@ -209,6 +209,28 @@ function vendorLabel(v: SubscriptionVendor): string {
         <!-- Workspace pool (commercial coding-plan subscriptions) -->
         <template #pool>
           <div class="space-y-5">
+            <!-- The pool is the modal's default tab, but most individual developers arrive
+                 looking for their OWN Claude / ChatGPT / GLM plan, which lives on the
+                 `personal` tab — point them there before they read a pool form that can't
+                 take their credential. -->
+            <div
+              class="flex items-center gap-3 rounded-lg border border-indigo-500/30 bg-indigo-950/30 px-3 py-2.5"
+            >
+              <UIcon name="i-lucide-user" class="h-5 w-5 shrink-0 text-indigo-300" />
+              <p class="min-w-0 flex-1 text-[13px] text-slate-300">
+                {{ t('providers.vendorCredentials.personalCallout.text') }}
+              </p>
+              <UButton
+                size="xs"
+                color="primary"
+                variant="subtle"
+                class="shrink-0"
+                @click="activeTab = 'personal'"
+              >
+                {{ t('providers.vendorCredentials.personalCallout.cta') }}
+              </UButton>
+            </div>
+
             <p class="text-sm text-slate-400">
               {{ t('providers.vendorCredentials.poolIntro') }}
             </p>

package/app/components/spec/ServiceSpecWindow.logic.spec.ts

@@ -0,0 +1,108 @@
+import { describe, it, expect } from 'vitest'
+import {
+  filterRequirementsByState,
+  requirementState,
+  summarizeRequirementStates,
+  summarizeSpecStates,
+} from './ServiceSpecWindow.logic'
+import type { RequirementItem, SpecModule } from '~/types/spec'
+
+/**
+ * The implementation-state view of the service-spec window (service-acceptance-criteria, slice 4).
+ * The axis only earns its keep if "agreed" and "observed to hold" never render the same, so these
+ * pin the counting, the defensive read of a missing state, and the filter's identity fast path.
+ */
+const req = (id: string, state?: RequirementItem['state']): RequirementItem =>
+  ({
+    id,
+    title: id,
+    statement: `The system SHALL ${id}.`,
+    kind: 'functional',
+    priority: 'must',
+    ...(state ? { state } : {}),
+  }) as RequirementItem
+
+describe('requirementState', () => {
+  it('reads an explicit established state', () => {
+    expect(requirementState(req('a', 'established'))).toBe('established')
+  })
+
+  it('treats an absent or unknown state as aspirational', () => {
+    expect(requirementState(req('a'))).toBe('aspirational')
+    expect(requirementState({ state: 'nonsense' } as unknown as RequirementItem)).toBe(
+      'aspirational',
+    )
+  })
+})
+
+describe('summarizeRequirementStates', () => {
+  it('counts both halves and their total', () => {
+    expect(
+      summarizeRequirementStates([
+        req('a', 'established'),
+        req('b', 'aspirational'),
+        req('c', 'established'),
+      ]),
+    ).toEqual({ total: 3, established: 2, aspirational: 1 })
+  })
+
+  it('counts a requirement with no state as aspirational', () => {
+    expect(summarizeRequirementStates([req('a')])).toEqual({
+      total: 1,
+      established: 0,
+      aspirational: 1,
+    })
+  })
+
+  it('returns zeroes for an absent or empty list', () => {
+    const zero = { total: 0, established: 0, aspirational: 0 }
+    expect(summarizeRequirementStates(undefined)).toEqual(zero)
+    expect(summarizeRequirementStates([])).toEqual(zero)
+  })
+})
+
+describe('summarizeSpecStates', () => {
+  // The parsed wire type fills every optional with its default, so the sparse shapes below are
+  // cast: they stand for what a hand-written or partially-hydrated tree actually looks like at
+  // runtime, which is exactly the case the helpers are defensive about.
+  const modules = [
+    {
+      name: 'auth',
+      groups: [
+        { name: 'login', requirements: [req('a', 'established'), req('b')] },
+        { name: 'logout', requirements: [req('c', 'established')] },
+      ],
+    },
+    // A module whose only group has no requirements, and a module with no groups at all: both
+    // contribute nothing rather than throwing — a spec is legitimately sparse while it is
+    // being written.
+    { name: 'billing', groups: [{ name: 'invoices' }] },
+    { name: 'empty' },
+  ] as unknown as SpecModule[]
+
+  it('rolls the per-group counts up across the tree', () => {
+    expect(summarizeSpecStates(modules)).toEqual({ total: 3, established: 2, aspirational: 1 })
+  })
+
+  it('returns zeroes for an absent module list', () => {
+    expect(summarizeSpecStates(undefined)).toEqual({ total: 0, established: 0, aspirational: 0 })
+  })
+})
+
+describe('filterRequirementsByState', () => {
+  const list = [req('a', 'established'), req('b'), req('c', 'aspirational')]
+
+  it('returns the same array reference for the default filter', () => {
+    expect(filterRequirementsByState(list, 'all')).toBe(list)
+  })
+
+  it('keeps only the requested half', () => {
+    expect(filterRequirementsByState(list, 'established').map((r) => r.id)).toEqual(['a'])
+    expect(filterRequirementsByState(list, 'aspirational').map((r) => r.id)).toEqual(['b', 'c'])
+  })
+
+  it('handles an absent list', () => {
+    expect(filterRequirementsByState(undefined, 'established')).toEqual([])
+    expect(filterRequirementsByState(undefined, 'all')).toEqual([])
+  })
+})

package/app/components/spec/ServiceSpecWindow.logic.ts

@@ -0,0 +1,71 @@
+// Pure logic behind the service-spec window's IMPLEMENTATION-STATE view.
+//
+// `spec/` is prescriptive — it says what must be TRUE — and `requirementItem.state` is what
+// lets it also say what is true YET (`aspirational` = agreed via the spec diff's PR review,
+// `established` = a tester exercised its acceptance criteria and they passed). The agents
+// already read that split off their checkout; this is the half a HUMAN reads, so the same
+// window that lists a service's behaviour can say how much of it the service actually honours.
+//
+// Kept out of the SFC so the counting and filtering are unit-testable without mounting Nuxt.
+import type { RequirementItem, RequirementState, SpecModule } from '~/types/spec'
+
+/** Which half of the spec the reader wants to see. `all` is the default (nothing hidden). */
+export type RequirementStateFilter = 'all' | RequirementState
+
+/** Requirement counts for one scope (a group, or a whole spec). */
+export interface RequirementStateSummary {
+  total: number
+  established: number
+  aspirational: number
+}
+
+/**
+ * Read a requirement's implementation state defensively. The wire schema defaults an absent
+ * value to `aspirational` at the parse boundary, but a requirement nobody has observed to hold
+ * is exactly what an unreadable/absent state means — so treating anything that is not literally
+ * `established` as aspirational is both the safe answer and the one the backend renders.
+ */
+export function requirementState(item: Pick<RequirementItem, 'state'>): RequirementState {
+  return item.state === 'established' ? 'established' : 'aspirational'
+}
+
+/** Count a list of requirements by implementation state. */
+export function summarizeRequirementStates(
+  requirements: readonly Pick<RequirementItem, 'state'>[] | undefined,
+): RequirementStateSummary {
+  const total = requirements?.length ?? 0
+  let established = 0
+  for (const req of requirements ?? []) {
+    if (requirementState(req) === 'established') established += 1
+  }
+  return { total, established, aspirational: total - established }
+}
+
+/** Roll the per-group counts up across the whole spec tree (the overview pane's headline). */
+export function summarizeSpecStates(
+  modules: readonly SpecModule[] | undefined,
+): RequirementStateSummary {
+  const summary: RequirementStateSummary = { total: 0, established: 0, aspirational: 0 }
+  for (const module of modules ?? []) {
+    for (const group of module.groups ?? []) {
+      const groupSummary = summarizeRequirementStates(group.requirements)
+      summary.total += groupSummary.total
+      summary.established += groupSummary.established
+      summary.aspirational += groupSummary.aspirational
+    }
+  }
+  return summary
+}
+
+/**
+ * Apply the reader's state filter. `all` returns the SAME array reference (not a copy), so the
+ * default view costs nothing and a `v-for` key set never churns on an unrelated re-render.
+ */
+export function filterRequirementsByState<T extends Pick<RequirementItem, 'state'>>(
+  requirements: readonly T[] | undefined,
+  filter: RequirementStateFilter,
+): readonly T[] {
+  const list = requirements ?? []
+  if (filter === 'all') return list
+  return list.filter((req) => requirementState(req) === filter)
+}

package/app/components/spec/ServiceSpecWindow.vue

@@ -10,9 +10,17 @@ import type {
   RequirementItem,
   RequirementKind,
   RequirementPriority,
+  RequirementState,
   SpecModule,
 } from '~/types/spec'
 import ResultWindowShell from '~/components/panels/ResultWindowShell.vue'
+import {
+  filterRequirementsByState,
+  requirementState,
+  summarizeRequirementStates,
+  summarizeSpecStates,
+  type RequirementStateFilter,
+} from './ServiceSpecWindow.logic'
 
 const { t } = useI18n()
 const board = useBoardStore()
@@ -20,6 +28,16 @@ const serviceSpec = useServiceSpecStore()
 
 type ViewMode = 'structured' | 'gherkin'
 const mode = ref<ViewMode>('structured')
+// Which half of the spec the reader wants: everything, only what the service is observed to
+// honour, or only what is agreed but not built yet.
+//
+// DELIBERATELY STICKY ACROSS GROUPS, and reset only on open (alongside the view mode and the
+// selection). "Show me what this service has actually proven" is a question about the SERVICE,
+// so re-answering it on every group click would defeat the filter the moment the reader
+// navigates. The cost is that a group with no match renders empty, which is why that case says
+// so and offers a way back rather than leaving the reader stranded in a filter they may have
+// set several groups ago.
+const stateFilter = ref<RequirementStateFilter>('all')
 // Selected feature group, keyed by its module + group index so a name collision can't
 // cross-select. Null = show the service overview.
 const selected = ref<{ m: number; g: number } | null>(null)
@@ -27,6 +45,7 @@ const selected = ref<{ m: number; g: number } | null>(null)
 const { open, blockId, close } = useResultView('service-spec', {
   onOpen: ({ blockId }) => {
     mode.value = 'structured'
+    stateFilter.value = 'all'
     selected.value = null
     void serviceSpec.load(blockId)
   },
@@ -109,9 +128,47 @@ const KIND_LABELS: Record<RequirementKind, string> = {
   constraint: t('spec.kind.constraint'),
 }
 
+// Exhaustive implementation-state → presentation map. `established` is the only state that
+// means "the service is observed to do this"; everything else is a behaviour that has been
+// agreed and not yet seen to hold, which must never read as standing behaviour.
+const STATE_META: Record<RequirementState, { label: string; chip: string; icon: string }> = {
+  established: {
+    label: t('spec.state.established'),
+    chip: 'success',
+    icon: 'i-lucide-circle-check',
+  },
+  aspirational: {
+    label: t('spec.state.aspirational'),
+    chip: 'neutral',
+    icon: 'i-lucide-circle-dashed',
+  },
+}
+
+// The state filter's three choices. The two state choices REUSE the badge labels rather than
+// carrying their own catalog keys: a chip that reads differently from the badge it filters for
+// is a translation bug waiting to happen, and one key per state cannot drift from itself. Only
+// `all` needs a key of its own, and it is a literal `t()` so the typed-key drift guard stays live.
+const STATE_FILTERS: { value: RequirementStateFilter; label: string }[] = [
+  { value: 'all', label: t('spec.state.filter.all') },
+  { value: 'established', label: STATE_META.established.label },
+  { value: 'aspirational', label: STATE_META.aspirational.label },
+]
+
+// Service-wide rollup, shown on the overview pane: how much of the written-down behaviour the
+// service is actually known to honour.
+const specStates = computed(() => summarizeSpecStates(modules.value))
+// The selected group's rollup + the requirements the filter admits.
+const groupStates = computed(() => summarizeRequirementStates(selectedGroup.value?.requirements))
+const visibleRequirements = computed(() =>
+  filterRequirementsByState(selectedGroup.value?.requirements, stateFilter.value),
+)
+
 function reqCount(group: RequirementGroup): number {
   return group.requirements?.length ?? 0
 }
+function stateMeta(item: RequirementItem) {
+  return STATE_META[requirementState(item)]
+}
 function priorityMeta(item: RequirementItem) {
   return PRIORITY_META[item.priority] ?? PRIORITY_META.could
 }
@@ -265,6 +322,21 @@ function kindLabel(item: RequirementItem): string {
             {{ spec.summary }}
           </p>
           <p v-else class="mt-2 text-sm text-slate-500">{{ t('spec.noSummary') }}</p>
+          <!-- implementation-state rollup: how much of the written-down behaviour is observed
+               to hold, rather than merely agreed -->
+          <div
+            v-if="specStates.total > 0"
+            class="mt-4 flex flex-wrap items-center gap-2 text-xs"
+            data-testid="spec-state-rollup"
+          >
+            <UBadge color="success" variant="subtle" size="sm">
+              {{ t('spec.state.establishedCount', { count: specStates.established }) }}
+            </UBadge>
+            <UBadge color="neutral" variant="subtle" size="sm">
+              {{ t('spec.state.aspirationalCount', { count: specStates.aspirational }) }}
+            </UBadge>
+            <span class="text-slate-500">{{ t('spec.state.rollupHint') }}</span>
+          </div>
           <p class="mt-4 text-xs text-slate-500">
             {{
               hasGherkin
@@ -303,15 +375,84 @@ function kindLabel(item: RequirementItem): string {
             <div v-if="reqCount(selectedGroup) === 0" class="mt-4 text-sm text-slate-500">
               {{ t('spec.noRequirements') }}
             </div>
+            <!-- per-group implementation-state rollup + the filter over the two halves -->
+            <div
+              v-else
+              class="mt-4 flex flex-wrap items-center justify-between gap-2"
+              data-testid="spec-state-filter"
+            >
+              <div class="flex items-center gap-1.5 text-[11px] text-slate-500">
+                <UIcon :name="STATE_META.established.icon" class="h-3.5 w-3.5 text-emerald-400" />
+                {{
+                  t('spec.state.groupRollup', {
+                    established: groupStates.established,
+                    total: groupStates.total,
+                  })
+                }}
+              </div>
+              <div class="flex items-center rounded-lg border border-slate-700 p-0.5">
+                <UButton
+                  v-for="option in STATE_FILTERS"
+                  :key="option.value"
+                  :color="stateFilter === option.value ? 'primary' : 'neutral'"
+                  :variant="stateFilter === option.value ? 'soft' : 'ghost'"
+                  size="xs"
+                  :data-testid="`spec-state-filter-${option.value}`"
+                  @click="
+                    () => {
+                      stateFilter = option.value
+                    }
+                  "
+                >
+                  {{ option.label }}
+                </UButton>
+              </div>
+            </div>
+            <!-- the filter can legitimately empty a non-empty group; say so rather than
+                 rendering a blank pane that reads like "no requirements". The filter is sticky
+                 across groups, so the reader may have set it several groups ago — offer the way
+                 back here rather than making them find the toggle again. -->
+            <div
+              v-if="reqCount(selectedGroup) > 0 && visibleRequirements.length === 0"
+              class="mt-4 flex flex-wrap items-center gap-2 text-sm text-slate-500"
+              data-testid="spec-state-filter-empty"
+            >
+              {{ t('spec.state.noneMatchFilter') }}
+              <UButton
+                color="primary"
+                variant="link"
+                size="xs"
+                class="p-0"
+                data-testid="spec-state-filter-reset"
+                @click="
+                  () => {
+                    stateFilter = 'all'
+                  }
+                "
+              >
+                {{ t('spec.state.showAll') }}
+              </UButton>
+            </div>
             <ul class="mt-4 space-y-4">
               <li
-                v-for="req in selectedGroup.requirements ?? []"
+                v-for="req in visibleRequirements"
                 :key="req.id"
                 class="rounded-lg border border-slate-800 bg-slate-900/60 p-4"
               >
                 <div class="flex items-start justify-between gap-3">
                   <h3 class="text-sm font-semibold text-slate-100">{{ req.title }}</h3>
                   <div class="flex shrink-0 items-center gap-1.5">
+                    <!-- implementation state: agreed vs observed to hold. The distinction the
+                         build prompt and the tester act on, so a reader must see it too. -->
+                    <UBadge
+                      :color="stateMeta(req).chip as any"
+                      variant="subtle"
+                      size="sm"
+                      :icon="stateMeta(req).icon"
+                      :data-testid="`spec-requirement-state-${requirementState(req)}`"
+                    >
+                      {{ stateMeta(req).label }}
+                    </UBadge>
                     <UBadge :color="priorityMeta(req).chip as any" variant="subtle" size="sm">
                       {{ priorityMeta(req).label }}
                     </UBadge>

package/app/types/domain.ts

@@ -55,6 +55,8 @@ export type {
   TestConcern,
   TestOutcome,
   TestReport,
+  RequirementVerdict,
+  RequirementVerdictStatus,
   TestScreenshot,
   AgentKind,
   AgentCategory,

package/app/types/spec.ts

@@ -10,6 +10,7 @@
 export type {
   RequirementPriority,
   RequirementKind,
+  RequirementState,
   AcceptanceCriterion,
   RequirementItem,
   DomainRule,