WEBVTT

1
00:00:00.000 --> 00:00:03.866
This challenge asks you to recover
known-good work while preserving a useful

2
00:00:03.924 --> 00:00:08.348
improvement. It combines the GitHub
and recovery habits from this module.

3
00:00:08.789 --> 00:00:12.504
Your result is a small handoff packet
with a clear history and actual

4
00:00:12.574 --> 00:00:16.266
software evidence. The goal is not
simply to make the terminal stop

5
00:00:16.312 --> 00:00:20.155
showing an error or to return the
folder to any state that looks familiar.

6
00:00:20.434 --> 00:00:23.301
Use a new clone of the supplied
generic history bundle.

7
00:00:23.580 --> 00:00:27.017
Keep your earlier practice
project intact. Create a branch

8
00:00:27.051 --> 00:00:30.941
from the prepared FAULT-hysteresis
checkpoint and inspect the current commit.

9
00:00:31.266 --> 00:00:33.774
The history is manufactured
for instruction,

10
00:00:33.924 --> 00:00:36.583
with an isolated bad
comparison at its tip.

11
00:00:36.908 --> 00:00:40.867
That controlled setup lets you practice
recovery without guessing which of many

12
00:00:40.960 --> 00:00:45.059
unrelated commits introduced a problem.
Write down the current folder,

13
00:00:45.093 --> 00:00:49.459
branch, and commit before running a test.
Read the supplied failure description.

14
00:00:49.784 --> 00:00:53.928
The defect concerns clearing at
exactly twenty-seven degrees Celsius:

15
00:00:54.311 --> 00:00:56.633
the strict comparison misses equality.

16
00:00:57.074 --> 00:00:59.385
This is a prepared later-policy example,

17
00:00:59.663 --> 00:01:02.287
not a request to develop
the capstone in this module.

18
00:01:02.612 --> 00:01:06.409
The expected case is provided so you
can judge the recovery independently.

19
00:01:06.850 --> 00:01:10.565
Run the native test command from the
documented root and preserve its real

20
00:01:10.647 --> 00:01:14.838
output. Confirm that the failure
matches the supplied boundary problem.

21
00:01:15.047 --> 00:01:18.379
If the executable does not start
or the compiler is missing,

22
00:01:18.553 --> 00:01:22.280
diagnose that setup issue
separately. Do not claim the policy

23
00:01:22.361 --> 00:01:25.948
fault was reproduced when the
program never reached its test cases.

24
00:01:26.332 --> 00:01:30.174
Now identify the useful documentation
improvement you want to keep.

25
00:01:30.453 --> 00:01:33.704
It might be a clearer sentence
stating that all replay inputs

26
00:01:33.774 --> 00:01:37.478
are synthetic. Do not mix that
improvement into the fault reversal

27
00:01:37.547 --> 00:01:41.634
before you understand the starting state.
The challenge is easier to review when

28
00:01:41.669 --> 00:01:44.966
the corrective history and the new
wording have distinct purposes.

29
00:01:45.349 --> 00:01:48.472
Inspect Git status and
both relevant diff views.

30
00:01:48.797 --> 00:01:52.176
If useful uncommitted text
already exists, preserve

31
00:01:52.211 --> 00:01:56.100
it deliberately before any operation
that might discard working content.

32
00:01:56.797 --> 00:02:00.999
For this prepared exercise, save the
useful text in a separate scratch note

33
00:02:01.046 --> 00:02:05.191
outside the recovery copy, so the
isolated fault remains at HEAD.

34
00:02:05.516 --> 00:02:08.685
Confirm the saved text is
recoverable before continuing.

35
00:02:09.068 --> 00:02:12.412
A new preservation commit would
move HEAD and require identifying

36
00:02:12.458 --> 00:02:15.442
the original fault commit
explicitly before reverting it.

37
00:02:15.825 --> 00:02:18.124
Choose the operation
that matches the state.

38
00:02:18.402 --> 00:02:21.967
An unwanted working edit can be
restored when you intend to discard it.

39
00:02:22.292 --> 00:02:26.181
An unwanted staged selection can
be unstaged while keeping the file.

40
00:02:26.506 --> 00:02:30.279
An isolated committed fault can be
reverted with a new corrective commit.

41
00:02:30.662 --> 00:02:31.986
These are different tasks,

42
00:02:32.021 --> 00:02:35.062
and the command options should
follow your intended data change.

43
00:02:35.445 --> 00:02:39.056
For the prepared fault, verify HEAD
once more and create the revert.

44
00:02:39.381 --> 00:02:43.944
Inspect the new history. The bad commit
should remain, followed by its reversal.

45
00:02:44.327 --> 00:02:48.089
You have not rewritten shared history
or pretended the error never happened.

46
00:02:48.472 --> 00:02:52.199
Another reader can follow the problem
and correction as explicit events.

47
00:02:52.582 --> 00:02:57.354
Rerun the same native test command. The
expected result is that the previously

48
00:02:57.423 --> 00:03:01.092
failing boundary now passes along
with the other relevant checks.

49
00:03:01.603 --> 00:03:04.145
Save the actual result and source version.

50
00:03:04.528 --> 00:03:08.394
Then run the firmware cross-build using
the matching target configuration.

