Commit efcbe31

@@ -1,7 +1,6 @@
 ---
 authors: Bryon <bryon@fryer.io>
-state: discussion
-discussion: https://github.com/knight-work/rfd/pull/1
+state: pre-discussion
 labels: process
 ---
 

@@ -1,82 +1,161 @@
 ---
 authors: Bryon <bryon@fryer.io>
 state: pre-discussion
-labels: business, product, affiliate, email
+labels: process, collaboration, workflow
 ---
 
-# RFC 002: buylater.email – An Email Based Delayed Gratification Shopping System
+# Pair Programming Workflow
+
+## Overview
+This document outlines our pair programming workflow for building this project. It ensures consistent process, proper testing, and knowledge capture as we work through the project plan.
+
+## Workflow Process
+
+### 1. Task Selection & Planning
+**Claude's Actions:**
+- Pick up the next **Pending** task from the `project_plan` markdown file
+- Review the task's acceptance criteria and testing requirements
+- Create a brief implementation plan (2-3 bullet points)
+- **Confirm plan with human before proceeding**
+
+### 2. Implementation Preparation
+**Claude's Actions:**
+- After brief plan is approved by human, create a comprehensive implementation plan
+- Build a detailed todo list for the task implementation using TodoWrite tool
+- Review `CLAUDE.md` for project-specific commands and architecture notes
+- Update todo list to mark task as "in_progress"
+- Read any relevant existing files to understand current state
+
+### 3. Implementation
+**Claude's Actions:**
+- Implement the task following acceptance criteria
+- Write clean, well-structured code following established patterns
+- Use proper error handling where needed
+
+### 4. Testing & Verification
+**Claude's Actions:**
+- Run specified tests from the task (unit/integration/manual)
+- Execute build commands to verify no compilation errors
+- Run any other relevant commands (linting, type checking, etc.)
+
+### 5. Human Verification Request
+**Claude's Actions:**
+- Summarize what was implemented
+- List what should be visible/testable in the app
+- **Provide specific testing steps for the human**
+- **Prompt human to verify in running app**
+
+**Required format:**
+> "## Task X.Y Implementation Complete!
+> 
+> **Changes made:**
+> - [Bulleted list of key changes]
+> 
+> **Please verify in the app:**
+> - [Specific steps to test the functionality]
+> - [Expected behavior/output]
+> 
+> **Expected results:**
+> - [What should happen if working correctly]
+> - [Any specific UI changes to look for]
+> 
+> **Ready for your verification!**"
+
+### 6. Human Testing & Feedback
+**Human's Actions:**
+- Test the changes in the running app 
+- Verify acceptance criteria are met
+- Provide feedback: "Perfect! That worked!" or describe issues
+
+**If Issues Found:**
+- Human describes what went wrong or what's not working
+- Claude investigates and fixes the issues
+- Return to step 4 (Testing & Verification) after fixes
+- Repeat until verification succeeds
+
+### 7. Task Completion
+**Claude's Actions (after human confirms success):**
+- Mark task as **Completed** in the `project_plan` markdown file
+- Update todo list to completed
+- Update progress tracking in the `project_plan` markdown file
+- Update technical_considerations.md with lessons learned
+
+## Documentation Updates
+
+### During Each Task
+**Claude should update these files as needed:**
+
+#### CLAUDE.md Updates
+- Add new commands discovered during implementation
+- Update architecture notes if patterns change
+- Document any new dependencies or tools
+- Note any gotchas or important considerations
+
+#### RFD Updates
+In the appropriate RFD document:
+- Document technical decisions and rationale
+- Record issues encountered and solutions
+- Note what works well and what to avoid
+- Capture performance considerations
+- Document testing strategies that work
+If a new RFD topic is appropriate:
+- Follow the RFD purpose and procedures in RFD 001
+- Document what new topic requires a new discussion
+- Propose an RFD with the next RFD number
+
+## Quality Checks
+
+### Before Marking task Complete
+- [ ] All acceptance criteria met
+- [ ] All specified tests pass
+- [ ] No new console errors or warnings  
+- [ ] Code follows project conventions
+- [ ] Relevant documentation updated
+- [ ] Human verification completed
+
+### Code Quality Standards
+- Handle errors gracefully
+- Write clear, self-documenting code
+- Keep functions small and focused
+
+## Communication Patterns
+
+### Starting a task
+Claude: "Ready for Task X.Y: [Title]. My plan: [brief plan]. Does this approach sound good?"
+
+### During Implementation
+Claude: [Work silently through implementation, testing, and verification]
+
+### Requesting Verification
+Claude: "Task X.Y implementation complete! Changes: [summary]. Please verify: [specific things to check]. Ready for your verification!"
+
+### After Human Confirmation
+Claude: "Great! Marking Task X.Y as completed. Moving to next task..."
+
+## Emergency Procedures
+
+### If Task Becomes Too Complex
+- Break it down into smaller sub-tasks
+- Document the breakdown in the appropriate RFD document
+- Get human approval for the new approach
+
+### If Architecture Changes Needed
+- Document the change rationale in the appropriate RFD document
+- Get human approval before major changes
+
+### If Stuck on Technical Issue
+- Document the issue in in the appropriate RFD document
+- Propose 2-3 alternative approaches
+- Ask human for guidance
+
+## Success Metrics
+- Tasks completed per session
+- Build success rate (should be 100%)
+- Quality of human verification feedback
+- Documentation completeness
+- Knowledge capture effectiveness
 
