Projects in Play and Next Steps

This is the current working snapshot of active projects, open issues, and recommended next steps as of April 1, 2026.

Priority Order

This is the current order that I think gives you the most value.

1. Mission Control needs to become useful

This is the biggest leverage item.

Right now too much of Mission Control is placeholder UI. If it becomes genuinely useful, it turns into the operating surface for planning, review, automation visibility, and future project tracking.

Your stated goals for this work:

• make tasks functional
• make projects functional
• remove Runs
• remove Tools
• improve Automation UI
• make Settings actually useful
• make Dashboard actually useful

My recommendation:

• do not try to activate a fancy full task/project system right away
• start by making a few surfaces actually useful instead of making everything exist in placeholder form
• focus on the smallest set of changes that create daily value

Future consideration: friendly URL

The current Tailscale URL (vinnys-mac-mini.tail31784c.ts.net:3100) is ugly in shared links. Options to explore later:

• Custom subdomain like mc.mauroz.com pointed at Mission Control
• Tailscale device rename for a slightly cleaner hostname
• Full custom domain with HTTPS and access control

Not worth its own spec yet. Revisit when Mission Control is further along and link sharing becomes more frequent.

Suggested first slice:

1. Dashboard shows real useful information, not placeholders
2. Automation page becomes the best place to understand cron/jobs/status
3. Settings page controls real behavior that matters
4. Remove or hide Runs and Tools if they are noise
5. Only after that, decide whether Tasks and Projects should become lightweight and useful, or stay minimal for now

Why this is first:

• it affects your daily operating environment
• it reduces friction across everything else
• it is a product-shaping decision, not just cleanup

2. New functionality workflow via specs in Mission Control

Current state

We established a spec-first workflow for new functionality.

Default process now:

1. Vinny researches and writes a spec as a Mission Control artifact
2. Vinny sends Pete a deep link to the artifact
3. Pete reviews and iterates on the artifact
4. After Pete approves, the artifact is marked approved
5. Only then does David build

Why it matters

This gives you a readable review surface and keeps planning out of fragile chat scrollback.

Suggested next steps

1. Use this on the next real feature request
2. Keep specs lightweight for small changes
3. Continue using artifact deep links, not chat-only summaries

3. LinkedIn post writing

Current state

A LinkedIn post writer exists, and we created a spec for it as a test of the new workflow.

Related artifact:

• LinkedIn Post Writer spec:

http://vinnys-mac-mini.tail31784c.ts.net:3100/artifacts/spec_linkedin_post_writer

Important nuance

You have not reviewed the spec yet. You also already have a GPT outside the system that can help with LinkedIn writing, so this is useful but not urgent infrastructure.

My take

This still matters because you have been meaning to write a LinkedIn post. But it is probably not the first systems project to push on if Mission Control is still mostly placeholder.

Suggested next steps

1. Review the LinkedIn spec artifact
2. Decide whether the skill is good enough to use now or whether your outside GPT is the better temporary tool
3. If you want quick momentum, write one actual LinkedIn post soon, regardless of which tool you use

4. Content ideas capture pipeline

Current state

#content-ideas is set up and appears wired correctly.

Verified:

• channel exists under PROJECTS
• Vinny is active there without requiring mention
• David is blocked there
• tracker file exists
• automated workflow rule exists in AGENTS.md

Why it matters

This looks like one of the easiest things to test quickly, and it connects directly to LinkedIn writing.

Suggested next steps

1. Drop one real link or idea into #content-ideas
2. Verify capture, tagging, summary, and tracker update
3. If capture works, use that item to draft a LinkedIn post

My take

You are right, this seems like an easy one to test. It is a good short win.

5. Cron and channel routing hygiene

Current state

You reported LinkedIn engagement content leaking into job-search related output.

David traced and fixed the stale session contamination risk:

• LinkedIn Invite Scan was already targeting #linkedin-engagement
• stale Browser Relay Check jobs were still pinned to the old #job-search session context
• those stale bindings were removed

Why it matters

Channel hygiene is trust hygiene. If routing is sloppy, every feed becomes suspect.

Suggested next steps

1. Watch the next 5:45am Browser Relay Check and 6:00am LinkedIn Invite Scan once
2. Confirm no LinkedIn-adjacent content appears in job-search surfaces
3. If clean, mark this closed

6. Gmail Pub/Sub inbox flow

Current state

The Gmail monitoring pipeline works end to end.

Confirmed:

• Gmail watch is set up
• Pub/Sub push path is working
• OpenClaw hooks are receiving events
• a test email was summarized into #openclaw-infra

Remaining issue

The model routing is not clean yet. It is still attempting Anthropic first instead of going directly to the intended cheap fast model.

Suggested next steps

1. fix the model routing so Gmail triage goes straight to the cheap fast model
2. retest with multiple emails
3. improve summary formatting only after routing is stable

My take

Useful, but not top-priority unless email triage is becoming part of your daily workflow right now.

7. Browser relay reliability

Current state

The recent browser issue was two separate problems:

• a real Discord pairing approval issue
• stale profile references using chrome instead of chrome-relay

Both were fixed.

Suggested next steps

1. watch for recurrence
2. if it happens again, trace the exact triggering workflow
3. longer-term, revisit this once OpenClaw browser workflows move away from relay dependence

8. Mission Control artifact workflow

Current state

Mission Control is now the default place for persistent specs and working docs.

Important rule:

• always share the direct Tailscale deep link to the specific artifact, not just the artifacts index

Suggested next steps

1. keep using artifact deep links every time
2. publish future specs and working docs as artifacts by default
3. if this becomes your standard mode, define a simple artifact naming convention

What feels done enough for now

Done enough

• Vinny vs David operating model
• browser pairing/profile incident fix
• content-ideas setup work
• artifact deep-link pattern

I removed the operating model as a live project because you said to consider that done.

Recommended next actions

If I were picking the next moves for maximum value, I would do them in this order:

1. Create a Mission Control spec artifact

Not build yet. Spec it.

Focus the spec on:

• what Mission Control should be for you day to day
• what should be removed
• what should become functional first
• what can stay intentionally minimal for now

2. Test #content-ideas

This is the easiest fast validation.

3. Review the LinkedIn post writer spec

Then decide whether to use the system tool now or keep using your outside GPT temporarily.

4. Verify the cron/channel routing cleanup tomorrow morning

One clean cycle should be enough to restore confidence.

5. Clean up Gmail model routing only if it matters this week

Otherwise keep it parked.

Short version

Highest-value project

• make Mission Control actually useful

Easiest quick win

• test #content-ideas

Important but not urgent

• LinkedIn post writer review and first real use
• Gmail routing cleanup

Watch item

• confirm job/engagement routing stays clean tomorrow morning

Recommendation

The next single best move is: write the Mission Control spec artifact.

Reason: that project is broad enough that if you do not shape it deliberately, it will sprawl. A spec will force the useful question: what should Mission Control actually do for Pete, right now, with the least complexity?