quart-httpauth 0.0.1__tar.gz

quart_httpauth-0.0.1/.claude/rules/ci.md

@@ -0,0 +1,29 @@
+# CI/CD Rules
+
+---
+
+## 1. Coverage
+
+### 1.1 Coverage Reporting
+- Publish coverage reports to Codecov using the GitHub codecov-action.
+
+---
+
+## 2. Pipeline Design
+
+### 2.1 Automation
+- Automate all test runs with a CI pipeline.
+
+### 2.2 Modular Jobs
+- CI configurations must be modular and split into three jobs:
+  - fast tests;
+  - deep tests;
+  - code style checks.
+
+---
+
+## 3. Local Execution
+
+### 3.1 Local Reproducibility
+- All jobs must be executable locally using the act CLI tool:
+  https://github.com/nektos/act

quart_httpauth-0.0.1/.claude/rules/testing.md

@@ -0,0 +1,136 @@
+# Testing Rules
+
+---
+
+## 1. Test Design
+
+### 1.1 Logic-Free Tests
+- Unit tests must be logic-free: they must not implement any algorithms.
+- Aim for one-statement tests.
+
+### 1.2 Assertions
+- Each test must contain exactly one assertion.
+- Each test must contain at least one assertion.
+- The last statement in every test must be an assertion.
+- Do not assert on the absence of failure.
+- Never assert on side effects.
+- Be creative with assertions.
+- Use the PyHamcrest library to achieve this.
+
+### 1.3 Test Inputs
+- Whenever possible, tests should use irregular, boundary, or strange inputs to provoke hidden issues.
+- Every test must use its own literals, numbers, and input values.
+- Do not reuse inputs across tests, as this may falsely suggest shared meaning.
+- Always write descriptive failure messages.
+
+### 1.4 Test Isolation
+- Test methods must share absolutely no fixtures with other test methods.
+
+---
+
+## 2. Naming and Documentation
+
+### 2.1 Test Naming
+- Test names must be complete English phrases that would start with "it" if written fully. Example: (it) builds_empty_png_image
+- "it" refers to the object under test, not the test itself.
+
+### 2.2 Documentation
+- Tests must not contain documentation comments.
+
+---
+
+## 3. Scope and Boundaries
+
+### 3.1 What to Test
+- Never write tests for private or protected methods.
+- Avoid overtesting.
+- Tests must never be the reason for expanding an object's public interface.
+- Avoid testing abstract classes directly.
+
+### 3.2 Feature Class Correspondence
+- Each feature class must have exactly one corresponding test module.
+- Feature classes should trust each other and only guard against invalid end-user input.
+
+---
+
+## 4. Resources and Cleanup
+
+### 4.1 System Resources
+- Tests must close all system resources when they finish.
+- Tests that require resources must begin with cleanup.
+
+### 4.2 File Handling
+- If a test works with files, it must create its own temporary directory and store all files there.
+- Do not mock the file system.
+- Place all temporary files inside a top-level tmp/ directory in the repository.
+
+---
+
+## 5. Fakes and Logging
+
+### 5.1 Fakes Over Mocks
+- Do not use mocks. Use fake implementations instead.
+
+### 5.2 Logging
+- Logging should be disabled during tests whenever possible.
+- If logging is part of the specification, test it using fake classes that capture messages instead of printing them.
+
+---
+
+## 6. Test Patterns
+
+### 6.1 Parametrized Tests
+- If multiple inputs share the same scenario, use parametrized tests.
+
+### 6.2 Thread Safety
+- If a class uses threads or claims thread safety, there must be tests confirming its thread safety.
+
+### 6.3 Flaky Tests
+- Use pytest-repeat to run flaky tests multiple times when needed.
+
+### 6.4 Online Tests
+- Mark all tests requiring internet access with: pytest.mark.online
+
+---
+
+## 7. Test-Driven Development
+
+### 7.1 Bug Fixes
+- Before fixing a bug, reproduce it with a failing test case.
+
+### 7.2 New Features
+- Before adding a new feature, there must be a failing test first.
+
+---
+
+## 8. Test Execution
+
+### 8.1 Performance
+- Use pytest-fail-slow to automatically fail tests that run too slowly.
+
+### 8.2 Randomization
+- Execute tests in random order and print the randomization seed to the console.
+
+---
+
+## 9. Test Categories
+
+### 9.1 Fast Tests (Unit)
+- Minimal execution time.
+
+### 9.2 Deep Tests (Integration)
+- Realistic live scenarios.
+- If deep tests require external dependencies (databases, remote services, etc.), use Testcontainers.
+
+---
+
+## 10. Quality Tools
+
+### 10.1 Grammar Checking
+- Use language-tool-python to check English grammar in string literals and exception messages.
+
+### 10.2 Property-Based Testing
+- Use Python Hypothesis for property-based testing.
+
+### 10.3 Mutation Testing
+- Use mutmut for mutation testing.