-## Summary
-
-`buylater.email` is a minimalist, privacy-first email service that delays gratification by letting users schedule product reminder emails for a future date. Users submit a link and their email address, and we send them a timed reminder with affiliate and add-to-cart links, no passwords, no upsells, no tracking.
-
-The service is monetized purely via affiliate commissions and designed to be transparent, consumer-centric, and willpower-enhancing.
-
-## Motivation
-
-Modern e-commerce is designed to encourage impulse buying. Many people struggle with overconsumption, addictive habits, or simply want to buy less and buy better. Tools that claim to support intentional spending are often tied to tracking, upsells, or hidden agendas. We want to offer a clean, honest alternative.
-
-We believe there is power in *not buying now*. We want to create a simple, no-nonsense, repeatable behavior: “Email this to me next month and if I still want it, I’ll buy it.”
-
-By restoring friction to the buying process, we help people make purchases on their own terms.
-
-## Goals
-
-- Let users submit any product URL and schedule a future email reminder.
-- Embed affiliate links and add-to-cart links in the email.
-- Operate on a minimal infrastructure with minimal user data retention.
-- Reach profitability at a minimal scale (1,000 users/month).
-- Stay focused on simplicity: no passwords, no app, no fluff.
-
-## Non-Goals
-
-- We will not track user behavior outside of what is strictly necessary.
-- We will not up-sell or advertise to our users.
-- We will not sell user data to a third-party.
-
-## Detailed Proposal
-
-### User Flow
-
-1. User visits `buylater.email`.
-2. User pastes a product link and enters their email.
-3. User selects a delay time (e.g., “3 days,” “2 weeks,” or “custom date”).
-4. A confirmation email is sent (to validate ownership and prevent spam).
-5. After confirmation, the service schedules a scheduled email to be sent after the specified delay.
-6. The final email includes:
-   - The original product title and image (fetched at submission).
-   - Affiliate-tagged product link.
-   - Optional “Add to Cart” link for convenience.
-
-### Monetization
-
-- Affiliate program:
-  - Every link in the final email uses a hardcoded affiliate tag.
-  - If a user purchases within the session, a small commission is earned.
-- No upsells, ads, or user data sales.
-
-### UX Philosophy
-
-- Extremely lightweight and fast.
-- No signups or logins.
-- Accessible and mobile-friendly.
-- Encourages mindful spending by intentionally *not* helping users buy faster.
-
-## Alternatives Considered
-
-| Option | Description | Reason Not Chosen |
-|--------|-------------|-------------------|
-| Full wishlist manager | Save/delete items, track price history | Too much overhead and feature creep |
-| Browser extension | Monitor tabs or pages visits | Breaks privacy-first principle, adds complexity |
-| App store product | Native app experience | Increases friction, requires ongoing updates and support |
-| Ads | Monetize with display ads | Conflicts with no-BS user promise |
+---
 
-## Risks & Mitigation
+This workflow ensures we maintain quality, capture knowledge, and make steady progress toward our goals.
 
-| Risk | Severity | Mitigation |
-|------|----------|------------|
-| Email deliverability issues | High | Use warm sender domain and reputable provider (Postmark, SES w/ dedicated IP) |
-| Abuse (spam input) | Medium | Use double opt-in and rate limiting |
-| Affiliate link breakage | Low | Use direct product URLs with embedded affiliate tags |
-| Low commission revenue | Medium | Optimize CTA placement, consider other affiliate programs only if ethical alignment maintained |
-| Amazon policy changes | Medium | Maintain compliance with Amazon Associates terms; minimize reliance on scraping or deprecated APIs |

