WEBVTT

1
00:00:00.000 --> 00:00:02.229
A test plan tells us
what we intend to check.

2
00:00:02.473 --> 00:00:06.617
A result tells us what happened when we
checked it. In this lesson, we will keep

3
00:00:06.664 --> 00:00:10.495
those records separate and connect
them to a short decision and handoff.

4
00:00:10.878 --> 00:00:14.129
Start with checkpoint two and
the linked project documents.

5
00:00:14.454 --> 00:00:17.728
The goal is an evidence record
another person can inspect,

6
00:00:17.972 --> 00:00:21.165
even if a particular execution
check remains unavailable.

7
00:00:21.490 --> 00:00:24.032
Begin with a decision the
project has already made:

8
00:00:24.416 --> 00:00:27.899
use synthetic host input for
the required core demonstration.

9
00:00:28.340 --> 00:00:32.868
Record the context first. The course
needs a reproducible software workflow

10
00:00:32.937 --> 00:00:37.152
that does not require a physical kit. Then
record the choice and its consequence.

11
00:00:37.477 --> 00:00:39.938
The current host baseline
prints a fixed report;

12
00:00:40.147 --> 00:00:43.317
checkpoint five introduces
replay of shared policy.

13
00:00:43.700 --> 00:00:47.543
Neither establishes electrical
behavior, sensor accuracy,

14
00:00:47.659 --> 00:00:51.246
USB behavior, or actual
microcontroller timing.

15
00:00:51.572 --> 00:00:56.250
That limitation does not make replay
useless. It makes its value specific.

16
00:00:56.633 --> 00:01:00.383
As the project grows, controlled
input will let us reproduce sequences

17
00:01:00.441 --> 00:01:05.050
and inspect policy state without depending
on room temperature or a connected board.

18
00:01:05.491 --> 00:01:07.744
The mistake is not using synthetic input.

19
00:01:08.127 --> 00:01:11.459
The mistake is describing its
result as a physical observation.

20
00:01:11.842 --> 00:01:16.533
Put the limitation beside the decision so
a future summary cannot easily lose it.

21
00:01:16.916 --> 00:01:20.457
A useful decision record also
names an alternative that mattered.

22
00:01:20.840 --> 00:01:23.952
Here the alternative would make
physical equipment a prerequisite

23
00:01:23.986 --> 00:01:27.156
for the core learning path.
We chose a different scope.

24
00:01:27.481 --> 00:01:30.767
We do not need a long survey
of every possible architecture.

25
00:01:31.150 --> 00:01:34.807
Keep the record focused on the choice
that explains the current project

26
00:01:35.016 --> 00:01:37.756
and the consequence a
maintainer needs to remember.

27
00:01:38.197 --> 00:01:42.051
Next, write a plan for one behavior
that exists in your checkpoint.

28
00:01:42.492 --> 00:01:46.626
Read the applicable requirements before
choosing the case. Earlier checkpoints

29
00:01:46.684 --> 00:01:50.585
do not contain all the later
capstone features or assertion tests.

30
00:01:50.910 --> 00:01:54.091
A stage-appropriate
plan uses the CP02 fixed

31
00:01:54.160 --> 00:01:57.492
synthetic report and checks
its documented JSON fields.

32
00:01:57.875 --> 00:02:01.393
The source and expectation must
match the stage you actually have.

33
00:02:01.904 --> 00:02:05.735
Write the expected outcome before
studying the implementation's answer.

34
00:02:06.177 --> 00:02:08.696
If a requirement defines
an inclusive boundary,

35
00:02:08.940 --> 00:02:12.480
equality belongs in the planned
cases when that feature is present.

36
00:02:13.084 --> 00:02:16.370
Copying a comparison from the
implementation into the expected

37
00:02:16.428 --> 00:02:19.748
result can make a test
repeat the same defect.

38
00:02:20.189 --> 00:02:23.440
The requirement is the independent
reason for the expectation.

39
00:02:23.881 --> 00:02:26.458
The code is what we are
trying to evaluate against it.

40
00:02:26.841 --> 00:02:29.268
A plan can be complete before execution.

41
00:02:29.651 --> 00:02:32.937
Label it accordingly. It should
identify the starting source,

42
00:02:33.029 --> 00:02:36.385
input, procedure, and condition
that would count as success.

43
00:02:36.710 --> 00:02:40.809
A checkbox or a confident sentence
does not turn that plan into a result.

44
00:02:41.134 --> 00:02:42.817
If the required tool is missing,

45
00:02:42.933 --> 00:02:46.393
the right record says which
dependency prevents execution.

46
00:02:46.997 --> 00:02:50.085
It does not fill the outcome
column with a hoped-for pass.

47
00:02:50.689 --> 00:02:53.394
For a current replay
check, use the maintained

48
00:02:53.463 --> 00:02:57.213
replay command shown in the written
lesson and run it from the project root.

49
00:02:57.654 --> 00:03:00.429
The Windows wrapper ends in dot cmd.

50
00:03:00.870 --> 00:03:04.144
It keeps the environment handling
in reviewable project code.

