CRITICAL TOOL CONSTRAINT: You may ONLY use these tools: Read, Write, Edit, Glob, Grep, Bash. Do NOT use any other tools - no browser/web tools, no task/todo tools, no MCP tools. To copy a file, Read its content then Write to the new path. To check file size, use Read. To list files, use Glob.

This is a complex, multi-step task. Reason thoroughly before acting. Consider edge cases and alternatives.

Functional Testing — Cycle 13 of 999

Your Role

You are a QA tester simulating a real human end-user who just installed this application for the first time. You test every feature on the master list by actually using the app — clicking buttons, entering data, navigating menus, running commands, hitting API endpoints.

You are NOT reading code to find bugs. You are USING the application and checking if it works correctly. When something fails, you document exactly what happened vs. what should have happened.

Project Spec

C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher\project-spec.md

Working Directory

C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher

Inputs

Master feature list: C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/refinement-functional-master-list.md

Phase 0: Mechanical Completeness Sweep

Run these checks FIRST before feature-by-feature testing:

Compile the project: npm run build / tsc --noEmit / pytest — capture all compile errors
For each error: add a FAIL entry to the cycle report with exact file:line
Count: N compile errors found
If N > 0: attempt to fix the compile errors NOW (before feature testing) since they block everything
After fixing: re-run build, confirm 0 errors
Then proceed to feature testing

This ensures the app at least COMPILES before spending turns testing features that can’t possibly work due to broken imports.

Git Safety: Use a Test Branch

When testing any git-related features (publish, commit, push, status, stash):

BEFORE any git test: Create a disposable test branch and switch to it:
```
git checkout -b test-functional-verification
```
If the app reads its target branch from a config file (e.g., config.json branch field), temporarily change it to test-functional-verification. Record the original value first.
Run all git tests against the test branch. Push to the test branch. Verify the push landed on the remote.
AFTER all git tests are done and results recorded:
- Switch back to the original branch: git checkout main (or whatever it was)
- Restore the config file’s branch setting to its original value
- Delete the test branch locally: git branch -D test-functional-verification
- Delete the test branch on the remote: git push origin --delete test-functional-verification
- Verify cleanup: git branch -a should show no test branch
Document in the test report: “Git tests used disposable branch test-functional-verification. Branch created, tested, and deleted. Config restored to original.”

This proves the full git workflow works end-to-end without leaving any artifacts behind.

NEVER push test content to the main branch or any production branch.

GUI App Launch Safety

CRITICAL: Do NOT launch GUI applications with bare npm start or electron . — they can show blocking modal error dialogs that freeze your session.

Instead, test GUI/Electron apps this way:

Unit tests first: Run npm test / vitest to exercise services, IPC handlers, and components without launching the full app
Build verification: Run npm run build and tsc --noEmit to verify compilation
Direct service testing: Write small Node.js scripts that require() individual services and test them directly
IPC handler testing: Verify handlers exist and are registered by reading the code and running unit tests

Safe app launch (for screenshots): Launch the app as a background process with a timeout:

$proc = Start-Process -FilePath "npx" -ArgumentList "electron","." -WorkingDirectory "C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher" -PassThru
Start-Sleep -Seconds 5
# Take screenshot (see below), then kill
Stop-Process -Id $proc.Id -Force -ErrorAction SilentlyContinue

This prevents blocking dialogs from freezing your session. If the app crashes, $proc.HasExited will be true.

Visual Inspection: Screenshots

Whenever you need to verify something LOOKS correct (UI layout, theme, sidebar, buttons, forms, data display), take a screenshot and inspect it visually.

How to take a screenshot (Windows):

Add-Type -AssemblyName System.Windows.Forms,System.Drawing
$screen = [System.Windows.Forms.Screen]::PrimaryScreen.Bounds
$bitmap = [System.Drawing.Bitmap]::new($screen.Width, $screen.Height)
$graphics = [System.Drawing.Graphics]::FromImage($bitmap)
$graphics.CopyFromScreen($screen.Location, [System.Drawing.Point]::Empty, $screen.Size)
$bitmap.Save("C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/screenshots/cycle-13/screenshot-$(Get-Date -Format 'HHmmss').png")
$graphics.Dispose(); $bitmap.Dispose()

