Code Comprehension Part 2: Tests & Cross-File Flow

1. What is the second step of the Part 1 reading routine — the move that follows Orient?

• Predict — name the responsibilities and behaviors you expect to find before reading.
• Trace — execute the code in your head line by line.

  Tracing is a verification move (step 5), used after a hypothesis exists.

• Refactor — rewrite confusing parts before continuing.

  Refactoring changes the code; comprehension is reading-only.

• Test — run the test suite before any other action.

  Running tests is one verification path, but the routine step that follows Orient is the prediction itself.

2. Name one switch trigger — a signal that you should stop scanning and start tracing line by line.

• A beacon is vague (data, item, result), a branch handles risky behavior (errors, money, hiding), or a test contradicts your hypothesis.
• The code uses snake_case instead of camelCase.

  Naming convention does not signal risk — it signals language.

• The function body is more than 5 lines long.

  Length alone is a poor switch trigger. A 20-line function with strong beacons can be skimmed; a 5-line function with money math may deserve a careful trace.

• There is at least one comment in the file.

  Comments are a weak signal. They can support hypotheses but do not by themselves force a switch to tracing.

3. Which are beacon types you classified in Step 3 of Part 1? (select all that apply)

• Lexical — names like visibleSnacks, isPriNum, summarize_playlist.

  Identifiers carry domain meaning and were the first beacon family introduced.

• Structural — recognizable code shapes like .filter(...).map(...), accumulator loops, guard clauses.

  Familiar code shapes activate stored programming-plan schemas.

• Framework — React useState, props, key, Node module.exports.

  Framework conventions like useState and the on* callback prefix encode behavior.

• Specification — tests, assertions, user stories, contracts.

  Tests and assertions describe behavior before the implementation is read.

• Aesthetic — code that ‘looks clean’ or follows project style.

  Style is not a behavior beacon. Pretty code can still be wrong; ugly code can still be correct.

4. What does the EiPE explanation frame stand for?

• Purpose / Mechanism / Evidence / Limit
• Purpose / Method / Equation / Length

  Code comprehension is not algebra. ‘Length’ is not part of the frame.

• Process / Mechanism / Evaluation / Logic

  Two of these are vague near-synonyms; the frame is sharper.

• Purpose / Methodology / Effect / Layout

  ‘Effect’ overlaps with mechanism; ‘Layout’ has no role in EiPE.

5. A variable named best_so_far updates only when a new candidate scores higher. Which role from Step 5 of Part 1 does it play?

• Candidate / best-so-far — remembers the current winner across iterations.
• Stepper — advances through a collection one element at a time.

  A stepper is the loop variable (item, entry), not the running winner.

• Accumulator — collects a running total of all items seen.

  An accumulator sums or appends every value; the candidate updates only when the new value beats the old.

• Flag — records whether a single condition has occurred.

  A flag is a boolean state marker, not a numeric or object winner.

6. Step 7 of Part 1 introduced false-beacon discipline. Which statement best captures that idea?

• A cue can be true about the code but still irrelevant to your specific question; test where the cue sits in the runtime flow before trusting it.
• Always assume names are lying; read every line from scratch every time.

  Universal skepticism throws away the benefit of beacons entirely. The discipline is selective, not paranoid.

• If a name is misleading, the code is buggy and should be rewritten before comprehension is possible.

  Reading and rewriting are different jobs. Comprehension comes first.

• False beacons only appear in deliberately bad code; production code can be trusted at face value.

  Production code is full of true-but-irrelevant cues: legacy fields, stale comments, helpers no longer on the runtime path.

1. What behavior hypothesis should the tests give you before reading sessionPlanner.js?

• Sessions that fit the time, prefer topic matches, favor solo at low energy.
• Sessions stored in a database, updated each request, and synced back to the user profile.

  The tests use plain functions and arrays. No database behavior appears in the setup or assertions.

• React cards rendered for each session.

  There is no JSX or React renderer in the test file.

• Every session returned, sorted alphabetically.

  The assertions check filtering and ranking, not alphabetical sorting or returning all sessions.

2. Which implementation region verifies the hypothesis that unavailable long sessions are excluded?

• The .filter(session.minutes <= request.minutes) call in pickSessionPlan()
• The request.energy === "low" scoring branch in scoreSession()

  That branch adjusts ranking for low energy. It does not remove long sessions.