@@ -0,0 +1,82 @@
+---
+authors: Bryon <bryon@fryer.io>
+state: pre-discussion
+labels: business, product, affiliate, email
+---
+
+# buylater.email – An Email Based Delayed Gratification Shopping System
+
+## Summary
+
+`buylater.email` is a minimalist, privacy-first email service that delays gratification by letting users schedule product reminder emails for a future date. Users submit a link and their email address, and we send them a timed reminder with affiliate and add-to-cart links, no passwords, no upsells, no tracking.
+
+The service is monetized purely via affiliate commissions and designed to be transparent, consumer-centric, and willpower-enhancing.
+
+## Motivation
+
+Modern e-commerce is designed to encourage impulse buying. Many people struggle with overconsumption, addictive habits, or simply want to buy less and buy better. Tools that claim to support intentional spending are often tied to tracking, upsells, or hidden agendas. We want to offer a clean, honest alternative.
+
+We believe there is power in *not buying now*. We want to create a simple, no-nonsense, repeatable behavior: “Email this to me next month and if I still want it, I’ll buy it.”
+
+By restoring friction to the buying process, we help people make purchases on their own terms.
+
+## Goals
+
+- Let users submit any product URL and schedule a future email reminder.
+- Embed affiliate links and add-to-cart links in the email.
+- Operate on a minimal infrastructure with minimal user data retention.
+- Reach profitability at a minimal scale (1,000 users/month).
+- Stay focused on simplicity: no passwords, no app, no fluff.
+
+## Non-Goals
+
+- We will not track user behavior outside of what is strictly necessary.
+- We will not up-sell or advertise to our users.
+- We will not sell user data to a third-party.
+
+## Detailed Proposal
+
+### User Flow
+
+1. User visits `buylater.email`.
+2. User pastes a product link and enters their email.
+3. User selects a delay time (e.g., “3 days,” “2 weeks,” or “custom date”).
+4. A confirmation email is sent (to validate ownership and prevent spam).
+5. After confirmation, the service schedules a scheduled email to be sent after the specified delay.
+6. The final email includes:
+   - The original product title and image (fetched at submission).
+   - Affiliate-tagged product link.
+   - Optional “Add to Cart” link for convenience.
+
+### Monetization
+
+- Affiliate program:
+  - Every link in the final email uses a hardcoded affiliate tag.
+  - If a user purchases within the session, a small commission is earned.
+- No upsells, ads, or user data sales.
+
+### UX Philosophy
+
+- Extremely lightweight and fast.
+- No signups or logins.
+- Accessible and mobile-friendly.
+- Encourages mindful spending by intentionally *not* helping users buy faster.
+
+## Alternatives Considered
+
+| Option | Description | Reason Not Chosen |
+|--------|-------------|-------------------|
+| Full wishlist manager | Save/delete items, track price history | Too much overhead and feature creep |
+| Browser extension | Monitor tabs or pages visits | Breaks privacy-first principle, adds complexity |
+| App store product | Native app experience | Increases friction, requires ongoing updates and support |
+| Ads | Monetize with display ads | Conflicts with no-BS user promise |
+
+## Risks & Mitigation
+
+| Risk | Severity | Mitigation |
+|------|----------|------------|
+| Email deliverability issues | High | Use warm sender domain and reputable provider (Postmark, SES w/ dedicated IP) |
+| Abuse (spam input) | Medium | Use double opt-in and rate limiting |
+| Affiliate link breakage | Low | Use direct product URLs with embedded affiliate tags |
+| Low commission revenue | Medium | Optimize CTA placement, consider other affiliate programs only if ethical alignment maintained |
+| Amazon policy changes | Medium | Maintain compliance with Amazon Associates terms; minimize reliance on scraping or deprecated APIs |

