Task lifecycle

A demonstrative endpoint task in MDAAI 2.0. These records are examples of the source schema, not claims that an endpoint or its tests were executed.

By Eris Margeta Kurdali · Repository

1. Establish the task and its scope

The operator authorizes a read-only status endpoint. The executor reads AGENTS.md, the assigned APP-001 row, its scopeRef and applicable rule documents. Confirm that the endpoint is within project scope and that no external effect is being smuggled into the task. Read current working files before editing; preserve unrelated changes.

2. Keep one active task record

This complete minimal registry uses fields checked by the source scripts/validate.py. APP is an illustrative project prefix. The scope file must actually exist. The ISO date and single active history entry satisfy that source validator; the task is not complete, has no invented evidence and names a useful next action.

Illustrative TASKS.json

{
  "schemaVersion": 1,
  "taskPrefix": "APP",
  "tasks": [
    {
      "id": "APP-001",
      "title": "Add a read-only status endpoint",
      "owner": "project executor",
      "state": "active",
      "disposition": "current",
      "scopeRef": "PROJECT-INTERNAL/MANAGEMENT/PROJECT-ELABORATION.md",
      "acceptance": [
        "Endpoint returns the documented response and rejects unsupported methods."
      ],
      "dependencies": [],
      "evidence": [],
      "blocker": null,
      "next": "Add boundary tests for response shape and unsupported methods.",
      "history": [
        {
          "at": "2026-10-04",
          "state": "active",
          "disposition": "current",
          "reason": "Operator authorized this bounded endpoint change."
        }
      ]
    }
  ]
}

3. Implement and collect evidence

Write endpoint code and relevant tests/docs in the existing project layout. Check response shape and unsupported methods, then affected integration/runtime paths appropriate to the application. Save actual results at project-selected paths and update evidence/next in the active row. No routine Work Order or checkpoint is added. If this were a bug fix, capture a faithful pre-fix regression where safely possible before the root fix.

4. Add context only when necessary

If the endpoint forces an architecture choice—such as a new service boundary—record alternatives, decision, migration/rollback and limits in the project’s compact ADR and link it. Otherwise no ADR is needed. A deployment or production write would need its applicable authorization and evidence; local implementation success does not authorize it.

5. Record a terminal result, not an invented one

Only after actual evidence supports every acceptance criterion should the owner/coordinator set state to complete, disposition to current, blocker and next to null, attach criterion-indexed evidence, and append the complete transition. The fragment below is structural notation, not a completed sample: substitute a real local reference and observed result. Do not record success merely because the JSON validates.

Field guide — not JSON

evidence entry: {criterion: 1, result: observed behavior + evidence level + limits,
                 reference: existing project-local evidence path}
history entry:  {at: ISO date, state: complete, disposition: current,
                 reason: actual supported acceptance result}
terminal fields: state = complete; disposition = current;
                 blocker = null; next = null

Blocked and deferred are different

If APP-001 cannot proceed, blocked requires a concrete blocker and useful next action; resume blocked → active before completing. A separate unrelated defect may be recorded as active or proposed with deferred disposition, impact and next action, but it is not automatically authorized. A relevant defect still blocks the acceptance it invalidates.

Field	Allowed values / role
state	proposed · active · blocked · complete · void
disposition	current · deferred (independent of lifecycle)
complete	Evidence covers every criterion; next and blocker null; terminal disposition current.
void	Reason required; preserve terminal record.
history	Concise state/disposition transitions; preserve coherent terminal history.

6. Resume or correct later

A new session reads APP-001 and its evidence, checks live state and continues only authorized nonterminal work. If the completed endpoint later proves defective, create a new task linked to APP-001 and retain the earlier evidence. Do not silently rewrite the old completed result into a different history.

Source references

Based on original contracts and templates. These are source locations, not installed-file claims. No private source archives are served.

MDAAI 2.0: AGENTS.md
MDAAI 2.0: CLAUDE.md
MDAAI 2.0: docs/ADOPTION.md
MDAAI 2.0: scripts/validate.py
MDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/AUTHORITY.md
MDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/ENGINEERING.md
MDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/EVIDENCE.md
MDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/REASONING.md
MDAAI 2.0: PROJECT-INTERNAL/GOVERNANCE/RECORDS.md
MDAAI 2.0: PROJECT-INTERNAL/MANAGEMENT/PROJECT-ELABORATION.md
MDAAI 2.0: PROJECT-INTERNAL/MANAGEMENT/TASKS.json