Mistflowdocs
Work in an AI editor

Feature manifest

How Mistflow tracks acceptance criteria from planned to verified, so you can tell what was promised from what was actually delivered.

Every project carries a feature manifest at .mistflow/manifest.json. It turns a plan into a set of verifiable promises, and turns "I think it's done" into "here is what is still unverified".

The three states

StateMeaning
plannedThe criterion came out of plan generation. Nothing has been built for it
implementedCode has been written that is believed to satisfy it
verifiedEvidence exists. QA passed against the live app, or a person confirmed it

The gap between implemented and verified is where regressions live. The manifest makes that gap visible instead of leaving it to memory.

Where criteria come from

They are generated as part of the plan, not written by you. For a habit tracker the plan might produce:

{
  "features": [
    {
      "id": "habit-crud",
      "name": "Habit CRUD",
      "criteria": [
        { "id": "hc-1", "text": "A signed-in user can create a habit with name, target days per week, and color." },
        { "id": "hc-2", "text": "Editing an existing habit updates the row without creating a duplicate." },
        { "id": "hc-3", "text": "Deleting a habit removes it from the list view within 1s." }
      ]
    },
    {
      "id": "streaks",
      "name": "Streak Tracking",
      "criteria": [
        { "id": "sk-1", "text": "Marking a habit complete for today increments its streak by 1." },
        { "id": "sk-2", "text": "Missing a day resets the streak to 0 the next time the habit is loaded." }
      ]
    }
  ]
}

Two features, five criteria, all starting at planned.

How state moves

planned to implemented — when a build step that maps to a feature completes, that feature's criteria flip to implemented. The mapping comes from the plan's own step-to-feature links.

implemented to verified — when QA drives the live app through the criteria, each one whose check passes flips to verified. A criterion you have confirmed by hand can be marked verified too.

Reading the manifest

Ask your editor for project state and it returns the manifest alongside the rest of the project context:

What's the state of this project?

Mid-build, that looks something like:

Feature: Habit CRUD (3 criteria)
  [x] hc-1  A signed-in user can create a habit...      verified
  [x] hc-2  Editing an existing habit...                implemented
  [ ] hc-3  Deleting a habit removes it from...         planned

Feature: Streak Tracking (2 criteria)
  [ ] sk-1  Marking a habit complete...                 planned
  [ ] sk-2  Missing a day resets the streak...          planned

Progress: 1 verified, 1 implemented, 3 planned

To see only what is outstanding, ask what is still unverified. That is the "what is left" list: the editor uses it to choose what to work on next, and QA uses it to know what still needs checking.

Why it matters

Without a manifest, "done" means whatever was last said out loud. With one, done means something specific and checkable: the criteria exist, and they are verified.

Pair it with contracts

The manifest keeps features in sync with the plan. Integration contracts keep code in sync with the database schema. Together they close the two most common ways an AI-built app drifts from what was promised.

On this page