Writing principles

Voice and tone:

Active voice only. Name who acts (the user, a worker, an external system)—not which module "handles" something
Plain prose first. Module and function names belong in the story only when they are the clearest way to say it
Do not open beats with a module as the subject ("A registrant saves facts in BusinessInformationComponent")—say what the user or system does, then anchor the beat with a link

Narrative flow:

Start at the recognizable entry point (user-facing feature, API, or main job)
Follow work through layers that matter for this specific issue, no further
Proceed chronologically: who does what, what runs first, how outputs become inputs downstream
One main beat per paragraph (or short sequence). Each beat is a skimmable step in the story; the reader should grasp the flow without clicking anything

Beat anchors:

At each main beat, embed one markdown link on the word or short phrase that best names the action or decision point in plain English—e.g. "When the user submits the business information step of campaign registration…"
The link target is always a resolved path in the codebase (see Code references). Never use a ticket, issue, PR, or doc URL as the beat anchor—even when a Linear or GitHub issue motivated the spike. Read the ticket for context; link the code you traced.
The link label is whatever reads naturally in the sentence (often a verb or short phrase), not a module name, file path, or Module.function string
Surrounding context stays unlinked: "business information step" and "campaign registration" do not need links unless that beat is specifically about them
Do not litter the paragraph with links for every helper, callback, or symbol you could name

spike