Restructure issue guidance as an OKF section

[MariusStorhaug]

MSX issue guidance currently spans overlapping format and hierarchy pages, while related workflow, readiness, branching, goal-setting, and pull-request pages make assumptions that apply only to delivery leaves. Agents must assemble the model across several documents, and the live organization configuration has not yet been fully reconciled with the intended Epic → PBI → Task/Bug hierarchy.

Request

Create one recursively navigable OKF issue-guidance section that explains how issues evolve through the existing workflow, how each native issue type is structured, and how containment differs from execution order. Align the surrounding ways-of-working guidance and migrate live issue metadata so the documented model and GitHub configuration agree.

Acceptance criteria

• Epic and PBI are native enabled organization issue types; Task and Bug remain delivery-leaf types
• Issue guidance is organized as small frontmatter-bearing pages under generated indexes
• Workflow remains authoritative for Capture, Refine, Plan, Build, Review, Ship, and Operate; issue pages map body and relationship evolution onto those phases
• Epic, PBI, Task, and Bug each have a distinct body, readiness, closure, and promotion/demotion model
• Native sub-issues are the source of truth for containment and progress
• Native blocked-by/blocking relationships are the source of truth for sequencing; ready siblings without dependency edges may execute in parallel
• Only Task/Bug delivery leaves receive closing pull requests; operational Tasks have a verified non-PR completion path
• Cross-cutting guidance no longer assumes every issue is a single PR-sized deliverable
• Applicable live Feature assignments and obsolete Bug/Feature hierarchy labels or conventions are migrated before Feature is retired
• Every child issue is complete, documentation checks are green, and no duplicated legacy guidance remains

---

Technical decisions

OKF structure: The issue model is a folder of small pages with title and description frontmatter. Generated indexes route humans and agents by phase, relationship question, and issue type.

Hierarchy: Epic and PBI aggregate scope. Task and Bug are delivery leaves. Nested PBIs are allowed when decomposition requires another aggregation level.

Relationships: Sub-issues express containment only. Blocked-by/blocking relationships express execution order. List position and body text do not imply sequence.

Workflow ownership: Workflow.md remains the only owner of phase definitions. Issue lifecycle guidance describes what happens to an issue during those phases without restating the workflow.

Delivery: Every executable unit has an issue. Repository implementation uses one session, branch, and pull request per Task/Bug. Parent PBIs coordinate and aggregate without owning implementation branches.

Migration: Feature remains enabled until the final migration verifies that no applicable live issue depends on it.

---

Delivery plan

Delivery is tracked through native sub-issues. Sub-issue relationships define scope; dependency relationships define the order in which child work may proceed. The parent closes only after all children and aggregate acceptance criteria are complete.

[MariusStorhaug]

Created the native delivery graph. Sub-issues: bootstrap Task #82, OKF-section PBI #85, cross-document Task #86, and migration Task #90. Dependencies: #82 blocks relocation #89; #89 blocks the parallel Process #88 and Types #87 Tasks; #87 and #88 both block #86; #86 blocks #90. Containment and execution order are represented only through GitHub relationships.

[MariusStorhaug]

Bootstrap Task #82 is complete via merged PR #83 (d4c4a15). Relocation Task #89 is now unblocked and has started from live origin/main (92d25fc) in its own coordinated delivery session. Process #88 and Types #87 remain correctly blocked until #89 merges.

[MariusStorhaug]

Relocation Task #89 is implemented in PR #91 at commit 2215cae. The atomic path/navigation cutover, complete inbound-link update, local validations, CI, and explicit clean Copilot review are complete. The PR is ready with squash auto-merge enabled and waits only for independent approval; #87 and #88 remain blocked until it merges.

[MariusStorhaug]

Relocation Task #89 completed via merged PR #91 (3e04c260). Parallel sibling Tasks #87 (Types) and #88 (Process) have now started from that live default-branch commit in separate coordinated sessions with strict subtree ownership. Cross-document Task #86 remains blocked until both merge.

[MariusStorhaug]

Parallel implementation exposed one genuine serialization edge: Process #88 links to the canonical type pages created by Types #87, so #88 link CI cannot pass before #87 lands. A native dependency now records that merge order. Development remains parallel; #86 still waits for both completed Tasks.

[MariusStorhaug]

Parallel implementation exposed one genuine serialization edge: Process #88 links to the canonical type pages created by Types #87, so #88 link CI cannot pass before #87 lands. A native dependency now records that merge order. Development remains parallel; #86 still waits for both completed Tasks.

[MariusStorhaug]

Types Task #87 is complete in PR #93 at head 6c48e9b: all local checks and CI pass, the valid first Copilot finding was fixed, a fresh Copilot round is clean, and squash auto-merge is enabled. Independent approval is the sole remaining gate. Process #88 stays draft and natively blocked until #87 merges.

[MariusStorhaug]

Baseline correction for the parallel Tasks: 3e04c260 is the required merged #89 blocker ancestor, not their branch base. Both #87 and #88 fetched first and started exactly at then-live origin/main 39411c555adfde1e357be44f63ccddc11e95fc73, which includes unrelated PR #92 and has no overlap with either issue subtree or their Zensical subsections. The earlier execution-order statement remains correct; this comment corrects only the exact starting SHA.