The Dogwalk story — from pet marketplace to CI/CD with 1456 tests
Dogwalk·

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.

~/lifelog — bash
$cat about.txt
╔══════════════════════════════════════╗
║  Samuel Medeiros                    ║
║  Senior Software Engineer           ║
║  Stack: Python · TypeScript · Rust  ║
║  Projetos: Arachne, Dogwalk,        ║
║            Capivara, TatuEngine      ║
╚══════════════════════════════════════╝
      
$