• The .map(session => session.title) call inside pickSessionPlan()

  Mapping to titles changes the output shape after sessions have already been selected.

• The module.exports line at the bottom of the file

  Exports make functions available to tests. They do not implement the filtering rule.

3. A low-energy request should favor solo sessions. What is the smallest useful trace?

• Run one solo session and one pair session through scoreSession() and compare.
• Run every test in the suite and inspect every console line.

  Running tests can reveal pass/fail, but the comprehension question needs the scoring reason.

• Trace .slice(0, 2) for each request and compare the two returned titles.

  Slicing controls output size. It does not explain why solo sessions score higher.

• Inspect only the static SESSIONS data array and stop there.

  The data shows possible modes, but the behavior lives in the scoring helper.

4. Which cues make the tests useful beacons rather than just grading tools? (select all that apply)

• Behavior-focused names such as prefers a matching topic when it fits

  Behavioral test names are high-value specification beacons.

• Assertions that name the expected title or invariant

  Assertions show what must be true after the function runs.

• Setup objects with realistic request fields

  Setup data reveals the important inputs: topic, minutes, and energy.

• The fact that the file extension is .js and the tests import CommonJS modules

  The language matters for syntax, but the extension alone says little about behavior.

5. What behavior is not fully specified by these tests?

• How ties are broken when two sessions receive the same score
• Whether sessions longer than the request are excluded from results

  The first test directly specifies that long sessions should not appear.

• Whether a matching topic can appear first when it fits

  The matching-topic test directly checks the first returned session for a Node request.

• Whether low energy can boost solo sessions

  The low-energy test directly compares a solo and pair score.

6. You read sessionPlanner.test.js and have a contract-shaped hypothesis. What is the next routine move before reading every line of sessionPlanner.js?

• Beacon-hunt + descend selectively — find the function names that match the contract and inspect only those.
• Trace every line of sessionPlanner.js to build a complete program model first.

  Linear tracing burns the time budget. The routine prefers selective descent into the helpers that match each contract clause.

• Re-read the tests three more times until the implementation is obvious by elimination.

  Re-reading the same tests does not add information.

• Write a new test before reading any implementation code.

  Writing tests is a separate workflow; comprehension is reading-only here.

7. Two tests both call pickSessionPlan() and assert returned titles. What contrast should guide your implementation reading?

• Similar test shape can point to different mechanisms: minutes filtering versus topic ranking.
• Similar test shape always means both tests are verified by the same implementation line.

  Both tests use the same public entry point, but one is about filtering and the other is about ranking.

• The test with more words in its name must point to the more important helper.

  Name length is not a behavior beacon.

• Once tests call the same public function, helper boundaries stop mattering.

  The public function coordinates helpers; the contrast tells you which helper to inspect for each contract clue.

1. For GET /sessions?topic=react, what is the request-data path?

• req.query.topic in listSessions() flows into findSessions(topic), then each session becomes a summary.
• req.params.id in sessionDetails() flows into findSessions(topic), then each session becomes a summary.

  Route params are used by the details route, not the list-by-topic route.

• sessions directly reads the URL query from the request object.

  The data module exports plain data. It does not know about HTTP request objects.

• toSummary() decides which topic to filter by.

  toSummary() changes output shape after filtering; it does not choose the topic.

2. Where is the missing-session 404 response implemented?

• In sessionDetails() after findSessionById(id) returns no session
• In findSessionById() after .find(...) returns undefined

  The service returns undefined when .find(...) misses. The route decides how to turn that into HTTP.

• In the static sessions data array under data/

  The data array has no HTTP status behavior.

• In the toSummary() formatter helper

  toSummary() only formats a found session.

3. Which helper should you inspect to answer why nextStep appears in the details response but not the list response?

• withNextStep() and its call site inside sessionDetails()
• findSessions(), the list-filtering helper in the service

  findSessions() controls list filtering, not details response shape.

• fakeResponse(), the Express-response test double

  fakeResponse() simulates Express’s response object for tests; it does not choose fields.

• Number(req.params.id), the ID-conversion expression in the route

  Number conversion explains ID lookup, not which fields are returned.

4. Which files are central implementation evidence for the missing-session 404 behavior? (select all that apply)

• routes/sessionRoutes.js, because it turns a missing lookup into res.status(404).json(...)

  The route owns the HTTP status and response body.

• services/sessionService.js, because findSessionById() performs the lookup that can miss

  The service lookup is part of the implementation path because it can return no session.

