WEBVTT

1
00:00:00.000 --> 00:00:04.342
The capstone adds configurable alerts to
the normal and fault monitor you already

2
00:00:04.401 --> 00:00:08.684
understand. In this lesson, we will turn
that feature into a plan with observable

3
00:00:08.719 --> 00:00:12.493
checks. Start from checkpoint eight
and preserve its working baseline.

4
00:00:13.003 --> 00:00:16.730
Checkpoint nine is the final reference
solution, but the goal is to carry

5
00:00:16.777 --> 00:00:21.084
the change through your own requirements,
implementation, review, and evidence.

6
00:00:21.409 --> 00:00:23.476
Begin by naming what stays important.

7
00:00:23.801 --> 00:00:27.353
Missing, nonfinite, and stale
input must still enter fault.

8
00:00:27.736 --> 00:00:31.405
Recovery still requires two
consecutive fresh valid samples.

9
00:00:31.614 --> 00:00:34.644
An invalid sample or a
stale gap resets that count.

10
00:00:34.969 --> 00:00:38.754
Startup follows the same rule, so the
first valid reading can be current while

11
00:00:38.778 --> 00:00:40.740
the state remains fault during recovery.

12
00:00:41.181 --> 00:00:44.815
New alert logic must not
bypass this existing contract.

13
00:00:45.140 --> 00:00:48.077
The default threshold is
twenty-eight degrees Celsius.

14
00:00:48.460 --> 00:00:53.453
From normal, a valid reading at or above
the threshold enters alert. From alert,

15
00:00:53.603 --> 00:00:57.621
a reading at or below one degree
beneath the threshold clears to normal.

16
00:00:57.899 --> 00:01:01.452
Between those boundaries,
retain the prior non-fault state.

17
00:01:01.835 --> 00:01:03.414
These are teaching values,

18
00:01:03.693 --> 00:01:07.629
not sensor calibration limits or
a safety-control specification.

19
00:01:08.232 --> 00:01:12.841
Write an example with twenty-seven point
five degrees. Starting from normal,

20
00:01:12.934 --> 00:01:16.672
that value remains normal because
it is below the entry threshold.

21
00:01:16.997 --> 00:01:18.066
Starting from alert,

22
00:01:18.275 --> 00:01:22.059
the same value remains alert because
it is above the clearing boundary.

23
00:01:22.443 --> 00:01:25.055
This history dependence is hysteresis.

24
00:01:25.333 --> 00:01:27.958
A test that supplies the
value without identifying

25
00:01:28.004 --> 00:01:31.104
the starting state cannot
determine the expected answer.

26
00:01:31.800 --> 00:01:34.088
Add equality cases explicitly.

27
00:01:34.691 --> 00:01:37.025
At twenty-eight, normal enters alert.

28
00:01:37.536 --> 00:01:42.041
At twenty-seven, alert clears to normal.
Also include jitter near the entry

29
00:01:42.099 --> 00:01:44.398
boundary and both
directions through the band.

30
00:01:45.001 --> 00:01:48.879
Write the expected sequence before
reading the implementation's comparisons.

31
00:01:49.262 --> 00:01:53.233
The requirement must provide the
independent reason for the expectation.

32
00:01:53.674 --> 00:01:58.318
Now consider recovery from fault. After
the two required fresh valid samples,

33
00:01:58.527 --> 00:02:01.487
classify the latest temperature
using the entry threshold.

34
00:02:01.928 --> 00:02:06.050
Do not restore an old alert simply because
the monitor was alert before the fault.

35
00:02:06.375 --> 00:02:09.846
The new reading and current configuration
determine the recovered state.

36
00:02:10.171 --> 00:02:13.445
Include an interrupted-recovery
sequence so the implementation

37
00:02:13.526 --> 00:02:17.102
cannot accidentally count invalid
or stale input as progress.

38
00:02:17.613 --> 00:02:21.003
The command interface needs
an equally explicit contract.

39
00:02:21.282 --> 00:02:23.836
The command begins with the
lowercase word threshold,

40
00:02:24.080 --> 00:02:27.865
followed by one space and a decimal
number, and ends with line feed.

41
00:02:28.306 --> 00:02:32.323
An optional final carriage return
supports the usual Windows line ending.

42
00:02:32.706 --> 00:02:36.816
The maximum line length is sixty-four
bytes before line feed, including

43
00:02:36.851 --> 00:02:41.101
that optional carriage return. These
details define the collector's bounds.

44
00:02:41.426 --> 00:02:45.640
Accept threshold values from zero
through fifty degrees inclusive.

45
00:02:46.023 --> 00:02:50.226
The setting is stored in RAM
only. Reset or a new process

46
00:02:50.551 --> 00:02:54.197
restores the default threshold
and fault with missing input.

47
00:02:54.580 --> 00:02:58.063
Do not promise persistence that
the project does not implement.

48
00:02:58.388 --> 00:03:01.511
A configuration acknowledgement
says the command was accepted;

49
00:03:01.755 --> 00:03:05.052
it does not establish that a
valid sensor sample exists.

50
00:03:05.377 --> 00:03:08.570
Define the number grammar before
choosing a conversion helper.

