WEBVTT

1
00:00:00.000 --> 00:00:03.819
A release candidate is useful when
another checkout can reproduce its result.

2
00:00:04.145 --> 00:00:07.128
In this lesson, we will
verify the complete capstone,

3
00:00:07.302 --> 00:00:10.228
package its evidence, and test
the written setup in a fresh

4
00:00:10.297 --> 00:00:13.920
copy. Start with your reviewed
implementation from the previous lesson.

5
00:00:14.129 --> 00:00:16.323
The target is a complete
private candidate;

6
00:00:16.532 --> 00:00:20.421
public publication and physical upload
are not required for the core course.

7
00:00:20.805 --> 00:00:22.267
Begin with source identity.

8
00:00:22.511 --> 00:00:25.890
Record the current commit or hashes
and inspect the working tree.

9
00:00:26.273 --> 00:00:29.907
Confirm that the requirements, tests,
fixtures, and build inputs describe

10
00:00:29.942 --> 00:00:33.204
the same candidate. A result
from an earlier source can remain

11
00:00:33.274 --> 00:00:36.849
useful history, but it does not
automatically certify the current edit.

12
00:00:37.174 --> 00:00:39.612
The evidence must name
what was actually checked.

13
00:00:40.053 --> 00:00:42.701
Run the full host-test
wrapper from the project root.

14
00:00:42.910 --> 00:00:45.301
Read the process result
and relevant assertions.

15
00:00:45.742 --> 00:00:50.491
The suite needs entry equality, clearing
equality, both hysteresis directions,

16
00:00:50.700 --> 00:00:54.763
jitter, invalid and stale input,
interrupted recovery, rollover,

17
00:00:54.937 --> 00:00:58.234
command validation,
bounds, and reset behavior.

18
00:00:58.838 --> 00:01:02.565
A large assertion count cannot substitute
for those specific requirements.

19
00:01:03.076 --> 00:01:05.525
Now run the normal fixture
with the replay wrapper.

20
00:01:05.966 --> 00:01:09.299
In the final capstone, the expected
state sequence begins fault,

21
00:01:09.542 --> 00:01:12.433
normal, alert, alert,
normal, fault, fault, normal.

22
00:01:13.130 --> 00:01:16.357
The initial and later recovering
samples are fresh but remain fault

23
00:01:16.404 --> 00:01:17.704
until recovery completes.

24
00:01:18.401 --> 00:01:21.350
Save the actual output from
your run. The expected sequence

25
00:01:21.373 --> 00:01:24.508
in the lesson is a criterion,
not an execution record.

26
00:01:24.949 --> 00:01:28.792
Run the commands fixture next.
It exercises accepted settings,

27
00:01:28.966 --> 00:01:32.728
malformed text, an out-of-range
value, truncation, and reset.

28
00:01:33.053 --> 00:01:36.060
Inspect both command acknowledgements
and subsequent state.

29
00:01:36.501 --> 00:01:39.008
A valid threshold command
changes configuration,

30
00:01:39.159 --> 00:01:41.957
but it cannot clear fault
or supply a missing sample.

31
00:01:42.561 --> 00:01:45.127
Rejected input must leave
the previous setting intact.

32
00:01:45.406 --> 00:01:47.553
Reset returns to the documented defaults.

33
00:01:48.064 --> 00:01:50.665
Continue with stale-recovery
and rollover fixtures.

34
00:01:50.839 --> 00:01:54.160
The injected times test software
logic under controlled conditions.

35
00:01:54.670 --> 00:01:58.420
They do not measure real microcontroller
scheduling or USB latency.

36
00:01:58.804 --> 00:02:02.205
A stale gap between otherwise
valid samples must reset recovery,

37
00:02:02.449 --> 00:02:05.375
and age exactly three thousand
milliseconds remains current.

38
00:02:05.758 --> 00:02:08.881
Preserve the source and fixture
identities with the result so

39
00:02:08.963 --> 00:02:11.052
a reviewer can reproduce the sequence.

40
00:02:11.435 --> 00:02:15.569
Interpret process results carefully. A
valid synthetic fixture can intentionally

41
00:02:15.615 --> 00:02:18.088
produce fault and still
complete with exit zero.

42
00:02:18.529 --> 00:02:22.035
A malformed fixture is rejected
with a diagnostic and exit two.

43
00:02:22.546 --> 00:02:25.147
Failed native assertions use exit one.

44
00:02:25.530 --> 00:02:29.222
These are different meanings. Do not
edit an intentionally invalid sample

45
00:02:29.268 --> 00:02:32.879
out of a valid fixture merely to
make every displayed state normal.

46
00:02:33.262 --> 00:02:36.675
Run the firmware cross-build after
the reviewed shared-source changes.

47
00:02:37.000 --> 00:02:40.181
The maintained wrapper preserves
the selected target configuration

48
00:02:40.228 --> 00:02:44.164
from the dependency record. Save the
actual command result and build evidence.

49
00:02:44.489 --> 00:02:48.402
This supports compilation for those
inputs. It does not establish that a board

50
00:02:48.436 --> 00:02:52.105
was connected, that an upload worked,
or that a sensor measured anything.

51
00:02:52.709 --> 00:02:55.426
Next, challenge the suite
with the isolated hysteresis

52
00:02:55.484 --> 00:02:56.970
and command fault copies.