51
00:03:08.719 --> 00:03:12.017
A host test and target build
exercise different paths,

52
00:03:12.191 --> 00:03:15.929
so each needs its own result rather than
borrowing confidence from the other.

53
00:03:16.254 --> 00:03:21.084
Apply the useful README clarification
after the recovery and inspect its diff.

54
00:03:21.467 --> 00:03:25.472
Preserve the original technical meaning
and keep synthetic labeling explicit.

55
00:03:25.797 --> 00:03:27.667
If the note changes a build command,

56
00:03:27.876 --> 00:03:30.209
execute that command
from the written context.

57
00:03:30.650 --> 00:03:33.344
If it changes only an
explanatory sentence,

58
00:03:33.495 --> 00:03:35.841
a careful content review may be enough.

59
00:03:36.282 --> 00:03:40.148
Verification should match the claim
instead of repeating a ritual unrelated

60
00:03:40.183 --> 00:03:44.060
to the change. Commit the reviewed
improvement with a descriptive message.

61
00:03:44.304 --> 00:03:46.638
Inspect the resulting history and status.

62
00:03:46.963 --> 00:03:50.910
The final packet should show an
understandable progression: known fault,

63
00:03:51.061 --> 00:03:54.115
recorded reversal, and a
useful documentation change.

64
00:03:54.440 --> 00:03:56.414
A single broad cleanup commit would make

65
00:03:56.437 --> 00:04:00.210
it harder to see what restored behavior
and what improved the explanation.

66
00:04:01.162 --> 00:04:05.121
Now reproduce the corrected committed
source in another checkout. You may use

67
00:04:05.144 --> 00:04:08.557
your private practice remote when
its access is available, or a clearly

68
00:04:08.604 --> 00:04:12.145
identified local clone of the corrected
branch for source reproduction.

69
00:04:12.957 --> 00:04:17.369
Record the actual path. A local clone
does not prove GitHub transport,

70
00:04:17.485 --> 00:04:20.295
and a remote push does not
prove the second folder builds.

71
00:04:20.736 --> 00:04:22.895
Keep those observations separate.

72
00:04:23.220 --> 00:04:26.436
Follow the second checkout's
README and dependency record.

73
00:04:26.819 --> 00:04:30.082
Run the applicable native tests
and cross-build from that root.

74
00:04:30.465 --> 00:04:34.366
This uses the already installed toolchain,
so it checks source and instructions

75
00:04:34.401 --> 00:04:38.035
in the current environment rather
than a completely fresh machine setup.

76
00:04:38.546 --> 00:04:42.343
If a required file was never committed,
the reproduction may expose it.

77
00:04:42.668 --> 00:04:46.963
Correct the omission and repeat the
affected check. Write a concise handoff.

78
00:04:47.138 --> 00:04:50.446
Include the current commit,
what changed, which commands ran,

79
00:04:50.563 --> 00:04:54.289
where their results are saved, known
limitations, and the next action.

80
00:04:54.614 --> 00:04:58.237
Do not say tests passed without enough
information to identify the run.

81
00:04:58.620 --> 00:05:00.222
Do not say the sensor works when

82
00:05:00.246 --> 00:05:03.508
the evidence is synthetic host
behavior and cross-compilation.

83
00:05:03.949 --> 00:05:07.444
Precise scope makes the handoff
more useful, not less complete.

84
00:05:07.885 --> 00:05:11.972
Review the packet against the challenge
rubric. Is the original failure visible?

85
00:05:12.297 --> 00:05:15.641
Was the right operation chosen?
Does useful work remain?

86
00:05:16.151 --> 00:05:19.089
Can another person reproduce
the final software checks?

87
00:05:19.414 --> 00:05:23.268
Are remote and physical claims
accurate? Correct the missing artifact

88
00:05:23.315 --> 00:05:26.914
or affected check without
redoing unrelated completed work.

89
00:05:27.297 --> 00:05:30.304
Treat the handoff as a small
interface for the next person.

90
00:05:30.629 --> 00:05:32.104
Put the current state first,

91
00:05:32.313 --> 00:05:36.121
followed by the evidence needed to
trust it and the next concrete task.

92
00:05:36.504 --> 00:05:40.115
Keep historical diagnosis notes
available through a link rather

93
00:05:40.161 --> 00:05:43.819
than making the reader reconstruct
the present from a long chronology.

94
00:05:44.260 --> 00:05:46.733
A concise handoff can
preserve considerable

95
00:05:46.779 --> 00:05:49.287
work when the original
chat is unavailable,

96
00:05:49.461 --> 00:05:53.490
because it points directly to the source
and results that govern the next decision.

97
00:05:54.094 --> 00:05:58.192
Finish the module quiz after submitting
the packet. You have now practiced

98
00:05:58.227 --> 00:06:01.954
a complete local-to-remote
workflow with review and recovery.

99
00:06:02.395 --> 00:06:07.143
The next module gives the repository
better written context: readable Markdown,

100
00:06:07.387 --> 00:06:11.184
sourced hardware facts, explicit
decisions, and evidence records.

101
00:06:11.625 --> 00:06:14.911
Those documents will help both
people and future agent sessions

102
00:06:15.062 --> 00:06:18.487
resume the project without
depending on an old conversation.