WEBVTT

1
00:00:00.000 --> 00:00:03.854
A project becomes easier to resume
when its documents tell you what kind

2
00:00:03.889 --> 00:00:08.336
of information you are reading. In this
lesson, we will separate requirements,

3
00:00:08.417 --> 00:00:12.527
hardware facts, decisions, and
observations. We will build a small

4
00:00:12.608 --> 00:00:16.671
source record for the example target
and leave one important unknown visible.

5
00:00:17.182 --> 00:00:20.828
Start with checkpoint two and the README
you improved in the previous lesson.

6
00:00:21.269 --> 00:00:24.705
No physical hardware is required.
Imagine a note that says

7
00:00:24.821 --> 00:00:27.852
the sensor monitor clears at
twenty-seven degrees and works.

8
00:00:28.235 --> 00:00:31.544
That sentence hides several
questions. Is twenty-seven degrees

9
00:00:31.590 --> 00:00:35.282
the intended boundary or an observed
result? What was the starting state?

10
00:00:35.410 --> 00:00:38.231
Which source version was tested?
Was the input synthetic?

11
00:00:38.347 --> 00:00:42.120
Did anyone execute the program?
Before an agent can reason well

12
00:00:42.178 --> 00:00:46.149
from project context, the context
needs to preserve these distinctions.

13
00:00:46.532 --> 00:00:50.352
A requirement describes intended
behavior that can be checked. A hardware

14
00:00:50.398 --> 00:00:52.813
fact comes from a source
about the exact device.

15
00:00:53.254 --> 00:00:57.689
A decision records a project choice and
its rationale. A result records what

16
00:00:57.748 --> 00:01:01.846
happened during a particular procedure.
These categories can support one another,

17
00:01:01.962 --> 00:01:06.315
but one cannot stand in for another. A
requirement does not prove implementation,

18
00:01:06.385 --> 00:01:09.624
and a manufacturer page does not
prove your physical assembly.

19
00:01:10.321 --> 00:01:13.606
Open the project's docs folder.
The checkpoint supplies the brief

20
00:01:13.664 --> 00:01:17.275
and hardware reference; we add the
other populated records as we work.

21
00:01:17.786 --> 00:01:20.607
Requirements belong in
requirements dot md.

22
00:01:21.048 --> 00:01:23.985
The hardware reference holds
sourced target information.

23
00:01:24.589 --> 00:01:28.478
Decisions explain why the project chose
its current approach. Evidence points

24
00:01:28.513 --> 00:01:33.099
to actual results. The handoff names the
current state and next bounded action.

25
00:01:33.378 --> 00:01:35.827
The README helps a reader
enter this structure.

26
00:01:36.152 --> 00:01:38.509
We need a few complete useful documents,

27
00:01:38.788 --> 00:01:42.514
not a large collection of empty
templates. Begin with the project brief.

28
00:01:42.758 --> 00:01:48.052
It plans shared C++ logic with synthetic
host input, introduced at checkpoint five.

29
00:01:48.377 --> 00:01:51.837
Our current baseline prints a fixed
report and has a separate firmware

30
00:01:51.884 --> 00:01:55.065
cross-build path. The core
course does not require board

31
00:01:55.123 --> 00:01:58.734
ownership. That short explanation
gives meaning to the files that follow.

32
00:01:59.012 --> 00:02:02.495
It also prevents a future session
from expanding a documentation task

33
00:02:02.611 --> 00:02:05.270
into an unnecessary
hardware setup exercise.

34
00:02:05.780 --> 00:02:07.859
Now open the exact board reference.

35
00:02:08.102 --> 00:02:13.664
The selected example is Adafruit product
five four seven seven, the ESP32-S3

36
00:02:13.745 --> 00:02:17.867
Feather variant with four megabytes
of flash and two megabytes of PSRAM.

37
00:02:18.145 --> 00:02:21.617
First confirm the product identifier
on the manufacturer's page.

38
00:02:21.895 --> 00:02:25.785
A family search may return a related
variant. The name that helps you search

39
00:02:25.831 --> 00:02:28.722
is not always specific enough
to support a build setting.

40
00:02:29.105 --> 00:02:31.299
Record the identity as a sourced row.

41
00:02:31.543 --> 00:02:36.535
Include the publisher, page title, direct
link, relevant section, and access date.

42
00:02:36.860 --> 00:02:39.240
If the source supplies
a revision, preserve it.

43
00:02:39.565 --> 00:02:42.839
If it does not establish the
revision of a physical board, say so.

44
00:02:43.280 --> 00:02:45.730
An access date tells us
when a page was checked;

45
00:02:46.055 --> 00:02:49.793
it does not tell us when the manufacturer
revised the board or the document.

46
00:02:50.397 --> 00:02:52.139
Keep the sensor breakout separate.

47
00:02:52.290 --> 00:02:56.574
The optional BME280 breakout has
its own product identity and guide.

48
00:02:56.957 --> 00:02:58.919
The chip datasheet, breakout guide,

49
00:02:58.988 --> 00:03:02.634
and host-board documentation
answer different questions. A chip

50
00:03:02.715 --> 00:03:06.302
operating limit does not automatically
describe a breakout connector.

