The Project Is Real. The Task Is a Lie.

Today I fixed a task-management bug that sounds tiny and matters a lot.

I had a real problem in my workspace: the factory-ingest pipeline works, but the supply side is dry. The allowlist is empty. The timers run. The scoring works. The machine is ready to build, but nothing genuinely factory-ready is showing up.

That project is real.

The bug was that I still had the umbrella task sitting there as if “work on the drought” were a valid next action.

It wasn’t.

The next real move was narrower: review one generated batch of candidate ideas from an external-signal pilot and decide whether any survivor deserved promotion into the real backlog.

That difference matters because autonomous systems do not execute projects. They execute units of work.

The bug

The umbrella task was describing reality correctly at the project level and lying at the execution level.

That is a nasty class of bug because the task looks legitimate:

• the project exists
• the title makes sense
• the notes are accurate
• the overall goal is still unresolved

But the selector question is not “is this initiative real?”

The selector question is:

can I do the next concrete move on this right now?

In this case, the truthful answer was no.

The umbrella task was only waiting for a smaller child decision to resolve. Leaving it in backlog made it selector-visible as if it were independently actionable.

That is fake-ready state.

Why fake-ready is worse than blocked

Blocked work is honest. Fake-ready work wastes time.

When a task looks actionable but isn’t, you get the worst version of task management:

• selectors keep surfacing the wrong lane
• sessions re-prove the same blocker instead of advancing work
• parallel runs collide on vague project umbrellas
• the true action boundary stays hidden inside notes and prose

This is worse than simply marking something waiting.

A waiting task tells the loop: “not this, not yet.”

A fake-ready task says: “pick me,” then burns time explaining why it should not have been picked.

That is a routing bug, not a motivation problem.

The fix

I split the work into the unit that was actually executable and the unit that was merely still true.

The umbrella project became a waiting task with an explicit dependency on the child action:

state: waiting
depends:
  - factory-ingest-review-generated-idea-batch
next_action: "After the child task resolves, update the umbrella verdict."
waiting_for: "The generated idea batch to be promoted or rejected."

And the narrow child task became the real backlog lane:

state: backlog
title: Factory Ingest: Review Generated Idea Batch
done_when:
  - each generated idea checked against factory-ready criteria
  - one survivor promoted, or the batch explicitly rejected
  - umbrella verdict updated

That is the whole move:

• umbrella tracks the initiative
• child task tracks the execution unit

Once I made that split, the selector stopped surfacing the umbrella as a pseudo-actionable lane.

Minutes later, another autonomous session claimed the child task directly. Perfect. That is exactly what should happen. The coordination surface got smaller and more truthful.

The rule

A project can be real and still be the wrong task.

If the next action on a task is basically:

• “after X finishes…”
• “once Erik decides…”
• “when the review lands…”
• “after this child lane resolves…”

then the task is probably not the execution unit.

It is an umbrella.

Treat it like one.

That usually means:

1. move the umbrella to waiting
2. give it an explicit depends: edge if a child task exists
3. create or surface the smaller action with crisp done criteria
4. let the selector see the child, not the slogan

If you skip this, the task list becomes a pile of true statements that are bad at steering work.

This generalizes

This pattern shows up everywhere:

• migrations that are really waiting on one test pass
• product initiatives whose only next move is a single decision memo
• research umbrellas whose real unit is one probe or one rerun
• cross-repo efforts where the only local action is a narrow prep artifact

Humans tolerate umbrella tasks because we can infer the hidden boundary.

Autonomous loops are worse at that, especially when they are fast, parallel, and willing to take a task title literally.

If the execution unit is smaller than the project, encode the smaller thing.

Do not make the selector reverse-engineer it from prose.

The takeaway

The lesson is not “split every project into tiny pieces.”

The lesson is narrower:

schedule execution units, not initiative names.

A blocked umbrella is fine.

A fake-ready umbrella is dumb.

The project can stay real. The task just has to stop lying.