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
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.
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.
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.
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.
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.
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.
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.
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.
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.
What actually matters
If the session goes sideways, make sure these three things happen regardless of everything else.
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.
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.
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.
For the SANSA team
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.
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.
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 →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.
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 →/src
/server
package.json → engines
Handoff package
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.
All 8 appendix files including quickstart, CONTRIBUTING, runbook, CI workflow, starter issues, and the architecture diagram in SVG and PNG.
Lists every placeholder in every file, and the exact terminal command to find the value from package.json.
Clone, install, start, test. Substitute {{node_version}}, {{dev_start_script}}, and {{test_script}} from package.json.
Branch naming, commit message style, PR checklist, and code review expectations. Paste the PR template into .github/pull_request_template.md.
Dev ops procedures: start/stop, clearing the cache, external service mocking, troubleshooting table, escalation contacts.
GitHub Actions: lint → test → typecheck on every PR to main. Copy to .github/workflows/ after updating the Node version.
8 GitHub Issues with titles, descriptions, acceptance criteria, labels, and effort estimates. Copy-paste into GitHub Issues.
Editable SVG system diagram and a 1920×1080 PNG export. Commit to /docs/architecture.svg and reference from README.md.
Post-session backlog
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.
Reproducible setup with exact Node version and npm scripts from package.json. Verified by someone who hasn't run the project before.
Branch naming, PR checklist (lint + tests + typecheck + screenshots), and code review expectations.
Gate PRs to main with lint, tests, typecheck. Template is in the ZIP — update Node version and script names.
Editable system diagram plus a companion architecture.md with design notes. Link from README.md.
Lightweight Express mock returning sample JSON so developers can work offline without live external services.
Top 3 most-used widgets — render, error state, loading state. Add coverage target to CI.
Consistent environment across machines and CI. Match engines field in package.json.
Top 10 questions new developers will ask: adding widgets, endpoints, testing, debugging, mock server, env setup.
Direct line to AfricaOne
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.
Prefer email?
bootcamp@africaoneconsult.com
— include 0ff1c8dbc00bb14b… in your subject line.