A campsite planning prototype that turns a trip idea into a shortlist, backup options, and an official-site handoff.
Built for campers who need a plan when their first-choice site is hard to find. The current interface calls that plan a CampCommand: define the trip, compare targets, prepare alternatives, and continue to Recreation.gov for booking.
Current local application, captured September 13, 2026. The prototype uses sample data; live availability and payment are not connected.
I define the product workflow, acceptance criteria, and review checkpoints, then use ChatGPT, Claude, and Codex to help implement and revise the application. My work connects product decisions with checks that another person can inspect:
- Preserve dates, party size, and campsite preferences across the planning flow.
- Give equivalent watch requests a consistent key while keeping different trips separate.
- Keep booking on the official site and make preview data visible to the user.
- Review generated changes against tests, rendered screens, and written requirements.
| Explore | What you will find |
|---|---|
| Product walkthrough | Actual screens and the planning sequence |
| Progress and next milestones | Implemented work, dated changes, remaining validation |
| One rule, executable evidence | Why reordering campsite selections must not create a different query |
| Verification record | What was checked, when, and the limits of each check |
| Architecture and public scope | How the full prototype is organized and what this repository contains |
This public edition contains selected source and executable tests. The complete web application remains in the development repository.
With Node.js 24 installed:
git clone https://github.com/notaa135/campalert.git
cd campalert
node --test test/*.test.mjsNo API keys, accounts, package installation, or network calls are needed to run the tests. The GitHub Actions workflow runs the same command.
Equivalent requests share an identity. Site order, repeated entries, casing, and blank entries are normalized before a watch key is built. Dates, party size, nights, provider, and site type remain part of the identity.
Preparation ends at a clear boundary. Search and watchlist screens lead to an official handoff. The prototype does not perform account login, checkout, or reservations for the user.
Evidence travels with the work. A nine-stage development loop connects a bounded task, planning, critique, implementation, review, automated checks, recorded results, and revision.
Independent project · working local prototype · fixture data. The application includes search, date-window previews, saved plans, and booking preparation. Live source validation, real notification delivery, billing activation, and user-outcome measurement remain future work.
Application stack: TypeScript, Next.js, React, Vitest, and Playwright. This repository isolates a small domain rule so its behavior is easy to inspect.
Created by Taeyoung Noh · DragonMagic