Projects Feature for Mission Control

SpecDraftJAM-25Created Apr 4, 20268 min readFull screen ↗

Projects Feature for Mission Control

Exec Summary

*Pending rewrite after problem statement is approved.*

1. Problem Statement and Goal

Problems

1. I'm running multiple concurrent initiatives with no way to see them as separate streams. Right now I have UAS market research, Mission Control development, OpenClaw infrastructure, job search tooling, and consulting projects. They all share one flat board. When I sit down to work on MC, I'm looking at UAS research tasks. When I'm thinking about Lantronix strategy, job search bugs are in the way. The board shows me everything at once, but I rarely need everything at once. I need to focus on one initiative and see its full picture without the noise of the others.

2. I can't answer "how is this initiative going?" without manually counting. If someone asks me the status of the UAS intelligence platform, I have to scan the whole board, mentally filter to the relevant tasks, and piece together what's done, what's in progress, and what's left. There's no view that scopes to one initiative and shows me its shape. I'm doing the computer's job in my head.

3. Related tasks don't know they're related. A spec, a research brief, a build task, and a bug fix might all belong to the same initiative, but nothing in the data model connects them beyond the fact that I happen to remember. If I create a new task for MC, I have to manually remember which other tasks are part of the same effort. There's no inheritance, no shared context, no way to say "these 6 tasks are all part of building the kanban board."

4. The tag system is overloaded and inconsistent. Tags are doing double duty: bug, feature, and enhancement are semantic labels about what kind of work something is. Gray tags like mc-board are acting as project identifiers. These are fundamentally different concepts sharing one field, which makes both less useful. I can't filter by project without also seeing label results, and I can't clean up labels without worrying about losing project associations.

5. Planning new work has no natural home. When I want to think about what's next for an initiative, there's nowhere to go. I can look at the full board and try to spot gaps, but there's no project-level view where I can see "here's everything we've done, here's what's in flight, here's what we haven't started." Planning happens in chat and in my head instead of in the tool.

Goal