quart_httpauth-0.0.1/.claude/rules/workflow.md

@@ -0,0 +1,54 @@
+# Agent Workflow Orchestration
+
+## 1. Workflow Orchestration
+
+### 1.1 General Rules
+- Enter **plan mode** for ANY non-trivial task (3+ steps or architectural decisions)
+- If something goes sideways, STOP and re-plan immediately – don't keep pushing
+- Use plan mode for verification steps, not just building
+- Write detailed specs upfront to reduce ambiguity
+- Never mark a task complete without proving it works
+
+### 1.2 Subagent Strategy
+- Use subagents liberally to keep main context window clean
+- Offload research, exploration, and parallel analysis to subagents
+- For complex problems, throw more compute at it via subagents
+- One tack per subagent for focused execution
+
+### 1.3 Self-Improvement Loop
+- After ANY correction from the user: update `./specs/lessons.md` with the pattern
+- Write rules for yourself that prevent the same mistake
+- Ruthlessly iterate on these lessons until mistake rate drops
+- Review lessons at session start for relevant project
+
+### 1.4 Verification Before Done
+- Never mark a task complete without proving it works
+- Diff behavior between main and your changes when relevant
+- Ask yourself: "Would a staff engineer approve this?"
+- Run tests, check logs, demonstrate correctness
+
+### 1.5 Demand Elegance (Balanced)
+- For non-trivial changes: pause and ask "is there a more elegant way?"
+- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
+- Skip this for simple, obvious fixes – don't over-engineer
+- Challenge your own work before presenting it
+
+### 1.6 Autonomous Bug Fixing
+- When given a bug report: just fix it. Don't ask for hand-holding
+- Point at logs, errors, failing tests – then resolve them
+- Zero context switching required from the user
+- Go fix failing CI tests without being told how
+
+## 2. Task Management
+
+1. **Plan First**: Write plan to `./specs/todo.md` with checkable items
+2. **Verify Plan**: Check in before starting implementation
+3. **Track Progress**: Mark items complete as you go
+4. **Explain Changes**: High-level summary at each step
+5. **Document Results**: Add review section to `./specs/todo.md`
+
+## 3. Core Principles
+
+- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
+- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
+- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

quart_httpauth-0.0.1/.claude/settings.json

@@ -0,0 +1,5 @@
+{
+  "env": {
+    "CLAUDE_CODE_USE_POWERSHELL_TOOL": "0"
+  }
+}

quart_httpauth-0.0.1/.claude/skills/pr-review-expert/SKILL.md

