WEBVTT

1
00:00:00.000 --> 00:00:03.669
This challenge asks you to repair a
contradiction that looks plausible.

2
00:00:04.110 --> 00:00:07.500
You will use the Markdown, source,
and evidence habits from this module

3
00:00:07.535 --> 00:00:11.483
to correct a hardware note and find the
current documents that depend on it. Start

4
00:00:11.506 --> 00:00:13.143
with a new checkpoint-two exercise

5
00:00:13.178 --> 00:00:16.649
folder. Keep your earlier work
preserved so the deliberately wrong

6
00:00:16.719 --> 00:00:19.912
statement cannot become the
active reference for another task.

7
00:00:20.190 --> 00:00:23.232
The seeded sentence says that
the selected Adafruit product

8
00:00:23.557 --> 00:00:26.587
five four seven seven has
eight megabytes of flash.

9
00:00:26.866 --> 00:00:30.419
Put that sentence only in the
exercise copy of the hardware note.

10
00:00:30.744 --> 00:00:34.238
In a separate exercise record,
label it as an intentional fault.

11
00:00:34.563 --> 00:00:37.953
This label matters because an
isolated wrong statement can later be

12
00:00:38.011 --> 00:00:41.761
copied into a handoff and mistaken
for something an engineer verified.

13
00:00:42.086 --> 00:00:46.034
Before correcting the number, decide what
evidence would resolve the disagreement.

14
00:00:46.359 --> 00:00:51.177
A general web search for an ESP32-S3
board is not specific enough.

15
00:00:51.502 --> 00:00:54.392
A family name can lead to a
sibling with different memory.

16
00:00:54.717 --> 00:00:58.549
We need the exact manufacturer's product
page for the selected identifier.

17
00:00:58.874 --> 00:01:01.428
The task is to connect one
claim to one applicable

18
00:01:01.474 --> 00:01:04.737
source, not to count how many
search results repeat each number.

19
00:01:05.340 --> 00:01:07.872
Open the product page and
confirm the identity before

20
00:01:07.918 --> 00:01:11.819
reading its memory description. For
the selected example, the documented

21
00:01:11.865 --> 00:01:15.894
configuration is four megabytes of
flash and two megabytes of PSRAM.

22
00:01:16.277 --> 00:01:20.259
A related eight-megabyte variant exists,
which makes the wrong note believable.

23
00:01:20.642 --> 00:01:24.032
The distinction is resolved by
the product identifier and source,

24
00:01:24.276 --> 00:01:26.633
not by familiarity with
the processor family.

25
00:01:27.329 --> 00:01:29.350
Now correct the active hardware reference.

26
00:01:29.791 --> 00:01:32.763
Preserve the unit and identify
the relevant source section.

27
00:01:33.088 --> 00:01:34.783
Add the access date for your check,

28
00:01:34.957 --> 00:01:37.650
and do not confuse that date
with a product revision.

29
00:01:38.033 --> 00:01:42.271
The corrected row should explain its
consequence for this project: the selected

30
00:01:42.317 --> 00:01:46.694
build configuration must match the
documented example variant. It should also

31
00:01:46.764 --> 00:01:50.874
preserve the fact that no physical board
revision was inspected in this exercise.

32
00:01:51.478 --> 00:01:55.297
We are not finished when the central
table is correct. Search the exercise

33
00:01:55.344 --> 00:01:58.943
documents for the product identifier
and the stale eight-megabyte claim.

34
00:01:59.384 --> 00:02:01.334
Read each result in context.

35
00:02:01.776 --> 00:02:06.199
The README or handoff may still direct a
future session to use the wrong variant.

36
00:02:06.524 --> 00:02:09.879
A useful repair updates current
guidance that depends on the fact,

37
00:02:10.053 --> 00:02:12.434
while keeping historical
records clearly scoped.

38
00:02:12.712 --> 00:02:15.092
Do not perform a blind global replacement.

39
00:02:15.371 --> 00:02:17.878
Another document might
describe a different product,

40
00:02:17.960 --> 00:02:21.419
or a dated result might accurately
record an older configuration.

41
00:02:21.930 --> 00:02:26.052
Changing every occurrence of a number
would destroy meaning. Decide whether each

42
00:02:26.098 --> 00:02:30.811
hit is active guidance, unrelated content,
or history. If an old instruction

43
00:02:30.858 --> 00:02:34.643
is superseded, mark that relationship
and link it to the current reference.

44
00:02:35.084 --> 00:02:38.253
Inspect the dependency record
before changing any build setting.

45
00:02:38.636 --> 00:02:42.410
A stale prose sentence does not prove
that the maintained wrapper is wrong.

46
00:02:42.921 --> 00:02:45.451
The canonical target
may already be correct.

47
00:02:45.730 --> 00:02:47.762
This distinction keeps the repair bounded.

48
00:02:48.087 --> 00:02:51.117
We want the diff to expose the
actual problem and correction,

49
00:02:51.291 --> 00:02:55.331
rather than mixing them with unneeded
source or configuration edits. Next,