• __tests__/sessionRoutes.test.js, because it states the expected behavior but does not implement it

  The test is excellent specification evidence, but it is not implementation evidence.

• data/sessions.js, because it is supporting data, but not where HTTP behavior is decided

  The data file supports the example, but the 404 behavior is not implemented there.

5. A bug report says the list endpoint is leaking nextStep. Where should the search start?

• routes/sessionRoutes.js, then compare toSummary() with withNextStep() in the service
• data/sessions.js, because every field leak starts in the data file and should be removed at the source

  The field exists in the data, but the leak would depend on which formatter the route uses.

• fakeResponse(), because it stores the response body

  fakeResponse() captures output for tests; it does not choose which fields are returned.

• Number(req.params.id), because IDs control every response field

  ID conversion belongs to the details route, not the list response shape.

6. In routes/sessionRoutes.js::listSessions(), what role does the local summaries value play?

• Gatherer / shaped output — it holds the transformed list ready to be returned in the response.
• Stepper — it iterates one session at a time.

  The stepper is the implicit session parameter inside the .map(toSummary) callback.

• Flag — it records whether any sessions were found.

  summaries is a list, not a boolean.

• Candidate / best-so-far — it tracks the highest-priority session.

  There is no ranking or comparison here; the transform is uniform across all matching sessions.

1. A user types node in the search input. What is the correct interaction path?

• LessonSearch → App (state update) → filtered lessons → LessonList.
• LessonList reads the input from the DOM, filters locally, and returns the result.

  LessonList receives the already-filtered lessons prop. It does not know about the input.

• data.js updates LESSONS to drop the non-Node lessons.

  LESSONS is static data in this example.

• LessonSearch mutates visibleLessons in App directly.

  visibleLessons is derived inside App; child components cannot mutate it directly.

2. Which file owns selectedId?

• App.jsx, where useState(null) is called and setSelectedId flows down as a prop
• LessonList.jsx, which renders the Select button that triggers the selection

  LessonList triggers the update, but the state belongs to the component that calls useState.

• LessonSearch.jsx, which owns the search input on the page

  The search input controls query, not selectedId.

• data.js, which is the source of every lesson id on the page

  The data file provides IDs. It does not own React state.

3. Which evidence proves that LessonList is display-and-event wiring, not the owner of lesson filtering?

• It receives lessons as a prop and maps over that prop.
• It contains an <article> element.

  The HTML structure says how content is grouped, not who filters data.

• It has a CSS class named lesson-card.

  The CSS class is presentation, not behavior ownership.

• It displays lesson.minutes for each card and therefore must have built the filtered collection.

  Displaying a field does not mean owning the filtered collection.

4. Which cross-file links should appear in an accurate interaction map? (select all that apply)

• LessonSearch → App through onQueryChange={setQuery}

  This is the search callback path from child to parent.

• LessonList → App through onSelectLesson={setSelectedId}

  This is the selection callback path from child to parent.

• App → LessonList through the lessons={visibleLessons} prop

  This is the derived-data path from parent to child.

• styles.css → data.js through class names that look like lesson categories

  CSS class names affect presentation here; they do not connect to the data array.

5. When should you switch from beacon reading to a small bottom-up trace in this React example?

• When you need to verify a click in LessonList actually updates App.selectedId
• Before reading any component names, props, or state hooks

  Starting with exhaustive tracing discards the useful top-down clues from names and props.

• Never — React prop names alone are enough to prove cross-file updates

  Prop names guide attention, but cross-file behavior still needs verification.

• Only after making an edit to the data.js lesson array

  The goal is comprehension before editing, not after accidental changes.

6. A reader claims that lesson.tag.includes(normalizedQuery) alone is the central evidence for what the search box does. What is the false-beacon-aware response?

• It is part of the central evidence, but the filter combines title and tag matching with ||; trusting one branch over the other is a partial-evidence trap. Verify against the full predicate.
• Always trust the first expression you read; subsequent ones are noise.

  First-found is not a comprehension strategy.

• Tag-matching always dominates title-matching in React filters by convention.

  There is no such React convention. The code shows || over title and tag.

• Search inputs only check tags, not titles, by React convention.

  There is no such convention.

1. Which helper computes subtotal: 11 for two mochi and one tea?

• subtotalFor(lineItems)
• discountFor(coupon, subtotal)

  The discount helper subtracts from an already-computed subtotal.