@@ -0,0 +1,384 @@
+---
+name: "pr-review-expert"
+description: "Use when the user asks to review pull requests, analyze code changes, check for security issues in PRs, or assess code quality of diffs."
+---
+
+# PR Review Expert
+
+**Tier:** POWERFUL
+**Category:** Engineering
+**Domain:** Code Review / Quality Assurance
+
+---
+
+## Overview
+
+Structured, systematic code review for GitHub PRs and GitLab MRs. Goes beyond style nits — this skill
+performs blast radius analysis, security scanning, breaking change detection, and test coverage delta
+calculation. Produces a reviewer-ready report with a 30+ item checklist and prioritized findings.
+
+---
+
+## Core Capabilities
+
+- **Blast radius analysis** — trace which files, services, and downstream consumers could break
+- **Security scan** — SQL injection, XSS, auth bypass, secret exposure, dependency vulns
+- **Test coverage delta** — new code vs new tests ratio
+- **Breaking change detection** — API contracts, DB schema migrations, config keys
+- **Ticket linking** — verify Jira/Linear ticket exists and matches scope
+- **Performance impact** — N+1 queries, bundle size regression, memory allocations
+
+---
+
+## When to Use
+
+- Before merging any PR/MR that touches shared libraries, APIs, or DB schema
+- When a PR is large (>200 lines changed) and needs structured review
+- Onboarding new contributors whose PRs need thorough feedback
+- Security-sensitive code paths (auth, payments, PII handling)
+- After an incident — review similar PRs proactively
+
+---
+
+## Fetching the Diff
+
+### GitHub (gh CLI)
+```bash
+# View diff in terminal
+gh pr diff <PR_NUMBER>
+
+# Get PR metadata (title, body, labels, linked issues)
+gh pr view <PR_NUMBER> --json title,body,labels,assignees,milestone
+
+# List files changed
+gh pr diff <PR_NUMBER> --name-only
+
+# Check CI status
+gh pr checks <PR_NUMBER>
+
+# Download diff to file for analysis
+gh pr diff <PR_NUMBER> > /tmp/pr-<PR_NUMBER>.diff
+```
+
+### GitLab (glab CLI)
+```bash
+# View MR diff
+glab mr diff <MR_IID>
+
+# MR details as JSON
+glab mr view <MR_IID> --output json
+
+# List changed files
+glab mr diff <MR_IID> --name-only
+
+# Download diff
+glab mr diff <MR_IID> > /tmp/mr-<MR_IID>.diff
+```
+
+---
+
+## Workflow
+
+### Step 1 — Fetch Context
+
+```bash
+PR=123
+gh pr view $PR --json title,body,labels,milestone,assignees | jq .
+gh pr diff $PR --name-only
+gh pr diff $PR > /tmp/pr-$PR.diff
+```
+
+### Step 2 — Blast Radius Analysis
+
+For each changed file, identify:
+
+1. **Direct dependents** — who imports this file?
+```bash
+# Find all files importing a changed module
+grep -r "from ['\"].*changed-module['\"]" src/ --include="*.ts" -l
+grep -r "require(['\"].*changed-module" src/ --include="*.js" -l
+
+# Python
+grep -r "from changed_module import\|import changed_module" . --include="*.py" -l
+```
+
+2. **Service boundaries** — does this change cross a service?
+```bash
+# Check if changed files span multiple services (monorepo)
+gh pr diff $PR --name-only | cut -d/ -f1-2 | sort -u
+```
+
+3. **Shared contracts** — types, interfaces, schemas
+```bash
+gh pr diff $PR --name-only | grep -E "types/|interfaces/|schemas/|models/"
+```
+
+**Blast radius severity:**
+- CRITICAL — shared library, DB model, auth middleware, API contract
+- HIGH     — service used by >3 others, shared config, env vars
+- MEDIUM   — single service internal change, utility function
+- LOW      — UI component, test file, docs
+
+### Step 3 — Security Scan
+
+```bash
+DIFF=/tmp/pr-$PR.diff
+
+# SQL Injection — raw query string interpolation
+grep -n "query\|execute\|raw(" $DIFF | grep -E '\$\{|f"|%s|format\('
+
+# Hardcoded secrets
+grep -nE "(password|secret|api_key|token|private_key)\s*=\s*['\"][^'\"]{8,}" $DIFF
+
+# AWS key pattern
+grep -nE "AKIA[0-9A-Z]{16}" $DIFF
+
+# JWT secret in code
+grep -nE "jwt\.sign\(.*['\"][^'\"]{20,}['\"]" $DIFF
+
+# XSS vectors
+grep -n "dangerouslySetInnerHTML\|innerHTML\s*=" $DIFF
+
+# Auth bypass patterns
+grep -n "bypass\|skip.*auth\|noauth\|TODO.*auth" $DIFF
+
+# Insecure hash algorithms
+grep -nE "md5\(|sha1\(|createHash\(['\"]md5|createHash\(['\"]sha1" $DIFF
+
+# eval / exec
+grep -nE "\beval\(|\bexec\(|\bsubprocess\.call\(" $DIFF
+
+# Prototype pollution
+grep -n "__proto__\|constructor\[" $DIFF
+
+# Path traversal risk
+grep -nE "path\.join\(.*req\.|readFile\(.*req\." $DIFF
+```
+
+### Step 4 — Test Coverage Delta
+
+```bash
+# Count source vs test files changed
+CHANGED_SRC=$(gh pr diff $PR --name-only | grep -vE "\.test\.|\.spec\.|__tests__")
+CHANGED_TESTS=$(gh pr diff $PR --name-only | grep -E "\.test\.|\.spec\.|__tests__")
+
+echo "Source files changed: $(echo "$CHANGED_SRC" | wc -w)"
+echo "Test files changed:   $(echo "$CHANGED_TESTS" | wc -w)"
+
+# Lines of new logic vs new test lines
+LOGIC_LINES=$(grep "^+" /tmp/pr-$PR.diff | grep -v "^+++" | wc -l)
+echo "New lines added: $LOGIC_LINES"
+
+# Run coverage locally
+npm test -- --coverage --changedSince=main 2>/dev/null | tail -20
+pytest --cov --cov-report=term-missing 2>/dev/null | tail -20
+```
+
+**Coverage delta rules:**
+- New function without tests → flag
+- Deleted tests without deleted code → flag
+- Coverage drop >5% → block merge
+- Auth/payments paths → require 100% coverage
+
+### Step 5 — Breaking Change Detection
+
+#### API Contract Changes
+```bash
+# OpenAPI/Swagger spec changes
+grep -n "openapi\|swagger" /tmp/pr-$PR.diff | head -20
+
+# REST route removals or renames
+grep "^-" /tmp/pr-$PR.diff | grep -E "router\.(get|post|put|delete|patch)\("
+
+# GraphQL schema removals
+grep "^-" /tmp/pr-$PR.diff | grep -E "^-\s*(type |field |Query |Mutation )"
+
+# TypeScript interface removals
+grep "^-" /tmp/pr-$PR.diff | grep -E "^-\s*(export\s+)?(interface|type) "
+```
+
+#### DB Schema Changes
+```bash
+# Migration files added
+gh pr diff $PR --name-only | grep -E "migrations?/|alembic/|knex/"
+
+# Destructive operations
+grep -E "DROP TABLE|DROP COLUMN|ALTER.*NOT NULL|TRUNCATE" /tmp/pr-$PR.diff
+
+# Index removals (perf regression risk)
+grep "DROP INDEX\|remove_index" /tmp/pr-$PR.diff
+```
+
+#### Config / Env Var Changes
+```bash
+# New env vars referenced in code (might be missing in prod)
+grep "^+" /tmp/pr-$PR.diff | grep -oE "process\.env\.[A-Z_]+" | sort -u
+
+# Removed env vars (could break running instances)
+grep "^-" /tmp/pr-$PR.diff | grep -oE "process\.env\.[A-Z_]+" | sort -u
+```
+
+### Step 6 — Performance Impact
+
+```bash
+# N+1 query patterns (DB calls inside loops)
+grep -n "\.find\|\.findOne\|\.query\|db\." /tmp/pr-$PR.diff | grep "^+" | head -20
+# Then check surrounding context for forEach/map/for loops
+
+# Heavy new dependencies
+grep "^+" /tmp/pr-$PR.diff | grep -E '"[a-z@].*":\s*"[0-9^~]' | head -20
+
+# Unbounded loops
+grep -n "while (true\|while(true" /tmp/pr-$PR.diff | grep "^+"
+
+# Missing await (accidentally sequential promises)
+grep -n "await.*await" /tmp/pr-$PR.diff | grep "^+" | head -10
+
+# Large in-memory allocations
+grep -n "new Array([0-9]\{4,\}\|Buffer\.alloc" /tmp/pr-$PR.diff | grep "^+"
+```
+
+---
+
+## Ticket Linking Verification
+
+```bash
+# Extract ticket references from PR body
+gh pr view $PR --json body | jq -r '.body' | \
+  grep -oE "(PROJ-[0-9]+|[A-Z]+-[0-9]+|https://linear\.app/[^)\"]+)" | sort -u
+
+# Verify Jira ticket exists (requires JIRA_API_TOKEN)
+TICKET="PROJ-123"
+curl -s -u "user@company.com:$JIRA_API_TOKEN" \
+  "https://your-org.atlassian.net/rest/api/3/issue/$TICKET" | \
+  jq '{key, summary: .fields.summary, status: .fields.status.name}'
+
+# Linear ticket
+LINEAR_ID="abc-123"
+curl -s -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  --data "{\"query\": \"{ issue(id: \\\"$LINEAR_ID\\\") { title state { name } } }\"}" \
+  https://api.linear.app/graphql | jq .
+```
+
+---
+
+## Complete Review Checklist (30+ Items)
+
+```markdown
+## Code Review Checklist
+
+### Scope & Context
+- [ ] PR title accurately describes the change
+- [ ] PR description explains WHY, not just WHAT
+- [ ] Linked Jira/Linear ticket exists and matches scope
+- [ ] No unrelated changes (scope creep)
+- [ ] Breaking changes documented in PR body
+
+### Blast Radius
+- [ ] Identified all files importing changed modules
+- [ ] Cross-service dependencies checked
+- [ ] Shared types/interfaces/schemas reviewed for breakage
+- [ ] New env vars documented in .env.example
+- [ ] DB migrations are reversible (have down() / rollback)
+
+### Security
+- [ ] No hardcoded secrets or API keys
+- [ ] SQL queries use parameterized inputs (no string interpolation)
+- [ ] User inputs validated/sanitized before use
+- [ ] Auth/authorization checks on all new endpoints
+- [ ] No XSS vectors (innerHTML, dangerouslySetInnerHTML)
+- [ ] New dependencies checked for known CVEs
+- [ ] No sensitive data in logs (PII, tokens, passwords)
+- [ ] File uploads validated (type, size, content-type)
+- [ ] CORS configured correctly for new endpoints
+
+### Testing
+- [ ] New public functions have unit tests
+- [ ] Edge cases covered (empty, null, max values)
+- [ ] Error paths tested (not just happy path)
+- [ ] Integration tests for API endpoint changes
+- [ ] No tests deleted without clear reason
+- [ ] Test names clearly describe what they verify
+
+### Breaking Changes
+- [ ] No API endpoints removed without deprecation notice
+- [ ] No required fields added to existing API responses
+- [ ] No DB columns removed without two-phase migration plan
+- [ ] No env vars removed that may be set in production
+- [ ] Backward-compatible for external API consumers
+
+### Performance
+- [ ] No N+1 query patterns introduced
+- [ ] DB indexes added for new query patterns
+- [ ] No unbounded loops on potentially large datasets
+- [ ] No heavy new dependencies without justification
+- [ ] Async operations correctly awaited
+- [ ] Caching considered for expensive repeated operations
+
+### Code Quality
+- [ ] No dead code or unused imports
+- [ ] Error handling present (no bare empty catch blocks)
+- [ ] Consistent with existing patterns and conventions
+- [ ] Complex logic has explanatory comments
+- [ ] No unresolved TODOs (or tracked in ticket)
+```
+
+---
+
+## Output Format
+
+Structure your review comment as:
+
+```
+## PR Review: [PR Title] (#NUMBER)
+
+Blast Radius: HIGH — changes lib/auth used by 5 services
+Security: 1 finding (medium severity)
+Tests: Coverage delta +2%
+Breaking Changes: None detected
+
+--- MUST FIX (Blocking) ---
+
+1. SQL Injection risk in src/db/users.ts:42
+   Raw string interpolation in WHERE clause.
+   Fix: db.query("SELECT * WHERE id = $1", [userId])
+
+--- SHOULD FIX (Non-blocking) ---
+
+2. Missing auth check on POST /api/admin/reset
+   No role verification before destructive operation.
+
+--- SUGGESTIONS ---
+
+3. N+1 pattern in src/services/reports.ts:88
+   findUser() called inside results.map() — batch with findManyUsers(ids)
+
+--- LOOKS GOOD ---
+- Test coverage for new auth flow is thorough
+- DB migration has proper down() rollback method
+- Error handling consistent with rest of codebase
+```
+
+---
+
+## Common Pitfalls
+
+- **Reviewing style over substance** — let the linter handle style; focus on logic, security, correctness
+- **Missing blast radius** — a 5-line change in a shared utility can break 20 services
+- **Approving untested happy paths** — always verify error paths have coverage
+- **Ignoring migration risk** — NOT NULL additions need a default or two-phase migration
+- **Indirect secret exposure** — secrets in error messages/logs, not just hardcoded values
+- **Skipping large PRs** — if a PR is too large to review properly, request it be split
+
+---
+
+## Best Practices
+
+1. Read the linked ticket before looking at code — context prevents false positives
+2. Check CI status before reviewing — don't review code that fails to build
+3. Prioritize blast radius and security over style
+4. Reproduce locally for non-trivial auth or performance changes
+5. Label each comment clearly: "nit:", "must:", "question:", "suggestion:"
+6. Batch all comments in one review round — don't trickle feedback
+7. Acknowledge good patterns, not just problems — specific praise improves culture