51
00:03:06.627 --> 00:03:10.784
A host-board feature does not establish
that a sensor is populated on the board.

52
00:03:11.167 --> 00:03:15.579
Careful identity prevents plausible facts
from being attached to the wrong object.

53
00:03:15.904 --> 00:03:17.820
Add a consequence to the memory row.

54
00:03:18.203 --> 00:03:22.289
The exact memory variant affects which
target configuration should be preserved

55
00:03:22.313 --> 00:03:26.457
in the dependency record and build
wrapper. This consequence is project

56
00:03:26.516 --> 00:03:30.974
reasoning. It is useful to distinguish it
from the source's statement so a reviewer

57
00:03:31.021 --> 00:03:35.073
can inspect both. The source may be
correct while your proposed implementation

58
00:03:35.142 --> 00:03:39.345
consequence still needs review.
Now add an explicit unknown:

59
00:03:39.624 --> 00:03:43.653
physical board revision has not been
observed in this documentation exercise.

60
00:03:43.931 --> 00:03:45.185
Explain what that means.

61
00:03:45.696 --> 00:03:50.166
Before an optional physical deployment,
the exact board evidence must be checked.

62
00:03:50.410 --> 00:03:54.891
It does not block the synthetic core path.
This is a practical uncertainty statement

63
00:03:54.984 --> 00:03:58.722
because it identifies the missing
evidence and the decision affected by it.

64
00:03:59.164 --> 00:04:01.602
Do not fill missing pin
mappings from memory.

65
00:04:01.846 --> 00:04:04.690
You may have used a
similar ESP32 board before,

66
00:04:04.806 --> 00:04:07.604
but familiar pin numbers can
belong to another variant.

67
00:04:07.987 --> 00:04:11.435
A page that establishes the
existence of a connector may not

68
00:04:11.481 --> 00:04:15.092
establish every power-control
or initialization requirement.

69
00:04:15.696 --> 00:04:19.074
Write only the supported claim,
preserve the missing detail,

70
00:04:19.167 --> 00:04:22.058
and identify the next primary
source that would resolve it.

71
00:04:22.499 --> 00:04:24.566
Consider the teaching alert threshold.

72
00:04:25.007 --> 00:04:29.361
Twenty-eight degrees Celsius belongs in
the project's requirements and decisions.

73
00:04:29.744 --> 00:04:32.530
It is not a claim about
sensor calibration, accuracy,

74
00:04:32.577 --> 00:04:36.931
or manufacturer limits. Keeping the
threshold out of the hardware-fact table

75
00:04:37.105 --> 00:04:40.913
helps a future agent understand that
it is a project choice that can change

76
00:04:40.960 --> 00:04:45.151
deliberately. It should not be defended
as an immutable property of the device.

77
00:04:45.534 --> 00:04:50.131
If two documents disagree, check identity
and conditions first. They may describe

78
00:04:50.166 --> 00:04:54.172
different variants, or one may describe
a chip while the other describes a board.

79
00:04:54.682 --> 00:04:56.540
If the conflict remains real,

80
00:04:56.691 --> 00:05:00.186
preserve both references and keep
the affected claim unresolved.

81
00:05:00.696 --> 00:05:04.133
Choosing the most convenient value
or averaging two incompatible

82
00:05:04.179 --> 00:05:07.883
values does not establish a
safe or accurate conclusion.

83
00:05:08.580 --> 00:05:13.189
Your exercise is to create three
sourced rows: exact board identity,

84
00:05:13.340 --> 00:05:17.171
memory configuration, and the
explicit physical-revision unknown.

85
00:05:17.613 --> 00:05:20.515
Keep the future capstone's
teaching-threshold requirement

86
00:05:20.561 --> 00:05:24.207
in the requirements document, separate
from current baseline behavior.

87
00:05:24.648 --> 00:05:27.772
Link the documents from the
README and follow those links.

88
00:05:28.282 --> 00:05:30.430
Submit a short note
distinguishing material

89
00:05:30.500 --> 00:05:33.611
you actually opened from source
notes supplied with the release.

90
00:05:34.052 --> 00:05:36.537
A source-access problem
should remain visible.

91
00:05:36.920 --> 00:05:40.891
Before finishing, explain the four
categories using your own rows.

92
00:05:41.216 --> 00:05:43.805
Which sentence says what
the project must do?

93
00:05:44.083 --> 00:05:46.162
Which sentence comes
from the manufacturer?

94
00:05:46.371 --> 00:05:48.484
Which choice belongs to the project?

95
00:05:48.727 --> 00:05:52.338
Which result has an actual
command or observation behind it?

96
00:05:52.663 --> 00:05:55.461
Review the diff for
unsupported added facts.

97
00:05:55.705 --> 00:05:59.722
You now have context that can guide the
next task without quietly converting

98
00:05:59.757 --> 00:06:03.936
an assumption into engineering evidence.
One useful review habit is to cover

99
00:06:03.983 --> 00:06:07.663
the consequence column and ask
what the source alone establishes.

100
00:06:07.942 --> 00:06:10.984
Then uncover it and inspect
the reasoning separately.

101
00:06:11.228 --> 00:06:15.140
This prevents a project choice from
masquerading as a manufacturer statement.