How MARS decides what to do next.

Delivery Flow

The core order is strict: active goal, active plan, feature contract, ticket, delivery evidence. If a repo has tickets or code work without that chain, repair the planning state before calling the work complete.

Goals

Goals are outcome decisions, not tickets. They carry priority, confidence, source, hypothesis, competing goals, support links, review triggers, and success or falsification evidence.

docs/goals/active.md
docs/goals/observations.md
docs/goals/superseded.md

Active Plan

There must be exactly one active execution plan. It decides which scenario is next and why that scenario advances the active goal. Backlog plans wait their turn; superseded plans are history.

mars doctor --repo /path/to/repo
go test ./internal/docsconsistency/...

Plan hygiene checks catch drift such as multiple active plans, stale status claims, missing feature pointers, or active tickets that no longer match the plan.

BDD Feature Contracts

BDD contracts define feature completeness. They are not optional notes. Business logic belongs here before or alongside implementation.

Contract Status

docs/features/F-001-delivery-operating-model.md
docs/features/README.md

Tickets

Tickets scope one bounded slice of work. Feature tickets implement the current failing BDD scenario or scenario group. Enabler, research, docs, and intervention-debt tickets must not claim shipped feature behavior unless scenario evidence exists.

Feature Evidence Gate

Before a feature ticket moves to done/, it needs non-empty bdd_scenarios, end_to_end_evidence: required, non-empty evidence_links, and a real verified_by value.

---
work_type: feature
bdd_scenarios: ["F-001-S002"]
end_to_end_evidence: required
evidence_links:
  - go test ./internal/serve -run TestValidateEngineerTicketGate
verified_by: command
blocker: none
next_action: none
---

Role Handoffs

The delivery model depends on role boundaries. Dispatch mode keeps those boundaries explicit through dispositions rather than prose.

Disposition Statuses

Evidence Gates

Evidence should be executable or durable. A chat summary is not a substitute for repo-owned proof.

Unit tests can support deterministic helpers, but user-visible features need scenario-level evidence: integration, E2E, dogfood, command, or docs-consistency proof mapped to the BDD scenario ID.

Review And Release

Review checks the delivered slice against the ticket and BDD contract. Release notes then classify what shipped. Enabler work can be valuable, but it must not be described as a shipped feature scenario unless the BDD evidence exists.

mars run qa --repo /path/to/repo --dry-run
mars docsync audit --repo /path/to/repo
mars scores export --repo /path/to/repo --window-days 30

mars release notes --repo /path/to/repo --bump auto --dry-run
mars release notes --repo /path/to/repo --bump auto
mars release backfill-notes --repo /path/to/repo --check

Recipes

read docs/goals/active.md
edit docs/exec-plans/active/current-operating-plan.md
edit docs/features/F-NNN-feature-name.md
mars run cto-weekly --repo /path/to/repo --dry-run

git mv docs/tickets/backlog/T-001-example.md docs/tickets/in-progress/
run the implementation and scenario evidence
edit the ticket evidence fields
git mv docs/tickets/in-progress/T-001-example.md docs/tickets/done/
git commit -m "feat(scope): implement scenario T-001"

blocker: "Cloud model endpoint returned 401 with configured api_key_env"
blocked_by: ["T-014"]
trace_id: tr-...
next_action: "Repair model credential env and rerun engineer on T-001"

mars doctor --repo /path/to/repo --json
mars docsync audit --repo /path/to/repo
git status --short --branch

Troubleshooting