Lab-11: Emerging Trends in Software Engineering

1. Tools. Git and your team repository; a C++20 compiler (GCC 13, Clang 17 or MSVC 2022 or later) with CMake 3.28+; a Markdown editor with Mermaid preview (VS Code with a Mermaid preview extension, or mermaid.live); the GitHub CLI gh (optional, for the metrics in Task 5). Depending on the proof of concept you choose in Task 3: an AI code assistant allowed by the course policy, clang-tidy, a sanitizer-capable compiler (GCC or Clang on Linux, macOS or WSL; MSVC supports /fsanitize=address), an SBOM generator or a text editor for a hand-written SBOM, or a browser with developer tools.

   git checkout main && git pull
   git checkout -b lab-11
   # the project must build and pass its tests before you start
   cmake -S . -B build && cmake --build build && ctest --test-dir build
   mkdir -p lab11/briefs lab11/poc lab11/decisions lab11/submission

2. Case-study brief. The box below is the product definition for this lab; there is no other product document to read. Wherever a step says "the case-study brief", it means this box.
   Case-study brief: ITC Club Hub

   Purpose

   An application for student clubs at the Institute of Technology of Cambodia. Teams analyse and model the full system as a web and mobile application and implement its core in C++20: domain model, business rules and a command-line front end with CSV or JSON file storage.

   Users

   Club leaders register a club and an administrator approves it · clubs publish events (title, date and time, location, capacity, description) · students browse, register, cancel and receive a reminder · organisers check students in at the door and see attendance · administrators see a monthly activity report across clubs.

   Business rules

   Capacity cannot be exceeded (a waiting list is a Should feature) · a student cannot register twice for the same event · cancellation closes 24 hours before the start · past events cannot be registered for · only approved clubs can publish events.

   Personal data

   Student ID, name, email, phone (optional), club membership, attendance records. None of it may appear in prompts to external tools, in PoC logs or in demo data: use made-up records.

   Code base

   Namespace clubhub; classes Club, Event, Student, Registration, enums ClubStatus and RegistrationStatus, RegistrationService (registerStudent, cancel, checkIn), repository interfaces with CSV implementations. Layout: CMakeLists.txt, src/, include/clubhub/, tests/ (GoogleTest via FetchContent), .github/workflows/ci.yml.

   Rhythm

   Sprint 1 in weeks 9 and 10, Sprint 2 in weeks 11 and 12. This lab: week 13. Project submission and a 10-minute demo in week 14; final exam in week 15. Roles: one Product Owner, a Scrum Master rotating each sprint, the rest Developers.

   Week-14 submission

   The team repository with all lab artifacts, the working increment (a tagged release that builds and passes CI), a short report and a 10-minute demonstration. Individual contribution is checked through the Git history and peer review.

3. Inputs from earlier labs. This lab uses everything the team built. If one input is incomplete, use the fallback and note it in lab11/README.md; do not stop to repair the earlier lab.

   Lab	Input	Used in	Fallback if missing
   01	Team charter, roles, repository	Task 5 (retrospective, contributions)	List names and roles at the top of lab11/README.md.
   02	Application type, quality attribute scenarios, context diagram	Tasks 1, 2, 4 (criteria), 5 (report: Problem)	CLI core now, web and mobile target; top attributes: usability on phones, availability during check-in, privacy.
   03	Privacy review, licence choice, accessibility checklist	Tasks 1 and 3 (licence, personal data), 5	Personal data list from the brief; MIT licence assumed; state it.
   04	Process choice and iteration plan	Task 5 (report: Process)	Scrum with two-week sprints as in the brief.
   05	SRS, user stories, prioritised backlog, traceability matrix	Task 5 (report: Requirements, demo stories)	The five business rules and five user groups of the brief.
   06	Use case, class, sequence, activity and state diagrams	Task 5 (report: Models)	Class names from the brief; one state machine for RegistrationStatus.
   07	Sprint 1 board, velocity, daily log, review and retrospective	Task 5 (retrospective metrics)	Count closed issues per sprint on the GitHub Projects board.
   08	.github/workflows/ci.yml, branch protection, PR reviews	Tasks 2, 3 (CI job), 5 (quality evidence)	Local build and test commands with their output pasted.
   09	Test plan, GoogleTest suites, coverage report, static analysis, bug reports	Tasks 3 (uncovered functions), 5 (quality evidence)	ctest summary plus a gcovr text summary produced now.
   10	Change request, refactoring, release tag, CHANGELOG.md, maintenance plan	Tasks 2 and 5 (report: Release)	git tag --list and the last merged PRs.

