Run #1

• Target: http://localhost:3456 — a self-hosted instance of Vikunja, an open-source task manager (lists, Kanban, Gantt).
• Testing level: Exploratory, whole application, no exclusions requested.
• Date: 2026-08-12.
• Run accounts: the run registered and used its own primary account, qa-runner-142310, plus a secondary account, qa-runner2-142310, created specifically to test cross-account isolation, team/project sharing, and a password-change flow that was deliberately kept off the primary account so a broken password path couldn't lock the run out. No passwords are reproduced in this report.
• Headline result: 32 scenarios executed, 21 passed, 11 failed, 0 blocked (recounted directly from the scenario logs).

This run went through an additional adversarial audit step: a Critic agent re-verified every fail/blocked verdict and every critical/high defect directly against the live app before this report was written. That audit is binding on this report. Its most important conclusion: the run's only critical defect and its only high-severity defect were both misreads, not real bugs, and both are withdrawn below with a plain-language explanation. After applying the Critic's findings, this run has no confirmed critical or high-severity defect — the reportable defect set is medium severity and below. The Critic also surfaced four additional real, lower-severity issues the Tester had noticed but filed only as passing observations; those are promoted into the issues list and marked accordingly.

No critical or high-severity defects survive the Critic's audit (see Withdrawn findings below for the two that did not hold up). The confirmed/promoted issue set is medium and low severity.

