WEBVTT

1
00:00:00.000 --> 00:00:03.948
This challenge brings together
exact context, small changes,

2
00:00:04.006 --> 00:00:08.162
and evidence-based debugging. You
will start with a preserved failure,

3
00:00:08.406 --> 00:00:11.169
correct it, and explain why
the result is supported.

4
00:00:11.982 --> 00:00:15.906
Use the separate fault-fixture
checkpoint in a new exercise folder.

5
00:00:16.289 --> 00:00:20.654
It is based on checkpoint six and
contains one deliberate input error.

6
00:00:21.165 --> 00:00:25.635
Do not begin from a previously repaired
copy or from the final capstone project.

7
00:00:25.961 --> 00:00:28.828
Establish the starting state
before touching the file.

8
00:00:29.153 --> 00:00:33.472
Read the checkpoint note, the project
README, and the dependency manifest.

9
00:00:34.587 --> 00:00:36.061
The input is synthetic,

10
00:00:36.177 --> 00:00:39.428
and the policy at this stage
handles normal and fault states.

11
00:00:39.707 --> 00:00:42.342
Configurable alerts and
commands arrive later.

12
00:00:42.621 --> 00:00:45.779
The optional interface plan
is documentary context;

13
00:00:46.057 --> 00:00:49.448
it does not mean that a board or
sensor is connected to this run.

14
00:00:49.958 --> 00:00:54.301
Record the source identity and command
you are about to execute. Run the normal

15
00:00:54.370 --> 00:00:58.317
fixture through the supplied replay
wrapper and save the actual exit value.

16
00:00:58.596 --> 00:01:02.869
Preserve the full diagnostic along with
any output printed before the error.

17
00:01:03.194 --> 00:01:06.549
The seeded token is twenty-six
C at the second data event,

18
00:01:06.700 --> 00:01:08.708
which appears on the third file line.

19
00:01:08.987 --> 00:01:11.971
The format expects a numeric
token without that suffix.

20
00:01:12.296 --> 00:01:15.350
Write the symptom in a form
another engineer could reproduce.

21
00:01:15.675 --> 00:01:18.438
The replay rejects the
named file at the named line

22
00:01:18.566 --> 00:01:21.515
with an invalid-number
diagnostic and exit two.

23
00:01:21.840 --> 00:01:26.368
Avoid calling it a sensor failure, because
no physical sensor supplied this value.

24
00:01:26.693 --> 00:01:30.501
Also avoid describing the cause as
established until you have compared

25
00:01:30.535 --> 00:01:34.425
the input, format requirement,
and relevant adapter behavior.

26
00:01:35.028 --> 00:01:37.861
Propose at least two
candidate failure locations.

27
00:01:38.140 --> 00:01:40.090
The fixture might violate the grammar,

28
00:01:40.265 --> 00:01:43.271
or the parser might reject a
number the contract permits.

29
00:01:43.654 --> 00:01:46.847
Consider what observation would
distinguish those explanations.

30
00:01:47.230 --> 00:01:50.063
The previous lesson
demonstrated one useful pattern,

31
00:01:50.307 --> 00:01:53.627
but your report should still explain
why that pattern applies here.

32
00:01:54.011 --> 00:01:57.006
Repeating a command without a
prediction is less informative

33
00:01:57.029 --> 00:01:59.966
than a controlled experiment
tied to a specific question.

34
00:02:00.663 --> 00:02:05.005
Inspect the intended format. Temperature
units are defined by the field,

35
00:02:05.214 --> 00:02:09.301
and arbitrary letter suffixes are not
accepted inside the numeric token.

36
00:02:09.626 --> 00:02:13.271
Preserve the timestamp and event
type. Correct only the malformed

37
00:02:13.329 --> 00:02:17.218
temperature token to twenty-six
in your disposable exercise copy.

38
00:02:17.602 --> 00:02:21.189
There is no reason to change the
board target, parser, policy,

39
00:02:21.259 --> 00:02:24.962
or sensor acquisition to address
this input-format problem.

40
00:02:25.287 --> 00:02:27.842
Run the same fixture again
after the correction.

41
00:02:28.225 --> 00:02:31.278
The expected checkpoint-six
sequence is fault,

42
00:02:31.406 --> 00:02:34.610
normal, normal, normal,
normal, fault, fault, normal.

43
00:02:34.993 --> 00:02:39.231
The initial valid reading begins
recovery; the second completes it.

44
00:02:39.614 --> 00:02:43.329
A later deliberately nonfinite
input starts another fault,

45
00:02:43.503 --> 00:02:47.695
followed by two valid recovery
readings. Keep that modeled failure

46
00:02:47.729 --> 00:02:51.468
in the sequence instead of removing
it to make every line look normal.

47
00:02:51.793 --> 00:02:55.067
A successful process exit and
a fault state are compatible.

48
00:02:55.392 --> 00:02:59.502
The adapter can successfully interpret a
fixture event that intentionally supplies

49
00:02:59.595 --> 00:03:03.717
invalid sensor data. The policy
then reports the required fault.

50
00:03:04.228 --> 00:03:06.201
A malformed token is different:

51
00:03:06.526 --> 00:03:10.497
the adapter cannot interpret it under
the contract and rejects the row.

52
00:03:10.938 --> 00:03:14.700
Your explanation should keep those two
meanings of failure separate because

53
00:03:14.723 --> 00:03:17.138
their corrections belong
in different places.