@@ -0,0 +1,93 @@
+authors: Bryon <bryon@fryer.io>
+state: pre-discussion
+labels: language-choice, golang, engineering
+date: 2025-07-20
+
+# Choosing Golang as the Primary Language
+
+## Summary
+
+This RFD proposes adopting Go (Golang) as the primary implementation language for our backend and systems-level development. Go offers simplicity, performance, strong concurrency primitives, and a thriving ecosystem that aligns well with our goals for maintainability, reliability, and developer productivity.
+
+## Motivation
+
+We need a language that:
+
+- Produces reliable, fast binaries  
+- Has a low barrier to entry for new contributors  
+- Encourages maintainable and readable code  
+- Supports concurrency with minimal cognitive overhead  
+- Has excellent tooling and ecosystem support  
+- Offers a strong standard library for networking, file I/O, and HTTP  
+
+## Requirements
+
+The primary language should:
+
+1. Be simple to learn and onboard new developers  
+2. Support high-concurrency and networked systems efficiently  
+3. Provide cross-platform compilation with minimal setup  
+4. Have a strong ecosystem of open source libraries and tooling  
+5. Be used widely in production by companies operating at scale  
+6. Offer first-class support for testing and static analysis  
+7. Enable fast iteration and deployment without lengthy build chains  
+
+## Evaluation
+
+| Language | Simple Syntax | Concurrency | Ecosystem | Binary Output | Tooling | Adoption |
+|----------|---------------|-------------|-----------|---------------|---------|----------|
+| **Go**   | ✅             | ✅ Goroutines, Channels | ✅ Robust, Standardized | ✅ Single binary | ✅ `go fmt`, `go test`, `go vet`, `gopls` | ✅ Google, Uber, Cloudflare, etc. |
+| Rust     | ❌ Complex     | ✅ `tokio`, `async/await` | ✅ Strong        | ✅      | ✅ Excellent, but heavy | ✅ Dropbox, AWS, Meta |
+| Python   | ✅             | ❌ GIL limits concurrency | ✅ Rich         | ❌ Needs interpreter | ✅ Excellent | ✅ Google, Instagram |
+| Node.js  | ✅             | ✅ Event-loop model | ✅ Large but fragmented | ❌ Requires runtime | ✅ Good, npm-heavy | ✅ Vercel, Netflix |
+| Java     | ❌ Verbose     | ✅ Threads, Loom (preview) | ✅ Mature        | ✅ JVM-based | ✅ Heavyweight | ✅ Everywhere |
+
+## Benefits of Go
+
+- **Simplicity**: Go has a small surface area; developers can become productive quickly.  
+- **Concurrency**: Goroutines and channels provide a clean abstraction over threads and async code.  
+- **Tooling**: The Go toolchain is self-contained and includes built-in formatting, testing, vetting, and documentation tools.  
+- **Deployment**: Statically linked binaries make deployment trivial and reduce runtime surprises.  
+- **Community**: Large, vibrant open-source community with active development and library support.  
+- **Performance**: Close to C-level performance with minimal optimization effort.  
+
+## Risks and Tradeoffs
+
+- **Runtime GC**: Garbage collection introduces non-deterministic pauses, though this is usually negligible.  
+- **No exceptions**: Go prefers explicit error handling; this is stylistically different from some other languages.  
+- **Not as low-level as Rust or C**: Go is not designed for systems programming requiring strict control over memory layout.  
+
+## Alternatives Considered
+
+- **Rust**: Excellent for performance and safety, but significantly higher complexity and slower iteration time.  
+- **Python**: Excellent for scripting and data tasks but lacks performance and concurrency for backend systems.  
+- **JavaScript/Node.js**: Good for fast prototyping but less suited for long-lived backend services with heavy concurrency.  
+
+## Recommendation
+
+Adopt Go as the primary language for:
+
+- Backend services  
+- Network proxies, schedulers, or agents  
+- Internal tooling  
+- CLIs and infrastructure automation  
+
+## Project Fit: `buylater.email`
+
+The `buylater.email` project is a strong match for Go, due to its focus on minimalism, privacy, and deterministic backend behavior. The core architectural needs include:
+
+- Stateless HTTP endpoints for link submission, confirmation, and unsubscribe  
+- Scheduled email delivery without persistent infrastructure 
+- Secure, tokenized URLs for one-click interactions  
+- Transparent, inspectable code that can run on cheap VPS or on-prem  
+
+Go is particularly well suited here because:
+
+- It supports **zero-dependency deployments** — one static binary does it all  
+- It includes **robust native libraries** for `net/http`, `crypto`, `html/template`, `context`, and `time`  
+- Its **concurrency model** is ideal for building timed job schedulers and retry queues  
+- Go makes it easy to **avoid shelling out** — all logic can live safely in a single process  
+- **Low cold start time** and **predictable memory usage** enable frictionless hosting
+
+We also expect the project to scale to serve thousands of scheduled reminders per day, a throughput well within Go’s sweet spot for low-latency I/O and CPU-light tasks.
+

@@ -0,0 +1,6 @@
+# RFDs
+
+- 001 [Requests for Discussion](001/README.md)
+- 002 [Pair Programming Workflow](002/README.md)
+- 003 [buylater.email - An Email Based Delayed Gratification Shopping System](003/README.md)
+- 004 [Primary Language: Golang](004/README.md)