53
00:02:57.295 --> 00:03:01.068
The hysteresis defect misses inclusive
clearing at twenty-seven degrees.

54
00:03:01.451 --> 00:03:05.399
The command defect accepts trailing
numeric text that should be malformed.

55
00:03:05.782 --> 00:03:09.787
Both wrong versions must compile before
their failed assertions establish useful

56
00:03:09.845 --> 00:03:14.432
behavioral rejection. A syntax error
would answer a different question.

57
00:03:14.942 --> 00:03:18.344
Keep the good solution separate
and show that it still passes.

58
00:03:18.727 --> 00:03:22.965
Preserve the bad source diff, the relevant
failed check, and the good result.

59
00:03:23.290 --> 00:03:25.960
A final passing screen alone does not show

60
00:03:26.030 --> 00:03:28.573
that the tests can reject
the meaningful defects.

61
00:03:28.898 --> 00:03:32.160
The point is to connect requirements,
implementation changes,

62
00:03:32.334 --> 00:03:35.712
and observations in a record
another engineer can inspect.

63
00:03:36.037 --> 00:03:40.635
Update the candidate documentation. The
README should explain setup and commands.

64
00:03:40.960 --> 00:03:44.176
Requirements and formats should
match the implemented behavior.

65
00:03:44.502 --> 00:03:48.530
Decisions should explain material
choices such as RAM-only settings.

66
00:03:48.855 --> 00:03:51.375
The evidence summary should
link to actual receipts,

67
00:03:51.502 --> 00:03:55.206
and the handoff should name the current
source and remaining work. Release

68
00:03:55.264 --> 00:03:59.130
notes should describe the final behavior
without exaggerating its validation.

69
00:03:59.641 --> 00:04:03.577
Review the package contents for its
intended audience. Include source,

70
00:04:03.669 --> 00:04:07.768
permitted fixtures, dependency
information, setup, and relevant evidence.

71
00:04:08.209 --> 00:04:11.274
Keep private authoring
credentials, unrelated history,

72
00:04:11.390 --> 00:04:15.349
service administration, and personal
captures outside the learner package.

73
00:04:16.045 --> 00:04:19.540
A useful private release is complete
and reviewable; it does not need

74
00:04:19.586 --> 00:04:23.139
public visibility to demonstrate
the engineering outcome. Create

75
00:04:23.162 --> 00:04:26.912
a fresh second checkout from the intended
release source. Follow the written

76
00:04:26.970 --> 00:04:30.546
setup without silently supplying
missing files from the original folder.

77
00:04:30.929 --> 00:04:34.854
Run the required tests, replay, and
firmware build there. This is the check

78
00:04:34.900 --> 00:04:38.696
that exposes dependence on untracked
files or incidental environment state.

79
00:04:39.137 --> 00:04:43.236
A clean working tree without actual
execution is not reproduction.

80
00:04:43.619 --> 00:04:47.589
The reference also supplies independent
JSON replay checks in its Python

81
00:04:47.648 --> 00:04:51.618
host appendix. When you use that
route, record the actual platform

82
00:04:51.676 --> 00:04:56.157
and commands separately from the Windows
wrapper receipts. Parsing the emitted JSON

83
00:04:56.366 --> 00:05:00.836
and comparing event sequences adds
another perspective beyond C++ assertions.

84
00:05:01.277 --> 00:05:03.204
It still evaluates software output,

85
00:05:03.286 --> 00:05:06.618
so it does not expand the result
into a physical validation claim.

86
00:05:07.059 --> 00:05:09.207
Record the second-copy result separately.

87
00:05:09.648 --> 00:05:14.014
Name its source identity, setup route,
commands, outcomes, and limitations.

88
00:05:14.455 --> 00:05:18.019
If a dependency is missing, improve
the setup or resolve the documented

89
00:05:18.065 --> 00:05:22.570
environment and repeat the affected check.
Preserve failures that explain the repair.

90
00:05:22.953 --> 00:05:25.588
Do not label the original
checkout's passing result

91
00:05:25.646 --> 00:05:28.247
as evidence that the second
copy ran successfully.

92
00:05:28.688 --> 00:05:32.369
Your exercise is to submit the
candidate, requirement-to-test map,

93
00:05:32.485 --> 00:05:35.863
actual software receipts,
meaningful defect-rejection records,

94
00:05:36.037 --> 00:05:40.356
fresh-checkout result, and current
handoff. Apply the capstone rubric.

95
00:05:40.530 --> 00:05:43.305
The suggested score target
is eighty out of one hundred,

96
00:05:43.456 --> 00:05:47.322
but mandatory behavior, reproducible
build, host and replay checks,

97
00:05:47.403 --> 00:05:51.513
and honest evidence labels must all
be satisfied. Pause here to complete

98
00:05:51.536 --> 00:05:55.565
the verification and packaging. When
you finish, state the strongest claim

99
00:05:55.611 --> 00:05:59.269
the evidence supports: this recorded
software candidate met its specified

100
00:05:59.303 --> 00:06:03.333
checks and reproduced through the written
path, if those results actually passed.

101
00:06:04.029 --> 00:06:07.129
Physical behavior remains
a separate optional task.

102
00:06:07.454 --> 00:06:10.275
A precise private candidate
is the intended core outcome,

103
00:06:10.426 --> 00:06:14.211
and its value comes from the work
another person can inspect and repeat.