Drop a case onto a plan — the target appears only while you drag
Grab a test case from the Library tree, drag it down, and a drop strip materializes at the bottom of the screen — listing only the plans that can actually accept the case. Zero idle pixels, no closed ledgers reopened by accident.
From the library to a plan, without the round trip
Adding a case to a test plan used to mean opening a picker modal, finding the plan, finding the case, confirming. That's fine when you're staging a whole plan. It's friction when you've got a case open in the Library and you just want it in the regression plan, now.
So now you drag it. Grab a case from the Library tree, pull it down, and a drop strip materializes along the bottom of the screen — one chip per plan, drop, done. The case is added without ever leaving the page.
The drop strip appears only while you drag — each chip is a plan ready to receive the case.
The drop strip, pinned across the tree and detail panes, present only for the duration of the drag.
Zero idle pixels
The strip isn't a permanent toolbar eating a slice of the screen. It exists only for the seconds your drag is in flight — it materializes when you pick up a case and vanishes the instant you drop, cancel with Esc, or let go off-target. When you're not dragging, it costs nothing. The affordance is exactly as big as the moment that needs it.
Only the plans that can actually take it
The strip doesn't list every plan you have — it lists the ones that can accept the case. Drafts, active plans, executing plans, paused plans: all valid targets. Archived plans and completed plans are excluded, and the completed one is the interesting case.
A completed plan is a closed ledger — every case in it accounted for, the plan signed off. Drop a fresh, not-yet-run case into it and you'd silently reopen that ledger: a plan that reads "complete" while quietly holding work that was never done, with no automatic path back to executing. That's a closed book a colleague reopened by accident and nobody noticed. So we don't allow it. The drop strip simply never offers a completed plan as a target — the constraint is visible in what you can aim at, not buried in an error after you've already let go.
Drop the same case twice, and nothing breaks
Drag a case onto a plan it's already in and you don't get a duplicate row or a red error. The server dedups it and hands back a quiet "already in plan" note — the same friendly result the picker modal gives you. Drop on a brand-new plan and the case rides into the plan the moment it's created. The mechanics stay out of your way.
An enhancement, not a replacement
Drag-and-drop is a mouse, large-screen nicety — a faster path for the common move, not the only one. The picker modal stays exactly where it was: the keyboard path, the accessible path, the way to stage many cases at once. We added a shortcut for the impatient moment without taking anything away from anyone who needs the deliberate one.
It's a small thing. But staging plans is something a QA lead does dozens of times a sprint, and shaving a modal round-trip off the most common move — while quietly refusing the one move that would corrupt a closed plan — is the kind of small thing that adds up.
Curious how this looks inside your team?
Book a short consult and we will walk through how OpenTestX maps to your current QA system.
Book a consultation →Related posts
Our risk pill almost shipped a lie. Our own eval caught it.
We built a Gantt board that flags its own slipping groups and drafts a catch-up plan from your team's methodology. Then our own A/B eval told us the proof was rigged — so we fixed the product, not the test. The honest 5 → 1 → 5.
Our coral sat 9° from our error red. We fixed color by measuring, not feeling.
A user told us twice the colors were too similar. The first fix over-corrected — every category chip went gray, and uniform is not the same as clear. The second fix put a number on it: our brand coral lives at hue 9°, our error red at 0°. Nine degrees apart, same lightness. You don't argue with 9°. You move.
The governance flywheel: when recurring review findings write their own methodology rule
Every AI review finding already lands in a per-case worklist. But the patterns across cases were going unread. The flywheel reads them — and when a weakness has truly recurred, it proposes one grounded SKILL.md rule into the queue you already approve from. The SQL decides. The model only phrases. A human still signs.