4. Deliverable folder. Create these files as you go; every task fills some of them.

   clubhub/                                  # your team repository
   ├── CMakeLists.txt  src/  include/clubhub/  tests/  .github/workflows/ci.yml
   ├── lab01/ … lab10/                       # earlier labs, read-only here
   └── lab11/
       ├── briefs/README.md                  # Task 1: member → trend
       ├── briefs/<trend-slug>.md            # Task 1: one brief per member
       ├── radar.md                          # Task 2: table of 8-12 entries
       ├── radar.mmd  (or radar.svg)         # Task 2: diagram
       ├── poc/README.md                     # Task 3: question, criteria, time-box
       ├── poc/findings-log.md               # Task 3
       ├── poc/…                             # Task 3: artefacts of the chosen option
       ├── decision-matrix.md                # Task 4
       ├── decisions/ADR-011-<slug>.md       # Task 4 (next free number)
       ├── submission/report-outline.md      # Task 5
       ├── submission/demo-script.md         # Task 5
       ├── submission/retrospective.md       # Task 5
       ├── README.md                         # Task 5: record what changed
       ├── oss/contribution-log.md           # Challenge (or contribution-plan.md)
       └── learning-plans/<name>.md         # Challenge: one per member

5. Conventions. Every Markdown file starts with a title, a version, a date and its author(s). Sources are cited with author or organisation, title, URL, publication date and access date. Any AI use is declared in the file or pull request where it happened. Commit after each step with a message such as Lab-11 task 2: radar entries 1-6.

Goal

Each member researches one trend from Chapter 11 and writes a one-page brief (what it is, maturity, evidence, risks, relevance to Club Hub) with sources, separating claims from evidence. The briefs feed the radar in Task 2.

Steps

1. As a team, assign one trend per member without duplicates and record it in lab11/briefs/README.md (table: member, trend, file, reviewer). Choose from: AI code assistants, AI-enabled features (for example natural-language event search), low-code and no-code platforms, serverless functions, microservices versus modular monolith, platform engineering, SBOM and supply chain security, sanitizers and memory-safe languages, green software, progressive web apps (PWA) for Club Hub.
2. Create lab11/briefs/<trend-slug>.md from the starter (for example sbom.md, ai-code-assistants.md). Keep it to one page: about 400 to 600 words plus the source list.
3. Fill the five sections: What it is in your own words; Maturity with a suggested radar ring and a hype-cycle position, each with a reason; Evidence as a claims table; Risks and costs including the effect on the quality attributes from Lab-02; Relevance to Club Hub with one concrete use and one reason not to adopt it now.
4. Find at least three sources, at least one of them primary (official documentation, a standard, a regulation text, a peer-reviewed study, or an engineering report from a named organisation). Record the access date. Vendor marketing and social media posts count as claims, never as evidence.
5. In the evidence table, label every claim with its source number, source type and your judgement of its strength (strong, medium, weak), with one reason.
6. Open a pull request for your brief; the reviewer named in briefs/README.md leaves one question and one suggested improvement, and you answer them in a follow-up commit.
7. Commit under your own name: git commit -m "Lab-11 task 1: brief on SBOM". Check with git log --format="%an %s" -- lab11/briefs that every member appears.

Starter template

# Trend brief: <trend name>
Author: <name> · Reviewer: <name> · Version 1.0 · Date: 2026-11-__

## 1. What it is
(3 to 5 sentences in your own words; no copied definitions)

## 2. Maturity
- Suggested radar ring for Club Hub: Adopt / Trial / Assess / Hold, because ...
- Hype-cycle position (a thinking tool, not a measurement): ..., because ...
- Who uses it in production (named organisations or projects): [n]

## 3. Evidence
| # | Claim | Source | Source type | Strength and why |
|---|-------|--------|-------------|------------------|
| 1 |       | [1]    | standard    | strong: ...      |
| 2 |       | [2]    | vendor page | weak: marketing  |

## 4. Risks and costs
- Security and privacy:
- Money, learning time, lock-in:
- Effect on our quality attributes (Lab-02):

## 5. Relevance to ITC Club Hub
- One concrete use:
- One reason not to adopt it now:

## Sources (accessed 2026-11-__)
1. <author or organisation>, "<title>", <URL>, <publication date>
2.
3.

AI use: none / "used <tool> to summarise source 2; checked against the original"

Expected output (excerpt of a good brief)