54
00:03:17.951 --> 00:03:21.376
Use the stale-recovery fixture
for a nearby regression check.

55
00:03:21.654 --> 00:03:24.812
The last reading is still current
at timestamp four thousand,

56
00:03:24.928 --> 00:03:27.808
where its age is exactly
three thousand milliseconds.

57
00:03:28.191 --> 00:03:31.720
At four thousand and one, the
value is stale and unavailable.

58
00:03:32.103 --> 00:03:33.973
These are injected timestamps.

59
00:03:34.216 --> 00:03:38.675
They test the software rule,
not measured MCU or USB latency.

60
00:03:39.116 --> 00:03:41.879
State the boundary explicitly
in your evidence note.

61
00:03:42.204 --> 00:03:43.957
Follow the recovery events as well.

62
00:03:44.201 --> 00:03:46.987
The valid reading at five
thousand begins recovery,

63
00:03:47.138 --> 00:03:50.435
but missing input at six
thousand resets that progress.

64
00:03:50.946 --> 00:03:53.663
One valid reading at seven
thousand is insufficient,

65
00:03:53.837 --> 00:03:57.865
and the next at eight thousand allows
normal. Checking only that the first

66
00:03:57.912 --> 00:04:01.952
corrected number appears would leave
these nearby behaviors unexplained.

67
00:04:02.556 --> 00:04:06.805
A useful regression check protects
meaning beyond the single visible symptom.

68
00:04:07.316 --> 00:04:11.461
Attempt the documented firmware
build using the same selected target.

69
00:04:11.844 --> 00:04:15.327
The functional correction is in a
host fixture, but the challenge also

70
00:04:15.408 --> 00:04:19.124
asks you to demonstrate the recorded
project build path when the toolchain

71
00:04:19.170 --> 00:04:22.862
is available. Save the actual
result separately from replay.

72
00:04:23.466 --> 00:04:27.634
A verified final-release build is useful
reference evidence, but it does not

73
00:04:27.680 --> 00:04:30.501
replace the receipt for your
own checkout and environment.

74
00:04:31.198 --> 00:04:34.936
If the build cannot run, identify
the exact missing dependency

75
00:04:35.018 --> 00:04:38.501
or command failure and preserve
the completed investigation.

76
00:04:39.104 --> 00:04:42.030
Do not substitute an old
binary, a reference log,

77
00:04:42.088 --> 00:04:45.304
or a reassuring agent summary.
The correction can be ready

78
00:04:45.362 --> 00:04:49.054
for review while a required
execution gate remains open.

79
00:04:49.379 --> 00:04:53.234
The practical challenge is fully
verified only when its required checks

80
00:04:53.269 --> 00:04:56.809
have actual supporting evidence.
Inspect the final diff.

81
00:04:57.088 --> 00:05:00.234
The intended functional
change is one fixture token.

82
00:05:00.559 --> 00:05:05.145
Your report can add the cause, receipts,
recovery route, and limitations.

83
00:05:05.528 --> 00:05:08.652
A broad cleanup that changes
accepted syntax or alters

84
00:05:08.710 --> 00:05:11.438
policy makes the result harder to defend.

85
00:05:11.821 --> 00:05:15.757
If an assistant introduces those edits,
compare them with the brief and remove

86
00:05:15.850 --> 00:05:19.890
unrelated work before presenting the
correction as the challenge result.

87
00:05:20.273 --> 00:05:25.289
Add one sourced hardware fact and one
unperformed physical claim to the handoff.

88
00:05:25.672 --> 00:05:28.516
For example, the exact
example variant can be

89
00:05:28.562 --> 00:05:31.175
supported by its manufacturer
product reference.

90
00:05:31.500 --> 00:05:34.692
That does not establish the
revision of an unseen assembly,

91
00:05:34.901 --> 00:05:38.930
successful wiring, serial enumeration,
or measurement accuracy.

92
00:05:39.174 --> 00:05:41.960
The exercise is complete
without physical hardware,

93
00:05:42.053 --> 00:05:45.409
while those optional claims remain
outside the software evidence.

94
00:05:45.850 --> 00:05:49.054
Assemble the evidence bundle so
another engineer can follow it.

95
00:05:49.379 --> 00:05:51.481
Include checkpoint and source identity,

96
00:05:51.690 --> 00:05:55.858
the original diagnostic and exit,
the small diff, corrected replay,

97
00:05:56.009 --> 00:05:59.132
regression output, build
record, and a concise handoff.

98
00:05:59.457 --> 00:06:02.766
Describe expected output
separately from observed output.

99
00:06:02.975 --> 00:06:06.493
If an assistant drafts the report,
verify every claim against

100
00:06:06.528 --> 00:06:10.405
the preserved files rather than accepting
a fluent reconstruction of events.

101
00:06:10.847 --> 00:06:15.014
Finish with the module quiz and read the
explanations for any missed questions.

102
00:06:15.456 --> 00:06:19.206
The recommended score is four
out of five with unlimited retry.

103
00:06:19.531 --> 00:06:21.957
Quiz progress records
your learning interaction;

104
00:06:22.236 --> 00:06:24.953
it is not proof that a
compiler or replay ran.

105
00:06:25.278 --> 00:06:29.295
The practical result is the bounded
correction and its defensible evidence.

106
00:06:29.736 --> 00:06:33.974
You now have a method for moving
from exact context through one useful

107
00:06:34.043 --> 00:06:38.130
test to a result another engineer
can reproduce and assess.