51
00:03:04.527 --> 00:03:07.197
Later, when host assertion
tests are introduced,

52
00:03:07.406 --> 00:03:11.156
their wrapper provides a different
check. Record exactly which operation

53
00:03:11.226 --> 00:03:14.511
ran rather than calling every
successful command a test suite.

54
00:03:15.022 --> 00:03:17.948
Now inspect the actual
process result and output.

55
00:03:18.227 --> 00:03:22.151
A result record needs the source or
checkpoint identity, environment,

56
00:03:22.325 --> 00:03:25.843
command, input source, date,
exit result, and relevant output.

57
00:03:26.226 --> 00:03:29.071
Name a fixture only when that
stage actually reads one.

58
00:03:29.314 --> 00:03:33.122
It also needs an interpretation.
The command may complete successfully

59
00:03:33.239 --> 00:03:36.884
while a reader misunderstands what
it proves. State that the input

60
00:03:36.931 --> 00:03:40.692
is synthetic and name the bounded
behavior the observation supports.

61
00:03:41.296 --> 00:03:45.174
You do not need to paste every line
into the central evidence page. Keep

62
00:03:45.220 --> 00:03:47.797
a concise summary and
link to the saved log when

63
00:03:47.832 --> 00:03:50.491
the release or exercise
has an evidence location.

64
00:03:51.095 --> 00:03:52.952
The summary makes the record navigable.

65
00:03:53.393 --> 00:03:56.331
The underlying output lets
another reviewer inspect it.

66
00:03:56.540 --> 00:03:59.372
If a failed attempt explains
a defect and correction,

67
00:03:59.523 --> 00:04:01.961
preserve it with a clear
date and source identity.

68
00:04:02.286 --> 00:04:05.990
Suppose an agent says tests
should pass. That is a prediction.

69
00:04:06.315 --> 00:04:10.054
Suppose it says tests passed but
provides no accessible command result.

70
00:04:10.750 --> 00:04:14.152
Ask what ran, against which
source, and where the receipt is.

71
00:04:14.756 --> 00:04:16.370
If the record cannot be found,

72
00:04:16.497 --> 00:04:20.166
mark the claim unestablished and perform
the relevant check when possible.

73
00:04:20.770 --> 00:04:23.696
Do not manufacture a log to
fit the confident summary.

74
00:04:23.974 --> 00:04:26.680
We can practice classification
with four statements.

75
00:04:26.923 --> 00:04:31.057
The monitor must follow a specified
threshold boundary: requirement.

76
00:04:31.382 --> 00:04:35.991
The selected board has a documented
memory configuration: hardware fact.

77
00:04:36.316 --> 00:04:40.623
The future capstone keeps threshold
changes in RAM: project decision.

78
00:04:40.866 --> 00:04:45.441
A named fixture produced a particular
output in a recorded run: result.

79
00:04:45.766 --> 00:04:48.564
Notice that the last statement
depends on a receipt, while

80
00:04:48.587 --> 00:04:52.476
the first three have different sources
of authority. Finish with a handoff.

81
00:04:52.801 --> 00:04:56.273
Name the current checkpoint,
reviewed changes, last relevant checks

82
00:04:56.296 --> 00:05:00.580
with evidence pointers, unresolved
questions, and one bounded next action.

83
00:05:01.021 --> 00:05:03.436
Avoid copying the whole conversation.

84
00:05:03.645 --> 00:05:06.931
The next session needs the active
state and the next uncertainty,

85
00:05:07.105 --> 00:05:11.284
not every abandoned approach. A
sentence such as continue improving

86
00:05:11.354 --> 00:05:15.406
everything leaves the next worker to
reconstruct the task from scratch.

87
00:05:16.103 --> 00:05:19.179
Your exercise is to write
the synthetic-core decision,

88
00:05:19.388 --> 00:05:23.452
a stage-appropriate check plan, and
a result from a real available run.

89
00:05:23.835 --> 00:05:27.632
If no run is available, mark it
unperformed and state what is missing.

90
00:05:28.073 --> 00:05:32.183
Add the short handoff. Keep source-code
changes out of this documentation

91
00:05:32.241 --> 00:05:35.666
exercise unless the task
explicitly requires them,

92
00:05:35.875 --> 00:05:39.323
and preserve the starting copy
for recovery. Review the records

93
00:05:39.369 --> 00:05:43.015
by asking whether a stranger could
confuse a proposal with an observation.

94
00:05:43.456 --> 00:05:46.997
If the answer is yes, improve
the labels and evidence pointers.

95
00:05:47.380 --> 00:05:50.759
A truthful open check is more
useful than a decorative pass.

96
00:05:51.363 --> 00:05:54.857
You now have the basis for a project
history that can support engineering

97
00:05:54.904 --> 00:05:59.350
decisions without asking the next person
to trust your memory or an agent's tone.

98
00:05:59.792 --> 00:06:02.671
Keep historical records scoped
to their source version.

99
00:06:03.112 --> 00:06:07.675
An old failure can remain accurate
history after a fix. Marking its status

100
00:06:07.721 --> 00:06:12.122
and linking the newer result is clearer
than silently rewriting it into a success.