## 2. Maturity
- Suggested ring: Assess, because the formats are stable but our C++
  build (FetchContent) is poorly detected by generators [3].
- Hype-cycle position: slope of enlightenment: two formats are
  standardised (SPDX is ISO/IEC 5962:2021 [1]) and regulation now
  refers to SBOMs [2]; the early "an SBOM makes you secure" talk
  has faded.

## 3. Evidence
| # | Claim                                   | Source | Type        | Strength |
|---|-----------------------------------------|--------|-------------|----------|
| 1 | SPDX is an international standard       | [1]    | standard    | strong: primary text |
| 2 | EU law asks manufacturers for an SBOM   | [2]    | regulation  | strong: primary text |
| 3 | "Our tool finds every C++ dependency"   | [4]    | vendor page | weak: our test found 1 of 2 |

Show hints

Acceptance checklist

Goal

Build the team's own technology radar: 8 to 12 entries placed in the rings Adopt, Trial, Assess and Hold across four quadrants, each with a one-sentence rationale grounded in your repository or a Task 1 brief, drawn as a Mermaid or SVG diagram.

Steps

1. Collect candidates in two groups: what you already use (read CMakeLists.txt, .github/workflows/ci.yml, tests/, the Lab-09 static analysis setup) and what the Task 1 briefs propose.
2. Choose 8 to 12 entries. Place each in one quadrant (Techniques, Tools, Platforms, Languages and frameworks) and one ring. Every ring has at least two entries and every quadrant at least one.
3. Write the table in lab11/radar.md: number, entry, quadrant, ring, one-sentence rationale, source. The rationale cites evidence ("46 tests green in CI since Sprint 1", "brief sbom.md: generator missed FetchContent dependencies"), not opinion.
4. Put at least one entry on Hold with a "not now, because" reason, and at least one entry you already use in Adopt.
5. Draw the radar in lab11/radar.mmd from the starter (one subgraph per ring), or as lab11/radar.svg with concentric rings. The numbers in the diagram match the table.
6. The Product Owner reviews the rings from the client's point of view and adds a line Reviewed by <PO name>, <date>: <one comment> at the end of radar.md.
7. Commit: git commit -m "Lab-11 task 2: technology radar v1.0".

Starter

# Technology radar · ITC Club Hub · v1.0 · 2026-11-__
Rings: Adopt = our default · Trial = real but low-risk use, review date
       Assess = study or PoC only · Hold = do not start new work (now)

| # | Entry      | Quadrant                 | Ring  | Rationale (one sentence, evidence) | Source          |
|---|------------|--------------------------|-------|------------------------------------|-----------------|
| 1 | GoogleTest | Languages and frameworks | Adopt | TODO                               | tests/, Lab-09  |
| 2 |            |                          |       |                                    |                 |

Reviewed by <PO name>, <date>: <comment>

%% lab11/radar.mmd: one subgraph per ring, numbers match radar.md
flowchart LR
  subgraph ADOPT["Adopt"]
    A1["1 · GoogleTest"]
  end
  subgraph TRIAL["Trial"]
    T1["TODO"]
  end
  subgraph ASSESS["Assess"]
    S1["TODO"]
  end
  subgraph HOLD["Hold"]
    H1["TODO"]
  end
  ADOPT ~~~ TRIAL ~~~ ASSESS ~~~ HOLD

Expected output (shape only; your entries and reasons will differ)

flowchart LR
  subgraph ADOPT["Adopt"]
    A1["1 · GoogleTest"]
    A2["2 · clang-format"]
  end
  subgraph TRIAL["Trial"]
    T1["4 · ASan in CI"]
    T2["5 · ..."]
  end
  subgraph ASSESS["Assess"]
    S1["7 · SBOM per release"]
    S2["8 · ..."]
  end
  subgraph HOLD["Hold"]
    H1["10 · microservices"]
    H2["11 · ..."]
  end
  ADOPT ~~~ TRIAL ~~~ ASSESS ~~~ HOLD

Show hints

Acceptance checklist

Goal

Answer one question about one trend from your radar's Trial or Assess ring with a small, throwaway experiment on Club Hub. Write the question and success criteria first, stop when the 4 hours are up, and keep a findings log that someone else could repeat.

Choose one option

Steps

