Describe issue phases, planning, and relationships

[MariusStorhaug]

Once the issue guidance has an OKF Process subtree, it needs concise pages that explain how an issue evolves through the existing workflow, when planning introduces Why/How/What detail, and how native relationships distinguish containment from order.

Request

Add Lifecycle, Planning, and Relationships pages under Issues/Process/, and reduce the universal Format page to rules shared by every type. Link to Workflow for phase definitions rather than restating it.

Acceptance criteria

• Lifecycle maps issue-body, type, readiness, and relationship changes onto Capture, Refine, Plan, Build, Review, Ship, and Operate
• Workflow remains the sole owner of phase definitions
• Planning explains progressive Why/How/What decomposition without duplicating spec/design ownership
• Relationships defines native sub-issues as containment and progress
• Relationships defines native blocked-by/blocking edges as execution order
• Ready siblings without dependency edges are explicitly eligible for parallel execution
• Manual Parent:, Blocked by:, child-link lists, and list-order sequencing are rejected as duplicate sources of truth
• Format contains only universal issue rules and routes type-specific guidance to the Types subtree
• Process index, links, lint, clean build, CI, and Copilot review are green

---

Technical decisions

Phase ownership: Workflow.md defines the phases. Lifecycle states only what happens to issues as they pass through them.

Planning altitude: Epic carries strategic Why and outcome-level What; PBI carries delivery-level How and bounded What; Task/Bug carries the concrete deliverable and implementation decisions. Each child still explains its local purpose and acceptance criteria.

Native relationships: GitHub relationships are authoritative. Prose records rationale, never a second relationship graph.

---

Implementation plan

Process pages

• Add Lifecycle with phase-specific issue evolution and gates
• Add Planning with Why/How/What decomposition rules
• Add Relationships with containment, sequence, and parallelism rules
• Reduce Format to universal rules and type-page routing

Validation

• Verify Process index and all internal links
• Run documentation checks, CI, and the Copilot review loop

[MariusStorhaug]

Implemented the Process-page scope in commit e1d9e60 and opened the draft pull request. Lifecycle, Planning, Relationships, and the reduced universal Format page are now present. Validation remains open while navigation is added and the parallel Types targets are serialized from the live default branch.

[MariusStorhaug]

Completed final validation after integrating PR #93 into PR #94 as requested. Merge commit f077ba3 added the canonical type targets; review fixes b872f08 and 2c3d91b clarified delivery-leaf ownership, Process metadata, and PBI wording. Documentation indexes update and check cleanly, all links resolve, the clean Zensical build reports no issues, Build/Links/Lint CI pass, every review thread is resolved, and the fresh Copilot round at 23:37:10Z produced zero new comments.

[MariusStorhaug]

Reopened the final validation checklist after the user-directed merge of PR #93 into PR #94. The combined branch is green and Copilot-clean, but #94 remains draft until #93 independently merges and live main absorbs the Types scope. Final Process-only validation, CI, and review will run again after that reconciliation.