Mission Control should let me think about work at two levels: the individual task level (what do I need to do next?) and the initiative level (how is this stream of work progressing, and what's left?). The system should make it easy to switch between "show me everything" and "show me just this project" so I can focus when I need to focus and zoom out when I need the big picture.

2. Success Metric

When I sit down to work on a specific initiative, I can scope MC to just that initiative's tasks in one action. When I want to check on overall progress across all initiatives, I can see a summary view that tells me the shape of each one without opening individual tasks. When I create a new task, associating it with the right initiative is obvious and fast, not something I have to remember to do manually.

3. Current State

Tasks support tags, but project identity is not first-class
Gray project-like tags exist on some tasks, but are mixed with other labels
No projectId or project field on task objects
No Projects page or Projects list in MC
Pete explicitly does not want teams or project-level status tracking
Linear deconstruction research completed: artifacts/research_linear_ui_deconstruction.md

4. Platform Capabilities

MC already has:

Task data model persisted in mission-control/data/tasks.json
Board and list views
Filtering concepts in code (status grouping, list/board toggle)
Task editor modal with metadata fields

Missing:

Separate projects data model
Project selector UI
Board/list filter for project
Dedicated Projects directory view

5. Community Patterns

Linear uses projects as first-class containers for issues, with their own page and metadata. Notion uses databases and relation fields. Shortcut uses epics. Height uses projects with smart grouping. The common thread: projects give one level above tasks for grouping and filtering.

For MC, the right pattern is the thinnest useful slice: a project object with name, optional description/color, and task membership. Nothing else.

6. Options

Option A: Keep using tags, add a project filter

Treat some tags as projects and add a filter dropdown.

Pros: Minimal data model change. Cons: Still conflates projects with semantic labels. Hard to keep clean. Weak foundation.

Option B: First-class projects, no project page

Add a projectId on tasks and a filter dropdown in board/list view. No separate Projects page.

Pros: Solves filtering. Cons: No overview of all projects. Feels half-built.

Option C: First-class projects + Projects directory

Add a small projects data model, task-to-project assignment, a Projects view with cards and task counts, and a project filter in board/list.

Pros: Complete enough to be useful, still lightweight. Cons: More UI work than B.

7. Recommendation

Option C. Pete explicitly wants both project overview and board filtering by project. That means first-class projects plus a directory page.

Scope boundaries

This is intentionally not a full Linear projects system.

Include:

Project object with name, description optional, color optional
One project per task
Projects directory page
Filter board/list by project
Show project on task card/detail

Do not include:

Teams
Project status/health/progress percentage
Due dates or lead fields at project level
Nested projects
Project comments/activity feed

Project data model

New file: mission-control/data/projects.json

json

[
  {
    "id": "proj-mc-board",
    "name": "Mission Control Board",
    "description": "Task board UX and workflow improvements",
    "color": "purple",
    "createdAt": "2026-04-04T00:00:00.000Z",
    "updatedAt": "2026-04-04T00:00:00.000Z"
  }
]

Task model change:

json

{
  "projectId": "proj-mc-board"
}

One project per task. Simple wins.

UI surfaces

1. Projects directory page

A new /projects page showing project cards:

┌─────────────────────────────┐
│ Mission Control Board       │
│ Task board UX improvements  │
│ 6 tasks · 2 in progress     │
└─────────────────────────────┘

Each card shows:

Project name
Optional description
Total task count
Count in progress / needs review
Click to open filtered board/list view

2. Project filter in Tasks view

Top of board/list view gets a simple project filter:

All Projects
Mission Control Board
UAS Research
Backup & Infra
etc.

Selecting a project filters visible tasks in both board and list views.

3. Task cards and detail view

Task card: optional small gray project pill under title or in metadata row
Task editor: project selector dropdown
Detail view: project pill, clickable

Migration strategy

Convert existing gray project-like tags into projects where appropriate. Examples:

mc-board → project: Mission Control Board
uas-intelligence → project: UAS Strategic Intelligence Platform
workspace-backup → project: OpenClaw Backup & Infra

Keep semantic labels (bug, feature, enhancement) as tags. Projects move out of tags and into projectId.

8. Security Considerations

None. Same task data, new grouping field.

9. Pete's Setup Checklist

None.

10. Implementation Scope

David builds:

Projects data model

mission-control/data/projects.json
Read/write store helpers
Type definitions for ProjectItem

Task model update

Add optional projectId field
Preserve backward compatibility for tasks without project

Projects page

Route: /projects
Card/grid view of all projects
Task counts per project
Click-through to filtered task board/list

Task editor update

Add project selector dropdown
Show current project if assigned

Board/list filter

Filter dropdown at top: All Projects + each project
Applies to both board and list layouts
Persist selected filter in URL if easy (?project=proj-mc-board)

Migration script

Create initial projects from existing project-like tags
Move matching tasks from tag → projectId
Preserve semantic tags

11. Validation Criteria

Pete can create and edit projects
Pete can assign a task to a project
Filtering by project shows only matching tasks
Projects page shows all projects with correct task counts
Tasks without project still render correctly
Existing semantic tags remain untouched

12. Test Plan

Test 1: Projects page

Open /projects
Verify project cards render with name, description, task counts
Pass: Directory is readable and counts match task data

Test 2: Task assignment

Open a task in the editor
Assign it to a project
Save and reopen
Pass: Project persists on the task

Test 3: Filtered board

Select one project from the filter dropdown
Verify only that project's tasks are shown
Switch back to All Projects
Pass: Filter works both directions

Test 4: Migration integrity

Run migration on current tasks
Verify semantic tags (bug, feature, enhancement) still exist
Verify project-like tags became projectId
Pass: No data loss, tag semantics preserved

Test 5: Project counts

Compare project card counts to actual tasks in tasks.json
Pass: Counts are accurate

13. Category

Tool - new lightweight organizing layer inside Mission Control

14. Context Loading

Build time: this spec + Linear UI deconstruction research + current task model
Runtime: projects.json + tasks.json

15. Guardrails

Do not add teams, project health, or project-level status tracking
One project per task only
Preserve existing semantic labels and priorities
Project feature must not break board/list performance
Back up tasks.json before migration

16. Handoff

David builds projects model, page, filter, and task editor selector
Vinny validates migration + filter behavior
Vinny moves to needs-review, assigns to Pete