• Scenario: S7 (dates and reminders)
• Reproduction steps:
• Open a task that already has an End Date (e.g. tomorrow).
• Set its Start Date to several days later than that End Date, using the app's own date picker, and save.
• Observe the task detail page and reload it.
• Expected: A start date later than the end date should be rejected outright, or accompanied by an explicit visible warning (per the scenario's own success condition — silent graceful acceptance still counts as a validation defect).
• Actual: The app silently accepted and persisted Start Date "in 5 days" against an End Date of "in 21 hours," with no warning, error, or visual flag anywhere, before or after a reload.
• Evidence: screenshots/S7-start-after-end.png. Independently reproduced by the Critic (screenshots/critic-S7-start-after-end.png), confirmed via the server record (start_date after end_date) — this is a genuine, confirmed defect.

• Scenario: S16 (project creation validation)
• Reproduction steps:
• Open the New Project form.
• Type three spaces into the Title field and submit.
• Expected: A whitespace-only title should be rejected with an explicit message or a disabled submit button (per the scenario's failure condition).
• Actual: The project is created successfully with a completely blank page heading, a blank browser tab title (| Vikunja), and a blank, text-less entry in both the sidebar and the /projects grid — the project exists but is permanently unlabeled and hard to distinguish from other blank entries.
• Evidence: screenshots/S16-whitespace-title.png, screenshots/S16-blank-sidebar-entry.png. Independently reproduced by the Critic (screenshots/critic-S16-whitespace-project.png).

• Scenario: S8 (labels lifecycle)
• Reproduction steps:
• On /labels, create a label titled qa-urgent.
• Create a second label with the exact same title qa-urgent.
• Expected: A duplicate label title should be explicitly rejected or at least flagged at creation time (per the scenario's success condition).
• Actual: The app accepts the duplicate with no warning; the run ended with several visually identical labels (three qa-filter-test, two qa-urgent) that are genuinely indistinguishable from one another in every label picker across the app (no ID, colour, or project hint to tell them apart).
• Evidence: screenshots/S8-duplicate-label.png. Independently confirmed by the Critic, who found the same indistinguishable-duplicate problem in the Table-view filter's label autocomplete (screenshots/critic-S8-filter-label-autocomplete.png, screenshots/critic-S8-picker-with-keystrokes.png).
• Note: the Tester originally attributed a second, more severe bug to this same area — that the label picker "always creates a new duplicate label" whenever an existing label is applied to a task. That specific claim did not hold up (see Withdrawn findings, W2); this narrower "duplicate titles allowed" finding is the part that survives.

• Scenario: S15 (project lifecycle)
• Reproduction steps:
• Open a project's Edit dialog by navigating directly to its settings-edit URL (e.g. typing http://localhost:3456/projects/{id}/settings/edit directly, or refreshing the browser while that dialog is open) rather than opening it through the in-app project menu.
• Rename the project and save.
• Check the page heading, the browser tab title, and the sidebar entry without reloading.
• Expected: The new name should appear in the heading, tab title, and sidebar immediately.
• Actual: The rename is correctly saved server-side (confirmed via the API), but the heading, tab title, and sidebar all continue to show the old name indefinitely — only a manual reload picks up the correct name.
• Evidence: screenshots/S15-rename-stale-heading.png. The Critic independently reproduced this exact path-dependence (screenshots/critic-S15-stale-after-directurl-save.png) and also confirmed the opposite: renaming through the normal in-app project menu → Edit path updates every surface immediately, with no delay (screenshots/critic-S15-rename-after-save.png).
• Note: the Tester's original framing ("does not propagate reactively anywhere") was broader than what's actually true. The bug is real but narrower: it only occurs when the Edit dialog is reached via a direct URL/deep link or a page refresh, not via ordinary in-app navigation.

• Scenario: S28 (data export/import)
• Reproduction steps:
• Open Settings → Import from other services → CSV.
• Upload a file containing clearly invalid content (e.g. not a valid csv {{{).
• Expected: An invalid import file should produce a clear, user-facing validation error (per the scenario's failure condition).
• Actual: The app throws an unhandled JavaScript exception surfaced to the user as the raw error toast "Cannot read properties of null (reading '0')," and the main content area of the settings page goes completely blank — leaving the user on a broken-looking page with no explanation of what was wrong with their file.
• Evidence: screenshots/S28-invalid-csv.png. Independently reproduced verbatim by the Critic, including the exact error text and the blanked content area (screenshots/critic-S28-invalid-csv.png).
• Note: S31's console/broken-media sweep flagged what looked like a second, separate crash finding — it is the same bug. See Withdrawn findings (W5) for why it is not counted twice.

• Scenario: S21 (saved filters)
• Reproduction steps:
• Create a New Saved Filter with a numeric query, e.g. priority >= 3, leaving all form defaults untouched.
• Open the filter and observe its results.
• Compare against the identical query built inside a project view's own Filters modal.
• Expected: The same query should behave the same way regardless of where it is built and applied.
• Actual: The New Saved Filter form defaults its "Include Tasks which don't have a value set" option to checked, so priority >= 3 also matches every task whose priority was never set (Vikunja stores unset priority as null/0) — the saved filter appears to return every task in every project, which looks exactly like "the filter isn't being applied at all." The project-view Filters modal defaults the same option to unchecked, so the identical query there correctly returns only the true matches. Nothing is actually broken in the filter engine — the two builders just disagree on a hidden default, and a saved filter can silently look non-functional as a result.
• Evidence: screenshots/critic-S21-filterA-form.png, screenshots/critic-S21-filterA-all-tasks.png, screenshots/critic-S21-filterB-two-tasks.png, screenshots/critic-S21-edit-includenulls.png.
• Origin: this is the corrected, promoted version of what the Tester originally reported as a critical "saved filters never apply their query" bug — see Withdrawn findings (W1) for the full explanation of the misread, and Coverage & caveats for how this affects the run's headline severity.

• Scenarios: S18 (filters), corroborated by S8 (label filtering)
• Reproduction steps:
• On a project's Table/List view, open FILTERS and enter clearly malformed text, e.g. &&& !! garbage (((.
• Separately, build a filter whose label/value never actually resolves to a real ID (e.g. an ambiguous or mistyped label reference).
• Expected: An invalid or unresolvable filter should produce an explicit error message.
• Actual: Two different silent-failure paths, both indistinguishable from a legitimately empty result: (1) a garbage expression is silently reinterpreted by the backend as a free-text search that matches nothing, rendering a blank table with no message; (2) a well-formed but unresolvable filter is rejected by the backend with an HTTP 400 that the frontend also renders as a blank table with no message at all.
• Evidence: screenshots/S18-malformed-result.png, screenshots/S8-filter-empty-result.png. The Critic independently reproduced both failure modes (screenshots/critic-S18-malformed-filter.png, screenshots/critic-S8-label-filter-result.png) and confirmed it is slightly worse than originally logged, since it happens in two different ways.

• Scenario: S32 (document title / navigation integrity)
• Reproduction steps:
• Navigate to /projects via any client-side navigation (sidebar link or Back button).
• Check the browser tab title.
• Expected: Every route's tab title should identify the page actually shown.
• Actual: The tab title on /projects is the literal, un-interpolated template string Title | Vikunja, both on a fresh client-side navigation and after using the Back button to return to that route. Every other route checked in this run (task detail, Kanban, Table, Gantt, a deep-link reload) resolved its title correctly.
• Evidence: No dedicated screenshot was filed for this defect (verified via the page's document.title directly); independently reconfirmed by the Critic on repeated visits during the audit.

• Scenario: S16 (project creation validation)
• Reproduction steps:
• Open the New Project form and type a 2000-character title.
• Submit.
• Expected: An extreme-length title should be rejected with a stated limit, or accepted and rendered without breaking layout.
• Actual: The title is accepted into the input with no client-side length cap at all; on submit, the backend correctly rejects it (HTTP 412) and the frontend does show a red error toast ("Error — Some of the request data was invalid."), but the message never states what the actual limit is, and the toast is easy to miss if you check the page even a couple of seconds late.
• Evidence: screenshots/S16-longtitle-silent-fail.png (taken after the toast had already expired). The Critic's own screenshot, taken at the moment of submission, shows the toast is genuinely present (screenshots/critic-S16-longtitle-silent.png).
• Note: the Tester originally reported this as a fully silent failure with zero visible error. That specific claim is corrected here — the app does give feedback, just poorly-timed/worded feedback. See the Critic's re-verification for detail.

• Scenario: S7 (dates and reminders)
• Reproduction steps:
• On a task with a Due Date later today, add a relative reminder such as "1 day before Due Date," at a point in the day when that reminder's absolute time has already elapsed.
• Save and observe the confirmation.
• Expected: A reminder resolving to the past should be rejected or explicitly flagged (per the scenario's failure condition).
• Actual: The reminder was accepted with only a generic "task saved successfully" toast — nothing distinguished it from a genuinely future reminder.
• Evidence: screenshots/S7-reminder-set.png.
• Caveat: the Critic did not independently re-verify this one live, and the Tester's own log notes that the true custom date/time reminder picker could not be reliably driven through automation — this finding rests solely on the relative-reminder inference. It is plausible and is reported, but with lower confidence than the other issues in this report.

• Scenario: S3 (registration validation)
• Reproduction steps:
• Fill in all three registration fields with valid, unused values.
• Double-click "CREATE ACCOUNT" rapidly.
• Expected: Exactly one account should result from a rapid double-click (idempotent handling of a duplicate rapid submission).
• Actual: The submit button is not disabled while the first request is in flight, so two concurrent POST /register requests do fire. In the Critic's live re-verification, the outcome was one account created plus automatic login, with one of the two concurrent requests failing server-side with an HTTP 500 the user never sees — a needless failed request, but not a broken registration from the user's point of view.
• Evidence: screenshots/S3-dblclick-misleading-error.png, screenshots/S3-dblclick-verify-account-created-fresh.png; Critic re-test: screenshots/critic-S3-doubleclick-register.png.
• Note: the Tester's original claim was more severe — that the double-click creates zero accounts while showing a false "email already exists" error. That specific outcome did not reproduce for the Critic and should not be stated as the app's behaviour; what is confirmed and worth fixing is the missing double-submit guard itself.

• Scenario: S28 (data export/import)
• Reproduction steps:
• Settings → Export your Vikunja data → request an export with your password.
• Read the confirmation toast, then reload the Export page a short time later.
• Expected: The status message shown at request time should accurately describe how and when the artifact becomes available.
• Actual: The initial toast reads "We'll notify you via email once it's ready to download," but reloading the same page moments later already shows "Your export is ready to download" with a working DOWNLOAD button — the artifact is actually ready almost immediately, in-app, on an instance that has no mail server configured at all. A user who closes the tab expecting an email may never think to check back.
• Evidence: screenshots/S28-export-requested.png, screenshots/S28-export-recheck.png.

• Scenario: S3 (registration validation)
• Reproduction steps:
• Attempt a registration that fails with a specific inline error (e.g. "A user with this email address already exists.").
• Correct only that field and resubmit with a new value that trips a different validation error.
• Expected: Correcting a field should clear the error that applied to it before showing any new result.
• Actual: The old inline error remains visible on screen alongside new errors from later attempts, across several consecutive submissions in this scenario — a user can end up looking at a wall of errors, some of which no longer apply.
• Evidence: screenshots/S3-validation-errors.png (captured during related validation steps in the same scenario; not a dedicated per-step screenshot).

• Scenario: S8 (labels lifecycle)
• Reproduction steps:
• On /labels, inspect a label row: the colored label body is a link to a filtered task view, while a small pencil icon inside the same row opens the actual edit form.
• Check the accessible name of each control.
• Expected: A control announced as "Edit Label" should open the edit form.
• Actual: Both controls are named "Edit Label" in the accessibility tree. Clicking the label's coloured body (the larger, more obvious target) navigates away to a filtered Overview instead of editing anything — only the small pencil icon actually edits.
• Evidence: not separately screenshotted; observed via accessibility-tree inspection during S8's exploration of /labels.

These are findings the Tester originally logged as defects that the Critic re-verified live against the running app and determined do not hold up as claimed. Per this run's binding audit process, they are withdrawn from the issues list above but recorded here so nothing is silently dropped.

W1 — "A custom saved filter's stored query is never actually applied — it returns every task regardless of filter criteria" (originally filed as CRITICAL, scenario S21). Withdrawn: refuted-misread. The saved-filter engine does apply its query correctly. The "returns everything" behaviour the Tester saw was caused by a checkbox: the New Saved Filter form defaults "Include Tasks which don't have a value set" to checked, which makes a query like priority >= 3 also match every task whose priority was simply never set. The Critic built the same filter twice — once with that box left at its default (checked), reproducing the "returns everything" result exactly, and once with it unchecked, which returned exactly the two tasks that genuinely have priority ≥ 3, in two different projects — and confirmed via the API and the filter's own Edit dialog that the stored query was correct the entire time. The real, lower-severity issue behind this observation is reported above as ISS-6.

W2 — "Applying an existing label to a task via the ADD LABELS autocomplete always creates a duplicate label instead of attaching the existing one" (originally filed as HIGH, scenario S8). Withdrawn: refuted-artifact. This was an artifact of how the test automation entered text — it bulk-inserted the label name instead of typing it keystroke-by-keystroke, which meant the picker's live search never ran, leaving only the "Add this as new label" option in the dropdown (which visually looks just like a normal suggestion chip). The Critic reproduced the exact same bulk-paste and got the same duplicate, then retyped the label name with individual keystrokes and the dropdown correctly listed the existing label as a selectable option — clicking it reused the label with no duplicate created. This run's own S17 evidence (Quick Add Magic reusing a pre-existing label by ID) already contradicted the "labels can't be reused" claim. What survives from S8 is the narrower, real finding that duplicate label titles are accepted with no warning — reported above as ISS-3.

W3 — "Typed markdown syntax renders as literal text instead of formatted content" (originally filed as MEDIUM, scenario S6). Withdrawn: refuted-artifact. Same root cause as W2: the rich-text editor's markdown shortcuts (bold, links, bulleted lists) fire on real keystrokes, and bulk-inserted text bypasses them — which is exactly why the toolbar's Bold button worked in the same test while the typed **bold** syntax did not. The Critic retyped the same markdown with individual keypresses and got correctly formatted bold text, a real clickable link, and a genuine bulleted list. The one thing that does survive from S6 is a UX note about inconsistent save-confirmation feedback — see UX & quality observations.

W4 — "Registration has no email verification and no consent step" (originally filed as LOW, scenario S3). Downgraded to a caveat, not a defect. The observation itself is accurate — this instance really does auto-authenticate a new account with no verification gate. The Critic classifies this as a characteristic of this particular self-hosted deployment (no mail server is configured), not an application defect, and the plan's own scope already excludes testing actual mail delivery. Reporting it as a "defect" would inflate the count with something that isn't a bug. It's recorded here as a caveat instead; see Coverage & caveats.

W5 — "Console-error/broken-media sweep found a JS crash" duplicate entry (scenario S31). Not counted as a second defect. S31's own defect entry explicitly describes itself as a cross-reference to the S28 CSV-import crash (ISS-5) — it is the same bug found again during the general sweep, not an independent second bug. S31's actual independent console and broken-image checks came back clean. Listing it separately would double-count the run's defect total, so it is folded into ISS-5 rather than listed on its own.

These are not counted as defects, but they reflect real friction, confusing flows, or unclear messaging worth a human's attention. The first four were raised by the Critic during its audit (medium confidence — worth a look, but not independently re-verified live) and are flagged as unconfirmed.

• Duplicate project titles are accepted with no disambiguation (S16 / critic review, unconfirmed): the run ended with two sidebar entries both reading "QA Sample Project," distinguishable only by clicking through to see the underlying project ID/URL.
• Setting a task's Start Date silently auto-fills its End Date to match the Due Date, with no message explaining the auto-fill (S7 / critic review, unconfirmed). Plausible as an intentional convenience default, but it was surprising in testing and is what set up the invalid start-after-end state in ISS-1.
• A Kanban drag-and-drop blocked by a bucket's task limit gives no feedback at all — no toast, flash, or message; the card simply doesn't move (S9 / critic review, unconfirmed). A real user would likely be unsure whether their drag failed for a mouse/driver reason or was intentionally rejected.
• The project Share modal's three submit buttons (user-share, team-share, link-share) are all named simply "Share" in the accessibility tree (S12 / critic review, unconfirmed) — this caused a genuine misclick during testing (accidentally submitting the team-share with an empty field).
• Description-save feedback is inconsistent: sometimes an explicit "Saved!" indicator appears after editing a task description, sometimes it does not, with no clear pattern observed (S6).
• The password-change form has no confirm-password field, so a typo in a new password is only caught if the user happens to notice it themselves (S27).
• The assignee picker never surfaces non-project-members at all, rather than showing an explicit "not a member" message when you search for someone who doesn't have access (S25) — a defensible design choice, but potentially confusing.
• The List view's built-in done = false filter silently combines with any user-entered filter (a done = true filter on List view will therefore always return nothing) — this is disclosed via a small note inside the Filters modal, but it's easy to miss (S18).
• The registration password policy (minimum 8 characters) is only communicated reactively, after a failed submission, rather than shown upfront near the password field (S3).
• Requesting another account's task directly (e.g. /tasks/1 as a non-owner) silently rewrites the URL back to / while rendering a 404 page, rather than keeping the requested URL with an explicit permission-denied message (S2). No content is leaked either way — this is a minor URL-consistency quirk, not a security issue.

What was covered: authentication and session handling (reload survival, protected-route enforcement, logout, Back-button safety); cross-account data isolation; the full task lifecycle (create, rename, complete/un-complete, delete); description and comment rich text, save feedback and persistence; due/start/end dates, reminders, and extreme dates; the complete labels lifecycle; Kanban buckets and drag-and-drop, including bucket limits and deletion; done-state consistency across Kanban/List/detail/open-task views; a single task's attributes across all four views (List, Table, Kanban, Gantt) plus Upcoming; public link sharing for a genuinely fresh unauthenticated visitor at two permission levels; teams and user-level sharing with permission enforcement; Gantt rendering, re-windowing, and genuine drag/resize interactions; the full project lifecycle (edit, duplicate, archive/un-archive, delete, Inbox protection); project-creation validation; Quick Add Magic across two configured modes; filters (single, combined, and malformed) on List and Table; sort and column toggles; the Upcoming view's presets, toggles, and clock dependence; saved filters and My Open Tasks scoping; genuine file-attachment upload/preview/delete; task relations and cross-project move; repeating-task rescheduling including invalid intervals; assignee assignment and membership boundaries; every general-settings preference; a full sweep of all twelve settings subpages; data export and import (including an invalid-file probe); invalid/empty/extreme input and script-injection handling on task fields; the search/quick-action bar and notifications; a console-error and broken-image sweep; and document-title/browser-history integrity across client-side navigation.

Deliberately out of scope, per the test plan:

• Account deletion was checked only to the affordance level — the "Delete your Vikunja Account" page was confirmed to exist and to demand a password before it can act, on the secondary account, but the deletion itself was never submitted.
• CalDAV, Atom feed, webhooks, and bot users were checked for reachability and that their configuration screens render real, working controls (a real CalDAV principal URL, a real Atom feed URL, working token/webhook/bot-creation forms) — actual delivery or sync to an external client was not exercised, since verifying that needs tooling outside the browser.
• Actual email delivery (password reset, export-ready notice, email-change confirmation) was not verified — this local instance has no mail server configured, so every verdict about these flows is based on the accuracy of the in-app status message alone, never on a real email arriving. This is also why W4 (no email verification on registration) is reported as a deployment characteristic rather than a defect.
• Two-factor authentication enrollment was confirmed to render a real, usable secret and QR code; the enrollment itself was deliberately not completed, to avoid risking a lockout on the test account.
• Load/performance testing, multi-browser matrices, and penetration testing beyond escaped-input rendering were out of scope per the intake, and were not attempted.

Partial coverage disclosed by the Tester (and flagged by the Critic) — not full verification:

• S29 (invalid/extreme task-field input): the 5000-character title, emoji/RTL title, 0%/100% progress extremes, and 20000-character description sub-checks were not exercised due to the run's time budget. The checks that were completed (empty/whitespace title rejection, script-injection escaping, clean date-clearing) passed.
• S30 (search/quick actions/notifications): the quick-action bar's "New task / New project / New team" creation shortcuts, and the cross-account notification-triggering checks (share a project → assign a task → comment, then check the second account's notifications), were not completed.
• S31 (console/broken-media sweep): the share modal, a saved-filter view, and several settings subpages were not re-probed programmatically for console errors or broken images, though they were visually inspected via screenshots elsewhere in the run with no visible breakage.
• S28 (data export): the export's retrievability was confirmed (a real download request returning HTTP 200), but the archive's byte-level contents — that it genuinely contains this run's projects, tasks, and labels — were not verified.

Methodology caveat — how to read several findings in this report: this run's browser-automation driver sometimes bulk-inserts text into an input field instead of typing it character by character. This app relies on real keystrokes to trigger several behaviours — debounced type-ahead search in comboboxes (label pickers, task-relation search, team-member search) and the rich-text editor's markdown auto-formatting — so bulk-inserted text can silently skip them. This produced three false findings in this run, all withdrawn above after the Critic reproduced the correct, working behaviour using real keystrokes: the S8 "labels always duplicate" claim (W2), the S6 "markdown never formats" claim (W3), and a stray duplicate task accidentally created during S23's relation-picker testing (noted here so it isn't mistaken for a data bug — the extra "Magic test task" record left in the account is a testing artifact, not evidence of anything broken). Separately, a number of buttons across the app (SAVE, MARK TASK DONE, CREATE A BUCKET, various delete icons) intermittently ignored a plain reference-based click during testing and needed a scripted click to register; in every case investigated this was confirmed to be a driver quirk — the control was on-screen, visible, and enabled the whole time — not the app failing to respond to a real mouse click.

Environment note: the Critic's own live re-verification work created and then deleted its own throwaway artifacts (two saved filters, a whitespace-titled project, two labels) and restored the renamed test project's title afterward. Two harmless residues remain in the instance from this process: one task still carries a start date later than its end date (deliberately left in place as live evidence for ISS-1), and a throwaway account, critic-dbl-probe, exists from re-testing the registration double-click race.

Report generated from .qa-output/20260812-142310/ — see plan.json for the full test plan, appmap.json for the exploration map, logs/S1.json–logs/S32.json for the raw per-scenario execution records, and critique.json for the full adversarial audit this report is bound by.