This repository is a Rails API backend for student course access and payments: Stripe card payments, activation codes, institution paywall settings, and user product access status.
It is provided for co-op technical assessments. Your job is to read the codebase (with or without a coding agent), understand how features are structured, and produce a technical specification for a new feature described in your assignment prompt.
This repo is not intended to be run locally. It may not fully function out of the box — for example, some dependencies require internal registry access. That is expected. You will not be evaluated on whether the application boots.
This exercise is designed to understand how you work with coding agents and/or how you think about problems. We are not looking for a production-ready spec or a working implementation.
- Time budget: spend no more than 30–45 minutes on this task.
- Open questions are welcome. If something is unclear in the codebase or the prompt, note it in your document rather than spending time resolving it.
- Incomplete is fine. A thoughtful partial spec with explicit assumptions beats an exhaustive one written under time pressure.
If you finish before your interview, we will discuss your document during your scheduled interview time.
Produce a technical specification or PRD for implementing one of the feature prompts below in this codebase. Your recruiter will tell you which prompt to use and how to submit your document. The spec should be detailed enough that a coding agent could begin implementation without guessing at your intent.
Scope the work to add special pricing for the Course Platform with institution-, product-, and course-level configuration:
- Institution defaults: Set price and access duration per product per institution. Duration may be shorter than the current one-year default.
- Course overrides: Allow course-level overrides that take precedence over institution defaults when resolving payment settings for a course.
- Section-scoped overrides: When a course override selects multi-pay (Stripe + activation codes) or Stripe-only, allow that override to apply to specific sections only — unlocking custom product pricing and duration for those sections.
- Existing pattern: This should work like inclusive access today, which unlocks multi-pay vs. code-only options at the institution/course level via
InstitutionPaymentSettingandInstitutionCoursePaymentOverride.
Start here: InstitutionPaymentSetting, InstitutionCoursePaymentOverride, Product, PaymentOption, and Institutions::InstitutionService.get_course_payment_setting.
Scope the work to add pricing support for a separate quantitative course product from Lumen, alongside the existing Course Platform product:
- Product differentiation: The system must distinguish between the Course Platform product and the quantitative course product across models, payment flows, and API behavior.
- Data migration: Plan migrations to classify and update existing supported products so current data fits the new two-product model.
- Pricing parity: Apply the same pricing dimensions as Option 1 — institution-level price and duration, course overrides, and payment option selection (multi-pay, direct pay, institution pay).
- Existing patterns: Follow how
Product,ProductType,PaymentOption, and institution payment settings interact today.
Start here: Product, ProductType, PaymentOption, InstitutionPaymentSetting, and UserProduct::PaymentSettingLookupService.
| Minutes | Read |
|---|---|
| 0–5 | This README + config/routes.rb |
| 5–12 | docs/background/DOMAIN_PAYMENTS_AND_ACCESS.md |
| 12–18 | docs/background/API_LAYER.md |
| 18–22 | docs/AGENTS.md (core code paths table) |
| 22–30 | Controller + service files for your feature area |
| Domain | Start here |
|---|---|
| Products & product types | app/models/product.rb, app/models/product_type.rb, app/controllers/api/v2/products_controller.rb |
| Institution & course pricing | app/models/institution_payment_setting.rb, app/models/institution_course_payment_override.rb, app/services/institutions/institution_service.rb |
| Activation codes | app/controllers/api/v2/activation_codes_controller.rb, app/services/activation_codes/ |
| Stripe payments | app/controllers/api/v2/payments_controller.rb, app/services/stripe_extender/ |
| Access / paywall | app/controllers/api/v2/user_product_controller.rb, app/services/user_product/access_status_service.rb |
| Institutions | app/controllers/api/v2/institution_controller.rb, app/services/institutions/ |
Include what you can within your time budget — you do not need every item:
- Problem statement and acceptance criteria
- API contract (method, path, request/response JSON)
- Data model changes (if any) with migration outline
- Service layer responsibilities
- Error cases and edge cases
- Which existing patterns to follow (cite file paths)
- Open questions and assumptions (explicitly call out anything you could not resolve)
- Follow
.cursor/rules/ruby/code-style.mdcandapi-standards.mdcwhere relevant - Business logic belongs in
app/services/, not controllers - This repository has no test suite — describe tests your implementation would need
Ruby 4.0.5, Rails 8.1, PostgreSQL, Stripe — see Gemfile. Production APIs use Bearer JWT auth (implementation omitted here). No local setup is required for this assessment.