test: wire desktop and utils coverage into turbo

[svperior-jon]

Summary

• add a desktop test script so existing Vitest coverage participates in the root Turbo pnpm test pipeline
• add the first @cap/utils Vitest suite covering shared helper behavior for class merging, UUID formatting, progress math, and signup email restrictions
• add the matching utils Vitest dev dependency and lockfile importer entry

/claim #54

AI-assisted with Codex; I reviewed the diff and kept the change scoped to test infrastructure and example tests.

Verification

• pnpm install --frozen-lockfile
• pnpm turbo run test --filter=@cap/desktop --filter=@cap/utils
• pnpm exec biome check apps/desktop/package.json packages/utils/package.json packages/utils/src/helpers.test.ts

Greptile Summary

This PR wires existing Vitest coverage in @cap/desktop into the root Turbo test pipeline and adds the first @cap/utils test suite covering class merging, UUID round-trips, progress circle geometry, display-progress selection, and email restriction logic.

• apps/desktop/package.json gains a generic \"test\": \"vitest run\" script; the package already had vitest and a config, so the 4 existing src/utils/*.test.ts files and the memory-soak unit tests will all participate correctly.
• packages/utils/package.json adds \"test\": \"vitest run\" and vitest ~2.1.9 as a devDependency; the new helpers.test.ts covers 7 exported functions with assertions that match the implementation, though the uploadProgress = 0 edge case of getDisplayProgress is not exercised.

Confidence Score: 4/5

Safe to merge; changes are limited to test infrastructure and a new test file with no production code modifications.

All production code is untouched. The new tests are correct against the implementation. The only gaps are a missing edge-case assertion for getDisplayProgress(0, n) and the absence of an explicit vitest.config.ts in @cap/utils, both of which are non-blocking quality observations.

No files require special attention; packages/utils/src/helpers.test.ts has a minor coverage gap worth a quick look.

Important Files Changed

Filename	Overview
packages/utils/src/helpers.test.ts	New test file covering 7 helpers; all assertions match the implementation, but the getDisplayProgress(0, n) edge case is untested and has non-obvious semantics.
packages/utils/package.json	Adds test script and vitest ~2.1.9 devDependency; no vitest.config.ts is present, so the package runs with defaults.
apps/desktop/package.json	Adds generic test script wired to vitest run; vitest and config already existed, and existing unit tests will be picked up correctly.
pnpm-lock.yaml	Adds lockfile importer entry for vitest ~2.1.9 in packages/utils, resolving to the same version already used by desktop — consistent.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/utils/src/helpers.test.ts:35-38
The `getDisplayProgress` test skips the `uploadProgress = 0` case. Because the implementation checks `uploadProgress !== undefined`, passing `0` returns `0` and never falls back to `processingProgress`. This is a non-obvious semantic boundary worth pinning so a future change to `=== undefined` vs. a falsy check doesn't silently regress.

```suggestion
	it("prefers upload progress over processing progress", () => {
		expect(getDisplayProgress(42, 10)).toBe(42);
		expect(getDisplayProgress(undefined, 64)).toBe(64);
		// uploadProgress=0 is defined, so processing progress is NOT used
		expect(getDisplayProgress(0, 64)).toBe(0);
	});
```

### Issue 2 of 2
packages/utils/package.json:10
`@cap/utils` has no `vitest.config.ts`. Vitest will default to Node environment and the standard `**/*.test.*` glob, which works for the current pure-function tests. As the package grows (or if path aliases from `tsconfig` are needed), the absence of an explicit config may cause friction. Consider adding a minimal config now to make the test environment intentional.

_{Reviews (1): Last reviewed commit: "test: wire desktop and utils coverage in..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[superagent-security]

Brin PR Security Scan

This PR has findings that should be reviewed.

• Score: 46/100
• Verdict: suspicious

Findings:

• first_time_contributor: svperior-jon has no prior commits to CapSoftware/Cap.

_{Analyzed by Brin}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	typescript@​5.8.3

View full report

[greptile-apps]

The getDisplayProgress test skips the uploadProgress = 0 case. Because the implementation checks uploadProgress !== undefined, passing 0 returns 0 and never falls back to processingProgress. This is a non-obvious semantic boundary worth pinning so a future change to === undefined vs. a falsy check doesn't silently regress.

Suggested change

	it("prefers upload progress over processing progress", () => {
	expect(getDisplayProgress(42, 10)).toBe(42);
	expect(getDisplayProgress(undefined, 64)).toBe(64);
	});
	it("prefers upload progress over processing progress", () => {
	expect(getDisplayProgress(42, 10)).toBe(42);
	expect(getDisplayProgress(undefined, 64)).toBe(64);
	// uploadProgress=0 is defined, so processing progress is NOT used
	expect(getDisplayProgress(0, 64)).toBe(0);
	});

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/utils/src/helpers.test.ts
Line: 35-38

Comment:
The `getDisplayProgress` test skips the `uploadProgress = 0` case. Because the implementation checks `uploadProgress !== undefined`, passing `0` returns `0` and never falls back to `processingProgress`. This is a non-obvious semantic boundary worth pinning so a future change to `=== undefined` vs. a falsy check doesn't silently regress.

```suggestion
	it("prefers upload progress over processing progress", () => {
		expect(getDisplayProgress(42, 10)).toBe(42);
		expect(getDisplayProgress(undefined, 64)).toBe(64);
		// uploadProgress=0 is defined, so processing progress is NOT used
		expect(getDisplayProgress(0, 64)).toBe(0);
	});
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

@cap/utils has no vitest.config.ts. Vitest will default to Node environment and the standard **/*.test.* glob, which works for the current pure-function tests. As the package grows (or if path aliases from tsconfig are needed), the absence of an explicit config may cause friction. Consider adding a minimal config now to make the test environment intentional.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/utils/package.json
Line: 10

Comment:
`@cap/utils` has no `vitest.config.ts`. Vitest will default to Node environment and the standard `**/*.test.*` glob, which works for the current pure-function tests. As the package grows (or if path aliases from `tsconfig` are needed), the absence of an explicit config may cause friction. Consider adding a minimal config now to make the test environment intentional.

How can I resolve this? If you propose a fix, please make it concise.