feat: add sponsor seed data fixture (#323) #327

Merged

forgejo_admin merged 1 commit from 323-sponsor-seed-data into main

2026-04-04 02:25:54 +00:00

forgejo_admin commented

2026-04-03 23:56:23 +00:00

Owner

Summary

Adds a JSON seed data fixture containing 44 sponsor entries sourced from Marcus's contact list. Each entry has business_name, email, and category fields.

Changes

data/sponsors_seed.json — new file with 44 sponsor objects across 7 categories (financial, food, retail, automotive, construction, fitness, dental)

Test Plan

python3 -c "import json; d=json.load(open('data/sponsors_seed.json')); print(f'{len(d)} sponsors loaded')" returns 44 sponsors loaded
Verify no duplicate emails, no TBD/placeholder entries
Spot-check category assignments match business type

Review Checklist

JSON is valid and parseable
44 entries confirmed
No TBD or placeholder emails
Separate entries per unique email (Raising Cane's x3, US Bank x2, Zions Bank x2)
Categories match issue spec

None.

Closes #323

## Summary Adds a JSON seed data fixture containing 44 sponsor entries sourced from Marcus's contact list. Each entry has business_name, email, and category fields. ## Changes - `data/sponsors_seed.json` — new file with 44 sponsor objects across 7 categories (financial, food, retail, automotive, construction, fitness, dental) ## Test Plan - `python3 -c "import json; d=json.load(open('data/sponsors_seed.json')); print(f'{len(d)} sponsors loaded')"` returns `44 sponsors loaded` - Verify no duplicate emails, no TBD/placeholder entries - Spot-check category assignments match business type ## Review Checklist - [x] JSON is valid and parseable - [x] 44 entries confirmed - [x] No TBD or placeholder emails - [x] Separate entries per unique email (Raising Cane's x3, US Bank x2, Zions Bank x2) - [x] Categories match issue spec ## Related Notes None. ## Related Closes #323

forgejo_admin added 1 commit

2026-04-03 23:56:23 +00:00

feat: add sponsor seed data fixture (#323 )

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

1b71dd6d0f

JSON array of 44 sponsor entries with business_name, email, and category.
Categories: financial, food, retail, automotive, construction, fitness, dental.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

forgejo_admin commented

2026-04-03 23:59:20 +00:00

Author

Owner

PR #327 Review — QA Agent

DOMAIN REVIEW

Tech stack: Data-only (JSON seed file). No Python/FastAPI code changes. Review focuses on data correctness against issue #323 acceptance criteria.

Entry count: 44 entries. Matches source data breakdown: financial(6) + food(21) + retail(1) + automotive(5) + construction(4) + fitness(2) + dental(5) = 44. PASS

Schema: Every entry has exactly three fields: business_name, email, category. No missing or extra fields. PASS

Valid JSON: Proper JSON array, no trailing commas, no syntax issues. Parseable by json.load(). PASS

Duplicate emails: All 44 email addresses are unique. Raising Cane's correctly has 3 separate entries for 3 distinct email addresses (community@, marketing@, info@raisingcanes.com), matching the "one entry per unique email" constraint. PASS

Category validation: All categories used (financial, food, retail, automotive, construction, fitness, dental) are from the allowed set in the issue spec. No invalid categories. PASS

No placeholders: No TBD, unknown, or placeholder email addresses. All businesses without emails from Marcus were correctly omitted. PASS

BLOCKERS

None. Data-only PR — no executable code, so standard code blockers (test coverage, input validation, secrets, DRY) do not apply.

NITS

"The Joint Chiropractic" categorized as fitness: A chiropractic clinic is arguably more "health" than "fitness." The allowed categories include other. Non-blocking — verify against Marcus's original categorization intent.
Sorting: Entries are grouped by category (good for readability). Within categories, order follows Marcus's listing rather than alphabetical. Just an observation.

SOP COMPLIANCE

Branch named after issue (323-sponsor-seed-data)
PR body has Closes #323
PR body follows template (Summary, Changes, Test Plan, Review Checklist)
No secrets committed
No scope creep (single file, exactly matching issue scope)

VERDICT: APPROVED

Data file matches all acceptance criteria from issue #323: correct count (44), correct schema, no duplicates, valid JSON, correct categories, no placeholder entries. No blockers.

## PR #327 Review — QA Agent ### DOMAIN REVIEW **Tech stack**: Data-only (JSON seed file). No Python/FastAPI code changes. Review focuses on data correctness against issue #323 acceptance criteria. **Entry count**: 44 entries. Matches source data breakdown: financial(6) + food(21) + retail(1) + automotive(5) + construction(4) + fitness(2) + dental(5) = 44. **PASS** **Schema**: Every entry has exactly three fields: `business_name`, `email`, `category`. No missing or extra fields. **PASS** **Valid JSON**: Proper JSON array, no trailing commas, no syntax issues. Parseable by `json.load()`. **PASS** **Duplicate emails**: All 44 email addresses are unique. Raising Cane's correctly has 3 separate entries for 3 distinct email addresses (`community@`, `marketing@`, `info@raisingcanes.com`), matching the "one entry per unique email" constraint. **PASS** **Category validation**: All categories used (financial, food, retail, automotive, construction, fitness, dental) are from the allowed set in the issue spec. No invalid categories. **PASS** **No placeholders**: No TBD, unknown, or placeholder email addresses. All businesses without emails from Marcus were correctly omitted. **PASS** ### BLOCKERS None. Data-only PR — no executable code, so standard code blockers (test coverage, input validation, secrets, DRY) do not apply. ### NITS 1. **"The Joint Chiropractic" categorized as `fitness`**: A chiropractic clinic is arguably more "health" than "fitness." The allowed categories include `other`. Non-blocking — verify against Marcus's original categorization intent. 2. **Sorting**: Entries are grouped by category (good for readability). Within categories, order follows Marcus's listing rather than alphabetical. Just an observation. ### SOP COMPLIANCE - [x] Branch named after issue (`323-sponsor-seed-data`) - [x] PR body has `Closes #323` - [x] PR body follows template (Summary, Changes, Test Plan, Review Checklist) - [x] No secrets committed - [x] No scope creep (single file, exactly matching issue scope) ### VERDICT: APPROVED Data file matches all acceptance criteria from issue #323: correct count (44), correct schema, no duplicates, valid JSON, correct categories, no placeholder entries. No blockers.

forgejo_admin commented

2026-04-04 02:24:58 +00:00

Author

Owner

PR #327 Review

DOMAIN REVIEW

Stack: Static JSON data fixture (no Python/FastAPI code in this PR).

This PR adds a single file data/sponsors_seed.json containing 44 sponsor entries. Each entry has three fields: business_name, email, category. The data/ directory is new to this repo -- no prior fixtures exist.

Data quality audit (manual verification from diff):

44 entries confirmed across 7 categories: financial (6), food (21), retail (1), automotive (5), construction (4), fitness (2), dental (5)
All 44 emails are unique (verified: US Bank x2 different emails, Zions Bank x2 different emails, Raising Cane's x3 different emails)
No TBD/placeholder values detected
Category assignments are reasonable (tire shops = automotive, banks = financial, restaurants = food, etc.)
JSON structure is consistent -- every object has the same three keys

Observation: "The Joint Chiropractic" is categorized as "fitness" -- arguable whether chiropractic is fitness or health/medical, but this is a judgment call, not a bug.

BLOCKERS

None.

This is a static data fixture with no executable code, no user input handling, no auth logic, and no secrets. The BLOCKER criteria (test coverage for new functionality, unvalidated user input, secrets in code, DRY violations in auth paths) do not apply to a passive JSON file.

The "no test coverage" blocker does not apply here -- this is seed data, not functionality. The consuming code (PR #328 -- Sponsor model + CRUD) is where test coverage will be evaluated.

NITS

No JSON schema validation: There is no JSON Schema or Pydantic model in this PR to enforce the {business_name, email, category} shape. The consuming PR (#328) should define the expected schema. Not a blocker for this PR since the data file is inert until loaded.
Category enum not defined here: The 7 category values (financial, food, retail, automotive, construction, fitness, dental) should be enforced as an enum in the consuming model. Just a note for the #328 review.

SOP COMPLIANCE

Branch named after issue: 323-sponsor-seed-data follows {issue-number}-{kebab-case-purpose}
PR body has Summary, Changes, Test Plan, Related sections
Related references plan slug: No plan slug -- PR body says "None" for Related Notes. Acceptable since this was called out as no plan slug in the review request.
No secrets committed -- emails are public business contact addresses, not credentials
No scope creep -- single file, exactly what the issue describes

PROCESS OBSERVATIONS

Low change failure risk: static data file with no runtime behavior.
This is the first of a multi-PR chain (seed data -> model+CRUD -> email template -> blast endpoint). The chain is well-decomposed with each PR doing one thing.
Deployment frequency: no deployment impact until the consuming code lands.

VERDICT: APPROVED

## PR #327 Review ### DOMAIN REVIEW **Stack**: Static JSON data fixture (no Python/FastAPI code in this PR). This PR adds a single file `data/sponsors_seed.json` containing 44 sponsor entries. Each entry has three fields: `business_name`, `email`, `category`. The `data/` directory is new to this repo -- no prior fixtures exist. **Data quality audit** (manual verification from diff): - 44 entries confirmed across 7 categories: financial (6), food (21), retail (1), automotive (5), construction (4), fitness (2), dental (5) - All 44 emails are unique (verified: US Bank x2 different emails, Zions Bank x2 different emails, Raising Cane's x3 different emails) - No TBD/placeholder values detected - Category assignments are reasonable (tire shops = automotive, banks = financial, restaurants = food, etc.) - JSON structure is consistent -- every object has the same three keys **Observation**: "The Joint Chiropractic" is categorized as "fitness" -- arguable whether chiropractic is fitness or health/medical, but this is a judgment call, not a bug. ### BLOCKERS None. This is a static data fixture with no executable code, no user input handling, no auth logic, and no secrets. The BLOCKER criteria (test coverage for new functionality, unvalidated user input, secrets in code, DRY violations in auth paths) do not apply to a passive JSON file. The "no test coverage" blocker does not apply here -- this is seed data, not functionality. The consuming code (PR #328 -- Sponsor model + CRUD) is where test coverage will be evaluated. ### NITS 1. **No JSON schema validation**: There is no JSON Schema or Pydantic model in this PR to enforce the `{business_name, email, category}` shape. The consuming PR (#328) should define the expected schema. Not a blocker for this PR since the data file is inert until loaded. 2. **Category enum not defined here**: The 7 category values (financial, food, retail, automotive, construction, fitness, dental) should be enforced as an enum in the consuming model. Just a note for the #328 review. ### SOP COMPLIANCE - [x] Branch named after issue: `323-sponsor-seed-data` follows `{issue-number}-{kebab-case-purpose}` - [x] PR body has Summary, Changes, Test Plan, Related sections - [ ] Related references plan slug: No plan slug -- PR body says "None" for Related Notes. Acceptable since this was called out as no plan slug in the review request. - [x] No secrets committed -- emails are public business contact addresses, not credentials - [x] No scope creep -- single file, exactly what the issue describes ### PROCESS OBSERVATIONS - Low change failure risk: static data file with no runtime behavior. - This is the first of a multi-PR chain (seed data -> model+CRUD -> email template -> blast endpoint). The chain is well-decomposed with each PR doing one thing. - Deployment frequency: no deployment impact until the consuming code lands. ### VERDICT: APPROVED