51
00:03:08.953 --> 00:03:12.401
The reference accepts an
optional sign, integer digits,

52
00:03:12.552 --> 00:03:15.791
and an optional decimal fraction
with digits after the point.

53
00:03:16.116 --> 00:03:21.352
It rejects exponents, extra whitespace,
nonfinite words, and trailing text.

54
00:03:21.678 --> 00:03:25.056
A command containing twenty-eight
followed by junk is malformed

55
00:03:25.114 --> 00:03:28.132
even if a library can extract
a numeric prefix from it.

56
00:03:28.573 --> 00:03:32.672
Invalid commands must leave the
prior configuration unchanged.

57
00:03:33.055 --> 00:03:35.911
Cover malformed text, out-of-range values,

58
00:03:36.085 --> 00:03:39.916
oversized lines, and a partial
line at host end-of-input.

59
00:03:40.195 --> 00:03:43.818
An oversized collector must drain to
the line boundary so the remaining

60
00:03:43.876 --> 00:03:46.941
bytes cannot become an
unintended second command.

61
00:03:47.452 --> 00:03:51.074
Repeated valid commands should
still work after a rejected line.

62
00:03:51.457 --> 00:03:54.963
A valid threshold update
immediately re-evaluates

63
00:03:55.010 --> 00:03:58.330
a current non-faulted reading
against the new entry threshold.

64
00:03:58.771 --> 00:04:03.079
It cannot clear fault or advance
recovery. Poll the injected time before

65
00:04:03.102 --> 00:04:07.282
applying the setting so an old cached
value is not treated as current.

66
00:04:07.665 --> 00:04:11.984
This connection between command handling
and freshness belongs in the plan

67
00:04:12.309 --> 00:04:16.256
because separate locally correct
functions can still interact incorrectly.

68
00:04:16.860 --> 00:04:19.263
Split the implementation into four slices.

69
00:04:19.774 --> 00:04:23.640
First add alert state and validated
configuration to shared policy.

70
00:04:24.081 --> 00:04:26.554
Second add the bounded
complete-line parser.

71
00:04:26.879 --> 00:04:30.803
Third integrate the parser and output
into the host and firmware adapters.

72
00:04:31.244 --> 00:04:35.505
Fourth complete verification,
documentation, and release reproduction.

73
00:04:35.946 --> 00:04:39.650
Keep each slice small enough to
inspect before moving to the next.

74
00:04:39.975 --> 00:04:43.957
Preserve shared source between host
and firmware. The policy, parser,

75
00:04:43.981 --> 00:04:49.124
and output implementation should have one
maintained copy used by both build paths.

76
00:04:49.449 --> 00:04:53.675
A host-only substitute would weaken the
connection between tests and the embedded

77
00:04:53.733 --> 00:04:58.284
source. At the same time, host checks
still do not establish electrical behavior

78
00:04:58.563 --> 00:05:02.406
or physical device timing, so keep
those evidence limits in the plan.

79
00:05:02.684 --> 00:05:05.297
Keep fixture grammar separate
from command grammar.

80
00:05:05.680 --> 00:05:10.208
The replay file has timestamp, event, and
value fields, while the command collector

81
00:05:10.266 --> 00:05:14.921
has its own byte limit and line boundary.
A valid command embedded in a malformed

82
00:05:14.979 --> 00:05:19.414
fixture can still be rejected by the
fixture parser before policy sees it.

83
00:05:19.856 --> 00:05:24.941
Your test plan should identify which layer
each invalid case is intended to exercise.

84
00:05:25.382 --> 00:05:28.946
Run the existing checkpoint-eight
tests and replay before editing.

85
00:05:29.550 --> 00:05:32.603
Record their actual results
and remember that this stage

86
00:05:32.638 --> 00:05:35.935
has no alert or command
behavior. The same normal

87
00:05:36.016 --> 00:05:39.407
fixture will have different state
expectations after the capstone.

88
00:05:39.732 --> 00:05:43.366
A result needs its checkpoint
identity so an earlier normal-state

89
00:05:43.412 --> 00:05:47.034
sequence is not accidentally
judged against the later solution.

90
00:05:47.545 --> 00:05:49.600
Your exercise is to write the brief,

91
00:05:49.751 --> 00:05:53.199
the requirement-to-check table,
and the four-slice plan.

92
00:05:53.641 --> 00:05:57.251
Include starting state,
equality, faults, recovery,

93
00:05:57.344 --> 00:06:00.897
parser grammar and bounds,
reset, and evidence limits.

94
00:06:01.338 --> 00:06:04.670
Identify which command or
review will check each slice.

95
00:06:05.181 --> 00:06:09.082
Do not mark planned behavior implemented
merely because the acceptance table

96
00:06:09.140 --> 00:06:12.832
is complete. Pause here to finish
the plan before beginning code.

97
00:06:13.273 --> 00:06:17.000
A good plan is not a promise that
no problem will occur. It gives

98
00:06:17.034 --> 00:06:21.005
you a way to recognize the important
problems and keep corrections bounded.

99
00:06:21.388 --> 00:06:25.777
In the next lesson, we will implement
one requirement at a time and inspect

100
00:06:25.800 --> 00:06:29.910
whether each source change preserves
the contract you have now made explicit.