50
00:02:55.413 --> 00:02:58.861
open the Markdown preview and follow
the hardware link from the README.

51
00:02:59.186 --> 00:03:01.369
Verify the file and section you reach.

52
00:03:01.752 --> 00:03:04.202
Return and read the handoff
as a new session would.

53
00:03:04.527 --> 00:03:08.741
If it contains a contradictory summary,
the project still has conflicting context.

54
00:03:09.020 --> 00:03:12.398
A link that resolves technically can
still be misleading when its label

55
00:03:12.456 --> 00:03:16.450
or surrounding sentence implies the
wrong source. Write the correction note.

56
00:03:16.624 --> 00:03:20.397
Include the seeded claim,
exact source, relevant location,

57
00:03:20.606 --> 00:03:24.565
corrected claim, affected current
documents, and remaining unknowns.

58
00:03:24.890 --> 00:03:27.142
Explain that the error came from confusing

59
00:03:27.212 --> 00:03:30.312
variants. Keep the note short
enough that another reviewer

60
00:03:30.370 --> 00:03:33.505
can trace the reasoning without
reading the old conversation.

61
00:03:33.830 --> 00:03:37.893
The source supports the identity; your
note explains why the project changed.

62
00:03:38.172 --> 00:03:42.201
Be precise about evidence. This is
a documentation-based correction.

63
00:03:42.526 --> 00:03:46.136
It does not establish that a physical
board was connected, that a build ran,

64
00:03:46.183 --> 00:03:50.258
or that firmware was uploaded. If you
perform an additional software check,

65
00:03:50.432 --> 00:03:53.195
record it separately with its
actual command and result.

66
00:03:53.636 --> 00:03:56.458
A screenshot of the corrected
diff illustrates the edit,

67
00:03:56.667 --> 00:03:59.558
but it is not evidence of an
operation that never occurred.

68
00:03:59.883 --> 00:04:03.679
You can pause now and complete the
challenge. Use the separate exercise

69
00:04:03.725 --> 00:04:08.196
and answer key after your own attempt.
Submit the corrected hardware reference,

70
00:04:08.312 --> 00:04:11.667
updated current links or handoff,
reviewed diff, and source note.

71
00:04:11.992 --> 00:04:15.812
Name one claim that remains unverified
physically. Preserve your starting

72
00:04:15.858 --> 00:04:19.411
copy so you can compare or restart
without deleting useful work.

73
00:04:20.014 --> 00:04:22.778
When reviewing the answer,
look for four qualities.

74
00:04:23.288 --> 00:04:25.703
The source must identify
the exact product.

75
00:04:26.028 --> 00:04:29.465
The correction must preserve the
correct memory configuration and units.

76
00:04:29.976 --> 00:04:31.984
Current dependent guidance must agree.

77
00:04:32.495 --> 00:04:35.665
The evidence note must avoid
claiming a physical observation.

78
00:04:36.048 --> 00:04:38.556
Different wording can
satisfy those criteria.

79
00:04:38.881 --> 00:04:42.039
A polished page that still
contains an unsupported pin mapping

80
00:04:42.364 --> 00:04:45.499
cannot pass simply because its
main memory row is correct.

81
00:04:45.882 --> 00:04:50.305
If the source cannot be opened, record
the access limitation. You can inspect

82
00:04:50.328 --> 00:04:53.962
the release's supplied source notes
and continue organizing the correction,

83
00:04:54.113 --> 00:04:56.702
but distinguish that from
your own live verification.

84
00:04:57.306 --> 00:05:01.915
An unavailable page is a real limitation,
not permission to invent a citation.

85
00:05:02.611 --> 00:05:04.898
The next action should
name the exact missing

86
00:05:04.956 --> 00:05:08.799
check so another session can finish it
without repeating the whole investigation.

87
00:05:09.008 --> 00:05:13.269
This challenge demonstrates why a small
knowledge base needs maintenance. A stale

88
00:05:13.327 --> 00:05:16.938
fact can survive in a handoff even
after the main table is corrected.

89
00:05:17.449 --> 00:05:21.199
Naming a source of truth, checking
dependent context, and preserving

90
00:05:21.269 --> 00:05:25.019
history with clear scope prevent
that error from quietly reappearing.

91
00:05:25.344 --> 00:05:28.780
The same approach applies to a
library version, a timer assumption,

92
00:05:28.826 --> 00:05:31.311
or a changed requirement
in your own project.

93
00:05:31.694 --> 00:05:35.676
Finish with the module quiz and read
the explanations for any missed answers.

94
00:05:36.117 --> 00:05:39.925
Four correct answers out of five is
the recommended self-check target,

95
00:05:39.983 --> 00:05:44.093
and retry is welcome. Quiz progress
is separate from the practical

96
00:05:44.163 --> 00:05:47.286
artifact. What matters in the
challenge is that you can defend

97
00:05:47.332 --> 00:05:49.828
the correction from source
to claim to consequence,

98
00:05:50.072 --> 00:05:54.287
while stating exactly what the available
evidence does and does not establish.