SANSA Bootcamp 1-Hour Handoff Session Snapshot: 0ff1c8…

share-sansa-engine
Technical Handoff

This site is your one-stop resource for the SANSA codebase handoff. It guides the presenter through the session, houses the full 30-slide deck, and stays live afterwards so SANSA can keep coming back as they get up to speed.

Presenter guide

What you're doing in this hour

The original plan was a full day of working groups producing documents together. You have one hour. That changes the goal: you're not here to produce the documents — you're here to give SANSA enough context to produce them independently, and to hand over everything they need to do that.

This site stays live after you leave. SANSA can use it to revisit every slide, re-read the walkthrough, download all the deliverables, and ask questions directly to AfricaOne engineers. Your job in the hour is to make that process feel approachable, not overwhelming.

Session length
60min
30 slides · 3 must-do outcomes · 1 handoff package
The three things that must happen before anyone leaves: a working quickstart.md with real commands filled in  ·  every deliverable has a named owner  ·  a follow-up date is on the calendar. Everything else is supporting material for these three outcomes.

Your 60-minute run of show

0:00
Open & set the snapshot rule Slides 1–2

Introduce yourself, fill in your name and today's date on slide 1 before the session. On slide 2, establish the snapshot rule clearly and firmly: "Everything we discuss today refers to commit 0ff1c8dbc00bb14b2… — if changes have been made since then, we are not talking about those today." This prevents the session derailing into half-finished work no one has context for.

0:05
Show the contract with the room Slides 3–5

Slide 3 is your commitment to the room — these exact deliverables will exist when you leave. Slide 4 is the adapted schedule (one hour, no working groups — just the walkthrough and handover). Slide 5 shows the commit SHA. Ask someone to screenshot it. Every document produced should contain that SHA.

0:10
Walk the architecture Slides 7–10

This is the educational core. You're not expecting people to memorise it — you're giving them just enough to know where to look when they're working alone later. The single most important thing to land: UI change → /src. Logic change → /server. New endpoint → controller + service + route registration, then write the test. Trace a user action through the architecture diagram on slide 10 out loud — from browser click all the way to database and back.

0:25
Show the code patterns Slides 11–15

Codebase tour (11–12): ask if anyone has the repo cloned and can read out their actual top-level directories. Correct the slide against what they see — that correction is itself useful documentation. Component skeleton (13–14): point out props at the top, render in the middle, widget registration at the bottom, and that tests mock the fetch call. Backend pseudocode (15): the most important line in the whole codebase is "no data access in controllers" — say that explicitly.

0:40
Walk through the deliverables package Slides 20–21, 26–28

You're not doing working groups today, so skip the group task slides and jump to the deliverables. Show slide 21 (the full list) and confirm the room knows what's in the ZIP. Open slide 27 (quickstart template) and walk through it — point at every {{placeholder}} and explain exactly where to find the value. The most important substitution: {{node_version}} from package.json → engines. If someone in the room can do that live and verify the app starts, do it now.

0:50
Name every owner — do not skip this Slide 24

This is the most important slide of the session. Go through each deliverable out loud and get a name against it before anyone stands up. "Who owns quickstart.md? …Great. Who opens the 8 GitHub issues? …Excellent." If you skip this, the ZIP ends up in someone's downloads folder and nothing ever gets committed. Write names on the slide live if you can.

0:55
Set the follow-up date and close Slides 25, 30

Read the wrap-up checklist on slide 25 like a flight checklist — confirm each item is green before closing. Then: agree on a follow-up review date before people leave the room. Two weeks from today is the target — owners review the ZIP, commit what's approved, open the 8 starter issues. Slide 30 is the close — confirm the ZIP is being delivered to the SANSA contact today or within 24 hours.

Which slides to actually show

In a full day you'd present all 30 slides. In an hour, focus on these. The appendix slides (26–29) are here for SANSA to read at their own pace after the session.

SlidesWhat they coverIn-session?
1–5Title, purpose, goals, agenda, snapshot commitPresent
6Section divider — architecturePresent
7–10Architecture overview, frontend, backend, full diagramPresent
11–15Codebase tour, UiEngine skeleton, backend pseudocodePresent
16Section divider — working groupsSkip
17–20Dev workflow, CI YAML, docs priorities, group tasksReference only
21Full deliverables listPresent
22–25Starter issues, risks, owners, wrap-up checklistPresent
26–29Appendix — quickstart/CONTRIBUTING previews, QA criteriaLeave for SANSA
30Closing — contact, ZIP delivery confirmationPresent

Full deck

The 30-slide presentation

Use the keyboard (← →) or tap left/right side of the slide to navigate. Press N for speaker notes, F for fullscreen, Space to auto-advance. On mobile, swipe left or right.

Slide 1
1 / 30
Speaker notes — Slide 1

What actually matters

The three outcomes that define success

If the session goes sideways, make sure these three things happen regardless of everything else.

01

A working quickstart.md with real commands

The template in the ZIP has placeholders. The highest-value action of the entire handoff is getting one person in the room to open package.json, find the engines field and the script names, and substitute them in. If the app then starts successfully, that's a verified quickstart. Everything else is commentary.

What to ask "Can someone open package.json right now and tell me what version of Node is in the engines field?"
02

Every deliverable has a named owner before anyone leaves

Slide 24 has the owner table. Go through it out loud — "who owns quickstart.md? Who opens the 8 GitHub issues?" — and get eye contact confirmation from each person. A ZIP without owners is a ZIP that never gets committed. This is the single most common reason handoffs fail.

