Paragraph Numbering

format_list_numberedGuideline

Like sections in a legal code — each plan gets a stable, hierarchical §-number.

Rule

Every plan receives a stable, hierarchical §1.2.3-number that reflects its position in a chapter tree. Plans are organized by thematic chapters, not creation order. §-numbers are never reused.

Why

Sequential IDs like EXP-042 give no structural context — you cannot tell at a glance which area of the project a plan belongs to. A hierarchical §-number groups related plans by domain.

How

Define project-specific chapters in context/plans/chapters/. Assign each new plan the next free §-number within its chapter. Use the §-number as the plan's primary identifier.

Concept

§1      Top-level chapter (thematic area)
§1.2    Sub-chapter (topic within the area)
§1.2.3  Concrete plan (actionable work item)

Hierarchy Rules

Rule	Detail
Tree-structured	New children appended at the end. Gaps allowed; numbers never reused. No letter suffixes.
Maximum 4 levels	§1.2.3.4 is the deepest. Beyond that, split into a parallel chapter.
No leading zeros	§1.2.3, not §01.02.03
Never reused	Deleted plans retain their number as `DEPRECATED_*` so old references don't break.
May be reorganized	§-numbers are documentation anchors, not runtime IDs — may change during restructuring.

File Naming

Plans:

§<number>_<slug-with-hyphens>.<type>.md

Type suffixes: .ctx.md · .exp.md · .prd.md · .task.md

Example: §1.2.3_static-asset-server.exp.md

Chapter Levels

Level	Example	Meaning
Top-level	§1	Major thematic area (Infrastructure, UI, Data)
Sub-chapter	§1.2	Topic within the area (Deployment, Auth)
Plan	§1.2.3	Concrete, actionable plan
Sub-plan	§1.2.3.4	Fine-grained task — use sparingly

menu_book guidelines/paragraph-numbering.mdopen_in_new