• checkStock(lineItems)

  Stock checking returns availability, not price totals.

• quoteCheckout(req, res) without any helper calls

  The route coordinates the helpers; it does not contain the price multiplication.

2. For the out-of-stock request, what is the shortest correct trace?

• quoteCheckout() reads req.body.items, calls checkStock(), sees ok: false, and returns res.status(409).json(...).
• Trace discountFor() because coupons decide every response.

  The route returns early before coupon logic when stock is missing.

• Trace subtotalFor() because every checkout must compute totals first, even when stock is missing and the route might return later.

  The route returns early before subtotal calculation when stock is missing.

• Trace only the items array and infer the HTTP status from stock values.

  The data is necessary evidence, but the HTTP status is created in the route.

3. Where is the STUDY10 coupon applied in a successful quote?

• discountFor(coupon, subtotal) in the route, with rules in discountService.js
• checkStock() in stockService.js, which validates line items before totals

  Stock checking decides whether the request can proceed. It does not apply coupons.

• findItem() in stockService.js, which looks up catalog items

  findItem() locates catalog items for stock and subtotal helpers.

• fakeResponse() in the test file, which captures the response body

  fakeResponse() captures what the route sends; it does not compute business rules.

4. Which files are part of the runtime flow for a successful checkout quote? (select all that apply)

• routes/checkoutRoute.js

  The route reads request data and sends the response.

• services/stockService.js

  The stock service checks availability and computes the subtotal.

• services/discountService.js

  The discount service applies coupon rules.

• data/items.js

  The data file supplies prices and stock counts.

• __tests__/checkoutRoute.test.js

  The test is specification evidence, not part of the runtime flow.

• services/receiptFormatter.js

  The receipt formatter is nearby code, but this route never imports or calls it.

5. When should a reader switch from top-down beacon reading to bottom-up tracing in this example?

• When a hypothesis depends on a risky branch such as the early 409 return or a coupon boundary.
• Immediately at the first line of every file, before reading tests.

  Starting with exhaustive tracing wastes attention before you know the behavior question.

• Never; descriptive names are always enough to prove branch behavior without reading the branch at all.

  Beacons guide attention, but behavior still needs verification when risk or ambiguity is present.

• Only after changing the code.

  Comprehension verification should happen before edits, especially around branches and boundaries.

6. A bug report says TEA3 can make tiny orders too cheap. Which explanation best fits the evidence?

• The discountFor(coupon, subtotal) name suggests subtotal matters, but the TEA3 branch returns 3 without checking subtotal.
• The checkStock() name sounds like it applies coupons, and the missing array proves it.

  checkStock() is a stock beacon, not a coupon beacon.

• The receiptFormatter.js file name proves receipts control discounts because receipt code usually knows final totals, coupons, and user-visible prices.

  A nearby receipt formatter is incidental because the route never imports it.

• The items array proves all coupons depend only on item names.

  The catalog data supplies prices and stock, but coupon policy is in the discount helper.

7. You suspect a coupon bug. Which routine move comes first?

• Read __tests__/checkoutRoute.test.js to learn what the contract says about coupons before reading any discount logic.
• Re-write the discount logic from scratch in a new file.

  Comprehension is reading, not writing.

• Read every other service file first to rule them out by exhaustion.

  Exhaustion is the strategy that fails the time budget.

• Run the entire test suite before forming any hypothesis.

  Running tests can reveal pass/fail, but the hypothesis must come first — otherwise you don’t know what a failure means.

1. Where is the pinning state owned?

• App.jsx, where useState(2) for pinnedId is called and passed down.
• LessonCard.jsx, which renders the Pin button and receives onPinLesson.

  LessonCard triggers the change, but the state belongs to the component that calls useState.

• styles.css, which defines the .pinned-card class used on the page.

  The CSS class is a presentation beacon. It does not own state.

• data.js, which provides the id field for every pinnable lesson.

  The IDs support pinning, but static data does not own the selected pinned lesson.

2. A user clicks Pin on a lesson. What is the correct interaction path?

• LessonCard calls onPinLesson(lesson.id), App sets pinnedId, then recomputes pinnedLesson and isPinned.
• ProgressSummary changes pinnedId after counting completed lessons, deciding which lesson deserves focus, and reordering cards.

  ProgressSummary receives lessons and computes a count. It is incidental to pinning.

• styles.css changes pinnedId when .pinned-card is applied.

  CSS can reflect pinned presentation, but it cannot update React state.

