Build a dependency table from N01–N10 before proposing milestones. Preserve the stated access gate for screenshots and keep the final reviewer and draft date open.
In this guide
Which dependencies are stated in the N-note project?
The Markdown map groups ten notes into confirmed scope, agreed actions, open questions, and ideas. Access restoration and reviewer confirmation remain questions; they are not newly assigned work items. The accompanying dependency table can record the explicit N09 access condition without upgrading N10 into an action. When the client names a reviewer, add a new sourced decision rather than silently rewriting the original note.
| Item | What the note establishes | Dependency / status |
|---|---|---|
| Draft checklist / N02 | Maya owns the draft; no due date agreed | Do not infer an access gate for drafting |
| Collect screenshots / N09, N10 | Omar collects them after access is available | Access unconfirmed; owner of restoration not supplied |
| Final review / N05 | Ask who approves the final version | Reviewer unknown; still a question |
| Welcome video / N04 | Suggestion only | Not approved first-version work |
How do you map the notes without inventing work?
- Read project-notes-example.md and keep each N-prefixed source ID with its statement.
- Put N01, N03, and N08 under confirmed scope; N02 and N09 under agreed actions.
- Keep N05, N06, N07, and N10 as open questions. N04 remains an idea.
- Attach the explicit access prerequisite to the screenshots row. Leave the restoration owner and reviewer unspecified until the team supplies them.
- Record each new answer before assigning dates or changing scope.
What can a tree-shaped map show?
The four branches organize the status of the notes; they do not compute a schedule. A table is better for several prerequisites attached to one task. Markmap renders the Markdown hierarchy supplied by the editor, so a neat connection does not establish a dependency the notes never stated.
The meeting-transcript exercise is separate: T02 includes a Friday draft condition, whereas N02 has no agreed due date. Mixing those fixtures would turn a condition from another example into a false project commitment. Keep the two source files and their ID prefixes visible when comparing them.
Request the table from these notes
Use only project notes N01–N10. Return: item, stated dependency, source IDs, owner if supplied, and open question. Keep questions separate from assigned actions. Use N09 for the screenshots access condition. Leave N02 draft date and N05 reviewer open. Do not import dates from the T-prefixed meeting exercise. Ask what needs confirmation before proposing milestones.
What changes when the client answers?
Add the response as a new source record with its date and authority. If the client identifies the reviewer, update that question into a confirmed decision and connect it to the actual review task. Retain the prior version so the team can see what changed. Do not rewrite N05 as though it originally named someone.
For a later schedule, gather availability, effort, and any acceptance gate from the people doing the work. The original notes do not provide those values. Review a proposed sequence with the team and label suggested dates as tentative until they agree the commitments.