quart_httpauth-0.0.1/.claude/skills/test-runner/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: "test-runner"
+description: "Use this skill when application code has been modified (*.py)"
+---
+
+# Test Runner
+
+**Tier:** POWERFUL
+**Category:** Testing
+**Domain:** Unit Testing / Quality Assurance
+
+---
+
+## Overview
+
+This skill provides steps on how to run tests and linters after application code has been changed.
+It shows how unit tests run process is organized in project and how properly work with test results.
+
+---
+
+## When to use
+
+- New application code has been introduced (*.py)
+- Application code has been changed (*.py)
+
+---
+
+## How to run tests
+
+To run unit tests:
+```bash
+make unit
+```
+To run e2e tests:
+```bash
+make e2e
+```
+
+## How to run linters:
+
+To run black:
+```bash
+make black
+```
+To run flake8:
+```bash
+make flake8
+```
+To run ruff:
+```bash
+make ruff
+```
+
+---
+
+## Important rules
+
+- Test coverage should be >= 90.
+- If test coverage is not enough, you should write additional tests to achieve desired state.
+- If linters fail and provide changes to implement, then those changes should be implemented.

quart_httpauth-0.0.1/.github/workflows/deep-tests.yml

@@ -0,0 +1,25 @@
+name: Deep tests
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  deep-tests:
+    name: Deep tests (integration)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install dependencies
+        run: make install
+
+      - name: Run deep tests
+        run: make test-deep