Run: 2026-05-06__018__intern-foundation · Date: 2026-05-06 · Phase 1 author
1. Stated intent (Ewing's words, paraphrased to brief) Build a foundation layer -- feature registry, circuit breakers, tickets, handoff contract, spend tracking, intern guardrails -- so two non-technical interns (Charlie on Meetings, Bear on Deals) can build features on top of it using Claude Code. The system must enforce permissions, track spend, and force collaboration through a formal meetings-to-deals handoff.
2. Unstated intent (5 reads, with evidence)
He is building a management instrument, not a CRM feature set. Evidence: the plan spends more words on permissions, metrics, lifecycle stages, and actor-context than on any user-facing feature. The feature_metrics table logs every action with actor name. The spend_log tracks every dollar with actor attribution. The circuit breaker Slacks Ewing personally. These are not product features -- they are management telemetry. Ewing is building a system where he can see what his interns did, what it cost, and whether it worked, without asking them.
He wants to evaluate judgment, not output. Evidence: the intern-tier permissions are not about blocking dangerous buttons. They are about forcing classification decisions (Charlie must classify meetings correctly before promotion is even possible), financial restraint (circuit breakers at $25/day), and triage accuracy (ticket resolution). The plan says interns "must learn that the system IS the database + the crons + the webhooks, not just the UI." The evaluation Ewing cares about is: do they understand why the system exists, or do they just click buttons?
He needs a "Day 0 terminal command" and hasn't written it yet. Evidence: the plan has detailed Week 1 and Week 2 learning paths for both interns. It specifies line-by-line code reading tasks. But it never says how Charlie and Bear get Claude Code installed, how they authenticate against Supabase, how they get Doppler access, or what their first git clone looks like. The CLAUDE.md intern rules assume the interns are already inside the repo with Claude Code running. There is a gap between "hire date" and "can read meetings/page.tsx."
He wants to know when they are stuck without them having to ask. Evidence: the ticket system has a promotion path (Tier 1 fails twice, escalates to Tier 2, then Tier 3 to Ewing). But there is no equivalent for intern confusion. If Charlie spends 90 minutes on a task that should take 15, nothing fires. The feature_metrics table records invocations but not duration or attempt count. The system tracks machine failures (sync errors, budget overruns) but not human failures (intern stalled, intern repeated the same action five times, intern hasn't touched the system in two hours).
He wants the handoff to teach collaboration, not just transfer data. Evidence: the plan says Charlie builds the "Promote to Deal" button and Bear builds the receiving end, and "they must coordinate on the HandoffPayload contract." But the HandoffPayload type is already fully defined in src/lib/handoff.ts. Ewing wrote the contract himself. The coordination he wants is not about the type definition -- it is about Charlie and Bear having a conversation about what makes a meeting promotable, what Bear needs to see in the deal when it arrives, and what happens when the data is incomplete. The handoff is a Socratic teaching device, not a data transfer.
3. Five gaps between what was built and what is needed
Gap A. No intern activity dashboard. feature_metrics and spend_log exist as tables, but no page reads them. There is /admin/dashboard and /admin/activity, but neither queries feature_metrics grouped by actor. Ewing currently has to run raw SQL to answer "what did Charlie do today?" He needs a single page -- /admin/intern-pulse or equivalent -- that shows: actions per intern per day, features used, tickets resolved, spend attributed, time since last action. Without this, the management telemetry he built has no UI.
Gap B. No trust gradient mechanism. The tier system is static: ACTOR_TIER in permissions.ts is a hardcoded Record. Charlie is "intern" forever unless Ewing edits source code. There is no tier_upgrade_criteria table, no "graduated to operator" event, no threshold (e.g., "classified 200 meetings with <5% reclassification rate" or "resolved 10 Tier 1 tickets"). The plan implies a trust gradient ("intern who proves competence earns operator access") but the system has no way to track progress toward that threshold or trigger the upgrade.
Gap C. No communication channel specification. The ticket system handles machine incidents. The review/tasks system handles approval queues. But where does Charlie ask "I don't understand what entity_id means"? The plan assumes a communication channel (Slack? In-app? Standup?) but never specifies it. The notifySlack function exists in alert.ts for system alerts, but there is no inverse: intern-to-Ewing question routing. An intern who is confused and has no channel defaults to either (a) guessing, which is what the guardrails are designed to prevent, or (b) stopping work entirely.
Gap D. No code review process. The plan says interns build features using Claude Code. The feature lifecycle is design-build-test-live. But the transition from "build" to "test" has no gate. There is no PR template, no review checklist, no "Ewing must approve the diff before status changes to test." The requires_review field on FeatureDef controls runtime approval (UVD review for drafts and enrichments), not code review. An intern could theoretically ship a feature to "test" status without Ewing ever seeing the code.
Gap E. No anti-silo mechanism beyond the handoff. The HandoffPayload forces a data dependency between Charlie and Bear. But once per week (Week 2), that link fires. The rest of the time, they work in separate domains with separate dashboards. There is no shared standup artifact, no "Bear sees Charlie's signal quality metrics" view, no cross-domain notification ("Charlie classified 3 meetings as deals today, Bear should expect warm leads"). The plan hopes the handoff creates collaboration, but the handoff is an event, not a relationship. A daily shared context artifact would do more.
4. What Ewing would build if he had infinite time
An intern scorecard. Something that composites classification accuracy, response time, ticket resolution rate, spend efficiency, and feature build quality into a single weekly number per intern. Not for performance review -- for Ewing to know which intern needs coaching on what, without reading every log line. A "stuck detector." A background process that watches feature_metrics for patterns: same feature invoked > 5 times in 10 minutes (looping), no invocations for > 2 hours during work hours (stalled), repeated "failed" events on the same feature (hitting a wall). Fires a quiet Slack DM to Ewing, not a ticket. A graduated permission cron. Weekly job that queries feature_metrics and agent_tickets, computes accuracy/velocity/resolution metrics per intern, and when thresholds are met, proposes a tier upgrade to Ewing for approval. Makes the trust gradient automatic instead of ad hoc. A shared daily digest. A page or Slack message that both interns and Ewing see every morning: "Yesterday: Charlie classified 14 meetings (2 promoted). Bear updated 3 deals. $4.20 spent. 1 ticket resolved." Forces shared context without requiring a meeting.
Ewing is building a management operating system disguised as a CRM foundation. The stated goal is "feature registry + guardrails so interns can build." The unstated goal is a system where Ewing can evaluate intern judgment (not just output), detect when they are stuck (not just when machines fail), and gradually increase their autonomy based on demonstrated competence. The infrastructure for this -- feature_metrics, spend_log, canUse() -- is built. But the five pieces that would make the management layer actually usable are missing: (A) an intern activity dashboard that reads the telemetry he already collects, (B) a mechanism to graduate interns from one tier to the next, (C) a specified communication channel for questions (not just incidents), (D) a code review gate between "build" and "test" lifecycle stages, and (E) a daily shared-context artifact that prevents silo formation beyond the weekly handoff event.
I have not verified whether /admin/dashboard or /admin/activity already query feature_metrics by actor. I saw that grep found no files outside metrics.ts and circuit-breaker.ts referencing these tables, but the pages could be using client-side Supabase queries or a different data path I did not trace. I also did not check whether Ewing has an existing Slack channel or workflow for intern communication -- the gap I identified (no communication channel) could be solved outside the codebase, in which case it is not a code gap but an onboarding-documentation gap. Finally, I assumed the interns are non-technical based on the plan's tone and the Claude Code scaffolding, but I do not have direct evidence of their skill level; if they are CS students, several of my "Day 0" concerns become less urgent.
This run resembles run #017 (About Us PDF) in structure: both required extracting the propagation layer beneath the stated artifact. In run #017, the unstated layer was "forwarding behavior." In this run, the unstated layer is "management telemetry." The pattern is: when Ewing builds something he says is for an external audience (prospects, interns), there is always a second audience (himself) whose needs are implicit. The listener's job is to surface that second audience and name what they need. New element: this is the first run where the unstated intent involves a live human relationship (employer-intern) rather than a document-reader relationship. The stakes of getting the gaps wrong are higher because confused interns cost real time, not just unopened PDFs.
Going forward, when Ewing builds infrastructure he describes as "for" someone else (interns, prospects, agents), I will immediately ask: what does Ewing-as-reviewer need from this system that he has not asked for? The pattern is consistent: the stated audience gets the features, but Ewing gets the telemetry, and the telemetry layer is always the part he builds last and needs first. I will surface that layer in Phase 1 rather than waiting for him to discover it in Phase 3.
Generated from 018__listener.md — do not edit this HTML directly.