spec

Projects Feature for Mission Control

2026-04-04

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

4. Platform Capabilities

MC already has:

Missing:

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:

Do not include:

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:

2. Project filter in Tasks view

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

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

3. Task cards and detail view

Migration strategy

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

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:

  1. Projects data model
  1. Task model update
  1. Projects page
  1. Task editor update
  1. Board/list filter
  1. Migration script

11. Validation Criteria

12. Test Plan

Test 1: Projects page

Test 2: Task assignment

Test 3: Filtered board

Test 4: Migration integrity

Test 5: Project counts

13. Category

Tool - new lightweight organizing layer inside Mission Control

14. Context Loading

15. Guardrails

16. Handoff