A useful project notebook has to survive the moment when you forget what you meant. In this lesson, we will make a small Markdown page that another person can read, navigate, and use. We will check both the text we type and the page that the reader sees. You need the Sensor Monitor exercise folder and your editor. You do not need a physical board for this work.

Open the project README. Notice that it is a plain text file. The hash marks, backticks, brackets, and vertical bars are visible in the source. A Markdown renderer gives some of that punctuation a structural meaning. A heading becomes a heading. A fenced block becomes a block of code. The source and the rendered page are two views of one document, and both deserve review.

Start with one title for the document. Use a single hash mark, a space, and Sensor Monitor. Below it, write one sentence explaining the purpose. A useful version says that this baseline prints a fixed synthetic report on the computer. Shared policy arrives at checkpoint five. That sentence tells the reader what they can accomplish. It also prevents them from assuming that a physical sensor is required before they can begin.

Now add a second-level heading for the first check. Two hash marks create that level. Keep the heading descriptive. Run synthetic replay is more helpful than More information because it names an action. Leave a blank line before the paragraph that explains the action. Consistent spacing helps people read the source and reduces surprises when another renderer processes the document.

Before the command, tell the reader where to run it. In this project, the starting point is the Sensor Monitor root, the folder containing scripts, docs, host, and firmware. The working directory is part of the instruction. A correct relative path can fail when the terminal is in a different folder. That is a documentation problem you can prevent with one clear sentence.

Put the supplied replay command inside a fenced code block. The opening line has three backticks followed by the word PowerShell. The closing line has three backticks. Copy the command from the written lesson so that its punctuation remains exact. Do not include the terminal prompt in the block. A prompt shows where a command was entered; it is not part of what the learner should execute.

The language label tells the renderer and the reader what kind of text follows. It does not run the command, check the script, or establish that tests passed. Those are separate actions. The supplied dot cmd wrapper is reviewable course code and should be used with the documented setup. If your environment blocks it, preserve the message and follow the approved setup path instead of changing broad machine settings.

Add a relative link to the hardware reference. The visible label should say hardware reference, and the destination should be docs slash hardware dot md. From this root README, that path points into the docs folder. A descriptive label tells the reader why they might follow the link. A label that says click here loses that meaning when read out of context.

Now add a small table with three columns: action, establishes, and limitation. In the first row, use baseline host replay as the action. Explain that it builds and prints the fixed synthetic report, without establishing electrical behavior. In another row, distinguish firmware compilation from successful physical operation. The rows are genuinely comparable, so a table helps. A long troubleshooting explanation would be easier to read as ordinary prose under a heading.

Open the Command Palette and search for Markdown: Open Preview to the Side. You should now be able to compare the source with its rendered result. Inspect the title, the second-level heading, the command block, the link, and the table. Do not judge only whether the page looks attractive. Ask whether a reader can find the next action and copy exactly the text they need.

We will introduce a small fault in the exercise copy. Remove the opening fence from the command block and inspect the preview again. Depending on the surrounding text, the command can lose its intended presentation or affect the material that follows. The important observation is that a tiny source change can alter how the reader interprets the procedure. Restore the fence and compare the result.

Next, follow the hardware link from the preview. Check the opened file's identity. A link is not correct merely because something opens; it must open the intended document. Return to the README and consider the same link from a nested document. Relative paths start from the document containing them, so a path that works here may need adjustment in a handoff under the docs folder.

Copy the command from the preview and inspect the pasted text before execution. Confirm that no prompt, closing punctuation, or explanation came along. If your tools are ready, you can run the documented check and record the actual outcome. If they are not, finish the formatting and link checks and leave execution explicitly open. Expected output and observed output belong to different evidence categories.

Your exercise is to create a page with one title, two useful headings, an ordered procedure, the command, the relative link, and the small evidence table. Introduce and repair one formatting fault. Save a brief note saying what failed, what you changed, and which checks you actually performed. You can pause here and complete that work before continuing.

When reviewing your result, explain why both views matter. The source preserves exact syntax and paths. The preview shows the reading and copying experience. A screenshot can illustrate either view, but it cannot replace selectable commands and a clear explanation. This is the beginning of a notebook that helps someone reproduce the work, including the future version of you who no longer remembers the setup.