DR-003: Mission↔Monday.com schema Option D¶

Status¶

Accepted — 2026-04-14 · CEO-approved after multi-session plan-mode deliberation with Jordan as Orchestrator

Context¶

CLAUDE.md v1.2.3 Section 10A.8 said "Mission = parent item. Features = sub-items." But "sub-items" was ambiguous in Monday.com context: 1. Native Monday sub-items (nested items inside a parent with an auto-generated sub-board) 2. Board-relation-linked Tasks (items on the separate Tasks board linked to a parent Epic via epic_tasks)

The existing 4-board hierarchy uses board_relation. The Council Review Mission brief used the word "Sub-items" explicitly. Both readings were defensible, but they produce radically different schemas.

Additionally, Section 10A.9 defined /Claude/missions/{id}/qa/ and knowledge-base.md as file-based governance artifacts — which contradicted the "sub-items" listing in the Council Review brief that included qa-scrutiny, qa-user-testing, and mission-closeout as Monday.com items.

Jordan caught both the ambiguity and the contradiction during plan mode.

Decision¶

Option D: Worker Features live as Tasks on the Tasks board linked via epic_tasks board_relation. Validation activities live as Tasks on the Tasks board as well, with their deliverables being QA Report files in /Claude/missions/{mission-id}/qa/. Mission closeout is a note in knowledge-base.md triggered by flipping the Epic's Mission Phase column to Close.

Schema changes required: - 6 new columns on the Epics board: Mission ID, Mission Phase, Sponsoring Exec, Orchestrator, Mission Risk, Target Close - 2 changes on the Tasks board: new Target Assertions text column + append Validation value to existing task_type dropdown - Validation Contract lives in the existing epic_description long_text field with a ## Validation Contract section header - No native Monday sub-items, no new sub-boards, no changes to Roadmap or Sprints boards

Alternatives considered¶

Option A — Native Monday sub-items¶

Mission Features as nested sub-items inside the parent Epic.

Rejected. Required ~200-500 lines of greenfield sub-item logic in the live monday_sync.py production runtime (which has zero sub-item support). Worker retrieval pattern would change (workers querying both Tasks board AND sub-items). Sprint planning visibility required adding Target Sprint column to sub-items sub-board.

Option B — Tasks via epic_tasks (reinterpret "sub-items" as board_relation)¶

Worker Features as Tasks, validator activities as Tasks, closeout as Task.

Rejected in favor of D. B was correct on the Task-shape for work items, but wrong on validator activities and closeout: it treated governance events as Tasks when CLAUDE.md Section 10A.9 already defined them as file-based artifacts. B and A had the same contradiction — they put governance artifacts in Monday.com when they should be in the vault.

Option C — Hybrid (worker features as Tasks, orchestrator-meta as native sub-items)¶

Mix of both patterns depending on item type.

Rejected. Two patterns instead of one. More cognitive load. Monday.com audit queries become more complex. Hooks must understand both patterns. Semantic cleanness not worth pattern complexity.

Option D — Tasks via epic_tasks + file-based governance events¶

Accepted. Honors CLAUDE.md Section 10A.9's existing file-based artifact definitions. Single pattern for all Monday.com work. Worker retrieval unchanged. Sprint planning native. Minimal production runtime changes (~50 lines, not 200-500). Governance artifacts stay in the vault where they're auditable and git-trackable.

Consequences¶

What becomes easier: - monday_sync.py integration (existing patterns extended, not rebuilt) - Worker retrieval (single query surface) - Sprint planning (native via task_sprint) - CoS audit queries (filter Tasks board by parent Epic's Mission ID) - Hook enforcement (single pattern to watch) - Governance artifacts stay in vault (Section 10A.9 honored)

What becomes harder: - CLAUDE.md Section 10A.8 wording pass required (v1.2.4 bump — executed 2026-04-14) - Council Review Mission brief reword required (4-line sub-items listing swapped) - chief.staff's early scaffolding at /Claude/system/sops/SOP-EXEC-council-review-v1.0.md may need alignment check

Trade-off accepted: Two governance doc edits in exchange for architectural coherence with Section 10A.9 and the existing production runtime.

During final review, chief.staff proposed two refinements to Jordan's Option D that were folded in:

Validator activities should be Tasks, not just file materializations. Each validator gets a Task on the Tasks board assigned to the validator agent. The Task's deliverable is the QA Report file in /qa/. Task closes when the file exists with Confidence: HIGH. This gives operational visibility + dispatchability while preserving file-based governance artifacts.
Mission closeout tracks via the Mission Phase column on the Epic, not a separate Task. When all worker Tasks are Done and all QA Reports are HIGH confidence, the Orchestrator flips Mission Phase to "Close" and writes the closeout note in knowledge-base.md. The Epic column IS the state signal.

Implementation status¶

Schema fields live on Monday.com — Rick added all 6 Epic columns + 2 Task changes on 2026-04-14
Smoke test HIGH confidence — Jordan ran 8-step test: create Mission Epic + worker Task + validator Task → cross-check both directions → phase-flip to Close → teardown. Clean.
Column IDs cached at /Claude/scripts/integrations/monday/dev/.mission-columns.json for future runtime integration
CLAUDE.md v1.2.4 wording pass applied — Section 10A.8 rewritten, Council Review Mission brief reworded

[[CLAUDE]] Section 10A.8 (v1.2.4 wording) — the governance rule this decision produced
[[project.manager/schema-design-v1]] — Jordan's full 12-section schema document
[[M-2026-0414-council-review-sop-authoring/task-brief]] — first Mission to execute under this schema
[[scripts/integrations/monday/]] — runtime integration code (dev + runtime variants)
Plan mode session record at /Users/rhartley/.claude/plans/crispy-twirling-dolphin.md

Date: 2026-04-14 · Author: project.manager (Jordan) · Approved by: ceo · Stakeholders: ceo, chief.staff, project.manager