• data.js mutates the matching lesson to store isPinned: true.

  The code keeps pinnedId in React state rather than mutating static data.

3. Which file is incidental to the pinning concept, even though it is nearby?

• ProgressSummary.jsx
• App.jsx, because it owns the state

  App owns pinnedId, so it is central.

• LessonCard.jsx, because it renders the button

  LessonCard triggers the pin callback and displays the pin button, so it is central/supporting.

• data.js, because it provides lesson IDs

  data.js provides lesson IDs that pinning depends on, so it is supporting evidence.

4. Which beacons should appear in a central/supporting map for pinning? (select all that apply)

• pinnedId

  The state name is the central lexical beacon.

• onPinLesson={setPinnedId}

  This prop wiring is the event path from child to parent.

• isPinned={lesson.id === pinnedId}

  This derived prop connects state to display.

• .pinned-card

  This is supporting presentation evidence, not state ownership.

• doneCount from the progress summary

  doneCount belongs to progress summary, not pinning.

5. Which explanation best fits the pinning evidence?

• .pinned-card affects presentation, but implementation lives in pinnedId state and onPinLesson wiring.
• pinnedId is weak evidence because variable names never help in React.

  Names are useful beacons when they align with state and behavior.

• ProgressSummary must own pinning because progress and pinning both appear on the screen and both mention lesson status.

  Screen proximity is not concept ownership. The progress component does not receive or change pinnedId.

• data.js must own pinning because lesson IDs are stored there.

  IDs support the concept, but the selected pinned id is state in App.

6. In App.jsx, what role does the derived value pinnedLesson play?

• Holder / candidate — it stores the single lesson currently pinned (or undefined) so render code can branch on its presence.
• Accumulator — it sums or appends pinned lessons across renders.

  Only one lesson is pinned at a time; no accumulation.

• Stepper — it advances through lessons one at a time.

  Iteration happens inside LESSONS.find(...), but pinnedLesson is the result, not the loop variable.

• Flag — it is a boolean indicating whether any lesson is pinned.

  It is a lesson object (or undefined), not a boolean.

1. Which first-pass hypothesis comes from the tests?

• Records completions, returns status codes, can award a three-day streak badge.
• Renders a React progress dashboard for the lesson catalog.

  There is no JSX or browser rendering in this packet.

• Sends a completion email whenever a lesson completes and a streak badge appears.

  The email helper is nearby, but the tests never exercise it.

• Sorts the lessons in the data store by their title fields.

  The tests describe completions and badges, not lesson-title sorting.

2. Where is the missing-field 400 behavior implemented?

• completeLessonRoute() in routes/progressRoutes.js
• completeLesson() in services/progressService.js, because services often validate route input before saving

  The service receives already-validated fields in this design.

• saveCompletion() in data/progressStore.js

  The store saves records. It does not know about HTTP status codes.

• streakBadgeFor() in services/badgeService.js

  The badge helper only decides whether completion records earn a badge.

3. Which files are central runtime evidence for awarding the streak badge? (select all that apply)

• services/progressService.js

  The progress service coordinates saving records and asking for a badge.

• services/badgeService.js

  The badge service owns the three-day streak policy.

• data/progressStore.js

  The store supplies the completion records the badge service evaluates.

• services/emailPreview.js

  The email helper is nearby but never imported by the route or service.

• __tests__/progressRoutes.test.js

  The test specifies expected behavior, but it is not runtime implementation.

4. Which responsibility map best matches the implementation?

• Route: HTTP validation/status. Progress service: completion workflow. Store: persistence. Badge service: streak policy.
• Route: streak algorithm. Progress service: CSS rendering. Store: HTTP validation. Badge service: database connection.

  Those responsibilities do not match the imports or function bodies.

• Route: email preview. Progress service: test runner. Store: React state. Badge service: route params.

  Those concepts are either absent or assigned to the wrong files.

• Route: static data only. Progress service: no behavior. Store: all user-visible response decisions. Badge service: unused.

  The implementation clearly distributes behavior across route, service, store, and badge helper.

5. Which explanation best fits the completion flow?

• emailPreview.js sounds related, but central files do not import it and tests do not exercise it.
• badgeService.js is incidental because badges are just strings.

  The badge string is user-visible policy, and the helper is called by the progress service.

• progressStore.js is irrelevant because tests should be the only source of truth and runtime persistence is just setup.

  Tests specify behavior, but runtime code still implements it.

