WEBVTT

1
00:00:00.000 --> 00:00:04.006
We are ready to run a small firmware
behavior and make one reviewable reporting

2
00:00:04.064 --> 00:00:07.976
change. Open checkpoint five
in a new exercise folder.

3
00:00:08.359 --> 00:00:12.016
This version has synthetic input
and normal or fault policy.

4
00:00:12.400 --> 00:00:16.707
It does not yet have configurable alerts,
hysteresis, or threshold commands.

5
00:00:17.218 --> 00:00:20.759
A high temperature can remain normal
at this stage because those later

6
00:00:20.828 --> 00:00:23.150
capstone requirements
are deliberately absent.

7
00:00:23.591 --> 00:00:27.516
Begin with the baseline, before
editing source. From the project root

8
00:00:27.562 --> 00:00:30.627
in PowerShell, run the replay
command with the normal fixture.

9
00:00:30.952 --> 00:00:33.994
Save the actual exit value
immediately after the command.

10
00:00:34.435 --> 00:00:37.825
The supplied wrapper compiles the
host executable and then runs it.

11
00:00:38.208 --> 00:00:42.365
If compilation fails or the executable
cannot start, diagnose that condition

12
00:00:42.412 --> 00:00:45.976
before interpreting a policy result
that has not actually been produced.

13
00:00:46.301 --> 00:00:48.437
The normal fixture contains eight events.

14
00:00:48.646 --> 00:00:52.802
The expected states begin fault, then
normal for the following valid readings.

15
00:00:53.081 --> 00:00:56.007
An intentionally nonfinite
input later produces fault,

16
00:00:56.216 --> 00:00:58.805
and two fresh valid
readings complete recovery.

17
00:00:59.084 --> 00:01:02.834
This is a successful replay when the
process exits zero and the expected

18
00:01:02.892 --> 00:01:06.108
sequence occurs. A fault state
can be correct application

19
00:01:06.143 --> 00:01:09.103
behavior; it does not automatically
mean the runner failed.

20
00:01:09.706 --> 00:01:11.239
Read the source path with me.

21
00:01:11.622 --> 00:01:16.162
The host adapter interprets fixture rows
and supplies timestamps and readings.

22
00:01:16.603 --> 00:01:21.073
The shared policy decides whether input is
current and whether recovery is complete.

23
00:01:21.514 --> 00:01:25.369
The output formatter writes a JSON
object for the resulting snapshot.

24
00:01:25.647 --> 00:01:29.142
These policy and output source files
live inside the sketch directory

25
00:01:29.293 --> 00:01:32.416
and are also compiled directly
into the host executable.

26
00:01:32.741 --> 00:01:36.409
The Arduino sketch provides a different
surrounding environment. It uses

27
00:01:36.444 --> 00:01:38.801
the platform clock,
generates a short synthetic

28
00:01:38.847 --> 00:01:42.110
sequence, and sends formatted
output through the serial interface.

29
00:01:42.284 --> 00:01:46.220
It does not read a physical
BME280. Compiling that sketch

30
00:01:46.266 --> 00:01:49.924
is useful evidence for the selected
target, but it does not turn replay into

31
00:01:49.982 --> 00:01:53.906
an electrical simulation or establish that
a board has been uploaded successfully.

32
00:01:54.719 --> 00:01:58.619
Attempt the baseline firmware build with
the recorded target and retain its actual

33
00:01:58.689 --> 00:02:01.800
result. The final release has
a separate verified Windows

34
00:02:01.835 --> 00:02:05.388
build, but another checkpoint or an
edited source needs its own receipt.

35
00:02:05.771 --> 00:02:08.360
Keep the native result and
firmware result distinct.

36
00:02:08.685 --> 00:02:11.541
A successful host run cannot
substitute for a cross-build,

37
00:02:11.750 --> 00:02:16.115
and neither result establishes sensor
accuracy, wiring, USB operation,

38
00:02:16.173 --> 00:02:20.028
or measured device timing. Now
choose one reporting requirement.

39
00:02:20.237 --> 00:02:22.826
The snapshot already
contains a current-data flag,

40
00:02:23.000 --> 00:02:26.007
but the sample JSON does not
expose that flag directly.

41
00:02:26.332 --> 00:02:30.256
We will add a Boolean field named
current. The request is limited to the

42
00:02:30.291 --> 00:02:32.485
status formatter and its
reporting description.

43
00:02:33.437 --> 00:02:37.895
Acquisition, policy, timing, dependencies,
and the board target should remain

44
00:02:38.012 --> 00:02:42.098
unchanged. This gives us a clear basis
for reviewing an assistant's patch.

45
00:02:42.795 --> 00:02:45.836
Notice why the field has a
useful meaning. The policy starts

46
00:02:45.871 --> 00:02:47.218
in fault with missing input.

47
00:02:47.822 --> 00:02:49.737
A first valid sample is fresh,

48
00:02:49.865 --> 00:02:52.768
but the two-sample recovery
rule keeps the state in fault.

49
00:02:53.371 --> 00:02:56.123
That record should therefore have
current true and state fault.

50
00:02:56.820 --> 00:02:59.897
Availability of data and completion
of recovery are different

51
00:02:59.931 --> 00:03:04.065
properties. Deriving the new field from
whether the state is normal would lose

