--- name: bootcamp-preparation description: 'Bootcamp preparation (first, mandatory module): choose Core vs Customized, select which modules to run, set verbosity and programming language, and initialize version control (git, no prompt). Use right after the onboarding WELCOME preface, before the entity-resolution primer / Module 1. Use when the bootcamper says "prepare the senzing bootcamp".' license: Apache-2.0 compatibility: Requires the Senzing MCP server and Docker. metadata: author: Senzing version: 0.5.3 templateRelease: 0.5.3 templateSkill: bootcamp-preparation --- # Bootcamp Preparation (first module, mandatory) > **MCP grounding (mandatory β€” applies to this entire skill).** Every Senzing fact you present β€” > SDK method and attribute names, config options, error codes, and entity-resolution specifics β€” > MUST come from the Senzing MCP tools, never from training data, memory, or speculation. > **Pre-response checklist:** if a reply contains any Senzing specific, you MUST have called an MCP > tool this turn to obtain it; if not, stop and call it first. This has the same precedence as a β›” > gate. The full rule and tool routing are the "MCP-first invariant" in > `../bootcamp-onboarding/ground-rules.md`. Follow `../bootcamp-onboarding/ground-rules.md` throughout (πŸ‘‰ one-question-at-a-time, MCP-first, file placement, checkpointing). This is the **first, mandatory module**. The onboarding preface (`../bootcamp-onboarding/onboarding-flow.md`) hands off here after the WELCOME banner, the overview, and the "any questions" step; this module consolidates the core setup in one place: the Core-vs-Customized path choice, per-module selection, level of detail (verbosity), programming language, and version control. (The software-integration and deployment-target questions are asked in Module 1 Phase 2, not here, per INV-097.) Bootcamp preparation is a **lightweight setup module**: it presents its own banner and closes with a bootcamper-facing recap of the setup choices (INV-099), but is otherwise exempt from the per-module completion apparatus (no journey map, no before/after framing, no `docs/bootcamp_recap.md` section, and it is not added to `modules_completed`). It cannot show a journey map yet β€” it is the module that *produces* the selection that drives the journey map from the first content module onward. Do the administrative parts quietly (INV-012); ask the setup questions one πŸ‘‰ at a time. Present the banner, then run the steps in order. ```text ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🧰🧰🧰 BOOTCAMP PREPARATION 🧰🧰🧰 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ## The module list (source of truth for selection and the journey map) The bootcamp is this ordered sequence. "Required" modules are always included and cannot be deselected; "Optional" modules are chosen in Customized mode. A module with **Requires** cannot run unless its prerequisite is also included. The **State token** column is the exact value to write into `selected_modules` and `modules_completed`. Copy it; never derive a token from a display name. | # | Module | Rule | State token | Maps to | |---|---|---|---|---| | 1 | Bootcamp preparation | Required | `bootcamp_preparation` | this module | | 2 | Entity Resolution Concepts | Optional | `entity_resolution_concepts` | `module-00-entity-resolution-concepts` | | 3 | Discover the Business Problem | Required | `business_problem` | `module-01-business-problem` | | 4 | SDK setup | Required | `sdk_setup` | `module-02-sdk-setup` | | 5 | System verification | Optional β€” Requires "SDK setup" | `system_verification` | `module-03-system-verification` | | 6 | Truth Set visualization | Optional β€” Requires "System verification" | `truthset_visualization` | `module-03b-truthset-visualization` | | 7 | Data collection | Required | `data_collection` | `module-04-data-collection` | | 8 | Data Quality, Mapping, and Transformation | Required β€” Requires "Data collection" | `data_quality_mapping` | `module-05-data-quality-mapping` | | 9 | Data processing | Required β€” Requires "Data Quality, Mapping, and Transformation" | `data_processing` | `module-06-data-processing` | | 10 | Query, Visualize and Discover | Required β€” Requires "Data processing" | `query_visualize_discover` | `module-07-query-visualize-discover` | | 11 | Bootcamp graduation | Required β€” Requires "Query, Visualize and Discover" | `graduation` | `graduation` | Because **Bootcamp graduation is required** and it requires "Query, Visualize and Discover", which requires "Data processing", which requires "Data Quality, Mapping, and Transformation", which requires "Data collection", that whole downstream chain is always included. So the genuinely deselectable modules are exactly three: **Entity Resolution Concepts**, **System verification**, and **Truth Set visualization** (and deselecting System verification forces deselecting Truth Set visualization, which requires it). ## 0. Read the saved preferences first β€” honor them, do not ask (INV-133) β›” **Before Step 1, read `config/bootcamp_preferences.yaml` once.** Every capture question below is governed by the same rule, and it applies to **all** of them, not just model guidance: > A setup preference already recorded in `config/bootcamp_preferences.yaml` MUST be honored, its > capture question MUST NOT be asked, and the saved value MUST NEVER be overwritten with a > recommended default (INV-133). This is what lets a returning bootcamper settle a recurring choice permanently β€” put `programming_language: Python` and `verbosity: {preset: minimal}` in the file before starting and those two questions never appear again β€” without changing the default for anyone else. Asking someone what they already told you is an INV-006 violation, and it is most galling on a second run. | Preference | Question it suppresses | Honor when | |---|---|---| | `path` | Step 1 | `core`; or `customized` **and** a valid `selected_modules` list is also saved | | `verbosity` | Step 3 | a recognized preset (`minimal`/`concise`/`standard`/`detailed`) | | `programming_language` | Step 4 | any non-empty value | - **`path: customized` with no `selected_modules`** is not honorable β€” the selection would be undefined. Ask Step 1 (and Step 2) in that case, and say why in one line. - **An unrecognized or unreadable value is not honorable.** Fall through to the question rather than guessing what was meant. - **Nothing here is a question.** Read the file quietly (INV-012) and hold each honored value for the Step 6 consolidated write, unchanged. - **`name`, `os`/`arch` and `git_init` are detected, never asked** (INV-134/INV-061/INV-095), so they have no question to suppress β€” but a saved `name` is still honored rather than re-detected. β›” **State every honored value once in the Step 7 recap**, marked as coming from the saved file, so the bootcamper can see what is in force and correct it. A silently-honored preference is indistinguishable from a question you forgot to ask. ## 1. Choose the bootcamp path β›” Skip this step entirely when `path` is honorable per Step 0. Present this pinned πŸ‘‰ question, verbatim (INV-056), and end the turn on it: > πŸ‘‰ **Which bootcamp would you like? Reply with a number:** > > 1. **Core bootcamp** *(recommended)* β€” every module, in order, from preparation through graduation. > 2. **Customized bootcamp** β€” you choose which optional modules to include (required modules are always in). This is a β›” gate: wait for the real choice, do not assume one (INV-007). - **Core** β†’ **every** module is selected, in order β€” including all three deselectable ones. "Optional" describes what Customized may drop; it never means Core omits it. **Hold** `path: core` and this exact ordered list for the consolidated write in Step 6, then skip Step 2: ```yaml selected_modules: - bootcamp_preparation - entity_resolution_concepts - business_problem - sdk_setup - system_verification - truthset_visualization - data_collection - data_quality_mapping - data_processing - query_visualize_discover - graduation ``` β›” Copy that list verbatim β€” all eleven tokens. Do **not** rebuild it by translating the module table's display names into tokens: that derivation is what silently dropped `entity_resolution_concepts` from a Core run, so the primer never appeared and the bootcamper was never told a module had been skipped (INV-014 permits only *requested* skips). - **Customized** β†’ go to Step 2. ## 2. Select modules (Customized only) Show the full module list above (as statements, so the bootcamper sees everything and what is always included) β€” present only the module **names** and their required/optional status; do NOT render the internal "#" or "Maps to" columns (catalog numbers and skill-directory names are internal β€” INV-079/INV-012). Then end the turn on this single pinned πŸ‘‰ question, verbatim (INV-056): > πŸ‘‰ **Which optional modules would you like to include? Reply with the numbers from the list below, comma-separated β€” reply "none" for just the required modules:** > > 1. **Entity Resolution Concepts** β€” a short primer on how entity resolution works. > 2. **System verification** β€” end-to-end checks that Senzing works on your machine. > 3. **Truth Set visualization** β€” an interactive web app of the resolved Truth Set (requires System verification). Apply the prerequisite rules when recording the selection: - All Required modules are always included. Name them exactly as the module table above spells them β€” Bootcamp preparation, Discover the Business Problem, SDK setup, Data collection, **Data Quality, Mapping, and Transformation**, Data processing, **Query, Visualize and Discover**, Bootcamp graduation β€” never an abbreviation, since these names are what the bootcamper reads here and in every later journey map and transition question (INV-079). - If the bootcamper chooses **Truth Set visualization** (3) without **System verification** (2), tell them Truth Set visualization requires System verification, and include System verification too (do not silently drop the choice; state what you included and why). - "none" β†’ include only the Required modules. **Hold** `path: customized` and the resolved ordered `selected_modules` list for the consolidated write in Step 6. Keep the list in module order so the journey map and transitions follow it. ## 3. Level of detail (verbosity) β›” Skip this step entirely when `verbosity` is honorable per Step 0. **Before asking, tell them the choice is not permanent** β€” that they can change it any time ("change verbosity", or "more code walkthroughs"). This has to come **first**: INV-251 requires the πŸ‘‰ question to end the turn, so nothing can follow it, and a reassurance delivered after the answer cannot inform the choice it was meant to inform. > πŸ‘‰ **How much detail would you like in the bootcamp output? Reply with a number:** > > 1. **minimal** β€” near-zero output: only questions, results, and required banners/summaries; no explanations, code walkthroughs, or step recaps. Best for experts who want to move fast. > 2. **concise** β€” minimal explanations, brief recaps. Best for experienced developers. > 3. **standard** *(recommended)* β€” balanced what-and-why, block-level code summaries. > 4. **detailed** β€” full explanations, line-by-line walkthroughs, SDK internals. Wait for the answer, then **hold** the chosen verbosity for the consolidated write in Step 6 β€” do not write it now (INV-058: one setup write, not one per gate). Each preset maps its five `categories` to a single level β€” `minimal` = 0, `concise` = 1, `standard` = 2, `detailed` = 3. When persisted, the `verbosity` key will look like (here, `standard`): ```yaml verbosity: preset: standard categories: explanations: 2 code_walkthroughs: 2 step_recaps: 2 technical_details: 2 code_execution_framing: 2 ``` For `minimal`, every category is `0`. `minimal` reduces only *explanatory* output; it NEVER suppresses required output β€” every πŸ‘‰ question (INV-005), gate, module banner (INV-079), end-of-module summary (INV-032), and the recap (INV-048) still appear. This is not a β›” gate, but it is still a πŸ‘‰ question the bootcamper answers (INV-007): wait for their reply. If they explicitly decline to choose (e.g. "no preference", "you pick", "skip"), treat that decline as choosing the recommended `standard` and say so β€” never assume a level before they have replied. (The can-change-it-any-time reassurance belongs **before** the question, above β€” not here.) ## 3a. Model guidance β€” no question (retired) β›” **There is no model-guidance question and no `model_guidance` preference (INV-137).** Ask nothing here and write nothing for it. Model/effort guidance behaves one way for everyone: at each module start and graduation start the guide surfaces the stage's recommendation, and **when that recommendation differs from what the bootcamper is running right now** β€” compared per dial β€” it pauses on the pinned switch question followed by the pinned "Are you done modifying the model and effort?" gate; when it already matches, it is a one-line statement. β›” **The comparison is against the live session, never against the previous stage's recommendation.** Four consecutive stages share one recommendation, so reading it stage-to-stage would suppress the switch question through the whole opening of a Core run β€” for precisely the bootcamper who is already running something stronger, which is the common case rather than an edge case. `../bootcamp-onboarding/ground-rules.md` β†’ "Best-value model/effort prompt" is **authoritative** for the comparison, including the per-dial rule for a value that cannot be read; do not restate that procedure here β€” two copies is how this drifted in the first place (INV-300). This step number is kept so the surrounding step numbering and every cross-reference to Steps 4-7 stay stable. Skip straight from Step 3 to Step 4. (A previous design asked the bootcamper to choose between `advisory`, `off` and `prompt` and persisted the answer. That question is retired: INV-137 supersedes INV-119 and INV-120, restoring the unconditional INV-063/INV-069 behavior. Do **not** reintroduce the question, and do not honor a stale `model_guidance` key left in an old preferences file.) ## 4. Programming language selection (gate) β›” Skip the **programming-language question** when `programming_language` is honorable per Step 0. Platform detection and name detection below still run either way β€” they are detections, not questions. - **Detect the platform first (do not ask).** Determine the OS and architecture from the environment/system context (else run `uname`/`systeminfo`), and state it in one line ("Detected macOS on Apple Silicon"). Hold the detected `os`/`arch` for the Step 6 consolidated write so Module 2 can reuse it instead of re-asking (INV-061). **Only if detection is genuinely unavailable or ambiguous**, ask this pinned fallback question, verbatim (INV-056), and hold the answer: πŸ‘‰ **Which operating system and processor architecture are you using? Reply with a number:** 1. Linux (x86-64) 2. Linux (ARM64) 3. macOS (Apple Silicon) 4. macOS (Intel) 5. Windows (x86-64) *(Internal: end the turn on this single πŸ‘‰ question and wait β€” INV-251.)* - **Detect the bootcamper's name silently (do not ask).** Best-effort: read a display name from `git config user.name` (else the environment). If found, hold it as `name` for the Step 6 consolidated write so the recap and graduation report can address the bootcamper by name; if none is available, leave `name` unset. Never ask for it and never block on it. - Call **`get_capabilities`** on the Senzing MCP server for the supported programming languages. It is the tool that carries that fact, and in the server's model the language set is **platform-independent**: Python, Java and C# official, Rust and TypeScript/Node.js community-maintained wrappers (re-verified 2026-08-12, server 1.32.9). What varies per platform is the install *mechanism*, not which languages exist β€” so do **not** route this lookup to `sdk_guide`: `sdk_guide(topic='install', platform=…)` returns install commands, env vars, paths and gotchas and **no language list at all**, and with no `platform` it returns the platform decision tree rather than a language one β€” `needs_input.parameter` is `platform`, offering five operating systems (both halves re-checked live, same server and date, `platform='linux_apt'` and no-platform). The one genuine platform↔language constraint the server does state β€” the Python SDK is supported on Linux only, with Docker or WSL2 as the route on macOS/Windows β€” is carried in the annotation rules below and in Module 2's routing, which is where it belongs. - Always say "**programming language**", never the bare word "language" (avoids confusion with spoken languages). - Present the MCP-returned options as a **numbered list**, rendered **directly beneath the πŸ‘‰ question, as part of it** β€” the same shape Steps 1–3 use, and required by `../bootcamp-onboarding/ground-rules.md` β†’ the πŸ‘‰ protocol. These options cannot be pinned, because they come from the server at runtime; that changes whether the text is fixed, never where it goes. The question says "reply with a number", so the numbers must follow it (INV-224). β›” **Sort the two kinds of prose in this step by where they belong, because it mixes them.** - **Platform-wide statements are informational β†’ BEFORE the πŸ‘‰**, with the detected-platform line. The Linux sentence is one: it says the same thing about every option, so it is a fact about the platform, not an annotation on a choice. - **Per-option annotations belong ON their option**, inside the numbered list β€” never hoisted above the question, where they separate the numbers from the instruction to use them. Annotate an option **only where the Module 2 routing rules actually distinguish it** β€” that is, where the platform forces a language into a container β€” so the trade-off is visible at the decision point. The rules are the numbered list under "Routing rules (apply in order)" in `../module-02-sdk-setup/SKILL.md`; the ordinals below index that list, so re-check them there rather than trusting the numbers if that list is ever edited. All four platform cases: - **macOS Apple Silicon:** per-option β€” "Python β€” runs via Docker (the SDK is Linux-only); Java / C# β€” native." (routing rules 1 and 3) - **macOS Intel:** platform-wide β€” every language runs via Docker; there is no native Intel-Mac install. (rule 2) Say it once, above the πŸ‘‰. - **Windows:** per-option β€” for Python, name the **cost**, not just the mechanism: choosing it here means installing and running a Linux environment (Docker Desktop **or** WSL2), which needs administrator rights and, for WSL2, a reboot. Other languages need Scoop, else Docker. (rules 1 and 4) - β›” **On Windows and macOS the Python annotation states the price, not the routing.** "Runs via Docker" is true and is not what the choice needs: it names a mechanism where the Bootcamper needs to know they are agreeing to a system-level install. A Bootcamper who picks Python here and meets that two modules later, at SDK setup, has paid for a reversible decision at the one point where reversing it was free β€” reported 2026-08-18 by a Windows 11 Bootcamper who lost the time to a WSL2 install and a reboot mid-bootcamp. - β›” **Relay every environment route the server returns, not just Docker.** Take them from `sdk_guide(topic='install', platform=, language='python')` at gate time rather than from this file (INV-080): on **server 1.33.0, 2026-08-21** its `compatibility_notes` give **two** β€” *"Pick a different environment β€” use Docker or WSL2 to run Python inside a Linux container"* β€” alongside two language alternatives (*"Java and C# are officially supported on macOS and Windows; Rust and TypeScript are community-supported on all platforms"*). The Bootcamper above chose WSL2, which is the server's own second option and which this gate did not offer. ⚠️ **On macOS, suppress the WSL2 half:** the `platform='macos_arm'` response carries the same sentence, and WSL2 does not exist on macOS. Reported upstream as a bug 2026-08-21; until it is corrected, do not relay that clause on a Mac. - **Linux:** platform-wide β€” the rules distinguish nothing per language, so all supported languages install natively via the platform's package manager (rule 5). Say that once above the πŸ‘‰ rather than annotating each option with the same thing, and do **not** invent per-language install detail to fill the space. β›” **Do not manufacture an annotation the routing rules do not support.** Those rules (`../module-02-sdk-setup/SKILL.md`, "Determine Platform") resolve a *platform*, not per-language install mechanics, so on Linux there is genuinely nothing to differentiate. Precise install commands come from `sdk_guide(topic='install', platform=…, language=…)` in Module 2, at the point they are needed β€” not from memory here (INV-080). If the MCP server flags a language as discouraged or unsupported on the platform, relay that and suggest alternatives. The resulting shape (Linux, where the platform statement is platform-wide). The question line is written once, below β€” this is its position, not a second copy of it: ```text Detected platform: Linux (apt). All supported programming languages install natively via the platform's package manager. 1. Python β€” official SDK 2. Java β€” official SDK … (one line per language `get_capabilities` returned, in its order) ``` On macOS Apple Silicon and Windows the same shape holds, with the routing note on the option it applies to β€” on Windows, `1. Python β€” needs a Linux environment: Docker Desktop or WSL2 (admin rights; WSL2 also a reboot)`, and on macOS the same without the WSL2 half β€” and nothing platform-wide hoisted above except the detected-platform line. πŸ‘‰ **Which programming language would you like to use for the bootcamp? Reply with a number:** - This is a β›” gate whose wording is pinned β€” present the πŸ‘‰ question above verbatim (INV-056); wait for the bootcamper's real choice. Do NOT assume or say "I'll go with X." - **Hold** the chosen programming language for the Step 6 consolidated write (do not write it now). ## 5. Initialize version control (automatic, no prompt) Do this quietly (administrative, not narrated β€” **no πŸ‘‰ question**, INV-095). Check whether the working directory is already a git repository. `git` behaves identically on Linux, macOS, and Windows; rely on the command's **exit status**, not a shell-specific stderr redirect: ```bash git rev-parse --is-inside-work-tree ``` - **Already a repo** (command succeeds / prints `true`): **hold** `git_init: existing`. - **Not a repo** (command fails / non-zero exit): run `git init` automatically as a quiet administrative action and **hold** `git_init: true`. Do not ask. - **`git` not installed** (command not found): skip initialization, **hold** `git_init: unavailable`, and continue β€” never block on version control. `git init` is an action (run it now when applicable), but the `git_init` value is **held** for the single consolidated write below β€” no separate write (INV-058). ## 6. Consolidated preference write (once, quietly) Persist all setup choices collected in Steps 1-5 to `config/bootcamp_preferences.yaml` in a **single** write (INV-058) β€” `path` (`core`/`customized`), `selected_modules`, `verbosity`, the programming language, the detected `name` (if any), the detected `os`/`arch`, and the `git_init` outcome. **No `model_guidance` key** β€” that preference is retired (INV-137). (The software-integration and deployment-target answers are NOT collected here β€” they are asked in Module 1 Phase 2 and persisted there, per INV-097.) (`path` replaces the old `track` preference; downstream readers β€” graduation, the recap header β€” read `path`.) This is the only setup write of this module; the gates only held their answers, so the bootcamper sees one diff instead of one per gate (INV-012). Do not narrate this administrative write. ```yaml path: core # or: customized selected_modules: # ordered; drives the journey map and transitions - bootcamp_preparation - entity_resolution_concepts # always in Core; omitted only if Customized drops it - business_problem - sdk_setup - system_verification # always in Core; omitted only if Customized drops it - truthset_visualization # always in Core; omitted only if Customized drops it - data_collection - data_quality_mapping - data_processing - query_visualize_discover - graduation ``` β›” **Before handing off, verify the list you are about to write** (internal self-check, not bootcamper-facing). When `path: core`, confirm `selected_modules` holds all eleven tokens from Step 1 in that order; when `path: customized`, confirm it holds the eight Required tokens plus exactly the optional ones resolved in Step 2, in module order. If a module is missing, correct it **now** β€” after the handoff in Step 7 the next module has already started and the omission is invisible. Also record the selection into `config/bootcamp_progress.json` where module-completion and the journey map read it (a single batched write, INV-012): the ordered `selected_modules` and the `current_module` pointing at the first content module. ## 7. Recap the setup and hand off to the first selected content module **First, recap the setup choices to the bootcamper** (INV-099): read them back from the consolidated write as a concise, lightly-highlighted summary β€” analogous to a per-module recap, but Bootcamp preparation stays apparatus-exempt, so this is a bootcamper-facing recap **only**: it is NOT added to `modules_completed` and NOT written as a `docs/bootcamp_recap.md` section (INV-092). Respect the active verbosity preset β€” shorten under `concise`, and keep it to a single line under `minimal`. Every line states the value **in force**, whether it came from a question this run or from the saved file (INV-133). Append ` β€” from your saved preferences` to any line whose question Step 0 suppressed, so an honored preference is visible rather than looking like a question you skipped: ```text βœ… Bootcamp preparation complete ──────────────────────────────── β€’ Path: Core (all modules) β€” or Customized (selected modules) β€’ Modules: {ordered selected module names, separated by "; "} β€’ Detail level: {verbosity}{ β€” from your saved preferences} β€’ Programming language: {programming language}{ β€” from your saved preferences} β€’ Version control: {git initialized | existing repo | git unavailable} β†’ Next: {first content module name} ``` β›” **Two details in that template are load-bearing; do not "tidy" either one.** - **The module list is separated by semicolons, not commas.** Two display names contain internal commas β€” *Data Quality, Mapping, and Transformation* and *Query, Visualize and Discover* β€” so a comma-separated Core list reads as **fourteen** modules instead of eleven. This is the same reason `generate_recap_pdf.py --check --expect-modules` takes a semicolon-separated list. The names themselves must stay verbatim (INV-079), so the separator is the only place this can be fixed. - **The label is "Programming language", never the bare "Language"** β€” the rule stated in Step 4 above, and it applies to every bootcamper-facing line, not only to the question. β›” **Under `minimal`, the six lines COLLAPSE to one β€” they are not dropped.** The one-line budget and the per-line provenance marker collide exactly when they matter most: a returning bootcamper who pre-seeded `path`, `verbosity` and `programming_language` needs all three marked, and has one line to put them on. Merge with `; ` and attach each marker **inline to its value**, per `../bootcamp-onboarding/ground-rules.md` β†’ Verbosity. The module list compresses to a count, since the names were just given in the preface; a count is not a module number, so INV-079 is unaffected. This exact shape: ```text βœ… Bootcamp preparation complete β€” Path: Core (all 11 modules) β€” from your saved preferences; Detail level: minimal β€” from your saved preferences; Programming language: Java β€” from your saved preferences; Version control: git initialized. β†’ Next: Entity Resolution Concepts ``` Nothing here is optional under `minimal`: the values in force, their provenance markers, and the next-module pointer are all required output, and `minimal` reduces only *explanatory* output. When Step 0 honored anything, close the recap with one line telling them how to change it: "Edit `config/bootcamp_preferences.yaml` to change any saved choice, or just tell me." Then hand off to the first module in `selected_modules` after `bootcamp_preparation`: - If **Entity Resolution Concepts** is selected β†’ invoke `module-00-entity-resolution-concepts` (it runs the primer directly; its skip/keep gate has been retired β€” inclusion is driven by this selection). - Otherwise β†’ invoke `module-01-business-problem` to begin Module 1 β€” **Discover the Business Problem** (name it to the bootcamper, never "Module 1"). The selected numbered modules then run in order per `selected_modules`, each ending with the standard module completion process in `../bootcamp-onboarding/module-completion.md`, and the journey map (per `ground-rules.md`) shows only the selected modules.