Skip to content

Status Tracking

Every node in your model can have a status that tracks where it is in the implementation lifecycle.

Proposed Implemented Verified Vagrant

Proposed — this node is planned but doesn’t exist in code yet. It’s a design decision waiting to be built.

Implemented — code exists for this node, but it might be incomplete. Stubs, partial implementations, scaffolding — anything that’s started but not finished.

When an AI agent implements a node, it marks it as Implemented with a reason explaining what was built: “Basic CRUD endpoints, needs auth middleware and rate limiting.”

Verified — this node is production-ready. The implementation is complete, tests pass, and all contract items are satisfied.

Verified is gated. A node can only be marked verified when every inherited expect contract item has passed: true. If even one expect item is unchecked or failed, the verified status is blocked.

Vagrant — this node was discovered during a codebase sync but wasn’t part of the architecture plan. It exists in code but has no home in the model yet.

Vagrant nodes need a decision: incorporate them into the architecture or remove them from the codebase.

  • Systems, containers, components, operations, processes, models
  • Persons and external systems don’t get status (they’re outside your control)

Marking a system or container as external automatically clears its status.

New nodes default to no status. Nodes without any status appear gray and unactionable. Use “no status” for framework defaults or infrastructure that doesn’t need implementation effort — things that are just there.

Auth API
Express
User Service
Express
Database
PostgreSQL

Nodes show a colored status dot and border:

  • Blue border and dot for proposed
  • Amber for implemented
  • Green for verified
  • Violet for vagrant

In the sidebar tree, the same colored dots appear next to node names for a quick overview of project progress.

During the implementation workflow:

  1. The agent sets nodes as proposed when planning
  2. The agent builds each piece and marks it implemented with a reason
  3. When you’re satisfied, ask the agent to verify — it checks for stubs, runs tests, and confirms contract items
  4. If everything checks out, the node moves to verified

Status propagates upward: when all components in a container are implemented or verified, the task system prompts the agent to mark the container as implemented too.