sherpa-portal

README

No README.

STATUS

---
type: project-status
project: sherpa-portal
last_updated: 2026-04-27
---

# STATUS — sherpa-portal

*The freshest file. Answers "where am I on this project?" Updated at the end of every substantive session.*

---

## Current state

<One short paragraph: what state is the project in right now? Mid-build? Shipped MVP? Stalled waiting on something? Be concrete.>

## In progress

- [ ] <What's actively being worked on. If nothing, write "Nothing in flight.">

## Next up

1. <The next thing to pick up when work resumes.>
2. <The thing after that, if obvious.>

## Blocked / waiting on

<External dependencies, decisions you need from someone, vendor responses, etc. "Nothing blocking" is a fine answer.>

## Known issues

<Bugs you know about but haven't fixed, edge cases not yet handled, debt you've taken on. Be specific so future-you doesn't get blindsided.>

## Recent wins

- 2026-04-27: <What was completed in the last session or two. Concrete, with dates.>

## Last session recap

*2026-04-27* — <One paragraph: what got done, what was learned, anything surprising. Read this first when picking up the project after a break.>

DECISIONS

---
type: project-decisions
project: sherpa-portal
last_updated: 2026-04-27
---

# DECISIONS — sherpa-portal

*Architectural and scope choices. Append-only log. Each entry is a decision that shouldn't be re-litigated without new information. If you find yourself reopening a decision, either add a new entry that overrides the old (and say why) or leave both so the history is visible.*

---

## How to use this file

Each decision gets a dated entry with: what was decided, why, what was considered instead, and what would change our mind. Never delete entries — if a decision is reversed, add a new one that supersedes it.

---

## 2026-04-27 — <Short decision title>

**Decision:** <what we chose>

**Context:** <the problem or question that forced a choice>

**Alternatives considered:** <what else was on the table and why we passed>

**Reasoning:** <why this option won>

**Would reconsider if:** <what new information would flip this>

---

## 2026-04-27 — <Short decision title>

**Decision:**

**Context:**

**Alternatives considered:**

**Reasoning:**

**Would reconsider if:**

---

<!-- Append new entries at the top. Older decisions remain below. -->

MEMORY

---
type: project-memory
project: sherpa-portal
last_updated: 2026-04-27
---

# MEMORY — sherpa-portal

*Standing facts, preferences, and accumulated context. Long-lived — not "what I did yesterday" (that's STATUS.md). Update when you learn something worth keeping.*

---

## Purpose and scope

<Why this app exists, who uses it, what problem it solves. 2-3 sentences max.>

## Domain knowledge

<Rules of the domain that Claude should know before making changes. For tax apps: the specific IRS rules this module implements, state conformity notes, edge cases. For non-tax apps: business rules, workflows, naming conventions specific to this app's world.>

## User preferences discovered

<Things Ken has said he prefers, or patterns that work / don't work. Example: "Ken prefers server-rendered HTML over SPAs for internal tools." "Don't auto-format tax return numbers with commas on input, only on display.">

## Integrations and external systems

<APIs, webhooks, third-party services this app talks to. Auth patterns, rate limits, quirks.>

## Gotchas and lessons learned

<The things that have bitten us. Non-obvious behavior, debugging dead-ends, environment quirks. Write these when they happen so the next session doesn't repeat the mistake.>

## Data model highlights

<Key tables/models and what's non-obvious about them. Don't duplicate the schema — reference it. Focus on the things you'd warn someone about.>

CLAUDE.md

# CLAUDE.md — Sherpa Portal

## What This Is
Client-facing portal for tax practices. Clients log in via magic link to check
return status, upload documents, download completed returns, and message their
preparer. Shares the same Supabase Postgres database as tts-tax-app.

## Tech Stack
- Django 5.2 LTS, Python 3.12+
- Server-rendered HTML templates (no SPA)
- Tailwind CSS (CDN in dev)
- Supabase Postgres (shared with tts-tax-app)
- Supabase Storage (S3-compatible, django-storages + boto3)
- WhiteNoise for static files (prod)
- Poetry for dependencies

## Project Structure
```
config/settings/{base,dev,prod}.py   # Split settings
apps/shared/models.py                # managed=False models (tax app tables)
apps/portal_auth/                    # Auth: magic links, sessions, middleware
apps/dashboard/                      # Home page: status cards, tax years
apps/documents/                      # File upload/download, doc requests
apps/messages/                       # Secure client-firm messaging
templates/portal/                    # All HTML templates
```

## Running Locally
```bash
cd D:\dev\sherpa-portal
poetry install
python manage.py runserver 8006
# Dev login (no magic link needed): http://127.0.0.1:8006/auth/dev-login/
```

## Testing
```bash
poetry run pytest
```
Tests go in `tests/` folder. Name files `test_{module}.py`.

## Database
- Portal-owned tables all use `portal_` prefix
- Shared tables (firms_firm, clients_client, etc.) are managed=False — never migrate them from this project
- All portal models use UUID primary keys

## Memory File Locations
After every session, save memory.md to BOTH locations:
1. `D:\dev\sherpa-portal\memory\memory.md`
2. `G:\My Drive\sherpa-memory\sherpa-portal\memory.md`
Always update both copies. They must stay in sync.

## Key Conventions
- Auth is session-based via PortalUser (not Django's built-in User)
- Every query must filter by firm_id + portal_user to enforce row isolation
- Use `@portal_login_required` decorator on al

…(truncated for upload size)

Diary mentions

No recent diary mentions for this app.