1. Before any work, commit lab11/poc/README.md with: option, the one question, at least two measurable success criteria, participants, start and end time of the 4-hour box, and what is out of scope.
2. Create the branch poc/<slug> (for example poc/sanitizers) from lab-11; the PoC code lives there.
3. Work in short steps and add an entry to lab11/poc/findings-log.md at least every 45 minutes: time, who, what you tried, the result (paste the command and its relevant output), what surprised you, time used.
4. Option A only: never paste real student data into the assistant; apply the review checklist (understanding, correctness, tests, security, licence) to every suggestion and record the decision per test in poc/ai-review.md; label the PR ai-assisted.
5. Measure what the success criteria name, with the same method before and after (for example gcovr -r . --filter src/csv_event_repository.cpp).
6. Stop when the box ends. If you want more time, write an entry "extend by N minutes, because ..." agreed by the team; otherwise conclude with what you have.
7. Write the conclusion at the end of the log: answer to the question (yes / no / partly), the measured numbers against each criterion, the biggest surprise, and a recommended ring for Task 4. Merge PoC code to lab-11 only if it passes CI; otherwise link the branch.

Starter code

# PoC · <option letter and name> · v1.0 · 2026-11-__
Question: <one question, answerable with yes / no / partly>
Success criteria (decided before starting):
  1. <measurable, e.g. "at least 5 accepted tests">
  2. <measurable, e.g. "coverage of the file +10 points">
Time-box: 4 h · start 2026-11-__ 13:00 · end 17:00
Participants: <names> · Branch: poc/<slug>
Out of scope: <what you will not try>

# Option C: opt-in sanitizer build (GCC and Clang)
option(CLUBHUB_SANITIZE "Build with AddressSanitizer and UBSan" OFF)
if(CLUBHUB_SANITIZE AND NOT MSVC)
  add_compile_options(-fsanitize=address,undefined -fno-omit-frame-pointer)
  add_link_options(-fsanitize=address,undefined)
endif()
# use: cmake -S . -B build-asan -DCLUBHUB_SANITIZE=ON -DCMAKE_BUILD_TYPE=Debug

# Option C: .clang-tidy at the repository root (start small, then widen)
Checks: >
  -*,
  bugprone-*,
  cppcoreguidelines-owning-memory,
  cppcoreguidelines-pro-bounds-pointer-arithmetic,
  modernize-use-nullptr,
  performance-*
HeaderFilterRegex: 'include/clubhub/.*'
WarningsAsErrors: ''

# Findings log · PoC <option>
| Time  | Who | Tried (command) | Result (output excerpt) | Surprise | Used |
|-------|-----|-----------------|-------------------------|----------|------|
| 13:00 |     |                 |                         |          | 0:00 |

## Conclusion (at the end of the box)
Answer: yes / no / partly
Criterion 1: target ... measured ... met / not met
Criterion 2: target ... measured ... met / not met
Biggest surprise:
Recommended ring for Task 4: Adopt / Trial / Assess / Hold

Expected output (excerpt of a findings log, option C)

