Run: 018 · Date: 2026-05-06 · Phase 1 author · Slice: emotional and motivational framing for intern onboarding
1. What actually motivates a 20 year old intern
Forget "professional development." Two people this age care about five things, in order:
Possession. "This is MY page." Charlie owns Meetings. Bear owns Deals. The feature definitions in src/lib/features/defs/meetings.ts literally say owner: 'charlie'. That is not a metadata field. That is an identity anchor. When Charlie opens the codebase and sees his name next to four features, the page stops being Ewing's system and starts being Charlie's territory. Same for Bear with owner: 'bear' on three deal features. The single strongest motivator for a young builder is seeing their name in the source code of a production system.
Visible fingerprints. "I added that column." The moment an intern changes something and sees the change appear on a URL that other humans use, a switch flips. This is not about learning. This is about proof of existence. A column header, a filter dropdown, a status badge. Small, visible, theirs. Every early task should produce something that loads in a browser and can be pointed at.
Scoreboard movement. "My classify speed went from 40 seconds to 12." The feature_metrics table logs every invocation with timestamps. Charlie can see that his meeting classification got faster. Bear can see that his pipeline view loads more deals. Numbers going in the right direction, week over week, are addictive at this age because most of their school experience is static grades on static assignments. A metric that moves because they moved it is new.
Boss noticed. "Ewing mentioned my draft was good." At 20, recognition from a Managing Partner is currency. Not a Slack emoji. An actual sentence: "Charlie, that follow up draft caught the tone." The feature system's requires_review: true on meetings.draft-followup means Ewing will literally see Charlie's output before it ships. That review loop is not a bottleneck. It is a stage.
Demonstrability. "Look what I built." They need to be able to pull out a phone, load a URL, and show a friend or a parent. "This page? I built the filter that finds warm leads." If the artifact is invisible or buried in backend logic, the motivation drains. Everything early should render on screen.
Evidence: The owner field on FeatureDef objects (src/lib/features/types.ts) is the structural proof that the system was designed to give interns named ownership. The FeatureMetricRow type records actor, event, and timestamp per feature invocation, giving each intern a personal performance trail. The requires_review flag on specific features creates forced touchpoints where Ewing sees their work.
2. Fear inventory
Five fears, ranked by how paralyzing they are on Day 1:
Fear #1: "I will break the live site." The site is at chapter.guide. Real data. Real clients could see it. A 20 year old who has never worked on production code will hover over every button, terrified that a wrong click deletes a deal. The circuit breaker in src/lib/circuit-breaker.ts exists partly to catch this, but they do not know that yet. The fear is rational: the system does connect to Supabase, does call external APIs, does cost real money. What they need to hear on Day 1 is not "don't worry" but "here is the safety net, and here is how to verify you haven't broken anything."
Fear #2: "I will look stupid in front of Ewing." Ewing is the Managing Partner of an M&A advisory firm. He built the codebase. He reviews their drafts. The power differential is enormous. A 20 year old would rather stay silent than ask a question that reveals they do not understand what EBITDA means or why a handoff validation checks for has_revenue_signal. The antidote is not "no stupid questions." The antidote is Ewing asking THEM questions first ("What do you think this classification should be?"), which normalizes not knowing.
Fear #3: "The codebase is alien." They will open src/lib/handoff.ts and see TypeScript types like PromotionCandidate and HandoffPayload and feel the vertigo of a system they did not build and cannot yet read. The codebase is 200+ files across Next.js, Vite, Python, and static HTML. The fear is not that it is hard. The fear is that everyone else seems to understand it and they are the only ones lost.
Fear #4: "I will accidentally spend real money." The $25/day budget cap is explicit in the CLAUDE.md rules. The circuit breaker pings Slack when spend crosses thresholds. Exa calls over $5 trigger warnings. A 20 year old intern who triggers a Slack alert to the Managing Partner on Day 2 will want to disappear. The fear is not the money. The fear is the notification, the proof that they messed up, visible to everyone.
Fear #5: "The other intern is better than me." Charlie and Bear will compare. Who shipped first? Whose page looks better? Who got operator access sooner? This fear is quiet and corrosive. It does not announce itself. It shows up as hesitation ("I should wait until mine is as good as theirs") or as copying ("Bear added a filter, I should add a filter"). The competition design below addresses this directly.
3. Onboarding emotional beats: Week 1
Day 1: "I can see the real system." Goal: awe without overwhelm. Charlie opens chapter.guide/meetings and sees live meeting data from Fireflies and Salesfinity. Bear opens chapter.guide/deals and sees an active pipeline with real company names and dollar amounts. Neither of them touches code. They browse. They click. They see that the system is alive and that real business runs through it. The emotional payload is: "This is not a tutorial project. This is a company." Guardrail: no code editors open on Day 1. No terminal. Just a browser and a notebook for questions.
Day 2: "I understand what my page does." Goal: comprehension without pressure to produce. Charlie reads meetings.ts and traces how a Fireflies transcript becomes a classified meeting. Bear reads deals.ts and traces how a promoted meeting becomes a pipeline deal. They each write a one paragraph summary of their page's data flow. They do not need to understand TypeScript syntax. They need to understand: data comes in here, gets processed here, shows up here. The emotional payload is: "I can follow the logic. I am not lost." Guardrail: the summary is for them, not for Ewing. No grading.
Day 3: "I changed something and it worked." Goal: first successful edit. A frontend only change. Charlie adds a new column to the meetings table (maybe "last contacted" or a color badge for classification). Bear adds a sort option to the deals pipeline (maybe by opportunity score). The change is small, visual, and impossible to break backend logic with. They use Claude Code to make the edit. They see it in the browser. The emotional payload is: "I can change this system. It responds to me." Guardrail: no API calls, no database writes, no new features that touch canUse() permissions. Pure frontend.
Day 4: "I built something useful." Goal: first feature that Ewing sees. Charlie builds a filter that surfaces unclassified meetings (the backlog). Bear builds a view that shows warm leads awaiting promotion (deals.view-warm-leads is already defined but Bear makes it better). These are intern tier features that go live without operator review. The emotional payload is: "Ewing used the thing I built today." Guardrail: features must be registered in the defs file before code is written. No rogue features.
Day 5: "I own this." Goal: identity lock. By Friday, Charlie can open chapter.guide/meetings and point to three things that exist because of him. Bear can do the same on deals. They each demo their page to Ewing in a 10 minute standup. Not a presentation. A walkthrough: "Here is what I built, here is what it does, here is what I want to build next week." The emotional payload is: "This page is mine. I can explain every piece of it." Guardrail: the demo is a conversation, not a performance. Ewing asks questions, not judges.
4. Guardrail messaging: "not yet" instead of "not allowed"
The permission system in src/lib/features/permissions.ts has three tiers: intern, operator, admin. The current gateReason() function returns a message like "Requires operator tier (you are intern)." That is technically accurate and emotionally dead. Here is how to reframe each blocked action:
Promote to Deal (operator tier): "Promotions go through the review queue right now. Once Ewing sees that your classification judgment is calibrated, meaning your promotable meetings consistently have revenue signals and entity links, you will get operator access to promote directly." Change Deal Stage (admin tier): "Stage changes affect the revenue forecast that Ewing presents to clients. You will earn this access after you have tracked a few deals through the full pipeline and understand what each stage transition means for the engagement." Edit Deal Financials (admin tier): "Financial numbers (EBITDA multiples, enterprise value, fee percentages) drive the firm's revenue projections. This stays with Ewing until you have sat through enough deal reviews to calibrate what the numbers should look like." Approve Learning (operator tier): "Agent extracted learnings feed back into the system's classification model. Approving bad learnings degrades future accuracy. You will get this after you have reviewed enough meetings to spot when the agent is wrong." Draft Follow up Email (intern tier but requires review): "You can draft these all day. They go to Ewing's review queue before sending because tone in a client email is make or break. Once your drafts consistently pass review without edits, the review flag comes off."
The pattern: name what the action affects, explain what calibration looks like, describe the specific milestone that unlocks access. Never say "you can't." Say "you will, after X."
Evidence: The gateReason() function in permissions.ts currently returns a bare tier comparison string. The reframing above does not require code changes to the permission system. It requires a UI layer that intercepts the gate reason and maps it to a contextual message per feature key. This could live as a simple lookup object in the frontend: GATE_MESSAGES[feature.key] returning the "not yet" framing instead of the raw tier string.
5. Competition design: rivalry through the handoff contract
Charlie and Bear must compete without sabotaging each other. The structural key is the handoff contract in src/lib/handoff.ts. Charlie classifies meetings on the Meetings page. When a meeting is promotable, it crosses into Bear's territory on the Deals page. This creates a natural dependency chain with built in quality pressure:
Charlie's quality is Bear's input. If Charlie classifies a meeting as "deal" but it has no revenue signal, no entity link, and an opportunity score of 15, the isPromotable() function rejects it. Bear never sees it. Charlie's sloppy classification does not burden Bear; it burdens Charlie, because his "deals found" count stays flat while Bear's pipeline has nothing new to work with. The system punishes low quality at the source, not downstream.
Bear's feedback is Charlie's training signal. When Bear sees a promoted meeting that was misclassified or missing context, he can flag it. That flag teaches Charlie what a good classification looks like. If Bear stays silent about bad promotions, Charlie never improves and Bear keeps getting weak leads. Bear's self interest (better input) requires him to give Charlie honest feedback.
Shared scoreboard, separate metrics. Both interns see the same dashboard, but their numbers measure different things:
Charlie: meetings classified per day, classification accuracy (did promoted meetings convert?), time from meeting to classification Bear: deals advanced per week, pipeline value managed, warm lead conversion rate
These metrics are complementary, not zero sum. Charlie's number going up helps Bear's number go up. But each intern can see their own trend line and push to improve it.
Weekly handoff review. Every Friday, Charlie and Bear sit together and review the week's handoffs. Which meetings promoted cleanly? Which ones had warnings? Which ones got stuck in the review queue? This is not a blame session. It is a calibration session. They learn what a good handoff looks like by examining real ones together. The emotional payload: "We are two parts of the same machine, and the machine works better when we both get sharper."
Evidence: The isPromotable() function requires has_revenue_signal, opportunity_score >= 30, is_classified_as_deal, and has_entity before a meeting can cross to Bear's pipeline. The promotionDecision() function gates auto promotion at score 50+, sending everything between 30 and 49 to the review queue. This is a built in quality ramp: Charlie cannot flood Bear's pipeline with garbage because the validation catches it. The HandoffValidation type tracks exactly which checks passed and which threw warnings, giving both interns a shared vocabulary for what "good" looks like.
I have not talked to Charlie or Bear. Everything above is projection based on the codebase, the permission model, and general knowledge of what motivates people at that age. Two risks: (1) one or both interns may already have coding experience that changes the fear profile entirely. If Bear already knows TypeScript, the "alien codebase" fear is irrelevant and the onboarding pacing is too slow. (2) The emotional arc assumes they care about ownership. Some 20 year olds are pure task followers who want to be told exactly what to do. If either intern is a task follower, the ownership framing will feel like pressure, not motivation. Ewing needs to calibrate during Day 1 whether each intern is a builder or a follower and adjust the onboarding speed accordingly.
Second blind spot: the "not yet" guardrail messaging assumes the UI can intercept gateReason() output and replace it with contextual messages. I have not verified that the frontend surfaces gate reasons to users at all. If the gate silently hides the button instead of showing a message, the "not yet" framing has nowhere to appear. The frontend needs a visible "why can't I do this?" affordance for the messaging to work.
No prior maxswarm run has addressed intern onboarding or emotional design. Run 017 was the closest draper assignment (About Us PDF creative direction), but that was visual/brand work with no personnel dimension. The permission system (canUse(), tier ranks, gate reasons) was introduced in the codebase recently (created_at dates on all features are 2026-05-06) and appears purpose built for this intern onboarding. The feature definitions naming Charlie and Bear as owners, combined with the tiered permission model, suggest Ewing designed the system with the emotional arc in mind before any swarm agent analyzed it. This run formalizes what was implicit.
On future runs involving human users (not agents, not systems), I will lead with the fear inventory before the motivation analysis. Motivation frameworks are useless if the person is paralyzed. Knowing what stops someone is more actionable than knowing what drives them, because you can remove a blocker in one conversation but building intrinsic motivation takes weeks. I will also always verify whether the UI surfaces the messaging I design. Copy without a delivery surface is decoration.
Generated from 018__draper.md — do not edit this HTML directly.