# Loose Ends: build prompts and product notes

Working app: `/planner/`  
Readable process notes: `/planner/process.html`

## The assignment

> Build a web app or AI agent to solve a problem you, a friend, or a family member has. Share your prompts and a link to the working web app or agent, to the extent possible. Record an approximately 5-minute video showing your approach, what you learned, how you iterated, and demo the working web app or agent. Limit your time spent building to a few hours.

## Prompt 1: define and build the smallest useful product

```text
Build a standalone web app for people who struggle to turn a messy friend-group chat into an actual plan.

Let someone paste messages written as “Name: message.” Identify who is participating, what days were mentioned, who is available or unavailable, any relevant time restrictions, practical constraints, and the best tentative plan.

Show the unresolved questions and write one friendly message the organizer can send back to the group. Include realistic examples, make it work on mobile, and keep the project small enough to finish in a few hours.
```

Result: a single-page planner with a pasted conversation, three realistic examples, an availability breakdown, a recommended day and time, practical constraints, unanswered questions, and a ready-to-copy draft.

## Prompt 2: fix misleading certainty

```text
Improve the planner so it never presents a guess as confirmed. Treat “maybe,” “if,” and “should work” as tentative. If someone replies “I’m in” without naming the day, keep that response contextual and explicitly ask for confirmation.

Detect direct conflicts, conflicting before/after times, budgets, dietary requirements, accessibility, dog-friendly spaces, childcare, weather, and reservations. Explain missing details rather than inventing a venue, availability, or agreed start time.
```

Result: responses have explicit states—confirmed, tentative, unavailable, or unanswered. Context-only replies remain tentative, and the recommendation calls itself a proposal rather than a confirmed booking.

## Prompt 3: make the product private, accessible, and verifiable

```text
Keep every conversation in the current browser tab. Use a transparent rules-based parser instead of an external AI call. Do not store messages, send requests, load tracking, or claim the app is AI-powered.

Render pasted names and messages as plain text, add a restrictive content-security policy, support keyboard and screen-reader users, respect reduced-motion preferences, and test representative conversations plus ambiguous replies, relative dates, explicit conflicts, malformed input, and malicious-looking markup.
```

Result: no account, API key, backend request, analytics, cookies, browser storage, external dependencies, or hidden AI call. A content-security policy blocks outbound connections. Dynamic content is inserted with DOM text APIs rather than interpreted as HTML.

## Architecture

- `index.html`: accessible app shell and restrictive content-security policy.
- `styles.css`: responsive, dependency-free styling for the app and process page.
- `analysis.js`: deterministic conversation parsing, evidence extraction, ranking, and message drafting.
- `app.js`: safe DOM rendering and browser interactions.
- `analysis.test.mjs`: regression tests using Node’s built-in test runner.
- `process.html`: shareable, human-readable design and iteration notes.

Run the regression suite:

```sh
node --test planner/analysis.test.mjs
```

## Five-minute walkthrough

1. Explain the everyday problem: group-chat replies do not add up to an actual plan.
2. Show the first build prompt and the intentionally narrow one-screen scope.
3. Demonstrate the dinner example and the ready-to-send message.
4. Switch to the dog-friendly weekend or birthday example and point out conflicts, uncertainty, budget, and constraints.
5. Explain the iteration: “I’m in” without a named day is not a confirmed response.
6. Discuss the browser-only privacy decision, automated tests, limitations, and a possible opt-in AI mode later.