| 13:40 | Dara  | cmake -DCLUBHUB_SANITIZE=ON ...; ctest  | 1 of 38 tests fails:
|       |       |   heap-use-after-free in CsvEventRepository::findByTitle   |
|       |       | Surprise: the same test passes in the normal build   | 0:40 |
| 14:30 | Sokha | clang-tidy -p build src/*.cpp           | 23 warnings: 17 bugprone-narrowing,
|       |       |   4 owning-memory, 2 performance; 3 are real defects | 0:50 |
...
Criterion 2: extra CI time target <= 3 min, measured 2 min 10 s: met

Show hints

Acceptance checklist

Goal

Turn the PoC result into a decision the team can defend: compare at least three options with a weighted decision matrix, check how sensitive the result is to the weights, and record the outcome (adopt, trial or hold) with its consequences in a decision record.

Steps

1. Write the decision question at the top of lab11/decision-matrix.md (for example "How should Club Hub produce its SBOM from now on?").
2. List at least three options; one of them must be "keep the current way" (or "do nothing").
3. Choose 4 to 6 criteria (fit to the problem, effort, team skills, risk, cost, maturity, effect on a quality attribute from Lab-02). Agree the weights so that they sum to 100 %, and commit the weights before scoring.
4. Score every option 1 to 5 per criterion; each score gets a one-line justification that points to evidence (a findings log entry, a brief, a measurement).
5. Compute each weighted score and show the arithmetic. Then run a sensitivity check: move the largest weight up or down by 10 points (rebalance the others), recompute, and state whether the winner changes.
6. Write lab11/decisions/ADR-011-<slug>.md (use your next free number): context, options, decision (adopt, trial or hold, and for which scope), at least two positive and two negative consequences, follow-up actions as GitHub issue links, review date. The Product Owner accepts it.
7. Update the entry's ring and rationale in radar.md and commit: git commit -m "Lab-11 task 4: ADR-011 SBOM in CI (trial)".

Starter templates

# Decision matrix · <question> · v1.0 · 2026-11-__
Weights committed in: <commit hash> (before scoring)

| Criterion | Weight | A: keep current | B: ... | C: ... |
|-----------|--------|-----------------|--------|--------|
|           |   %    |                 |        |        |
| Total     | 100 %  |                 |        |        |

## Justifications
- A / criterion 1: score ... because ... (evidence: poc/findings-log.md 14:30)

## Arithmetic
A = w1×s1 + w2×s2 + ... = ...

## Sensitivity check
Changed <criterion> from ... % to ... %; ... % taken from ...
New scores: A = ..., B = ..., C = ...; winner changes: yes / no

# ADR-011: <title>
Status: proposed / accepted · Date: 2026-11-__ · Deciders: <names>
## Context
## Options considered
## Decision
Adopt / Trial / Hold: ... (scope: ...)
## Consequences
+ ...
+ ...
- ...
- ...
## Follow-up
- [ ] #<issue> ...
Review date: ...

Expected output (excerpt, different question from yours)

Question: How should Club Hub produce its SBOM from now on?
| Criterion               | Weight | A keep: none | B by hand | C tool in CI |
| Fit (finds our deps)    |  35 %  |      1       |     4     |      3       |
| Effort per release      |  25 %  |      5       |     2     |      4       |
| Risk of going stale     |  25 %  |      1       |     2     |      5       |
| Team skills             |  15 %  |      5       |     5     |      3       |
A = 0.35×1 + 0.25×5 + 0.25×1 + 0.15×5 = 0.35 + 1.25 + 0.25 + 0.75 = 2.60
B = ...   C = ...
Sensitivity: fit 35 % → 45 % (effort 25 % → 15 %): winner unchanged
Decision: C, Trial until the week-14 release; hand-check FetchContent deps

Show hints

Acceptance checklist

Goal

Assemble the team's own work from Labs 01 to 11 into a report outline with evidence, a rehearsed 10-minute demo script and a project retrospective, then record what changed in lab11/README.md. Next week you only write and present; the structure and the evidence are ready.

Steps

1. Report outline in lab11/submission/report-outline.md with seven sections: 1 Problem, 2 Requirements, 3 Models, 4 Process, 5 Quality evidence, 6 Release, 7 Lessons learned. For each section write 3 to 5 key points, the evidence (repository paths plus commit, tag or PR number), an owner and a target length. Every member owns at least one section.
2. Collect the numbers for section 5 from your repository and paste the commands with their output into the outline: test count, coverage, CI pass rate on main, open and closed defects, release tags.

   ctest --test-dir build | tail -n 3
   gcovr -r . --txt | tail -n 3
   gh run list --branch main --limit 50 --json conclusion \
     --jq 'group_by(.conclusion) | map({(.[0].conclusion): length}) | add'
   gh issue list --label bug --state all --limit 100 --json state --jq 'length'
   git tag --list --sort=-creatordate | head -n 5

3. Demo script in lab11/submission/demo-script.md: a timed table for exactly 10 minutes (segment, presenter, what the audience sees, exact CLI commands, time). Walk through the main user stories on made-up data: register and approve a club, publish an event, register students until the capacity is reached, a cancellation before and after the 24-hour limit, check-in, the monthly report. Add a data reset step (copy of the demo CSV files) and a backup plan (screen recording or screenshots) in case the live run fails.
4. Rehearse once with a timer; write the actual time per segment next to the planned one and cut until the total is at most 10:00.
5. Retrospective in lab11/submission/retrospective.md, facilitated by the current Scrum Master; everyone writes their notes before the meeting. Include: a Mermaid timeline of the project, a metrics table (velocity Sprint 1 and Sprint 2, PRs merged, tests, coverage, CI pass rate, defects), what went well, what did not, start / stop / continue, an individual contribution table (git shortlog -sne main plus each member's own description of their role) and three action items for future projects.
6. Record what changed: create lab11/README.md with the table of this lab's files, the inputs reused from Labs 01 to 10 with their version, tag or commit (and any fallback you used), and a change-log row. Commit, push and open the pull request.

Starter templates

# Project report outline · ITC Club Hub · <team> · v0.1 · 2026-11-__

| # | Section            | Key points (3-5) | Evidence (path + commit/tag/PR) | Owner | Length | Status |
|---|--------------------|------------------|---------------------------------|-------|--------|--------|
| 1 | Problem            |                  | lab02/..., lab03/...            |       | 1 p    | todo   |
| 2 | Requirements       |                  | lab05/...                       |       | 2 p    | todo   |
| 3 | Models             |                  | lab06/...                       |       | 2 p    | todo   |
| 4 | Process            |                  | lab04/..., lab07/...            |       | 1 p    | todo   |
| 5 | Quality evidence   |                  | lab08/..., lab09/..., CI runs   |       | 2 p    | todo   |
| 6 | Release            |                  | lab10/..., tag v...             |       | 1 p    | todo   |
| 7 | Lessons learned    |                  | submission/retrospective.md     |       | 1 p    | todo   |

## 5. Quality evidence: raw numbers
(paste the commands of step 2 and their output here)

# Demo script · 10 minutes · v0.1
Reset: cp demo-data/*.csv data/     Backup: submission/demo-backup.mp4

| # | Segment                        | Presenter | Command / what is shown | Plan | Actual |
|---|--------------------------------|-----------|-------------------------|------|--------|
| 1 | Problem and team               |           | one slide               | 1:00 |        |
| 2 | Club registered and approved   |           | ./clubhub ...           | 1:00 |        |
| 3 | Event published, capacity full |           |                         | 2:00 |        |
| 4 | Cancellation, 24-hour rule     |           |                         | 1:30 |        |
| 5 | Check-in and monthly report    |           |                         | 1:30 |        |
| 6 | Quality evidence (CI, tests)   |           |                         | 1:30 |        |
| 7 | Technology decision (Lab-11)   |           | radar + ADR             | 1:00 |        |
| 8 | Handover to questions          |           |                         | 0:30 |        |
|   | Total                          |           |                         | 10:00|        |

# Project retrospective · v1.0 · facilitator: <Scrum Master>

## Timeline
(Mermaid timeline: one period per phase, events from your own history)

## Metrics
| Metric | Sprint 1 | Sprint 2 | Source |
|--------|----------|----------|--------|

## Went well / did not go well
## Start / Stop / Continue
## Individual contributions
| Member | Commits (git shortlog) | Main contributions in own words |
## Action items for future projects (3)

# Lab-11 · Emerging trends and submission preparation
| File | Purpose | Author(s) |
|------|---------|-----------|

## Inputs reused
| Input | Version / tag / commit | Fallback used? |
|-------|------------------------|----------------|

## Change log
| Date | Version | Change | By |
|------|---------|--------|----|

Expected output (shape of the retrospective timeline; your periods and events come from your history)

timeline
  title Project timeline (shape only)
  Weeks 1-4 : Charter : Quality scenarios : Privacy review : Process choice
  Weeks 5-8 : SRS and backlog : UML models : Checkpoint 1
  Weeks 9-10 : Sprint 1 : CI pipeline
  Weeks 11-12 : Sprint 2 : Tests and coverage : Release
  Week 13 : Radar and PoC : Submission prep

lab11/README.md, change log row:
| 2026-11-__ | 1.0 | Lab-11: briefs, radar, PoC (option C), ADR-011, report outline,
|            |     | demo script (rehearsed 9:40), retrospective | whole team |

Show hints

Acceptance checklist

1. Repository layout at the end of this lab:

   clubhub/
   ├── CMakeLists.txt  src/  include/clubhub/  tests/  .github/workflows/ci.yml
   ├── lab01/ … lab10/
   └── lab11/
       ├── README.md  radar.md  radar.mmd  decision-matrix.md
       ├── briefs/        README.md + one brief per member
       ├── poc/           README.md  findings-log.md  + option artefacts
       ├── decisions/     ADR-011-<slug>.md
       ├── submission/    report-outline.md  demo-script.md  retrospective.md
       └── oss/  learning-plans/          (challenge)

2. Self-check from a clean clone before you open the pull request:

   cmake -S . -B build && cmake --build build && ctest --test-dir build
   ls lab11 lab11/briefs lab11/poc lab11/decisions lab11/submission
   git shortlog -sne -- lab11          # every member appears
   grep -rniE "@(student\.)?itc\.edu|password|api[_-]?key" lab11 || echo "no personal data or secrets found"

3. Branch lab-11, pull request titled Lab-11 – <team name>, reviewed by at least one other member, CI green. Merge before the week-14 submission: the submission is built from main.