• completeLessonRoute() is unrelated because routes never affect behavior.

  The route reads request fields, validates them, and chooses HTTP response shape.

6. When the intended architecture and the actual code disagree, which artifact is the most reliable tiebreaker?

• The tests, because they encode the intended behavior in executable form.
• The most recent commit message, because the most recent change must be correct.

  Commit messages describe intent at one moment; intent drifts.

• The longest file, because lines of code track responsibility.

  Length is not a signal for responsibility ownership.

• The README, because documentation always describes the live system.

  READMEs are often the first artifact to go stale.

1. Kai does not receive the labs tab even though featureFlags.betaDashboard is true. Which hypothesis survives the smallest trace?

• canUseBetaDashboard() rejects Kai because Kai has no invite and is not on the pro plan.
• featureFlags.betaDashboard directly enables Labs for every verified user and overrides invite or plan policy.

  This is the misleading beacon: betaDashboard: true looks decisive, but no runtime path reads that property when adding tabs.

• welcomeBanner disables Labs when the banner is visible.

  welcomeBanner is read by the route, but it only decides the banner text in the JSON response.

• dashboardRoute() returns 404 for Kai.

  The test for Kai expects status 200, so the 404 hypothesis is contradicted immediately.

2. Which evidence best tests whether betaDashboard: true controls Kai’s Labs access?

• routes/dashboardRoute.js imports featureFlags, but only reads featureFlags.welcomeBanner.
• config/featureFlags.js contains the word beta, so it must own beta access.

  This answer follows the misleading beacon by trusting the filename and property name without checking who reads it.

• __tests__/dashboardRoute.test.js mentions a global beta flag, so tests are the implementation.

  Tests specify behavior; they do not execute in production as part of the route.

• data/users.js is short, so it cannot matter.

  Small files can carry central evidence. Here Kai’s betaInvite and plan values matter.

3. Which files are central runtime evidence for deciding whether labs appears? (select all that apply)

• services/dashboardService.js

  dashboardService.js adds the labs tab when access policy allows it.

• services/accessPolicy.js

  accessPolicy.js owns the invite/pro-plan/verification rule.

• data/users.js

  data/users.js supplies Kai’s betaInvite, plan, and verified values.

• config/featureFlags.js

  This is the realistic misleading beacon: the config file is imported, but its betaDashboard property is not read when tabs are built.

• __tests__/dashboardRoute.test.js

  The test is a specification beacon, but it is not runtime implementation.

4. Which smallest trace best tests the hypothesis that the global beta flag controls Labs access?

• dashboardRoute() → dashboardTabsFor() → canUseBetaDashboard(), then check whether featureFlags.betaDashboard appears on that path.
• featureFlags.js only, because the property name already answers the question.

  This keeps following the misleading beacon. A property name is a hypothesis, not proof.

• dashboardRoute() only, because routes always contain all business policy and imported config controls tabs there without any service call needing inspection.

  The route delegates tab construction to the service, so stopping at the route misses the policy.

• __tests__/dashboardRoute.test.js only, because tests replace the need to read implementation.

  Tests tell you what should happen, but the implementation trace explains where it happens.

5. Which final incident summary is strongest?

• Kai misses Labs because access policy requires verification plus invite or pro plan; betaDashboard is not read on the tab path.
• Kai misses Labs because the global beta flag is false in practice, even though the file says true and the route imports it for Kai.

  This answer invents a hidden override. The trace shows the flag is simply not part of the Labs access decision.

• Kai misses Labs because welcomeBanner takes priority over all other dashboard behavior.

  welcomeBanner appears in the response, but it does not control tabs.

• Kai misses Labs because tests intentionally hide the tab from free users.

  Tests describe the expected behavior; they do not hide tabs at runtime.

6. In Part 1’s Campus Feed sprint, the pinned field looked decisive but turned out irrelevant to that question. Which verification move generalizes from there to the betaDashboard flag here?

• Check where the cue sits in the runtime flow — what file imports it, and which path actually reads it.
• Always trust frozen config objects because immutability proves correctness.

  Immutability is unrelated to runtime relevance.

• Assume any name containing Dashboard implies dashboard tab control.

  Name overlap is the false-beacon trap, not the fix.

• Skip every flag-shaped value because flags are unreliable.

  Universal skepticism throws away beacons’ benefit; selective verification keeps it.