Two-Track Architecture — INTERN vs BOOTCAMP, Design Decisions and Constraints

[LarytheLord]

What This Discussion Is

A deep-dive into why the platform has two tracks (INTERN and BOOTCAMP), why they are kept separate, how they interact, and what constraints that places on every feature you build.

Read docs/ARCHITECTURE_DECISIONS.md (Decisions #1–3) alongside this.

---

The Core Problem This Solves

Open Paws runs two fundamentally different programs simultaneously:

1. Interns — contracted professionals, paid, production-grade delivery, D+ rank quests, squads of 3–5, May–July 2026
2. Bootcamp students — learners, unpaid (XP only), F/E rank quests, solo or pairs, ongoing

These two groups cannot be in the same talent pool because:

• A bootcamp student's first submission cannot go directly to a paying client
• Interns working on D-rank features cannot be mixed with F-rank students who don't understand the architecture yet
• Quality SLAs differ: interns deliver in days, bootcamp students deliver over a week or more

The solution: the QuestTrack enum creates a hard separation at the data layer.

---

The QuestTrack Enum

enum QuestTrack {
  OPEN      // public marketplace — any adventurer can apply
  INTERN    // 20 paid interns, May–Jul 2026, D+ rank, squads
  BOOTCAMP  // bootcamp students, F/E rank only, solo or pairs
}

Every quest has a track. Track is enforced at the API level, not just the UI.

GET /api/quests with ?track=BOOTCAMP

If the requesting user has a BootcampLink:
  → force track = BOOTCAMP regardless of query param
  → if eligibleForRealQuests = false: only return Tutorial: quests

If the requesting user is an intern:
  → can see INTERN track quests
  → can also see OPEN track quests (they're ranked professionals)

If the requesting user is a regular adventurer (OPEN):
  → only sees OPEN track quests

Why API enforcement and not just UI? A determined user can bypass frontend filters by hitting the API directly. Track is a business constraint, not a preference. It must be enforced server-side.

---

The BOOTCAMP Track in Detail

Entry Conditions

A student enters the platform when Open Paws Bootcamp sends a webhook to POST /api/onboard. This creates:

• User (role: adventurer, rank: F)
• AdventurerProfile
• BootcampLink with eligibleForRealQuests = false

The student cannot see or apply to real bootcamp quests yet.

Tutorial Gate

Before real work, every student must complete two tutorial quests:

Quest	What it proves
Tutorial: First Blood	Can navigate git, PRs, CI, basic code review
Tutorial: Party Up	Can work in a pair, coordinate on a shared codebase

On approval of each tutorial:

• BootcampLink.tutorialQuest1Complete = true / tutorialQuest2Complete = true
• When both done: eligibleForRealQuests = true

Without this gate, first real deliverables to clients would be embarrassing. See docs/ARCHITECTURE_DECISIONS.md Decision #3.

Work Format

• F-rank quests: solo only
• E-rank quests: pairs (party of 2)
• Max revision cycles: 2 (then escalation to admin)
• Submissions go to pending_admin_review before client sees them (issue feat: Admin QA Mediation Layer — pending_admin_review state and QA queue #105)

---

The INTERN Track in Detail

Entry Conditions

Interns are recruited externally and onboarded by the admin. They arrive as D-rank adventurers minimum. They do not go through the tutorial gate.

Work Format

• D+ rank quests
• Squads of 3–5 (Party system, issue feat: Squad/Party System — Schema, API, and Party Panel UI [S-rank] #104)
• Party Leader must have rank >= quest difficulty
• Real clients, real payment (Stripe Connect, issue feat: Stripe Connect — Adventurer payout onboarding and PaymentIntent flow #106)
• Submissions also go through pending_admin_review before client (issue feat: Admin QA Mediation Layer — pending_admin_review state and QA queue #105)

Timeline

Interns arrive May 2026. The squad system MUST be built before then. That is why issue #104 (Squad/Party) is the highest-priority Phase 2 task — it is on the critical path to launch.

---

The OPEN Track

The original marketplace track. Any ranked adventurer can browse and apply. No tutorial gate. No squad requirement (though squads are permitted in Phase 3). Direct to client review on submission (no admin QA gate).

This is the commercial track for external clients who want to post quests publicly. It generates platform revenue via the 15% commission.

---

How the Tracks Interact: Sub-Quests

When an INTERN squad is working on a D-rank feature, they may need small supporting tasks done: writing docs, adding tests, fixing a CSS bug. These are sub-quests.

Admin (or the party leader) creates F/E rank sub-quests with parentQuestId pointing to the intern quest. These sub-quests have track = BOOTCAMP, so they appear on the bootcamp quest board.

D-rank INTERN quest: "Build auth module" (party of 4 interns)
  └── F-rank BOOTCAMP sub-quest: "Write unit tests for auth module"
  └── E-rank BOOTCAMP sub-quest: "Document the auth API endpoints"

This creates an organic pipeline of F/E bootcamp work that is directly useful to the intern delivery — no artificial exercises.

---

What NOT to Build Across These Tracks

Do not mix tracks. A bootcamp student should never see an INTERN quest, even if they are technically advanced. The track is about program enrollment, not just skill level.

Do not remove the admin QA gate for INTERN track. Even experienced interns can produce work that needs mediation before reaching the client. The gate stays.

Do not add payment to BOOTCAMP track in Phase 2. Bootcamp students earn XP and portfolio. Payment infrastructure is complex and the program is not yet validated. Phase 3 will revisit.

Do not graduate students from BOOTCAMP to INTERN track automatically. This transition is a manual admin decision based on performance. No automated promotion.