Feature Guide

A tester-facing reference for the feature sets that shipped this month. Read this once before running test groups L–O in hackorda-test-cases.md — it explains how the features are meant to behave, so the test cases make sense and you can tell a bug from designed behaviour.

Read onboarding.md first if you haven't. This guide assumes you know the basic vocabulary (cycle, issue, triage, severity).

---

A. Cycle close-out tools

These live on the admin cycle detail page, /app/admin/test-cycles/[id]. They help an admin wrap a cycle up: push the real bugs to Linear, and clear the queue of fixes that still need verifying.

Batch Linear export — Issues tab

When the cycle's product has a Linear integration configured, each issue row in the Issues tab gains a checkbox, and a toolbar appears above the list:

The export dialog offers two modes — group (one Linear issue covering the batch) or separate (one Linear issue per selected issue). On a successful export the selection clears.

If the product has no Linear integration, there are no checkboxes and no toolbar at all — the Issues tab looks exactly as it did before.

Bulk verification queue — Overview tab

The Overview tab shows an amber "Awaiting fix verification (N)" card. It lists every issue currently in status fixed — the ones an engineer says they've fixed and that now need a tester to confirm. Each row has two actions:

A row you act on drops off the list immediately. When nothing is awaiting verification, the whole card is hidden — an empty cycle Overview won't show it.

---

B. Cycle aging & list views

These changes are on the test-cycles list — both the tester view (/app/test-cycles) and the admin view (/app/admin/test-cycles). They make it obvious which cycles have been sitting too long and how far through review each one is.

Aging pill

Every cycle row/card shows an aging pill — e.g. In review 6d, Active 2d. It counts how long the cycle has been in its current status. For review cycles the colour escalates:

Cycles in any non-review status (planned, active, closed, cancelled) always show a neutral pill, regardless of age.

Progress bar

A thin segmented bar summarises issue triage progress:

It carries a label like 12 / 17 reviewed · 71%. A cycle with no issues shows No issues yet instead of a bar.

Views — Cards, Table, Timeline, Board

The list has a view toggle. The view you pick persists across reloads.

• Cards view — each card shows the aging pill + progress bar. A sort dropdown in the toolbar offers: Longest in review, Recently created, Ending soonest, Name A–Z. Selecting the review status filter auto-switches the sort to Longest in review.
• Table view — has a sortable "Days in review" column (this is the table's default sort, descending; non-review cycles sink below review cycles) and a "Progress" column.
• Timeline view — unchanged.
• Board view (new) — a Kanban board, the 4th option in the toggle. One column per status: planned, active, review, closed, cancelled. Cycles sit in their status column; within a column cards are sorted stalest-first (longest in status on top). Empty columns read "No cycles". On a narrow screen the board scrolls horizontally.

Honest caveat — approximate age for old cycles

The day count is exact for any cycle that changes status from now on. Cycles that were already in review before this feature shipped show an approximate age — the system didn't record a precise "entered review" timestamp for them. Don't file a bug just because an old cycle's pill looks a day or two off; it's a known limitation, not a defect.

---

C. Mobile responsiveness

The following surfaces are now usable at phone width (~375px):

• the admin cycle detail page,
• triage rows and the status controls on them,
• the cycle list (all views),
• the tester issue and fix-verification screens.

Desktop layout is unchanged — if anything looks different on desktop, that's a regression worth filing.

---

D. Roles & payout integrity

A new role tier — super_admin — sits above admin. This split exists so that money movement and access changes need a higher level of trust than everyday triage. Here is who can do what:

Self-dealing guard

Nobody — not even a super-admin — can approve OR pay out a payout for an issue they reported themselves. The action is blocked with a permission error. This stops anyone from filing an issue and then signing off their own payout.

Audit log

A new screen at /app/admin/audit (an "Audit Log" entry in the sidebar) shows a trail of sensitive actions: payout decisions, batch payments, role changes, and cycle status changes. It is filterable by action and by actor, and is visible to super-admins only.

Role management UI

On the users admin page, the role dropdown is interactive only for super-admins. A plain admin sees each user's role as a read-only badge — they can look, but not change.

See approval-process.md for the step-by-step procedure that ties triage, the verification gate, and disbursement together for a super-admin.

---

What this means for you

Your test account is a plain admin. You can run almost everything in groups L–O yourself. The cases that need a payout approved or paid, or that open the Audit Log, must be set up or run by the owner (a super-admin) — each such case says so in its Preconditions. See onboarding.md §12 for the full account/tier breakdown and the test-data rule.