Assignments
Goal: twelve read-only exercises (15—45 minutes each) that train the four core skills: finding an API, tracing a data flow, explaining a control flow, and localizing a real bug. Each exercise has a model answer outline and a four-stage rubric. Use this for self-assessment or as the basis for mentor check-ins.
All exercises are read-only. Don’t try to fix anything. Train your reading muscles.
How to use this chapter
-
Pick one exercise per day in the first month.
-
Time-box at the suggested length. If you go over, stop and read the model answer.
-
Write your answer in your own words (1—2 paragraphs or a small diagram).
-
Rate yourself against the rubric — not as a grade, as a way to see what you missed.
Exercise 1 — Locate BendSetup (15 min, level 1)
Task. Find the BendSetup class. Tell me, in five lines:
-
Which file?
-
Which assembly?
-
What does its
Dumpmethod do? -
Which interfaces does it implement?
-
How is a new instance constructed?
Tools. Grep, file open.
Model answer. Src\Core\Bend\BendSetup.cs in Flux.Core. Dump (TextWriter) writes a per-line text representation of mounts (and clamp positions) used as the test contract. Implements INotifyPropChanged. Constructed via new BendSetup (BendTech owner) inside the bend-tooler — the parameterless constructor is for serialization.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Finds the file and one of: assembly / interfaces / construction |
| 2 | All five facts correct |
| 3 | Plus: explains why Dump matters for tests |
| 4 | Plus: identifies the [PostLoad] migration logic and what it does |
Exercise 2 — Trace a hem bend (30 min, level 2)
Task. Explain in half a page how a hem bend flows from geometry to the emitted Dump line.
Approach.
-
BendCore.cs: whichEBendKindvalues belong to hems? -
BendTech.cslines 32—46: how is a hem flex split into twoBendOps? -
BendOpconstructor (lines 36—54): how ismKindset for hem bends? What isOpenHemLimit? -
BendSetup.Dumplines 46—62: which fields end up in the text output?
Model answer.
-
Four hem kinds:
OpenHem,ClosedHem,OpenHemPrebend,ClosedHemPrebend. -
A hem flex gets
PhaseSplits = [1 - hemPrebend / 180]. The bend is then created twice (one per phase). -
In the constructor,
IsHemtriggers a switch onPhases[0]andRadius < OpenHemLimitto assign one of the fourEBendKindvalues. -
The dump emits per-mount tool name, piece composition, X position, optional Z, flip flag, and sensor pair.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Lists hem kinds and points at the phase split |
| 2 | Connects the phase split to two BendOps |
| 3 | Plus: explains the mKind decision tree |
| 4 | Plus: identifies the prebend-locked edge case (BendTech.cs lines 81—88) |
Exercise 3 — Find every place a setting cascade is used (30 min, level 2)
Task. Find at least three properties on BendOp whose value resolves through the Sheaf cascade. For each: which SH key, and where is the parent dictionary?
Approach. Grep BendOp.cs for Settings. and Sheaf. accesses. Cross-reference with Sheaf.cs for the SH enum.
Model answer. Examples:
-
BendSpeedresolvesSettings.RamVBend(cascades fromBendOp→BendTech→BendMachine). -
BGTransitionresolvesSheaf.EBGTransition.BGTransition(cascades similarly). -
BumpStepsand many others.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Identifies one property and its SH key |
| 2 | Three properties; can name the cascade direction |
| 3 | Plus: identifies a property that writes into the cascade and where it writes |
| 4 | Plus: contrasts with a property that bypasses the cascade — and explains why |
Exercise 4 — Explain BendTooler in twelve sentences (30 min, level 2)
Task. Read BendTooler.cs lines 16—80 and explain the auto-tooler’s pipeline in exactly 12 sentences. One sentence per phase, plus the inputs and outputs.
Approach. The pipeline is named in the comments next to the calls in DoTooling.
Model answer (skeleton). Inputs: a BendTech, plus EDoFlags and optional auxiliary setups. (1) PrepareForTooling resets state. (2) SetupBasicSequence does dead-reckoning. (3) TurnOnBumpBending switches large radii without tools to bump-bends. (4) DemoteCrashingTools downscores tools that collide in 2D. (5) UpdateToolScores favors broadly-liked tools. (6) DoToolerCore is the heart: final sequence + setups + BG. (7) Outputs: BendTech is now populated with Setups, per-BendOp tools, BG positions, and bending-aid states. (8—12) Notes on robotic-cell handling, manual-list extraction, validity ordering, and the success/failure return path.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Names 3+ phases correctly |
| 2 | Names all six phases in order |
| 3 | Plus: names inputs/outputs accurately |
| 4 | Plus: identifies one branch (e.g. mRobotic) that changes the pipeline |
Exercise 5 — Localize a real bug (45 min, level 3)
Task. Look at commit 4a5119dcb: "Case 45728: Changing the suction cup state no longer deletes adjusted waypoints."
Answer:
-
Which classes were touched?
-
Which subsystem (Bend root,
Ops\, UI, BCell)? -
What was the trigger of the bug (which property setter)?
-
Which test covers the case?
-
What was the smallest possible alternative fix?
Tools. git show 4a5119dcb, Grep.
Rubric. | Level | Criterion | |--|--| | 1 | Identifies the touched files | | 2 | Names the subsystem and the property setter | | 3 | Plus: identifies the test and the assertion | | 4 | Plus: proposes a defensible alternative fix and discusses trade-offs |
Exercise 6 — Map the dual crash engines (30 min, level 3)
Task. Compare BendOpCrash.cs and NBendCrash.cs. Specifically:
-
Which routine is the entry point of each?
-
What is the input contract — the same?
-
Which one is selected at runtime, and how?
-
Where do they diverge in their output?
Approach. Open both, look at their public methods. Search BendOpCrash and NBendCrash callers.
Model answer (sketch). Both expose check entry points called from BendOp validation. The selection is by a settings flag (look in BendOp.cs and Sheaf.cs for the relevant SH key). Outputs may differ in how they report partial failures.
Rubric. | Level | Criterion | |--|--| | 1 | Names the entry points | | 2 | Identifies the selection mechanism | | 3 | Plus: documents two output differences | | 4 | Plus: writes a recommendation: which one is the migration target, and what blocks the cutover |
Exercise 7 — Trace a feature bit through the codebase (30 min, level 2)
Task. Pick the Bend feature bit (from Notes\Tech\2013.FluxFlavors.ftx). Find:
-
Where the feature is declared.
-
Three places in the code where the feature is checked.
-
What changes (UI, logic, both) when the bit is off.
Tools. Grep "EFeature" or whatever the actual enum is — discover its name.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Finds the enum |
| 2 | Three call sites |
| 3 | Plus: classifies them (UI vs. logic) |
| 4 | Plus: explains how the B23 flavor is special re. this bit |
Exercise 8 — Read a golden file (30 min, level 2)
Task. Open X:\TData\Bend\Auto\Bend_04.geo and Bend_04.txt. For each non-empty line in the .txt:
-
Which property of which class produces this line?
-
Which test verifies it?
Approach. Match the Dump methods in BendSetup.cs and BendTech.cs to lines in the golden.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Maps three lines |
| 2 | Maps every line in the file |
| 3 | Plus: identifies one line that is conditional and explains the condition |
| 4 | Plus: predicts what would change in the golden if Settings.RamVBend were halved |
Exercise 9 — Discover a static singleton (15 min, level 1)
Task. Find three places where Flux uses the .It singleton convention. Are any of them stateful?
Approach. Grep "\.It\b" (with caution — this matches plenty of unrelated text; refine the regex).
Rubric.
| Level | Criterion |
|--|--|
| 1 | Finds three .Its |
| 2 | Identifies the type and the use case |
| 3 | Plus: confirms statelessness |
| 4 | Plus: finds one .It whose statelessness is questionable and discusses it |
Exercise 10 — Migration in real life (30 min, level 3)
Task. Pick three classes with [PostLoad] methods. For each:
-
What did the old shape look like? (Inferred from the migration code.)
-
Why was the change made? (Inferred from comments / commit log.)
-
What’s the highest
ObjVersionchecked?
Approach. Grep "[PostLoad]". Pick three. Read.
Rubric.
| Level | Criterion |
|--|--|
| 1 | Identifies three [PostLoad] methods |
| 2 | Reconstructs the old shape for each |
| 3 | Plus: traces the responsible commit for one of them |
| 4 | Plus: predicts what would happen if the migration were removed (i.e. if old files were loaded as-is) |
Exercise 11 — Locate a UI flow (30 min, level 2)
Task. Trace what happens when the user clicks "Add Regrip" on a selected bend in the UI. Specifically:
-
Which glob receives the click?
-
Which method is invoked?
-
Which method on the model is mutated?
-
Where is the rendering refreshed?
Approach. Start at Src\UI\Bend\BendOpUI.cs line 22 (the AddRegrip method).
Rubric. | Level | Criterion | |--|--| | 1 | Names the glob and the method | | 2 | Traces to a model-side mutation | | 3 | Plus: identifies the render refresh trigger | | 4 | Plus: explains how the same flow behaves in the composite (multi-select) case |
Exercise 12 — Read your tour and explain (45 min, level 3)
Task. Pick one tour from chapter 07 you haven’t done yet. Walk it. Then write a 200-word brief that another new joiner could read instead of doing the tour themselves.
Goal. This exercise tests teaching, not just understanding.
Rubric. | Level | Criterion | |--|--| | 1 | Brief is correct in fact | | 2 | Brief is teachable: a peer can follow it | | 3 | Plus: brief includes one "watch out for" | | 4 | Plus: brief is short enough to read in 90 seconds |
A learning calendar (months 1—6)
The original concept proposes a six-month pacing. Here is one way to phase the exercises.
| Month | Focus | Exercises |
|---|---|---|
1 |
Navigation, vocabulary, build mental model |
1, 7, 9 |
2 |
Data flow, control flow |
2, 3, 4 |
3 |
Real bugs, dual systems |
5, 6 |
4 |
Tests, persistence |
8, 10 |
5 |
UI flows, full traces |
11 |
6 |
Synthesis & teaching |
12 + a 30-minute tech talk |
By the end of month 6, you’ve earned the right to a small first PR — typically a test addition or a documentation fix. The reading muscles you’ve trained are the foundation for everything you’ll do thereafter.
Self-assessment heat-map
After working through the exercises, you should be able to fill in this matrix yourself:
| Skill | Where I am (1—4) |
|---|---|
Find an API by name |
|
Find an API by behavior |
|
Trace a data flow |
|
Trace a control flow |
|
Localize a bug from an issue number |
|
Read a test as a contract |
|
Read a golden file as a spec |
|
Recognize the architecture’s intentional asymmetries |
|
Distinguish stable from in-flight code |
|
Teach a tour to a peer |
Last updated: 2026-05-04. Exercises are pinned to current code paths; if a file moves, update or retire the exercise.