taurean.bryant.land / drydown
a a vibe-coded abomination experiment of a fragrance review platform built on the atmosphere. drydown.social
fork atom
drydown / docs / README.md
at main 6.0 kB view raw view code
taurean.bryant.land docs for LLM
0c501a11

Drydown Documentation#

Status: See status.md for current implementation progress

Quick Navigation#

For Feature Development#

For Technical Implementation#

For API Integration#

For Reference#

Documentation Conventions#

Status Indicators#

Each document uses these status indicators:

  • 🔴 Planned - Not started
  • 🟡 In Progress - Actively being worked on
  • 🟢 Implemented - Complete and tested
  • 🔵 Documented - Implemented with documentation

Cross-References#

Use relative links: [Link Text](../path/to/file.md#optional-anchor)

LLM Optimization#

This documentation is optimized for LLM consumption (Claude, Gemini, etc.):

Self-Contained Files: Each document includes necessary context at the top, so you don't need to read everything to understand a specific topic.

Status Tracking: Status indicators (🔴🟡🟢🔵) help quickly identify what's implemented vs planned.

Cross-References: Explicit linking helps navigate between related concepts. Each document includes a "Related Documents" section at the top.

Code Examples: Technical details include concrete code examples with real parameters, not just descriptions.

Decision Rationale: When documenting architectural choices, we explain "why" not just "what" - including alternatives considered and trade-offs.

Searchable Terminology: Consistent terminology throughout. See glossary.md for term definitions.

File Size: Individual files kept under 1000 lines. Longer topics split into sub-documents.

Project Overview#

Drydown is a fragrance review app built on AT Protocol / Bluesky that implements a unique three-stage rating system aligned with how fragrances develop over time:

  1. Stage 1 (Initial): Rate opening appeal, projection, and first impressions immediately
  2. Stage 2 (Heart): Rate heart notes after 2-4 hours when middle notes emerge
  3. Stage 3 (Final): Rate longevity, sillage, and complexity after 4+ hours

Users can customize rating weights, and the app calculates a final weighted score. Reviews can be shared directly to Bluesky with automatic formatting.

Technology Stack#

  • Frontend: Preact 10.27.2 + TypeScript 5.9.3 + Vite 7.2.4
  • Authentication: AT Protocol OAuth (@atproto/oauth-client-browser)
  • Data Storage: AT Protocol Personal Data Server (via @atproto/api)
  • Social: Bluesky feed posting

Current Status#

  • ✅ OAuth authentication working
  • ✅ Basic UI with login flow
  • 🔴 Review features (planned)
  • 🔴 Lexicon schemas (planned)
  • 🔴 Bluesky posting (planned)

See status.md for detailed progress tracking.

Evolution Strategy#

This documentation evolves as features are implemented:

  1. During Planning: All features start with 🔴 Planned status
  2. During Implementation: Update to 🟡 In Progress, add implementation notes
  3. After Completion: Update to 🟢 Implemented, document any deviations
  4. After Documentation: Update to 🔵 Documented with full details

The status.md file tracks overall progress and serves as a quick reference for what's done vs what's next.

Getting Started#

New to the project? Start here:

  1. Read Product Features to understand what we're building
  2. Review Architecture Overview for system design
  3. Check Implementation Roadmap for development phases
  4. See Existing Code for what's already built

Implementing a feature? Start here:

  1. Find the feature in Product Features
  2. Review related Data Models and Lexicon Schemas
  3. Check Component Structure for where it fits
  4. Follow the relevant Implementation Phase guide
  5. Update status.md as you progress

Working with AT Protocol? Start here:

  1. Review AT Protocol Repo for repository operations
  2. Check Lexicon Schemas for record structures
  3. See Existing Code for OAuth examples

Contributing to Documentation#

When updating documentation:

  • Update status indicators as features progress
  • Add implementation notes and learnings
  • Document deviations from the original plan
  • Keep status.md current
  • Use meaningful commit messages: docs: Add lexicon schema definitions

External Resources#