Westside Basketball

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #144, sub-ticket 4/4, depends on #147
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- "As a parent I want to open a link Marcus sent me..."
• [x] Context -- Token approach, live queries, pay button logic explained
• [x] File Targets -- 4 create/modify, 3 do-not-touch, all verified
• [x] Feature Flag -- "none" with justification (inert without valid token)
• [x] Acceptance Criteria -- 10 criteria, all specific and testable
• [x] Test Expectations -- 5 integration tests + run command
• [x] Constraints -- 5 constraints (auth bypass, layout, CSS, mobile-first, no JS)
• [x] Checklist -- present
• [x] Related -- 3 references (#144 parent, #147 dependency, public views)

Traceability

• [x] story:WS-S9 label -- "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified -- WS-S9 found in project-westside-basketball user-stories section (Admin stories list)
• [x] arch:rails-app label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-app for component rails-app. Search returned no results for "arch-rails-app" or "arch rails-app westside".
• [x] Forgejo issue -- ldraney/westside-basketball#148, open

File Targets

• [x] app/controllers/invoices_controller.rb -- verified: does not exist yet (new file, expected)
• [x] app/views/invoices/show.html.erb -- verified: does not exist yet (new file, expected)
• [x] app/views/layouts/invoice.html.erb -- verified: does not exist yet (new file, expected). Existing layouts: application, admin, mailer
• [x] config/routes.rb -- verified: exists, currently has public routes at lines 41-48 for reference pattern
• [x] Do-not-touch: app/controllers/admin/players_controller.rb -- exists
• [x] Do-not-touch: app/controllers/webhooks_controller.rb -- exists, uses same ActionController::Base inheritance pattern
• [x] Do-not-touch: app/controllers/application_controller.rb -- exists, includes Authentication module
• [x] Reference: app/views/public/ -- exists with about.html.erb, gear.html.erb, etc. CSS patterns (semantic CSS with .hero, .section, .container, .card classes) confirmed

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets in the same repo. Single-repo feature, no cross-repo concerns.

Dependencies

• parent:144 -- "Player invoice builder" (board item 1678, backlog) -- documented in Lineage
• depends:147 -- "Invoice builder UI: select items and generate tokenized link" (board item 1681, backlog) -- documented. Introduces Rails.application.message_verifier(:invoice) pattern that #148 consumes. Token payload structure (player_id, scope, item IDs) defined in #147.
• Transitive: #147 depends on #145 -- "Mark-as-paid + paid_method migration" (board item 1679, backlog). #148 queries paid state but doesn't modify it.
• Sibling: #146 -- "Custom charges on player detail page" (board item 1680, backlog, depends:145). Not a direct dependency of #148 but custom charges would appear as unpaid items on the invoice.
• Note: player_tournaments table referenced in #147 token payload does not exist in DB schema yet (model file exists at app/models/player_tournament.rb, but issue #111 is still open). The invoice page handles this gracefully -- it queries whatever items exist. Not a blocker.
• All dependency items are in backlog. Chain is clear: #145 -> #147 -> #148.

Acceptance Criteria

10 criteria, all specific, measurable, and verifiable by an agent via integration tests. Criteria cover: no-login access, correct data display, conditional pay buttons, full vs selective scope, paid-in-full state, error handling for invalid/expired tokens, mobile responsiveness, and branding consistency. Test expectations align with AC (5 integration tests covering the key states).

Blast Radius

Low. All new code (controller, view, layout) is isolated from existing auth and admin systems. The InvoicesController inherits from ActionController::Base directly (matching the existing WebhooksController pattern), so no risk of auth bypass leaking into admin routes. New layout prevents admin nav exposure. Route GET /invoice/:token does not conflict with existing routes. No existing invoice patterns in the codebase to conflict with (only one reference to "invoice" in existing views, in the delinquency report meta tag). No downstream consumers affected.

Decomposition Assessment

• 4 file targets in 1 repo -- under the >3 across >2 repos threshold
• 10 acceptance criteria -- exceeds the >5 threshold
• Estimated agent work: ~3-5 minutes -- borderline on >5 min threshold

Assessment: No decomposition needed despite exceeding the AC count threshold. The 10 criteria test different states of a single page (valid/invalid token, full/selective scope, paid/unpaid, mobile, branding), not separate features. The 3 new files form one logical unit (controller + view + layout) plus one trivial route addition. The 2-point estimate is appropriate. Decomposing would create artificial sub-tickets that cannot be delivered independently.

Recommendation

• [SCOPE] Create architecture note arch-rails-app for component rails-app. Every ticket labeled arch:rails-app (including siblings #145, #146, #147, and parent #144) has this same gap. Creating the note once resolves the traceability gap for the entire invoice builder epic.

No other issues found. The scope document is well-written with clear context, accurate file targets, proper dependency documentation, and testable acceptance criteria. Once the arch note exists, this ticket is READY.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #144, sub-ticket 1/4
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present
• [x] Context — thorough, identifies schema issue and webhook impact
• [x] File Targets — 6 files listed with clear descriptions
• [x] Feature Flag — none (appropriate for internal admin feature)
• [x] Acceptance Criteria — 10 criteria listed
• [x] Test Expectations — 4 test cases with run command
• [x] Constraints — 3 constraints listed
• [x] Checklist — present
• [x] Related — parent issue and review note referenced

All required sections present per template-issue-feature.

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for the Rails application component. Search for "arch-rails-app" returned no results in pal-e-docs.
• [x] Forgejo issue — ldraney/westside-basketball#145, open

File Targets

• [x] db/migrate/YYYYMMDD_add_paid_method_and_nullable_stripe.rb — new file. Schema confirms payment_links.stripe_payment_link_id (NOT NULL, line 221) and stripe_payment_link_url (NOT NULL, line 222) need nullable migration. orders table lacks paid_at (confirmed at lines 156-172). paid_method column does not exist yet anywhere in codebase.
• [x] app/controllers/admin/players_controller.rb — verified exists. Already loads @unpaid_links (line 43), @paid_links (line 44), @paid_orders (line 46), @player_tournaments (line 51). Good insertion point for mark_paid action.
• [x] app/views/admin/players/show.html.erb — verified exists. Has "Outstanding Balances" section (line 153) and "Tournament History" section (line 92). Renders @unpaid_links (line 175) and @pending_orders (line 159).
• [x] app/controllers/webhooks_controller.rb — verified exists. Line 75 confirms: payment_link.update!(paid_at: Time.current, status: "paid") — matches ticket's description exactly. Adding paid_method: 'stripe' here is correct.
• [x] config/routes.rb — verified exists. Admin player routes at lines 24-28 use resources :players with member block. New mark_paid route fits naturally as another member action.
• [x] app/javascript/controllers/mark_paid_controller.js — new file. Reference pattern inline_fee_controller.js exists and verified — uses Stimulus with fetch PATCH, CSRF token, and status feedback. Good pattern to follow.

All file targets verified. Schema claims match actual codebase state.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets in same repo. Single-repo change.

Dependencies

• Board item #1679 has label parent:144 (parent issue: Player invoice builder)
• Board items #1680 and #1681 both have label depends:145 — they depend on THIS ticket completing first
• Board item #1682 has depends:147 (invoice builder UI) — sibling but not dependent on #145
• This ticket (#145) has no depends: label — it can be implemented independently, which is correct since it is the foundation sub-ticket (1/4)
• The ticket correctly makes stripe_payment_link_id and stripe_payment_link_url nullable, which unblocks #146 (custom charges that create DB-only payment_links without Stripe backing)

Dependency chain is correctly structured: #145 is the foundation, #1680/#1681 depend on it.

Acceptance Criteria

10 acceptance criteria, all verifiable by an agent:

• AC 1-4: migration assertions — verifiable via schema.rb inspection after rails db:migrate
• AC 5-7: UI dropdowns — verifiable via view file inspection and manual test
• AC 8: correct column updates — verifiable via controller test
• AC 9: webhook writes paid_method: 'stripe' — verifiable via code inspection and test
• AC 10: subscription webhook not broken — verifiable via existing test suite

Test commands are real (bin/rails test). All criteria are testable.

Note: AC 8 references player_tournaments.paid_at — this column already exists in the create_player_tournaments migration (line 9 of 20260628220000_create_player_tournaments.rb), so the new migration does NOT need to add it. The ticket's migration spec does not mention adding paid_at to player_tournaments, which is correct.

Blast Radius

• app/controllers/admin/payments_controller.rb — queries orders.select { |o| o.status == "paid" }. Manually-paid orders will now appear here too. This is intended and correct.
• app/controllers/admin/delinquency_report_controller.rb — queries payment_links.select { |l| l.status == "active" }. Marking paid changes status away from "active", removing the item from the delinquency report. Correct behavior.
• app/views/admin/roster_report/ — ticket correctly excludes this. No impact.
• app/services/stripe_client.rb — ticket correctly excludes this. No new Stripe API calls needed.
• Webhook backward compatibility: existing payment_links with NULL paid_method are treated as legacy/unknown per ticket constraints. Safe.

No unintended blast radius found. Downstream consumers handle the new state correctly.

Decomposition Assessment

6 file targets in 1 repo. 10 acceptance criteria (exceeds threshold of 5). Estimated agent work: ~8 minutes.

However, this ticket was already decomposed from parent #144 (sub-ticket 1/4). The 10 AC are tightly coupled around a single feature (mark-as-paid). Splitting further would create artificial seams between migration/controller/view that must be deployed atomically. No further decomposition recommended.

Recommendation

• [SCOPE] Create architecture note arch-rails-app for the Rails application component. This label is used across multiple board items (1678, 1679, 1680, 1681, 1682) but has no backing note.

Verdict: READY

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #144, depends on #145
• [x] Repo — ldraney/westside-basketball
• [x] User Story — As admin, I want to add custom charges so that all outstanding balances are tracked in one place
• [x] Context — Explains gap in current charge sources (payment_links, orders, player_tournaments)
• [x] File Targets — 4 files to modify/create, 3 files NOT to touch
• [x] Feature Flag — none (internal admin feature, correct)
• [x] Acceptance Criteria — 6 criteria
• [x] Test Expectations — 3 test expectations + run command (bin/rails test)
• [x] Constraints — 3 constraints documented
• [x] Checklist — standard PR/tests/no unrelated changes
• [x] Related — lists parent #144 and dependency #145

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for the Rails application component. Note: this is a systemic gap affecting many board items, not specific to this ticket.
• [x] Forgejo issue — ldraney/westside-basketball#146, open

File Targets

• [x] app/controllers/admin/players_controller.rb — verified: exists (2.1k), has index + show actions, needs create_charge action added
• [x] app/views/admin/players/show.html.erb — verified: exists (11k), Outstanding Balances section at line 150, already handles nil stripe_payment_link_url (line 181-184 shows dash)
• [x] config/routes.rb — verified: exists, admin players routes at line 24 with member block, needs POST route added
• [x] app/javascript/controllers/add_charge_controller.js — NEW FILE: to be created. Reference pattern inline_fee_controller.js (3.8k) exists and is well-structured
• [x] NOT TOUCH: app/models/payment_link.rb — verified: product already optional (belongs_to :product, optional: true), no changes needed
• [x] NOT TOUCH: app/services/stripe_client.rb — correct: custom charges are DB-only
• [x] NOT TOUCH: app/controllers/webhooks_controller.rb — verified: webhook finds by stripe_payment_link_id (line 69-70), so custom charges with nil IDs won't be matched. Safe.

Repo Placement

OK — issue filed on ldraney/westside-basketball, fix is in ldraney/westside-basketball. Single repo.

Dependencies

• depends:145 (board item 1679) — Mark-as-paid + paid_method migration. Currently in backlog. MUST complete first: makes stripe_payment_link_id and stripe_payment_link_url nullable (currently NOT NULL per schema.rb lines 221-222). Without this migration, creating payment_links rows with nil Stripe fields will raise DB constraint violations.
• parent:144 (board item 1678) — Player invoice builder parent issue, in backlog.
• Siblings #147 (board item 1681) and #148 (board item 1682) do not depend on this ticket.
• Dependencies are correctly documented in both the Lineage and Constraints sections of the issue.

Acceptance Criteria

All 6 AC are verifiable by an agent:

• AC1-2: UI presence checks (button + inline form) — verifiable via view source or browser test
• AC3: DB row creation with correct fields — verifiable via unit test
• AC4: No-reload appearance — verifiable via Turbo/DOM test
• AC5: Mark Paid integration — verifiable but requires #145 to be merged first
• AC6: Amount validation — verifiable via unit test

Test commands are real (bin/rails test). No missing criteria detected.

Blast Radius

• Unique constraint safety: payment_links has a unique constraint on [player_id, product_id, tenant_id]. Custom charges use product_id: nil. PostgreSQL treats NULLs as distinct in unique constraints, so multiple custom charges per player are safe. Note for awareness only.
• Webhook safety: Stripe webhook at webhooks_controller.rb:69 finds payment_links by stripe_payment_link_id. Custom charges with nil stripe_payment_link_id will never be matched. No conflict.
• Outstanding Balances view: Already filters by status == 'active' and handles nil stripe_payment_link_url by showing a dash. Custom charges will render correctly without view logic changes beyond the Add Charge form.
• Total outstanding calculation: Controller line 48 sums all unpaid_links.amount_cents. Custom charges will be included automatically. Correct behavior.

Decomposition Assessment

4 file targets in 1 repo. 6 acceptance criteria (borderline on the >5 threshold). Estimated agent time: under 5 minutes — the work is a single POST action, a Stimulus controller following an existing pattern, an inline form in an existing view, and one route addition. All tightly coupled. No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-rails-app for the Rails application component. This is a systemic gap — multiple board items reference arch:rails-app but no backing note exists. Not a blocker for this ticket specifically.

No other action needed. Scope is solid, file targets verified, dependency chain correct.

Verdict: NEEDS_REFINEMENT

Board item #1681 — Forgejo issue ldraney/westside-basketball#147. Feature type. Points: 2.

Template Completeness

• [x] Type — Feature
• [x] Lineage — child of #144, depends on #145
• [x] Repo — ldraney/westside-basketball
• [x] User Story — complete (admin generates shareable invoice link)
• [x] Context — thorough; documents MessageVerifier token approach
• [x] File Targets — 5 files to modify/create, 3 files to avoid
• [x] Feature Flag — "none" (appropriate for admin-only UI)
• [x] Acceptance Criteria — 9 items
• [x] Test Expectations — 3 tests + run command
• [x] Constraints — 3 listed (secret_key_base, payload size, Stimulus patterns)
• [x] Checklist — present
• [x] Related — 3 related issues

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-app label — Rails application component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-app for the Rails application component
• [x] Forgejo issue — ldraney/westside-basketball#147, open

File Targets

• [x] app/controllers/admin/players_controller.rb — verified: exists with index and show actions; generate_invoice action will be added
• [x] app/views/admin/players/show.html.erb — verified: 287 lines, shows outstanding balances (payment_links, orders) and tournament history sections. Checkboxes will span multiple sections.
• [x] config/routes.rb — verified: admin namespace has resources :players, only: [:index, :show] with member block; POST route for generate-invoice will be added
• [x] app/javascript/controllers/invoice_builder_controller.js — new file; directory exists with 4 existing controllers (application, index, inline_fee, program). Stimulus patterns established.
• [x] app/javascript/controllers/clipboard_controller.js — new file; ticket says "(or inline in invoice_builder)" so may be optional

Repo Placement

OK. Issue filed on ldraney/westside-basketball, Repo section says ldraney/westside-basketball, all file targets within this repo. No cross-repo concerns.

Dependencies

• #144 (parent, board ID 1678) — backlog, 5pts — parent issue for the invoice builder epic
• #145 (dependency, board ID 1679) — backlog, 2pts — "Mark-as-paid + paid_method migration". Currently in backlog. This must be completed first: without manual mark-as-paid, the invoice builder would show items as unpaid that may have been paid via cash/Venmo, producing inaccurate invoices. Dependency is correctly documented in both labels and issue body.
• #146 (sibling, board ID 1680) — backlog, 1pt — "Custom charges on player detail page". Not a direct dependency but adds custom charge items that would appear on invoices. The issue body mentions #146 in the Context section.
• #148 (downstream, board ID 1682) — backlog, 2pts, depends:147 — "Public invoice page (tokenized, no-login)". Consumes the tokens this ticket generates. Correctly listed as downstream.

All dependencies correctly documented. Ordering on the board is correct: #145 must be done before #147, and #148 depends on #147.

Acceptance Criteria

9 AC items. Most are verifiable via controller tests and DOM assertions. Two issues:

• AC #9 ("Token is tamper-proof — modifying the URL returns an error on the public page (#148)") — this AC tests #148's behavior, not #147's. The tamper-proof property can be verified in isolation with a unit test (MessageVerifier raises InvalidSignature on modified tokens), which is already covered in Test Expectations. AC #9 should be reworded to reference the unit test, not the public page.
• AC #7 ("Clicking Copy copies the URL to clipboard") — clipboard API tests can be flaky in CI due to browser permissions, but the Stimulus controller can be tested with mocked navigator.clipboard. Acceptable.

Blast Radius

• No existing MessageVerifier usage in the codebase — this introduces a new pattern. Low risk since MessageVerifier is a standard Rails API.
• No existing clipboard functionality — new Stimulus controller adds no risk to existing features.
• Checkboxes modify the player detail show page visual layout. The show page is admin-only, so blast radius is limited to admin users.
• Route changes are scoped to admin namespace — no impact on public routes.
• Note: @total_outstanding_cents currently excludes unpaid tournament amounts (only sums payment_links + orders). The invoice builder will include tournaments as selectable items but the "Total Owed" stat card will not match. This is a pre-existing data gap, not introduced by this ticket.

Decomposition Assessment

5 file targets across 1 repo, 9 acceptance criteria, estimated agent work ~25-35 minutes.

• >3 file targets across >2 repos — NO (1 repo)
• >5 acceptance criteria — YES (9 AC)
• Estimated agent work >5 minutes — YES

The 9 AC count triggers the decomposition threshold. However, the work is highly cohesive: the Stimulus controller, the controller action, the view changes, and the route are tightly coupled and cannot be meaningfully separated. The backend token generation only has value with the frontend checkboxes, and vice versa. Decomposing would create artificial boundaries and increase integration risk. Recommendation: keep as single ticket but reduce AC count by removing AC #9 (belongs to #148) and potentially merging AC #4/#5 into one criterion. If AC count drops to 7, it is borderline acceptable.

Recommendations

• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs
• [BODY] Reword AC #9: replace "modifying the URL returns an error on the public page (#148)" with "Unit test verifies MessageVerifier raises InvalidSignature on tampered tokens" — the public page error handling belongs to #148
• [BODY] Clarify that checkboxes span two view sections (Outstanding Balances for payment_links/orders, Tournament History for player_tournaments with pending status) since unpaid items are currently displayed in separate sections

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during data audit discussion
• [x] Repo — ldraney/westside-basketball
• [x] User Story — As an admin (Marcus), mark payments, add charges, generate invoice link
• [x] Context — Detailed table of current state, Stripe flow, critical gap, approach
• [x] File Targets — 7 files to modify/create, 4 exclusions
• [x] Feature Flag — none (admin-only + signed token)
• [x] Acceptance Criteria — 9 criteria
• [x] Test Expectations — 5 test items + run command
• [x] Constraints — 6 constraints
• [x] Checklist — 3 items
• [x] Related — 4 references

Traceability

• [x] story:WS-S9 — "As an admin, I want to track payment status per player so that I know who owes what" — verified in project-westside-basketball user-stories section
• [x] story:WS-S35 — "As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier" — verified in project-westside-basketball user-stories section
• [ ] arch:rails-app — arch note MISSING — [SCOPE] Create architecture note arch-rails-app for the Rails application component
• [x] Forgejo issue — ldraney/westside-basketball#144, state: open

File Targets

• [x] app/controllers/admin/players_controller.rb — verified: exists, has show action with payment_links/orders/player_tournaments queries
• [x] app/views/admin/players/show.html.erb — verified: exists, 287 lines, shows outstanding balances and payment history
• [x] config/routes.rb — verified: exists, admin namespace with players resources
• [x] app/controllers/invoices_controller.rb — does not exist yet (to be created), no conflict
• [x] app/views/invoices/show.html.erb — does not exist yet (to be created), no conflict
• [x] app/javascript/controllers/clipboard_controller.js — does not exist yet (to be created), no conflict. Existing Stimulus controllers (inline_fee, program) confirm pattern.
• [x] db/migrate/YYYYMMDD_add_paid_method_columns.rb — migration, will be generated
• [ ] ISSUE: Migration scope underestimated — see Recommendation below

Repo Placement

OK — issue filed on ldraney/westside-basketball, all file targets are in this repo. No multi-repo concerns.

Dependencies

No blocking dependencies found on the board. Issues #131/#132/#133/#134 (Stripe DB reconciliation) are closed predecessors. Issue #123 (fee editing to player detail page) is open but addresses a different concern. Phase 14 (Billing Tiers) is in_progress but doesn't block this ticket.

Acceptance Criteria

9 criteria, all in "When X, then Y" format, each testable by an agent. Well-written and specific. However, 9 AC exceeds the decomposition threshold of 5.

Blast Radius

• webhooks_controller.rb — Currently marks payment_links as paid at line 75: payment_link.update!(paid_at: Time.current, status: "paid"). After adding paid_method, webhook-originated payments will have NULL paid_method unless the webhook is updated to set paid_method: 'stripe'. The ticket says NOT to touch the webhook, but doesn't address this gap (no DB default, no backfill strategy).
• MessageVerifier — No existing usage in the codebase. New pattern introduction, low blast radius.
• Schema constraint conflict — payment_links.stripe_payment_link_id (NOT NULL, limit 200) and payment_links.stripe_payment_link_url (NOT NULL, limit 500) prevent storing DB-only custom charges. The ticket's Constraints section claims "no schema change needed for this" but the NOT NULL constraints must be relaxed.

Decomposition Assessment

NEEDS DECOMPOSITION — route to skill-decompose-ticket

• 7 file targets in 1 repo (threshold: >3 across >2 repos — not met, but close)
• 9 acceptance criteria (threshold: >5 — exceeded)
• Estimated agent work: well over 5 minutes — migration with schema changes, 3+ new controller actions, 1 new controller, significant view modifications, 1 new public view, 1 new Stimulus controller, multiple test files
• 4 independent concerns: (1) mark-as-paid with method tracking, (2) custom charges, (3) invoice builder UI + tokenized URL generation, (4) public invoice page

Recommendation

• [BODY] Fix schema claim: payment_links.stripe_payment_link_id and stripe_payment_link_url are NOT NULL — migration must ALTER these columns to be nullable for DB-only custom charges. Update the Constraints section that says "no schema change needed for this" and expand the migration file target description.
• [BODY] Address webhook blast radius: webhooks_controller.rb line 75 sets status: "paid" without paid_method. Either (a) add paid_method: 'stripe' to the webhook update (contradicts "don't touch" directive — update that list), or (b) add a DB default of 'stripe' for paid_method so webhook-originated payments are correctly tagged, or (c) explicitly document that webhook payments will have NULL paid_method and that's acceptable.
• [SCOPE] Create architecture note arch-rails-app for the Rails application component in pal-e-docs.
• [DECOMPOSE] 9 AC across 7 file targets with 4 independent concerns (mark-paid, custom charges, invoice builder, public invoice page). Exceeds 5-minute rule. Route to skill-decompose-ticket with suggested sub-tickets:
  1. Migration + Mark as Paid — migration (paid_method, paid_at, nullable Stripe columns), mark-paid controller actions, UI buttons per line item
  2. Custom Charges — add-charge action, form UI on player detail page
  3. Invoice Builder + Clipboard — tokenized URL generation endpoint, checkboxes in admin UI, clipboard Stimulus controller
  4. Public Invoice Page — InvoicesController, public view, mobile-friendly layout, pay buttons

Verdict: APPROVED

Re-review of board item #1673. Previous review (review-1673-2026-07-01) returned NEEDS_REFINEMENT for two issues, both now resolved.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during docs robustness audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present
• [x] Context — present
• [x] File Targets — present (1 create, 2 reference)
• [x] Feature Flag — none (correct for docs-only)
• [x] Acceptance Criteria — 6 items
• [x] Test Expectations — no automated tests, documentation only
• [x] Constraints — present
• [x] Checklist — present (omits "Tests pass" appropriately given no-test expectation)
• [x] Related — present

Traceability

• [x] story:WS-S1 label — present on board item. WS-S1 ("deploy platform changes via IaC") is not a perfect match for developer testing docs, but accepted as the closest existing story. No dedicated developer-docs story exists. Acceptable per re-review guidance.
• [x] story note verified — WS-S1 found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:docs label — present on board item
• [x] arch note verified — arch-docs note exists in pal-e-docs (created 2026-07-01, associated with westside-basketball project). Covers docs/ directory scope, lists current docs inventory.
• [x] Forgejo issue — #138, open

Previous Review Issues — Resolution

• [x] story:WS-S1 mismatch — accepted. WS-S1 is the closest existing story (platform IaC/reproducibility). No dedicated developer-docs story exists. This affects all 6 sibling docs tickets (#136-#141) and is acceptable for now.
• [x] arch-docs note missing — resolved. arch-docs note now exists with title "Architecture: Documentation", scoped to docs/ directory content.

File Targets

• [x] docs/testing-strategy.md — verified: file does NOT exist yet (correct, this is a create target). Parent docs/ directory exists with 7 existing docs.
• [x] test/ directory — verified: exists with 23 test files across controllers, helpers, lib, mailers, models, services, support, and test_helper.rb
• [x] Gemfile — verified: exists, has group :development, :test with debug, bundler-audit, brakeman gems

Repo Placement

OK. Issue filed on ldraney/westside-basketball, issue body says ldraney/westside-basketball. Single repo, no cross-repo concerns.

Dependencies

Part of a docs batch (issues #136-#141), all in backlog. Sibling tickets:

• #1671 — Docs: local dev setup guide (#136) — backlog
• #1672 — Docs: CI/CD pipeline architecture (#137) — backlog
• #1673 — Docs: testing strategy (#138) — THIS ITEM — backlog
• #1674 — Docs: security posture (#139) — backlog
• #1675 — Docs: observability and alerting (#140) — backlog
• #1676 — Docs: deployment and infrastructure (#141) — backlog

No blocking dependencies. In-progress items (Phase 15 SPA Rebuild, Phase 11 Girls Tryout, Phase 14 Billing Tiers) do not block this ticket. All docs batch items are independent and can be worked in any order.

Acceptance Criteria

6 criteria, all verifiable by an agent:

• [x] File existence check — trivial to verify
• [x] Content coverage (philosophy, test types, fixtures, run commands, CI) — verifiable by searching doc content

Criteria are clear and testable. No missing criteria identified.

Blast Radius

Minimal. Creates one new markdown file. No code changes. No existing testing documentation found in the repo to conflict with. No downstream consumers affected.

Decomposition Assessment

No decomposition needed:

• 1 file to create, 2 files to reference — single repo
• 6 acceptance criteria (all about content in one file)
• Estimated agent work: <5 minutes
• Fits comfortably in a single agent pass

Recommendation

No action needed.

Verdict: READY

Re-review of board item #1671. Previous review (review-1671-2026-07-01) returned NEEDS_REFINEMENT due to missing arch-docs architecture note. That note has now been created. All other checks passed previously and still pass.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during docs robustness audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present
• [x] Context — present, explains motivation
• [x] File Targets — present (1 create, 3 reference)
• [x] Feature Flag — none (appropriate for docs)
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — present (manual review only, appropriate for docs)
• [x] Constraints — present (follow landscaping-assistant model, reference platform SOPs)
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — WS-S1 found in project-westside-basketball user-stories section under Superadmin (Lucas). Mapping is loose (IaC deployment vs local dev setup) but acceptable as foundational platform work.
• [x] arch:docs label — present on board item
• [x] arch note verified — arch-docs note exists (id 2311, created 2026-07-01). Describes docs/ directory scope, lists current docs inventory, associated with westside-basketball project, active status. Previous blocker resolved.
• [x] Forgejo issue — ldraney/westside-basketball#136, state: open

File Targets

• [x] docs/local-dev-setup.md — to be created. Confirmed file does not yet exist (correct for a new feature).
• [x] docs/keycloak.md — verified: exists, has "Dev Mode" section at line 239 describing KEYCLOAK_URL-unset behavior.
• [x] docker-compose.yml — verified: exists at repo root.
• [x] Gemfile — verified: exists at repo root.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, ### Repo section says ldraney/westside-basketball. Single-repo change, no cross-repo concerns.

Dependencies

No blocking dependencies. No doc-related items in in_progress, todo, or next_up. Sibling docs tickets exist in backlog (all arch:docs, story:WS-S1) but are independent:

• #1672 — Forgejo #137: CI/CD pipeline architecture (3pt)
• #1673 — Forgejo #138: testing strategy (2pt)
• #1674 — Forgejo #139: security posture (3pt)
• #1675 — Forgejo #140: observability and alerting (2pt, story:WS-S2)
• #1676 — Forgejo #141: deployment and infrastructure (3pt)

Acceptance Criteria

7 criteria, all verifiable by an agent:

• File existence — trivial ls check
• Prerequisites section — grep for Ruby/Bundler/Node
• Database setup — grep for local DB and k8s overlay
• Dev overlay — grep for kubectl port-forward and localhost:9999
• Docker-compose option — grep for docker-compose
• Environment variables — grep for env var section
• Keycloak reference — grep for keycloak.md

All criteria are clear and testable. No missing criteria detected.

Blast Radius

Zero. Documentation-only change. No code, no tests, no config affected. No downstream consumers impacted.

Decomposition Assessment

1 file target, 1 repo, 7 AC (all for a single markdown file). Estimated agent work: under 5 minutes. No decomposition needed.

Recommendation

No action needed.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during docs robustness audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present
• [x] Context — present
• [x] File Targets — present (1 create, 2 reference)
• [x] Feature Flag — none (correct for docs-only)
• [x] Acceptance Criteria — 6 items
• [x] Test Expectations — no automated tests, documentation only
• [x] Constraints — present
• [x] Checklist — present (missing "Tests pass" item from template, but appropriate given no-test expectation)
• [x] Related — present

Traceability

• [x] story:WS-S1 label — present on board item
• [ ] story note MISMATCH — WS-S1 is "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable." The issue's own user story is "As a developer contributing to westside-basketball, I want a testing strategy doc." Testing docs are developer experience, not IaC deployment. [SCOPE] Assign correct story or create a developer-docs story (e.g. WS-S39).
• [x] arch:docs label — present on board item
• [ ] arch note MISSING — search for "arch-docs" returned no results. [SCOPE] Create architecture note arch-docs for the documentation component.
• [x] Forgejo issue — #138, open, valid URL

File Targets

• [x] docs/testing-strategy.md — verified: file does NOT exist yet (correct, this is a create target). Parent docs/ directory exists with 7 existing docs.
• [x] test/ directory — verified: exists with subdirectories controllers, helpers, lib, mailers, models, services, support, and test_helper.rb
• [x] Gemfile — verified: exists

Repo Placement

OK. Issue filed on ldraney/westside-basketball, issue body says ldraney/westside-basketball. Single repo, no cross-repo concerns.

Dependencies

Part of a docs batch (issues #136-#141), all in backlog. Sibling tickets:

• #1671 — Docs: local dev setup guide (#136)
• #1672 — Docs: CI/CD pipeline architecture (#137)
• #1673 — Docs: testing strategy (#138) — THIS ITEM
• #1674 — Docs: security posture (#139)
• #1675 — Docs: observability and alerting (#140)
• #1676 — Docs: deployment and infrastructure (#141)

No blocking dependencies. All are independent docs and can be worked in any order. No in-progress items block this ticket.

Acceptance Criteria

6 criteria, all verifiable by an agent:

• [x] File existence check — trivial to verify
• [x] Content coverage (philosophy, test types, fixtures, run commands, CI) — verifiable by grepping doc content

Criteria are clear and testable. No missing criteria identified.

Blast Radius

Minimal. Creates one new markdown file. No code changes. No existing testing documentation found in the repo to conflict with. No downstream consumers affected.

Decomposition Assessment

No decomposition needed:

• 1 file to create, 2 files to reference — single repo
• 6 acceptance criteria (all about content in one file)
• Estimated agent work: <5 minutes
• Fits comfortably in a single agent pass

Recommendation

• [SCOPE] Story label mismatch: story:WS-S1 is about IaC deployment, but this ticket is developer testing documentation. Either create a new developer-docs user story (e.g. WS-S39: "As a developer, I want project documentation so that onboarding is fast and conventions are clear") or reassign to a more fitting existing story. This affects all 5 sibling docs tickets (#136-#141) that also use WS-S1.
• [SCOPE] Create architecture note arch-docs for the documentation component in pal-e-docs.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during docs robustness audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present (operator deploying westside-basketball)
• [x] Context — present
• [x] File Targets — docs/deployment.md (create), k8s/ (reference)
• [x] Feature Flag — none (appropriate for docs)
• [x] Acceptance Criteria — 8 criteria present
• [x] Test Expectations — no automated tests, documentation only
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — project-westside-basketball

All required sections for the Feature template are present.

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:docs label — documentation component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-docs for component docs
• [x] Forgejo issue — ldraney/westside-basketball#141, open

File Targets

• [x] docs/deployment.md — to be created. Confirmed does not exist yet. Target directory docs/ exists with 7 other docs (consolidation.md, dashboard.md, keycloak.md, roles.md, routes.md, spike-47-actionmailer-gmail-api.md, stripe-subscription-architecture.md).
• [x] k8s/ directory — exists, contains dev.yaml (namespace, secret, deployment, service, ingress with Tailscale funnel). Only dev overlay is committed; prod manifests live in pal-e-deployments repo.

Repo Placement

OK — issue filed on ldraney/westside-basketball and the file target (docs/deployment.md) belongs in this repo. The documentation will reference cross-repo infrastructure (pal-e-services for Terraform, pal-e-deployments for k8s overlays) but the doc itself is correctly placed in the application repo.

Dependencies

• Sibling docs batch: issues #136 (local dev setup), #137 (CI/CD pipeline), #138 (testing strategy), #139 (security posture), #140 (observability) — all in backlog with arch:docs label. No ordering dependency between them.
• No blocking items found in in_progress or next_up columns.
• The Constraints section references two SOPs that do not exist in pal-e-docs: sop-deploy-recovery and sop-frontend-dev-overlay. An implementing agent would fail to reference these. Either the SOPs need to be created first, or the constraint must be updated to remove the references.

Acceptance Criteria

8 acceptance criteria, all verifiable by checking for section headings and keyword presence in docs/deployment.md. The criteria are sections of a single file rather than distinct behavioral features, which is appropriate for a docs ticket. The criteria use "covers" which is slightly vague but acceptable for documentation — an agent can verify each section exists with meaningful content.

Blast Radius

Minimal — documentation only, no code changes. The landscaping-assistant reference doc (docs/infrastructure-and-pipeline.md, 443 lines) exists and provides a good structural model as specified in constraints. Five sibling docs issues follow the same pattern.

Decomposition Assessment

1 file target in 1 repo. 8 acceptance criteria, but they are sections of a single document. Estimated agent work ~5 minutes — gather info from k8s/dev.yaml and landscaping-assistant reference, then write a cohesive doc. No decomposition needed.

Recommendations

• [SCOPE] Create architecture note arch-docs for the documentation component in pal-e-docs.
• [BODY] Fix Constraints section: referenced SOPs sop-deploy-recovery and sop-frontend-dev-overlay do not exist in pal-e-docs. Either create them first or update the constraint to say "Reference pal-e-docs memory notes and existing infrastructure docs rather than duplicating."

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag — "none" (appropriate for docs)
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist — missing "Tests pass" but justified (doc-only ticket)
• [x] Related

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [ ] arch:docs label — MISLABELED. This ticket documents the CI/CD pipeline, not a "docs" architecture component. Other CI/CD board items use arch:ci-cd (#1603) or arch:ci-pipeline (#1616, #438). [LABEL] Change to arch:ci-cd
• [ ] arch note MISSING — no arch-docs, arch-ci-cd, or arch-ci-pipeline note exists in pal-e-docs. [SCOPE] Create architecture note arch-ci-cd for the CI/CD component
• [x] Forgejo issue — ldraney/westside-basketball#137, open

File Targets

• [x] docs/cicd-pipeline.md — to be created (expected for Feature). docs/ directory exists with 7 existing docs
• [x] Dockerfile — verified exists (2.8k, multi-stage Ruby 3.4.8 build)
• [x] .woodpecker.yaml — verified exists (3.4k, 6 steps: clone, bundle-install, lint, test, audit, build-and-push, update-kustomize-tag)

Repo Placement

OK. Issue filed on ldraney/westside-basketball, doc will live in docs/ of same repo. Single repo scope.

Dependencies

• #1603 "Set up Woodpecker CI pipeline" — done (prerequisite work complete)
• #1616 "Fix CI test failures and gem audit" — done
• #1634 "Fix CI: update-kustomize-tag runs on build failure" — done
• #438 "CI image repo mismatch" — done
• No blocking dependencies. All upstream CI/CD work is complete.

Acceptance Criteria

6 criteria, all verifiable by an agent:

• docs/cicd-pipeline.md exists — file existence check
• Covers Woodpecker pipeline stages — grep for Woodpecker/pipeline content
• Covers Harbor image registry — grep for Harbor content
• Covers ArgoCD deployment flow — grep for ArgoCD content
• Includes mermaid diagram — grep for ```mermaid block
• Documents branch/tag strategy — grep for branch/tag content

All testable. No missing criteria detected.

Blast Radius

Documentation only — no code changes, no downstream consumers affected. Minimal blast radius.

Decomposition Assessment

1 file to create, 2 files to reference. 6 acceptance criteria but all targeting a single markdown file. Estimated agent work under 5 minutes. No decomposition needed.

Recommendation

• [LABEL] Change arch:docs to arch:ci-cd — matches existing board convention (items #1603, #1616, #438 use arch:ci-cd or arch:ci-pipeline)
• [SCOPE] Create architecture note arch-ci-cd for the CI/CD component in pal-e-docs — no arch note exists for any CI/CD label variant
• [BODY] Remove or update constraint referencing sop-ci-pipeline-recovery — this SOP does not exist in pal-e-docs. Either create the SOP first or replace with "Reference platform CI/CD documentation as available"

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, discovered during docs robustness audit
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- present
• [x] Context -- present, clear motivation
• [x] File Targets -- present, files to create and reference listed
• [x] Feature Flag -- "none" (appropriate for docs-only)
• [x] Acceptance Criteria -- 7 items
• [x] Test Expectations -- "No automated tests" (appropriate for docs-only)
• [x] Constraints -- present
• [x] Checklist -- present (omits "Tests pass" which is acceptable for docs-only)
• [x] Related -- present

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified -- found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:docs label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-docs for component docs. Search for "arch-docs" returned no results in pal-e-docs.
• [x] Forgejo issue -- ldraney/westside-basketball#139, state: open

File Targets

• [x] docs/security.md (to create) -- confirmed does not exist yet
• [x] docs/keycloak.md (reference) -- verified exists (6.3k)
• [x] docs/roles.md (reference) -- verified exists (4.3k)
• [x] docs/stripe-subscription-architecture.md (reference) -- verified exists (5.9k)

Repo Placement

OK. Issue filed on ldraney/westside-basketball. All file targets are in docs/ within the same repo. Single-repo scope, no cross-repo concerns.

Dependencies

No blocking dependencies. Five sibling docs tickets share the same labels (arch:docs, story:WS-S1) and are all in backlog:

• #1671 (issue #136) -- Docs: local dev setup guide
• #1672 (issue #137) -- Docs: CI/CD pipeline architecture
• #1673 (issue #138) -- Docs: testing strategy
• #1675 (issue #140) -- Docs: observability and alerting
• #1676 (issue #141) -- Docs: deployment and infrastructure

All are independent and can be implemented in any order. No items in in_progress block this ticket.

Acceptance Criteria

7 ACs, all verifiable by content grep on docs/security.md:

1. File existence -- trivial check
2. Authentication model (Keycloak OIDC) -- grep for keycloak/OIDC
3. Authorization (RBAC) -- grep for role/authorization
4. Stripe API key handling -- grep for stripe/API key
5. PII data handling -- grep for PII/sensitive
6. Secrets management (k8s secrets, SOPS) -- grep for secrets/SOPS
7. References platform SOPs -- ISSUE: Constraints reference sop-secrets-management and sop-network-security but neither exists in pal-e-docs. Agent cannot reference what does not exist.

Blast Radius

Zero. Documentation-only change. No code modifications, no runtime behavior changes, no downstream consumers affected.

Decomposition Assessment

• File targets: 1 file to create, 3 files to reference -- OK (under threshold)
• Repos: 1 -- OK (under threshold)
• Acceptance criteria: 7 -- technically exceeds >5 threshold
• Estimated agent work: ~3-4 minutes (read 3 reference docs, write 1 markdown file with 6 content sections)

No decomposition needed. All 7 ACs map to sections within a single markdown document. The work is a coherent single-agent pass well under 5 minutes.

Recommendations

• [SCOPE] Create architecture note arch-docs for the docs component in pal-e-docs. This is needed for traceability -- 6 board items reference arch:docs but no backing architecture note exists.
• [BODY] AC #7 and Constraints reference sop-secrets-management and sop-network-security which do not exist in pal-e-docs. Update to either: (a) create those SOPs first and add as a dependency, or (b) rewrite AC #7 as "Documents secrets management approach inline" and remove the platform SOP references from Constraints.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type (Feature)
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag (none — appropriate for docs-only work)
• [x] Acceptance Criteria (6 items)
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

All required sections for a Feature issue are present.

Traceability

• [x] story:WS-S2 label — "As superadmin, I want to monitor service health via Grafana so that I catch issues before users do"
• [x] story note verified — found in project-westside-basketball user-stories section (Superadmin list)
• [x] arch:docs label — present on board item
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-docs for component docs. No arch-docs note exists in pal-e-docs. This affects all 6 sibling docs tickets (#1671-#1676) sharing the same label.
• [x] Forgejo issue — ldraney/westside-basketball#140, open

File Targets

• [x] docs/observability.md — to be created. The docs/ directory exists with 7 existing docs (consolidation.md, dashboard.md, keycloak.md, roles.md, routes.md, spike-47-actionmailer-gmail-api.md, stripe-subscription-architecture.md). No existing observability content found in codebase. Valid target.

Repo Placement

OK — issue filed on ldraney/westside-basketball, all work is in the same repo. Single file creation, no cross-repo concerns.

Dependencies

• Board item #184 (done): "Observability — Grafana dashboard + structured logging" (5 points) — prior observability work that may have created infrastructure this doc should reference.
• Sibling docs items in backlog (#1671 CI/CD, #1672 deployment, #1673 local dev, #1674 security, #1676 testing) — all share arch:docs label. Parallel work, none blocking.
• No blocking dependencies detected.

Acceptance Criteria

6 criteria, all assessable by an agent:

• AC-1: File existence — trivially verifiable
• AC-2 through AC-5: Content coverage (logging, monitoring, alerting, health diagnostics) — verifiable via section presence and keyword grep
• AC-6: Grafana references — verifiable via grep for "Grafana"

Criteria are slightly vague (e.g., "Covers logging" without specifying exact requirements) but acceptable for documentation tickets where the constraint section provides structural guidance via the landscaping-assistant model.

Blast Radius

Minimal. Documentation-only change — no code, no tests, no deployments affected. The docs/ directory is not consumed by any build process.

Decomposition Assessment

• 1 file target in 1 repo
• 6 acceptance criteria (slightly over 5 threshold, but all relate to content sections within a single document)
• Estimated agent time: well under 5 minutes
• No decomposition needed.

Constraint Verification

• [x] landscaping-assistant docs/observability-roadmap.md exists at /home/ldraney/landscaping-assistant/docs/observability-roadmap.md — valid structural model
• [x] sop-incident-response exists in pal-e-docs (pal-e-platform project, status: active) — valid reference target

Recommendation

• [SCOPE] Create architecture note arch-docs for the docs component. This note should define what the docs architecture covers (in-repo documentation standards, structure, cross-reference conventions). Affects this ticket and 5 siblings (#1671-#1676).

Verdict: APPROVED

Re-review after refinement. Previous review (review-1670-2026-06-30) returned NEEDS_REFINEMENT with two findings. Both addressed.

Previous Findings Resolution

• [x] [LABEL] story:WS-S12 → story:WS-S9 — FIXED. Board item labels updated. Issue body Related section now references story:WS-S9. Story aligns directly with ticket purpose: "As an admin, I want to track payment status per player so that I know who owes what."
• [x] [SCOPE] arch-rails note missing — Acknowledged as platform-wide gap. The arch:rails label is used across multiple board items but no arch-rails note exists in pal-e-docs. Not blocking for this individual ticket; tracked as cross-cutting documentation debt.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during manual audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — proper As/I want/So that format
• [x] Context — detailed, 5 categories of data inconsistency documented with tables
• [x] File Targets — 2 modify/create, 2 do-not-touch boundaries
• [x] Feature Flag — none (appropriate for rake task)
• [x] Acceptance Criteria — 5 items, all verifiable
• [x] Test Expectations — present with run command
• [x] Constraints — 5 constraints including idempotency and secret handling
• [x] Checklist — present
• [x] Related — present, references story:WS-S9
• [x] Validation Queries — bonus section with concrete reproduction commands

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — WS-S9 found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails label — present on board item
• [~] arch note MISSING — search_notes("arch-rails") returned empty. Platform-wide gap, not blocking. [INFO] Create architecture note arch-rails when addressing cross-cutting documentation debt.
• [x] Forgejo issue — #131, open, valid

File Targets

• [x] lib/tasks/stripe_reconciliation.rake — NEW file. Directory lib/tasks/ exists with 2 existing rake files (seed_tournament_attendance.rake, tournament_email.rake). Correct location for new rake task.
• [x] app/models/player_tournament.rb — EXISTS (337 bytes). Model defines PAYMENT_STATUSES = %w[pending paid_stripe paid_cash paid_venmo waived]. The paid_stripe status is a valid enum value. Schema has amount_cents (integer, nullable) and payment_status (string, default "pending").
• [x] Do-not-touch boundaries verified — app/views/admin/** and app/controllers/** correctly excluded.
• [x] app/services/stripe_client.rb — EXISTS (7.8k). Provides Stripe API access patterns the rake task can reuse.

Repo Placement

OK — issue filed on ldraney/westside-basketball, all code changes are in the same repo. Single-repo ticket.

Dependencies

• No blocking in_progress issues. In-progress items are phases (15, 14, 11) — none conflict.
• Phase 14 (Billing Tiers & Contracts) is the parent phase and is in_progress — correct context.
• Board item #1660 (missing env vars for Stripe) is in backlog. Not a hard blocker — existing Stripe integration (webhooks_controller.rb, stripe_client.rb) is working, confirming the key is available.
• Upstream seed_tournament_attendance.rake (PR #125) already merged — creates the PlayerTournament records this task reconciles.
• Todo items are iOS/app-store related, unrelated to this ticket.

Acceptance Criteria

• 5 criteria, all testable by an agent.
• AC #1 (rake task runs audit): Clear — run bin/rails stripe:reconcile and verify output.
• AC #2 (markdown report): Clear — output covers payment gaps, orphan charges, data quirks.
• AC #3 (idempotent): Clear — re-run produces same result without duplication.
• AC #4 (orphan charge email matching): Clear — orphans with known parent emails are flagged.
• AC #5 (exclude test charges): Clear — $1 test charges from Lucas filtered out.
• Validation queries section provides concrete reproduction commands.

Blast Radius

• Low blast radius. Creates 1 new rake task file, modifies no existing files structurally.
• Data writes confined to player_tournaments.payment_status column updates (pending → paid_stripe).
• No schema migrations, no controller changes, no view changes.
• Existing StripeClient service provides reusable Stripe API patterns.
• Admin dashboard display changes explicitly out of scope (separate ticket).

Decomposition Assessment

• 2 file targets in 1 repo — under threshold.
• 5 acceptance criteria — at threshold, not over.
• Estimated agent work: <5 minutes. Single rake task creation, no schema changes, clear patterns from existing rake tasks and StripeClient.
• No decomposition needed.

Recommendation

No action needed. Both previous findings resolved. Ticket is ready for implementation.

[INFO] The arch-rails note gap is tracked as platform-wide documentation debt and does not block this ticket.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during manual audit
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present
• [x] Context — detailed, 5 categories of data inconsistency documented
• [x] File Targets — 2 modify/create, 2 do-not-touch
• [x] Feature Flag — none (appropriate for rake task)
• [x] Acceptance Criteria — 5 items, all verifiable
• [x] Test Expectations — present with run command
• [x] Constraints — 5 constraints including idempotency and secret handling
• [x] Checklist — present
• [x] Related — present
• [x] Validation Queries — bonus section with concrete reproduction commands

Traceability

• [x] story:WS-S12 label — "As an admin, I want to manage user accounts (reset passwords, view profiles) so that I can support parents directly"
• [x] story note verified — WS-S12 found in project-westside-basketball user-stories section under Admin (Marcus)
• [~] story alignment — WS-S12 is a weak match for Stripe/DB reconciliation. The ticket's user story ("I want the database to accurately reflect all Stripe payment activity and parent identities") maps more closely to WS-S9 ("track payment status per player") or WS-S33 ("bill players for tournament entry fees at team-specific rates"). The "parent identities" angle loosely connects to WS-S12 but the bulk of the work is payment reconciliation. [LABEL] Consider relabeling to story:WS-S9.
• [x] arch:rails label — present on board item
• [ ] arch note MISSING — search_notes("arch-rails") returned empty. [SCOPE] Create architecture note arch-rails for the Rails component.
• [x] Forgejo issue — #131, open

File Targets

• [x] lib/tasks/stripe_reconciliation.rake — NEW file. Directory lib/tasks/ exists with 2 existing rake files (seed_tournament_attendance.rake, tournament_email.rake). Correct location for new rake task.
• [x] app/models/player_tournament.rb — EXISTS (337 bytes). Model defines PAYMENT_STATUSES = %w[pending paid_stripe paid_cash paid_venmo waived]. The paid_stripe status referenced in AC #2 is a valid enum value. Schema has amount_cents (integer, nullable) and payment_status (string, default "pending").
• [x] Do-not-touch boundaries verified — app/views/admin/** and app/controllers/** correctly excluded from scope.

Repo Placement

OK — issue filed on ldraney/westside-basketball, all code changes are in the same repo. Single-repo ticket.

Dependencies

• Board item #1660 "Add missing env vars to rails-env k8s secret (Keycloak + Stripe + APP_URL)" is in backlog. If STRIPE_API_KEY is not set on the production pod, the rake task's StripeClient.new call (which defaults to ENV["STRIPE_API_KEY"]) will fail. However, the app already has working Stripe integration (webhooks at app/controllers/webhooks_controller.rb, payment status at app/services/stripe_client.rb), indicating the key is likely available. Not a hard blocker.
• The seed_tournament_attendance.rake task (PR #125, merged) creates the PlayerTournament records that this task reconciles. This is upstream and already done.
• No blocking in_progress items found on the board.

Acceptance Criteria

• 5 criteria, all testable by an agent.
• AC #1 (rake task runs audit): Clear — run bin/rails stripe:reconcile and verify output.
• AC #2 (tournament status update): Clear — 16 pending records with matching paid orders get updated to paid_stripe. The matching logic (player_id + amount_cents) is specified in constraints. Note: could produce false matches if a player has multiple paid orders with the same amount, but this is an edge case the implementer can guard against.
• AC #3 (markdown report): Clear — output covers payment gaps, orphan charges, data quirks.
• AC #4 (idempotent): Clear — re-run produces same result without duplication.
• AC #5 (orphan charge email matching): Clear — orphans with known parent emails are flagged.
• Validation queries section provides concrete reproduction commands for post-implementation verification. Well-structured.

Blast Radius

• Low blast radius. Creates 1 new rake task file, modifies no existing files structurally.
• Data writes are confined to player_tournaments.payment_status column updates (pending → paid_stripe).
• No schema migrations, no controller changes, no view changes.
• Existing StripeClient service (app/services/stripe_client.rb) provides Stripe API access patterns the rake task can reuse.
• The orderstatus enum values are: pending, paid, refunded, canceled — confirmed in db/schema.rb.
• The admin dashboard views that display this data are explicitly out of scope (separate ticket).

Decomposition Assessment

• 2 file targets in 1 repo — under threshold.
• 5 acceptance criteria — at threshold, not over.
• Estimated agent work: <5 minutes. Single rake task creation, no schema changes, clear patterns from existing seed_tournament_attendance.rake and StripeClient.
• No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-rails for the Rails component in pal-e-docs. The arch:rails label is used across multiple board items but has no backing documentation.
• [LABEL] Consider relabeling from story:WS-S12 to story:WS-S9. WS-S12 ("manage user accounts") is a weak fit for Stripe/DB payment reconciliation. WS-S9 ("track payment status per player") aligns directly with the ticket's purpose. If WS-S12 is kept, the rationale should be documented (parent name cleanup touches user accounts).

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, discovered during PR #122 review
• [x] Repo — ldraney/westside-basketball
• [x] User Story — As an admin (Marcus), edit fee from player detail page
• [x] Context — Three redundant report endpoints, only unique action is update_fee
• [x] File Targets — 3 to modify, 7 to delete
• [x] Feature Flag — None (appropriate for relocating existing functionality)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — Unit + integration tests, run command provided
• [x] Constraints — Clear guidance on moving action as-is, JSON response, minimal UI
• [x] Checklist — Standard PR/tests/no-unrelated
• [x] Related — project-westside-basketball, PR #122, PR #21

Traceability

• [ ] story:admin-dashboard label — NOT a recognized story code. No story:admin-dashboard entry exists in project-westside-basketball user-stories section. Closest match: story:WS-S35 ("As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier"). [LABEL] Change to story:WS-S35.
• [ ] arch note MISSING — arch-rails-app not found in pal-e-docs. [SCOPE] Create architecture note arch-rails-app for the Rails application component.
• [x] Forgejo issue — #123, open, body matches ticket title

File Targets

• [x] app/controllers/admin/players_controller.rb — verified: exists, has index and show actions, no existing update_fee
• [x] app/views/admin/players/show.html.erb — verified: exists, already displays monthly_fee in a stat card (line 21)
• [x] config/routes.rb — verified: exists, report routes on lines 20-22, monthly_fee member route on line 26 currently dispatches to roster_report#update_fee
• [x] app/controllers/admin/payments_controller.rb — verified: exists (to delete)
• [x] app/controllers/admin/roster_report_controller.rb — verified: exists, 137 lines, update_fee at line 35 (~102 lines, issue says ~80)
• [x] app/controllers/admin/delinquency_report_controller.rb — verified: exists (to delete)
• [x] app/views/admin/payments/index.html.erb — verified: exists (to delete)
• [x] app/views/admin/roster_report/index.html.erb — verified: exists (to delete)
• [x] app/views/admin/roster_report/_inline_fee_editor.html.erb — verified: exists (to delete)
• [x] app/views/admin/delinquency_report/index.html.erb — verified: exists (to delete)
• [ ] app/javascript/controllers/inline_fee_controller.js — NOT mentioned in File Targets. This Stimulus controller handles the PATCH request for fee editing. URL path (/admin/players/:id/monthly_fee) stays the same so no code change needed, but agent should know it exists to avoid breaking data attribute contracts. [BODY] Add to "Files the agent should NOT touch" section.

Repo Placement

OK — issue filed on ldraney/westside-basketball, matches ### Repo section. All affected files are in this single repo.

Dependencies

• PR #122 (admin dashboard shell with bottom tab navigation) — mentioned in Related section as "merge first" but NOT tracked with a depends: label on the board item. PR #122 is currently open. [LABEL] Add depends:121 label to board item.
• No other blocking dependencies found on the board. No active items in in_progress column overlap with this work.

Acceptance Criteria

5 criteria, all agent-verifiable:

• AC1: Tap "Edit" next to monthly fee — testable via integration test
• AC2: Fee change updates Stripe or regenerates payment link — testable via unit test with Stripe mock
• AC3: Inline success/error feedback — testable via integration test
• AC4: Report routes return 404 — testable via route assertion
• AC5: No dead files remain — testable via file existence check

Test expectations include unit and integration tests with run command bin/rails test. Complete and testable.

Blast Radius

• inline_fee_controller.js constructs URL from data attributes (this.urlValue) — route path /admin/players/:id/monthly_fee is unchanged, only controller dispatch changes. Safe.
• Admin layout (admin.html.erb) has NO nav links to report pages — no cleanup needed there.
• No path helper references (payments_path, roster_report_path, delinquency_report_path) found anywhere outside the files being deleted. Clean removal.
• No downstream consumers or sibling services affected.

Decomposition Assessment

3 files to modify + 7 files to delete = 10 files, all in 1 repo. 5 acceptance criteria (at limit, not over). Work is straightforward: move one action, add minimal UI, update one route line, delete 7 files. Estimated well under 5 minutes. No decomposition needed.

Recommendation

• [LABEL] Change story:admin-dashboard to story:WS-S35 — the user story maps to "set and manage subscription pricing on a player's detail page"
• [SCOPE] Create architecture note arch-rails-app for the westside-basketball Rails application component
• [LABEL] Add depends:121 label to board item to document the dependency on issue #121 / PR #122 (admin dashboard shell)
• [BODY] Add app/javascript/controllers/inline_fee_controller.js to "Files the agent should NOT touch" section with note: "Stimulus controller constructs URL from data attributes; route path unchanged, do not modify"

Verdict: APPROVED

Round 3 re-review. Round 2 finding (incorrect .p12 signing cert reference) has been resolved. Issue now correctly documents Xcode automatic signing with keychain-managed identity. All file targets verified. Scope is clean and appropriately sized.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #78, Sub-ticket E
• [x] Repo — ldraney/westside-basketball-ios (filed on westside-basketball, transfer note included)
• [x] User Story — platform operator wants Fastlane build+deploy via SSH
• [x] Context — SSH keychain gotcha, tmux workaround, three-stage pipeline
• [x] File Targets — 2 create targets, 2 read-only references
• [x] Feature Flag — none (build infrastructure)
• [x] Acceptance Criteria — 4 criteria
• [x] Test Expectations — 2 manual tests
• [x] Constraints — tmux, xcargs, SSH alias, dependency ordering
• [x] Checklist — standard 3 items
• [x] Related — arch note, project page, parent issue, pipeline docs

Traceability

• [x] story:WS-S34 label — "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified — WS-S34 found in project-westside-basketball user-stories section (Parent role)
• [x] arch:app-store label — App Store Billing architecture
• [x] arch note verified — arch-app-store note exists in pal-e-docs (ID 2224)
• [x] Forgejo issue — ldraney/westside-basketball#86, state: open

File Targets

• [x] fastlane/Fastfile — to create: beta + release lanes (repo does not exist yet, depends on #81; expected)
• [x] scripts/build-remote.sh — to create: SSH wrapper with tmux (repo does not exist yet; expected)
• [x] ~/macbook-ssh/connect.sh — read-only reference: verified exists at /home/ldraney/macbook-ssh/connect.sh
• [x] ~/secrets/apple-developer/AuthKey_2A6BSP3H76.p8 — read-only reference: verified exists at /home/ldraney/secrets/apple-developer/AuthKey_2A6BSP3H76.p8. Correctly described as App Store Connect API key for Fastlane API auth, NOT code signing.

Round 2 fix verified: No .p12 reference remains. Issue correctly states "Uses Xcode automatic signing (code signing identity managed by MacBook Keychain, not exported .p12)" in AC #4 and explains recovery path in Context section.

Repo Placement

OK. Issue is filed on westside-basketball because westside-basketball-ios does not exist yet (created by dependency #81). Issue includes explicit transfer note: "Transfer after Sub-ticket A completes." This is the correct approach.

Dependencies

• depends:81 — Create westside-basketball-ios repo with Turbo Native shell (board ID 1640, backlog). REQUIRED: repo must exist before any Fastlane work.
• depends:84 — Fastlane IaC for auto-renewable subscription product (board ID 1641, backlog). REQUIRED: Fastlane Appfile and initial config must exist; this ticket adds beta/release lanes to existing Fastfile.
• depends:85 — StoreKit 2 purchase flow in Turbo Native shell (board ID 1642, backlog). REQUIRED: app code must exist for build to have something to compile.
• parent:78 — iOS StoreKit subscription purchase flow + Fastlane IaC (board ID 1635, backlog, decomposed). Parent decomposition is consistent.

All dependencies are documented in the issue body (Lineage and Constraints sections) and in board labels. Dependency chain is sound and correctly ordered.

Acceptance Criteria

4 criteria, all verifiable:

• AC 1-2: Manual verification via SSH — testable once MacBook is reachable and dependencies complete
• AC 3: tmux session handling — verifiable by checking script code
• AC 4: Xcode automatic signing — verifiable by confirming no .p12 export, no manual cert config

Test expectations are manual (appropriate for SSH-based iOS build pipeline). Commands are realistic.

Blast Radius

Low. This is build infrastructure isolated to the iOS pipeline. The macbook-ssh/docs/ios-pipeline.md confirms the tmux SSH pattern (Stage 3 shows ssh macbook "cd ~/{app}-ios && fastlane beta"). The build-remote.sh script is specific to westside-basketball-ios. No sibling services affected. No shared Fastlane config to break.

Decomposition Assessment

No decomposition needed. 2 file targets in 1 repo, 4 acceptance criteria, estimated agent work well under 5 minutes. Single-pass ticket.

Recommendation

No action needed. Scope is solid, all file targets verified, traceability complete, dependencies documented and correctly ordered. Round 2 finding (incorrect .p12 reference) has been resolved.

Verdict: APPROVED

Round 3 re-review (2026-06-27). Round 2 found depends:87 missing from board labels. Label has been added. All prior findings resolved.

Template Completeness

• [x] Type — Spike
• [x] Lineage — "Gap discovered during Sprint 6 decomposition"
• [x] Repo — ldraney/westside-basketball-ios (filed on westside-basketball temporarily because iOS repo doesn't exist yet)
• [x] Question — Clear top-level yes/no question with 5 sub-questions
• [x] Context — Present, describes WKWebView vs Safari cookie isolation risks
• [x] Deliverables — 4 items, all concrete artifacts
• [x] Time-box — 2 hours with clear exit criteria
• [x] Constraints — Present, documents prerequisites and test requirements
• [x] Related — References #81, #154, #87, project page, story
• [x] Checklist — Present (generic spike checklist, acceptable)

All required spike template sections present and well-formed.

Traceability

• [x] story:WS-S38 label — "As a parent, I want to create an account, log in through the iOS app, and be routed to my subscription status page so I can manage payments and see where I stand"
• [x] story note verified — WS-S38 found in project-westside-basketball user-stories section (Parent role)
• [x] arch:app-store label — App Store Billing component
• [x] arch note verified — arch-app-store exists in pal-e-docs (note ID 2224, "Architecture: App Store Billing")
• [x] Forgejo issue — ldraney/westside-basketball#88, open

File Targets

N/A — Spike type. Output is docs + follow-up tickets, not code. The deliverable is a docs/{topic}.md file. No file targets to verify.

Repo Placement

Acceptable. Issue is filed on westside-basketball but states the work targets westside-basketball-ios. The iOS repo does not exist yet (creation tracked by #81). Filing on the parent repo is the correct interim approach and is explicitly documented in the issue body.

Dependencies

• depends:81 (board #1640) — "Create westside-basketball-ios repo with Turbo Native shell" — backlog, 2pts. HARD prerequisite: cannot test iOS login without the iOS app.
• depends:87 (board #1646) — "Role-based routing: admin vs player post-login redirect" — backlog, 3pts. HARD prerequisite: spike needs post-login redirect to verify end-to-end flow. Round 2 finding resolved — label now present on board item.
• depends:154 — Keycloak player self-registration (pal-e-services#154) — open. HARD prerequisite: cannot test player login without player self-registration.

All three dependencies are in backlog. This spike cannot begin until at least #81 and #154 are complete.

Acceptance Criteria

Spike deliverables are clear and verifiable:

• Document whether login works in WKWebView — binary yes/no, verifiable
• If works: document config needed — verifiable by checking docs file
• If fails: document failure mode + effort estimate — verifiable by checking docs file
• Create follow-up tickets — verifiable by checking Forgejo

Time-box (2 hours) and escalation path are well-defined.

Blast Radius

Low. Investigation spike — no code changes. Findings may affect approach for subsequent arch:app-store tickets (#66 subscription UI, #78 StoreKit purchase flow, #87 role-based routing). If WKWebView login fails, the fallback (ASWebAuthenticationSession) would add complexity to the iOS shell architecture.

Decomposition Assessment

No decomposition needed. Single investigation task, 2pts, docs-only output, 2-hour time-box. Well within single-agent capacity.

Recommendation

No action needed. All prior findings resolved:

• Round 1 [SCOPE] "Create architecture note arch-app-store" — false positive. Note exists (ID 2224).
• Round 2 [LABEL] "Add depends:87 to board item 1647" — resolved. Label now present.

Review History

Round	Date	Verdict	Finding	Resolution
1	2026-06-27	NEEDS_REFINEMENT	[SCOPE] arch-app-store note missing; [LABEL] depends:87 missing	arch note was false positive; label still missing
2	2026-06-27	NEEDS_REFINEMENT	[LABEL] depends:87 still missing from board item	Label added
3	2026-06-27	APPROVED	None	All findings resolved

Verdict: APPROVED

Round 3 re-review. Both round 1 and round 2 findings have been addressed. Scope is solid.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #66
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- well-formed (admin viewing player list)
• [x] Context -- explains existing Stripe badge pattern and dependency on #79
• [x] File Targets -- 3 modify targets + 2 do-not-touch entries
• [x] Feature Flag -- none (admin-only UI)
• [x] Acceptance Criteria -- 2 items
• [x] Test Expectations -- 2 unit tests + run command
• [x] Constraints -- 4 constraints including enum alignment
• [x] Checklist -- present
• [x] Related -- arch-app-store, project page, parent, dependency

Traceability

• [x] story:WS-S36 label -- "As an admin, I want to see Apple subscription lifecycle states per player"
• [x] story note verified -- found in project-westside-basketball user-stories section (Admin/Marcus list)
• [x] arch:app-store label -- App Store Billing component
• [x] arch note verified -- arch-app-store note exists in pal-e-docs (ID 2224)
• [x] Forgejo issue -- ldraney/westside-basketball#80, open

File Targets

• [x] app/helpers/application_helper.rb -- verified: exists (22 lines), has subscription_badge_variant and subscription_badge_label helper patterns to parallel
• [x] app/views/admin/players/index.html.erb -- verified: exists (112 lines), uses badge helpers at lines 77-78 (desktop) and 94-95 (mobile cards)
• [x] app/assets/stylesheets/application.css -- verified: exists (1907 lines), has status-badge--paid (green), --unpaid (red), --partial (yellow), --active (red) but NO orange or gray badge variants. Round 2 correctly identified this gap.
• [x] app/models/player.rb -- correctly marked do-not-touch (model changes in #79)
• [x] app/views/admin/players/show.html.erb -- correctly marked do-not-touch (does not exist yet, detail page is sub-ticket C/#82)

Enum Alignment (critical cross-ticket check)

• [x] Issue #80 enum values: subscribed, expired, billing_retry, grace_period, revoked, none
• [x] Issue #79 (dependency) enum values: subscribed, expired, billing_retry, grace_period, revoked, none
• [x] arch-app-store Data Model: subscribed, grace_period, billing_retry, expired, revoked, none
• [x] All three sources are aligned

Repo Placement

Correct. Issue filed on ldraney/westside-basketball, all file targets are in the same repo. Single-repo change.

Dependencies

• [x] depends:79 (model+migration) -- correctly documented. #79 must merge first to provide the apple_subscription_status enum on the Player model. Board item #1636 is in backlog.
• [x] parent:66 (Subscription UI parent) -- correctly documented. This is sub-ticket B of 4.
• No circular dependencies. No undocumented dependencies.

Acceptance Criteria

2 criteria, both agent-verifiable:

• AC1: Admin list page shows Apple badge -- verifiable via view inspection and integration test
• AC2: Badge colors follow semantic convention -- verifiable via unit tests on helper methods

Test file test/helpers/application_helper_test.rb exists with 10 existing tests for Stripe badge helpers. Run command is valid.

Blast Radius

Low. No existing Apple subscription references in the codebase. Changes are additive -- new helpers alongside existing ones, new CSS classes alongside existing ones, new column in existing table. Existing Stripe badge behavior is untouched.

Decomposition Assessment

No decomposition needed. 3 file targets in 1 repo, 2 acceptance criteria, estimated agent work under 5 minutes. Well-scoped for a single pass.

Recommendation

No action needed. Scope is complete and ready for implementation after #79 merges.

Verdict: APPROVED

Round 3 re-review. Round 2 found enum value mismatch (active/in_billing_retry/in_grace_period vs arch note's subscribed/billing_retry/grace_period). Issue body has been updated. All values now align with arch-app-store.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #66
• [x] Repo -- ldraney/westside-basketball
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag -- none (internal model change, correct)
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S35 label -- "As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier"
• [x] story note verified -- WS-S35 found in project-westside-basketball user-stories section (Admin list, block 45874)
• [x] arch:app-store label -- App Store Billing architecture
• [x] arch note verified -- arch-app-store exists in pal-e-docs (note ID 2224, slug "arch-app-store")
• [x] Forgejo issue -- ldraney/westside-basketball#79, state: open

File Targets

• [x] app/models/player.rb -- verified: exists (14 lines), currently has no enum declarations. Migration will add apple_subscription_status enum, model will need enum declaration added.
• [x] db/migrate/*_add_apple_subscription_to_players.rb -- new file. db/migrate/ directory does not exist yet (schema was loaded from SQL dump, not migrations). Agent will create the directory. Acceptable.
• [x] test/models/player_test.rb -- verified: exists (19 lines), has association tests. New enum/field tests will be added.

Enum Value Alignment (Round 2 Fix Confirmed)

• [x] Issue AC enum values: subscribed, expired, billing_retry, grace_period, revoked, none
• [x] Issue File Targets enum values: subscribed/expired/billing_retry/grace_period/revoked/none
• [x] arch-app-store enum values: subscribed, grace_period, billing_retry, expired, revoked, none
• [x] All three match (order differs, which is inconsequential for PostgreSQL enum creation)

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets are in that repo. Single-repo change.

Dependencies

• Parent: #66 (Subscription UI -- 3-page arch). This ticket is sub-ticket A of 4.
• Upstream: #65 (App Store webhook) provides data that populates these fields, but is not a blocker for the model+migration work itself.
• Downstream: Board items 1637, 1638, 1639 all carry depends:79 -- this ticket unblocks the admin list badges (#80), admin detail UI (#82), and player-facing status page (#83).
• No blocking dependencies -- this ticket can proceed independently.

Acceptance Criteria

4 AC, all testable by an agent:

• [x] Enum values verifiable via Player.apple_subscription_statuses in Rails console or unit test
• [x] Column existence verifiable via schema inspection or model test
• [x] Additive check verifiable by confirming existing subscription_status enum and Stripe columns unchanged
• [x] Reversibility verifiable via rails db:migrate:down

Blast Radius

Low. The existing subscription_status enum (subscriptionstatus type: active/past_due/canceled/none) is used in 6+ files (delinquency_report_controller, roster_report_controller, webhooks_controller, admin/players/index view, application_helper). The ticket explicitly states NOT to touch these. The new apple_subscription_status is a separate PostgreSQL enum type with different values. No overlap or conflict. The expires_at column name could potentially conflict with OAuth token handling in gmail_client.rb, but that uses a local variable, not a Player column -- no conflict.

Decomposition Assessment

3 file targets, 1 repo, 4 AC. Well within the 5-minute rule. No decomposition needed.

Recommendation

No action needed.

Verdict: APPROVED

Re-review (round 2) of pal-e-services#154 after round 1 refinements. Issue body is well-scoped and addresses all prior feedback. Two minor file target clarifications noted below but neither blocks implementation.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- gap discovered during Sprint 6 decomposition
• [x] Repo -- ldraney/pal-e-services
• [x] User Story -- WS-S38
• [x] Context -- thorough, includes two options with recommendation
• [x] File Targets -- 3 targets listed (see verification below)
• [x] Feature Flag -- none (correct for IaC-only change)
• [x] Acceptance Criteria -- 5 criteria, all testable
• [x] Test Expectations -- 3 tests + terraform plan command
• [x] Constraints -- 5 constraints including blast radius (SMTP), dependency on #152
• [x] Checklist -- standard 3 items
• [x] Related -- 6 references including arch note, downstream tickets, dependency

Traceability

• [x] story:WS-S38 label -- "As a parent, I want to create an account, log in through the iOS app, and be routed to my subscription status page so I can manage payments and see where I stand"
• [x] story note verified -- WS-S38 found in project-westside-basketball user-stories section under Parent
• [x] arch:app-store label -- App Store Billing architecture
• [x] arch note verified -- arch-app-store note exists in pal-e-docs (ID 2224, slug "arch-app-store")
• [x] Forgejo issue -- pal-e-services#154, state: open

File Targets

• [x] terraform/k3s.tfvars -- verified: file is gitignored (actual config lives in ~/secrets/pal-e-services/k3s.tfvars), but this is the correct target. The .example file is tracked in repo. Agent will modify the real tfvars. The westside-basketball realm entry already exists in the live config with roles [admin, coach, player]. Setting registration_allowed = true here is correct.
• [x] terraform/keycloak.tf -- verified: realm resource at line 28 already wires registration_allowed and reset_password_allowed from the variable schema (lines 36, 39). No changes needed to keycloak.tf itself unless adding the default_roles resource. Minor clarification: the registration settings change is in tfvars, not keycloak.tf.
• [~] keycloak_default_roles resource -- CLARIFICATION: This resource does not currently exist in keycloak.tf. The mrparkers/keycloak v5 provider does support keycloak_default_roles as a resource type, so it can be created. The issue frames it as an existing resource to modify, when it is actually a new resource to add. The implementing agent should add a new keycloak_default_roles resource block to keycloak.tf that assigns the player role as default for the westside-basketball realm. This is a minor framing issue, not a blocker -- the intent is clear and the path forward is unambiguous.

Repo Placement

Correct. Issue is filed on pal-e-services, and all file targets (terraform/k3s.tfvars, terraform/keycloak.tf) are in pal-e-services. Single-repo change.

Dependencies

• Upstream: pal-e-services#152 (drop stale basketball DB role + update Keycloak westside-ror references) -- currently OPEN. Issue correctly identifies this as a prerequisite. #152 cleans up stale westside-ror references that could conflict with realm changes. Dependency is documented in the Constraints section.
• Downstream: Two board items depend on #154:
  • Board item #1646 (depends:154,depends:83) -- 3pts, backlog, story:WS-S38
  • Board item #1647 (depends:81,depends:154) -- 2pts, backlog, spike, story:WS-S38

Acceptance Criteria

All 5 criteria are testable by an agent:

• AC1 (self-reg enabled) -- verifiable via terraform plan output showing registration_allowed = true
• AC2 (default player role) -- verifiable via terraform plan showing new keycloak_default_roles resource with player role
• AC3 (registration page renders) -- requires manual verification post-apply (theme already exists)
• AC4 (existing admin unaffected) -- verifiable via terraform plan showing no changes to existing users
• AC5 (reset_password decision) -- issue asks agent to decide; the Constraints section already answers this: do NOT enable until SMTP is resolved

Blast Radius

Issue proactively addresses blast radius in Constraints section: SMTP placeholder password means email verification and password reset will not work. This is the correct call -- scope is limited to enabling self-registration without email-dependent features.

Other realms (e.g., landscaping-assistant) are unaffected -- changes are scoped to the westside-basketball realm entry in k3s.tfvars only. The for_each pattern in keycloak.tf isolates realms.

Decomposition Assessment

No decomposition needed:

• 2 file targets in 1 repo (under threshold of 3 files / 2 repos)
• 5 acceptance criteria (at threshold but manageable)
• Estimated agent work: ~3 minutes (set tfvars value + add one new resource block + terraform plan)
• Single-repo, single-concern change

Recommendation

No action needed. Ticket is APPROVED for implementation.

Minor notes for the implementing agent (not blockers):

• The keycloak_default_roles resource does not exist yet in keycloak.tf -- create it as a new resource block, do not look for an existing one to modify
• Set reset_password_allowed = false explicitly per the SMTP constraint
• Ensure #152 has merged before starting this work

Verdict: NEEDS_REFINEMENT

Re-review (round 2) of board item #1644. Round 1 had two findings: one [SCOPE] (arch note missing) and one [BODY] (signing identity ambiguity). The [SCOPE] finding is resolved. The [BODY] finding remains unaddressed.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #78, Sub-ticket E, dependency chain documented
• [x] Repo -- ldraney/westside-basketball-ios (to be created by Sub-ticket A). Filed on westside-basketball with explicit transfer note.
• [x] User Story -- present, well-formed (platform operator perspective)
• [x] Context -- thorough, includes tmux keychain gotcha, three-stage pipeline, MacBook SSH details
• [x] File Targets -- 3 files to create, 2 reference paths listed
• [x] Feature Flag -- None (build infra, acceptable)
• [x] Acceptance Criteria -- 4 criteria
• [x] Test Expectations -- 2 manual tests
• [x] Constraints -- 5 constraints listed
• [x] Checklist -- standard 3-item
• [x] Related -- project, parent issue, pipeline docs

All template sections present.

Traceability

• [x] story:WS-S34 label -- "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified -- found in project-westside-basketball user-stories section (Parent role)
• [x] arch:app-store label -- architecture note arch-app-store EXISTS (note ID 2224, slug "arch-app-store", title "Architecture: App Store Billing"). Covers Apple subscription billing architecture, dependency chain, data model, and key decisions. Round 1 false positive resolved.
• [x] Forgejo issue -- ldraney/westside-basketball#86, state: open

All three traceability legs verified.

File Targets

• [x] fastlane/Fastfile -- to be created (extends Sub-ticket B output). Target repo does not exist yet (expected; depends on #81). Acceptable for a dependent ticket.
• [x] scripts/build-remote.sh -- to be created. Path is reasonable.
• [x] scripts/import-ci-keychain.sh -- to be created. Path is reasonable.
• [x] ~/macbook-ssh/connect.sh -- verified: exists at /home/ldraney/macbook-ssh/connect.sh (32 bytes)
• [ ] ~/secrets/apple-developer/ -- STILL UNRESOLVED from R1: Directory exists and contains .env (114 bytes) and AuthKey_2A6BSP3H76.p8 (257 bytes, App Store Connect API key). No .p12 certificate found. Issue Context still references "The signing cert (dev.p12) may need reimporting after MacBook reboot via import-ci-keychain.sh" -- but no such cert exists on disk. The import-ci-keychain.sh script and File Targets reference need clarification on whether signing uses a .p12 cert (to be created/exported later) or Xcode automatic signing with API key (.p8) authentication.

Repo Placement

OK. Issue is filed on ldraney/westside-basketball because the target repo (westside-basketball-ios) does not exist yet. Explicitly documented with transfer plan. Forgejo API confirms iOS repo returns 404.

Dependencies

• depends:81 -- #81 "Create westside-basketball-ios repo with Turbo Native shell" (board item 1640, backlog, open) -- REQUIRED: repo must exist
• depends:84 -- #84 "Fastlane IaC for auto-renewable subscription product" (board item 1641, backlog, open) -- REQUIRED: Fastfile base must exist before adding beta/release lanes
• depends:85 -- #85 "StoreKit 2 purchase flow in Turbo Native shell" (board item 1642, backlog, open) -- REQUIRED: app code must exist before building
• parent:78 -- #78 parent issue (board item 1635, backlog, decomposed)

All three dependencies in backlog and open. Dependency chain correctly documented in both board labels and issue body. This ticket is last in the chain (Sub-ticket E) -- it cannot move to in_progress until all three dependencies are complete.

Acceptance Criteria

4 criteria, all manually verifiable. Infrastructure/pipeline work has no automated test path -- manual verification via SSH to MacBook and checking App Store Connect is the correct approach. Test expectations correctly specify manual verification (run build-remote.sh, check TestFlight). Testable and complete.

Blast Radius

Low. Creates new files in a not-yet-existing repo. No existing code modified. No other services use Fastlane or iOS build infrastructure. The SSH/tmux pattern is isolated to the iOS pipeline. No sibling services affected. No similar patterns elsewhere in the codebase (confirmed: no Fastfile, Appfile, Matchfile, build-remote.sh, or import-ci-keychain.sh found anywhere in ~/repos).

Minor note: The pipeline reference docs (~/macbook-ssh/docs/ios-pipeline.md line 213) show direct SSH (ssh macbook "cd ~/{app}-ios && fastlane beta"), while this issue correctly identifies that direct SSH fails due to keychain restrictions and uses tmux instead. The issue's approach is correct; the reference docs may need updating when this ticket ships.

Decomposition Assessment

3 file targets in 1 repo, 4 acceptance criteria. Estimated agent work well under 5 minutes once dependencies are met. No decomposition needed.

Round 1 Finding Resolution

Finding	Tag	Status
Create architecture note arch-app-store	[SCOPE]	RESOLVED -- arch-app-store exists (note ID 2224)
Clarify signing identity (.p12 vs .p8)	[BODY]	NOT RESOLVED -- issue Context still references dev.p12; only .p8 exists on disk

Recommendation

• [BODY] Clarify signing identity in issue Context and File Targets. The Context section references "The signing cert (dev.p12)" and File Targets lists ~/secrets/apple-developer/ as containing "signing certs and API key". In reality, the directory contains only AuthKey_2A6BSP3H76.p8 (API key) and .env. Either: (a) state that the .p12 cert will be exported from the MacBook Keychain as part of Stage 2 signing setup and does not yet exist on the archbox, or (b) if using Xcode automatic signing with API key authentication, remove the .p12 reference and update import-ci-keychain.sh's purpose accordingly.

Verdict: APPROVED

Re-review of board item #1641 (Forgejo issue ldraney/westside-basketball#84). Round 1 refinements have been applied. All checks pass.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #78, Sub-ticket B
• [x] Repo — ldraney/westside-basketball-ios (to be created by Sub-ticket A)
• [x] User Story — present, well-formed
• [x] Context — thorough: iOS-only subscriptions decision, Fastlane IaC mandate, Apple app creation constraint documented
• [x] File Targets — 3 files to create, 1 read-only reference
• [x] Feature Flag — none (infrastructure, correct)
• [x] Acceptance Criteria — 4 criteria, all testable
• [x] Test Expectations — 2 manual tests specified
• [x] Constraints — 4 constraints listed
• [x] Checklist — present
• [x] Related — links to parent #78 and dependency #65

Traceability

• [x] story:WS-S34 label — "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified — found in project-westside-basketball user-stories section under Parent
• [x] arch:app-store label — App Store Billing component
• [x] arch note verified — arch-app-store note exists in pal-e-docs (note ID 2224). Documents dependency chain, data model, and key decisions.
• [x] Forgejo issue — ldraney/westside-basketball#84, state: open
• [x] parent:78 label — parent issue (iOS StoreKit subscription purchase flow + Fastlane IaC)

File Targets

• [x] fastlane/Fastfile — to be created in new repo. Cannot verify existence (repo not created yet). Correct: depends:81 gates this.
• [x] fastlane/Appfile — to be created in new repo. Same as above.
• [x] fastlane/metadata/subscription_config.json — to be created in new repo. Same as above.
• [x] ~/secrets/apple-developer/api_key.json — read-only reference. Does NOT exist yet on disk. Acceptable: this secret is provisioned by sibling ticket #1643 (Terraform: App Store Connect API key secret). The Fastlane config references the path; the key needs to exist at runtime, not at config-write time.

Repo Placement

OK with caveat. Issue is filed on westside-basketball because westside-basketball-ios does not exist yet. Issue body explicitly notes: "Filed on westside-basketball because the iOS repo does not exist yet. Transfer after Sub-ticket A completes." This is correct — the repo is created by #81 (board item 1640), which is a declared dependency.

Dependencies

• depends:81 (board item 1640, "Create westside-basketball-ios repo with Turbo Native shell") — backlog, open. This ticket's files all live in the iOS repo. Correctly declared.
• depends:65 (board item 1610, "Configure App Store Connect subscription product and billing grace period") — next_up, sprint:6, open. The v2 notifications URL in Fastlane config points to this webhook endpoint. Correctly declared.
• Undeclared soft dependency: Board item 1643 ("Terraform: App Store Connect API key secret") provisions the API key referenced in the read-only file target. However, this is a soft dependency — the Fastlane config can reference the key path without the key existing at config-write time. The key just needs to exist at runtime. Not blocking.
• parent:78 (board item 1635, "iOS StoreKit subscription purchase flow + Fastlane IaC") — backlog, decomposed. Correctly declared.

Acceptance Criteria

4 acceptance criteria, all verifiable:

• [x] Fastfile lane with API key auth — agent can verify file contents
• [x] Appfile with correct identifiers — agent can verify literal values (team_id HAY64YD5PX)
• [x] Subscription product config with 16-day grace period — agent can verify JSON structure
• [x] Server Notifications v2 URL configured — agent can verify URL points to Rails webhook

All criteria are concrete and machine-verifiable. No ambiguity.

Blast Radius

Low. This ticket creates new files in a new repo. No existing code is modified. The only external coupling is the v2 notifications URL pointing to the Rails webhook endpoint (#65), which is a read-only reference. No sibling services are affected.

Decomposition Assessment

No decomposition needed. 3 file targets in 1 repo. 4 acceptance criteria. Estimated agent time well under 5 minutes. Single-pass work.

Recommendation

No action needed. Ticket is well-scoped, dependencies are declared, traceability is complete, and the work fits in a single agent pass.

Note: The soft dependency on the API key secret (#1643) is not blocking. The agent can write the config referencing the key path; the key just needs to exist before runtime. No label change required.

Verdict: READY

Round 2 re-review after round 1 refinements.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #66, sub-ticket C of 4
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present, well-formed
• [x] Context — present, explains dependency chain clearly
• [x] File Targets — present with modify and do-not-touch lists
• [x] Feature Flag — "none" with rationale (admin-only UI)
• [x] Acceptance Criteria — 2 items, clear and testable
• [x] Test Expectations — 2 integration tests, run command provided
• [x] Constraints — present, documents all dependencies and patterns
• [x] Checklist — present
• [x] Related — present, links parent, dependency, and sub-ticket

Traceability

• [x] story:WS-S35 label — "As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier"
• [x] story note verified — WS-S35 found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:app-store label — App Store Billing architecture component
• [x] arch note verified — arch-app-store note exists (ID 2224, slug "arch-app-store"), covers webhook endpoint, subscription UI, iOS StoreKit, data model, and dependency chain
• [x] Forgejo issue — ldraney/westside-basketball#82, state: open

File Targets

• [x] app/views/admin/players/show.html.erb — does NOT exist yet (confirmed: only index.html.erb in that directory). Expected because #58 creates it. Ticket correctly documents this dependency.
• [x] app/models/player.rb — correctly listed as do-not-touch. No apple_subscription fields exist yet; those come from #79 (Apple subscription model + migration).
• [x] app/views/admin/players/index.html.erb — correctly listed as do-not-touch (list page badges are in a sibling sub-ticket).

Repo Placement

OK — issue filed on ldraney/westside-basketball, all file targets are in the same repo. Single-repo change.

Dependencies

• #58 (Admin player detail page — product payment matrix and contact info) — board item ID 1609, column: next_up, sprint:6. Creates show.html.erb and the show controller action. Must merge first. Currently admin/players routes only expose :index.
• #79 (Apple subscription model + migration) — board item ID 1636, column: backlog. Adds apple_subscription_status enum, original_transaction_id, expires_at, grace_period_expires_at to Player model. Must merge first. Currently Player model has zero Apple fields.
• #66 (Subscription status on admin player detail page) — board item ID 1611, column: next_up, sprint:6. Parent ticket (decomposed). This is sub-ticket C of 4.
• Both dependencies documented in the issue body (Context and Constraints sections) and in board labels (depends:58,depends:79). Dependency chain is consistent.

Acceptance Criteria

2 acceptance criteria — both agent-verifiable:

• "Admin detail page shows Apple subscription badge with status, expiry date, and grace period info" — verifiable via integration test rendering the view with fixture data.
• "Admin detail page includes pricing management section for Apple subscriptions" — verifiable via integration test checking for the section DOM element.

Test command is valid: bundle exec rails test test/controllers/admin/players_controller_test.rb — the test file exists at that path.

Blast Radius

• Existing Stripe subscription helpers in application_helper.rb (subscription_badge_variant, subscription_badge_label) may need parallel Apple equivalents. The ticket scope (adding Apple badge + pricing to the detail page) is narrow and should not conflict.
• No downstream consumers of the detail page exist yet (page is being created by #58).
• Delinquency report controller references subscription_status (Stripe) — this ticket does not touch it. No blast radius concern.

Decomposition Assessment

1 file target to modify, 2 acceptance criteria, single repo. Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

No action needed. Scope is solid: all 12 template sections present, traceability complete (story note WS-S35 and arch note arch-app-store both verified in pal-e-docs), dependencies correctly documented and reflected in board labels, file targets accurately describe the current codebase state. The "sub-ticket A" reference maps correctly to #79 via depends:79. Points (1) are appropriate — adding UI elements to an existing page with existing model fields once both dependencies merge.

Verdict: APPROVED

Re-review (round 2) after round 1 refinements. All sections complete, all file targets verified, traceability intact. Scope is solid for a single agent pass.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Gap discovered during Sprint 6 decomposition
• [x] Repo — ldraney/westside-basketball
• [x] User Story — WS-S38
• [x] Context — explains current single-path redirect, need for role-based routing
• [x] File Targets — 4 files listed
• [x] Feature Flag — none (appropriate — internal routing, not user-visible toggle)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — 4 integration tests + run command
• [x] Constraints — 3 constraints listed
• [x] Checklist — present
• [x] Related — lists both dependencies and project page

Traceability

• [x] story:WS-S38 label — "As a parent, I want to create an account, log in through the iOS app, and be routed to my subscription status page"
• [x] story note verified — found in project-westside-basketball user-stories section (Parent subsection)
• [x] arch:app-store label — App Store Billing architecture
• [x] arch note verified — arch-app-store note exists in pal-e-docs (note ID 2224)
• [x] Forgejo issue — westside-basketball#87, state: open

File Targets

• [x] app/controllers/application_controller.rb — verified: exists, includes Authentication concern, has TENANT_SLUG constant
• [x] app/controllers/sessions_controller.rb — verified: exists, contains OIDC callback (lines 11-33), already extracts realm roles (lines 17-18), currently redirects all users to root_path (line 32). This is the exact line that needs role-based branching.
• [x] config/routes.rb — verified: exists, no /status route yet. Admin namespace exists (lines 19-28). Player route needs to be added.
• [x] app/controllers/admin/base_controller.rb — verified: exists, already has require_role :admin (line 5). Admin guard is already in place — no changes needed here.

Repo Placement

OK. Issue filed on westside-basketball, all file targets are in westside-basketball. Single-repo change.

Dependencies

• depends:154 — pal-e-services#154 (Keycloak player self-registration). Board item 1645, backlog. Must be done first so player accounts exist in Keycloak.
• depends:83 — westside-basketball#83 (Player-facing subscription status page). Board item 1639, backlog. Must be done first so /status has a page to render. Note: #83 itself depends on #79 (Apple subscription model + migration) and is a child of #66.
• Both dependencies are correctly documented in the issue body Related section and in the board item labels.

Acceptance Criteria

5 ACs, all testable via integration tests. Each maps to a specific behavior that can be verified with a test login flow. The test expectations section lists matching integration tests for each AC. Run command (bundle exec rails test) is valid. No missing criteria — the ticket covers both the redirect logic and the authorization guards.

Blast Radius

Low. The Authentication concern already has require_role and current_user_has_role? methods. Admin::BaseController already uses require_role :admin. The primary change is adding a role-based branch in SessionsController#create (line 32) and adding a /status route + controller. No existing auth behavior needs to change — admin flow stays identical.

Decomposition Assessment

4 file targets in 1 repo. 5 acceptance criteria. Estimated agent work well under 5 minutes — the auth infrastructure (role extraction, require_role) already exists. No decomposition needed.

Recommendation

No action needed. Scope is complete and verified.

Verdict: READY

Re-review (round 2) of board item #1643 (pal-e-services#153). All sections present, traceability complete, file targets verified, scope fits a single agent pass.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of westside-basketball#78
• [x] Repo — ldraney/pal-e-services
• [x] User Story — present
• [x] Context — present, clear motivation (API key for receipt validation + Fastlane auth)
• [x] File Targets — present with modify and do-not-touch lists
• [x] Feature Flag — None (infrastructure, appropriate)
• [x] Acceptance Criteria — 3 items
• [x] Test Expectations — 2 items
• [x] Constraints — present (pattern, git safety, namespace)
• [x] Checklist — present
• [x] Related — present (arch note, project, parent, consumer)

Traceability

• [x] story:WS-S34 label — "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified — found in project-westside-basketball user-stories section (Parent list)
• [x] arch:app-store label — App Store Billing architecture
• [x] arch note verified — arch-app-store note exists in pal-e-docs (ID 2224, slug "arch-app-store")
• [x] Forgejo issue — ldraney/pal-e-services#153, open

File Targets

• [x] terraform/main.tf or terraform/services.tf — verified: both exist. Existing kubernetes_secret_v1.westside_rails_env in services.tf is the closest analog (standalone per-service secret with hardcoded namespace reference). Agent should follow that pattern.
• [x] terraform/k3s.tfvars — verified: file is gitignored (sensitive), k3s.tfvars.example exists as the tracked template. Agent will need to update both the real tfvars and the example.
• [x] Do-not-touch list correct: Fastlane config (westside-basketball-ios) and Rails webhook code (westside-basketball#65) are in other repos.

Repo Placement

Correct. The Apple API key is infrastructure managed by pal-e-services Terraform. The consuming code lives in westside-basketball (Rails) and westside-basketball-ios (Fastlane), both separate repos as documented.

Dependencies

• No depends: label on board item #1643 — correct, this ticket has no upstream blockers. It provisions infrastructure that downstream tickets consume.
• Board item #1641 (Fastlane IaC) has depends:65 and is a sibling under parent:78, but does not depend on this ticket directly (Fastlane reads from local filesystem via SSH, per arch-app-store).
• westside-basketball#65 (webhook endpoint) consumes this secret at runtime — documented in Related section.

Acceptance Criteria

3 ACs, all verifiable by an agent:

• AC1: Terraform resource defines K8s secret — verifiable via code inspection
• AC2: Secret in westside-basketball namespace — verifiable via namespace reference in code
• AC3: terraform plan succeeds — verifiable via command execution

Test expectations (plan + kubectl) are real and executable. No missing criteria.

Blast Radius

Low. No other services need Apple Developer credentials. The secret is scoped to the westside-basketball namespace. Existing secret patterns (westside_rails_env, harbor_creds, sops_age_key) are unaffected. The new variable declarations in variables.tf and values in k3s.tfvars add new entries without modifying existing ones.

Decomposition Assessment

No decomposition needed. 1-2 file targets (services.tf + variables.tf + k3s.tfvars), 3 acceptance criteria, estimated agent work ~2-3 minutes. Well within the 5-minute rule.

Recommendation

No action needed. Scope is solid for agent execution.

Verdict: APPROVED

Re-review after round 1 refinements. All sections complete, traceability verified, scope is tight and well-defined for a single agent pass.

Template Completeness

• [x] Type (Feature)
• [x] Lineage (child of #78)
• [x] Repo (ldraney/westside-basketball-ios -- new repo)
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag (none -- correct for repo bootstrap)
• [x] Acceptance Criteria (4 items)
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S34 label -- "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified -- found in project-westside-basketball user-stories section (Parent role)
• [x] arch:app-store label -- App Store Billing architecture
• [x] arch note verified -- arch-app-store note exists (ID 2224) with components, data model, and dependency chain
• [x] Forgejo issue -- ldraney/westside-basketball#81, state: open
• [x] parent:78 label -- parent issue documented in Lineage section

File Targets

New repo -- files do not exist yet (expected). Template repo ldraney/landscaping-assistant-ios confirmed to exist on Forgejo with matching structure:

• [x] CLAUDE.md -- per first-PR pattern (constraint documented)
• [x] docs/ -- per first-PR pattern (constraint documented)
• [x] .xcodeproj/ or project.yml -- template repo has both (XcodeGen generates xcodeproj from project.yml). Issue correctly lists both options.
• [x] SceneDelegate.swift -- template has LandscapingAssistant/SceneDelegate.swift, maps to westside-basketball-ios/SceneDelegate.swift
• [x] AppDelegate.swift -- template has LandscapingAssistant/AppDelegate.swift
• [x] Info.plist -- template has LandscapingAssistant/Info.plist

Repo Placement

OK. Issue is filed on westside-basketball because westside-basketball-ios does not exist yet. Issue body explicitly notes: "Transfer this issue to westside-basketball-ios after repo creation." Confirmed westside-basketball-ios does not exist on Forgejo (404). This is correct -- this ticket creates it.

Dependencies

No upstream blockers -- #81 is a leaf dependency (nothing blocks it). Four downstream items depend on #81:

• #1641 (Fastlane IaC for subscription product) -- depends:81, depends:65
• #1642 (StoreKit 2 purchase flow) -- depends:81, depends:84
• #1644 (Fastlane SSH build pipeline) -- depends:81, depends:84, depends:85
• #1647 (spike, story:WS-S38) -- depends:81, depends:154

Dependencies are correctly modeled on the board. #81 is the foundation for the entire iOS work stream.

Acceptance Criteria

4 criteria, all verifiable:

• [x] Repo exists with CLAUDE.md and docs/ -- agent-verifiable via Forgejo API
• [x] Xcode project builds for iOS 17+ simulator -- verifiable via xcodebuild command (documented in Test Expectations)
• [x] App launches and loads westsidekingsandqueens.com -- manual verification required (acceptable for iOS)
• [x] Bundle ID follows convention -- agent-verifiable by reading Info.plist

Blast Radius

Low. New repo creation with no changes to existing code. The Rails app (westsidekingsandqueens.com) is only loaded via URL -- no Rails-side changes required. Template repo (landscaping-assistant-ios) is read-only reference, not modified.

Decomposition Assessment

No decomposition needed. 4 AC, 1 repo (new), estimated agent work under 5 minutes. Single-pass ticket.

Recommendation

No action needed.

Verdict: APPROVED

Re-review of board item #1642 (round 2). Issue body is complete, traceability is solid, scope is well-bounded for a single agent pass.

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S34 label — "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified — found in project-westside-basketball user-stories section under Parent
• [x] arch:app-store label — App Store Billing architecture
• [x] arch note verified — arch-app-store note exists in pal-e-docs (ID 2224), documents iOS StoreKit Purchase Flow component and references parent #78
• [x] Forgejo issue — ldraney/westside-basketball#85, state: open

File Targets

• [x] westside-basketball-ios/Store/SubscriptionManager.swift — new file (repo created by depends:81)
• [x] westside-basketball-ios/Store/SubscriptionView.swift — new file (repo created by depends:81)
• [x] westside-basketball-ios/PathConfiguration.swift — new file (repo created by depends:81)

All targets are new files in a repo that does not yet exist. The issue correctly documents this and specifies the dependency on #81 (repo creation). File paths follow standard iOS/Swift conventions. Exclusions (Rails backend, Fastlane config) are clearly stated.

Repo Placement

OK — Issue filed on westside-basketball because westside-basketball-ios does not exist yet (depends on #81). Issue body documents this and instructs to transfer after #81 completes. Acceptable interim placement.

Dependencies

• #81 (Create westside-basketball-ios repo) — backlog. Required: provides the repo this ticket works in.
• #84 (Fastlane IaC for subscription product) — backlog. Required: the subscription product must exist in App Store Connect before StoreKit can load it.
• #78 (parent, decomposed) — backlog. This ticket is Sub-ticket C of the decomposition.
• #86 (Fastlane SSH build pipeline) — backlog. Depends on THIS ticket (depends:85 in labels). Downstream consumer.

All dependencies are documented in the issue body and board labels. Dependency chain is correct: #81 → #84 → #85 → #86.

Acceptance Criteria

4 criteria, all manually verifiable in Xcode sandbox environment. Clear and specific:

• Product loading — verifiable via StoreKit sandbox
• Purchase sheet presentation — verifiable via navigation interception test
• Transaction completion + receipt sending — verifiable via sandbox + server logs
• End-to-end sandbox test — integration verification

Test expectations include StoreKit Configuration file for unit testing. Reasonable scope.

Blast Radius

Low. Native iOS code in a new repo. No shared code with sibling services. Receipt sending touches the Rails webhook endpoint (#65) but the issue explicitly excludes server-side validation from scope. Boundary is clean.

Decomposition Assessment

No decomposition needed. 3 file targets in 1 repo, 4 acceptance criteria, estimated agent work well under 5 minutes. Single-focus: StoreKit 2 purchase flow implementation.

Recommendation

No action needed.

Verdict: NEEDS_REFINEMENT

Re-review (round 2) of board item #1636. Prior review: review-1636-2026-06-27 (NEEDS_REFINEMENT).

Round 1 Resolution

• [x] [SCOPE] Create architecture note arch-app-store -- RESOLVED. Note exists (ID 2224, slug arch-app-store, title "Architecture: App Store Billing"). Covers components, data model, dependency chain, key decisions.
• [x] [BODY] Clarify that existing Stripe subscription_status is DB-level only -- RESOLVED. Context section now reads "DB-level enum: active/past_due/canceled/none", making clear there is no model-level enum declaration.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Child of #66, Sub-ticket A of 4
• [x] Repo -- ldraney/westside-basketball
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag -- none (internal model change, acceptable)
• [x] Acceptance Criteria -- 4 criteria
• [x] Test Expectations -- 3 expectations + run command
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S35 label -- "As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier" -- verified in project-westside-basketball user-stories section under Admin (Marcus)
• [x] story note verified -- found in project-westside-basketball user-stories section
• [x] arch:app-store label -- "Architecture: App Store Billing" -- verified: arch-app-store note exists in pal-e-docs (ID 2224)
• [x] arch note verified -- arch-app-store covers data model, components, dependency chain
• [x] Forgejo issue -- ldraney/westside-basketball#79, open
• [x] Parent issue -- #66 (Subscription UI), open, in next_up

File Targets

• [x] app/models/player.rb -- verified: file exists (14 lines, associations only). No existing enum declarations in model. DB schema confirms subscription_status enum and Stripe columns exist at schema level.
• [x] db/migrate/*_add_apple_subscription_to_players.rb -- new file to create. db/migrate/ directory does not exist yet (schema was loaded from DB dump). Agent must create directory. Not a blocker.
• [x] test/models/player_test.rb -- verified: file exists (2 existing tests for associations and table name).

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets are within the same repo. Single-repo change.

Dependencies

• Parent: #66 (board item #1611) in next_up, decomposed into 4 sub-tickets.
• Downstream dependents: #80 (depends:79, WS-S36), #82 (depends:58,depends:79, WS-S35), #83 (depends:79, WS-S37) -- 3 items depend on this ticket.
• No upstream blockers on #79 itself. The migration is self-contained.
• #65 (webhook infra, board item #1610, next_up) provides data that populates these fields, but #79 does not depend on #65 to ship. Fields can exist before the webhook fills them.

Acceptance Criteria

4 AC, all verifiable by agent. Test commands are real. Criteria are clear and complete.

Blast Radius

Additive-only change. New apple_subscription_status is a separate PostgreSQL enum type. No collision with existing subscriptionstatus enum or Stripe columns. No blast radius concerns.

Decomposition Assessment

3 file targets in 1 repo. 4 acceptance criteria. Estimated agent work: 2-3 minutes. No decomposition needed.

NEW FINDING: Enum Value Mismatch

The issue body and arch-app-store note disagree on enum values:

Issue #79 (AC1)	arch-app-store (Data Model)
active	subscribed
expired	expired
in_billing_retry	billing_retry
in_grace_period	grace_period
revoked	revoked
none	none

Two classes of discrepancy:

1. Naming: active vs subscribed -- semantically different. Apple Server Notifications v2 uses neither; the closest Apple status is ACTIVE. The issue and arch note must agree on one name.
2. Prefix: in_billing_retry/in_grace_period vs billing_retry/grace_period -- the in_ prefix adds clarity but diverges from the arch note. Must pick one convention.

This mismatch would cause the agent to implement values that conflict with the arch note, creating confusion for downstream tickets #80, #82, #83 that consume this enum.

Recommendation

• [BODY] Align enum values in issue #79 AC1 with arch-app-store Data Model section (or vice versa). The two sources must agree. Recommend: pick one set, update both the issue body AND the arch note to match. Suggest using the arch note values (subscribed, grace_period, billing_retry) since they are shorter and closer to Rails enum conventions, but this is an owner decision.

Verdict: APPROVED

Re-review after round 1 refinements. Round 1 flagged missing arch-app-store note -- that note now exists (ID 2224). All other checks passed in round 1 and remain valid.

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S37 label — "As a player or parent, I want to log in and see my subscription status and payment history so that I know where I stand and can take action if needed"
• [x] story note verified — found in project-westside-basketball user-stories section (Player role)
• [x] arch:app-store label — App Store Billing component
• [x] arch note verified — arch-app-store note exists in pal-e-docs (ID 2224, "Architecture: App Store Billing")
• [x] Forgejo issue — ldraney/westside-basketball#83, open

File Targets

• [x] app/controllers/players_controller.rb — verified: exists, has only index action. Adding status action is correct.
• [x] app/views/players/status.html.erb — new file to create. Only index.html.erb exists currently. Correct.
• [x] config/routes.rb — verified: exists, currently has resources :players, only: [:index]. Route expansion needed.
• [x] DO NOT touch list — app/views/admin/ (admin pages are separate sub-tickets) and app/models/player.rb (model changes in sub-ticket A) are correctly excluded.

Repo Placement

Correct. Issue filed on ldraney/westside-basketball, all file targets are in that repo. Single-repo change.

Dependencies

• depends:79 (sub-ticket A — Apple subscription model fields + migration). Board item #1636, currently in backlog. The Player model has NO apple_subscription_status field yet — this dependency is real and correctly documented. The status page reads subscription state from these fields.
• parent:66 (Subscription UI — 3-page arch). Parent item #1611, in next_up with decomposed label. Correct parent relationship.

Acceptance Criteria

3 ACs, all verifiable by an agent:

• Player can view subscription status at the status route — testable via controller test
• Status page shows appropriate state for all Apple subscription statuses (6 states enumerated) — testable via view rendering tests
• No-subscription state shows call-to-action (not an error) — testable via specific assertion

Test expectations include 3 unit tests with a valid run command: bundle exec rails test test/controllers/players_controller_test.rb. Test file exists in the repo.

Blast Radius

Minimal. This is a new route and view — no existing behavior changes. No feature flag needed (correctly noted as "none"). The status page is additive; existing player index page is untouched.

Decomposition Assessment

3 file targets, 1 repo, 3 ACs. Estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

No action needed. Ticket is APPROVED for todo.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Sprint 6 decomposition context
• [x] Repo -- ldraney/pal-e-services
• [x] User Story -- WS-S38
• [x] Context -- clear motivation, two options laid out, recommendation given
• [x] File Targets -- two files listed
• [x] Feature Flag -- none (appropriate for IaC change)
• [x] Acceptance Criteria -- 4 items
• [x] Test Expectations -- 3 items plus terraform plan command
• [x] Constraints -- 3 items
• [x] Checklist -- present
• [x] Related -- 4 items with cross-references

Traceability

• [x] story:WS-S38 label -- present on board item
• [x] story note verified -- WS-S38 found in project-westside-basketball user-stories section under Parent: "As a parent, I want to create an account, log in through the iOS app, and be routed to my subscription status page so I can manage payments and see where I stand"
• [x] arch:app-store label -- present on board item
• [ ] arch note MISSING -- [SCOPE] No note found for arch-app-store in pal-e-docs. Create architecture note arch-app-store for the App Store component.
• [x] Forgejo issue -- ldraney/pal-e-services#154, open

File Targets

• [x] terraform/k3s.tfvars -- verified: symlink to ~/secrets/pal-e-services/k3s.tfvars. westside-basketball realm exists with registration_allowed = false. Change to true is straightforward.
• [ ] terraform/keycloak.tf -- ISSUE: file exists and handles realm config, but currently has NO keycloak_default_roles resource. AC #2 says "New self-registered users automatically get player role" but there is no mechanism to assign a default role to self-registered users. The keycloak_realm resource manages registration_allowed but not default role assignment. A new keycloak_default_roles resource is needed (provider supports it since v4.x). This also requires a new variable in variables.tf for default_roles per realm.

Missing file target: terraform/variables.tf -- needs a default_roles field added to the keycloak_realms variable type definition.

Repo Placement

OK. Keycloak IaC lives in pal-e-services, issue is filed on pal-e-services. Single-repo change.

Dependencies

• #1633 (next_up, sprint:6) -- "Drop stale basketball DB role + update Keycloak westside-ror references" touches the same Keycloak terraform files. Should be completed BEFORE this ticket to avoid merge conflicts. Not documented in issue.
• #1646 (backlog, depends:154) -- downstream, depends on this ticket. Properly documented.
• #1647 (backlog, depends:154) -- downstream spike, depends on this ticket. Properly documented.
• westside-basketball#83 (open) -- player-facing status page, needs player auth. Downstream consumer.
• westside-basketball#87 (open) -- role-based routing, needs player role. Downstream consumer.
• Related issue pal-e-services#152 (same as board #1633) -- should be done first to clean up westside-ror references before adding new realm features.

Acceptance Criteria

• [x] AC1: "Self-registration enabled" -- verifiable via terraform plan output
• [ ] AC2: "New self-registered users automatically get player role" -- NOT achievable with file targets as written. Requires keycloak_default_roles resource which is not in scope. Issue body needs to add this file target and the corresponding variable.
• [x] AC3: "Self-registration page renders correctly" -- verifiable manually
• [x] AC4: "Existing admin accounts unaffected" -- verifiable via terraform plan

Blast Radius

• Other realms unaffected -- change is scoped to westside-basketball realm only via tfvars.
• reset_password_allowed is currently false -- self-registered users will not be able to reset passwords. The issue doesn't mention enabling this, but self-registration without password reset creates a poor UX. Consider whether reset_password_allowed should also flip to true.
• SMTP config has placeholder password -- the SMTP block in k3s.tfvars has auth_password = "REPLACE_WITH_GMAIL_APP_PASSWORD". If SMTP isn't configured, email verification and password reset won't work. Self-registration without email verification is a security risk (bots). Issue should note whether SMTP is actually configured or if the placeholder was already replaced.
• No email verification required action specified -- Keycloak can require email verification on self-registration. The issue doesn't mention this. Without it, anyone can create accounts with fake emails.

Decomposition Assessment

2 file targets (expanding to 3 with variables.tf), 4 AC, single repo. Estimated agent work under 5 minutes. No decomposition needed.

Recommendations

• [BODY] Add file target: terraform/variables.tf -- add optional default_roles field to keycloak_realms variable type.
• [BODY] Add file target detail for terraform/keycloak.tf -- add keycloak_default_roles resource that assigns default realm roles to self-registered users.
• [BODY] Add dependency note: should be done after #1633 (pal-e-services#152) which cleans up westside-ror Keycloak references in the same files.
• [BODY] Address reset_password_allowed -- consider flipping to true alongside self-registration. Self-registered users without password reset is poor UX.
• [BODY] Address SMTP placeholder -- confirm whether Gmail app password is actually configured in the secrets file, or add AC to configure it.
• [BODY] Consider adding email verification required action for self-registered users to prevent bot accounts.
• [SCOPE] Create architecture note arch-app-store for the App Store component referenced by the arch:app-store label.

Verdict: NEEDS_REFINEMENT

Re-review v3 — previous review was review-1611-2026-06-27-v2 (NEEDS_REFINEMENT). This re-review evaluates the rewritten scope after all three factual errors were corrected.

Summary: The rewrite fixed the critical factual errors (subscription fields acknowledged, Stripe stays, #58 correctly open). The scope is now factually accurate. However, two issues remain: (1) the arch:app-store note still does not exist, and (2) the ticket still exceeds the 5-criterion decomposition threshold with 11 AC across 8 file targets. Decomposition is still needed.

Template Completeness

• [x] Type — Feature
• [x] Lineage — depends on #65 and #58, correctly stated both are open
• [x] Repo — ldraney/westside-basketball
• [x] User Story — WS-S35, WS-S36, WS-S37
• [x] Context — three-page architecture explained, Stripe coexistence clearly stated
• [x] File Targets — 8 targets listed (reduced from 11 in v2 after removing Stripe deletion targets)
• [x] Feature Flag — "none" (correct — repo has no docs/feature-flags.md, and this is informational display)
• [x] Acceptance Criteria — 11 criteria
• [x] Test Expectations — 4 test items + run command
• [x] Constraints — 5 constraints listed
• [x] Checklist — present
• [x] Related — stories, issues, project page, prior review note

Traceability

• [x] story:WS-S35 — verified on project-westside-basketball user-stories section: "As an admin, I want to set and manage subscription pricing on a player's detail page so that I control what each family pays for their program tier"
• [x] story:WS-S36 — verified on project-westside-basketball user-stories section: "As an admin, I want to see Apple subscription lifecycle states (subscribed, grace period, billing retry, expired) per player so that I know who's current, who's in grace, and who's delinquent"
• [x] story:WS-S37 — verified on project-westside-basketball user-stories section: "As a player or parent, I want to log in and see my subscription status and payment history so that I know where I stand and can take action if needed"
• [ ] arch:app-store — label present but arch note MISSING. search_notes(query="arch-app-store") returned empty. [SCOPE] Create architecture note arch-app-store.
• [x] Forgejo issue — westside-basketball#66, open

Factual Corrections Verified

All three factual errors flagged in v2 have been corrected:

1. Subscription fields: Issue now correctly states "The codebase has active Stripe integration" with stripe_customer_id, stripe_subscription_id, and subscription_status enum listed. Verified against db/schema.rb lines 266-268. FIXED.
2. Stripe stays: Issue now explicitly says "Do NOT delete any Stripe code. Stripe continues to handle one-off payments. Apple handles recurring subscriptions. Both coexist." File targets section adds explicit "Files the agent should NOT touch" list including all Stripe code. FIXED.
3. #58 dependency: Issue now says "#58 is still open and must be implemented first." Lineage says "Depends on #58 (admin player detail page — still open, not yet implemented)." Verified: Forgejo issue #58 is open, show.html.erb does not exist on main. FIXED.

File Targets

• [x] app/models/player.rb — verified exists. Issue correctly describes adding apple_subscription_status enum and new fields. Existing model has no explicit enum declaration in Ruby (DB-level enum only). Correct.
• [x] db/migrate/*_add_apple_subscription_to_players.rb — new migration to create. Issue correctly says "additive — do NOT alter existing Stripe columns or subscription_status enum." Schema confirms existing subscriptionstatus enum (active/past_due/canceled/none) is separate from proposed apple_subscription_status. A new PostgreSQL enum type will be created. Correct.
• [x] app/views/admin/players/show.html.erb — correctly identified as NOT existing. Issue correctly notes "requires #58 to create this view first." Verified: show.html.erb absent from app/views/admin/players/.
• [x] app/views/admin/players/index.html.erb — verified exists (112 lines). Issue says add Apple subscription badges alongside existing badges. Correct.
• [x] app/helpers/application_helper.rb — verified exists. Currently has subscription_badge_variant and subscription_badge_label for Stripe states. Issue says add badge helpers for Apple states alongside. Correct.
• [x] app/views/players/status.html.erb — correctly identified as new file to create. Verified: does not exist. Only index.html.erb exists in app/views/players/.
• [x] app/controllers/players_controller.rb — verified exists. Currently has only index action. Issue says add status action. Correct.
• [x] config/routes.rb — verified exists. Admin players has only [:index]. Player resources also only [:index]. Both need additions. Correct.

All 8 file targets verified accurate. No factual errors in file target descriptions.

Repo Placement

OK — issue filed on westside-basketball, all file targets are in westside-basketball. Single-repo scope is correct. "Files the agent should NOT touch" correctly excludes iOS repo and webhook infrastructure (#65).

Dependencies

• depends:65 (board item #1610) — App Store webhook infrastructure. Currently in next_up. Issue open. This ticket cannot start until #65 lands the Apple webhook handler that populates the new fields.
• depends:58 (board item #1609) — Admin player detail page. Currently in next_up. Issue open. The show.html.erb view does NOT exist on main. This ticket's AC #5 and #6 (show page subscription badge + pricing UI) cannot be implemented until #58 creates the page. Correctly documented in issue.
• Sibling: Board item #1635 (issue #78, iOS StoreKit purchase flow) also depends on #65 and is in backlog. Not a blocker, but implements the client-side subscription purchase that feeds data into the fields this ticket displays.

Both dependencies correctly labeled and documented in the issue body.

Acceptance Criteria

11 acceptance criteria. Assessment:

• AC 1-2 (model enum + fields): Verifiable via schema inspection and model test.
• AC 3-4 (migration additive + reversible): Verifiable via migration inspection and rollback test.
• AC 5-6 (admin detail page): Depends on #58. Agent-verifiable but blocked until #58 merges.
• AC 7 (admin list badges): Verifiable via view test.
• AC 8-9 (player-facing status page + no-subscription state): Verifiable via controller/view test.
• AC 10 (badge colors): Verifiable via helper test.
• AC 11 (Stripe test regression): Verifiable via bundle exec rails test. 33 Stripe/webhook-related tests exist.

All criteria are agent-verifiable. Test command is real. No missing criteria identified — the previous v2 concern about data migration for existing enum values is no longer relevant since the migration is now additive (new enum type, not altering the existing one).

Blast Radius

• Existing subscription_status references (5 controllers, 2 views, 1 helper) are UNTOUCHED by this ticket. The new apple_subscription_status is a separate field and separate PostgreSQL enum type. No blast radius on existing Stripe integration.
• The onboardingstatus enum includes "stripe_connected" — NOT affected by this ticket since Stripe stays.
• Adding badges to index.html.erb (112 lines) is low-risk — additive HTML only.
• New player-facing status page is isolated — new route, new action, new view. No interaction with existing player index page.

Blast radius is well-contained by the additive design. Previous v2 blast radius concerns are resolved.

Decomposition Assessment

NEEDS DECOMPOSITION.

• 8 file targets in 1 repo — exceeds >3 threshold
• 11 acceptance criteria — exceeds >5 threshold
• Estimated agent work: over 5 minutes (migration, model changes, 2 view modifications, 1 new view, helper additions, controller addition, route additions, tests for all)
• Natural decomposition along the three-page architecture:
  1. Sub-ticket A: Apple subscription model + migration (AC 1-4: enum, fields, additive migration, reversible) — ~3 file targets
  2. Sub-ticket B: Admin list page Apple badges (AC 7, 10: index.html.erb badges + helper additions) — ~2 file targets
  3. Sub-ticket C: Admin detail page subscription UI (AC 5-6: show.html.erb additions) — depends on #58 AND sub-ticket A — ~1 file target
  4. Sub-ticket D: Player-facing status page (AC 8-9: new route, action, view) — depends on sub-ticket A — ~3 file targets
• AC 11 (Stripe regression) applies to all sub-tickets as a universal constraint.

The scope is factually clean and ready for decomposition. No factual corrections needed first (unlike v2).

Recommendation

• [SCOPE] Create architecture note arch-app-store. Label arch:app-store is on the board item but no backing note exists in pal-e-docs.
• [DECOMPOSE] 11 AC across 8 file targets, estimated over 5 minutes. Scope is now factually accurate and ready for decomposition. Route to skill-decompose-ticket with the four sub-ticket breakdown above.

Verdict: NEEDS_REFINEMENT

Re-review of review-1635-2026-06-27. Previous review flagged repo mismatch, arch note gap, and decomposition. Scope refinement addressed body issues; decomposition still required.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- "Depends on #65 (webhook infrastructure). Sibling of #66 (admin subscription UI). Requires new iOS repo."
• [x] Repo -- ldraney/westside-basketball-ios (NEW, with transfer note) -- FIXED from previous review
• [x] User Story -- WS-S34
• [x] Context -- Turbo Native + StoreKit 2 + Fastlane IaC + Apple delinquency gate + iOS-only decision + prerequisites listed
• [x] File Targets -- all reference new iOS repo (Fastfile, Appfile, Swift StoreKit, API key reference)
• [x] Feature Flag -- "none" (appropriate for core iOS subscription flow)
• [x] Acceptance Criteria -- 7 criteria listed
• [x] Test Expectations -- unit + integration + run command
• [x] Constraints -- 6 constraints listed (including "Repo must be westside-basketball-ios")
• [x] Checklist -- present
• [x] Related -- lists #65, #66, project page, previous review note, iOS pipeline memory

All required sections for Feature template are present. No gaps.

Traceability

• [x] story:WS-S34 label -- "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified -- found in project-westside-basketball user-stories section under Parent heading
• [x] arch:app-store label -- present on board item
• [x] arch note verified -- arch-app-store note exists in pal-e-docs, correctly covers westside-basketball components including iOS StoreKit (#78), Rails webhook (#65), and subscription UI (#66) -- FIXED from previous review (was arch:ios pointing to landscaping-assistant)
• [x] Forgejo issue -- ldraney/westside-basketball#78, open

All three traceability legs present and verified. Previous arch note gap resolved.

File Targets

• [~] fastlane/Fastfile -- CANNOT VERIFY: target repo westside-basketball-ios does not exist yet. Path is logically correct for Fastlane convention.
• [~] fastlane/Appfile -- CANNOT VERIFY: same as above. Standard Fastlane path.
• [~] Swift StoreKit 2 integration files -- CANNOT VERIFY: repo does not exist. Description is directionally correct for StoreKit 2 in a Turbo Native app.
• [~] App Store Connect API key reference -- CANNOT VERIFY: references pal-e-services terraform, which is a separate repo. Issue correctly notes "separate ticket needed."
• [x] Files NOT to touch -- correctly excludes westside-basketball (Rails) repo. #65 covers webhook, #66 covers UI.

File targets cannot be verified because the target repo does not exist. This is expected and documented. Paths are logically correct for the intended architecture.

Repo Placement

FIXED. Issue now correctly identifies ldraney/westside-basketball-ios as the target repo. Includes clear note explaining why the issue is temporarily filed on westside-basketball with transfer instructions. This resolves the primary finding from the previous review.

However, AC #6 ("App Store Connect API key managed in pal-e-services terraform") is explicitly cross-repo work. This AC should be a separate pal-e-services issue, not part of this ticket.

Dependencies

• depends:65 (board item #1610) -- "Configure App Store Connect subscription product and billing grace period" -- currently in next_up, sprint:6. Rails webhook endpoint. #78 needs the server notifications URL from #65.
• Sibling #66 (board item #1611) -- "Subscription status on admin player detail page" -- currently in next_up, sprint:6. No ordering dependency.
• Prerequisite: iOS repo creation -- documented in Context as "Prerequisites not yet tracked." Repo westside-basketball-ios does not exist. Must be created before any work starts.
• Prerequisite: Apple Developer Program -- documented in Context. Status unknown. Required for App Store Connect API access and sandbox testing.
• Prerequisite: pal-e-services terraform -- documented in Context and in AC #6. Needs its own issue in pal-e-services repo.

Dependencies are now documented in the issue body (improvement from previous review). The depends:65 label correctly captures the primary dependency.

Acceptance Criteria

7 acceptance criteria. Assessment:

• AC 1-3 (Fastlane config): Testable via Fastlane commands. Require App Store Connect API access but are automatable.
• AC 4-5 (StoreKit purchase): Require physical device or simulator + sandbox Apple ID + running Rails webhook (#65). Partially automatable.
• AC 6 (pal-e-services terraform): Cross-repo. This is work in pal-e-services, not the iOS repo. Should be a separate issue.
• AC 7 (SSH pipeline): Requires MacBook SSH access. Not automatable by a standard agent.

AC count (7) exceeds the 5-criterion decomposition threshold. AC #6 is explicitly cross-repo. Several ACs require external infrastructure an agent cannot easily verify.

Blast Radius

Moderate but well-contained. The arch-app-store note documents the full system architecture. Key interactions:

• Rails webhook (#65) receives Apple notifications -- covered by separate ticket
• Admin UI (#66) displays subscription status -- covered by separate ticket
• Existing Stripe webhooks unaffected -- Apple flow runs in parallel
• Other Turbo Native apps (landscaping-assistant) use same Fastlane pattern but have own repos -- no cross-contamination

Decomposition Assessment

NEEDS DECOMPOSITION.

• File targets across repos: iOS repo (new) + pal-e-services terraform = 2 repos. Exceeds threshold.
• Acceptance criteria: 7. Exceeds 5-criterion threshold.
• Estimated agent work: Well over 5 minutes. Creating Turbo Native shell, Fastlane config (3 ACs), StoreKit 2 integration (2 ACs), plus separate pal-e-services terraform work.
• Recommended decomposition:
  1. Create westside-basketball-ios repo with Turbo Native shell (prerequisite for all other work)
  2. Fastlane IaC: Fastfile + Appfile defining subscription product, billing grace period, server notifications v2 URL (AC 1-3)
  3. StoreKit 2 purchase flow: native Swift purchase view within Turbo Native shell + sandbox testing (AC 4-5)
  4. pal-e-services terraform: App Store Connect API key secret management (AC 6 -- separate repo, separate issue)
  5. Fastlane SSH pipeline: build + deploy pipeline via SSH to MacBook (AC 7)

[DECOMPOSE] 7 AC across 2 repos (iOS new + pal-e-services), estimated well over 5 minutes. Route to skill-decompose-ticket.

Note: The refinement comment on the issue acknowledged decomposition is still needed. The body fixes addressed repo placement and arch note gaps but decomposition was intentionally deferred to this re-review.

Improvements Since Previous Review

• FIXED: Repo placement -- now targets westside-basketball-ios with transfer note
• FIXED: Arch note -- arch:app-store label with arch-app-store note in pal-e-docs (replaces arch:ios gap)
• IMPROVED: Prerequisites documented in Context section
• IMPROVED: File targets explicitly scoped to new iOS repo
• REMAINING: Decomposition still needed (7 AC, 2 repos, well over 5 min)

Recommendation

• [BODY] Remove AC #6 ("App Store Connect API key managed in pal-e-services terraform") from this ticket -- it is cross-repo work that belongs in a separate pal-e-services issue.
• [DECOMPOSE] 7 AC across 2 repos (iOS new + pal-e-services). Even after removing the pal-e-services AC, the remaining 6 ACs span repo creation + Fastlane config + StoreKit integration + SSH pipeline = well over 5 minutes. Route to skill-decompose-ticket with the 5-part decomposition above.

Verdict: READY

Re-review round 2 (2026-06-27). All three findings from round 1 have been resolved. Scope is solid, all file targets verified, traceability complete, fits in a single agent pass.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, Sprint 6 planning
• [x] Repo — ldraney/westside-basketball
• [x] User Story — WS-S34, well-formed
• [x] Context — clear explanation of Apple's auto-hold behavior, Fastlane IaC separation, and iOS-only subscription decision (2026-06-27)
• [x] File Targets — 4 modify/create targets, 3 exclusions (all verified)
• [x] Feature Flag — none (infrastructure, appropriate)
• [x] Acceptance Criteria — 6 criteria, all code-deliverable
• [x] Test Expectations — 2 integration tests with run command
• [x] Constraints — 6 constraints listed
• [x] Checklist — standard 3 items
• [x] Related — story, project, sibling tickets, previous review note referenced

Traceability

• [x] story:WS-S34 label — "As a parent, I want to subscribe to my child's team program through the iOS app so that Apple handles monthly billing and automatically enforces the delinquency gate if I fall behind on payments"
• [x] story note verified — found in project-westside-basketball user-stories section under Parent
• [x] arch:app-store label — App Store billing component
• [x] arch note verified — arch-app-store note exists in pal-e-docs (created 2026-06-28, covers webhook flow, data model, dependency chain, iOS-only decision)
• [x] Forgejo issue — ldraney/westside-basketball#65, state: open

File Targets

• [x] Gemfile — verified: exists (2.3k), no app_store_server_library gem present yet. Ready for addition.
• [x] config/routes.rb — verified: exists, line 50 has post "webhooks/stripe" => "webhooks#stripe". Appropriate place to add App Store webhook route alongside existing Stripe route.
• [x] app/controllers/webhooks_controller.rb — verified: exists (4.1k), inherits from ActionController::Base, has skip_forgery_protection only: :stripe. Existing Stripe webhook implementation present (lines 7-118). Pattern matches ticket description.
• [x] config/credentials.yml.enc — verified: exists (548 bytes).
• [x] No webhooks/ subdirectory — verified: only admin/ and concerns/ exist under app/controllers/.

Repo Placement

OK. Issue is filed on ldraney/westside-basketball and all file targets are in the same repo. Fastlane IaC and iOS code correctly scoped out to the iOS repo. Single-repo ticket.

Dependencies

• depends:58 label removed (was inverted — round 1 finding, now fixed).
• Board item #1611 (westside-basketball#66, Subscription management UI, 5pts) has depends:58,depends:65 — correctly depends on this ticket for webhook data.
• Board item #1635 (westside-basketball#78, iOS StoreKit purchase flow, 5pts, backlog) has depends:65 — correctly depends on this ticket (needs webhook endpoint before iOS can send notifications).
• No blocking dependencies on this ticket — it can be implemented immediately.

Acceptance Criteria

6 ACs, all code-deliverable and agent-verifiable:

• AC1 (gem in Gemfile) — trivially verifiable via grep
• AC2 (route added) — verifiable via grep on routes.rb
• AC3 (webhook action acknowledges) — verifiable via integration test
• AC4 (JWS verification) — verifiable via integration test with invalid signature
• AC5 (credentials stored) — verifiable via rails credentials:show
• AC6 (observability logging) — verifiable via test log output inspection. NEW since round 1 — addresses the missing payload handling finding.

All criteria are complete and testable. No missing AC.

Blast Radius

• No existing App Store or Apple code in the codebase (only CSS font-family and meta tags). This is greenfield — no risk of conflicting with existing patterns.
• Existing WebhooksController uses ActionController::Base + skip_forgery_protection per-action. Adding a new Apple action follows the same pattern — low risk.
• Credentials access: the app currently uses file-based credentials for Gmail (config/gmail/credentials.json), not Rails.application.credentials. The ticket specifies credentials.yml.enc for App Store secrets — correct Rails convention but introduces a new credential access pattern. Not a blocker, just awareness for the implementing agent.
• Constraint "Do NOT delete or modify existing Stripe webhook" is explicitly stated — prevents accidental breakage of one-off payments.

Decomposition Assessment

4 file targets in 1 repo, 6 ACs, estimated agent work under 5 minutes. No decomposition needed.

Recommendation

No action needed. All round 1 findings have been resolved:

• [SCOPE] Create architecture note arch-app-store — DONE. Note exists with full component breakdown, data model, dependency chain, and iOS-only decision.
• [LABEL] Remove depends:58 — DONE. Board item #1610 labels no longer include depends:58.
• [BODY] Add AC for observability logging — DONE. AC6 added: "Webhook logs the decoded notification type and subtype for observability."

Round 1 Findings — All Resolved

• [SCOPE] arch-app-store note missing — FIXED. arch-app-store note created in pal-e-docs.
• [LABEL] Remove depends:58 (inverted dependency) — FIXED. Label removed from board item.
• [BODY] Add AC for payload handling after verification — FIXED. AC6 now covers observability logging.

Verdict: APPROVED

Scope simplified after two review rounds. Architectural decision confirmed by project owner: Stripe code is dead scaffolding (never connected to real payments), replace with Apple subscription tracking. No decomposition needed — one focused feature.

Template Completeness

• [x] Type — Feature
• [x] Lineage — depends on #65
• [x] Repo — ldraney/westside-basketball
• [x] User Story — admin sees Apple subscription status
• [x] Context — delinquency gate focus, Stripe is dead code
• [x] File Targets — 7 files listed
• [x] Acceptance Criteria — 5 ACs, all verifiable
• [x] Test Expectations — model + view tests
• [x] Constraints — Apple states, reversible migration
• [x] Checklist — standard
• [x] Related — #65 dependency, project page

Traceability

• [x] Forgejo issue — westside-basketball#66, open
• [x] Board item — #1611, sprint:6

File Targets

7 files in 1 repo. Player model, migration, 2 views, helper, webhooks controller, routes. All in westside-basketball.

Repo Placement

Correct. Single-repo Rails change.

Dependencies

Depends on #65 (webhook infrastructure). #65 is in next_up, reviewed and approved.

Acceptance Criteria

5 ACs: Stripe removal, Apple enum, detail badge, list badge, no-subscription state. All agent-verifiable.

Blast Radius

Stripe code is unused scaffolding. Removing it has no production impact. Any test files referencing Stripe enum values will need updating — agent will find these via test failures.

Decomposition Assessment

No decomposition. Previous review recommended split but was treating dead scaffolding as a production system. Project owner confirmed: just delete and replace.

Recommendation

Ready for implementation. Prior review concerns resolved by architectural decision.

Verdict: NEEDS_REFINEMENT

Re-review after major refinement. Previous review (review-1611-2026-06-27) found critical Stripe vs Apple architectural conflict. Owner decided to REPLACE Stripe with Apple. Issue body rewritten. This review validates the rewritten scope.

What improved: The Stripe-vs-Apple coexistence question is resolved — the issue now explicitly says "replace Stripe." Context section documents the decision. Migration approach (repurpose existing column) is sound. File targets are more comprehensive.

What still needs work: The ticket is too large (8 file targets + migration + Stripe removal + Apple badge UI across 2 subsystems), show.html.erb still doesn't exist on main, and several blast radius files are missing from file targets.

Template Completeness

• [x] Type — Feature
• [x] Lineage — references #65 and #58
• [x] Repo — ldraney/westside-basketball
• [x] User Story — admin wants subscription status on player detail page
• [x] Context — explains Apple delinquency gate and Stripe replacement decision
• [x] File Targets — 8 modify/create targets, 1 do-not-touch
• [x] Feature Flag — none (admin-only, acceptable)
• [x] Acceptance Criteria — 6 criteria
• [x] Test Expectations — 3 test items with run command
• [x] Constraints — 3 constraints listed
• [x] Checklist — present
• [x] Related — project-westside-basketball, review note, #65

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what" — verified in project-westside-basketball user-stories section
• [ ] arch note MISSING — [SCOPE] No architecture note found for arch-rails-views. Search returned empty results. Create architecture note arch-rails-views for component rails-views.
• [x] Forgejo issue — ldraney/westside-basketball#66, state: open

File Targets

• [x] db/migrate/*_replace_stripe_with_apple_subscription.rb — new migration. Sound approach: repurpose existing subscription_status enum column, drop stripe_subscription_id, add Apple fields. Note: db/migrate/ directory does not exist in repo (schema-only). Agent will need to create directory.
• [x] app/models/player.rb — verified: exists. Currently has no explicit enum declaration (relies on Postgres enum). Agent will need to add explicit enum declaration for Apple states.
• [ ] app/views/admin/players/show.html.erb — ISSUE: File does NOT exist on main. Issue #58 (player detail page) is marked done on board (item 1609) but code has NOT been merged. No branch for it found. No show action in controller. Routes only define :index. This file target is invalid until #58 is actually merged.
• [x] app/views/admin/players/_subscription_badge.html.erb — new partial. Acceptable — will be created.
• [x] app/views/admin/players/index.html.erb — verified: exists (113 lines). Currently uses subscription_badge_variant and subscription_badge_label helpers with Stripe states. Needs Apple state update.
• [x] app/helpers/application_helper.rb — verified: exists (22 lines). Defines subscription_badge_variant and subscription_badge_label with Stripe states (active/past_due/canceled/none). Needs Apple state update.
• [x] app/controllers/webhooks_controller.rb — verified: exists (119 lines). Full Stripe webhook handling: checkout.session.completed, customer.subscription.updated, customer.subscription.deleted. To be removed.
• [x] config/routes.rb — verified: has post "webhooks/stripe" => "webhooks#stripe" at line 50. To be removed.

Repo Placement

OK — issue is filed on ldraney/westside-basketball, which is the correct repo for all affected files.

Dependencies

• depends:65 — item 1610 is in todo column. Issue #65 (App Store Connect configuration) is open on Forgejo and in todo on the board. This ticket's AC #5 ("When webhook updates subscription state, badge reflects new state") depends on #65 providing the webhook endpoint. However, the issue acknowledges this dependency in Lineage and explicitly says webhook verification logic is in #65's scope (do-not-touch). The migration and badge display work can proceed independently — only the webhook integration AC requires #65 first.
• depends:58 (implicit) — STILL BROKEN. Issue #58 (admin player detail page) is marked done on board (item 1609) but show.html.erb does NOT exist on main. Git log shows no merge commit for a show view. No branch found. The admin/players controller has no show action. Routes define only :index. This ticket targets show.html.erb which cannot be modified if it doesn't exist.
• Stripe removal blast radius undocumented. The issue lists 8 file targets but misses several files that reference Stripe subscription fields and will break when the enum values change or stripe_subscription_id is removed (see Blast Radius).

Acceptance Criteria

• [x] AC1: "Stripe subscription fields and webhook code removed" — testable, clear scope
• [x] AC2: "Player model subscription_status enum updated to Apple states" — testable, enum values specified
• [ ] AC3: "Player detail page shows color-coded subscription badge" — NOT testable: show.html.erb doesn't exist. Depends on #58 being merged first.
• [x] AC4: "Player list page badge helper updated to reflect Apple states" — testable
• [ ] AC5: "When webhook updates subscription state, badge reflects new state on next page load" — NOT fully testable in isolation: depends on #65 webhook. However, the subscription_status column update can be tested independently.
• [x] AC6: "Players without subscriptions show 'No subscription' gracefully" — testable

Blast Radius

SIGNIFICANT. The issue's file targets miss several files that hard-code Stripe subscription_status enum values and will break when enum values change:

• app/controllers/admin/players_controller.rb (33 lines) — Lines 27-29 hard-code "active", "past_due", "none", "canceled" for summary counts. NOT in file targets.
• app/controllers/admin/roster_report_controller.rb (137 lines) — Lines 14, 24, 29-30, 58, 121 reference "active", "none", "canceled" and stripe_subscription_id. Line 58-60 calls stripe.update_subscription_price using stripe_subscription_id. NOT in file targets.
• app/controllers/admin/delinquency_report_controller.rb (89 lines) — Lines 34, 44, 57 reference "past_due" and subscription_status. NOT in file targets.
• app/views/admin/roster_report/index.html.erb — Lines 51, 79 reference subscription_status. NOT in file targets.
• app/services/stripe_client.rb (249 lines) — Full Stripe API client with subscription methods. NOT in file targets (should it be deleted or kept for non-subscription Stripe use like payment links?).
• app/views/admin/payments/index.html.erb — References Stripe. NOT in file targets.
• test/helpers/application_helper_test.rb — 10 tests hard-coding Stripe enum values. NOT in file targets.
• test/controllers/webhooks_controller_test.rb — Full Stripe webhook test suite. NOT in file targets.
• test/controllers/admin/roster_report_controller_test.rb — References subscription_status. NOT in file targets.
• test/services/stripe_client_test.rb — Stripe client tests. NOT in file targets.

Total: 10 files reference Stripe subscription fields that are NOT in the issue's file targets. If the agent only modifies the 8 listed files, the app will have broken enum references, failing tests, and a non-functional roster report.

Decomposition Assessment

NEEDS DECOMPOSITION.

• 8 file targets listed + 10 unlisted blast radius files = 18 files potentially affected
• 6 acceptance criteria
• Two distinct subsystems: (1) data migration (enum change + field removal), (2) UI/badge updates
• Estimated agent work: well beyond 5 minutes. The migration touches the database schema, 6+ controllers, 4+ views, 1 service class, and 4+ test files.
• Recommended split:
  • Ticket A: Migrate subscription_status enum from Stripe to Apple states. Remove stripe_subscription_id. Update all controllers, helpers, and tests that reference old enum values. Remove Stripe webhook action and route. (Data layer + backend cleanup)
  • Ticket B: Add subscription badge to player detail page (show.html.erb). Blocked on #58 merge. (UI layer)

[DECOMPOSE] — 18 files across 2 subsystems, 6 AC. Route to skill-decompose-ticket.

Recommendation

• [DECOMPOSE] 18 files (8 listed + 10 unlisted) across 2 subsystems (data migration + UI). Exceeds 5-minute rule. Route to skill-decompose-ticket. Recommended split: (A) enum migration + Stripe removal + blast radius cleanup, (B) show page badge UI (blocked on #58).
• [BODY] show.html.erb does not exist on main. Issue #58 is marked done on board but code is NOT merged. Either: (a) merge #58 first, or (b) include show view creation in this ticket's scope, or (c) split badge-on-show into a separate ticket blocked on #58.
• [BODY] Add missing blast radius files to file targets: app/controllers/admin/players_controller.rb, app/controllers/admin/roster_report_controller.rb, app/controllers/admin/delinquency_report_controller.rb, app/views/admin/roster_report/index.html.erb, app/services/stripe_client.rb (decide: delete or keep for non-subscription Stripe use?), and all 4 affected test files.
• [BODY] Clarify stripe_client.rb disposition: it handles payment links and checkout sessions beyond subscriptions. Should it be deleted entirely or only have subscription methods removed?
• [SCOPE] Create architecture note arch-rails-views for component rails-views.
• [SCOPE] Verify #58 (player detail page) is actually merged/deployed before this ticket can target show.html.erb. Board says done but code is missing from main.

Verdict: READY

Re-review of board item #1610 after refinement. All three [BODY] issues from review-1610-2026-06-27 have been resolved. Two [SCOPE] items (story note, arch note) remain outstanding but are acknowledged as non-blocking per the review request.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, Sprint 6 planning
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- well-formed (As an admin, I want...)
• [x] Context -- thorough explanation of Apple billing behavior
• [x] File Targets -- 4 targets listed (Gemfile, routes.rb, webhooks_controller.rb, credentials.yml.enc) plus exclusion list
• [x] Feature Flag -- none, justified as infrastructure
• [x] Acceptance Criteria -- separated into Manual (3) and Code (3) sections
• [x] Test Expectations -- 2 integration tests with run command
• [x] Constraints -- 3 constraints listed
• [x] Checklist -- standard 3 items
• [x] Related -- project reference and previous review note present

Traceability

• [ ] story:WS-AUTH label -- NOT registered on project-westside-basketball user-stories section. Stories range WS-S1 through WS-S33; no WS-AUTH entry exists. Deferred -- acknowledged from prior review, not blocking.
• [ ] arch:app-store label -- No arch-app-store note found in pal-e-docs. Deferred -- acknowledged from prior review, not blocking.
• [x] Forgejo issue -- ldraney/westside-basketball#65, state: open

File Targets

• [x] Gemfile -- verified exists. app_store_server_library gem is NOT yet present (correct -- ticket adds it). Fixed from R1: was missing from file targets, now listed.
• [x] config/routes.rb -- verified exists. Contains Stripe webhook route at line 50: post "webhooks/stripe" => "webhooks#stripe". New App Store route will follow same pattern.
• [x] app/controllers/webhooks_controller.rb -- verified exists (119 lines). Single-file controller inheriting from ActionController::Base with skip_forgery_protection. No webhooks/ subdirectory exists. Fixed from R1: was incorrectly listed as webhooks/app_store_controller.rb, now correctly references the flat controller file.
• [x] config/credentials.yml.enc -- verified exists.

Repo Placement

OK. Issue filed on ldraney/westside-basketball. All code changes (webhook endpoint, gem, routes, credentials) live in this Rails app. Manual Apple portal steps are clearly labeled as non-code tasks.

Dependencies

• depends:58 (Admin player detail page) -- issue #58 is still OPEN. Dependency is documented via board label. The dependency is logical: #58 provides the admin page where subscription status will eventually display. However, #65 (webhook infrastructure) can be built independently -- it receives and processes notifications without any UI. The dependency chain #58 -> #65 -> #66 is correctly modeled on the board. Item #1611 (issue #66, 5pts) in backlog depends on #65 via depends:65 label.

Acceptance Criteria

Fixed from R1: ACs are now cleanly separated into Manual and Code sections.

• [x] Manual ACs (3) -- clearly labeled as "Apple portal -- human task, not agent-verifiable". Agent will skip these.
• [x] Code AC: app_store_server_library gem added to Gemfile -- agent-verifiable (check Gemfile)
• [x] Code AC: App Store Server Notifications v2 endpoint receives and acknowledges test notifications -- agent-verifiable via integration test
• [x] Code AC: JWS signature verification -- agent-verifiable via integration test

Test command is accurate: bundle exec rails test test/controllers/webhooks_controller_test.rb. Test file verified to exist (320 lines of Stripe webhook tests; App Store tests will be appended).

Blast Radius

Low. The webhook endpoint is additive -- new route, new controller method, new gem. No existing code is modified except adding a route to routes.rb and a new action method to webhooks_controller.rb. The existing Stripe webhook functionality is untouched. No sibling services affected. No existing App Store code in the codebase (grep confirmed: zero matches for app_store, apple, storekit, or jws in .rb files).

Decomposition Assessment

4 file targets in 1 repo, 3 code acceptance criteria, estimated agent work well under 5 minutes. No decomposition needed.

Refinement Resolution

R1 Finding	Tag	Status
Wrong controller path (webhooks/app_store_controller.rb)	[BODY]	RESOLVED -- now webhooks_controller.rb
Missing Gemfile from file targets	[BODY]	RESOLVED -- Gemfile now listed
Manual/code ACs not separated	[BODY]	RESOLVED -- clear Manual/Code headers
story:WS-AUTH not registered	[SCOPE]	DEFERRED -- acknowledged, not blocking
arch-app-store note missing	[SCOPE]	DEFERRED -- acknowledged, not blocking

Recommendation

No blocking action needed. All [BODY] issues resolved. Ticket is ready for agent execution.

Deferred items for future cleanup:

• [SCOPE] Register story:WS-AUTH (or assign a new WS-S## code) on project-westside-basketball user-stories section.
• [SCOPE] Create architecture note arch-app-store for the App Store subscription component.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — references sibling App Store ticket and #58
• [x] Repo — ldraney/westside-basketball
• [x] User Story — admin wants subscription status on player detail page
• [x] Context — describes StoreKit renewal states
• [x] File Targets — 5 modify/create, 1 do-not-touch
• [x] Feature Flag — none (admin-only, acceptable)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — 3 test items with run command
• [x] Constraints — 3 constraints listed
• [x] Checklist — present
• [x] Related — project-westside-basketball

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what" — verified in project-westside-basketball user-stories section
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-rails-views for component rails-views. No matching note found in pal-e-docs.
• [x] Forgejo issue — ldraney/westside-basketball#66, state: open

File Targets

• [ ] app/models/subscription.rb — ISSUE: New file, but conflicts with existing Stripe-based subscription tracking on Player model. Player already has subscription_status enum (active/past_due/canceled/none) and stripe_subscription_id. Creating a separate Subscription model with Apple StoreKit states introduces two incompatible subscription systems with no documented coexistence or migration strategy.
• [ ] db/migrate/*_create_subscriptions.rb — ISSUE: New table, but the existing subscriptionstatus Postgres enum on players (active/past_due/canceled/none) conflicts with the proposed Apple states (subscribed/grace_period/billing_retry/expired/revoked). No migration plan for existing data.
• [ ] app/views/admin/players/show.html.erb — ISSUE: File does not exist. Issue #58 (player detail page) is marked done on board (item 1609) but the show view, controller action, and route are NOT present in main. Only index.html.erb exists in app/views/admin/players/. Controller has no def show. Routes: resources :players, only: [:index].
• [ ] app/views/admin/players/_subscription_badge.html.erb — ISSUE: Badge partial proposed, but application_helper.rb already defines subscription_badge_variant and subscription_badge_label helpers used by the existing index view. The new badge would need to coexist with or replace the existing badge system.
• [x] app/models/player.rb — verified: exists with 10 associations (belongs_to :parent, :tenant; has_many :player_teams, :teams, :contract_audit_logs, :email_logs, :orders, :payment_links, :registrations, :jersey_public_orders). No existing has_one :subscription.

Repo Placement

OK — issue is filed on ldraney/westside-basketball, which is the correct repo for the Rails app models and admin views.

Dependencies

• depends:65 NOT MET — Issue #65 ("Configure App Store Connect subscription product and billing grace period") is in backlog (board item 1610) and open on Forgejo. This ticket provides the App Store Server Notifications v2 webhook endpoint that #66 depends on for AC #4 ("When webhook updates subscription state, badge reflects new state on next page load").
• depends:58 (implicit) — Issue #58 ("Admin player detail page") is marked done on board but show.html.erb does not exist in main. The code may not be merged or deployed. This ticket targets show.html.erb which doesn't exist.
• Existing Stripe system undocumented — The dependency on the existing Stripe subscription system (webhooks_controller.rb handles customer.subscription.updated/deleted, Player has stripe_subscription_id and subscription_status) is not documented. The issue does not explain whether Apple StoreKit replaces Stripe or runs alongside it.

Acceptance Criteria

• [x] AC1: "Subscription model persists StoreKit renewal states per player" — testable but architecturally conflicted with existing Stripe model
• [ ] AC2: "Player detail page shows color-coded subscription badge" — NOT testable: show.html.erb doesn't exist yet
• [ ] AC3: "Player list page shows subscription status indicator per row" — ALREADY EXISTS: index.html.erb already renders subscription_badge_variant and subscription_badge_label via existing Stripe-based subscription_status. This AC is redundant unless it means Apple-specific badges, which is unclear.
• [ ] AC4: "When webhook updates subscription state, badge reflects new state" — NOT testable: depends on #65 (App Store webhook) which is in backlog
• [x] AC5: "Players without subscriptions show 'No subscription' gracefully" — testable

Blast Radius

• Existing subscription UI will break or conflict — admin/players/index.html.erb, admin/delinquency_report, admin/roster_report, and application_helper.rb all reference Player#subscription_status (Stripe-based). A new Subscription model with different states will create confusion about which status is authoritative.
• webhooks_controller.rb — existing Stripe webhook handler updates Player#subscription_status directly. The proposed app_store_controller.rb (from #65) would update the new Subscription model. Two webhook handlers updating two different subscription tracking systems.
• stripe_client.rb — has update_subscription_price and create_subscription_payment_link methods. These won't know about Apple subscriptions.

Decomposition Assessment

5 file targets across 1 repo, 5 acceptance criteria. Fits within the 5-minute rule on surface count, BUT the architectural conflict with the existing Stripe subscription system makes this ticket fundamentally under-scoped. The ticket cannot be implemented as-written without first deciding the Stripe-vs-Apple coexistence strategy. No decomposition needed — scope clarification needed first.

Recommendation

• [SCOPE] Resolve Stripe vs Apple StoreKit coexistence strategy before implementation. The codebase has a fully functional Stripe subscription system (Player#subscription_status, webhooks_controller.rb, stripe_client.rb, admin views). The issue proposes an Apple StoreKit system without acknowledging the existing one. Decision needed: replace Stripe with Apple? Run both? Migrate?
• [BODY] Fix file target: app/views/admin/players/show.html.erb does not exist. Depends on #58 being merged first, or this ticket must include creating the show view.
• [BODY] Remove or clarify AC #3 ("Player list page shows subscription status indicator per row") — this already exists for Stripe-based status. Clarify whether this means adding Apple-specific status alongside.
• [BODY] Add context about existing Stripe subscription system: Player already has subscription_status enum (active/past_due/canceled/none) and stripe_subscription_id. Explain coexistence or migration plan.
• [BODY] Update AC #4 to not depend on #65 webhook, or explicitly mark it as blocked until #65 ships.
• [SCOPE] Create architecture note arch-rails-views for component rails-views.

Verdict: APPROVED

Ground truth verified via direct grep -rn westside-ror overlays/ on cloned repo. Three prior review rounds had conflicting claims about prod overlay state. This review resolves the conflict with evidence.

Template Completeness

• [x] Type — Bug
• [x] Lineage — Sub-ticket of #220
• [x] Repo — ldraney/pal-e-deployments
• [x] What Broke — stale references + missing funnel ingress
• [x] Repro Steps — 3 steps with grep command
• [x] Expected Behavior — 5 bullets
• [x] Environment — prod namespace, file list with counts
• [x] Acceptance Criteria — 8 checkboxes, all verifiable
• [x] Related — parent, predecessor, 3 review notes, project page

Traceability

• [x] story:WS-S1 — superadmin IaC
• [x] arch:iac label
• [x] Forgejo issue — pal-e-deployments#221, open

File Targets

Verified via grep -rn westside-ror on cloned repo:

• [x] overlays/westside-ror/prod/ — ZERO stale references. Clean.
• [x] overlays/westside-ror/dev/deployment.yaml — 5 stale refs (lines 4, 5, 10, 14, 47)
• [x] overlays/westside-ror/dev/service.yaml — 4 stale refs (lines 4, 5, 7, 10)
• [x] overlays/westside-ror/dev/ingress.yaml — 4 stale refs (lines 4, 5, 12, 17)
• [x] overlays/westside-ror/README.md — 6 stale refs (lines 1, 5, 6, 9, 19, 27)
• [x] overlays/westsidekingsandqueens/README.md — 1 stale ref (line 5)

Total: 20 stale references across 5 files.

Repo Placement

Correct. All files in pal-e-deployments, issue filed there.

Dependencies

• Parent: pal-e-deployments#220 (decomposed)
• Predecessor: #219 (namespace hotfix, merged)
• Siblings: #1632, #1633, #1634 — independent, no ordering constraints

Acceptance Criteria

8 ACs, all agent-verifiable. Directory rename + find-replace + new funnel ingress file.

Blast Radius

Contained to overlay directory. ArgoCD application manifest may reference old path — verify during implementation.

Decomposition Assessment

No decomposition needed. 5 file edits + 1 directory rename + 1 new file. Single repo. ~3 min agent work.

Recommendation

No action needed. Issue body is accurate after 3 rounds of refinement with grep-verified ground truth.

Verdict: NEEDS_REFINEMENT

Re-review after refinement. The previous [BODY] recommendation (add README.md coverage) has been addressed. However, file target verification reveals factual inaccuracies in the issue body that would mislead an implementing agent.

Template Completeness

• [x] Type — Bug
• [x] Lineage — Sub-ticket of #220, discovered during sprint 5 validation
• [x] Repo — ldraney/pal-e-deployments
• [x] What Broke — describes stale references and missing funnel ingress
• [x] Repro Steps — 3 concrete steps with grep command
• [x] Expected Behavior — 6 bullet points covering rename + funnel + dev + westsidekingsandqueens + README
• [x] Environment — prod, westside-basketball namespace, lists related files
• [x] Acceptance Criteria — 9 checkboxes
• [x] Related — parent issue, predecessor, review notes, project page

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section (Superadmin list, first entry)
• [x] arch:iac label — infrastructure-as-code component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-iac for the IaC component (carried forward from r1, cross-cutting concern, deferrable)
• [x] Forgejo issue — ldraney/pal-e-deployments#221, open

File Targets

• [x] overlays/westside-ror/ directory — verified: exists with prod/, dev/, README.md subdirectories. Directory itself needs renaming to westside-basketball/.
• [x] overlays/westside-ror/prod/kustomization.yaml — verified: ALREADY references westside-basketball, NOT westside-ror. Zero stale references. Issue body incorrectly claims "10+ stale references in kustomization.yaml (6 env var patches)."
• [x] overlays/westside-ror/prod/deployment-patch.yaml — verified: ALREADY correct. Zero stale westside-ror references. No hostPath line. Issue body incorrectly claims stale "resource names, labels, selectors, hostPath."
• [ ] overlays/westside-ror/dev/deployment.yaml — ISSUE: 5 stale references (name, namespace, selector, label, hostPath /home/ldraney/westside-ror). Correctly identified in issue.
• [ ] overlays/westside-ror/dev/service.yaml — ISSUE: 4 stale references (name, namespace, label, selector). Correctly identified in issue.
• [ ] overlays/westside-ror/dev/ingress.yaml — ISSUE: 4 stale references (name, namespace, backend service, TLS host). Correctly identified in issue.
• [x] overlays/westside-ror/dev/kustomization.yaml — verified: 0 stale references (just resource list). No action needed.
• [ ] overlays/westside-ror/README.md — ISSUE: 6 stale references (title, URL, namespace, source path, volume mount, apply command). Correctly identified in issue (new in this revision).
• [ ] overlays/westsidekingsandqueens/prod/kustomization.yaml — ISSUE: No stale westside-ror comment exists. The issue claims "line 6 referencing 'westside-ror namespace'" but line 6 is - ingress.yaml. No line in this file contains "westside-ror". AC6 and the Expected Behavior bullet referencing this file are incorrect.

Actual stale reference count: 19 across 4 files (dev/deployment.yaml: 5, dev/service.yaml: 4, dev/ingress.yaml: 4, README.md: 6). The prod overlay already uses westside-basketball. The westsidekingsandqueens overlay has no westside-ror references.

Repo Placement

OK. Issue filed on pal-e-deployments, all affected files are in pal-e-deployments. Single-repo change.

Dependencies

• Parent issue #220 (board item 1630) — decomposed, in backlog. This is sub-ticket 1 of 4.
• Sibling sub-tickets in backlog: #1632 (NetworkPolicy update, 1pt), #1633 (drop stale DB role, 2pt), #1634 (CI fix, 1pt)
• Predecessor #219 (namespace hotfix) — already merged
• No blocking dependencies — this ticket can proceed independently of siblings

Acceptance Criteria

9 ACs listed. Assessment:

• AC1 (rename directory): valid, verifiable via ls overlays/westside-basketball
• AC2 (resource names/labels/selectors): misleading — prod already correct, only dev needs updating. Should specify "dev overlay" scope.
• AC3 (deployment-patch hostPath): incorrect — prod deployment-patch.yaml has no westside-ror hostPath. The stale hostPath is in dev/deployment.yaml.
• AC4 (env var patches in kustomization.yaml): incorrect — prod kustomization.yaml already references westside-basketball. Zero stale env var patches.
• AC5 (Tailscale funnel ingress in prod): valid — prod has no ingress resource currently, dev has one that can serve as a template.
• AC6 (westsidekingsandqueens comment): incorrect — no such comment exists in the file.
• AC7 (README.md update): valid, verifiable via grep.
• AC8 (ArgoCD sync): valid post-merge criterion.
• AC9 (no stale references): valid, verifiable via grep -r westside-ror overlays/westside-basketball/

ACs 2, 3, 4, and 6 contain factual errors that would confuse an implementing agent. The agent would waste time looking for stale references that don't exist in prod, and might incorrectly modify the westsidekingsandqueens overlay.

Blast Radius

• Renaming the directory (git mv overlays/westside-ror overlays/westside-basketball) will require updating any ArgoCD Application manifest that references the old path. Verify ArgoCD config is not in scope (it may be in pal-e-services).
• No other overlays reference westside-ror — blast radius is contained.
• The dev overlay ingress has the Tailscale funnel pattern — can serve as template for the prod ingress resource (AC5).

Decomposition Assessment

Corrected scope: ~4 file edits (dev/deployment.yaml, dev/service.yaml, dev/ingress.yaml, README.md) + 1 directory rename + 1 new file (prod ingress). Estimated agent work: ~3 minutes. No decomposition needed.

Recommendation

• [BODY] Remove or correct "What Broke" claim about "10+ stale references in kustomization.yaml (6 env var patches) and deployment-patch.yaml" — these prod files are already correct. The stale references are only in the dev overlay and README.md.
• [BODY] Remove or correct the claim about westsidekingsandqueens overlay having a stale "westside-ror namespace" comment — no such comment exists in the file.
• [BODY] Correct AC2 to specify "dev overlay" scope: resource names/labels/selectors in dev/deployment.yaml, dev/service.yaml, dev/ingress.yaml.
• [BODY] Correct AC3: the stale hostPath is in dev/deployment.yaml line 47, not in deployment-patch.yaml.
• [BODY] Remove AC4 (env var patches already correct) or rephrase to target dev overlay.
• [BODY] Remove AC6 (westsidekingsandqueens comment does not exist).
• [BODY] Correct Repro Step 1 grep target scope to overlays/westside-ror/dev/ and overlays/westside-ror/README.md (prod returns zero hits).
• [SCOPE] Create architecture note arch-iac for the IaC component (carried forward, deferrable).

Verdict: READY

Re-review of board item #1634 after refinement. Previous review review-1634-2026-06-27 found NEEDS_REFINEMENT due to incorrect AC2 (OVERLAY rename), wrong OVERLAY references in What Broke, and hedged file path. All three [BODY] recommendations have been addressed in the updated issue.

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Sub-ticket of pal-e-deployments #220, decomposed per review-1630-2026-06-27
• [x] Repo -- ldraney/westside-basketball
• [x] What Broke -- clear description of status filter overriding depends_on semantics. No longer contains incorrect OVERLAY references.
• [x] Repro Steps -- 3 steps, reproducible
• [x] Expected Behavior -- clear
• [x] Environment -- Woodpecker CI, .woodpecker.yaml line 121
• [x] Acceptance Criteria -- 3 criteria, all testable
• [x] Related -- parent issue, predecessor, review notes, project page
• [x] Blast Radius Note -- documents same bug in paldocs and pal-e-platform template

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified -- found in project-westside-basketball user-stories section (Superadmin list, WS-S1)
• [ ] arch note MISSING -- [SCOPE] No architecture note found for arch-iac. Search returned zero results. This is a cross-cutting gap shared by multiple tickets using this label -- not a blocker for this specific ticket.
• [x] Forgejo issue -- ldraney/westside-basketball#77, state: open

File Targets

• [x] .woodpecker.yaml -- verified: file exists at repo root
• [x] Line 121 status: [success, failure] -- verified: exact match at line 121
• [x] Lines 116-117 depends_on: [build-and-push] -- verified: lines 116-117 contain depends_on: and - build-and-push

No OVERLAY file target references remain in the issue -- correctly removed per first review.

Repo Placement

Correct. Fix targets .woodpecker.yaml in ldraney/westside-basketball; Forgejo issue filed there. Blast radius note correctly identifies that the template source at pal-e-platform/scripts/woodpecker-update-tag-step.yaml needs a separate ticket.

Dependencies

• No blocking items in in_progress. Three in-progress items are unrelated plan-level phases (Phase 14, 11, 15).
• Parent issue: pal-e-deployments #220 -- this is a decomposition child.
• Predecessor: westside-basketball #69 (CI test failures) -- already merged.
• No board items block or are blocked by this ticket.

Acceptance Criteria

• AC1: "status: [success, failure] changed to status: [success] (or removed)" -- agent-verifiable, one-line change
• AC2: "CI pipeline tested: update-kustomize-tag does NOT run when build-and-push fails" -- verifiable via Woodpecker pipeline observation. Requires a failing build trigger.
• AC3: "CI pipeline tested: update-kustomize-tag DOES run when build-and-push succeeds" -- verifiable, normal push to main.

All 3 criteria are testable. AC1 is automatable. AC2 and AC3 require pipeline observation but are clearly defined.

Blast Radius

Documented in the issue itself. The same status: [success, failure] pattern exists in:

• paldocs/.woodpecker.yaml:121 -- identical bug
• pal-e-platform/scripts/woodpecker-update-tag-step.yaml:45 -- canonical template

The issue correctly notes these need separate tickets. No downstream consumers beyond the repos already identified.

Decomposition Assessment

No decomposition needed. 1 file target, 1 repo, 3 acceptance criteria, one-line code change. Estimated agent work: under 2 minutes. Well within the 5-minute rule.

Previous Review Recommendations -- Resolution

• [BODY] Remove AC2 (OVERLAY rename) -- DONE. AC2 removed from issue body.
• [BODY] Remove incorrect OVERLAY sentence from What Broke -- DONE. OVERLAY references removed.
• [BODY] Clarify file path to .woodpecker.yaml -- DONE. Issue now definitively states .woodpecker.yaml.
• [SCOPE] Create arch note arch-iac -- OPEN. Cross-cutting gap, not a blocker for this ticket.

Recommendation

No action needed. Ticket is ready for implementation.

Standing [SCOPE] note: Create architecture note arch-iac for the IaC component. This is a cross-cutting gap affecting multiple tickets with the arch:iac label and should be addressed separately.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Sub-ticket of pal-e-deployments #220, discovered during sprint 5 validation
• [x] Repo -- ldraney/westside-basketball
• [x] What Broke -- clear description of status filter overriding depends_on semantics
• [x] Repro Steps -- 3 steps, reproducible
• [x] Expected Behavior -- clear
• [x] Environment -- Woodpecker CI, file paths identified
• [x] Acceptance Criteria -- 4 criteria, testable
• [x] Related -- parent issue, predecessor, review note, project page

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified -- found in project-westside-basketball user-stories section (Superadmin list, WS-S1)
• [ ] arch note MISSING -- [SCOPE] No architecture note found for arch-iac. Search for "arch-iac" returned zero results. Create architecture note arch-iac for the IaC component.
• [x] Forgejo issue -- ldraney/westside-basketball#77, state: open

File Targets

• [x] .woodpecker.yaml -- verified: file exists at repo root (not .woodpecker/ci.yaml as issue hedges). Issue mentions both possible names; the actual file is .woodpecker.yaml.
• [x] Line ~121 status: [success, failure] -- verified: exact match at line 121
• [x] Lines 116-117 depends_on: [build-and-push] -- verified: lines 116-117 contain depends_on: and - build-and-push
• [x] Line ~110 OVERLAY: "westside-ror" -- verified: exact match at line 110
• [ ] OVERLAY target value -- ISSUE: Issue says change OVERLAY to westside-basketball, but no overlay directory westside-basketball exists in pal-e-deployments. The existing overlays are westside-ror (Rails app) and westsidekingsandqueens (frontend). The value westside-ror correctly maps to overlays/westside-ror/prod/kustomization.yaml which exists. The pal-e-platform template mapping comment confirms westside-app -> OVERLAY=westsidekingsandqueens and does not list a westside-basketball overlay.

Repo Placement

Correct. The fix is in .woodpecker.yaml which lives in ldraney/westside-basketball and the Forgejo issue is filed there. However, the template source at pal-e-platform/scripts/woodpecker-update-tag-step.yaml also has the same status: [success, failure] pattern and should be fixed separately to prevent future onboarding of the bug.

Dependencies

• No blocking items in in_progress. The three in-progress items (Phase 14, Phase 11, Phase 15) are unrelated plan-level phases.
• Parent issue: pal-e-deployments #220 -- this is a decomposition child.
• Predecessor: westside-basketball #69 (CI test failures) -- already merged.
• No board items block or are blocked by this ticket.

Acceptance Criteria

• AC1: "status changed to [success] or removed" -- agent-verifiable, one-line sed change
• AC2: "OVERLAY updated from westside-ror to westside-basketball" -- INVALID. No westside-basketball overlay exists. This AC must be corrected or removed. If the intent is to rename the overlay directory, that is a separate pal-e-deployments change not scoped here.
• AC3: "CI pipeline tested: does NOT run on failure" -- verifiable in Woodpecker but requires triggering a real build failure. May need manual verification or a targeted test commit.
• AC4: "CI pipeline tested: DOES run on success" -- verifiable, normal push to main.

Blast Radius

HIGH. The same status: [success, failure] pattern exists in:

• paldocs/.woodpecker.yaml:121 -- identical bug
• pal-e-platform/scripts/woodpecker-update-tag-step.yaml:45 -- the canonical template that all new repos copy from
• Multiple worktree copies of the template (stale, not actionable)

Fixing only westside-basketball leaves the bug alive in paldocs and baked into the template for future repos. The template fix should be a separate ticket on pal-e-platform.

Decomposition Assessment

No decomposition needed. 1 file target, 1 repo, the valid fix is a one-line change (remove or change the status filter). Estimated agent work: under 2 minutes. Well within the 5-minute rule.

Recommendation

• [BODY] Remove AC2 entirely ("OVERLAY updated from westside-ror to westside-basketball"). The overlay westside-ror is the correct value -- no westside-basketball overlay exists in pal-e-deployments. Alternatively, if a rename is intended, it must be a separate ticket scoped to pal-e-deployments.
• [BODY] Remove the sentence in "What Broke" that says "the OVERLAY env var still references westside-ror and needs to change to westside-basketball" -- this is factually incorrect per current infrastructure.
• [BODY] Clarify the file path: the file is .woodpecker.yaml (not .woodpecker/ci.yaml). Remove the hedging "(or .woodpecker.yaml)" and state the definitive path.
• [SCOPE] Create architecture note arch-iac for the IaC component. The arch:iac label is used but no backing note exists in pal-e-docs.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Bug
• [x] Lineage — Sub-ticket of #220, discovered during sprint 5 validation
• [x] Repo — ldraney/pal-e-deployments
• [x] What Broke — stale westside-ror references, missing funnel ingress in prod
• [x] Repro Steps — 3 concrete steps with grep command
• [x] Expected Behavior — 5 bullet points covering rename + funnel + dev + westsidekingsandqueens
• [x] Environment — prod, westside-basketball namespace
• [x] Acceptance Criteria — 8 checkboxes
• [x] Related — parent issue, predecessor, review note, project page

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section (Superadmin list, first entry)
• [x] arch:iac label — infrastructure-as-code component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-iac for the IaC component
• [x] Forgejo issue — ldraney/pal-e-deployments#221, open

File Targets

• [x] overlays/westside-ror/prod/kustomization.yaml — verified: 9 stale westside-ror references (6 env var patches, comment, service rename, deployment rename)
• [x] overlays/westside-ror/prod/deployment-patch.yaml — verified: 1 stale hostPath reference (/home/ldraney/westside-ror on line 58)
• [x] overlays/westside-ror/dev/deployment.yaml — verified: 5 stale references (name, namespace, labels, hostPath)
• [x] overlays/westside-ror/dev/service.yaml — verified: 4 stale references (name, namespace, labels, selector)
• [x] overlays/westside-ror/dev/ingress.yaml — verified: 4 stale references (name, namespace, backend service, TLS host)
• [x] overlays/westside-ror/dev/kustomization.yaml — verified: 0 stale references (just resource list)
• [x] overlays/westsidekingsandqueens/prod/kustomization.yaml — verified: line 6 has stale comment "westside-ror namespace"
• [ ] overlays/westside-ror/README.md — ISSUE: [BODY] Not mentioned in issue body but has 6 stale westside-ror references. Should be included in scope or deleted during rename.

Total stale references: 29 across 7 files (prod: 10, dev: 13, westsidekingsandqueens: 1, README: 6). Issue claims "10+" which is accurate for prod but undercounts the total.

Repo Placement

OK. Issue filed on pal-e-deployments, all affected files are in pal-e-deployments. Single-repo change.

Dependencies

• Parent issue #220 (board item 1630) — decomposed, in backlog. This is sub-ticket 1 of 4.
• Sibling sub-tickets in backlog: #1632 (NetworkPolicy update, 1pt), #1633 (drop stale DB role, 2pt), #1634 (CI fix, 1pt)
• Predecessor #219 (namespace hotfix) — already merged
• No blocking dependencies — this ticket can proceed independently of siblings

Acceptance Criteria

8 ACs listed. All are verifiable by an agent:

• ACs 1-6: mechanical rename + file additions, verifiable via grep and file existence checks
• AC 7 (ArgoCD sync): requires cluster access, may not be automatable in agent pass — but reasonable as a post-merge validation criterion
• AC 8 (no stale references): verifiable via grep -r westside-ror

AC count (8) exceeds the 5-AC decomposition threshold on paper. However, ACs 1-6 are a single coherent rename operation (one git mv + find-replace), not 6 independent tasks. No decomposition needed.

Blast Radius

• The overlays/westside-ror/README.md has 6 stale references not mentioned in the issue. An agent doing the rename would likely miss updating it or removing it.
• No other overlays reference westside-ror — blast radius is contained to the westside-ror/ directory and one comment in westsidekingsandqueens/.
• The dev overlay ingress already has the correct Tailscale funnel pattern — the prod overlay just needs an equivalent ingress resource added.

Decomposition Assessment

8 ACs across 1 repo, ~7 file targets. ACs 1-6 are a single atomic rename. Estimated agent work: ~3 minutes (git mv + sed + add ingress resource). No decomposition needed despite AC count exceeding threshold.

Recommendation

• [BODY] Add overlays/westside-ror/README.md to file targets or add AC: "README.md updated or removed during rename"
• [SCOPE] Create architecture note arch-iac for the IaC component (this is a cross-cutting concern, not specific to this ticket — can be deferred)

Verdict: READY

Note: Both READY and APPROVED are accepted as passing verdicts by the check-board-advance hook. Use either keyword interchangeably.

Template Completeness

• [x] Type
• [x] Lineage
• [x] Repo
• [x] What Broke
• [x] Repro Steps
• [x] Expected Behavior
• [x] Environment
• [x] Acceptance Criteria
• [x] Related

All required sections for template-issue-bug are present.

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section (Superadmin list)
• [x] arch:iac label — infrastructure-as-code component
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-iac for component iac (systemic gap, not a blocker for this ticket)
• [x] Forgejo issue — ldraney/pal-e-platform#475, open

File Targets

• [x] terraform/network-policies.tf — verified: westside-ror namespace selector found at line 178 (issue says line 181, off by 3 — minor discrepancy, does not affect implementation)
• [x] Only one occurrence of westside-ror in the entire pal-e-platform terraform codebase — clean single-line fix

Repo Placement

OK. Issue filed on ldraney/pal-e-platform, fix is in ldraney/pal-e-platform. Single-repo change.

Dependencies

• Sibling ticket #1631 (Add Tailscale funnel ingress + rename westside-ror overlay to westside-basketball, 3pts) — coordinates the overlay rename. This NetworkPolicy fix is logically independent: it can be applied before or after the overlay rename without conflict. The namespace selector just needs to match the target state.
• Sibling ticket #1633 (Drop stale basketball DB role + update Keycloak westside-ror references, 2pts) — different systems (DB role + Keycloak), no ordering dependency.
• Parent issue: ldraney/pal-e-deployments#220 — decomposed per review-1630-2026-06-27.
• No blockers in in_progress column.

Acceptance Criteria

4 criteria, all verifiable by an agent:

• [x] network-policies.tf namespace selector updated — verifiable via grep
• [x] terraform plan shows only expected change — verifiable via CLI
• [x] terraform apply succeeds — verifiable via CLI
• [x] No regression in other namespace NetworkPolicies — verifiable via grep for unchanged entries

Blast Radius

Minimal. Only 1 occurrence of westside-ror across all .tf files in pal-e-platform. No other terraform files reference this namespace. No downstream consumers affected — this is a NetworkPolicy ingress rule allowing a specific namespace to reach postgres. Changing the selector only affects the westside app's postgres access path.

Decomposition Assessment

No decomposition needed. 1 file target, 1 repo, 4 acceptance criteria, estimated agent work well under 5 minutes. Single-line string replacement.

Recommendation

• [BODY] Fix line reference: line 181 should be line 178 (minor, non-blocking)
• [SCOPE] Create architecture note arch-iac for component iac (systemic gap across multiple sibling tickets — not a blocker for this ticket)

No action needed to proceed — ticket is READY.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Bug
• [x] Lineage — discovered during sprint 5 validation
• [x] Repo — ldraney/pal-e-deployments
• [x] What Broke — five manual fixes described
• [x] Repro Steps — ArgoCD resync scenario
• [x] Expected Behavior — full IaC, no manual intervention
• [x] Environment — prod, westside-basketball namespace
• [x] Acceptance Criteria — 8 items listed
• [x] Related — references SOPs and related PRs

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section (Superadmin block)
• [x] arch:iac label — present on board item
• [ ] arch note MISSING — [SCOPE] No architecture note arch-iac found in pal-e-docs. Create architecture note for the IaC component.
• [x] Forgejo issue — ldraney/pal-e-deployments#220, state: open

File Targets

• [x] pal-e-deployments/overlays/westside-ror/prod/ — verified: directory exists, contains kustomization.yaml and deployment-patch.yaml with 10+ westside-ror references needing rename
• [x] pal-e-deployments/overlays/westside-ror/prod/kustomization.yaml — verified: 6 occurrences of value: westside-ror in env var patches
• [x] pal-e-services/terraform/k3s.tfvars line 274 — verified: source_path = "overlays/westside-ror/prod" needs update to westside-basketball
• [x] pal-e-platform/terraform/network-policies.tf line 181 — verified: westside-ror namespace selector in postgres ingress rules
• [x] westside-basketball/.woodpecker.yaml line 110 — verified: OVERLAY: "westside-ror" needs update
• [ ] westside-basketball/.woodpecker.yaml depends_on — ISSUE: ticket says update-kustomize-tag needs depends_on: [build-and-push], but this ALREADY EXISTS (lines 116-117). The actual bug is status: [success, failure] on line 121 which causes the step to run even when build-and-push fails. Ticket body needs correction.
• [ ] Database role changes — ISSUE: ticket mentions dropping stale basketball role and reassigning ownership, but does not specify which repo/file contains this IaC. The k3s.tfvars (line 22) shows databases = ["basketball", ...] — these database names also use the old convention. No file target given for the DB role fix.

Additional Findings (not in ticket)

• [ ] pal-e-services/terraform/k3s.tfvars lines 156-175 — Keycloak config has 5 stale westside-ror references (client_id, redirect URIs, root_url, web_origins). These will break auth if overlay is renamed without updating Keycloak config.
• [ ] pal-e-deployments/overlays/westsidekingsandqueens/prod/kustomization.yaml line 6 — comment says "ingress.yaml removed — westsidekingsandqueens URL now served by westside-ror namespace." This comment becomes stale after rename and the relationship between the two overlays is not documented in the ticket.
• [ ] pal-e-deployments/overlays/westside-ror/dev/ — dev overlay has service.yaml, deployment.yaml, ingress.yaml all with westside-ror references. Not mentioned in ticket scope.
• [ ] pal-e-deployments/overlays/westside-ror/prod/deployment-patch.yaml line — has path: /home/ldraney/westside-ror hostPath reference

Repo Placement

The Forgejo issue is filed on pal-e-deployments, which is the primary repo for the overlay rename. However, the ticket explicitly touches 4 repos: pal-e-deployments (overlay), pal-e-platform (NetworkPolicy), pal-e-services (k3s.tfvars + Keycloak), and westside-basketball (CI). This is a multi-repo fix that needs either multiple Forgejo issues or explicit sub-task tracking.

Dependencies

• No blocking items found in in_progress or next_up columns
• Closed issue #218 and PR #219 (namespace hotfix) are related predecessors — already merged
• Implicit ordering: overlay rename must happen before source_path update, or ArgoCD will break
• Keycloak redirect URIs must update simultaneously with overlay rename or auth breaks

Acceptance Criteria

8 acceptance criteria listed. Assessment:

• AC1 (funnel ingress in overlay): Verifiable — check file exists in kustomization
• AC2 (overlay rename): Verifiable — check directory name and resource names
• AC3 (source_path update): Verifiable — grep k3s.tfvars
• AC4 (NetworkPolicy): Verifiable — grep network-policies.tf
• AC5 (drop basketball role): NOT verifiable by agent — requires DB access, no IaC file target specified
• AC6 (CI depends_on): ALREADY DONE — depends_on exists. Real fix is removing status: [success, failure]
• AC7 (ArgoCD sync): Integration test — requires cluster access, not agent-verifiable
• AC8 (SOP updated): Already marked done in ticket

Blast Radius

• Keycloak redirect URIs at lines 165-175 of k3s.tfvars still reference westside-ror.tail5b443a.ts.net. If the Tailscale hostname changes with the rename, auth will break for all users.
• The westsidekingsandqueens overlay has its own prod directory with a separate ingress.yaml pointing to service westside-app. The relationship between these two overlays and which one ArgoCD actually uses needs documentation.
• Harbor image repo is already westside-basketball/app (correct), but the westsidekingsandqueens overlay references harbor.tail5b443a.ts.net/westsidekingsandqueens/app — a different image path. Unclear which is canonical.

Decomposition Assessment

NEEDS DECOMPOSITION — This ticket exceeds the 5-minute rule on multiple dimensions:

• File targets: 6+ files across 4 repos (threshold: >3 files across >2 repos)
• Acceptance criteria: 8 items (threshold: >5)
• Estimated agent work: 15-20 minutes across 4 repos with terraform apply + ArgoCD sync verification
• Points: 3 pts is too low for this scope — realistic estimate is 8+ pts

Recommended decomposition into 4 sub-tickets by repo:

1. pal-e-deployments: Rename overlay directory, add funnel ingress to prod kustomization, update all resource names (3pts)
2. pal-e-services: Update source_path in k3s.tfvars, fix Keycloak redirect URIs (2pts)
3. pal-e-platform: Update NetworkPolicy namespace selector (1pt)
4. westside-basketball: Fix OVERLAY env var in CI, remove status: [success, failure] from update-kustomize-tag step (1pt)

Database role cleanup (AC5) needs a separate spike — no IaC file target exists for it today.

Recommendation

• [BODY] Fix AC6: depends_on: [build-and-push] already exists. The real bug is status: [success, failure] on line 121 which causes update-kustomize-tag to run even when build-and-push fails. Rewrite AC to: "Remove status: [success, failure] from update-kustomize-tag when clause"
• [BODY] Add missing file targets: Keycloak redirect URIs in pal-e-services/terraform/k3s.tfvars lines 156-175 (5 stale westside-ror references)
• [BODY] Add file target for database role cleanup or split into separate spike ticket
• [BODY] Document the westsidekingsandqueens vs westside-ror overlay relationship and which one ArgoCD uses
• [SCOPE] Create architecture note arch-iac for the IaC component
• [DECOMPOSE] 8 AC across 4 repos, estimated 15-20 min agent work. Route to skill-decompose-ticket for sub-ticket creation by repo.

Verdict: READY

Scope is solid, all file targets verified, traceability complete (story note present, arch note missing but non-blocking), fits in a single agent pass.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, discovered during Sprint 5 validation
• [x] Repo -- ldraney/pal-e-services
• [x] User Story -- Platform operator / rails-env secret in IaC
• [x] Context -- Clear motivation, references existing harbor_creds pattern
• [x] File Targets -- 3 files to modify, 2 exclusions documented
• [x] Feature Flag -- none (correct, infrastructure work)
• [x] Acceptance Criteria -- 6 criteria covering plan, apply, and runtime
• [x] Test Expectations -- tofu plan + kubectl verification
• [x] Constraints -- Pattern reference, sensitive vars, DB prerequisite noted
• [x] Checklist -- Standard PR checklist
• [x] Related -- Sprint 5 context, upstream dependencies

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified -- found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:iac label -- infrastructure-as-code component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-iac for component iac. Non-blocking: the arch:iac label is semantically correct and the work pattern (terraform resources) is well-established in this repo.
• [x] Forgejo issue -- ldraney/pal-e-services#150, open

File Targets

• [x] terraform/services.tf -- verified: file exists (245 lines), contains kubernetes_secret_v1.harbor_creds pattern at line 127 that the new resource should follow. No existing rails-env resource.
• [x] terraform/variables.tf -- verified: file exists (248 lines), contains existing credential variables (e.g., paledocs_db_password, cnpg_superuser_password) with sensitive = true. Has service_databases map variable that could be an alternative pattern, but standalone variables match the ticket's approach.
• [x] terraform/k3s.tfvars -- verified: file exists (symlink to ~/secrets/pal-e-services/k3s.tfvars), contains credential values for other services. westside-basketball service entry present at line 262.
• [x] terraform/cnpg.tf (exclusion) -- verified: file exists, CNPG cluster named pal-e-postgres in postgres namespace. Correctly excluded from scope.
• [x] terraform/keycloak.tf (exclusion) -- confirmed unrelated

Repo Placement

Correct. The Forgejo issue is filed on ldraney/pal-e-services and all file targets are in that repo's terraform/ directory. Single-repo change, no cross-repo coordination needed.

Dependencies

• westside-basketball#69 (CI fix) -- in validation column, merged. Image in Harbor. Not a blocker for this ticket.
• pal-e-deployments#219 (namespace fix) -- in validation column, merged. Deployment overlay at overlays/westside-ror/prod references rails-env secret at line 29 of deployment-patch.yaml. Confirmed.
• Database prerequisite -- The basketball database must exist on the CNPG cluster. Issue correctly notes this as a manual step outside terraform scope. This is a runtime dependency, not a ticket dependency.
• Namespace alignment -- The service key is westside-basketball (namespace), but ArgoCD source_path is overlays/westside-ror/prod. The kustomize renames the deployment to westside-ror within the westside-basketball namespace. The secret must be created in namespace westside-basketball, which is what the ticket specifies. Correct.

Acceptance Criteria

All 6 AC are verifiable by an agent:

• AC1-3: Structural checks on terraform code -- agent can verify via file read
• AC4-5: tofu plan and tofu apply -- agent can run these commands (CI pipeline exists)
• AC6: Pod starts without CreateContainerConfigError -- verifiable via kubectl, though requires the database to exist first (noted in constraints)

Test commands are real and specific. The tofu plan -var-file=k3s.tfvars command is correct for this repo.

Blast Radius

• westside-docs dev overlay also uses rails-env secretRef (different namespace, different environment). Not affected by this change.
• Issue correctly identifies 12 services with manually-created secrets -- this ticket is scoped to westside-basketball only, with follow-up planned. No blast radius concern.
• The new kubernetes_secret_v1 resource is standalone (not part of the for_each services loop), so it won't affect other services.

Decomposition Assessment

3 file targets, 1 repo, 6 AC. Estimated agent work: ~3 minutes (add one resource block, add 3-4 variables, add values to tfvars). No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-iac for the IaC component. Non-blocking -- this is a documentation gap across the platform, not specific to this ticket.

No other action needed. Scope is solid and ready for implementation.

Verdict: APPROVED

Re-review after refinement. Previous review: review-1616-2026-06-26 (NEEDS_REFINEMENT). Both prior issues resolved.

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Sprint 5 blocking, discovered during pipeline validation
• [x] Repo -- ldraney/westside-basketball
• [x] What Broke -- Detailed description of pipeline failures (test + audit blocking build-and-push)
• [x] Repro Steps -- 6-step reproduction with specific pipeline output
• [x] Expected Behavior -- Clear target state
• [x] Acceptance Criteria -- 7 test fixes, 6 gem audit fixes, 4 pipeline criteria
• [x] Environment -- Woodpecker 3.13.0, Ruby 3.4, Rails 8.1.3
• [x] Related -- Sprint 5 tickets and dependencies listed

All required sections for Bug template are present and complete.

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable." Correct match for CI/pipeline infrastructure work. (Fixed from previous review's story:admin-player-management.)
• [x] story note verified -- WS-S1 found in project-westside-basketball user-stories section under Superadmin (Lucas).
• [x] arch:ci-pipeline label -- CI pipeline architecture component.
• [ ] arch note MISSING -- search_notes("arch-ci-pipeline") returned no results. Known gap across multiple board items (items #1612, #578 also reference arch:ci-pipeline). Not blocking per user direction -- this is a cross-cutting gap, not a scoping deficiency of this ticket.
• [x] Forgejo issue -- ldraney/westside-basketball#69, state: open.

File Targets

• [x] test/controllers/admin/players_controller_test.rb -- verified: file exists (2.3k), contains all 3 failing test methods. CSS selectors (.status-badge, a.player-list-link, .player-list-table-wrap) match the view at app/views/admin/players/index.html.erb (L51, L66, L77). Failures likely stem from DB/fixture issues preventing player data from rendering.
• [x] test/mailers/tournament_mailer_test.rb -- verified: file exists (5.8k). Contains 3 failing tests. Transportation content mismatch CONFIRMED: test asserts "15-passenger van" (L54) but mailer view says "We will not be traveling as a team, and there will be no team transportation" (PR #64 content update). Tenant lookup uses Tenant.find_by!(slug: "westside-kings-queens") (L108, L124) with no fixture/seed data.
• [x] .woodpecker.yaml -- verified: pipeline config exists (3.4k), build-and-push depends on lint, test, audit (L97-100).
• [x] Gemfile.lock -- vulnerable versions confirmed: concurrent-ruby 1.3.6, faraday 2.14.1, jwt 3.1.2, net-imap 0.6.4, nokogiri 1.19.3, puma 8.0.1. All match issue claims.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets in same repo. No cross-repo changes required -- gem updates and test fixes are repo-local.

Dependencies

• This ticket is an implicit BLOCKER for all Sprint 5 deployment: #55 (player list, 5pts, backlog) and #58 (player detail, 5pts, todo) cannot deploy without a passing pipeline.
• Dependency chain: #69 (pipeline fix) -> #55 (player list) -> #58 (player detail).
• Board item #1612 (1pt, backlog, arch:ci-pipeline, sprint:4) targets pal-e-services#144 -- different repo, no overlap with this ticket.
• No items in next_up, needs_approval, or qa columns. Only #1609 (#58, player detail) in todo.
• No explicit depends: labels reference #69, but the blocking relationship is clear from the issue body.

Acceptance Criteria

Comprehensive and agent-verifiable:

• 7 test fix criteria with specific test method names -- verifiable via bundle exec rails test.
• 6 gem audit criteria with specific version targets -- verifiable via Gemfile.lock inspection and bundle-audit check.
• 4 pipeline criteria -- pipeline pass and Harbor image push are CI-verifiable. ArgoCD sync and site 200 are post-deploy validation (better suited for skill-validate-ticket than AC, but acceptable as aspirational criteria).

Blast Radius

Same vulnerable gem versions exist in sibling Rails repos (pal-enterprises, palinks, landscaping-assistant, believers-elite, paldocs). Correctly scoped to westside-basketball only -- sibling updates should be separate tickets. Base image does not pin gem versions.

Decomposition Assessment

File targets: ~4 files in 1 repo. AC count: 18 (high). Estimated agent work: ~10 minutes. Despite high AC count, work is mechanically straightforward: bundle update for gems, test assertion edits for 2 test files. All single-repo. No decomposition needed.

Recommendation

No action needed. Both prior issues resolved:

• [LABEL] story label -- Fixed: changed from story:admin-player-management to story:WS-S1.
• arch:ci-pipeline note gap -- Acknowledged as cross-cutting gap, not blocking for individual tickets. Will be addressed separately.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Sprint 5 blocking, discovered during pipeline validation
• [x] Repo -- ldraney/westside-basketball
• [x] What Broke -- Detailed description of pipeline failures
• [x] Repro Steps -- 6-step reproduction with specific pipeline output
• [x] Expected Behavior -- Clear target state
• [x] Acceptance Criteria -- Comprehensive (test fixes, gem audit, pipeline)
• [x] Environment -- Woodpecker 3.13.0, Ruby 3.4, Rails 8.1.3
• [x] Related -- Sprint 5 tickets and dependencies listed

Template is complete -- all required sections for a Bug issue are present.

Traceability

• [ ] story:admin-player-management label -- INVALID. Project page user stories use WS-S{N} format. admin-player-management is a freeform label not matching any documented story. This CI fix is infrastructure/pipeline work that blocks all deployments. Best match: story:WS-S1 ("As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable").
• [ ] story note NOT verified -- no admin-player-management story entry exists on project-westside-basketball user-stories section. [SCOPE] Create user story entry on project-westside-basketball OR remap to existing WS-S1.
• [x] arch:ci-pipeline label -- CI pipeline architecture component
• [ ] arch note MISSING -- search_notes("arch-ci-pipeline") returned no results. No architecture note exists for the ci-pipeline component. [SCOPE] Create architecture note arch-ci-pipeline for component ci-pipeline.
• [x] Forgejo issue -- ldraney/westside-basketball#69, state: open

File Targets

• [x] test/controllers/admin/players_controller_test.rb -- verified: file exists, contains all 3 failing test methods referenced in the issue (player links L54-58, status badges L47-52, table wrap L60-65)
• [x] CSS selectors verified in views -- app/views/admin/players/index.html.erb contains .status-badge (L77), .player-list-link (L66), .player-list-table-wrap (L51), .player-list-cards (L88). These selectors match the test assertions, so the tests should pass if the view is rendered correctly. The failures likely stem from DB/fixture issues preventing player data from rendering.
• [x] test/mailers/tournament_mailer_test.rb -- verified: file exists, contains the 3 failing tests referenced in the issue
• [x] Transportation content mismatch CONFIRMED -- test asserts "15-passenger van" and "Travel to Las Vegas together as a team" (L54-55) but mailer view says "We will not be traveling as a team, and there will be no team transportation" (PR #64 content update). Issue correctly identifies this.
• [x] Tenant lookup in tests CONFIRMED -- TournamentMailerTest uses Tenant.find_by!(slug: "westside-kings-queens") (L108, L124). No fixtures directory exists, db/seeds.rb has no Tenant records. These tests will fail in CI with ActiveRecord::RecordNotFound. However, note that tests already have rescue ActiveRecord::ConnectionNotEstablished, PG::ConnectionBad skip guards (L118-119, L141-142), but RecordNotFound is NOT caught by these guards.
• [x] .woodpecker.yaml -- verified: pipeline config exists, build-and-push depends on lint, test, audit (L97-99). Issue accurately describes the dependency chain.
• [x] Gemfile.lock gem versions verified:
  • concurrent-ruby 1.3.6 (needs 1.3.7+)
  • faraday 2.14.1 (needs 2.14.3+)
  • jwt 3.1.2 (needs 3.2.0+)
  • net-imap 0.6.4 (needs 0.6.4.1+)
  • nokogiri 1.19.3 (needs 1.19.4+)
  • puma 8.0.1 (needs 8.0.2+)

Repo Placement

OK. Issue is filed on ldraney/westside-basketball, all file targets are in the same repo. No cross-repo changes required -- gem updates and test fixes are repo-local.

Dependencies

• This ticket is a BLOCKER for all downstream Sprint 5 work: #55 (player list), #58 (player detail) cannot deploy without a passing pipeline.
• Board item 1612 (1pt, backlog) also targets arch:ci-pipeline with sprint:4 label -- possible overlap or predecessor. Its title is null (no Forgejo link visible), so scope is unclear.
• Board item 1609 (todo, 5pts, "Admin player detail page") has depends:55 -- the dependency chain is: #69 (pipeline fix) → #55 (player list) → #58 (player detail).
• No items explicitly depend on #69 via depends: label, but #69 is an implicit blocker for all deployment.

Acceptance Criteria

AC is comprehensive and agent-verifiable:

• 7 test fix criteria with specific test method names -- verifiable by running bundle exec rails test
• 6 gem audit criteria with specific version targets -- verifiable by checking Gemfile.lock and bundle-audit check
• 4 pipeline criteria (Woodpecker pass, Harbor image, ArgoCD sync, site 200) -- partially verifiable (pipeline pass is CI, ArgoCD/site require post-deploy validation)
• CONCERN: The "ArgoCD syncs and deploys pods" and "site returns 200" criteria are post-deploy validation, not verifiable by the implementing agent. These belong in post-merge validation, not AC. However, they are reasonable aspirational AC.

Blast Radius

WARNING: The same vulnerable gem versions exist in at least 5 sibling Rails repos:

• concurrent-ruby 1.3.6 -- pal-enterprises, palinks, landscaping-assistant, believers-elite, paldocs
• nokogiri 1.19.3 -- same repos
• faraday 2.14.1-2 -- pal-enterprises, landscaping-assistant

These repos will have the same CVEs. However, this ticket correctly scopes to westside-basketball only -- sibling repo updates should be separate tickets. The base image (ruby-rails-build) does not pin gem versions, so each repo manages its own Gemfile.lock independently.

Decomposition Assessment

File targets: ~4 files in 1 repo (2 test files, Gemfile, Gemfile.lock). AC count: 18 total (7 test + 6 gem + 4 pipeline + 1 overall). Estimated agent work: ~10-15 minutes (test fixes require understanding view rendering, gem updates require resolving dependency conflicts).

The 18 AC count exceeds the 5 AC threshold, BUT the work is mechanically straightforward -- bundle update for gems, test assertion edits for test fixes. All changes are in a single repo. The gem updates are a single bundle update command. The test fixes are independent edits to 2 test files. A skilled agent can do this in one pass.

Borderline. No decomposition needed -- work is mechanical and single-repo despite high AC count.

Recommendation

• [LABEL] Fix story label: story:admin-player-management is not a valid story code. Replace with story:WS-S1 (superadmin deploy via IaC) which is the closest match for CI/pipeline infrastructure work.
• [SCOPE] Create architecture note arch-ci-pipeline for the CI pipeline component. Multiple board items reference arch:ci-pipeline but no backing note exists.

Verdict: READY

Re-review after refinements addressing 5 issues from initial NEEDS_REFINEMENT verdict. All 5 issues resolved.

Previous Issues Resolution

• [x] pal-e-deployments overlay added to scope -- issue body now lists "In scope (pal-e-deployments)" with overlay path update
• [x] State management approach documented -- issue body now includes "State management approach" section with moved blocks strategy and tofu plan verification
• [x] keycloak_clients map key added to scope -- issue body now lists keycloak_clients rename with corresponding moved block in keycloak.tf
• [x] arch-terraform note -- referenced in Related section. Note does not yet exist in pal-e-docs (search returns empty), but the issue body references it. Acceptable: creating the arch note is a separate documentation task, not a blocker for this bug fix.
• [x] story label changed to WS-S1 -- board item now shows story:WS-S1 (superadmin IaC reproducibility), correct alignment for an infrastructure bug

Template Completeness

• [x] Type -- Bug
• [x] Lineage -- Regression from westside-ror rename
• [x] Repo -- ldraney/pal-e-services (primary), ldraney/pal-e-deployments (overlay fix)
• [x] What Broke -- ImagePullBackOff with 401 Unauthorized, root cause identified
• [x] Repro Steps -- 5-step reproduction
• [x] Expected Behavior -- New pod should pull successfully
• [x] Environment -- Cluster, namespace, pull secret username, Terraform key
• [x] Scope -- Detailed scope section covering both repos, with state management approach
• [x] Acceptance Criteria -- 6 criteria listed
• [x] Related -- project, parent issue, westside-rename note, arch-terraform reference

Traceability

• [x] story:WS-S1 label -- "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified -- found in project-westside-basketball user-stories section (Superadmin block)
• [x] arch:terraform label -- terraform component
• [ ] arch note NOT YET CREATED -- arch-terraform note does not exist in pal-e-docs. However, this is a documentation gap, not a scope blocker for a 2pt bug fix. The issue body correctly references it in Related.
• [x] Forgejo issue -- ldraney/pal-e-services#148, open

File Targets

• [x] terraform/k3s.tfvars services map -- verified: key is westside-ror at line 336 (in .example), with image_repo = "westside-ror/app", forgejo_repo = "ldraney/westside-ror", source_path = "overlays/westside-ror/prod". All need updating to westside-basketball.
• [x] terraform/k3s.tfvars keycloak_clients map -- verified: key is westside-ror at line 152 (in .example) with client_id = "westside-ror". Needs key rename + moved block.
• [x] terraform/services.tf -- verified: 6 resources iterate var.services (harbor_project, service_ci, service_pull, kubernetes_namespace_v1, harbor_creds, argocd_application). Note: service_funnel is filtered by v.funnel and westside-ror has funnel = false, so only 6 moved blocks needed in services.tf, not 7.
• [x] terraform/keycloak.tf -- verified: existing moved block precedent (westside-app -> westside-landing). 2 resources need moved blocks: keycloak_openid_client, keycloak_openid_user_realm_role_protocol_mapper (since include_realm_roles_mapper = true).
• [x] overlays/westside-ror/prod/kustomization.yaml (pal-e-deployments) -- verified: image reference already updated to harbor.tail5b443a.ts.net/westside-basketball/app. The overlay does NOT remove imagePullSecrets (base deployment includes them). Directory rename is the main change needed.

Repo Placement

Correct. Primary fix in ldraney/pal-e-services (Terraform). Secondary fix in ldraney/pal-e-deployments (overlay directory rename). Both repos identified in issue body. Single Forgejo issue is appropriate since the pal-e-deployments change is a simple directory rename.

Dependencies

• Board item #1614 (TLS handshake bug) is a sibling sprint:5 unplanned bug -- independent fix, no blocker.
• This ticket blocks Sprint 4+ deployments. Correctly references westside-basketball#54 (Keycloak auth, merged but not deployed).
• No upstream dependencies. No depends: label needed.

Acceptance Criteria

6 criteria listed. Assessment:

• [x] AC1: "tofu plan shows 0 destroy" -- verifiable by running tofu plan and checking output
• [x] AC2: "Harbor pull secret uses correct robot account" -- verifiable via kubectl get secret
• [x] AC3: "New pod pulls successfully" -- verifiable via kubectl get pods
• [x] AC4: "Sprint 4 auth changes are live" -- verifiable by testing Keycloak login flow
• [x] AC5: "keycloak_clients map key updated without disrupting existing client" -- verifiable via tofu plan + Keycloak admin console
• [x] AC6: "No regression in other service deployments" -- verifiable by checking all other service pods

All criteria are agent-verifiable. No missing criteria.

Blast Radius

• The moved blocks strategy mitigates destroy/recreate risk. With correct moved blocks, tofu plan should show only in-place updates.
• Keycloak client rename has precedent (westside-app -> westside-landing moved blocks already exist in keycloak.tf).
• No other services affected -- all other service keys match their image_repo prefixes.
• Minor detail: the issue body says "moved blocks in services.tf, harbor.tf" but harbor.tf does not exist as a separate file -- Harbor resources live in services.tf. The issue should say "services.tf and keycloak.tf" for moved blocks. This is cosmetic and does not affect implementation correctness since the agent will find the resources in services.tf regardless.

Decomposition Assessment

4 files across 2 repos, 6 AC. Borderline on the 5-minute rule. However, the core fix is a single logical operation (rename map keys + add moved blocks), and the pal-e-deployments change is a trivial directory rename. The tofu plan verification is the gating step. No decomposition needed -- this is a cohesive 2pt bug fix that an agent can complete in one pass.

Recommendations

• [BODY] Minor: issue body says "moved blocks in services.tf, harbor.tf" but harbor.tf does not contain service resources. Should say "services.tf and keycloak.tf". Non-blocking -- agent will find the correct files.
• [BODY] Minor: issue body does not explicitly mention updating forgejo_repo from ldraney/westside-ror to ldraney/westside-basketball or source_path from overlays/westside-ror/prod to overlays/westside-basketball/prod in the services map. These are implicit in "rename services map key" but worth calling out. Non-blocking.

Neither recommendation is blocking. The scope is clear enough for an agent to implement correctly.

Verdict: APPROVED

Re-review of board item #1609 after refinements. Previous review (review-1609-2026-06-25) found 3 issues, all resolved.

Previous Issues — Resolution

• [x] arch-rails-views note missing — RESOLVED. Note arch-rails-views (id: 1839) exists in pal-e-docs, scoped to paldocs project. Both paldocs and westside-basketball are Rails ERB apps sharing the same architecture pattern. Cross-project arch note is acceptable.
• [x] players_controller.rb listed as "modify" — RESOLVED. Issue body now clarifies: "add show action (controller created by #55)." File is correctly listed under "Files the agent should modify" since #55 creates it first.
• [x] Missing routing constraint — RESOLVED. Constraints section now includes: "Existing admin/players resource has a member { patch :monthly_fee } route dispatched to roster_report_controller. The show action uses the players_controller — do not disrupt existing member routes."

Template Completeness

• [x] Type — Feature
• [x] Lineage — References #55 and story WS-S9
• [x] Repo — ldraney/westside-basketball
• [x] User Story — As Marcus (admin), track payment status
• [x] Context — Good background on data model and purpose
• [x] File Targets — Create and modify targets listed with DO NOT TOUCH directive
• [x] Feature Flag — none (appropriate for internal admin page)
• [x] Acceptance Criteria — 6 criteria listed
• [x] Test Expectations — Controller tests with run command
• [x] Constraints — 5 constraints listed (up from 3, added routing caution and controller dependency note)
• [x] Checklist — Standard 3-item checklist
• [x] Related — References companion tickets and future sprints

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-views label — Rails views component
• [x] arch note verified — arch-rails-views note exists in pal-e-docs (id: 1839, project: paldocs, cross-project pattern)
• [x] Forgejo issue — ldraney/westside-basketball#58, state: open

File Targets

• [x] app/views/admin/players/show.html.erb — to be created. Directory does not yet exist (expected, will be created by #55 or at file creation time). No collision.
• [x] app/controllers/admin/players_controller.rb — to be modified (created by dependency #55). File does not yet exist, consistent with dependency chain. Ticket correctly notes "#55 creates it, this ticket adds show action."
• [x] config/routes.rb — verified exists. Current routes have resources :players, only: [] at line 15 inside admin namespace with only a monthly_fee member route via roster_report controller. Adding :show is the correct approach.
• [x] app/views/admin/payments/ — DO NOT TOUCH directive verified. Directory exists with index.html.erb.

Data Model Verification

• [x] subscription_status — exists on players table (enum: subscriptionstatus, default: none)
• [x] jersey_order_status — exists on players table (enum: jerseyorderstatus: none/pending/paid/shipped)
• [x] monthly_fee — exists on players table (integer column)
• [x] orders.amount_cents — exists (integer, not null) with status enum (pending/paid/refunded/canceled)
• [x] orders.product_id — exists with FK and index
• [x] product.category — exists (enum: jersey/contract/tournament/equipment/monthly) — matches AC categories
• [x] email_log.email_type — exists (enum includes payment_request and outstanding_balance) — matches AC filter
• [x] Player model associations verified: has_many :orders, :payment_links, :email_logs, :teams (through player_teams), :registrations, :jersey_public_orders; belongs_to :parent, :tenant

Repo Placement

OK — issue filed on ldraney/westside-basketball, all file targets are in that repo. Single-repo change.

Dependencies

• [x] depends:55 (Admin player list page) — board item #1606, currently in backlog. Correctly documented. #55 depends on #54 (Keycloak auth, now done). Dependency chain: #54 (done) → #55 (backlog) → #58 (backlog). Sprint:5 label on both #55 and #58 is correct.
• [x] Issue body references #54 as prerequisite — consistent with board labels.
• [x] Downstream: board item #1610 (sprint:6) has depends:58. Not documented in issue body but acceptable — downstream awareness is sprint-level.

Acceptance Criteria

6 acceptance criteria — all are verifiable by an agent:

• AC1-4: Route response, DOM content checks, data correctness — testable via controller tests and view assertions
• AC5: Back button — testable via link presence check
• AC6: Mobile-responsive — standard for ERB; verifiable via viewport meta tag presence. Acceptable as-is.

Test commands are real: rails test test/controllers/admin/players_controller_test.rb is the correct Rails test invocation path.

Blast Radius

• The existing admin/roster_report controller handles update_fee on the player member route. The new admin/players_controller.rb show action must coexist with this. The Constraints section now explicitly documents this routing concern — the agent is instructed not to disrupt existing member routes. Risk mitigated.
• No similar admin detail pattern exists elsewhere — this is the first admin detail page, so no blast radius to sibling services.

Decomposition Assessment

3 file targets in 1 repo, 6 acceptance criteria (just over the 5 threshold but all are tightly related view/controller concerns for a single page). Estimated agent work: ~3-4 minutes. No decomposition needed — the 6th AC (mobile-responsive) is a CSS concern bundled with the view, not a separate system.

Recommendation

No action needed. All three issues from the previous review have been resolved. Ticket is ready for implementation.

Verdict: READY

Re-review of board item #1606. Previous review (review-1606-2026-06-25) found two issues, both now resolved.

Previous Issues -- Resolution

• [x] arch-rails-views note missing -- RESOLVED. Note now exists (slug: arch-rails-views, note_type: architecture, project: paldocs). Covers ERB templates, Hotwire patterns, CSS conventions.
• [x] CSS badge constraint missing -- RESOLVED. Constraint added to issue body: "Reuse existing status-badge status-badge--{variant} CSS class pattern from roster_report/index.html.erb and payments/index.html.erb -- do not invent new badge styles."

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references #54, story WS-S9
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As Marcus (admin), scrollable player list with payment status
• [x] Context -- explains current disjointed views, motivation for unified list
• [x] File Targets -- 2 create, 1 modify, 2 do-not-touch
• [x] Feature Flag -- "none" (correct for admin-only internal view)
• [x] Acceptance Criteria -- 7 criteria
• [x] Test Expectations -- 2 controller tests with run command
• [x] Constraints -- 5 constraints listed (was 4, now includes CSS badge reuse)
• [x] Checklist -- standard 3-item checklist
• [x] Related -- references #54 and #58

All required sections present. Template is complete.

Traceability

• [x] story:WS-S9 label -- "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified -- found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-views label -- present on board item
• [x] arch note verified -- arch-rails-views note exists in pal-e-docs (Architecture: Rails Views -- ERB templates and Hotwire patterns)
• [x] Forgejo issue -- ldraney/westside-basketball#55, state: open

File Targets

• [x] app/controllers/admin/players_controller.rb -- verified: does NOT exist yet, correct to CREATE
• [x] app/views/admin/players/index.html.erb -- verified: does NOT exist yet, correct to CREATE
• [x] config/routes.rb -- verified: contains resources :players, only: [] at line 15 inside admin namespace with nested member route for monthly_fee. Ticket correctly says to expand only: [] to include :index. Note: a separate resources :players, only: [:index] exists at line 22 outside the admin namespace (public players route) -- agent must modify the admin-namespaced one at line 15, not the public one.
• [x] app/controllers/admin/payments_controller.rb -- verified: EXISTS, correctly listed as do-not-touch
• [x] app/controllers/admin/roster_report_controller.rb -- verified: EXISTS, correctly listed as do-not-touch

All file targets verified. No inaccuracies found.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets are in that repo. No cross-repo work needed.

Dependencies

• depends:54 (Keycloak auth) -- board item #1605, column: done. Dependency is satisfied.
• Blocks #58 (Admin player detail page) -- board item #1609, column: backlog, has depends:55. Correctly documented in both issues' Related sections.

Dependency chain is clean. No undocumented dependencies found.

Acceptance Criteria

7 acceptance criteria are testable:

• AC1 (/admin/players shows list) -- verifiable via controller test, HTTP 200 + content check
• AC2 (grouped/filterable by team) -- verifiable via controller test with team params
• AC3 (row shows player name, parent name, email, status badge) -- verifiable via view test or system test checking DOM elements
• AC4 (visual indicator for current vs behind) -- verifiable via CSS class check on badge. CSS classes confirmed: status-badge--paid, status-badge--unpaid, status-badge--partial, status-badge--active all defined in application.css lines 1467-1479
• AC5 (click navigates to /admin/players/:id) -- verifiable but detail page (#58) doesn't exist yet. Link will 404 until #58 ships. Acceptable since #58 depends on #55.
• AC6 (mobile-responsive) -- requires manual/visual check or system test with viewport
• AC7 (admin role required) -- verifiable via auth test (Keycloak gating from #54)

Test expectations list 2 controller tests with run command rails test test/controllers/admin/players_controller_test.rb. No existing admin players test file -- agent must create it. Expected for a new controller.

Blast Radius

• Status badge pattern confirmed in app/views/admin/roster_report/index.html.erb (line 66, 83) and app/views/admin/payments/index.html.erb (line 78, 143). Both use status-badge status-badge--{variant} CSS class pattern. The new constraint explicitly requires reusing this pattern.
• Models verified: Player, Parent, Team, PlayerTeam all exist. No migrations needed as stated in the issue.
• No other downstream consumers affected. The route addition is additive.

Decomposition Assessment

• File targets: 3 files across 1 repo -- under threshold
• Acceptance criteria: 7 ACs -- above the 5-AC threshold, but all are tightly coupled to a single controller+view. The work is cohesive: one controller, one view template, one route line.
• Estimated agent time: ~3-4 minutes (scaffold controller, build view, add route, write 2 tests)

No decomposition needed. The ACs are facets of a single page, not independent features.

Recommendation

No action needed. Both issues from the previous review have been addressed. Scope is solid, all file targets verified, traceability complete with backing notes, fits in a single agent pass.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references #54, story WS-S9
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As Marcus (admin), scrollable player list with payment status
• [x] Context -- explains current disjointed views, motivation for unified list
• [x] File Targets -- 2 create, 1 modify, 2 do-not-touch
• [x] Feature Flag -- "none" (correct for admin-only internal view)
• [x] Acceptance Criteria -- 7 criteria
• [x] Test Expectations -- 2 controller tests with run command
• [x] Constraints -- 4 constraints listed
• [x] Checklist -- standard 3-item checklist
• [x] Related -- references #54 and #58

All required sections present. Template is complete.

Traceability

• [x] story:WS-S9 label -- "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified -- found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:rails-views label -- present on board item
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-rails-views for component rails-views. No matching note found in pal-e-docs.
• [x] Forgejo issue -- ldraney/westside-basketball#55, state: open

File Targets

• [x] app/controllers/admin/players_controller.rb -- verified: does NOT exist yet, correct to CREATE
• [x] app/views/admin/players/index.html.erb -- verified: does NOT exist yet, correct to CREATE
• [x] config/routes.rb -- verified: contains resources :players, only: [] inside admin namespace with a nested member route for monthly_fee. Ticket correctly says to expand the only: [] to include :index.
• [x] app/controllers/admin/payments_controller.rb -- verified: EXISTS, correctly listed as do-not-touch
• [x] app/controllers/admin/roster_report_controller.rb -- verified: EXISTS, correctly listed as do-not-touch

All file targets verified. No inaccuracies found.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets are in that repo. No cross-repo work needed.

Dependencies

• depends:54 (Keycloak auth) -- board item #1605, column: done. Dependency is satisfied.
• Blocks #58 (Admin player detail page) -- board item #1609, column: backlog, has depends:55. Correctly documented in both issues' Related sections.

Dependency chain is clean. No undocumented dependencies found.

Acceptance Criteria

7 acceptance criteria are testable:

• AC1 (/admin/players shows list) -- verifiable via controller test, HTTP 200 + content check
• AC2 (grouped/filterable by team) -- verifiable via controller test with team params
• AC3 (row shows player name, parent name, email, status badge) -- verifiable via view test or system test checking DOM elements
• AC4 (visual indicator for current vs behind) -- verifiable via CSS class check on badge
• AC5 (click navigates to /admin/players/:id) -- verifiable but NOTE: the detail page (#58) doesn't exist yet. The link will 404 until #58 ships. This is acceptable since #58 explicitly depends on #55.
• AC6 (mobile-responsive) -- requires manual/visual check or system test with viewport
• AC7 (admin role required) -- verifiable via auth test (Keycloak gating from #54)

Test expectations list 2 controller tests with run command rails test test/controllers/admin/players_controller_test.rb. No existing admin players test file -- agent must create it. This is expected for a new controller.

Blast Radius

• Status badge pattern already exists in app/views/admin/roster_report/index.html.erb and app/views/admin/payments/index.html.erb. Both use the status-badge status-badge--{variant} CSS class pattern. The new view MUST reuse this existing pattern for visual consistency. The ticket's Constraints section says "Style after landscaping-assistant Today view" but should reference the existing badge pattern in this repo's own views.
• No other downstream consumers affected. The route addition is additive.

Decomposition Assessment

• File targets: 3 files across 1 repo -- under threshold
• Acceptance criteria: 7 ACs -- above the 5-AC threshold, but all are tightly coupled to a single controller+view. The work is cohesive: one controller, one view template, one route line.
• Estimated agent time: ~3-4 minutes (scaffold controller, build view, add route, write 2 tests)

No decomposition needed. The ACs are facets of a single page, not independent features.

Recommendation

• [SCOPE] Create architecture note arch-rails-views for the rails-views component. The arch:rails-views label is used on both #55 and #58 but no backing architecture note exists in pal-e-docs. This note should document the admin view conventions, layout structure, and shared patterns (e.g., the status-badge CSS classes).
• [BODY] Add a constraint to the issue body: "Reuse existing status-badge status-badge--{variant} CSS class pattern from roster_report/index.html.erb and payments/index.html.erb" -- this ensures the agent discovers and follows the existing pattern rather than inventing a new one.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- References #55 and story WS-S9
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As Marcus (admin), track payment status
• [x] Context -- Good background on data model and purpose
• [x] File Targets -- Create and modify targets listed
• [x] Feature Flag -- none (appropriate for internal admin page)
• [x] Acceptance Criteria -- 6 criteria listed
• [x] Test Expectations -- Controller tests with run command
• [x] Constraints -- 3 constraints listed
• [x] Checklist -- Standard 3-item checklist
• [x] Related -- References companion tickets and future sprints

Traceability

• [x] story:WS-S9 label -- "As an admin, I want to track payment status per player so that I know who owes what" -- verified on project-westside-basketball user-stories section under Admin (Marcus)
• [x] story note verified -- found in project-westside-basketball user-stories section
• [ ] arch:rails-views label -- arch note MISSING -- [SCOPE] Create architecture note arch-rails-views for component rails-views. Searched pal-e-docs for "arch-rails-views" -- no matching note found.
• [x] Forgejo issue -- ldraney/westside-basketball#58, state: open

File Targets

• [x] app/views/admin/players/show.html.erb -- to be created. Directory app/views/admin/players/ does not yet exist (expected for new file). Verified no collision.
• [x] app/controllers/admin/players_controller.rb -- to be created (does NOT currently exist). Ticket says "modify" but this file needs to be created. Minor inaccuracy but non-blocking -- agent will create it regardless.
• [x] config/routes.rb -- verified exists. Current routes have resources :players, only: [] inside admin namespace (line 15) with only a monthly_fee member route. Adding :show is correct approach.
• [x] app/views/admin/payments/ -- DO NOT TOUCH directive verified. Directory exists with index.html.erb.

Data Model Verification

• [x] subscription_status -- exists on players table (enum: subscriptionstatus, default: none)
• [x] jersey_order_status -- exists on players table (enum: jerseyorderstatus: none/pending/paid/shipped)
• [x] monthly_fee -- exists on players table (integer column)
• [x] orders.amount_cents -- exists (integer, not null) with status enum (pending/paid/refunded/canceled)
• [x] orders.product_id -- exists with FK and index
• [x] product.category -- exists (enum: jersey/contract/tournament/equipment/monthly) -- matches AC categories
• [x] email_log.email_type -- exists (enum includes payment_request and outstanding_balance) -- matches AC filter
• [x] Player model associations verified: has_many :orders, :payment_links, :email_logs, :teams (through player_teams), belongs_to :parent

Repo Placement

OK -- issue filed on ldraney/westside-basketball, all file targets are in that repo. Single-repo change.

Dependencies

• [x] depends:55 (Admin player list page) -- board item #1606, currently in backlog. Correctly documented. Issue #55 depends on #54 (Keycloak auth, now closed/merged). Dependency chain: #54 (done) -> #55 (backlog) -> #58 (backlog). Sprint:5 label on both #55 and #58 is correct.
• [x] Issue body references #54 as prerequisite -- consistent with board labels.
• [x] Downstream: issues #65 and #66 (sprint:6) depend on #58 per board data. Not documented in issue body but acceptable -- downstream awareness is sprint-level.

Acceptance Criteria

6 acceptance criteria -- all are verifiable by an agent:

• AC1-4: Route response, DOM content checks, data correctness -- testable via controller tests and view assertions
• AC5: Back button -- testable via link presence check
• AC6: Mobile-responsive -- vague but standard for ERB; could be verified via viewport meta tag presence. Acceptable as-is.

Test commands are real: rails test test/controllers/admin/players_controller_test.rb is the correct Rails test invocation path.

Blast Radius

• The existing admin/roster_report controller already handles update_fee on the player member route. The new admin/players_controller.rb must coexist with this. The routes currently nest resources :players under admin for the monthly_fee member route via roster_report controller. Adding a separate admin/players_controller.rb with a show action could conflict if not carefully scoped. The ticket should note that the existing member { patch :monthly_fee } routes through roster_report controller and the new show action needs its own controller without disrupting that routing.
• No similar admin detail pattern exists elsewhere -- this is the first admin detail page, so no blast radius to sibling services.

Decomposition Assessment

3 file targets in 1 repo, 6 acceptance criteria (just over the 5 threshold but all are tightly related view/controller concerns for a single page). Estimated agent work: ~3-4 minutes. No decomposition needed -- the 6th AC (mobile-responsive) is a CSS concern bundled with the view, not a separate system.

Recommendations

• [SCOPE] Create architecture note arch-rails-views for the rails-views component. This label is used by multiple board items (#55, #58, #66) but has no backing architecture note in pal-e-docs.
• [BODY] Fix file target description: app/controllers/admin/players_controller.rb is listed under "Files the agent should modify" but this file does not exist yet -- it should be listed under "Files the agent should create."
• [BODY] Add routing caution note: the existing admin/players resource has a member { patch :monthly_fee } route that dispatches to roster_report controller. The new show action must be added without disrupting this routing. Suggest noting this in Constraints.

Verdict: NEEDS_REFINEMENT

Note: Both READY and APPROVED are accepted as passing verdicts by the check-board-advance hook. Use either keyword interchangeably.

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered during Sprint 4
• [x] Repo — ldraney/pal-e-services
• [x] What Broke — Woodpecker tfvars_content secret stale after PR #143 merge
• [x] Repro Steps — 4 steps, clear and reproducible
• [x] Expected Behavior — Specific resources listed (client, users, roles)
• [x] Environment — Cluster/namespace, commit SHA, alert status all present
• [x] Acceptance Criteria — 4 criteria, all testable
• [x] Related — project-westside-basketball and PR #143 referenced

All required Bug template sections are present and complete.

Traceability

• [ ] story:superuser-deploy label — WRONG FORMAT. Project page uses story:WS-S* convention. This maps to story:WS-S1 ("As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"). [LABEL] Change story:superuser-deploy to story:WS-S1.
• [x] story note verified — WS-S1 found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [ ] arch:ci-pipeline label — present on board item
• [ ] arch note MISSING — [SCOPE] No arch-ci-pipeline note found in pal-e-docs. Create architecture note arch-ci-pipeline for the Woodpecker CI pipeline component.
• [x] Forgejo issue — ldraney/pal-e-services#144, state: open

File Targets

No explicit file paths in the issue body. This is an operational bug — the fix is re-encoding the Woodpecker tfvars_content secret and re-triggering the pipeline. No source code changes required. Verified:

• [x] ~/secrets/pal-e-services/k3s.tfvars — exists locally, contains westside-ror client entries (16 matching lines)
• [x] k3s.tfvars.example — exists in repo (PR #143 merged these entries)
• [x] Woodpecker secret tfvars_content — exists on repo ID 45 (confirmed via API)
• [x] PR #143 — confirmed merged, title matches ("Add westside-ror Keycloak client and seed admin users")
• [x] Pipeline #53 — confirmed status: failure, event: push, message references PR #143

Repo Placement

Correct. Issue filed on ldraney/pal-e-services, fix is in the pal-e-services Woodpecker secret configuration. No multi-repo concern.

Dependencies

• Blocks #1605 (Add Keycloak auth with admin/coach/player roles, 5pts, currently in next_up) — this item depends on the Keycloak client being provisioned, which this bug prevents.
• Caused by #1608 (Add westside-basketball Keycloak client, done) — PR #143 added tfvars entries but the Woodpecker secret was not re-synced.
• Issue body correctly identifies this as a Sprint 4 blocker.

Acceptance Criteria

4 criteria, all verifiable:

• AC1: Woodpecker secret updated — verifiable via Woodpecker API (check secret exists and pipeline uses current content)
• AC2: Pipeline re-triggered and succeeds — verifiable via Woodpecker pipeline status API
• AC3: westside-ror Keycloak client provisioned — verifiable via Keycloak admin API or UI
• AC4: Lucas and Marcus seed users created — verifiable via Keycloak admin API or UI

No missing criteria. The scope is tight and well-defined.

Blast Radius

Contained. Only ldraney/pal-e-services uses the tfvars_content secret pattern. No other Woodpecker repos have a similar secret. The fix (re-encoding the secret) has no downstream side effects beyond provisioning the intended resources.

Process gap worth noting: The root cause is a manual step (re-encoding tfvars into Woodpecker secret) that was missed during PR #143. This is a recurring risk any time k3s.tfvars changes. Consider documenting this step in the CI pipeline architecture note when it is created.

Decomposition Assessment

No decomposition needed. 1 point, 0 file changes (operational fix only), 4 AC in a single repo, estimated agent work under 2 minutes. Well within the 5-minute rule.

Recommendation

• [LABEL] Change story:superuser-deploy to story:WS-S1 on board item #1612 to match project page convention.
• [SCOPE] Create architecture note arch-ci-pipeline in pal-e-docs for the Woodpecker CI pipeline component. Document the tfvars secret sync process as part of the note.

Verdict: APPROVED

Re-review after refinement. The three changes (roles corrected to admin/coach/player, dependency direction fixed to depends:57, context updated to reference #57 for client creation) are all correct and do not introduce new issues. Scope and file targets are unchanged from the previously approved version.

Template Completeness

• [x] Type (Feature)
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets
• [x] Feature Flag (none -- foundational, appropriate)
• [x] Acceptance Criteria (9 criteria)
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-AUTH label -- foundational auth infrastructure story
• [ ] story note MISSING -- [SCOPE] WS-AUTH not found in project-westside-basketball user-stories section. The section uses numbered stories (WS-S1 through WS-S33). Create a WS-AUTH entry or map to an existing numbered story.
• [x] arch:keycloak-oidc label -- Keycloak OIDC component
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-keycloak-oidc for the Keycloak OIDC integration component.
• [x] Forgejo issue -- ldraney/westside-basketball#54, state: open

File Targets

• [x] app/controllers/sessions_controller.rb -- verified: does not exist (to be created). Landscaping-assistant has this file as reference.
• [x] app/controllers/concerns/authentication.rb -- verified: concerns/ directory exists but is empty (to be created). Note: landscaping-assistant puts auth directly in application_controller.rb; concern approach is cleaner.
• [x] Gemfile -- verified: exists, no OmniAuth/Keycloak gems present. Landscaping-assistant uses omniauth_openid_connect ~0.8 and omniauth-rails_csrf_protection ~1.0.
• [x] config/routes.rb -- verified: exists, has admin namespace (lines 12-20) and public routes (lines 32-39), no auth routes yet.
• [x] app/controllers/application_controller.rb -- verified: exists, currently bare (only allow_browser and stale_when_importmap_changes).
• [x] app/controllers/webhooks_controller.rb -- verified: exists, inherits from ActionController::Base (NOT ApplicationController). Naturally bypasses any before_action on ApplicationController. Correctly listed as "should NOT touch."
• [x] app/controllers/public_controller.rb -- verified: exists, inherits from ApplicationController. See recommendation below re: conflict with "should NOT touch" vs AC #5.

Repo Placement

Correct. Rails auth work is in westside-basketball. Keycloak client creation is in pal-e-services (#57). No cross-repo confusion. Issue filed on westside-basketball, all file targets in westside-basketball.

Dependencies

• #57 (Add westside-basketball Keycloak client and seed admin user) -- board item #1608, column: backlog, labels: depends:56,sprint:4. This ticket depends on #57 (client must exist before Rails can authenticate against it). Direction CORRECT after refinement.
• #56 (Set up westsidekingsandqueens.com via Hetzner edge proxy) -- board item #1607, column: next_up, sprint:3. #57 depends on #56 for public redirect URIs. Transitive dependency.
• #55 (Admin player list page) -- board item #1606, column: backlog, labels: depends:54,sprint:5. Downstream consumer that depends on THIS ticket for auth/role checks.
• Full dependency chain verified: #56 (DNS, sprint:3) -> #57 (Keycloak client, sprint:4) -> #54 (Rails auth, sprint:4) -> #55 (admin player list, sprint:5). All directions correct, sprint ordering consistent.

Acceptance Criteria

9 acceptance criteria, all agent-verifiable:

• AC 1-3: OmniAuth config, current_user, before_action -- verifiable via code inspection and test run
• AC 4: Webhooks exemption -- automatically satisfied (WebhooksController inherits from ActionController::Base, not ApplicationController)
• AC 5: Public controller exemption -- requires skip_before_action in public_controller.rb (see recommendation)
• AC 6: Admin namespace restricted to admin role -- verifiable via controller test
• AC 7-9: Login redirect, logout, unauthenticated redirect -- verifiable via controller tests

4 test expectations with run command: rails test test/controllers/sessions_controller_test.rb. Test directory exists at test/controllers/ with existing test files for admin/, players, public, and webhooks controllers.

Blast Radius

• Landscaping-assistant has a working Keycloak OIDC implementation (reference pattern confirmed: omniauth_openid_connect gem, sessions_controller.rb, auth helpers in application_controller.rb).
• No other westside-basketball controllers will break: webhooks inherits from Base (safe), public inherits from ApplicationController (needs skip_before_action). Controllers that will correctly gain auth: emails_controller, players_controller, welcome_controller, admin/payments_controller, admin/roster_report_controller.
• The coaches table role enum mentioned in context was not found in app/models/ -- likely referring to Keycloak roles, not database roles. No conflict.

Decomposition Assessment

2 new files + 3 modified files, all in one repo. 9 AC but tightly coupled (single auth integration). Estimated agent work: 3-4 minutes. No decomposition needed.

Refinement Changes Verified

1. Roles corrected to admin/coach/player: Matches Keycloak realm definition confirmed in #57 body ("roles: admin, coach, player"). CORRECT.
2. Dependency direction fixed to depends:57: #57 creates the Keycloak client in pal-e-services, #54 consumes it in Rails. Client must exist before Rails auth. CORRECT.
3. Context references #57: Issue body says "Keycloak client creation and user seeding is handled by #57 (pal-e-services)." Matches #57's scope exactly. CORRECT.

Recommendation

• [BODY] Minor conflict: public_controller.rb is listed under "Files the agent should NOT touch" but AC #5 requires it to be exempted from auth. Since PublicController inherits from ApplicationController, it will need at minimum a skip_before_action :authenticate_user! line added. Either move public_controller.rb to the "should modify" list with a note about adding skip_before_action, or clarify that exemption is handled via routing/concern logic. Non-blocking.
• [SCOPE] Create user story entry WS-AUTH on project-westside-basketball user-stories section (currently only has numbered WS-S* stories).
• [SCOPE] Create architecture note arch-keycloak-oidc for the Keycloak OIDC integration component.

Verdict: APPROVED

Third review (re-review after full rewrite). The rewrite resolves all critical issues from reviews 1 and 2. The scope is now correctly targeted at pal-e-services (which has the mrparkers/keycloak v5.0 provider), with a single file target (terraform/k3s.tfvars), and the client creation gap is closed -- this ticket IS the client creation ticket.

Prior Review Issues -- Resolution Status

• [x] [BODY] Wrong repo (pal-e-platform) -- FIXED. Now correctly targets ldraney/pal-e-services.
• [x] [BODY] Invalid file targets (no keycloak provider in pal-e-platform) -- FIXED. Targets terraform/k3s.tfvars in pal-e-services, which has the mrparkers/keycloak provider in providers.tf and for_each resources in keycloak.tf.
• [x] [BODY] Client creation gap (nobody creates the client) -- FIXED. This ticket now explicitly creates both the keycloak_clients entry and keycloak_users entry. The title and scope match.
• [ ] [SCOPE] story:WS-AUTH not in project-westside-basketball user-stories -- PERSISTS but acceptable (see Traceability).
• [ ] [SCOPE] arch-keycloak-oidc note missing -- PERSISTS but acceptable (see Traceability).

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- prerequisite for #54, story WS-AUTH
• [x] Repo -- ldraney/pal-e-services
• [x] User Story -- Rails app needs OIDC client and seed users
• [x] Context -- excellent: references existing realm, existing provider, landscaping-assistant pattern, explicitly states what exists and what is missing
• [x] File Targets -- present with both "should modify" and "should NOT touch" sections
• [x] Feature Flag -- none (correct for infra)
• [x] Acceptance Criteria -- 6 AC (within limits)
• [x] Test Expectations -- 4 items including tofu plan command
• [x] Constraints -- 4 constraints, all actionable
• [x] Checklist -- present
• [x] Related -- references #54, #56, landscaping-assistant pattern

All template sections present and well-populated.

Traceability

• [x] story:WS-AUTH label present
• [ ] story note MISSING -- story:WS-AUTH does not exist in project-westside-basketball user-stories section (which uses WS-S{N} convention). However, WS-AUTH is a coherent story grouping used across 3 related items (#1605, #1607, #1608) covering the full auth stack (DNS, Keycloak client, Rails integration). This is foundational infrastructure work. [SCOPE] Create user story entry for WS-AUTH on project-westside-basketball, or map these items to an existing story (closest match: WS-S3 "manage Keycloak realms").
• [x] arch:keycloak-oidc label present
• [ ] arch note MISSING -- arch-keycloak-oidc does not exist in pal-e-docs. [SCOPE] Create architecture note arch-keycloak-oidc documenting the Keycloak OIDC component (realms, clients, providers, tfvars pattern, for_each resource design).
• [x] Forgejo issue -- ldraney/westside-basketball#57, open

The two [SCOPE] items (story note, arch note) are documentation gaps that do not block implementation. The work itself is well-scoped and the labels provide correct traceability grouping. These notes should be created as part of sprint prep but do not require another review cycle.

File Targets

• [x] terraform/k3s.tfvars (symlink to ~/secrets/pal-e-services/k3s.tfvars) -- VERIFIED. File exists. keycloak_clients map starts at line 73, currently has 3 entries (pal-e-app, pal-enterprises, landscaping-assistant). No westside-basketball client entry exists. keycloak_users map starts at line 249, currently has 4 entries (all in landscaping realm). No westside-basketball/* user entry exists.
• [x] terraform/keycloak.tf -- VERIFIED should NOT touch. keycloak_openid_client resource (line 137) uses for_each = var.keycloak_clients. keycloak_user resource (line 214) uses for_each = var.keycloak_users. Both handle new entries automatically.
• [x] terraform/variables.tf -- VERIFIED should NOT touch. keycloak_clients variable type supports all fields mentioned in AC (realm_key, public_client, pkce_code_challenge_method, include_realm_roles_mapper, use_refresh_tokens, valid_redirect_uris, web_origins, post_logout_redirect_uris). keycloak_users variable type supports realm_key, username, first_name, last_name, email, initial_password, roles.
• [x] terraform/providers.tf -- VERIFIED. mrparkers/keycloak v5.0 provider is configured.
• [x] westside-basketball realm -- VERIFIED exists in k3s.tfvars (line 30) with roles [admin, coach, player], login_theme "westside", and SMTP configured.
• [x] landscaping-assistant pattern -- VERIFIED as reference. Confidential client (public_client = false), PKCE S256, include_realm_roles_mapper = true, use_refresh_tokens = true, redirect URIs for both Tailscale and public domain.

Repo Placement

Issue filed on ldraney/westside-basketball, work targets ldraney/pal-e-services. This is a deliberate cross-repo placement: the issue is filed on the consuming project's board (westside-basketball) because it tracks auth infrastructure for that project, but the PR will be opened on pal-e-services where the file lives. The issue body explicitly states ### Repo: ldraney/pal-e-services and the checklist says "PR opened on pal-e-services". This is correct and clear.

Dependencies

• [x] depends:56 -- Set up westsidekingsandqueens.com via Hetzner edge proxy (board item #1607, currently next_up, sprint:3). Public redirect URIs require the domain to resolve. Correctly declared. This item must complete before #57 can be fully validated.
• [x] Downstream: Board item #1605 (issue #54, "Add Keycloak auth with admin/coach/player roles") has depends:57 label. Correctly declares that Rails auth depends on this client existing. Dependency chain is clean: #56 (DNS) -> #57 (Keycloak client) -> #54 (Rails auth).
• [x] Sprint ordering: #56 is sprint:3, #57 is sprint:4, #54 is sprint:4. Sprint boundaries respect the dependency chain.

Note: #57 can be partially worked (Tailscale redirect URIs) before #56 completes. The public domain URIs are additive and can be configured now even if the domain doesn't resolve yet -- tofu apply will succeed regardless. Full validation (AC2 end-to-end login via public URL) requires #56.

Acceptance Criteria

6 AC, all testable by an agent:

• AC1-4: Structural checks on tfvars entries -- verifiable via grep/read after edit
• AC5: User entry with correct realm, role, credentials -- verifiable via grep/read
• AC6: tofu plan shows only new resources -- verifiable via command output

Test expectations include tofu plan (2-3 new resources), tofu apply, and Keycloak admin UI verification. The run command is provided: cd ~/pal-e-services/terraform && tofu plan -var-file=k3s.tfvars. All criteria are machine-verifiable.

Blast Radius

Low. The change is purely additive -- adding new map entries to keycloak_clients and keycloak_users. Existing clients (pal-e-app, pal-enterprises, landscaping-assistant) are not affected. Existing users (landscaping realm) are not affected. The for_each pattern means Terraform will create new resources without modifying existing ones. tofu plan AC confirms no drift on existing resources.

Decomposition Assessment

1 file target, 1 repo, 6 AC (at the limit but all are structural checks on the same file), estimated agent work well under 5 minutes. No decomposition needed.

Recommendation

No blocking issues. The two [SCOPE] items below are documentation housekeeping that should be addressed but do not block implementation:

• [SCOPE] Create user story entry for WS-AUTH on project-westside-basketball user-stories section (or map to existing WS-S3).
• [SCOPE] Create architecture note arch-keycloak-oidc documenting the Keycloak OIDC component.

These are the same [SCOPE] items from reviews 1 and 2. They are documentation gaps, not implementation blockers. The ticket scope itself is now solid.

Verdict: APPROVED

Board item #1603: Set up Woodpecker CI pipeline for westside-basketball (5pts, sprint:3)

Forgejo issue: ldraney/westside-basketball#53

Re-review of review-1603-2026-06-24 (NEEDS_REFINEMENT). All 4 BODY issues have been addressed.

Prior BODY Fixes Verified

• [x] deployment-patch.yaml added to File Targets — now listed under modify with clear instructions: remove hostPath volume mount, remove inline apt-get/bundle command, keep env vars, probes, resource limits
• [x] imagePullSecrets reversal documented — kustomization.yaml modify entry now says "reverse the imagePullSecrets removal (re-add harbor-creds)". Verified: base standard/deployment.yaml already has imagePullSecrets: harbor-creds at line 20-21, so removing the removal patch is sufficient
• [x] Minitest vs RSpec clarified — Context states "test framework is Minitest (test/ directory), not RSpec". Constraints adds "Test step must use rails test + rails db:schema:load (Minitest), NOT rspec". AC2 specifies "rails test, not rspec". Verified: westside-basketball/test/ exists with controllers/, models/, services/, test_helper.rb; no spec/ directory
• [x] Woodpecker CI secrets documented — Constraints: "Woodpecker CI secrets (forgejo_token, harbor_username, harbor_password) must be verified or created for this repo". Test Expectations: "Verify: Woodpecker CI secrets exist for this repo"

Template Completeness

• [x] Type — Feature
• [x] Lineage — discovered during sprint:2 validation
• [x] Repo — ldraney/westside-basketball + ldraney/pal-e-deployments (both identified)
• [x] User Story — well-formed (developer role, CI/CD pipeline, automated deploy)
• [x] Context — comprehensive: gap explanation, current dev-mode pattern, Minitest note, 4 specific problems to fix
• [x] File Targets — create (.woodpecker.yaml), modify (kustomization.yaml, deployment-patch.yaml), verify (harbor-creds.enc.yaml), don't-touch (application code)
• [x] Feature Flag — none (correct for infra work)
• [x] Acceptance Criteria — 6 criteria, all measurable and agent-verifiable
• [x] Test Expectations — integration test + kubectl verification + secrets check + run command
• [x] Constraints — pattern reference, Harbor registry, base-images, Minitest, secrets
• [x] Checklist — standard PR checklist
• [x] Related — project page, blocking PRs, reference overlay

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:ci-cd label — CI/CD pipeline component
• [ ] arch note MISSING — [SCOPE] search for "arch-ci-cd" returned no results. Create architecture note arch-ci-cd documenting the Woodpecker CI/CD pattern across repos. (Carried forward from prior review — does not block implementation, the issue body documents the pattern sufficiently for agent execution)
• [x] Forgejo issue — ldraney/westside-basketball#53, state: open

File Targets

• [x] .woodpecker.yaml (create) — verified: file does not exist in westside-basketball. Correct target.
• [x] ~/pal-e-deployments/overlays/westside-ror/prod/kustomization.yaml (modify) — verified: exists, currently uses ruby:3.4-slim (line 61-62), has explicit imagePullSecrets removal at lines 31-33. Both changes correctly scoped.
• [x] ~/pal-e-deployments/overlays/westside-ror/prod/deployment-patch.yaml (modify) — verified: exists, has hostPath mount at lines 52-59 and inline apt-get/bundle command at line 14. Both correctly identified for removal.
• [x] harbor-creds.enc.yaml (verify/create) — verified: does NOT exist in westside-ror overlay yet. westsidekingsandqueens overlay has one as reference (confirmed). Base deployment already references harbor-creds secret name.

Repo Placement

Issue filed on westside-basketball (correct for .woodpecker.yaml). Cross-repo changes in pal-e-deployments are standard pattern — paldocs and landscaping-assistant follow the same pattern. Both repos identified in the Repo section. The issue is clear that changes span two repos. This is a two-PR workflow (one per repo), consistent with existing patterns.

Dependencies

• No explicit depends: label on board item — correct, this is foundational infrastructure.
• Other sprint:3 items (email #1598 5pts next_up, domain #1607 2pts next_up, email #1580 3pts next_up) do NOT depend on this CI pipeline — they can proceed independently.
• Sprint:2 merged PRs #50 and #51 are undeployed because this pipeline does not exist. This ticket unblocks their deployment.
• Woodpecker CI secrets requirement is now documented in Constraints and Test Expectations.

Acceptance Criteria

6 criteria (up from 4 in original review). All are agent-verifiable:

• [x] AC1: pipeline triggers on push to main and pull_request — verifiable via Woodpecker UI
• [x] AC2: pipeline runs lint, test (rails test), build-and-push, update-kustomize-tag — verifiable, correctly specifies rails test not rspec
• [x] AC3: deployment-patch.yaml no longer has hostPath or inline apt-get — verifiable via file diff
• [x] AC4: kustomization.yaml references Harbor image with imagePullSecrets — verifiable via file diff
• [x] AC5: ArgoCD auto-syncs new image — verifiable via ArgoCD UI / kubectl
• [x] AC6: Pod runs Harbor-built image — verifiable via kubectl describe pod

AC expanded from 4 to 6, now explicitly covering deployment-patch and kustomization changes. Well-defined and complete.

Blast Radius

• westsidekingsandqueens overlay is separate and unaffected — different namespace, different image path.
• update-kustomize-tag.sh is a shared script from pal-e-platform/scripts/ using OVERLAY env var. No blast radius.
• Base standard/deployment.yaml is not modified — only overlay patches change.
• No other repos reference westside-basketball CI config.

Decomposition Assessment

3 file targets (1 create + 2 modify + 1 verify) across 2 repos. 6 acceptance criteria. Estimated agent work: ~5 minutes. At the upper bound of a single agent pass but within limits. The file targets are all well-understood patterns with clear reference implementations (paldocs .woodpecker.yaml, landscaping-assistant overlay). No decomposition needed.

Recommendations

• [SCOPE] Create architecture note arch-ci-cd documenting the Woodpecker CI/CD pattern (pipeline stages, shared scripts, Harbor registry, kustomize tag updates). Carried forward from prior review — does not block implementation.

All 4 prior BODY issues resolved. Scope is solid for agent execution.

Verdict: NEEDS_REFINEMENT

Board item #1603: Set up Woodpecker CI pipeline for westside-basketball (5pts, sprint:3)

Forgejo issue: ldraney/westside-basketball#53

Template Completeness

• [x] Type — Feature
• [x] Lineage — discovered during sprint:2 validation
• [x] Repo — ldraney/westside-basketball
• [x] User Story — present and well-formed
• [x] Context — comprehensive, explains the gap
• [x] File Targets — present with create/modify/don't-touch sections
• [x] Feature Flag — none (correct for infra work)
• [x] Acceptance Criteria — 4 criteria, all measurable
• [x] Test Expectations — integration test and kubectl verification
• [x] Constraints — references paldocs pattern, Harbor registry, base-images
• [x] Checklist — standard PR checklist present
• [x] Related — project page and blocking PRs referenced

Traceability

• [x] story:WS-S1 label — "As superadmin, I want to deploy platform changes via IaC so that infrastructure is reproducible and auditable"
• [x] story note verified — found in project-westside-basketball user-stories section under Superadmin (Lucas)
• [x] arch:ci-cd label — CI/CD pipeline component
• [ ] arch note MISSING — [SCOPE] search for "arch-ci-cd" returned no results. Create architecture note arch-ci-cd documenting the Woodpecker CI/CD pattern across repos.
• [x] Forgejo issue — ldraney/westside-basketball#53, state: open

File Targets

• [x] .woodpecker.yaml (create) — verified: file does not exist yet in westside-basketball. Correct target.
• [x] ~/pal-e-deployments/overlays/westside-ror/prod/kustomization.yaml (modify) — verified: file exists, currently uses ruby:3.4-slim as image with no Harbor reference. Confirmed this is the right file to switch to Harbor image.
• [ ] ~/pal-e-deployments/overlays/westside-ror/prod/deployment-patch.yaml — ISSUE: not mentioned in file targets but MUST be modified. Currently has hostPath: /home/ldraney/westside-ror volume mount (line 58) and inline apt-get install && bundle install in the command (line 14). When switching to a Harbor-built image, this hostPath mount becomes invalid and the inline build command is redundant — the Dockerfile handles all of this. The agent needs to know this file needs changes too.
• [ ] ~/pal-e-deployments/overlays/westside-ror/prod/kustomization.yaml line 32-33 — ISSUE: the kustomization explicitly removes imagePullSecrets because it uses a public ruby image. When switching to Harbor, imagePullSecrets must be KEPT (Harbor requires auth). This patch removal must be reversed, and a harbor-creds.enc.yaml resource may be needed (the westsidekingsandqueens overlay already has one as reference).

Repo Placement

Issue is filed on westside-basketball (correct for .woodpecker.yaml), but the kustomization changes are in pal-e-deployments. This cross-repo pattern is consistent with how other pipelines work (paldocs pipeline updates pal-e-deployments too). The issue correctly identifies both repos. However, the agent will need to make two PRs (one per repo) or the pal-e-deployments changes need a separate issue. The issue should clarify whether this is a single-PR or two-PR workflow.

Dependencies

• No explicit depends: label on board item — correct, this is foundational infrastructure.
• Other sprint:3 items (email #1598, domain #1607, email #1580) do NOT depend on this CI pipeline — they can proceed independently.
• However, sprint:2 merged PRs #50 and #51 are undeployed BECAUSE this pipeline doesn't exist. This ticket unblocks their deployment.
• Woodpecker CI secrets (forgejo_token, harbor_username, harbor_password) must exist in Woodpecker for the westside-basketball repo. The issue does not mention creating these secrets. Paldocs and pal-e-docs already have them — the agent needs to know whether these are global secrets (shared) or per-repo secrets that need creation.

Acceptance Criteria

• [x] AC1 "pipeline triggers on push to main and pull_request" — verifiable via Woodpecker UI, well-defined
• [x] AC2 "Pipeline runs lint, test, build-and-push, update-kustomize-tag" — verifiable BUT the test step must use rails test (Minitest), NOT rspec. The paldocs reference uses rspec. Also, westside-basketball has no db/ci_schema.sql — the test step needs rails db:schema:load instead of psql -f db/ci_schema.sql.
• [x] AC3 "ArgoCD auto-syncs new image" — verifiable via ArgoCD UI / kubectl
• [x] AC4 "Pod runs Harbor-built image" — verifiable via kubectl describe pod

All criteria are agent-verifiable. The test expectations are reasonable (integration test via commit push, kubectl verification).

Blast Radius

• The westsidekingsandqueens overlay in pal-e-deployments is "being replaced by westside-ror" per its README. It already has Harbor creds and a different deployment pattern. Changes to westside-ror overlay do not affect westsidekingsandqueens.
• The update-kustomize-tag.sh script is shared across all pipelines (fetched from pal-e-platform/scripts/). It uses the OVERLAY env var to target the right overlay directory. No blast radius concern here — standard pattern.
• No other repos reference westside-basketball's CI config.
• The Dockerfile currently uses ruby:3.4.8-slim directly. The constraints say "Base image should come from base-images repo." The base-images repo has a Dockerfile at ~/base-images/Dockerfile using ruby:3.4.9-slim. If the ticket means the CI build step should use harbor.tail5b443a.ts.net/library/ruby-rails-build:latest (like paldocs CI), that's fine. But if it also means the production Dockerfile should be rebased onto the Harbor base image, that's additional scope not captured in file targets.

Decomposition Assessment

2 file targets across 2 repos, 4 acceptance criteria. Estimated agent work: ~5 minutes. Fits within single agent pass. No decomposition needed.

However, the missing file target (deployment-patch.yaml) and the imagePullSecrets reversal add complexity. With those additions it remains within a single pass but is at the upper bound.

Recommendations

• [BODY] Add deployment-patch.yaml to File Targets (modify section): "Remove hostPath volume mount and inline build command — the Harbor image handles all of this via the Dockerfile. Remove the volume and volumeMounts entries."
• [BODY] Add note to File Targets (modify section) for kustomization.yaml: "Reverse the imagePullSecrets removal patch — Harbor requires auth. Add harbor-creds.enc.yaml resource if not already present (see westsidekingsandqueens overlay as reference)."
• [BODY] Add note to Constraints or Context: "westside-basketball uses Minitest (test/ directory), not RSpec. CI test step should use rails test and rails db:schema:load, not rspec and ci_schema.sql."
• [BODY] Add to Context or Dependencies: "Verify Woodpecker CI secrets (forgejo_token, harbor_username, harbor_password) exist as global secrets or create per-repo secrets for westside-basketball."
• [SCOPE] Create architecture note arch-ci-cd documenting the Woodpecker CI/CD pattern (pipeline stages, shared scripts, Harbor registry, kustomize tag updates).

Verdict: APPROVED

Re-review of board item #1607. Prior review (review-1607-2026-06-24) returned NEEDS_REFINEMENT with 8 BODY fixes, 1 LABEL fix, 2 SCOPE items. All 9 BODY+LABEL issues have been resolved. The issue has been completely rewritten with correct file targets, correct repo scope, and accurate patterns. Two SCOPE items (backing notes) remain as non-blocking documentation recommendations.

Template Completeness

• [x] Type — Feature
• [x] Lineage — references #54, story WS-AUTH
• [x] Repo — forgejo_admin/pal-e-platform (minor: actual org is ldraney, not forgejo_admin)
• [x] User Story — present, clear actor/want/so-that
• [x] Context — clear, references landscaping-assistant.app pattern, explains architecture
• [x] File Targets — 2 targets verified, plus explicit "should NOT touch" list
• [x] Feature Flag — "none" (correct for infra work)
• [x] Acceptance Criteria — 6 criteria, all testable
• [x] Test Expectations — 4 items with real commands
• [x] Constraints — present, accurate
• [x] Checklist — present, includes terraform plan and salt state
• [x] Related — present, references #54 and #57

Traceability

• [x] story:WS-AUTH label — present on board item
• [ ] story note MISSING — WS-AUTH does not exist in project-westside-basketball user-stories section. The concept is valid (public URL enables auth flow), but no formal entry exists. [SCOPE] Create WS-AUTH user story entry on project-westside-basketball user-stories section.
• [x] arch:hetzner-proxy label — present on board item
• [ ] arch note MISSING — arch-hetzner-proxy note does not exist in pal-e-docs. [SCOPE] Create architecture note arch-hetzner-proxy documenting the GoDaddy DNS → Hetzner Caddy edge proxy → Tailscale → k8s pattern.
• [x] Forgejo issue — ldraney/westside-basketball#56, open

File Targets

• [x] pal-e-platform/terraform/dns.tf — verified: godaddy_dns_record.landscaping_assistant_a at line 12 is the exact pattern to follow. File exists, pattern confirmed.
• [x] pal-e-platform/salt/pillar/caddy.sls — verified: landscaping site entry at line 17-20 is the exact pattern to follow. File exists, pattern confirmed.
• [x] "Should NOT touch" list — correctly excludes godaddy-tofu/ (provider repo), pal-e-services/, and pal-e-deployments/.

Prior Review Issues — Resolution Status

• [x] [BODY] godaddy-tofu → pal-e-platform/terraform/dns.tf — FIXED
• [x] [BODY] vague proxy config → salt/pillar/caddy.sls — FIXED
• [x] [BODY] remove TLS cert provisioning target — FIXED (Caddy handles ACME)
• [x] [BODY] clarify/remove pal-e-deployments target — FIXED (moved to "should NOT touch")
• [x] [BODY] remove pal-e-services target — FIXED (moved to "should NOT touch")
• [x] [BODY] remove ~/secrets/stripe constraint — FIXED
• [x] [BODY] add Salt highstate / terraform apply AC — FIXED (in AC and Checklist)
• [x] [BODY] fix WS-S7 lineage reference — FIXED (now says WS-AUTH)
• [x] [LABEL] remove depends:godaddy-tofu — FIXED (label removed from board item)

Repo Placement

Issue filed on westside-basketball, actual work in pal-e-platform. Acceptable as a cross-repo feature issue filed against the consuming project. The issue now correctly identifies only pal-e-platform as the target repo. Minor note: Repo field says forgejo_admin/pal-e-platform but actual owner is ldraney — cosmetic, not blocking.

Dependencies

• Board item #1608 ("Update Keycloak redirect URIs") has depends:56 — correctly depends on this ticket.
• Board item #1605 ("Add Keycloak auth") is the story parent (story:WS-AUTH).
• No blocking dependencies for this ticket — it can proceed independently.
• Dependency chain documented in Related section (#54, #57).

Acceptance Criteria

6 criteria, all agent-verifiable. Test commands are real (dig, curl -vI, curl -sI). Salt state application is covered in AC #6. Terraform plan is covered in Checklist. Complete and testable.

Blast Radius

Low. Adding a new DNS record and a new Caddy site entry follows the exact pattern of 2 existing sites (palinks.app, landscaping-assistant.app). Caddyfile.j2 template iterates over pillar data — new entries cannot break existing sites. No changes to existing entries.

Decomposition Assessment

2 file edits in 1 repo. 6 AC (within limit). Estimated agent time: 2-3 minutes. Well within 5-minute rule. No decomposition needed.

Recommendations

• [BODY] Minor: Fix Repo field from forgejo_admin/pal-e-platform to ldraney/pal-e-platform (cosmetic, non-blocking)
• [SCOPE] Create user story entry WS-AUTH on project-westside-basketball user-stories section — the concept is valid but no formal entry exists yet. Can be done in parallel with or after this ticket.
• [SCOPE] Create architecture note arch-hetzner-proxy documenting the GoDaddy DNS → Hetzner Caddy edge proxy → Tailscale → k8s pattern. Can be done in parallel with or after this ticket.

Verdict: READY

Third review (v3). Previous reviews: review-1605-2026-06-24 (spike, NEEDS_REFINEMENT), review-1605-2026-06-24-v2 (feature rewrite, NEEDS_REFINEMENT with 6 recommendations). Issue has been fully rewritten to address all prior feedback. This review evaluates the final version.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Related to #56 (DNS/proxy) and #57 (Keycloak redirect URIs)
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As any user, I want to log in securely and see only what my role allows
• [x] Context -- thorough, explains no auth exists today, three roles needed, Keycloak server config explicitly out of scope
• [x] File Targets -- 2 create, 3 modify, 3 do-not-touch
• [x] Feature Flag -- "none" with justification (foundational infrastructure). No docs/feature-flags.md in repo, correct to skip.
• [x] Acceptance Criteria -- 9 criteria
• [x] Test Expectations -- 4 tests with run command
• [x] Constraints -- 4 constraints, references landscaping-assistant pattern
• [x] Checklist -- standard 3-item
• [x] Related -- references landscaping-assistant, #56, #57, #55

All required sections present. Template is complete.

Traceability

• [x] story:WS-AUTH label -- custom auth story label, appropriate for foundational auth work that spans multiple roles
• [ ] story note MISSING -- WS-AUTH is not listed in the project-westside-basketball user-stories section. The standard stories use WS-S* numbering. [SCOPE] Create user story entry on project-westside-basketball user-stories section for WS-AUTH (e.g. "As any user, I want to log in securely and see only what my role allows so that admin pages are protected and each role gets an appropriate experience").
• [x] arch:keycloak-oidc label -- references the Keycloak OIDC integration component
• [ ] arch note MISSING -- no arch-keycloak-oidc note exists in pal-e-docs. [SCOPE] Create architecture note arch-keycloak-oidc for the Keycloak OIDC integration component. (Carryover from v1 and v2 reviews.)
• [x] Forgejo issue -- ldraney/westside-basketball#54, state: open

File Targets

• [x] app/controllers/sessions_controller.rb -- verified: does NOT exist (correct, to be created)
• [x] app/controllers/concerns/authentication.rb -- verified: does NOT exist (correct, to be created). Concerns directory exists with .keep file.
• [x] Gemfile -- verified: exists, no omniauth/keycloak gems present
• [x] config/routes.rb -- verified: exists, has namespace :admin, no auth routes. Public routes and webhook route present.
• [x] app/controllers/application_controller.rb -- verified: exists, no auth concerns included, inherits ActionController::Base
• [x] app/controllers/webhooks_controller.rb -- verified: exists, inherits from ActionController::Base (NOT ApplicationController), already isolated from any before_action on ApplicationController. Correctly listed as do-not-touch.
• [x] app/controllers/public_controller.rb -- verified: exists, inherits from ApplicationController. Will need skip_before_action for auth. Correctly listed as do-not-touch (auth exemption, not content modification). AC #5 explicitly covers this.
• [x] db/schema.rb -- verified: exists, has coachrole enum. Correctly listed as do-not-touch (session-based auth, no migrations).

Note: config/initializers/omniauth.rb is not listed but will be implicitly created by the agent as standard Rails OmniAuth setup. This is acceptable -- the agent will follow the landscaping-assistant pattern referenced in Constraints.

Repo Placement

OK. Issue filed on ldraney/westside-basketball, all file targets are in that repo. Cross-repo Keycloak server config (client creation, redirect URIs) has been correctly split into separate tickets #56 and #57. This was a key finding from v2 review and is now properly addressed.

Dependencies

• Downstream: Board item #1606 (westside-basketball#55 "Admin player list page") has depends:54 label -- correctly documented.
• Downstream: Board item #1609 (westside-basketball#58 "Admin player detail page") has depends:55, which transitively depends on #54.
• Infrastructure prerequisites: #56 (DNS/proxy via Hetzner) and #57 (Keycloak redirect URIs) are documented in Lineage. These are needed for production but not for development/testing -- the agent can develop and test against a dev Keycloak instance.
• No blockers: Nothing in in_progress or next_up blocks this ticket. All three auth-story items (#1605, #1607, #1608) are in backlog.

Acceptance Criteria

9 acceptance criteria. All are testable by an agent via controller tests:

• AC 1-5: Standard OmniAuth setup verification -- gem presence, helper availability, default protection, exemptions. All verifiable via code inspection and controller tests.
• AC 6: Admin namespace restriction -- verifiable via controller test (role-based access).
• AC 7: Login redirects to root path -- simplified from v2's problematic /admin/players, /dashboard, /profile targets. Now correctly points to existing root_path. Downstream tickets handle role-specific dashboards.
• AC 8-9: Logout and unauthenticated user behavior -- standard auth flow, verifiable via controller tests.

All criteria are well-scoped to this repo and testable. No cross-repo AC remain.

Blast Radius

Controlled. before_action :authenticate_user! in ApplicationController affects all inheriting controllers:

• WelcomeController, PlayersController, EmailsController -- will require auth (correct, these are admin-facing)
• PublicController -- explicitly exempted in AC #5 and do-not-touch list
• WebhooksController -- inherits from ActionController::Base, NOT ApplicationController. Already isolated. AC #4 covers this.
• Admin controllers (payments, roster_report, delinquency_report) -- will require auth AND admin role (AC #6)
• Health check (/up) -- uses Rails::HealthController, does not inherit ApplicationController. No impact.

Blast radius is well-documented and all edge cases are covered.

Decomposition Assessment

9 AC in 1 repo, 5 file targets (2 create + 3 modify). Estimated agent work: 3-5 minutes. This is a single coherent unit -- OmniAuth gem + auth concern + sessions controller + route config + tests. No decomposition needed.

V2 review flagged 12 AC across 2 repos. The rewrite reduced to 9 AC in 1 repo by splitting Keycloak server config into #56/#57. Well within the 5-minute rule.

V2 Findings Resolution

V2 Finding	Status
[LABEL] story:WS-S7 mismatch	RESOLVED -- relabeled to story:WS-AUTH
[SCOPE] arch-keycloak-oidc missing	OPEN -- still needs creation (carryover)
[BODY] AC #2/#3 cross-repo Keycloak config	RESOLVED -- split to #56/#57
[BODY] AC #8 redirect targets don't exist	RESOLVED -- simplified to root_path
[BODY] public_controller.rb exemption	RESOLVED -- added to do-not-touch + AC #5
[DECOMPOSE] 12 AC across 2 repos	RESOLVED -- 9 AC in 1 repo

Recommendation

All [BODY], [LABEL], and [DECOMPOSE] issues from v2 have been resolved. Two [SCOPE] items remain as non-blocking documentation tasks:

• [SCOPE] Create user story entry WS-AUTH on project-westside-basketball user-stories section.
• [SCOPE] Create architecture note arch-keycloak-oidc in pal-e-docs. (Carryover from v1 and v2.)

These are backing-note creation tasks that do not affect the ticket's scope, file targets, or agent executability. The ticket itself is well-scoped, all file targets verified, AC are testable, blast radius documented, and fits within a single agent pass. Verdict: READY.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — references #54, story WS-S7
• [x] Repo — cross-repo listed
• [x] User Story — present
• [x] Context — clear, references landscaping-assistant.app pattern
• [x] File Targets — present (but inaccurate, see below)
• [x] Feature Flag — "none" (correct for infra work)
• [x] Acceptance Criteria — 6 criteria, testable
• [x] Test Expectations — 4 items with real commands
• [x] Constraints — present
• [x] Checklist — present
• [x] Related — present

Traceability

• [ ] story:WS-AUTH label — MISSING from project page. The project-westside-basketball user-stories section has no WS-AUTH entry. The issue body references WS-S7, but WS-S7 is "As an admin, I want to send branded email announcements" which does not match this work (public URL/domain setup). [SCOPE] Create a WS-AUTH user story entry on project-westside-basketball user-stories section, or re-map to an existing story that covers public URL access.
• [x] arch:hetzner-proxy label — present on board item
• [ ] arch note MISSING — arch-hetzner-proxy note does not exist in pal-e-docs. [SCOPE] Create architecture note arch-hetzner-proxy documenting the GoDaddy DNS → Hetzner edge proxy (Caddy) → Tailscale → k8s pattern.
• [x] Forgejo issue — ldraney/westside-basketball#56, open

File Targets

• [ ] godaddy-tofu DNS A record — WRONG REPO. godaddy-tofu is a custom Terraform provider (Go source code at ~/godaddy-tofu/: main.go, provider.go, resource_dns_record.go). DNS A records are managed in pal-e-platform/terraform/dns.tf using godaddy_dns_record resources. The reference implementation is godaddy_dns_record.landscaping_assistant_a at line 12 of that file. [BODY] Fix file target: godaddy-tofu → pal-e-platform/terraform/dns.tf
• [ ] pal-e-platform Hetzner edge proxy config (nginx/caddy) — INCOMPLETE. The proxy config is managed via Salt, not raw config files. Actual targets are: pal-e-platform/salt/pillar/caddy.sls (add a new site entry matching the landscaping entry pattern) and optionally pal-e-platform/salt/states/caddy/Caddyfile.j2 (no changes needed, template is generic). [BODY] Fix file target: replace vague "Hetzner edge proxy config" with pal-e-platform/salt/pillar/caddy.sls
• [ ] pal-e-platform TLS cert provisioning — NOT NEEDED as separate target. Caddy handles ACME/Let's Encrypt automatically. No cert-manager or manual TLS config required. The Caddyfile.j2 template auto-provisions TLS for each site block. [BODY] Remove TLS cert provisioning file target — Caddy handles this automatically via ACME
• [ ] pal-e-deployments ArgoCD overlay — NEEDS CLARIFICATION. The overlay already exists at overlays/westsidekingsandqueens/prod/ with a Tailscale funnel ingress. The prod kustomization.yaml comments out ingress ("ingress.yaml removed — westsidekingsandqueens URL now served by westside-ror namespace"). Unclear what change is needed here — the ingress is already configured for Tailscale funnel. If the intent is to accept the new public hostname, that's a Rails config.hosts change (which the ticket explicitly excludes). [BODY] Clarify what pal-e-deployments change is needed, or remove this file target if no overlay change is required.
• [ ] pal-e-services service onboarding — NO MECHANISM EXISTS. pal-e-services has no domain onboarding config, no YAML/TF files referencing any domains. The repo contains only terraform/ and docs. [BODY] Remove pal-e-services file target — no domain onboarding mechanism exists in this repo.

Repo Placement

Issue is filed on westside-basketball but the actual work is entirely in pal-e-platform (dns.tf + salt/pillar/caddy.sls). This is acceptable as a cross-repo feature issue filed against the consuming project, but the file targets must be corrected to point to the right repos and paths.

The ticket claims 4 repos (godaddy-tofu, pal-e-platform, pal-e-services, pal-e-deployments). Actual repos affected: 1 (pal-e-platform). godaddy-tofu is the provider, not a target. pal-e-services has no relevant config. pal-e-deployments overlay already exists.

Dependencies

• depends:godaddy-tofu label is misleading — godaddy-tofu is the Terraform provider (a build dependency), not a blocking ticket. The provider already exists and works (dns.tf uses it for palinks.app and landscaping-assistant.app). [LABEL] Change depends:godaddy-tofu to something more accurate, or remove — there is no blocking dependency.
• Board item #1608 ("Update Keycloak redirect URIs to westsidekingsandqueens.com") has depends:56 label — correctly depends on this ticket.
• Board item #1605 ("Add Keycloak auth with admin/parent/player roles") is the story parent (story:WS-AUTH).
• Issue body references #54 (Keycloak auth needs public URL) and #57 (Keycloak redirect URLs depends on this) — dependency chain is documented in the issue.

Acceptance Criteria

6 criteria, all testable. The test commands are real and verifiable (dig, curl -vI, curl -sI). One gap: no AC for the Salt highstate application (how the Caddy config gets deployed to the Hetzner edge proxy). An agent could verify DNS and TLS after deployment, but needs to know that salt '*edge*' state.highstate (or equivalent) must be run to apply the Caddy config.

Blast Radius

Low blast radius. Adding a new site entry to caddy.sls and a new DNS record to dns.tf follows the exact same pattern as the two existing sites (palinks.app, landscaping-assistant.app). No changes to existing entries. The Caddyfile.j2 template is generic and iterates over pillar data — adding a site entry cannot break existing sites.

One consideration: the ticket mentions ~/secrets/stripe under Constraints ("Reference ~/secrets/stripe for any secrets that need the new domain"). This is irrelevant to DNS/proxy setup and may confuse an agent. This constraint should be removed or moved to the Keycloak redirect ticket (#57).

Decomposition Assessment

Despite claiming 4 repos, the actual work is 2 file edits in 1 repo (pal-e-platform): add a DNS record to terraform/dns.tf and add a site entry to salt/pillar/caddy.sls. Plus terraform apply and Salt highstate. Well within the 5-minute rule. No decomposition needed.

Recommendations

• [BODY] Fix file target: godaddy-tofu → pal-e-platform/terraform/dns.tf (add godaddy_dns_record.westsidekingsandqueens_a matching the landscaping pattern at line 12-18)
• [BODY] Fix file target: replace vague "Hetzner edge proxy config (nginx/caddy)" with pal-e-platform/salt/pillar/caddy.sls (add westsidekingsandqueens site entry matching the landscaping pattern)
• [BODY] Remove TLS cert provisioning file target — Caddy handles this automatically via ACME, no manual config needed
• [BODY] Clarify or remove pal-e-deployments file target — overlay already exists, unclear what changes
• [BODY] Remove pal-e-services file target — no domain onboarding mechanism exists in this repo
• [BODY] Remove misleading Constraints reference to ~/secrets/stripe — not relevant to DNS/proxy setup
• [BODY] Add AC or constraint: "Run Salt highstate on edge-proxy to deploy Caddy config" and "Run terraform apply in pal-e-platform to create DNS record"
• [BODY] Fix Lineage: WS-S7 reference is wrong — WS-S7 is "branded email announcements", not public URL access
• [LABEL] Change or remove depends:godaddy-tofu — godaddy-tofu is a provider dependency, not a blocking ticket
• [SCOPE] Create user story entry WS-AUTH on project-westside-basketball user-stories section (or map to an existing story covering public URL access)
• [SCOPE] Create architecture note arch-hetzner-proxy documenting the GoDaddy DNS → Hetzner Caddy edge proxy → Tailscale → k8s pattern

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- references #54, DNS dependency, story WS-S7
• [x] Repo -- cross-repo: pal-e-platform + westside-basketball
• [x] User Story -- As Marcus logging into westsidekingsandqueens.com...
• [x] Context -- solid background referencing landscaping-assistant precedent
• [x] File Targets -- 3 targets listed (see verification below)
• [x] Feature Flag -- none (appropriate for config change)
• [x] Acceptance Criteria -- 6 criteria listed
• [x] Test Expectations -- manual test steps
• [x] Constraints -- references landscaping-assistant patterns
• [x] Checklist -- present
• [x] Related -- references landscaping-assistant issues and dependencies

All required feature template sections are present.

Traceability

• [ ] story:WS-AUTH label -- MISMATCH: board label says story:WS-AUTH but issue body says WS-S7. Neither WS-AUTH nor a matching auth story exists in the project-westside-basketball user-stories section. WS-S7 is "As an admin, I want to send branded email announcements" which does not match this ticket's scope. The closest story would be about auth/login flow but none exists yet. [SCOPE] Create a proper user story (e.g. WS-S34 or similar) for auth redirect/login flow on the project-westside-basketball user-stories section, then update the board label to match.
• [ ] arch:keycloak-oidc label -- arch note MISSING. Search for arch-keycloak-oidc in pal-e-docs returned no results. [SCOPE] Create architecture note arch-keycloak-oidc for the Keycloak OIDC component.
• [x] Forgejo issue -- ldraney/westside-basketball#57, state: open

File Targets

• [ ] pal-e-platform Keycloak Terraform client -- ISSUE: No Keycloak client resource for westside-basketball exists in Terraform yet. The Keycloak module at pal-e-platform/terraform/modules/keycloak/ only defines infrastructure (namespace, deployment, service, themes), not client/realm resources. Per pal-e-platform's consolidation.md, old clients (westside-app, westside-spa) were destroyed and no client for westside-ror/westside-basketball exists. This is issue #54's job, not this ticket's.
• [ ] westside-basketball/config/initializers/omniauth.rb -- ISSUE: File does not exist. No OmniAuth configuration exists anywhere in westside-basketball. No keycloak references found in the codebase at all. This file would need to be created, not modified. This is also issue #54's responsibility.
• [ ] westside-basketball deployment config (KEYCLOAK_ISSUER) -- ISSUE: Neither k8s/dev.yaml nor docker-compose.yml contain any Keycloak env vars. These would need to be added, which is again issue #54's scope.
• [x] Landscaping-assistant reference pattern -- VERIFIED: landscaping-assistant/config/initializers/omniauth.rb exists and shows the target pattern (dynamic redirect_uri using KEYCLOAK_URL, KEYCLOAK_REALM, KEYCLOAK_CLIENT_ID, KEYCLOAK_CLIENT_SECRET, APP_URL env vars).

Repo Placement

The issue correctly identifies cross-repo scope (pal-e-platform for Terraform, westside-basketball for Rails config). However, the Forgejo issue is filed only on westside-basketball. Since most file targets actually belong to prerequisites (#54 Keycloak auth setup), the scope of THIS ticket may reduce to just Terraform redirect URI additions + verifying dynamic redirect_uri works with the public domain -- but only after #54 lands.

Dependencies

• depends:56 (board label) -- "Set up westsidekingsandqueens.com via Hetzner edge proxy" -- board item 1607, currently in backlog. This itself depends on godaddy-tofu.
• Undocumented dependency on #54 -- "Add Keycloak auth with admin/parent/player roles" -- board item 1605, currently in backlog. The issue body mentions this in Related but NOT in the depends label. This ticket cannot work without #54 landing first because no Keycloak client, no OmniAuth config, and no Keycloak env vars exist yet.
• Dependency chain: #54 (Keycloak auth) must land first, then #56 (DNS/proxy), then this ticket (#57). All three are in backlog.

Acceptance Criteria

6 acceptance criteria listed. They are generally testable but several are only verifiable after #54 and #56 land:

• AC1 (redirect URIs in Keycloak client) -- testable via Terraform plan, but requires #54 to create the client first
• AC2 (dynamic redirect_uri) -- testable in code review, but requires omniauth.rb to exist (#54)
• AC3 (end-to-end login flow) -- requires both #54 and #56 to be done
• AC4 (issuer validation) -- requires #54
• AC5 (auth.palinks.app accessible publicly) -- this is infrastructure, may already exist or may need separate work
• AC6 (Tailscale fallback) -- requires #54

6 AC exceeds the 5-criterion decomposition threshold. However, this is borderline -- the criteria are tightly coupled and the actual scope (once #54 and #56 exist) is small: add a redirect URI to Terraform + verify the flow. Decomposition is NOT recommended; instead, the scope should be narrowed to only the redirect URI changes that are incremental to #54.

Blast Radius

The landscaping-assistant precedent (issues #259 and #246) shows this exact pattern has been solved before. The blast radius is limited to:

• Keycloak client config for westside-basketball only (other clients unaffected)
• OmniAuth initializer for westside-basketball only
• No other services consume this Keycloak client

Low blast radius once dependencies are in place.

Decomposition Assessment

6 AC (exceeds 5 threshold), cross-repo (2 repos), but the file targets are largely invalid because they belong to prerequisite #54. Once #54 lands, the actual scope of this ticket shrinks to 1-2 files (Terraform redirect URI addition + verification). No decomposition needed -- the ticket needs scope narrowing, not splitting.

Recommendations

• [LABEL] Add depends:54 to the board item labels. Issue #54 (Keycloak auth) is an undocumented hard dependency -- no Keycloak client, no OmniAuth config, and no Keycloak env vars exist without it.
• [BODY] Narrow file targets: remove omniauth.rb creation and KEYCLOAK_ISSUER env var setup (those belong to #54). This ticket's file targets should be: (1) pal-e-platform Terraform -- add westsidekingsandqueens.com redirect URI to the westside-basketball Keycloak client (created by #54), (2) verify/adjust OmniAuth dynamic redirect_uri if #54 didn't already handle it.
• [BODY] Reduce acceptance criteria to only what is incremental to #54: redirect URI addition in Terraform, end-to-end login via public URL, Tailscale fallback still works. Remove criteria that #54 should satisfy (dynamic redirect_uri, issuer validation).
• [SCOPE] Create user story entry on project-westside-basketball user-stories section for auth/login flow. The board label story:WS-AUTH does not match any existing story. The issue body references WS-S7 which is about email announcements, not auth.
• [SCOPE] Create architecture note arch-keycloak-oidc for the Keycloak OIDC component.
• [LABEL] Fix story label from story:WS-AUTH to whatever new story ID is created for auth/login flow.

Verdict: APPROVED

Re-review of board item #1606. Prior review review-1606-2026-06-24 returned NEEDS_REFINEMENT with 5 recommendations. This re-review confirms all actionable items have been addressed.

Prior Review Resolution

• [x] [LABEL] story:WS-S7 → story:WS-S9 — FIXED. Board item now carries story:WS-S9.
• [x] [BODY] Route clarification (expand existing resources :players, only: []) — FIXED. Added to Constraints section.
• [x] [BODY] Outstanding balance calculation method — FIXED. Moved to companion ticket #58 (player detail page). No longer in scope for this ticket.
• [x] [DECOMPOSE] 11 AC across 2 pages → split into #55 (list) + #58 (detail) — FIXED. Issue #58 exists and is open.
• [ ] [SCOPE] Create architecture note arch-rails-views — STILL MISSING. No arch-rails-views note found in pal-e-docs. This is a documentation gap, not an issue body defect. Does not block implementation.

Template Completeness

• [x] Type — Feature
• [x] Lineage — references #54 (Keycloak auth dependency) and story WS-S9
• [x] Repo — ldraney/westside-basketball
• [x] User Story — Marcus (admin) wants scrollable player list with payment status at a glance
• [x] Context — explains current state (disjointed payments + roster pages), scope (list only, detail is #58)
• [x] File Targets — create (controller, view), modify (routes), don't-touch (payments, roster_report)
• [x] Feature Flag — none (appropriate for internal admin page)
• [x] Acceptance Criteria — 7 items
• [x] Test Expectations — 2 tests with run command
• [x] Constraints — includes route expansion note, mobile-first, no new tables, no Stripe API
• [x] Checklist — standard 3-item
• [x] Related — references #54 (auth), #58 (detail page)

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — WS-S9 found in project-westside-basketball user-stories section under Admin (Marcus)
• [ ] arch:rails-views label — no arch-rails-views note found in pal-e-docs. [SCOPE] Create architecture note arch-rails-views. Non-blocking.
• [x] Forgejo issue — ldraney/westside-basketball#55, state: open

File Targets

• [x] app/controllers/admin/players_controller.rb — to create. Directory app/controllers/admin/ exists with payments_controller.rb and roster_report_controller.rb as reference patterns. Verified.
• [x] app/views/admin/players/index.html.erb — to create. Parent directory app/views/admin/ exists with payments/ and roster_report/ subdirectories. Verified.
• [x] config/routes.rb — to modify. Existing resources :players, only: [] at line 15 in admin namespace. Constraints section correctly notes "expand existing — do not add duplicate resource block." Verified.
• [x] app/controllers/admin/payments_controller.rb — don't touch. Exists. Verified.
• [x] app/controllers/admin/roster_report_controller.rb — don't touch. Exists. Verified.

Data Model Verification

• [x] players table — exists with subscription_status enum and jersey_order_status enum
• [x] parent_id FK — exists on players table
• [x] Player model associations: belongs_to :parent, has_many :teams through :player_teams, has_many :orders, has_many :payment_links
• [x] No migrations needed — all columns and tables exist

Repo Placement

OK — issue filed on ldraney/westside-basketball, all file targets in the same repo. Single-repo change.

Dependencies

• depends:54 (board item #1605) — "Add Keycloak auth with admin/parent/player roles" — currently in backlog. Correctly documented in issue body and AC ("Admin role required, gated by #54 auth"). Existing admin controllers have no auth, so this ticket can be built without it and auth layered on after #54 lands. Test expectation for auth is correctly deferred.
• Board item #1609 (issue #58, player detail page) — depends:55. This ticket is the upstream dependency. AC #5 correctly notes clicking player name navigates to detail page "built in #58." No circular dependency.

Acceptance Criteria

7 AC items, all agent-verifiable:

• AC 1-4: List display, grouping/filtering, row content, payment status badges — testable via controller test and view assertions
• AC 5: Click-through to detail page — testable via link_to path assertion (detail page built in #58, link just needs correct path)
• AC 6: Mobile-responsive — relies on CSS patterns; acceptable for feature ticket with "landscaping-assistant Today view" style reference in Constraints
• AC 7: Admin role gating — deferred to #54; noted as gated dependency. Correct.

Blast Radius

• Existing /admin/payments and /admin/roster_report pages query similar data. Issue correctly notes these are untouched ("keep existing").
• Route expansion: existing resources :players, only: [] has a member { patch :monthly_fee } nested route. Expanding to only: [:index] will not conflict — :index is a collection route, :monthly_fee is a member route. Safe.
• Top-level resources :players, only: [:index] exists at line 22. No conflict — admin namespace is separate (/admin/players vs /players). Agent should be aware but no action needed.

Decomposition Assessment

7 AC across 1 page (list only). Creates 2 files, modifies 1. All AC concern a single controller action + single view. The 5-AC threshold exists to catch multi-page/multi-system sprawl, not tightly-coupled single-page criteria. Estimated agent work: 4-5 minutes. No decomposition needed.

Recommendation

• [SCOPE] Create architecture note arch-rails-views for the Rails views component. This is a documentation gap that persists from review-1, but does not block implementation. Can be created during or after the sprint.

All other prior recommendations resolved. Issue is well-scoped, decomposed, and ready for implementation.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] File Targets (create, modify, don't-touch sections)
• [x] Feature Flag (none, with justification)
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [ ] story:WS-S7 label -- MISMATCH. WS-S7 on project-westside-basketball says "As an admin, I want to send branded email announcements so that parent comms are professional and consistent." This ticket is about a player dashboard showing payment status. The issue body user story ("see at a glance who owes what without digging through Stripe manually") maps to story:WS-S9 ("As an admin, I want to track payment status per player so that I know who owes what"). [LABEL] Change story label from story:WS-S7 to story:WS-S9.
• [x] story note verified -- WS-S9 exists in project-westside-basketball user-stories section under Admin (Marcus)
• [ ] arch:rails-views label -- no arch-rails-views note found in pal-e-docs. [SCOPE] Create architecture note arch-rails-views for the Rails views component.
• [x] Forgejo issue -- ldraney/westside-basketball#55, state: open

File Targets

• [x] app/controllers/admin/players_controller.rb -- to create. Directory app/controllers/admin/ exists with payments_controller.rb and roster_report_controller.rb as reference patterns. Verified.
• [x] app/views/admin/players/index.html.erb -- to create. Parent directory app/views/admin/ exists with payments/ and roster_report/ subdirectories. Verified.
• [x] app/views/admin/players/show.html.erb -- to create. Same parent directory. Verified.
• [x] config/routes.rb -- to modify. File exists. NOTE: Current routes already have resources :players, only: [] in the admin namespace (used as nesting for the monthly_fee member route). The agent must expand this existing resource declaration to include [:index, :show] rather than adding a duplicate. [BODY] Add a note in File Targets: "Expand existing resources :players, only: [] to include [:index, :show] -- do not add a duplicate resource block."
• [x] app/controllers/admin/payments_controller.rb -- don't touch. Verified exists.
• [x] app/controllers/admin/roster_report_controller.rb -- don't touch. Verified exists.
• [x] db/schema.rb -- don't touch. Verified exists.

Data Model Verification

• [x] players table -- exists, has subscription_status enum and jersey_order_status enum as referenced in AC
• [x] parents table -- exists, has name, email, phone columns as needed for detail page
• [x] products table -- exists with category enum (jersey, contract, tournament, equipment, monthly)
• [x] orders table -- exists
• [x] payment_links table -- exists
• [x] email_log table -- exists with email_type enum including payment_request value and player_id FK
• [x] Player model has associations: belongs_to :parent, has_many :teams through :player_teams, has_many :orders, has_many :payment_links, has_many :email_logs
• [x] No migrations needed claim verified -- all tables and columns exist

Repo Placement

OK -- issue filed on ldraney/westside-basketball, all file targets are in the same repo. Single-repo change.

Dependencies

• depends:54 (board item #1605) -- "Add Keycloak auth with admin/parent/player roles" -- currently in backlog, state: open. This is correctly documented in the issue body ("depends on #54 landing first").
• AC item "Admin role required (depends on #54 landing first)" correctly acknowledges the dependency, but auth does not exist yet. The controller can be built without auth (matching existing admin controllers which also have no auth), and auth can be layered on after #54 lands.
• Test expectation "unauthenticated user redirected to login (after #54)" is correctly deferred.

Acceptance Criteria

11 AC items + 3 test expectations = 14 checkable items. Most are agent-verifiable via controller tests and view inspection. Concerns:

• "Mobile-responsive" (AC #10) -- hard to verify via automated tests; relies on CSS patterns. Landscaping-assistant reference style is mentioned in constraints but no specific CSS framework or breakpoint targets are given. This is acceptable for a feature ticket if the implementing agent follows responsive patterns.
• "Outstanding balance" (AC #8) -- no formula specified. The existing payments_controller.rb uses a hardcoded 552.0 expected amount per player. The ticket should clarify how outstanding balance is calculated (sum of unpaid orders? difference from expected total?). [BODY] Add clarification to AC #8: specify outstanding balance calculation method.

Blast Radius

• Existing /admin/payments and /admin/roster_report pages query similar data. The issue correctly notes these are kept as-is ("may deprecate later").
• The existing admin namespace route block has a resources :players, only: [] that must be expanded, not duplicated.
• There is also a top-level resources :players, only: [:index] route (non-admin). No conflict, but the agent should be aware.
• No auth exists on any admin controller currently. No blast radius from adding new unprotected admin routes (existing pattern).

Decomposition Assessment

NEEDS DECOMPOSITION -- 11 acceptance criteria across 2 pages (list + detail) with distinct UI concerns. Exceeds the 5 AC threshold. The work naturally splits into:

• Sub-ticket A: Player list page -- controller index action, index view, routes, list-specific tests (ACs 1-4, 10)
• Sub-ticket B: Player detail page -- controller show action, show view, detail-specific tests (ACs 5-9, 10)

Estimated agent work: 8-12 minutes as a single ticket; 4-6 minutes each if split. Route to skill-decompose-ticket.

Recommendation

• [LABEL] Change story label from story:WS-S7 to story:WS-S9 -- the user story is about payment tracking, not email announcements.
• [SCOPE] Create architecture note arch-rails-views for the Rails views component.
• [BODY] Add route clarification to File Targets: "Expand existing resources :players, only: [] to include [:index, :show] -- do not add a duplicate resource block."
• [BODY] Add outstanding balance calculation method to AC #8.
• [DECOMPOSE] 11 AC across 2 distinct pages, exceeds 5 AC threshold. Route to skill-decompose-ticket with sub-tickets: (A) player list page, (B) player detail page.

Verdict: APPROVED

Re-review of board item #1598 after scope refinement. Previous review review-1598-2026-06-24 returned NEEDS_REFINEMENT with 6 recommendations. 4 of 5 [BODY] recommendations fully addressed; 1 [SCOPE] item remains but is non-blocking.

Previous Recommendations Status

• [x] [BODY] Fix Repo field -- FIXED. Now correctly says ldraney/westside-basketball.
• [x] [BODY] Add Feature Flag section -- FIXED. Section present with "none" and rationale ("internal refactor, same external behavior").
• [x] [BODY] Rewrite File Targets -- FIXED. Paths align with spike #47 deliverables. Correctly references lib/delivery_methods/gmail_api.rb (namespaced), app/mailers/parent_mailer.rb, marks spike-delivered files as NOT to touch. Includes oauth_tokens migration as "potentially add."
• [x] [BODY] Rewrite Acceptance Criteria -- FIXED. ACs reference ParentMailer, EmailLogging, deliver_later. Nonexistent TournamentEmailService removed. Token storage AC added.
• [~] [BODY] Clarify blast/single-send routes -- PARTIALLY FIXED. See minor findings below.
• [ ] [SCOPE] Create arch note arch-westside-basketball -- NOT ADDRESSED. Non-blocking; tracked as standing recommendation.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Follows Spike #47 / PR #52
• [x] Repo -- ldraney/westside-basketball (correct)
• [x] User Story -- Present, well-scoped
• [x] Context -- Excellent. Explains spike deliverables, what's wired vs not, production concern.
• [x] File Targets -- Present, accurate (see verification below)
• [x] Feature Flag -- "none" with rationale
• [x] Acceptance Criteria -- 8 items, testable
• [x] Test Expectations -- Present with run command
• [x] Constraints -- Present (SolidQueue, sanitize raw body, no UI breakage)
• [x] Checklist -- Present
• [x] Related -- Present

Traceability

• [x] story:WS-S7 label -- "As an admin, I want to send branded email announcements so that parent comms are professional and consistent" -- verified in project-westside-basketball user-stories section
• [~] arch:westside-basketball label -- label present but no backing architecture note arch-westside-basketball exists in pal-e-docs. Standing [SCOPE] recommendation from previous review. Non-blocking for this ticket.
• [x] Forgejo issue -- ldraney/westside-basketball#14, state: open

File Targets

All file targets verified against main branch and spike branch (origin/47-actionmailer-spike).

Files to modify (verified):

• [x] config/environments/development.rb -- exists on main. No delivery_method set currently. Correct target.
• [x] config/environments/production.rb -- exists on main. No delivery_method set currently. Correct target.
• [x] app/controllers/emails_controller.rb -- exists on main. Confirmed: send_email action calls GmailClient.new / client.send_email directly (lines 28-29). Spike did NOT modify this file. Correct target.
• [x] app/mailers/parent_mailer.rb -- exists on spike branch. Confirmed: spike's version does NOT include EmailLogging. Adding the concern here is correct.
• [x] app/mailers/application_mailer.rb -- exists on main, updated by spike. Issue correctly says "no changes expected."

Files potentially added (verified):

• [x] db/migrate/*_move_oauth_tokens_to_db.rb -- oauth_tokens table already exists in schema with provider, account, token_data columns. OauthToken model exists. Migration would update DeliveryMethods::GmailApi to read from DB instead of config/gmail/token.json.
• [x] lib/delivery_methods/gmail_api.rb -- exists on spike branch. Currently reads file-based tokens. Modification for DB tokens is correctly scoped.

Files NOT to touch (verified):

• [x] app/mailers/concerns/email_logging.rb -- exists on spike branch. Complete implementation with after_deliver callback. No changes needed.
• [x] app/views/parent_mailer/ -- 4 templates exist on spike branch (announcement + payment_reminder, HTML + text). No changes needed.

Repo Placement

Correct. Issue filed on ldraney/westside-basketball, Repo section says ldraney/westside-basketball. All file targets are within this repo. Single-repo scope.

Dependencies

• depends:47 (Spike: Rails email sending) -- label present and correct. Spike is board item #1579, column in_progress, PR #52 open. This issue CANNOT start until spike merges. Clearly documented in issue Lineage and Context.
• Board item #1580 (Queens EYBL email, todo) and #1581 (Email #2 TBD, backlog) both carry depends:47. After #47 merges and #14 activates the mechanism, those items become unblocked.
• SolidQueue dependency noted in Constraints section -- solid_queue gem confirmed in Gemfile. Queue adapter activation for production may need attention (currently commented out in production.rb).

Acceptance Criteria

8 criteria. Assessment:

• [x] AC 1 (delivery_method in dev/prod) -- Testable. Grep config files.
• [x] AC 2 (announcement uses ParentMailer.deliver_later) -- Testable. Unit test on controller.
• [x] AC 3 (payment_reminder uses ParentMailer.deliver_later) -- Testable, but note: EmailsController currently has no payment_reminder action. Agent will need to add one or clarify scope. Minor ambiguity -- acceptable, agent can resolve.
• [x] AC 4 (EmailLogging in ParentMailer) -- Testable. Check concern inclusion and email_log writes.
• [~] AC 5 (compose form works e2e) -- Route is /emails/compose, NOT /admin/emails/new as stated. Minor path error but intent is clear. Agent will find the correct route.
• [x] AC 6 (blast functionality works) -- Current "blast" is the compose form sending to selected team parents. No separate blast endpoint. Intent is clear.
• [x] AC 7 (GmailClient deprecated) -- Testable. Remove send calls, keep read/inbox methods.
• [x] AC 8 (token storage) -- "Migrated to DB or documented as follow-up" -- flexible, testable either way.

Test run command: bin/rails test test/controllers/emails_controller_test.rb test/mailers/ -- these files do not exist yet. Agent will create them. This is expected for a feature ticket.

Blast Radius

Low. GmailClient is used in exactly 2 places: emails_controller.rb lines 28-29 (send_email) and line 37 (inbox). The send path gets replaced by ParentMailer; the inbox/read path stays on GmailClient. No other consumers. No cross-repo impact.

If token storage migration is included, blast radius increases slightly to lib/delivery_methods/gmail_api.rb and app/services/gmail_client.rb (both read tokens). Contained within the same repo.

Decomposition Assessment

5 files to modify across 1 repo, 8 acceptance criteria. Post-spike scope is primarily: activate delivery method in 2 config files, rewrite 1 controller action, add 1 concern include, optionally migrate token storage. Estimated agent work: ~5 minutes. Borderline on AC count (8 > 5 threshold) but the individual changes are small and tightly coupled. No decomposition needed.

Recommendations

Minor items -- none blocking. Verdict is APPROVED.

• [BODY] AC 5: fix route path /admin/emails/new to /emails/compose (routes.rb confirms emails are not under admin namespace).
• [BODY] AC 3: clarify whether #14 adds a payment_reminder controller action or if that's future work (current controller only has generic send_email).
• [SCOPE] Create architecture note arch-westside-basketball in pal-e-docs (standing from previous review, non-blocking).

If APPROVED: No action needed. Minor body items can be addressed during implementation.

Verdict: APPROVED

Re-review of board item #1580. Previous review (review-1580-2026-06-23) returned NEEDS_REFINEMENT with 7 recommendations. All 6 actionable fixes (5 [BODY], 1 [LABEL]) have been applied. The remaining [SCOPE] item (missing arch note) is a project-level documentation gap, not a ticket-scope blocker.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- depends on #47, part of story:WS-S7
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As an admin (Marcus), send tournament details email to Queens families
• [x] Context -- Nike EYBL Live Period, Las Vegas, July 9-13, stay-to-play required
• [x] Email Details -- full email body provided inline
• [x] File Targets -- tournament_mailer.rb, queens_eybl.html.erb, queens_eybl.text.erb, admin trigger mechanism (was MISSING, now present)
• [x] Feature Flag -- "None -- admin-triggered one-shot send" (was MISSING, now present with justification)
• [x] Acceptance Criteria -- 5 items present (was 4, added Queens-only audience AC)
• [x] Test Expectations -- ActionMailer helpers, delivery assertions, audience scoping test (was MISSING, now present)
• [x] Constraints -- dependency on #47, 72-hour deadline, audience query
• [x] Checklist -- PR opened, tests pass, no unrelated changes, Marcus review (was MISSING, now present)
• [x] Related -- links to #47, #49, story:WS-S7, sop-email-send

All required template-issue-feature sections are present.

Traceability

• [x] story:WS-S7 label -- "As an admin, I want to send branded email announcements so that parent comms are professional and consistent" (was story:email, fixed to story:WS-S7)
• [x] story note verified -- WS-S7 found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:westside-basketball label -- present on board item
• [ ] arch note MISSING -- arch-westside-basketball note does not exist in pal-e-docs. [SCOPE] Create architecture note arch-westside-basketball. This is a pre-existing project-level gap, not a ticket-scope deficiency. Does not block this ticket.
• [x] Forgejo issue -- #48, open, valid URL

File Targets

• [x] app/mailers/tournament_mailer.rb -- to be created. Parent class app/mailers/application_mailer.rb exists (still has default from@example.com, will be updated by #47). Verified.
• [x] app/views/tournament_mailer/queens_eybl.html.erb -- to be created. Views directory convention is consistent with Rails mailer pattern. Verified.
• [x] app/views/tournament_mailer/queens_eybl.text.erb -- to be created. Plain-text fallback is good practice. Verified.
• [x] Admin trigger mechanism -- left flexible (dashboard button, rake task, or runner script). Acceptable since #47 spike will determine the pattern.

All file targets are valid Rails conventions. Parent files verified to exist.

Repo Placement

OK. Issue filed on ldraney/westside-basketball. All work belongs in that repo. Single-repo change.

Dependencies

• depends:47 (Spike: Rails email sending -- ActionMailer setup and docs) -- board item #1579, currently in backlog. Hard dependency: #47 establishes the email sending mechanism. #48 cannot start until #47 is merged. Correctly documented in issue body (Lineage, Constraints) and board item labels.
• Sibling: #49 (Email #2, TBD) -- board item #1581, also depends on #47. No circular dependency.

Acceptance Criteria

• [x] "Email is sent to all Queens family email addresses" -- testable via ActionMailer delivery assertions
• [x] "Audience query returns only Queens team parents (not Kings)" -- testable. Data model supports this: Team has division enum (boys/girls), traverse teams -> player_teams -> players -> parent for email addresses. Filter by division: "girls". (This AC was added per previous review recommendation.)
• [x] "Email body matches the content above (formatted, not plain text)" -- testable via ActionMailer preview or template assertion
• [x] "Email is sent from the configured Westside sending address" -- testable, depends on #47
• [x] "Send is logged (who received, timestamp)" -- testable, EmailLog model exists with parent and player associations

All 5 AC are specific, testable, and agent-verifiable.

Blast Radius

Low. New mailer class + views + trigger. Does not modify existing email infrastructure (#47 does that). No sibling services affected. EmailLog model already exists. Main risk (sending to wrong audience) is covered by AC #2. The division enum cleanly separates boys (Kings) from girls (Queens).

Decomposition Assessment

5 AC, 1 repo, 3-4 file targets. Estimated agent work: under 5 minutes once #47 is complete. No decomposition needed. 3 points is appropriate.

Recommendations

• [SCOPE] Create architecture note arch-westside-basketball for the westside-basketball component. This is a pre-existing project-level gap that affects all tickets with the arch:westside-basketball label, not specific to this ticket. Does not block APPROVED.

All other previous recommendations have been addressed. Ticket is ready for implementation once #47 (email spike) is complete.

Verdict: APPROVED

Re-review of board item #1582 after refinement. Previous review (review-1582-2026-06-23) returned NEEDS_REFINEMENT with 4 [BODY] recommendations. All 4 have been addressed.

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- Standalone, part of story:WS-S9
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- well-formed As/I want/So that
• [x] Context -- excellent; now acknowledges existing /admin/payments dashboard, StripeClient#db_payment_summary, and frames this as a filtered delinquency report
• [x] File Targets -- 4 targets, all verified (see below)
• [x] Feature Flag -- none (appropriate for admin-only tool)
• [x] Acceptance Criteria -- 4 criteria, all specific and testable
• [x] Test Expectations -- present with run command
• [x] Constraints -- present, time-sensitive noted
• [x] Checklist -- present
• [x] Related -- present
• [x] Definition of "behind on payment" -- NEW SECTION, explicitly defines the filter condition with enum values

Traceability

• [x] story:WS-S9 label -- "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified -- found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:westside-basketball label -- references the main app repo
• [ ] arch note MISSING -- [SCOPE] Create architecture note arch-westside-basketball for component westside-basketball. No matching note found in pal-e-docs. (Carried forward from previous review; not a blocker for this ticket.)
• [x] Forgejo issue -- ldraney/westside-basketball#50, open

File Targets

• [x] lib/tasks/payments.rake -- verified: lib/tasks/ directory exists (contains .keep). Valid creation target, and the issue correctly frames this as "create new".
• [x] app/controllers/admin/payments_controller.rb -- verified: exists with index action and payment dashboard logic. Issue correctly lists as alternative endpoint location.
• [x] app/services/stripe_client.rb -- verified: exists with db_payment_summary method at line 157. Method already queries payment_links grouped by team with total_owed/total_paid per player. Issue correctly says "reuse existing logic or extract a filtered variant".
• [x] Database tables -- verified: payment_links table exists (schema.rb line 211) with amount_cents, paid_at, status (enum paymentlinkstatus: active/paid/canceled). players table exists (line 236) with name. parents table exists (line 185) with name and email. Issue correctly notes "there is no payments table".

Refinement Fixes Verified

All 4 recommendations from the previous review have been addressed:

1. [BODY] Fix table reference -- FIXED. Issue now says "payment_links, players, and parents tables" with explicit note that there is no payments table.
2. [BODY] Acknowledge existing infrastructure -- FIXED. Context section references /admin/payments, StripeClient#db_payment_summary, and positions this as a filtered delinquency report.
3. [BODY] Narrow AC3 output format -- FIXED. AC3 now specifies CSV format explicitly. AC4 added as exclusion criterion.
4. [BODY] Define "behind on payment" -- FIXED. New dedicated section defines: status = 'active' AND paid_at IS NULL. Enum values documented. Amount owed = sum of amount_cents on unpaid active links.

Repo Placement

OK -- issue filed on ldraney/westside-basketball, which is the correct repo. All file targets are within this repo. Single-repo scope.

Dependencies

• No blocking dependencies. All related payment items (Phase 6 Stripe, commerce admin, webhook sync) are in the done column.
• The existing StripeClient#db_payment_summary is a solid foundation. The new report can reuse or adapt its query pattern.
• ActionMailer spike (#1579) is in backlog but is NOT a dependency -- the output format is now CSV (not email), so no ActionMailer needed.

Acceptance Criteria

• [x] AC1 "Query identifies all players with outstanding payment_links (status = active with paid_at IS NULL)" -- testable, precisely defined, matches schema.
• [x] AC2 "Output includes: player name, parent name, parent email, amount owed, last payment date" -- testable. parent.name column confirmed in schema. Existing db_payment_summary returns email but not parent name; minor addition.
• [x] AC3 "Output is CSV format" -- testable, specific format chosen.
• [x] AC4 "Players with no outstanding payment_links are excluded" -- testable, clear exclusion criterion.

Blast Radius

Low. Read-only report, no mutations. Reuses existing query patterns from StripeClient. No downstream consumers affected. One minor note: the existing db_payment_summary treats ALL active links as "owed" regardless of paid_at; the new definition (active AND paid_at IS NULL) is more precise, which is correct behavior for a delinquency report.

Decomposition Assessment

No decomposition needed. Single file creation (rake task) or minor controller addition in one repo, with 4 acceptance criteria. Estimated agent time: well under 5 minutes.

Recommendation

No action needed. All previous refinement issues resolved. Ticket is ready for implementation.

Note: the missing arch-westside-basketball note is a project-level gap, not a ticket blocker. It should be tracked separately.

Verdict: APPROVED

Re-review of board item #1579 after refinement. Previous review review-1579-2026-06-23 returned NEEDS_REFINEMENT with 5 findings. All 5 have been addressed.

Previous Findings -- Resolution Status

1. [LABEL] story label -- FIXED. Board item label changed from story:email to story:WS-S7. Verified on board item.
2. [SCOPE] arch note missing -- ACKNOWLEDGED. arch-westside-basketball note still does not exist in pal-e-docs, but label arch:westside-basketball references a valid component. For a spike (docs output only), this is acceptable. The arch note can be created as part of broader project scaffolding -- not a blocker.
3. [BODY] westside-ror references -- FIXED. All references in issue body now say westside-basketball. Zero occurrences of westside-ror remain.
4. [BODY] gmail_client.rb missing -- FIXED. app/services/gmail_client.rb now explicitly referenced in the Question section under both "ActionMailer vs Gmail API" (with details: wraps Google::Apis::GmailV1::GmailService, sends via send_user_message) and "Existing state" (noted as "production-proven").
5. [BODY] PR #17 and issue #14 missing -- FIXED. Related section now includes #14 (open issue) and #17 (closed PR, correctly noted as "not merged"). Note: previous review incorrectly stated PR #17 was "merged" -- it was closed without merging. The updated issue body is accurate.

Template Completeness

• [x] Type -- Spike
• [x] Lineage -- standalone, references westside-emails and basketball-api
• [x] Repo -- ldraney/westside-basketball (correct)
• [x] Question -- well-structured with 5 sub-questions, includes existing state and gmail_client.rb reference
• [x] Deliverables -- 4 items: docs file, ApplicationMailer update, config/secrets, follow-up ticket updates
• [x] Time-box -- 2 hours / 1 session
• [x] Related -- references project, stories (WS-S7, WS-S32), prior art (#14, #17), downstream (#48, #49)

Traceability

• [x] story:WS-S7 label -- "As an admin, I want to send branded email announcements so that parent comms are professional and consistent"
• [x] story note verified -- WS-S7 found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] story:WS-S32 referenced in issue body -- "generic email blast system with pluggable audience queries" -- also verified on project page
• [ ] arch note gap -- board item has arch:westside-basketball but no arch-westside-basketball note exists. Acceptable for spike -- not a blocker. Recommend creating as part of broader project work.
• [x] Forgejo issue -- ldraney/westside-basketball#47, open

File Targets

• [x] app/mailers/application_mailer.rb -- verified: exists with from: "from@example.com" and layout "mailer"
• [x] app/views/emails/ -- verified: contains compose.html.erb, inbox.html.erb, index.html.erb (email preview pages, not mailer templates -- issue description is accurate)
• [x] Gemfile google-apis-gmail_v1 -- verified: present at line 20
• [x] config/environments/production.rb SMTP settings -- verified: commented-out defaults, action_mailer.default_url_options set to example.com
• [x] app/views/layouts/mailer.html.erb and mailer.text.erb -- verified: both present
• [x] app/services/gmail_client.rb -- verified: exists, referenced in issue body. Used by emails_controller.rb (lines 28, 37).

Repo Placement

Correct. Issue filed on ldraney/westside-basketball, investigation targets same repo. No cross-repo mismatch.

Dependencies

• Board item #1580 (Email: Queens EYBL tournament, Forgejo #48) has depends:47 -- correctly documented
• Board item #1581 (Email #2: TBD, Forgejo #49) has depends:47 and status:blocked-on-spec -- correctly documented
• Board item #1582 (Report: players behind on payment, Forgejo #50) -- independent, no dependency on this spike
• Prior art: Issue #14 (open) and PR #17 (closed, NOT merged) now referenced in Related section

Acceptance Criteria

Spike deliverables are clear and verifiable: docs file existence, ApplicationMailer config change, production/dev email config, follow-up ticket updates. All can be verified by file reads or issue inspection. Minor note: ApplicationMailer update is technically implementation, not investigation, but acceptable for a 2pt spike bundling a quick config fix.

Blast Radius

Low. Docs-only spike output. Existing GmailClient service is production-active (used by emails_controller.rb). Spike investigates but does not change running code. Legacy basketball-api email system exists but is being replaced -- no downstream impact from documentation.

Decomposition Assessment

No decomposition needed. Single repo, 2 points, 1 doc file output, 2-hour time-box. Well within the 5-minute agent pass threshold.

Recommendation

No action needed. All previous findings resolved. The remaining arch note gap (arch-westside-basketball) is a broader project scaffolding task, not a blocker for this spike.

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type — Feature
• [x] Lineage — Standalone, part of story:WS-S9
• [x] Repo — ldraney/westside-basketball
• [x] User Story — well-formed As/I want/So that
• [x] Context — adequate background
• [x] File Targets — present but inaccurate (see below)
• [x] Feature Flag — none (appropriate for admin-only tool)
• [x] Acceptance Criteria — 3 criteria
• [x] Test Expectations — present
• [x] Constraints — present, time-sensitive noted
• [x] Checklist — present
• [x] Related — present

Traceability

• [x] story:WS-S9 label — "As an admin, I want to track payment status per player so that I know who owes what"
• [x] story note verified — found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:westside-basketball label — references the main app repo
• [ ] arch note MISSING — [SCOPE] Create architecture note arch-westside-basketball for component westside-basketball. No matching note found in pal-e-docs.
• [x] Forgejo issue — ldraney/westside-basketball#50, open

File Targets

• [ ] lib/tasks/payments.rake — ISSUE: file does not exist. The lib/tasks/ directory is empty. This is a valid creation target but should be stated as "create new" not implied as existing.
• [x] app/controllers/admin/payments_controller.rb — verified: exists, already has payment dashboard logic with index action including both Stripe and DB payment summaries.
• [ ] "Database query against players, payments, and parents tables" — ISSUE: there is no payments table. The actual tables are payment_links (with status, amount_cents, paid_at), players, and parents. The issue should reference the correct table names.

Critical discovery: existing infrastructure

The existing codebase already has almost everything this ticket describes:

• Admin::PaymentsController#index — full payment dashboard at /admin/payments
• StripeClient#db_payment_summary — returns per-team, per-player data including: player name, parent email, total owed, total paid, per-link status and paid_at dates
• app/views/admin/payments/index.html.erb — renders all payment data in table format, already showing player name, parent email, paid amount, owes amount, and status

The "report" may simply be a filtered view of the existing dashboard (unpaid players only) or a rake task / CSV export wrapper around the existing db_payment_summary method. The issue should acknowledge this existing infrastructure and clarify what additional output format is needed beyond the existing dashboard.

Repo Placement

OK — issue filed on ldraney/westside-basketball, which is the correct repo. All file targets are within this repo. Single-repo scope.

Dependencies

• No blocking dependencies. All related payment items (Phase 6 Stripe, contract flow, commerce admin, webhook sync) are in the done column.
• The existing payment dashboard and StripeClient#db_payment_summary are solid foundations — this ticket extends them rather than building from scratch.
• Item #1579 (Spike: Rails email sending — ActionMailer setup) is in backlog. If "delivered as email" is the intended output format, this ticket may depend on #1579. Currently undocumented.

Acceptance Criteria

• [x] AC1 "Query identifies all players with overdue or missing payments" — testable, though "overdue" needs definition. The DB uses payment_links.status and paid_at — "overdue" could mean status=active with no paid_at, but this should be explicit.
• [x] AC2 "Output includes: player name, parent name, parent email, amount owed, last payment date" — testable. Note: existing db_payment_summary already returns all of these except "parent name" (it returns parent email only). The parents table has a name column, so this is a minor addition.
• [ ] AC3 "List is delivered in a format Marcus can act on (email, spreadsheet, or console output)" — too vague. Which format? If email: depends on ActionMailer (#1579). If spreadsheet: needs CSV generation. If console: rake task or rails runner. Pick one.

Blast Radius

Low blast radius. This is a read-only report — no mutations to existing data. The existing StripeClient#db_payment_summary is already called by the payments controller; adding a rake task that calls the same method is safe. No downstream consumers affected.

One consideration: the existing dashboard uses a hardcoded expected amount of $552.0 for the Stripe links section. The ticket should clarify whether this threshold is relevant or if the DB payment links section (which tracks actual amounts owed) is the correct data source.

Decomposition Assessment

No decomposition needed. This is a single-file addition (rake task or controller enhancement) in one repo, with 3 acceptance criteria. Estimated agent time: well under 5 minutes. The existing db_payment_summary method does most of the heavy lifting already.

Recommendation

• [BODY] Fix file targets: remove "Database query against players, payments, and parents tables" — the correct table is payment_links (not payments), joined with players and parents.
• [BODY] Acknowledge existing infrastructure: Admin::PaymentsController#index, StripeClient#db_payment_summary, and the payment dashboard view already contain the data this report needs. Clarify whether this ticket adds a rake task, CSV export, or filtered view on top of the existing dashboard.
• [BODY] Narrow AC3: specify the output format (CSV file, rake task console output, email, or filtered dashboard page). If email is chosen, add dependency on #1579 (ActionMailer spike).
• [BODY] Define "behind on payment" — does it mean any player with an active (unpaid) payment_link? Or players missing payment links entirely? Or players below a dollar threshold? The existing dashboard distinguishes between Stripe manual links (hardcoded $552 threshold) and DB payment links (per-link status tracking).

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Spike
• [x] Lineage -- standalone, references westside-emails and basketball-api
• [x] Repo -- present (but wrong name, see below)
• [x] Question -- well-structured with 5 sub-questions
• [x] Deliverables -- 4 items, includes docs file and follow-up ticket updates
• [x] Time-box -- 2 hours / 1 session
• [x] Related -- references project, stories, and downstream issues

Traceability

• [ ] story label MISMATCH -- board item has story:email but story:email is not a canonical story ID. Issue body references story:WS-S7 (admin branded email announcements) and story:WS-S32 (generic email blast system). Both exist on the project page under Admin (Marcus). [LABEL] Change board label from story:email to story:WS-S7 (primary story this spike serves).
• [x] story notes verified -- WS-S7 ("As an admin, I want to send branded email announcements so that parent comms are professional and consistent") and WS-S32 ("As an admin, I want a generic email blast system with pluggable audience queries") both found in project-westside-basketball user-stories section.
• [ ] arch note MISSING -- board item has arch:westside-basketball but no arch-westside-basketball note exists in pal-e-docs. [SCOPE] Create architecture note arch-westside-basketball for the westside-basketball component, or change label to a more specific arch component (e.g., arch:email which is used on other board items like #750, #751, #752).
• [x] Forgejo issue -- ldraney/westside-basketball#47, open

File Targets

• [x] app/mailers/application_mailer.rb -- verified: exists with placeholder from: "from@example.com" and layout "mailer"
• [x] app/views/emails/ -- verified: contains compose.html.erb, inbox.html.erb, index.html.erb (email preview pages, not mailer templates -- issue description is accurate)
• [x] Gemfile google-apis-gmail_v1 -- verified: present at line 20
• [x] config/environments/production.rb SMTP settings -- verified: all commented-out defaults, action_mailer.default_url_options set to example.com
• [x] Mailer layouts exist -- app/views/layouts/mailer.html.erb and mailer.text.erb present
• [ ] app/services/gmail_client.rb NOT MENTIONED -- this file exists and contains a working Gmail OAuth send implementation (GmailClient class with credentials/token file paths, send_email method). This is directly relevant to the spike's core question (ActionMailer vs Gmail API) and should be referenced in the issue. [BODY] Add app/services/gmail_client.rb to the Question section under "Existing state" -- it's a working Gmail OAuth sender that the spike needs to evaluate.

Repo Placement

MISMATCH: Issue body says ldraney/westside-ror in three places (Repo section, follow-up references to #48 and #49). The repo was renamed to ldraney/westside-basketball. Forgejo redirects the old URLs, but the issue body should be updated for clarity. [BODY] Replace all westside-ror references with westside-basketball.

Dependencies

• Board item #1580 (Email: Queens EYBL tournament, Forgejo #48) has depends:47 label -- correctly documented as dependent
• Board item #1581 (Email #2: TBD, Forgejo #49) has depends:47 and status:blocked-on-spec -- correctly documented as dependent and blocked on Marcus's input
• Board item #1582 (Report: players behind on payment, Forgejo #50) is in backlog but has no dependency on this spike -- independent
• Existing closed work: PR #17 "Refactor email system to ActionMailer with Gmail API delivery" is merged. Issue #14 "Refactor email sending to use ActionMailer with Gmail API delivery adapter" is still open. The spike should reference these -- they may already contain decisions that inform this spike. [BODY] Add PR #17 (merged) and issue #14 (open) to the Related section -- previous ActionMailer refactor work.

Acceptance Criteria

Spike deliverables are clear and testable:

• docs/email-sending.md -- verifiable by file existence and content review
• ApplicationMailer updated -- verifiable by reading the file
• Production/dev email config -- verifiable by reading config files or documented secrets list
• Follow-up tickets #48/#49 updated -- verifiable by reading issue bodies

One concern: the deliverable "ApplicationMailer updated with correct default from: address" goes beyond spike output (a spike produces docs + tickets, not code changes). This could be a quick config change that's fine to bundle, but technically it's implementation, not investigation. Minor -- acceptable for a 2pt spike.

Blast Radius

Low blast radius. This is a docs-only spike. The existing GmailClient service and related email infrastructure (EmailLog model, email_log table) are already in production. The spike's investigation may recommend changes but won't make them. No downstream services are affected by documentation.

Note: The legacy basketball-api (Python/FastAPI) has its own email system with MJML templates (board items #750-#753 show completed email infrastructure there). The spike should be aware this exists to avoid reinventing patterns.

Decomposition Assessment

No decomposition needed. Single repo, 2 points, 1 doc file output, 2-hour time-box. Well within the 5-minute agent pass threshold for spike investigation.

Recommendations

• [LABEL] Change board item story label from story:email to story:WS-S7 (canonical story ID from project page)
• [SCOPE] Create architecture note arch-westside-basketball in pal-e-docs, OR change board label to arch:email (which has an existing usage pattern on this board)
• [BODY] Replace westside-ror with westside-basketball in Repo section and Related section references
• [BODY] Add app/services/gmail_client.rb to "Existing state" in the Question section -- it's a working Gmail OAuth sender directly relevant to the spike's core question
• [BODY] Add PR #17 (merged ActionMailer refactor) and issue #14 (open ActionMailer refactor issue) to the Related section

Verdict: NEEDS_REFINEMENT

Template Completeness

• [x] Type -- Feature
• [x] Lineage -- depends on #47
• [x] Repo -- ldraney/westside-basketball
• [x] User Story -- As an admin (Marcus), send tournament details email
• [x] Context -- EYBL Live Period, Las Vegas, July 9-13
• [ ] File Targets -- MISSING. No file paths listed. Issue should specify which mailer class to create, which view template, and which controller action or rake task triggers the send.
• [ ] Feature Flag -- MISSING. Section required by template-issue-feature. This is a new user-visible email send capability. Recommend: "none" with justification (one-shot admin-triggered action, not a persistent feature toggle), or flag it if email sending should be gated.
• [x] Acceptance Criteria -- 4 items present
• [ ] Test Expectations -- MISSING. No test section. Should specify ActionMailer test helpers, email delivery assertion, email_log record creation.
• [x] Constraints -- present (dependency on #47, 72-hour deadline, audience query)
• [ ] Checklist -- MISSING (PR opened, tests pass, no unrelated changes)
• [x] Related -- present (links to #47, #49, story:WS-S7, sop-email-send)

Traceability

• [ ] story:email label -- MISMATCH. Board item label is story:email, but issue body references story:WS-S7 (As an admin, I want to send branded email announcements so that parent comms are professional and consistent). WS-S7 is verified on project-westside-basketball user-stories section. [LABEL] Change board item label from story:email to story:WS-S7.
• [ ] arch:westside-basketball label -- arch note MISSING. mcp__pal-e-docs__search_notes(query="arch-westside-basketball") returned no results. [SCOPE] Create architecture note arch-westside-basketball for the westside-basketball component.
• [x] Forgejo issue -- #48, open, valid URL (redirects from old westside-ror name)

File Targets

No file targets listed in the issue. Based on repo inspection, the following files are relevant:

• app/mailers/application_mailer.rb -- exists, still has default from@example.com (will be updated by #47)
• app/services/gmail_client.rb -- exists, legacy Gmail API client
• app/models/email_log.rb -- exists, for send logging
• app/models/tournament.rb -- exists, tournament model
• app/controllers/emails_controller.rb -- exists, email management
• app/views/emails/ -- exists, email preview pages

Issue should specify: new mailer class (e.g. app/mailers/tournament_mailer.rb), new mailer view (e.g. app/views/tournament_mailer/queens_eybl.html.erb), and how the send is triggered (admin action, rake task, or controller endpoint).

Repo Placement

OK. Issue is filed on ldraney/westside-basketball, and the work belongs in that repo. Board item forgejo_issue_url still shows old name (westside-ror) but Forgejo redirects correctly.

Dependencies

• depends:47 (Spike: Rails email sending -- ActionMailer setup and docs) -- board item #1579, currently in backlog. This is a hard dependency: #47 establishes the email sending mechanism (ActionMailer config, SMTP vs Gmail API decision, template strategy). #48 cannot be implemented until #47 is complete and merged.
• Sibling: #49 (Email #2, TBD) -- board item #1581, also depends on #47. No circular dependency.
• Dependency is correctly documented in both the issue body (Lineage, Constraints) and the board item labels (depends:47).

Acceptance Criteria

• [x] "Email is sent to all Queens family email addresses" -- testable, but needs clarification: what defines "Queens family"? The Constraints section says "all parents with a daughter on a Queens team" which helps. Agent needs a query/scope to identify these records.
• [x] "Email body matches the content above" -- testable via ActionMailer preview or test assertion against the template. The full email body is provided inline, which is good.
• [x] "Email is sent from the configured Westside sending address" -- testable, depends on #47 establishing the address.
• [x] "Send is logged (who received, timestamp)" -- testable, email_log model already exists.

AC are reasonable and verifiable. Could benefit from one more: "Audience query returns only Queens team parents (not Kings)".

Blast Radius

Low. This is a new mailer class + view + trigger. It does not modify existing email infrastructure (that is #47's job). No sibling services affected. The email_log model already exists. The main risk is sending to wrong recipients (Kings families instead of Queens), which AC should cover.

Decomposition Assessment

4 AC, 1 repo, ~3 file targets (mailer, view, trigger). Estimated agent work: under 5 minutes once #47 is complete. No decomposition needed.

Recommendations

• [BODY] Add File Targets section: specify the new mailer class, mailer view template, and trigger mechanism (controller action or rake task).
• [BODY] Add Feature Flag section: "none" with justification (admin-triggered one-shot action), or specify a flag if email sending should be gated.
• [BODY] Add Test Expectations section: ActionMailer test helpers, email delivery count assertion, email_log record creation, audience query correctness.
• [BODY] Add Checklist section (PR opened, tests pass, no unrelated changes).
• [BODY] Add AC: "Audience query returns only Queens team parents (not Kings or other teams)".
• [LABEL] Change board item label from story:email to story:WS-S7.
• [SCOPE] Create architecture note arch-westside-basketball for the westside-basketball component.

Verdict: NEEDS_REFINEMENT

Re-review of board item #1375 after major refinement. Previous issues (wrong repo, ingress conflict, wrong secret pattern, port mismatch) were all addressed. Two new issues found.

Template Completeness

• [x] Type — Feature
• [x] Lineage — Child of #40, depends on #41
• [x] Repo — specifies forgejo_admin/pal-e-deployments
• [x] User Story — present
• [x] Context — thorough, includes platform pattern, existing resources, database, port
• [x] File Targets — 6 files to create, exclusion list present
• [x] Acceptance Criteria — 8 criteria
• [x] Test Expectations — kustomize build, SOPS decrypt, ArgoCD sync, dry-run command
• [x] Constraints — 5 constraints, all clear
• [x] Checklist — present
• [x] Related — 5 references

All required sections present and complete.

Traceability

• [x] story:ci-pipeline label — maps conceptually to story:WS-S1 ("deploy platform changes via IaC so that infrastructure is reproducible and auditable") on project-westside-basketball
• [x] story note verified — WS-S1 exists in project-westside-basketball user-stories section under Superadmin
• [ ] arch:k8s label — no matching architecture note found in pal-e-docs — [SCOPE] Create architecture note arch-k8s for Kubernetes component
• [x] Forgejo issue — ldraney/westside-ror#42, state: open

File Targets

• [ ] overlays/westside-ror/prod/kustomization.yaml — ISSUE: file ALREADY EXISTS in pal-e-deployments. Current version references bases/standard, renames to westside-ror, sets port 3000, uses ruby:3.4-slim image (not Harbor). Ticket says "create" but should say "update" to add SOPS secret resources, Harbor image, ingress resources, and namespace
• [ ] overlays/westside-ror/prod/deployment-patch.yaml — ISSUE: file ALREADY EXISTS. Current version has hostPath volume mount (/home/ldraney/westside-ror), inline apt-get/bundle install command, and envFrom secretRef to rails-env. Ticket says "create" but should say "replace" with proper prod pattern (initContainer, SOPS secret refs, security context, no hostPath)
• [x] overlays/westside-ror/prod/ingress.yaml — does not exist yet, correct to create. Tailscale Funnel pattern confirmed from westsidekingsandqueens/prod/ingress.yaml
• [x] overlays/westside-ror/prod/ingress-westsidekingsandqueens.yaml — does not exist yet, correct to create
• [x] overlays/westside-ror/prod/secrets.enc.yaml — does not exist yet, correct to create. SOPS age pattern confirmed from westsidekingsandqueens/prod/harbor-creds.enc.yaml
• [x] overlays/westside-ror/prod/harbor-creds.enc.yaml — does not exist yet, correct to create

Repo Placement

ISSUE: The issue body says Repo: forgejo_admin/pal-e-deployments but the actual Forgejo repo is ldraney/pal-e-deployments. The API confirms the repo owner is ldraney, not forgejo_admin. An agent following the ticket would fail to find the repo or open the PR against the wrong owner. The Constraints section and Checklist also reference forgejo_admin/pal-e-deployments.

Dependencies

• #41 (Terraform service onboarding) — prerequisite, state: open. Creates namespace + ArgoCD app. Documented in issue.
• #43 (Dockerfile + Woodpecker CI) — sibling, state: open. Updates Dockerfile to drop Thruster, expose port 3000, push Harbor images. Documented in issue.
• #40 (Epic: CI/CD pipeline) — parent epic, state: open. Documented in issue.
• #28 (Commit prod deployment manifests) — board item 1358, column: done. This is the ticket that created the existing prod overlay files. The overlap was noted in the previous review context but the current ticket body does not acknowledge that kustomization.yaml and deployment-patch.yaml already exist.

Dependencies are well-documented in the issue. The gap is that #28's output (existing prod files) is not acknowledged in the file targets.

Acceptance Criteria

8 criteria, all testable by an agent:

• [x] Directory existence — verifiable
• [x] kustomization.yaml references bases/standard — verifiable by file read
• [x] deployment-patch.yaml has initContainer with db:prepare — verifiable by file read
• [x] Both Tailscale Funnel ingresses — verifiable by file read
• [x] SOPS secret with 6 keys — verifiable by sops --decrypt or by checking encrypted structure
• [x] Harbor pull secret follows SOPS pattern — verifiable by file structure comparison
• [x] Port 3000 — verifiable by grep
• [x] kustomize build renders valid manifests — verifiable by running command

Criteria are clear and agent-verifiable. Note: AC does not mention removing the hostPath mount or the inline apt-get command from the existing deployment-patch.yaml, which are dev artifacts that must go.

Blast Radius

• The westsidekingsandqueens/prod overlay still exists but its namespace was terraform-destroyed. The ticket correctly notes this overlay should NOT be touched. The westsidekingsandqueens Tailscale Funnel ingress being added to westside-ror's overlay is the right approach.
• The existing kustomization.yaml removes imagePullSecrets and uses ruby:3.4-slim instead of Harbor. The new version will need Harbor image + imagePullSecrets. This is a significant change from the current prod state — the running pod will need to be rebuilt from a Harbor image (dependent on #43).
• The existing deployment-patch.yaml has hostPath mounts to /home/ldraney/westside-ror — this only works on nodes with Lucas's home directory. Removing this is correct for prod.

Decomposition Assessment

6 file targets in 1 repo, 8 acceptance criteria. All files are in the same overlay directory and follow established patterns. Estimated agent work: ~5 minutes (pattern-match from landscaping-assistant + westsidekingsandqueens, create/update 6 files). Borderline but feasible in a single pass given strong pattern references. No decomposition needed.

Recommendations

1. [BODY] Fix repo owner: forgejo_admin/pal-e-deployments → ldraney/pal-e-deployments in Repo section, Constraints section, and Checklist. Three occurrences total.
2. [BODY] Fix file target language: kustomization.yaml and deployment-patch.yaml already exist (created by #28). Change "create" to "replace/update" for these two files and note that the existing dev-like prod overlay (hostPath mounts, inline apt-get, ruby:3.4-slim base) must be fully replaced with proper prod patterns (Harbor image, SOPS secrets, initContainer, security context).
3. [SCOPE] Create architecture note arch-k8s for the Kubernetes component in pal-e-docs. Non-blocking but needed for full traceability.

Verdict: APPROVED

Pass-2 review of board item #1033 (Forgejo basketball-api#497). All six pass-1 refinements are landed correctly. The single-ticket decision is defensible given the audit data now cited in the body (4 real parents / $455 blast radius). Ready to move backlog → todo.

Pass-1 Refinement Verification

• [x] (1) HARD STOP banner reproduced verbatim — #497 lines 4–16 match #486 lines 4–16 word-for-word. All 6 numbered gates present, "Approved draft ≠ approved to send. One approval = one send." paragraph present, feedback refs (feedback_email_blast_nuclear_gate, feedback_no_email_without_five_approvals, feedback_one_approval_one_send) present, 2026-04-04 + 2026-04-13 incident refs present, Test recipients paragraph present. The only delta is Gate 5's parenthetical count ("recipient count (17)" in #486 vs. "recipient count" in #497) — correct, since the count is finalized during Phase A.
• [x] (2) Hard constraint against email drafting in Phase A — Present as an explicit Constraint bullet (line 111): "Phase A produces NO email drafts. Drafting begins only in Phase B after Lucas approves the recipient list." Reinforced in the Phase A AC heading (line 68: "NO EMAIL WORK IN THIS PHASE"). Satisfies pass-1 ask — it's a hard Constraint, not implicit AC.
• [x] (3) Phase A AC per-parent classification structure — Line 71 specifies full tabular deliverable: parent_id, parent_name, player_name, email, latest_order_id, amount_cents, classification (TRUE_STRANDED / PAID_VIA_RETRY / NORMAL_PENDING / WITHDRAWN / TEST_ACCOUNT), rationale. Enum is explicit and per-parent. Satisfies pass-1 ask.
• [x] (4) Phase C hard scope cap — Phase C shrunk to 3 AC with an explicit "pick one; do not build all three" on output surface (line 100), bounded to one metric class (line 99: status=pending AND session.status=expired). Reinforced by Constraint line 113: "Phase C MUST NOT expand into a generic analytics/reporting feature. Single output channel, single metric class." Satisfies pass-1 ask — the previous "at minimum" escape hatch is gone.
• [x] (5) Six approval gates as separate checkbox lines — Phase B approval block (lines 78–85) contains 8 individual checkboxes: template draft, Gate 1 (Lucas approves), Gate 2 (Marcus approves), test email sent, Gate 3 (Lucas confirms test), Gate 4 (Lucas says BLAST), Gate 5 (Ava reads back), Gate 6 (Lucas confirms BLAST #2). The six gates are bolded and numbered verbatim, matching #486 lines 54–61 exactly. No collapsing.
• [x] (6) Checklist section present, covers A/B/C — Lines 119–128, 9 checkboxes: Phase A classification note, dry-run shared with Lucas, email template PR, 6 gates completed in order, mechanical recovery complete, blast sent, ≥1 payment confirmed, Phase C observability shipped (one channel / one metric), Phase D runbook update. Covers all three phases plus Phase D. Mirrors #486's Checklist shape.

Single-Ticket Decision (pass-1 recommendation 4/5 rejected)

Defensible. The Lineage block (lines 21–27) explicitly documents the rejection: "Decomposition considered and rejected: the 2026-04-17 audit (agent a1a654212264ebceb) classified the blast radius at 4 real parents / $455 (baseline of 5 orders / $460 dilated when order 79 was identified as the Westside Admin test account). At this size, one-ticket recovery is correct."

Pass-1 recommended decomposition based on:

• Three distinct phases, three exit criteria, three risk profiles
• Concern that coupling A + B lets a dev agent "finish" A and drift into drafting emails
• Concern that Phase C is orthogonal to recovery

Pass-2 evaluates whether the now-landed controls defuse these concerns:

• A→B drift risk: mitigated by the "NO EMAIL WORK IN THIS PHASE" header on Phase A AC, the hard Constraint forbidding drafts in Phase A, and the "Phase A deliverable logged as a pal-e-docs note referenced from this ticket" gate (line 75) which forces an explicit handoff checkpoint. A dev agent cannot silently cross the boundary.
• Phase C orthogonality risk: mitigated by the scope cap ("pick one; do not build all three") and the anti-scope-creep Constraint. Phase C is explicitly marked "can ship independently" (line 98), so if it drifts, it can be spun out mid-execution without derailing the recovery.
• Blast-radius reality: 4 parents / $455 is ~24% of #486's 17 parents / $985. At this size, decomposing into three tickets would impose more coordination overhead than it removes risk. Splitting made sense for a 17-parent blast; it doesn't at 4.

Pass-2 endorses the single-ticket shape as the right call.

Scope Creep Check

No scope creep beyond the six pass-1 items. New additions in the patched body are all evidence/data surfaces that reduce the dev agent's discovery burden:

• Context section now contains the audit category table (TRUE_STRANDED, NORMAL_PENDING, PAID_VIA_RETRY, PAID_ORIGINAL, TEST_ACCOUNT counts and dollars).
• Context section now contains the 4-row true-stranded parent table with order IDs, names, emails, amounts, ages.
• Context section now flags order 95 (Artyom Litvinau) for re-audit the day of execution.
• Constraints section enumerates specific paid-original and paid-via-retry parents not to touch, plus parent 170 (Westside Admin test).

These are data handoffs from the 2026-04-17 audit, not scope additions — they prevent the dev agent from re-running the audit.

Template Completeness

• [x] Type (Task)
• [x] HARD STOP banner (verbatim per #486)
• [x] Lineage (references #486, audit agent ID, decomposition rejection rationale)
• [x] Repo (forgejo_admin/basketball-api)
• [x] User Story (matches story:WS-S22)
• [x] Context (Stripe mechanism, audit tables, re-audit flag for order 95)
• [x] Scope (three phases labeled, one-line summaries)
• [x] Acceptance Criteria (Phase A investigation, Phase B approval gates, Phase B mechanical, Phase B execution, Phase C observability, Phase D runbook)
• [x] Constraints (9 bullets including the hard no-drafting-in-Phase-A rule)
• [x] Checklist (9 items spanning A/B/C/D)
• [x] Related (links #486, #498, audit artifacts, memory notes)

Traceability

• [x] story:WS-S22 label — "clear email communications with action links so that I never miss a deadline"
• [x] story note verified (pass 1)
• [x] arch:dataflow-westside-basketball label
• [x] arch note verified (pass 1)
• [x] Forgejo issue — basketball-api#497, open, body well-formed
• [!] Forgejo issue currently has no labels applied at the platform level (API returns labels: []). Labels live on the board item, so this is cosmetic, not blocking — noting for Ava in case she wants label parity on Forgejo itself.

File Targets

Not applicable — Task type. Claims in body verified against live repo:

• [x] src/basketball_api/routes/checkout.py — first_payment_checkout def at line 306, mint at line 410 (stripe.checkout.Session.create). Claim matches.
• [x] services/email.py:202 (_brand_wrapper) — reference is consistent with feedback_two_email_systems.md. Not re-verified this pass (pass 1 did not flag this).
• [x] No CHECKOUT_SESSION_TTL_SECONDS constant reintroduced — consistent with #493 revert context.

Repo Placement

OK — forgejo_admin/basketball-api. Recovery data access + email blast both live in that repo.

Dependencies

• #486 (tournament recovery) — precedent pattern, already executed; template mirrored verbatim.
• #498 (monthly Payment Link helper) — soft dependency for Phase B mechanical recovery. Fallback (30-day TTL Sessions via #486's helper) explicitly documented. Correct framing.
• Order 95 re-audit — internal dependency on Phase A re-retrieve step. Captured as the first Phase A AC bullet.

Acceptance Criteria

Phase A (7 AC) — testable, gated on Lucas's explicit approval of recipient list. Investigation-only; no drafting. OK.

Phase B approval gates (8 AC) — each gate is a separate, bolded, numbered checkbox. Matches #486 verbatim. OK.

Phase B mechanical (4 AC) — #498-gated with documented fallback; spot-check requirement present. OK.

Phase B execution (3 AC) — only fires after all gates green AND mechanical complete. OK.

Phase C (3 AC) — one job, one output surface, one alert. Scope cap is the AC itself. OK.

Phase D (1 AC) — runbook update. OK.

Blast Radius

• 4 real parents / $455 — confirmed by the audit table in the body.
• 1 pending re-audit (order 95, Artyom Litvinau, $150) — captured as the first Phase A AC.
• Test-account exclusion (parent 170, Westside Admin) — explicit Constraint.
• Paid-original and paid-via-retry exclusion lists — named parents in Constraints, prevents noise.

Decomposition Assessment

No decomposition needed. 4-parent / $455 blast radius is below the threshold where three-ticket coordination overhead pays for itself. Controls landed in the body (hard Constraint on Phase A, scope cap on Phase C, per-phase deliverable gates) provide the same drift protection that decomposition would have enforced, without the overhead.

Recommendation

APPROVED. Move board item #1033 from backlog to todo.

No further refinements required. Optional nit (not blocking):

• [LABEL] Consider adding type:task, story:WS-S22, arch:dataflow-westside-basketball labels on Forgejo issue #497 for parity with the board item. Cosmetic.

Related

• Pass 1 review: review-1033-2026-04-17
• Precedent ticket: basketball-api#486 (tournament recovery)
• Skill: skill-review-ticket
• Memory: feedback_email_blast_nuclear_gate, feedback_one_approval_one_send, feedback_no_email_without_five_approvals, feedback_retrieve_before_theorize

Verdict: APPROVED

Pass-2 review of basketball-api#498. All three pass-1 NEEDS_REFINEMENT deltas have landed in the issue body as first-class acceptance criteria, constraints, test expectations, and checklist items — not as narrative asides. No scope creep beyond the required deltas plus the mint-site citation and the #497 related-link add. The email-URL architectural question is now locked in as a constraint, not left open.

Template Completeness

• [x] Type — Feature
• [x] Lineage — carries pass-1 provenance + pointer to `review-1032-2026-04-17`
• [x] Repo — `forgejo_admin/basketball-api`
• [x] User Story — parent-framed
• [x] Context — now carries the three explicit monthly-vs-tournament deltas
• [x] File Targets — "dev agent's decision" with verified mint-site citation (`routes/checkout.py:305`)
• [x] Acceptance Criteria — 8 bullets, all testable
• [x] Test Expectations — real-Stripe integration test mandated, mock + deactivation + `setup_future_usage` coverage all named
• [x] Constraints — includes new "do not embed Stripe URLs in email" constraint
• [x] Checklist — 7 items, four directly enforcing pass-1 deltas
• [x] Related — `#494`, `#486`, `#493`, `#497`, memory `feedback_retrieve_before_theorize.md`

Pass-1 Delta Coverage

Delta 1 — `setup_future_usage: "off_session"` preservation

• [x] Context — item 2: "`setup_future_usage: "off_session"` is required on the monthly flow for card-save on recurring billing. The existing Session call sets this via `payment_intent_data` (checkout.py:423). #494's tournament helper does NOT set this, so a straight copy will silently break recurring charges."
• [x] Acceptance Criteria — bullet: "`setup_future_usage: "off_session"` carried over from the existing Session call. The regression test `tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe` must continue to pass (and ideally an analogous assertion added for the Payment Link path)."
• [x] Test Expectations — bullet: "`setup_future_usage` presence asserted on the Payment Link path (extend or add alongside `tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe`)."
• [x] Checklist — bullet: "`setup_future_usage` carry-over explicitly asserted."
• [x] Live-code anchor verified — `payment_intent_data={"setup_future_usage": "off_session"}` sits at `src/basketball_api/routes/checkout.py:423` on origin/main. Regression test `tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe` exists at line 477.

Delta 2 — Webhook deactivation gate widening (additive, not replacement)

• [x] Acceptance Criteria — bullet: "Webhook deactivation gate widened: `webhooks.py:246-267` currently deactivates Payment Links only when `product.category == ProductCategory.tournament`. Widen to include `ProductCategory.monthly` WITHOUT removing the tournament branch — jersey/tryout/generic must continue to skip deactivation."
• [x] Test Expectations — bullet: "Deactivation on payment asserted for monthly category (and existing tournament assertion still green)."
• [x] Checklist — bullet: "Webhook deactivation gate widened to include monthly, tournament branch still intact."
• [x] Live-code anchor verified — the gate at `src/basketball_api/routes/webhooks.py:246-267` on origin/main matches exactly: `if (payment_link_id and product is not None and product.category == ProductCategory.tournament)`. Widening to include monthly without removing tournament is the correct transform.

Delta 3 — Email-URL architectural choice, stated as a constraint

• [x] Context — item 3 is unambiguous: "Keep the redirect — the `first_payment_checkout` endpoint should return the persisted Payment Link URL from `Order.stripe_checkout_url`, preserving the contract-status re-check that happens on click. Do NOT embed `https://buy.stripe.com/...` directly in the email template."
• [x] Acceptance Criteria — bullet: "Email continues to embed `{base_url}/checkout/first-payment?token=...` — no change to the email template. The redirect endpoint returns the persisted Payment Link URL from `Order.stripe_checkout_url`."
• [x] Constraints — bullet: "Do not embed Stripe URLs directly in the email template — keep the `/checkout/first-payment?token=...` redirect so contract-status re-check on click is preserved."
• [x] Checklist — bullet: "Email template unchanged (redirect preserved)."
• [x] Live-code anchor verified — `src/basketball_api/services/email.py` still builds `checkout_url = f"{settings.base_url}/checkout/first-payment?token={player.contract_token}"` (around the lines the pass-1 review cited). The body's instruction matches the live shape.
• [x] Decision is phrased as a directive ("Keep the redirect…Do NOT embed"), not as a question or an option list. Dev agent has no ambiguity.

Traceability

• [x] story:WS-S11 label — verified on project-westside-basketball Admin section (pass 1 verified)
• [x] arch:dataflow-westside-basketball label — arch-dataflow-westside-basketball note exists (pass 1 verified)
• [x] Forgejo issue — `forgejo_admin/basketball-api#498`, open, title unchanged

File Targets

• [x] `src/basketball_api/routes/checkout.py:305` — `first_payment_checkout` endpoint (sole monthly-fee mint path) — verified present on origin/main
• [x] `src/basketball_api/routes/checkout.py:423` — `payment_intent_data={"setup_future_usage": "off_session"}` — verified present
• [x] `src/basketball_api/routes/webhooks.py:246-267` — tournament-only deactivation gate — verified present, ready to widen
• [x] `src/basketball_api/services/email.py` (~line 1041) — `{base_url}/checkout/first-payment?token=...` URL construction — verified present
• [x] `tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe` — regression test exists (line 477)

Repo Placement

OK — single repo, `forgejo_admin/basketball-api`. No cross-repo work. Frontend redirect stays as-is (parents click email URL, no SPA involvement). Unchanged from pass 1.

Dependencies

• Not blocked by #497 (monthly recovery). #497 is the downstream consumer of this helper, not a predecessor. Confirmed in pass 1.
• Depends on #494 having landed (it has — commit `4a4b88a` on origin/main). `services/tournament_checkout.py` provides the dogfooded pattern to copy with the three monthly-specific deltas above.
• No blockers in `in_progress`. This ticket is the enabler for `#497`.

Acceptance Criteria

8 bullets, all testable. Four are net-new work (Payment Link URL creation with metadata, webhook gate widening, `setup_future_usage` carry-over, email redirect plumbing). Four are pass-through assertions (amount_cents flow-through, `#497` compatibility, non-monthly flows untouched, email template unchanged). Agent-verifiable. Fits the 5-minute rule — no decomposition needed.

Blast Radius

• Webhook handler gate (webhooks.py:250) — additive widening only. Tournament branch untouched. Jersey/tryout/generic untouched. No risk.
• Email template — explicitly unchanged by constraint. No risk.
• Stale-pending reuse path (checkout.py:358-377) — will simplify with Payment Links (no expiry, no 30-min reuse gymnastics). Acceptable cleanup within scope.
• Non-monthly flows (jersey.py, admin.py, register.py, generic checkout paths) — unchanged by constraint. 24h-safe for their latency profiles.

Scope Creep Check

Diff vs pass-1 body, counted narratively:

• Lineage — one sentence added pointing at `review-1032-2026-04-17`. Audit trail. Acceptable housekeeping.
• Context — three numbered sub-items added (per-parent amount already present conceptually; `setup_future_usage`; email redirect). All three trace to pass-1 recommendations.
• File Targets — single mint-site citation added (`routes/checkout.py:305` `first_payment_checkout`). Explicitly within pass-1 allowed deltas.
• Acceptance Criteria — +3 bullets (webhook gate, `setup_future_usage`, email redirect). All three map 1:1 to required deltas.
• Test Expectations — +1 bullet (`setup_future_usage` on Payment Link path). Maps to delta 1.
• Constraints — +1 bullet (do not embed Stripe URLs in email). Maps to delta 3.
• Checklist — +4 bullets (`setup_future_usage`, webhook gate, email template, helper availability for `#497`). All four map to the three deltas or the `#497` consumer note.
• Related — `#497` link added (explicitly allowed).

No new repos, no new file targets beyond the cited mint site, no expanded blast radius, no new user stories, no real-Stripe scope expansion. Body grew only within the pass-1 allowed deltas.

Decomposition Assessment

File count: 3 (checkout.py, email.py or first_payment_checkout redirect body, webhooks.py gate). AC count: 8 — on the edge of the >5 threshold, but four of those eight are pass-through assertions (email template unchanged, non-monthly flows untouched, recovery-ticket compatibility, metadata flow-through) rather than net-new work. Estimated agent work: 30-45 min. No decomposition needed — fits a single agent pass.

Recommendation

APPROVED. Board item #1032 is ready to advance from `backlog` to `todo` via `update_board_item`. No further body edits required. No `[BODY]`, `[LABEL]`, `[SCOPE]`, or `[DECOMPOSE]` recommendations.

Related

• Pass-1 review: `review-1032-2026-04-17` (verdict NEEDS_REFINEMENT)
• Forgejo issue: `forgejo_admin/basketball-api#498`
• Board item: `board-westside-basketball#1032`
• Skill: `skill-review-ticket`

Verdict: NEEDS_REFINEMENT

Directionally this ticket is an accurate analog of #494 and scope is standalone (not dependent on #497 recovery — #497 explicitly marks itself as the blocked-on-this-one side). But two substantive gaps in the spec will put the dev agent at risk of missing behavior that shipped in #494 and of mis-scoping the email template change. Both are fixable in the issue body.

Template Completeness

• [x] Type — Feature
• [x] Lineage — accurate standalone framing, correct provenance off #494 and #490
• [x] Repo — forgejo_admin/basketball-api
• [x] User Story — parent-framed
• [x] Context — identifies the real per-parent amount_cents differentiator vs tournament
• [x] File Targets — "dev agent's decision" (acceptable per feedback_tickets_not_solution_specs)
• [x] Acceptance Criteria
• [x] Test Expectations — real-Stripe integration test mandated, #490 lesson cited
• [x] Constraints
• [x] Checklist
• [x] Related links — #494, #486, #493, feedback memory

Traceability

• [x] story:WS-S11 label — exists on project-westside-basketball Admin section ("As an admin, I want to create Stripe checkout sessions for jerseys/fees so that payments are automated"). Fit is reasonable though the issue's user story is parent-framed. Acceptable: WS-S11 is the closest existing story and covers the payment-mint machinery regardless of frame.
• [x] arch:dataflow-westside-basketball label — arch-dataflow-westside-basketball note exists in pal-e-docs
• [x] Forgejo issue — forgejo_admin/basketball-api#498, open

File Targets

"Dev agent's decision" is acceptable per feedback_tickets_not_solution_specs. Verified the monthly-fee mint paths are grep-able and unambiguous:

• [x] src/basketball_api/routes/checkout.py:305 — first_payment_checkout (GET /checkout/first-payment?token=...) — the sole monthly-fee mint path. Reads player.monthly_fee, computes prorated amount_cents, creates Stripe Session with payment_intent_data.setup_future_usage = "off_session".
• [x] src/basketball_api/services/email.py:1021 — send_first_payment_email embeds {base_url}/checkout/first-payment?token=... as the email-facing URL. The email currently points at our redirect, not at Stripe directly. Migrating to Payment Links will change this — the email should embed the durable https://buy.stripe.com/... Payment Link URL persisted on Order.stripe_checkout_url.
• [x] Reference pattern at src/basketball_api/services/tournament_checkout.py on origin/main (post-#494).

Note: the second bullet is the scope ambiguity — see Recommendations [BODY] item 2 below.

Repo Placement

OK — single repo, basketball-api. Frontend redirect stays as-is (parents click email URL, no SPA involvement).

Dependencies

• Not blocked by #497 (monthly recovery). Per #497's own Constraints block: "Blocked on the sibling architecture migration ticket IF we decide monthly-recovery should mint Payment Links — OR we accept 24h TTL for the recovery window." #497 is the consumer, #498 is the enabler. Confirmed standalone.
• Depends on #494 being merged (it is — commit 4a4b88a on origin/main). Helper file services/tournament_checkout.py provides the dogfooded structural pattern (Price → PaymentLink → deactivate-on-webhook).

Acceptance Criteria

Five ACs, all testable. But one substantive omission and one potential confusion:

• [x] "URLs remain clickable indefinitely" — testable
• [x] "order_id metadata present" — testable against mocked webhook
• [x] "Payment Link deactivated programmatically" — testable. However, the dev agent must widen the webhook deactivation gate. Today webhooks.py:246-267 (origin/main) deactivates only when product.category == ProductCategory.tournament. Monthly orders will not trigger deactivation under the existing gate. The issue body says "same pattern as #494" but doesn't explicitly call out that the gate must be widened — dev agent may miss it and ship a working-but-never-deactivating implementation.
• [x] "Per-parent amount_cents flows through" — testable, explicitly preserves scholarships/prorations
• [ ] Missing AC: setup_future_usage: "off_session" must still fire so the card is saved for recurring monthly billing. The current Session call at checkout.py:423 passes payment_intent_data={"setup_future_usage": "off_session"}. Stripe Payment Links accept payment_intent_data.setup_future_usage, but #494's implementation does not set it (tournament doesn't need card save). A dev agent copying #494 verbatim will drop this behavior silently, breaking all downstream recurring charges. Test coverage at tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe will fail loudly, which is good, but the AC should name this explicitly so it's not treated as a regression to fix but as a required carry-over.

Test Expectations

• [x] Real-Stripe integration test mandated — matches #494's pattern (tests/test_payment_link_real_stripe.py on origin/main)
• [x] Mock-based webhook match coverage — present
• [x] Deactivation-on-payment asserted — present
• [x] #490 lesson referenced correctly: "Mock-only coverage missed the 24h cap that broke #490" — accurate. PR #490 had comprehensive mocked tests (8-site parametrized test) but did not catch the 24h Stripe-side cap because mocks accepted any expires_at.

Blast Radius

• Webhook handler category gate (webhooks.py:250): As noted above, the existing deactivation hook is tournament-gated. Widening to include monthly is correct; the dev agent should NOT widen it for jersey/tryout/generic (those remain Sessions and self-expire).
• Email template (services/email.py:1041-1043): Monthly-fee email currently embeds our redirect endpoint URL. Dev agent must decide whether to (a) keep the redirect (and make first_payment_checkout return a persisted Payment Link URL) or (b) embed the Stripe Payment Link URL directly. Option (a) is closer to the existing shape and preserves our ability to re-check contract status on click; option (b) is simpler and truer to the "no expiry" promise. Issue body is silent on this — see [BODY] recommendation.
• Stale-pending reuse path (checkout.py:358-377): Current code "reuses fresh pending Session" within a 30-min stale threshold. With Payment Links there is no expiry and no reuse gymnastics — one Payment Link per Order, forever (until webhook-deactivated). The dev agent will need to simplify this block.
• Non-monthly flows: Jersey (jersey.py:291), admin tryout regen (admin.py:2005), register.py tryout paths (1378, 1423), generic checkout (checkout.py:247, 553) — all 24h-safe for their latency profile. Constraint in issue body is correct.

Decomposition Assessment

File count: 2-3 (checkout.py, email.py, webhooks.py gate widening). AC count: 5 (acceptable). Estimated agent work: 30-45 min (helper refactor + call-site substitution + webhook gate + email URL decision + real-Stripe test). No decomposition needed — fits a single agent pass.

Recommendation

Three issue-body refinements before advancing to todo. All are [BODY] — dev agent reads the issue body, not the review note, so these must land in the spec itself.

• [BODY] Add AC for setup_future_usage preservation: add an acceptance-criteria bullet: "Card is saved for future recurring billing — existing payment_intent_data.setup_future_usage = 'off_session' behavior (checkout.py:423) is preserved on the Payment Link. Regression test at tests/test_first_payment.py::test_setup_future_usage_passed_to_stripe must continue to pass."
• [BODY] Name the webhook gate widening explicitly: in the Acceptance Criteria or Constraints, add: "Webhook deactivation gate in routes/webhooks.py must be widened from ProductCategory.tournament-only to include ProductCategory.monthly. Do not remove the gate entirely — jersey/tryout/generic must remain untouched."
• [BODY] Answer the email-URL architectural question: add a Context or Constraints sentence clarifying whether the monthly-fee email should (a) continue to embed {base_url}/checkout/first-payment?token=... with first_payment_checkout returning the persisted Payment Link URL, or (b) embed the https://buy.stripe.com/... URL directly. Recommended: (a) — preserves contract-status re-check on click and matches the minimum-diff philosophy. Dev agent should not have to guess.

No [LABEL], [SCOPE], or [DECOMPOSE] recommendations. Traceability triangle is intact and ticket size fits a single pass.

Verdict: NEEDS_REFINEMENT

Scope is directionally sound and the ticket accurately mirrors #486's three-phase structure. However, the nuclear gate collapses 6 steps into a single checkbox — #486's "HARD STOP" banner and per-gate checkboxes set the floor, and #497 falls short of that floor. Phase C observability also bloats the ticket beyond the recovery scope.

Template Completeness

• [x] Type (Task)
• [x] Lineage (references #486, 2026-04-17 date, stranded $460 evidence)
• [x] Repo (forgejo_admin/basketball-api)
• [x] User Story (matches story:WS-S22)
• [x] Context (Stripe mechanism, stranded table with 5 orders, historical canceled investigation rationale)
• [x] Scope (three phases labeled)
• [x] Acceptance Criteria
• [x] Constraints
• [x] Related (links #486, #494, #493, memory note)
• [ ] HARD STOP banner — MISSING. #486 opens with a ⚠️ HARD STOP — NO EMAILS WITHOUT APPROVAL ⚠️ section that enumerates the 6 gates and states "Approved draft ≠ approved to send. One approval = one send." This is the single most important template convention for blast tickets and #497 has no equivalent.
• [ ] Checklist section — MISSING. #486 has a Checklist enumerating dry-run, template PR, gates, blast, payment confirmation, runbook. #497 folds everything into AC.

Traceability

• [x] story:WS-S22 label — "clear email communications with action links so that I never miss a deadline"
• [x] story note verified — found in project-westside-basketball user-stories section (stories-parent)
• [x] arch:dataflow-westside-basketball label
• [x] arch note verified — arch-dataflow-westside-basketball exists (search confirmed)
• [x] Forgejo issue — #497, open, body well-formed

File Targets

Not applicable — Task type. Scope references the monthly-fee mint path generically. Live repo confirms:

• src/basketball_api/routes/checkout.py — prorated first-month path at _calculate_prorated_cents (line 293), uses stripe.checkout.Session.create with no expires_at override. Confirms 24h cap claim.
• src/basketball_api/routes/admin.py — admin regen path (line 2005) — same pattern, no TTL override.
• No monthly_checkout.py helper exists — monthly flow has no dedicated service module (unlike tournament, which has services/tournament_checkout.py). #498 will need to create one.
• No CHECKOUT_SESSION_TTL_SECONDS constant present — good, consistent with #493 revert.

Repo Placement

OK — forgejo_admin/basketball-api. Recovery data access + email blast both live in that repo. No cross-repo spillover expected.

Dependencies

• #486 (tournament recovery) — precedent pattern, already executed. Reuse nuclear-gate structure.
• #498 (monthly Payment Links migration) — soft dependency. Ticket states correctly: "Blocked on the sibling architecture migration ticket IF we decide monthly-recovery should mint Payment Links (non-expiring) — OR we accept 24h TTL." This matches Ava's framing: can use helper if it ships first, but can fall back to Sessions with tight turnaround.
• #494 (tournament Payment Links helper) — not directly consumed, but is the architectural precedent #498 copies from. Reference is accurate.
• #493 (revert of 30-day TTL approach) — context anchor. Tells dev agent not to reintroduce the TTL constant. Accurate.
• No blocker currently in in_progress column that would stall Phase A.

Acceptance Criteria

Phase A (3 AC) — testable. Dry-run recipient list to Lucas before drafting is explicit. Roster/subscription cross-reference explicit. OK.

Phase B — weakened gate. A single bullet — "all 6 nuclear-gate steps logged" — replaces #486's six individual gate checkboxes plus the HARD STOP banner. This is the biggest refinement need. Per feedback_email_blast_nuclear_gate.md, the gate must be reproduced verbatim, not referenced. A single checkbox invites a dev agent to mark it complete after a perfunctory approval chain.

Phase C — 1 AC ("mechanism exists for Lucas to request a paid/unpaid snapshot on demand, at minimum"). This is vague, unbounded, and not scoped like a recovery ticket should be. "At minimum" is an escape hatch that can swallow arbitrary observability work.

Blast Radius

• Related blast risk: Same class of customer-facing incident as #486. If Phase B emails go out under the weakened gate, a 2026-04-04 or 2026-04-13 style incident could repeat. This is the exact risk the nuclear-gate feedback was created to prevent.
• Test parent exclusion: Ticket notes "Exclude test parent rows (admin / test seed data) — same principle as order 93 exclusion in #486." Acknowledged but not verified — the dev agent needs to explicitly grep the 5 stranded parent rows for admin/test accounts before Phase A dry-run goes to Lucas.
• Per-parent variable amount: players.monthly_fee or orders.amount_cents used as source. Ticket constraint correctly flags: each Payment Link must charge the exact amount_cents on that specific Order. Accurate — unlike tournament's uniform per-product rate.
• Silent-abandon parents in canceled state: Ticket says parents 166 and 170 may be true silent abandons (canceleds + still-pending without paid record). Phase A must resolve these explicitly; currently a single AC ("exhaustive list") covers the investigation but does not require per-parent classification (paid-via-retry / normal-pending / true-stranded). Adding a classification requirement would sharpen Phase A deliverable.

Decomposition Assessment

NEEDS DECOMPOSITION. Three distinct phases, three distinct exit criteria, three distinct risk profiles:

• Phase A (investigation + dry-run list) — 1 agent, ~15-30 min. Pure data / SQL + Stripe retrieve work. No customer risk.
• Phase B (recovery blast) — cannot start until Phase A is Lucas-approved. Must be a separate ticket with its own HARD STOP banner, its own 7-step gate reproduced verbatim, its own single-responsibility scope. Coupling A + B in one ticket lets a dev agent "finish" A and drift into drafting emails.
• Phase C (observability) — orthogonal to recovery. Should be a standalone Feature ticket that survives independent of whether the blast happens. Currently bloats the ticket.

Recommended split: keep #497 as Phase A only. New ticket for Phase B (gated by Phase A approval). New ticket for Phase C (Feature, not Task).

Recommendation

• [BODY] Add a ⚠️ HARD STOP — NO EMAILS WITHOUT APPROVAL ⚠️ banner at the top of the issue body, identical in structure to #486's. Enumerate the 6 gates verbatim. Include "Approved draft ≠ approved to send. One approval = one send." State test recipients are draneylucas@gmail.com or @example.com only.
• [BODY] Replace the single Phase B checkbox "all 6 nuclear-gate steps logged" with the 6 individual checkboxes (Lucas approves draft / Marcus approves draft / test email sent / Lucas confirms test / Lucas says BLAST / Ava reads back / Lucas says BLAST #2). Match #486's Phase A block verbatim.
• [BODY] Add explicit Constraint: "No email drafting, MJML work, or blast endpoint invocation may occur during Phase A. Phase A output = recipient list + classification only."
• [BODY] Strengthen Phase A AC: require per-parent classification (paid-via-retry / normal-pending / true-stranded / test-account-excluded) rather than just "exhaustive list." This is the deliverable.
• [DECOMPOSE] Split the ticket: keep #497 as Phase A (investigation + dry-run recipient list). Open a new Forgejo issue for Phase B (recovery blast, blocked on #497 Phase A completion + Lucas approval). Open a new Forgejo issue for Phase C (paid/unpaid observability, standalone Feature, decoupled from recovery). Route to skill-decompose-ticket.
• [BODY] Replace the vague Phase C AC ("mechanism exists... at minimum") with a concrete scope once lifted into its own ticket — e.g., a single SQL view + admin endpoint, or a weekly cron report to westsidebasktball@gmail.com.
• [BODY] Add a Checklist section mirroring #486's (dry-run shared, gates completed in order, blast sent, payment confirmed, docs updated).

Verdict: NEEDS_REFINEMENT

Board item: #1024 (board-westside-basketball, column=backlog, position=2)
Forgejo issue: forgejo_admin/basketball-api#487 — open
Base commit audited: basketball-api working tree at ~/basketball-api (origin/main)
Issue type: Feature (template-issue-feature)
Policy lens: Lucas's 2026-04-17 feedback "tickets are not solution specs" — ticket scope should be User Story + Context + AC only; flag over-specification.

Template Completeness

• [x] Type — "Feature"
• [x] Lineage — standalone, 2026-04-17 Utah Invitational discovery narrative
• [x] Repo — forgejo_admin/basketball-api
• [x] User Story — Ava as the consumer, alert rule as the so-that
• [x] Context — references branch 290-payment-pipeline-observability, explains why WebhookErrorRate/WebhookStale don't cover this failure mode
• [x] File Targets — present but inaccurate (see below)
• [x] Acceptance Criteria — 6 items, each verifiable
• [x] Test Expectations — 2 unit tests with run command
• [x] Constraints — present but over-prescriptive (see Recommendation)
• [x] Checklist — PR opened / tests pass / gauge visible / clean refresh logged
• [x] Related — blocks Ticket C2 (pal-e-platform#295, verified open)

All template sections present.

Traceability

• [ ] story:observability label — present on board item, but OFF-TAXONOMY. project-westside-basketball user-stories uses WS-S{N} (WS-S1 through WS-S33). Siblings #488 and #486 were already reconciled to story:WS-S11 and story:WS-S22 respectively during this morning's refinement pass. #487 was missed. Closest existing story: WS-S11 ("As an admin, I want to create Stripe checkout sessions for jerseys/fees so that payments are automated") — reasonable home since the metric defends the same payment-session surface.
• [ ] story note — not applicable until label is reconciled. Once retagged to WS-S11, the existing entry in project-westside-basketball user-stories covers it.
• [ ] arch:payment-pipeline label — present on board item, but NO BACKING NOTE. search_notes(query="arch-payment-pipeline") returned zero results. Sibling #488 was retagged to arch:dataflow-westside-basketball (which DOES exist as a linked note on the project page). Same reconciliation should apply to #487.
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/forgejo_admin/basketball-api/issues/487, open, contains full spec.

Traceability drift mirrors what review-1023-2026-04-17 flagged for #488. The payment-pipeline story cluster (#486/#487/#488/#489) is still only half-reconciled: #487 and #489 retain off-taxonomy story + arch labels.

File Targets

Audited against ~/basketball-api HEAD. Findings:

• [ ] src/basketball_api/metrics.py — ISSUE: this file does not exist. The ticket hedges with "or wherever Prometheus metrics are currently registered — confirm pattern by reading existing basketball_api_up, webhook_errors_total, etc." but then assumes a metrics.py module as the landing spot. Actual live pattern:
  • src/basketball_api/routes/health.py:12 — _API_UP = Gauge("basketball_api_up", ...), served at /metrics (line 38)
  • src/basketball_api/routes/webhooks.py:29-44 — WEBHOOK_RECEIVED (Counter), WEBHOOK_PROCESSED (Counter), WEBHOOK_ERRORS (Counter "webhook_errors_total"), WEBHOOK_LAST_RECEIVED (Gauge)
• [ ] "APScheduler job running every 5 minutes" — ISSUE: APScheduler is not a current dependency. Grep across ~/basketball-api for APScheduler|apscheduler|BackgroundScheduler|AsyncIOScheduler returned zero matches. Adding it introduces a new runtime dependency that isn't justified in Context. The ticket already lists the correct fallback (FastAPI startup event + asyncio task) which matches the existing src/basketball_api/main.py:38 lifespan pattern. The preference ordering is backwards.
• [x] Model field Order.stripe_checkout_session_id — verified, referenced in src/basketball_api/models.py and 5 other files. Query pattern (select pending orders with non-null session id) is viable against the real schema.
• [x] Order.status = 'pending' — verified as a live status value in the codebase.

This is partly a feedback_verify_repo_layout_before_ticketing.md violation: the file path and the runtime library were written from memory/aspiration, not from grep against the current repo.

Repo Placement

OK. The metric emission lives in basketball-api; the alert consuming it lives in pal-e-platform#295. Correctly split into two tickets.

Dependencies

• Blocks pal-e-platform#295 — verified open. pal-e-platform#295 explicitly expects basketball_api_pending_orders_with_expired_session gauge with a category label (tournament/monthly) and proposes both TournamentOrdersWithExpiredSessions and MonthlyOrdersWithExpiredSessions alert rules. #487's AC "Gauge includes at minimum a category label (tournament, monthly, jersey)" matches that contract. Gauge metric name + label schema is a cross-repo API contract — if Dev agent changes either during implementation, pal-e-platform#295 breaks silently. Worth adding to AC: "metric name and label keys MUST match pal-e-platform#295 File Targets verbatim."
• Sibling #488 (board item #1023, currently in needs_approval) — sets 30-day TTL on Stripe sessions. Once #488 deploys, new sessions won't expire for 30 days, so the gauge value from #487 will approach zero for new orders. The metric still has value (surfaces legacy sessions + future edge cases), but the "local run surfaces 18+6=24" AC in #487 is only true before #488 deploys. Doesn't block ordering, but worth noting in Context.
• Sibling #486 (regen blast, item #1022) — independent. #486 rewrites Utah orders; #487 observes the class.
• Sibling #489 (pattern spike, item #1025) — independent. #489 may eventually change the mint pattern; if it does, #487's gauge contract holds regardless.

Acceptance Criteria

• AC-1 "gauge exposed at /metrics" — verifiable by curl of the pod's /metrics.
• AC-2 "category label (tournament, monthly, jersey)" — verifiable. Matches pal-e-platform#295's expectations.
• AC-3 "refreshes at least every 5 minutes" — verifiable by timestamp observation or test harness.
• AC-4 "Stripe API failures log a warning, do not crash, leave gauge at its last value" — testable via mocked Stripe client throwing.
• AC-5 "Local run: current production state surfaces 18 + 6 = 24" — depends on #488 not yet being deployed. Reasonable snapshot AC but time-sensitive.
• AC-6 "Integration test with mocked Stripe client" — testable. Test Expectations section covers this with unit-test granularity (2 pending / 1 expired → gauge=1).

Suggested addition: Metric name and label keys MUST match pal-e-platform#295 contract (basketball_api_pending_orders_with_expired_session, label category). Prevents silent cross-repo drift.

Blast Radius

• Stripe API load: "18+ API calls every 5 min" stated as acceptable. For context, Stripe default rate limit is 100 read ops/sec — this is 0.06/sec averaged, negligible. OK.
• Internal inconsistency: File Targets suggests "consult a cached session table" as an optimization; Constraints says "Do NOT add a new DB table unless truly necessary. Prefer in-memory refresh." These contradict. Dev agent should treat "no new table" as the binding constraint and drop the cached-table branch from the prompt.
• Gauge vs Counter: Constraint is correct (Gauge — count decreases as parents pay). No concern.
• Kaniko/CI: new dependency (if agent picks APScheduler) would land in pyproject.toml, triggering a fresh wheel build. Avoidable by sticking with asyncio/lifespan.
• Downstream: Grafana dashboards in pal-e-platform (basketball-api golden-signals) will auto-pick up the new metric via Prometheus scrape. No change needed until #295 adds the panel.

Decomposition Assessment

File surface: 1-2 modules (new metric registration + refresh task, wired into existing lifespan) + 1 new test file. 6 AC, all verifiable in a single pass. Estimated agent work: ~4-5 minutes. Fits within the 5-minute rule. No decomposition needed — single Dev agent pass.

Scope / Solution-Spec Assessment (Lucas 2026-04-17 policy)

The ticket over-specifies implementation in three places:

1. File Targets ⇒ numbered 4-step query algorithm. "Select all Order rows where... / For each, call stripe.checkout.Session.retrieve OR consult a cached session table / Count those where session.status == 'expired' / Set gauge value; label by product.category if cheap." This is a solution spec, not a file target. AC already expresses the outcome; the algorithm is a Dev agent decision.
2. Constraints ⇒ library prescriptions. "Prefer Gauge over Counter" (correct but derivable from AC wording — "Gauge refreshes"), "Do NOT add a new DB table unless truly necessary" (protects an invariant, OK), "Match existing metrics style in basketball-api (module path, naming prefix)" (ambiguous — Dev agent has to grep anyway). The Gauge-vs-Counter and module-style items are over-specification.
3. File Targets ⇒ "Preferred: APScheduler job." Recommends a library that isn't in the codebase. This is the most load-bearing over-specification because it nudges Dev agent toward a dependency change that isn't justified and obscures the already-correct fallback (asyncio in lifespan).

Per Lucas's feedback, ticket body should shrink to: User Story + Context + AC + "files the agent should NOT touch." File Targets for this class of ticket (new observability signal) is optional — a pointer to the existing metrics patterns is enough. The algorithm, library choice, and style rules should come out.

Recommendation

Each recommendation is tagged for skill-refine-ticket:

• [BODY] Remove the 4-step numbered query algorithm from "File Targets" — the AC already specifies the outcome. Replace with a one-line pointer: "Existing metrics live in routes/health.py and routes/webhooks.py (module-local, not centralized). Follow that pattern."
• [BODY] Remove the "Preferred: APScheduler" recommendation. APScheduler is not a current dependency. Replace with: "Refresh task runs in the existing FastAPI lifespan (src/basketball_api/main.py:38). No new runtime dependencies."
• [BODY] Remove the contradictory "consult a cached session table" branch — the "no new DB table" constraint already rules it out.
• [BODY] Remove the "match existing metrics style" Constraint as redundant with the File Targets pointer.
• [BODY] Remove the "Prefer Gauge over Counter" Constraint — AC-3 ("refreshes at least every 5 minutes") already implies Gauge semantics.
• [BODY] Add AC: "Metric name MUST be basketball_api_pending_orders_with_expired_session and MUST expose a category label with values in {tournament, monthly, jersey}. This is a cross-repo contract with pal-e-platform#295 — changes here break the alert rule silently."
• [BODY] Add to Context: "Sibling #488 (30-day TTL) will reduce this gauge's value for new orders once deployed. AC-5's '18 + 6 = 24' snapshot is valid against current main; re-measure after #488 lands."
• [LABEL] Retag board item #1024: replace story:observability with story:WS-S11 and replace arch:payment-pipeline with arch:dataflow-westside-basketball. Matches the sibling reconciliation on #488/#486 from earlier today.
• [SCOPE] (project-wide, not #487-specific but surfaced here) Complete the payment-pipeline story-cluster reconciliation — #489 also retains story:payment-reliability + arch:stripe-checkout and needs the same treatment as #488/#486/#487.

Blocking refinements: the [BODY] removals (algorithm, APScheduler, cached-table branch) and the [LABEL] retag. The added cross-repo AC and Context note are hardening — strongly recommended but can land with the body rewrite. The [SCOPE] item is a follow-up, not a blocker for #487.

Note on brief: The policy note cited in the dispatch brief (feedback_tickets_not_solution_specs.md) does not exist in pal-e-docs (404 on get_note, zero hits on search_notes). Closest concept in Ava's memory is feedback_tickets_are_stories.md ("Tickets = user stories. No epic/bug/feature taxonomy.") — I treated that as the operative policy for this review. Ava may want to promote the 2026-04-17 "tickets not solution specs" feedback into a pal-e-docs feedback note for future agent dispatches to reference.

Verdict: NEEDS_REFINEMENT

Board item: #1023 (board-westside-basketball, column=backlog)
Forgejo issue: forgejo_admin/basketball-api#488 — open
Base commit audited: origin/main @ a4047d2 (fd081e0 ancestor confirmed)
Issue type: Bug (template-issue-bug)

Template Completeness

• [x] Type — "Bug"
• [x] Lineage — references #486, discovery narrative present
• [x] Repo — forgejo_admin/basketball-api
• [x] What Broke — Stripe API evidence + stranded revenue quantified
• [x] Repro Steps — both inline code path and Stripe API retrieve path
• [x] Expected Behavior — 30-day TTL, shared constant suggestion, runbook correction requirement
• [x] Environment — commit pin, namespace, affected data counts
• [x] Acceptance Criteria — 7 items, each verifiable
• [x] Related — #486 (recovery), #487 (metric), pal-e-platform#295 (alert)

All sections present.

Traceability

• [x] story:payment-reliability label — present on board item
• [ ] story note MISSING — project-westside-basketball user-stories uses WS-S{N} convention (WS-S1 through WS-S33). The label payment-reliability is a bare slug that doesn't match the project's story taxonomy. The closest existing story is WS-S11 ("As an admin, I want to create Stripe checkout sessions for jerseys/fees so that payments are automated"). Note: siblings #486 (story:payment-recovery) and #487 (story:observability) share the same pattern — the whole payment-pipeline story cluster is off-taxonomy.
• [x] arch:stripe-checkout label — present on board item
• [ ] arch note MISSING — search_notes(query="arch-stripe-checkout") returned zero results. No backing architecture note exists in pal-e-docs.
• [x] Forgejo issue — https://forgejo.tail5b443a.ts.net/forgejo_admin/basketball-api/issues/488 is open and contains the full spec.

File Targets

Audited against origin/main @ a4047d2. Grep for stripe\.checkout\.Session\.create across src/ returned 8 call sites, not 6.

• [x] src/basketball_api/services/tournament_checkout.py:78 — verified, stripe.checkout.Session.create( at line 78
• [x] src/basketball_api/routes/jersey.py:291 — verified, call is at line 291
• [ ] src/basketball_api/routes/checkout.py:246 — ISSUE: line 246 is the comment # Create Stripe Checkout Session; the actual call is at line 247. Off by one.
• [ ] src/basketball_api/routes/checkout.py:398 — ISSUE: line 398 is order = Order(...); the actual call is at line 410. Off by 12 lines.
• [ ] src/basketball_api/routes/register.py:1373 — ISSUE: line 1373 is amount_cents = 3000 if reg_type == "tryout" else 4000; the actual call is at line 1378. Off by 5 lines.
• [ ] src/basketball_api/routes/register.py:1418 — ISSUE: line 1418 is amount_cents = 3000 if reg_type == "tryout" else 4000; the actual call is at line 1423. Off by 5 lines.
• [ ] MISSING CALL SITE: src/basketball_api/routes/checkout.py:553 — confirmed stripe.checkout.Session.create( call. Appears to be a helper path that builds the shared order_id/player_id/product_id metadata and then mints a session. Not referenced in the ticket.
• [ ] MISSING CALL SITE: src/basketball_api/routes/admin.py:2005 — confirmed stripe.checkout.Session.create( call inside an admin "regenerate session" handler (preceded by # Create a fresh Stripe Checkout Session). Not referenced in the ticket.

This is a feedback_verify_repo_layout_before_ticketing.md violation. The ticket was authored against memory or a stale snapshot. The "all 6" count is wrong — there are 8 sites — and 4 of the listed line numbers are stale. This matters because:

1. The ticket title says "all 6," the first acceptance criterion says "All 6 call sites," and the regression test AC says "parametrizes across all 6 routes/helpers." If a Dev agent trusts the count, admin.py:2005 and checkout.py:553 will be left unfixed and the test will pass while still shipping two 24-hour-TTL sessions.
2. Bad line numbers slow Dev agents down but do not break correctness (they will locate the call sites by pattern). Bad counts do break correctness.

Repo Placement

OK. All 8 call sites live in forgejo_admin/basketball-api. No cross-repo scope.

Dependencies

• Sibling #486 (board item #1022) — recovery blast for the 18 stranded Utah Invitational orders. #486's body explicitly says the regen script re-mints sessions via the blessed helper; if #488 lands first, those regenerated sessions inherit the new 30-day TTL. If #486 ships first, parents get regenerated links that still expire in 24h and the whole recovery blast wastes one approval cycle. #488 is correctly ordered before #486. Dev agent must not start #486's regen step until #488 is merged and deployed.
• Sibling #487 (board item #1024) — expired-session metric, observability follow-up. Independent; can run in parallel.
• Sibling #489 (board item #1025) — spike comparing Payment Links vs lazy-mint vs 30d TTL. #488 is the interim fix; #489 picks the long-term pattern. Don't couple them.
• Commit fd081e0 (#480) — "require amount match when reusing fresh pending Stripe session" touched Stripe session reuse logic. Confirmed this commit is ancestor of current HEAD; no rebase needed.

Acceptance Criteria

Each AC is verifiable by the Dev/QA agent. However:

• AC-1 "All 6 call sites" — must be updated to "All 8 call sites" (see File Targets).
• AC-2 "parametrizes across all 6 routes/helpers" — must be updated to 8.
• AC-5 Runbook update — adequately scoped. The runbook's sanctioned-call-sites table (lines 23-29) is also stale: it lists 5 non-tournament sites with the same outdated line numbers the ticket has, and omits routes/checkout.py:553 and routes/admin.py:2005. Dev agent should fix the table row list + line numbers in the same PR as the root-cause narrative fix.
• AC-7 "expires_at - created ≈ 2592000s" — math confirmed: 30 × 24 × 3600 = 2,592,000, which is Stripe's maximum for payment mode. Correct value.
• Consider adding: "Shared constant CHECKOUT_SESSION_TTL_SECONDS lives in exactly one module (suggest src/basketball_api/stripe_config.py or similar) and is imported at all 8 sites — no duplicated literal." This hardens the "one knob" invariant and makes the spike #489's cutover easier.

Blast Radius

• Regression test file: tests/test_checkout_session_ttl.py does not exist in main — safe to create. Existing tests/test_checkout.py is unrelated (generic checkout coverage) and won't collide.
• Non-tournament flow risk: 30-day TTL is benign for all 8 sites. Stripe sessions are only "active" until paid or expired; a longer TTL just keeps more expired links reachable, which is the desired behavior for blast-delivered URLs.
• Webhook handlers: No change. expires_at is a client-side mint parameter; webhook signatures and checkout.session.completed semantics are untouched.
• Runbook blast radius: The order_id-metadata narrative is wrong on the Utah incident (ticket correctly flags this), but order_id metadata is still a real correctness invariant for tournament flows — the "forbidden ad-hoc create" rule in the runbook's TL;DR should be preserved, only the "What broke" section needs the TTL rewrite + move the metadata hypothesis to a "Historical note" subsection. Ticket AC already says this explicitly.
• Other repos: Grep confirms no stripe.checkout.Session.create calls in westside-app, westside-contracts, or pal-e-app. basketball-api is the only mint point.

Decomposition Assessment

8 call sites in a single repo + 1 runbook + 1 new test file. All changes share one invariant ("pass expires_at"). Mechanical edit with obvious pattern. Estimated agent work: ~5 minutes for the code + test + runbook rewrite. No decomposition needed — single Dev agent pass is appropriate.

Recommendation

• [BODY] Fix the count: replace "all 6" with "all 8" in the title, the "Affected call sites (all 6)" header, AC-1 ("All 6 call sites"), and AC-2 ("parametrizes across all 6 routes/helpers").
• [BODY] Fix the file-target list to the verified lines on origin/main @ a4047d2:
  • src/basketball_api/services/tournament_checkout.py:78 (unchanged)
  • src/basketball_api/routes/jersey.py:291 (unchanged)
  • src/basketball_api/routes/checkout.py:247 (was 246)
  • src/basketball_api/routes/checkout.py:410 (was 398)
  • src/basketball_api/routes/checkout.py:553 (NEW — was missing)
  • src/basketball_api/routes/register.py:1378 (was 1373)
  • src/basketball_api/routes/register.py:1423 (was 1418)
  • src/basketball_api/routes/admin.py:2005 (NEW — was missing)
• [BODY] Add explicit note in AC-5 that docs/tournament-billing-runbook.md's "sanctioned call sites" table (currently lines 23-29) must also be updated to reflect the 7 non-tournament sites with correct line numbers — not just the "What broke" narrative.
• [BODY] (Optional hardening) Add AC: "A single CHECKOUT_SESSION_TTL_SECONDS = 30 * 24 * 3600 constant lives in one module and is imported at all 8 call sites; no inline duplication of the literal." Makes the spike #489's future cutover a one-line change.
• [SCOPE] Create architecture note arch-stripe-checkout covering the 8-site mint surface, TTL invariant, webhook handler routing (order_id metadata contract), and the relationship to #489's pattern evaluation. This is also missing for siblings #486 (arch:stripe-checkout) and #487 (arch:payment-pipeline) — one note likely covers all three.
• [SCOPE] Reconcile story taxonomy: either add WS-S34 (or similar) to project-westside-basketball user-stories section with a payment-reliability narrative, OR retag #488/#486/#489 with an existing WS-S* story (WS-S11 is the nearest fit). Same reconciliation applies to #487's story:observability. This is a project-wide convention drift, not a #488-specific problem, but #488 inherits it.

Blocking refinements: the two [BODY] corrections on count + line numbers. The [SCOPE] items can land in parallel (or as follow-up board items) and should not hold the Bug fix — the Utah incident is fresh and #486 depends on this patch.

Verdict: NEEDS_REFINEMENT

Scope is largely solid — the 6-gate approval chain is the spine of the ticket and is cited in three places (HARD STOP block, Phase A AC, Constraints). The 18-order stranded list and 5-order paid-exclusion list reconcile 100% against live DB state. Script and MJML wrapper references are valid. Four fixable issues prevent advance to todo.

Template Completeness

• [x] Type (Task)
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context
• [x] Scope
• [x] Acceptance Criteria (phased A/B/C, 13 gates)
• [x] Constraints
• [x] Checklist
• [x] Related
• [x] HARD STOP block with 6-gate chain — prominent, unmissable
• File Targets section N/A — Task type uses Scope instead (per template-issue)

Traceability

• [x] type:task label — matches issue Type header
• [ ] story:payment-recovery label — story NOT found in project-westside-basketball user-stories. Closest existing story is WS-S22 ("receive clear email communications with action links so I never miss a deadline") — this ticket arguably fulfills that story.
• [ ] arch:stripe-checkout label — no arch-stripe-checkout note exists in pal-e-docs (verified via search_notes). Existing arch notes are arch-domain-westside-basketball, arch-dataflow-westside-basketball, arch-deployment-westside-basketball, arch-auth-westside-basketball.
• [x] Forgejo issue forgejo_admin/basketball-api#486 — open, body well-formed

File / Script Targets

• [x] scripts/regenerate_tournament_orders.py — verified. Supports --product-ids 5,6,7 --commit exactly as ticket states (argparse at line 184, product-ids at 191-194, --commit at 196-200). Dry-run default, commit flag opt-in.
• [x] _brand_wrapper MJML helper — verified at src/basketball_api/services/email.py:202. In active use by contract emails and roster emails. Queens branded (_BRAND_RED default).
• [x] Blast endpoint via basketball-api / gmail-sdk — confirmed via tests/test_tournament_blast.py.

Stranded-18 Verification (DB query against live basketball-api)

Products 5/6/7 have exactly 23 orders. 5 paid, 18 pending — matches ticket counts. Revenue math: 5×$55 + 5×$65 + 8×$55 = $1,040 ✓.

• [x] 17U Elite (prod 5) pending = 5: orders 51 (rjmob446), 53 (gabrieliuspeciulis08), 54 (derob81), 56 (zacbod1709), 93 (Westside Admin) — all match ticket.
• [x] 17U Select (prod 6) pending = 5: orders 58 (Roni Webster), 59 (elsonolotu46), 60 (Eric Porter), 62 (Kandis & Jeff Froebe), 94 (Chaoying Fan) — all match.
• [x] 16U Elite (prod 7) pending = 8: orders 63 (miroakbas), 64 (Mohamed Nur), 65 (ulgenersarp), 66 (yigitulgener), 67 (niyitangadaniel72 = Daniel), 68 (owencebully29), 69 (Artyom Litvinau), 70 (Vince Ifote Ifote) — all match.
• [x] Paid exclusions (5): orders 52 (Spencer Thorn), 55 (Goudiaby Family), 57 (Marcel), 61 (Heather Jordan), 71 (fatkid816) — all verified status=paid, matches ticket exclusion list exactly.
• [!] Order 93 concern — parent name is "Westside Admin", email westsidebasktball@gmail.com, player name "Test Kings Player". This appears to be an internal admin test order created Apr 15, not a real parent. Blasting a customer-facing apology to the Westside admin inbox is either intentional (QA check of the template) or a scope bug. Ticket does not acknowledge this. Recipient count of 18 drops to 17 if excluded.

Repo Placement

OK — all work lands in forgejo_admin/basketball-api. Script, MJML wrapper, blast endpoint, DB all in this repo. No cross-repo scope.

Dependencies

Sibling-related to board items #1023 (forgejo #488, 30-day expires_at infra fix) and #1024 (forgejo #487, metric emission). All three on board-westside-basketball in backlog. Ticket correctly notes #488 "ideally merges first" but #486 can proceed with 24h TTL in an emergency — this is the right tradeoff. Checklist item "Runbook updated… move into #488's scope" is slightly awkward — #488 is an infra bug, not docs. Runbook tracking should live in its own board item or explicitly deferred to #488's Epilogue.

Acceptance Criteria

Strong. 13 gates across three phases, each individually verifiable:

• Phase A (6 approval gates) — binary pass/fail, clear actors (Lucas, Marcus, Ava).
• Phase B (4 gates) — dry-run count, Lucas confirms, commit, Stripe spot-check. All verifiable via CLI + Stripe dashboard.
• Phase C (3 gates) — send, webhook flip, post-send report. Verifiable via logs + DB.
• Gate 5 (Ava reads back) is the mura-reducer — forces recipient count and name echo before blast. Good control.

Blast Radius

Recovery action is narrowly scoped — only touches 18 rows (status=pending, product_id in [5,6,7]). Script re-uses existing tournament_checkout.py helper which already carries the order_id metadata fix from #485 (closed). Parallel Stripe session creation paths exist at 6 sites (checkout.py, admin.py, jersey.py, register.py, tournament_checkout.py, regen script) — each still carries 24h TTL. Those sites are correctly scoped to #488, not this ticket. No bleed.

Email blast radius: 18 recipients. Inadvertent over-send risk mitigated by hard-coded product filter + dry-run gate. Under-send risk (e.g., Eric Porter email bounces) addressed by AC Phase C monitor step.

Decomposition Assessment

5-min rule: 13 AC, 1 repo, 1 script, 1 template. Agent-pass-wise Phase B is <5 min (dry-run + commit). Phases A and C are gated on human approval, not agent work. One agent can own the whole ticket with Lucas/Marcus wait states between phases. No decomposition needed.

Recommendation

• [SCOPE] Clarify order 93 (Westside Admin test order, westsidebasktball@gmail.com) treatment. Options: (a) exclude it and update recipient count to 17 throughout the ticket + Gate 5 read-back; (b) keep it as intentional QA recipient and note that explicitly in Scope. Currently ambiguous.
• [SCOPE] Create the story:payment-recovery entry on project-westside-basketball → stories-parent section (e.g. WS-S29: "As a parent whose checkout link expired before I could pay, I receive an apology with a fresh link so I can still complete payment"). Or, if team prefers, relabel board item to story:WS-S22 (existing "clear communications" story).
• [SCOPE] Create arch-stripe-checkout note covering the 6 Stripe Session creation paths + expires_at/metadata conventions. This backs the arch:stripe-checkout label on this ticket and the sibling tickets #1023 and #1024. Alternatively relabel to arch:dataflow-westside-basketball (existing).
• [BODY] Reword Checklist item 6 ("Runbook updated with actual recovery procedure (move into #488's scope to avoid PR churn)"). #488 is a Stripe TTL bug, not docs work. Either open a separate tracking item for the runbook update or move the clause to #488's Checklist directly (with confirmation).

Not blocking: 6-gate approval chain placement is exemplary — HARD STOP header, Phase A AC, and Constraints each re-state the rule. A reader skimming the ticket cannot miss it. The three memory references (feedback_email_blast_nuclear_gate, feedback_no_email_without_five_approvals, feedback_one_approval_one_send) are correctly cited. No refinement needed on the approval chain itself.

Verdict: READY

Board item #1013 on board-westside-basketball. Forgejo issue forgejo_admin/basketball-api#484. Labels: type:feature, arch:checkout, arch:email, story:WS-S33.

Template Completeness

• [x] Type (Feature)
• [x] Lineage
• [x] Repo
• [x] User Story
• [x] Context (webhook + helper line refs)
• [x] Current State
• [x] File Targets (3 NEW files)
• [x] Files NOT to Touch
• [x] Acceptance Criteria (5)
• [x] Test Expectations (run command included)
• [x] Constraints
• [x] Checklist
• [x] Related

Traceability

• [x] story:WS-S33 label — "As an admin, I want to bill players for tournament entry fees at team-specific rates via Stripe so that event costs are collected before registration deadlines"
• [x] story note verified — WS-S33 present in project-westside-basketball user-stories (stories-admin-list block)
• [x] arch:checkout + arch:email labels
• [ ] arch note MISSING — [SCOPE] No arch-checkout or arch-email notes exist in pal-e-docs. Non-blocking here (consistent with current project convention; no peer tickets carry backing arch notes either), but worth a follow-up scoping item to stand these up.
• [x] Forgejo issue — forgejo_admin/basketball-api#484 open

File Targets

• [x] src/basketball_api/routes/webhooks.py (reference-only) — verified. Line 197 reads order_id_str = metadata.get("order_id"). Matches ticket claim that handler reconciles via order_id metadata.
• [x] src/basketball_api/routes/checkout.py (reference-only) — verified. create_player_checkout_session() defined at line 467 (ticket said 529-533; those lines are where the metadata dict is built and include "order_id": str(order.id)). Ticket's functional claim is correct; the cited line range refers to the metadata block inside the helper, not the def line. Acceptable.
• [x] scripts/regenerate_tournament_orders.py — NEW; does not exist. Correct.
• [x] tests/test_tournament_webhook_roundtrip.py — NEW; does not exist. Correct.
• [x] docs/tournament-billing-runbook.md — NEW; docs/ exists (migrations.md, auth-architecture.md), file does not. Correct.

Repo Placement

OK. All file targets live under forgejo_admin/basketball-api. Single-repo scope; no cross-repo coordination needed.

Dependencies

• Related: #456 (blast system), #457 (tournament checkout), #463 (blast query integration). None are listed as blockers, and the ticket operates on data those features produced. The 21 stale Orders are an artefact of #457's rollout; this ticket cleans up without depending on further work.
• No board items in in_progress appear to block this (board_slug board-westside-basketball is large; relied on ticket's own Related links rather than exhaustively diffing the board).
• sop-email-send (updated 2026-04-13) referenced as context for blast handoff, not as a code dependency.

Acceptance Criteria

All 5 criteria are verifiable by an agent:

• Script deletes + regenerates against tournament_id=2 — verifiable via DB query pre/post.
• Every new session has order_id metadata — verifiable via Stripe API list.
• Webhook roundtrip flips pending → paid — covered by the integration test run command pytest tests/ -k "tournament_webhook or regenerate".
• Runbook documents sequence + forbids ad-hoc sessions — verifiable by reading docs/tournament-billing-runbook.md.

Minor ambiguity: ticket says "synthesized signed" webhook event and "test-mode Stripe webhook secret", while every existing webhook test in this repo mocks stripe.Webhook.construct_event rather than exercising real HMAC verification. Dev should either (a) follow existing mock pattern and drop the "signed" language, or (b) use stripe.WebhookSignature.generate_header against a fixture secret. [BODY] Minor clarification welcome but not blocking — dev can judge from existing tests/test_webhooks.py.

Blast Radius

Flagging for visibility (not blocking this ticket):

• The runbook rule "always use admin endpoint, never ad-hoc sessions" conflicts with 6 existing call sites of stripe.checkout.Session.create in src/: admin.py:2005, jersey.py:291, register.py:1378+1423, checkout.py:246+394+537. Each of these paths is "the committed endpoint" for its domain (jersey/register/subscription), not ad-hoc. The runbook should scope its rule to tournament-fee checkout specifically, or explicitly enumerate the sanctioned helpers per product type. Worth a sentence in the runbook.
• Zero production data risk: ticket confirms 21 stale sessions are all expired/unpaid with zero payments collected. Safe cleanup.
• Idempotency constraint is explicit — good.

Decomposition Assessment

3 new files, 5 AC, single repo, no migrations, no infra changes. Estimated agent work < 5 min. No decomposition needed.

Recommendation

• [SCOPE] Follow-up ticket: create arch-checkout and arch-email notes in pal-e-docs so future tickets with these labels have backing architecture notes to reference. Not a blocker for #484.
• [BODY] Optional clarification in #484: spell out whether "signed synthesized event" means real HMAC (via stripe.WebhookSignature.generate_header) or the existing mocked construct_event pattern used across tests/test_webhooks.py. Dev can reasonably choose either; noting it preempts review churn.
• [BODY] Optional refinement: in the runbook's "never ad-hoc" rule, scope it to "never create Stripe sessions for tournament fees outside create_player_checkout_session()." The broader statement conflicts with sanctioned per-product helpers elsewhere in the codebase.

READY to advance to next_up. Recommendations above are nits for dev to absorb; none block execution.

Verdict: READY

Scope is tight, file targets verified against origin/main, traceability complete. Fits a single agent pass (<5 min).

Template Completeness

• [x] Type (Bug)
• [x] Lineage (regression from #473)
• [x] Repo
• [x] What Broke
• [x] Repro Steps
• [x] Expected Behavior
• [x] Environment
• [x] File Targets
• [x] Acceptance Criteria
• [x] Test Expectations
• [x] Related

Traceability

• [x] story:WS-S11 — "As an admin, I want to create Stripe checkout sessions for jerseys/fees so that payments are automated" (verified in project-westside-basketball user-stories)
• [x] arch:basketball-api label present
• [ ] arch note MISSING — no arch-basketball-api note returned by semantic search. [SCOPE] Create arch-basketball-api note (pre-existing gap across all basketball-api tickets, not unique to this one — recommend tracking as a board item rather than blocking this fix)
• [x] Forgejo issue 479 — open, URL valid

File Targets

• [x] src/basketball_api/routes/checkout.py — verified on origin/main. The "fresh-pending reuse" branch is at lines 358-374 (ticket says 360-380 — close enough, line count matches intent). Confirmed: stripe.checkout.Session.retrieve followed by unconditional RedirectResponse without amount comparison. Fix surface is ~5 lines as claimed.
• [x] tests/test_first_payment.py — verified. Existing tests referenced in acceptance criteria all present: test_first_payment_paid_still_blocked (line 171), test_first_payment_stale_pending_replaced (line 201), test_first_payment_fresh_pending_returns_redirect (line 263). Adding new test fits existing fixture pattern.

Repo Placement

OK. Fix is localized to basketball-api. Email rendering (basketball-api/services/email.py) is explicitly excluded and correct — email always uses fresh fee. No cross-repo work needed.

Dependencies

Depends on #473/#474 (already merged on main). No open blockers. Ticket does not block anything else.

Acceptance Criteria

Five criteria, all verifiable via pytest. Each maps to a specific test (existing or new). Run command provided: pytest tests/test_first_payment.py -v. Testable and complete.

Blast Radius

Grepped for similar "retrieve existing Stripe session and redirect" patterns in checkout.py. The pattern exists only in first_payment_checkout (single match at lines 365-368). Jersey and tournament checkout flows do not reuse sessions — they create new each time. No sibling services need the same fix.

Note: Stripe Checkout Sessions are immutable after creation — ticket correctly identifies that the fix path must cancel + create new, not "update amount."

Decomposition Assessment

2 file targets, 1 repo, 5 AC, estimated ~5 line code change + 1 new test. Well under the 5-minute rule. No decomposition needed.

Recommendation

• [SCOPE] Create arch-basketball-api architecture note. Pre-existing gap affecting all basketball-api tickets — track separately, do NOT block this fix.

No other action needed. Ready to move backlog → todo.

Verdict: READY

Template Completeness

• [x] Type — Bug
• [x] Lineage — Standalone, discovered Apr 13
• [x] Repo — forgejo_admin/basketball-api
• [x] What Broke — detailed symptoms, prod log evidence, order state table
• [x] Repro Steps — 6 clear steps including bot-triggered scenario
• [x] Expected Behavior — present
• [x] Environment — cluster, namespace, commit SHA
• [x] File Targets — present with explicit "do not touch" list (exceeds template minimum)
• [x] Acceptance Criteria — 5 criteria
• [x] Test Expectations — 3 named tests with run command (exceeds template minimum)
• [x] Constraints — 4 constraints including audit trail and threshold rationale
• [x] Related — project, cross-repo ticket, discovered scope noted

All required Bug template sections present. Issue also includes File Targets, Test Expectations, and Constraints sections beyond the base Bug template — excellent specificity.

Traceability

• [x] story:WS-S11 label — "As an admin, I want to create Stripe checkout sessions for jerseys/fees so that payments are automated"
• [x] story note verified — WS-S11 found in project-westside-basketball user-stories section under Admin (Marcus)
• [x] arch:basketball-api label — basketball-api component
• [ ] arch note MISSING — [SCOPE] No arch-basketball-api note exists in pal-e-docs. This is a pre-existing gap across many westside board items, not specific to this ticket.
• [x] Forgejo issue — forgejo_admin/basketball-api#473, open

File Targets

• [x] src/basketball_api/routes/checkout.py lines 347-361 — verified: first_payment_checkout() duplicate guard queries for OrderStatus.paid and OrderStatus.pending in an .in_() filter, then raises 409 unconditionally. Exactly matches ticket description.
• [x] "Do not touch" files verified as existing and irrelevant to the fix

Repo Placement

OK. Issue filed on forgejo_admin/basketball-api, fix is entirely within basketball-api. Single repo.

Dependencies

No blocking dependencies found on the board. Board item #720 (legacy jersey webhook handler) touches payment status but is in backlog and unrelated. Cross-reference to pal-e-platform#290 (observability) is informational only, not a blocker.

Acceptance Criteria

All 5 AC are agent-verifiable:

• AC1-4: testable via the 3 named pytest cases in Test Expectations
• AC5 (no webhook regression): verifiable by running existing webhook test suite

Test command provided: pytest tests/test_first_payment.py -v. Test file confirmed to exist at tests/test_first_payment.py.

Blast Radius

Same pattern exists in 2 sibling functions — important context for the dev agent:

• create_checkout_session() (checkout.py:181) — jersey/product checkout, same .in_([paid, pending]) guard. May need the same stale-pending fix if jersey links are also shared via email/social.
• create_player_checkout_session() (checkout.py:485) — admin bulk checkout helper, same pattern. Less urgent since admin-triggered, not link-based.
• admin.py:2356 — admin bulk route already handles pending differently (skips with message instead of hard 409). No fix needed here.

The ticket correctly scopes to first_payment_checkout() only. The sibling functions are discovered scope for separate tickets if the same bot-triggered 409 manifests there.

Decomposition Assessment

1 file target, 1 repo, 5 AC, 3 tests. Single function modification with clear before/after behavior. Well under the 5-minute rule. No decomposition needed.

Recommendation

No action needed — ticket is ready for dispatch.

Informational notes (not blocking):

• [SCOPE] Create architecture note arch-basketball-api for component basketball-api (pre-existing gap, not specific to this ticket).
• Discovered scope: sibling functions create_checkout_session() and create_player_checkout_session() have the same stale-pending vulnerability. Track as separate tickets if the pattern manifests on jersey or admin checkout links.