Objective

Complete every item on the done-means list to verified completion. Not "attempt each item once" — complete the outcome, resolve blockers where resolvable, and stop only at a boundary that is actually real.

Step 1 — Locate the list

Before building anything, confirm you have the actual done-means output, not a memory of it:

Check this conversation for the done-means result.
Check the project's configured tracking backend (Airtable, GitHub Issues, or whatever /done-means wrote to) for the current state of each item.
Check for a written roadmap file in the project if one exists.

If none of these produce the list, that is a real blocker. State it and ask where the list lives. Do not reconstruct it from guesswork or from a stale summary in this chat.

Step 2 — Build the execution plan

For the full list:

Preserve the sequencing and dependencies done-means already identified. Do not re-derive them from scratch.
Separate items into safe-and-reversible (proceed without asking) and anything that touches a real permission boundary (external sends, deploys, deletions, credential changes) — flag those up front as a group, with one recommended path each, rather than one at a time as you reach them.
Note which items are BROKEN (something exists but is wrong), MISSING (something doesn't exist yet), or REQUIRED (a dependency for another item) — the fix pattern differs for each.
Step 3 — Execute, persisting until a real boundary

Work the plan in sequence. For each item:

State the exact attempt and what you're checking to confirm it worked.
If it fails, diagnose why before retrying. Do not repeat an identical action hoping for a different result.
Before concluding a tool, connector, or access path is unavailable, check the alternatives actually present in this session — other MCP connectors, filesystem access, a different skill, a manual construction of the same output.
Try a genuinely different approach before calling something blocked: different tool, different method, different order, different framing of the same objective.
If the literal item as written would produce the wrong outcome given what you now know, say so and correct course rather than completing it literally.

Keep going across the whole list until every item is verified complete, or you hit one of these:

Permission boundary — required access, credentials, or authorization aren't available and can't be obtained in this session.
Capability boundary — the available tools or platform genuinely can't do it, backed by a specific error, a documented limit, or a failed verification attempt.
Wrong objective — completing the item as stated would produce an outcome the project doesn't actually need.

A single error or refusal is evidence about the approach you just tried, not proof the item is blocked. Do not fabricate success and do not route around a genuine boundary to make an item look done.

Step 4 — File safety while executing

Any item that involves writing or modifying a file:

Check for an existing file of the same name or purpose before writing. Finding one is information, not a reason to stop — read it and say whether your output supersedes, extends, or conflicts with it.
Never overwrite or destructively edit a file another agent or Paul created. Write a new dated file instead, named per ClearPath: name-CODE_MMDDYY.ext, your agent code as the last hyphenated segment before the date.
In-place editing is only fair game on a file you created earlier in this same session, or when the done-means item itself explicitly names a file and says edit in place.
Deleting, truncating, or moving another agent's file needs explicit permission in the moment — that's a permission boundary, not a judgment call.
Step 5 — Verify before marking complete

For each item, verify against the specific condition done-means stated for it, not a general sense that it's fine now. An attempted fix or a file that now exists is not proof the underlying condition is met — check the actual thing done-means was testing for.

Step 6 — Update the tracking backend

As items complete, update their status in the same backend done-means wrote to, so the list reflects reality without a separate manual pass. If the backend doesn't support a status write from this session, say so and report the completions in your final summary instead.

Step 7 — Report

At the end of the run, or when you hit a boundary that stops further progress, report:

Every item attempted, in order.
The specific result or failure for each — not "handled," the actual evidence.
Which items remain, and for each, the boundary reached.
For every remaining item: who owns unblocking it and the exact action that would do it.

Do not summarize a partial run as complete. If six of nine items are done and three are genuinely blocked, say six of nine, name the three, and stop there.

What wrong looks like
Producing a plan for how you'd execute the list instead of executing it.
Marking an item complete because the action was attempted, not because the stated condition was verified.
Retrying the same failed action a second time without a changed hypothesis.
Silently skipping an item that looked hard.
Overwriting a file that already existed instead of writing a new dated one.
Reporting "all done" when some items are actually blocked, or burying the blocked ones in a wall of text instead of naming them explicitly.