
The Dogwalk story — from pet marketplace to CI/CD with 1456 tests
The app that couldn’t break on deploy
Every project has a moment when you realize: you can’t keep deploying on hope. For Dogwalk, that moment came twice — first when the build broke because of an npm-cli.js without execute permission, and then when 1456 tests became the bar for any change.
But Dogwalk wasn’t born that way. It was born as a pet marketplace that needed to prove it worked.
Context — from zero to marketplace
The first commit was on April 24, 2026:
73a610f5 DogWalk/PataPass: clean initial commit
The idea was simple: connect pet owners to walkers. The owner schedules a walk, a walker accepts, and both follow the walk in real time with GPS. The stack: React 19 + Vite on the front, FastAPI + PostgreSQL on the back, Stripe Connect for payments, and Cloudflare Pages for deploy.
The catch: “simple” is never simple when it involves real-time GPS, geofencing, payments, and two user types (tutor and walker).
The struggle — when the build broke on WSL
The most memorable saga was the WSL build break. The which npm on Samuel’s environment resolved to the Windows npm (/mnt/c/Program Files/nodejs/npm) instead of the Hermes node npm. And CMD.EXE with a UNC path broke everything:
Cannot find module 'C:\Windows\scripts\verify-csp.cjs'
The root cause: the Hermes node npm-cli.js had no execute permission (-rw-------). The fix was surgical:
chmod +x ~/.local/share/npm/bin/npm-cli.js
But the bigger lesson came from there: deploy can’t depend on a specific environment. That’s when the project gained manual deploy scripts and local CI — so the platform could still ship when GitHub Actions was offline.
In parallel came the visual reformulation: the role-aware UniversalHeader (different navigation for Tutor vs Walker), the DesktopSidebar with Tailwind v4, and the refactor of TutorDashboard (464 → 298 lines) and WalkerDashboard (807 → 409 lines). All following a DESIGN.md created with the Open Design pattern — CSS tokens, role themes, and a component gallery in components.html.
Resolution — 1456 tests as the bar
The turning point was test week. Five giant components gained real coverage:
| Component | Lines | Tests | Coverage |
|---|---|---|---|
| Domain skeletons | 614 | 22 | 100% |
| WalkerRequests | 633 | 17 | 88% |
| Scheduling | 687 | 5 | 70% |
| ActiveWalkInterface | 874 | 10 | 56% |
| MetricsDashboard | 724 | 5 | 44% |
And Scheduling was optimized with useCallback/useMemo — 7 memoized handlers, 5 derived values.
The result: 1456/1456 tests passing, 93 files, 100% clean build — and the confidence that any change that broke something would be caught before deploy.
Metrics
| Metric | 24/04 (birth) | 31/07 (today) |
|---|---|---|
| Commits | 1 | 970 |
| Tests | 0 | 1456 (93 files) |
| Top-5 coverage | — | 44–100% |
| Stack | idea | React 19 + FastAPI + PG |
| Deploy | — | Cloudflare Pages CI/CD |
Takeaways
Dogwalk taught that quality isn’t a feature — it’s an architecture decision. After breaking the WSL build because of a file without permission, the project gained: local + remote CI, manual deploy scripts, and a test suite that prevents regression.
And Open Design proved that a design system isn’t a luxury: when WalkerDashboard was refactored with tokens and documented components, it lost 48% of its lines without losing a single feature.