52
00:03:04.099 --> 00:03:07.896
that distinction. Inspect the
complete bounded formatting call.

53
00:03:08.140 --> 00:03:11.704
Add a placeholder for the current
field before the closing brace, then

54
00:03:11.762 --> 00:03:14.862
add the matching argument based
on the existing snapshot flag.

55
00:03:15.187 --> 00:03:19.007
The strings true and false are
used as unquoted JSON literals.

56
00:03:19.332 --> 00:03:22.327
If the output places quotation
marks around them, the consumer

57
00:03:22.373 --> 00:03:24.707
receives strings instead
of Boolean values.

58
00:03:25.148 --> 00:03:28.214
Keep the existing buffer-completion
check after the change.

59
00:03:28.655 --> 00:03:32.858
Review the diff before running it. The
new placeholder needs its corresponding

60
00:03:32.916 --> 00:03:37.223
argument in the right position. The policy
does not need a new global variable,

61
00:03:37.339 --> 00:03:41.298
and the synthetic sequence does not need
new values to accommodate this report.

62
00:03:41.576 --> 00:03:46.360
If the assistant also changes recovery or
adds a driver, return to the bounded task.

63
00:03:46.685 --> 00:03:50.377
Those edits make the result harder
to assess and are unnecessary here.

64
00:03:50.888 --> 00:03:53.372
Run the stale-recovery
fixture after rebuilding.

65
00:03:53.651 --> 00:03:57.377
Its sample at timestamp one thousand is
still current at four thousand because

66
00:03:57.412 --> 00:03:59.920
the age is exactly three
thousand milliseconds.

67
00:04:00.431 --> 00:04:02.799
At four thousand and
one, it becomes stale.

68
00:04:03.496 --> 00:04:05.400
A valid sample at five thousand starts

69
00:04:05.446 --> 00:04:08.825
recovery, a missing event at six
thousand interrupts it, and valid

70
00:04:08.871 --> 00:04:12.459
samples at seven and eight thousand
complete a fresh recovery sequence.

71
00:04:12.668 --> 00:04:16.534
The expected current flags are true,
true, true, false, true, false, true,

72
00:04:16.557 --> 00:04:20.783
true. Look particularly at five and seven
thousand. Those records remain in fault

73
00:04:20.806 --> 00:04:23.569
while containing fresh input.
They distinguish the correct

74
00:04:23.616 --> 00:04:25.288
snapshot mapping from the tempting

75
00:04:25.369 --> 00:04:29.165
state-based shortcut. The state and error
sequence should be the same as before

76
00:04:29.189 --> 00:04:33.600
the reporting change, because the policy
was not part of the task. Use PowerShell's

77
00:04:33.670 --> 00:04:38.314
JSON parser to inspect the output rather
than relying only on visual alignment.

78
00:04:38.697 --> 00:04:41.960
Preserve the replay exit before
passing lines through the parser.

79
00:04:42.401 --> 00:04:45.559
Convert each line into a
record, select sample records,

80
00:04:45.652 --> 00:04:48.136
and display timestamp,
state, error, and current.

81
00:04:48.519 --> 00:04:52.547
A parsing failure matters. Confirm
that current is a Boolean value,

82
00:04:52.629 --> 00:04:55.485
not merely text that looks
like the word true or false.

83
00:04:55.868 --> 00:04:58.666
Adding a field changes
the local output contract.

84
00:04:58.991 --> 00:05:02.822
Update the exercise documentation
so a consumer knows what to expect.

85
00:05:03.426 --> 00:05:05.260
A strict parser may reject unknown

86
00:05:05.342 --> 00:05:08.488
fields, so do not promise
compatibility without checking it.

87
00:05:09.092 --> 00:05:11.356
This lesson uses a disposable extension;

88
00:05:11.797 --> 00:05:14.966
the next published checkpoint
remains its own starting state.

89
00:05:15.291 --> 00:05:19.065
You are not required to carry this
extra field into every later exercise

90
00:05:19.239 --> 00:05:21.584
or alter the capstone acceptance tests.

91
00:05:22.095 --> 00:05:25.961
Cross-compile the edited shared source
using the unchanged manifest target

92
00:05:26.170 --> 00:05:30.118
and save the actual result. If
a required tool is unavailable,

93
00:05:30.327 --> 00:05:33.125
identify that missing dependency
and leave the check open.

94
00:05:33.450 --> 00:05:36.736
Do not replace it with an old
binary or an agent assurance.

95
00:05:37.061 --> 00:05:41.299
The instructor host check establishes this
reporting behavior for synthetic fixtures;

96
00:05:41.624 --> 00:05:45.559
a learner run and a firmware build are
separate receipts. Finish by inspecting

97
00:05:45.605 --> 00:05:48.055
the final diff and writing
a brief evidence note.

98
00:05:48.380 --> 00:05:52.200
Name the starting checkpoint, changed
files, fixtures, command exits,

99
00:05:52.281 --> 00:05:55.822
and any remaining limitation.
A successful solution exposes

100
00:05:55.869 --> 00:05:59.782
the existing flag accurately while
leaving the previous behavior intact.

101
00:06:00.107 --> 00:06:03.857
We now have a small change that can be
explained from requirement to source

102
00:06:03.891 --> 00:06:06.480
to output. The next lesson uses the same

103
00:06:06.527 --> 00:06:09.337
discipline when the starting
output reveals a failure.