What to do Fill in the names on slide 24 live in front of the room, or write them on a whiteboard everyone can photograph.
03

A follow-up date is on the calendar before anyone leaves

Two weeks from today is the target. Owners have had time to review the ZIP, commit what's approved, and open the 8 starter issues. The follow-up session is the checkpoint that confirms the handoff actually happened. Without a date, there is no handoff — just a meeting.

What to say "Before we close — what date works for a 1-hour follow-up in two weeks? Let's get it in the diary right now."

For the SANSA team

How to use this site after the session

The session is one hour. Getting comfortable with the codebase takes longer. Here's how to use what's on this page to keep making progress on your own.

Step 1

Start with the quickstart

Download the ZIP, open README_APPENDIX.txt first — it lists every placeholder and the exact terminal command to find each value. Then work through quickstart.md line by line. If you hit a problem, document the error in the Troubleshooting section.

Go to deliverables →
Step 2

Re-watch the architecture walkthrough

Jump to slide 7 in the viewer and work through slides 7–15 at your own pace. The speaker notes under each slide contain the full explanation the presenter gave — read those as you go through. Toggle "Notes" in the viewer controls.

Open presentation viewer →
Step 3

Open the 8 starter issues in GitHub

The starter-issues.md in the ZIP is copy-paste ready. Open GitHub Issues, paste each one in, apply the labels, assign to the named owners. Start with issues #1 and #2 — adding quickstart.md and CONTRIBUTING.md. These unblock everyone else.

See the 8 issues →
Step 4

Ask when you're stuck

The question form below goes directly to AfricaOne engineers. Include the file path, the error message, and what you've already tried. Reference the snapshot commit in your subject so we know which codebase state you're working with.

Ask a question →
The one thing to remember about the codebase
UI bug or new chart? Edit UiEngine widgets in /src
Wrong calculation or data? Edit the service layer in /server
New API endpoint needed? Controller + service + route registration — then write the test
Environment not starting? Check Node version matches package.json → engines

Handoff package

Everything in the ZIP

Start with README_APPENDIX.txt — it tells you which placeholders remain in each file and the exact terminal command to find the value. Files marked Has placeholders need values from package.json before committing.

📦

Complete appendix package

All 8 appendix files including quickstart, CONTRIBUTING, runbook, CI workflow, starter issues, and the architecture diagram in SVG and PNG.

⬇ Download ZIP
README_APPENDIX.txt Read first

Lists every placeholder in every file, and the exact terminal command to find the value from package.json.

quickstart.md Has placeholders

Clone, install, start, test. Substitute {{node_version}}, {{dev_start_script}}, and {{test_script}} from package.json.

CONTRIBUTING.md Has placeholders

Branch naming, commit message style, PR checklist, and code review expectations. Paste the PR template into .github/pull_request_template.md.

runbook.md Has placeholders

Dev ops procedures: start/stop, clearing the cache, external service mocking, troubleshooting table, escalation contacts.

ci-lint-test.yaml Has placeholders

GitHub Actions: lint → test → typecheck on every PR to main. Copy to .github/workflows/ after updating the Node version.

starter-issues.md Ready to use

8 GitHub Issues with titles, descriptions, acceptance criteria, labels, and effort estimates. Copy-paste into GitHub Issues.

architecture.svg / .png Ready to use

Editable SVG system diagram and a 1920×1080 PNG export. Commit to /docs/architecture.svg and reference from README.md.

Slides PPTX + PDF Ready to use

The full 30-slide branded deck with embedded speaker notes. Also viewable directly on this page.

Post-session backlog

8 starter issues for GitHub

Open these in GitHub Issues within one week of the session. Start with #1 and #2 — they unblock everything else. Full templates with acceptance criteria are in starter-issues.md.

P1docs0.5d
#1 — Add quickstart.md

Reproducible setup with exact Node version and npm scripts from package.json. Verified by someone who hasn't run the project before.

P1docs0.5d
#2 — Add CONTRIBUTING.md

Branch naming, PR checklist (lint + tests + typecheck + screenshots), and code review expectations.

P2ci0.5d
#3 — Add GitHub Actions CI workflow

Gate PRs to main with lint, tests, typecheck. Template is in the ZIP — update Node version and script names.

P2docs0.5d
#4 — Add architecture.svg to /docs

Editable system diagram plus a companion architecture.md with design notes. Link from README.md.

P2infra2d
#5 — Create mock server for ROI/dataset APIs

Lightweight Express mock returning sample JSON so developers can work offline without live external services.

P3test2d
#6 — Add unit tests for key UiEngine components

Top 3 most-used widgets — render, error state, loading state. Add coverage target to CI.

P3chore0.5d
#7 — Pin Node version with .nvmrc

Consistent environment across machines and CI. Match engines field in package.json.

P4docs1d
#8 — Add developer FAQ

Top 10 questions new developers will ask: adding widgets, endpoints, testing, debugging, mock server, env setup.

Direct line to AfricaOne

Ask our engineers

Have a question about the codebase, the architecture, the deliverables, or anything from the session? Submit it here and an AfricaOne engineer will respond — usually within one business day.

0 / 1000

Question received

We'll reply to within one business day.

Prefer email? bootcamp@africaoneconsult.com — include 0ff1c8dbc00bb14b… in your subject line.