pal-e-docs

Review: P0: bundle_id resource implementation (v2)

review-1535-2026-06-20-v2 Review

review ready
Project

Verdict: READY

Board item #1535 on board-project-ios-infrastructure. Forgejo issue: ldraney/appstoreconnect-tofu#3. Reviewed 2026-06-20 (re-review v2).
Re-review context: Previous review (review-1535-2026-06-20) returned NEEDS_REFINEMENT due to missing arch-asc-provider note and missing project-page-ios-infrastructure. Both have since been created. Issue body was unchanged -- it was already clean.

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- Standalone, first code implementation
  • [x] Repo -- ldraney/appstoreconnect-tofu
  • [x] User Story -- platform engineer wants declarative bundle ID management
  • [x] Context -- adequate background, references architecture.md and godaddy-tofu patterns
  • [x] File Targets -- 7 files to create, clearly specified with purpose
  • [x] Feature Flag -- "none" (appropriate for provider infrastructure)
  • [x] Acceptance Criteria -- 5 items covering build, plan, apply, destroy, data source
  • [x] Test Expectations -- unit (JWT, JSON:API) and integration (TF_ACC=1)
  • [x] Constraints -- godaddy-tofu patterns, JSON:API in pkg/, env vars only
  • [x] Checklist -- PR opened, tests pass, no unrelated changes
  • [x] Related -- project-ios-infrastructure
All required sections present. Template is fully complete.

Traceability

  • [x] story:provision label -- present on board item
  • [x] story note verified -- "provision" entry found in project-page-ios-infrastructure user-stories section (Role: Platform engineer, Success: "tofu apply provisions bundle IDs, profiles, devices, DNS for a new iOS app")
  • [x] arch:asc-provider label -- present on board item
  • [x] arch note verified -- arch-asc-provider note exists in pal-e-docs (project: project-ios-infrastructure, covers API capabilities, auth, app creation constraint, consumer info)
  • [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/appstoreconnect-tofu/issues/3, state: open
All three traceability legs verified. Previous blockers resolved.

File Targets

  • [x] main.go -- to create, consistent with docs/conventions.md debug flag pattern
  • [x] provider.go -- to create, consistent with docs/architecture.md diagram
  • [x] go.mod / go.sum -- to create, standard Go module init
  • [x] pkg/appstoreconnect/client.go -- to create, consistent with architecture.md Client class diagram
  • [x] pkg/appstoreconnect/bundle_ids.go -- to create, consistent with architecture.md BundleID struct
  • [x] resource_bundle_id.go -- to create, consistent with architecture.md resource diagram
  • [x] data_source_bundle_ids.go -- to create, consistent with architecture.md data source diagram
All files are new (repo currently contains only CLAUDE.md, README.md, and docs/). File paths are consistent with the documented architecture and conventions. The repo's docs/conventions.md provides detailed Go patterns (factory pattern, debug flag, ImportState, JSON:API handling, error mapping) that give the implementing agent strong guardrails.

Repo Placement

OK. Issue filed on ldraney/appstoreconnect-tofu, all work targets that repo. Single-repo scope.

Dependencies

  • No upstream blockers on the board -- this is the first implementation ticket.
  • Board item #1537 (Manual: Create Palinks app in ASC) logically depends on bundle_id existing first (per architecture diagram: BID -> APP). Correctly sequenced.
  • godaddy-tofu repo exists and is the pattern reference. Not a code dependency, but a convention dependency -- agent needs read access to study patterns.
  • No cross-repo code dependencies.

Acceptance Criteria

5 ACs, all agent-verifiable:
  • go build -- verifiable via CLI
  • tofu plan -- verifiable via CLI (requires provider config)
  • tofu apply creates bundle ID -- verifiable against live API (requires API credentials)
  • tofu destroy removes bundle ID -- verifiable against live API
  • Data source lists bundle IDs -- verifiable via tofu plan output
ACs are well-scoped and testable. The tofu apply/destroy ACs require live API credentials which the agent would need access to (env vars per Constraints section).

Blast Radius

Minimal. This is a greenfield provider in its own repo. No existing consumers. The only downstream integration point is pal-e-platform/terraform/ios.tf (shown in architecture.md), which would consume this provider after it's published. No blast radius concerns for this ticket.

Decomposition Assessment

7 files to create across 1 repo. 5 acceptance criteria. 2 test categories. All files follow well-documented patterns from godaddy-tofu and the repo's own docs/conventions.md. The strong convention docs (factory pattern, CRUD mapping, JSON:API handling, error table, naming conventions) significantly reduce implementation ambiguity. Estimated agent work: ~5 minutes, borderline but feasible as a single pass given the pattern-following nature. No decomposition needed.

Recommendation

No action needed. Ticket is ready to move from backlog to todo.