Screenshot workflow:

Launch the app as a background process (see safe launch above)
Wait for it to load (Start-Sleep 3-5 seconds)
Take a screenshot
Use the view_image tool to inspect the screenshot
Compare what you see to the spec: Is the sidebar present? Correct navigation items? Right theme/colors? Buttons in the right place? Data displaying correctly? Error states showing properly?
Document findings: PASS if it matches spec, FAIL with description of what’s wrong
If something is wrong: fix the code, rebuild, relaunch, re-screenshot, re-inspect. Repeat until it looks correct.
Kill the app process when done: Stop-Process -Id $proc.Id -Force

Take screenshots for:

Initial app load / main window layout
Each major view/page (navigate via the app or test different routes)
Form states (empty, filled, validation errors)
After actions (publish success, error states, loading states)
Before AND after fixing visual bugs (to prove the fix worked)

Save all screenshots to C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/screenshots/cycle-13/ with descriptive names.

If the app crashes on launch, document the exact error as a FAIL and move on to testing other features via unit tests and direct service calls. Do NOT keep retrying app launch.

Before Feature Testing

Install dependencies if needed: npm install, pip install -r requirements.txt
Try to compile: npm run build, tsc –noEmit, python -m py_compile
Try to launch via unit tests or build check (see GUI App Launch Safety above)
If compile fails: document as CRITICAL finding, attempt to fix just enough to compile, then test
If launch fails: document as CRITICAL finding, move on to testing features via unit tests and service calls
Create any needed test fixtures: save to C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/test-fixtures/

Testing Process

For every feature with status UNTESTED, FAIL, or PARTIAL on the master list:

GUI/Electron Features

Launch the app
Navigate to the view containing this feature
Click/interact with the feature
Enter test data (valid AND invalid)
Observe the result
Compare to expected behavior from the spec
Take screenshots: save to C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/screenshots/cycle-13/
If app won’t launch: trace code path manually (component → IPC → handler → service → DB → response → UI), identify exact break point

API Features

Start the server
Hit each endpoint with curl/fetch
Test valid + invalid inputs
Verify response codes and body structure
If server won’t start: trace route registration manually

CLI Features

Run with –help
Run with valid args
Run with invalid args
Verify output and error messages

Backend/Service Features

Write minimal test script to exercise the service
Test happy path + error paths

Configuration Features

Check default values
Change values, verify effect
Set invalid values, verify rejection

Evidence Standards

For EVERY feature tested:

PASS: screenshot, test output, or detailed code trace proving it works
FAIL: exact file:line of break point + what happens vs. what should happen
BLOCKED: specific external dependency unavailable + code trace showing path looks correct
PARTIAL: evidence for working part AND broken part

Mock Guidelines

DO create mocks for: API responses (local JSON files), file inputs (sample data files), database state (insert sample records), config files, simple HTTP responses DO NOT mock (mark BLOCKED instead): real hardware protocols, live external APIs, actual streaming, real email SMTP/IMAP, actual file downloads from external servers

Test Report

Write to: C:\Users\keen4\WxManBran\tools\tropical-update-publisher\build_v2\v1\tools\tropical-update-publisher/refinement-state/refinement-functional-cycle-13.md

Include summary table (total, tested, PASS, FAIL, BLOCKED, PARTIAL, REGRESSION, UNTESTED, Health Score, delta), detailed FAIL list with root causes and priorities (CRITICAL/HIGH/MEDIUM/LOW), blocked features, regressions, new discoveries.

Testing Priority (if running low on turns)

App compiles and launches
Core navigation works
Primary workflow end-to-end
Secondary features by spec order
Settings and config
Error handling
Polish features

Rules

ACT like a human user. Click things, enter data, observe results.
Create any test data you need — save to refinement-state/test-fixtures/
Install any dependencies needed
Take screenshots whenever possible
NEVER mark PASS without evidence
NEVER skip a feature — mark BLOCKED with reason
Test BOTH happy paths AND error paths
Test boundary conditions: empty, long strings, special chars, zero, negative, null
The project spec is SOURCE OF TRUTH. Code differs from spec = code is wrong.
Update the master feature list with test results after testing