Testing And Triage

The testing workflow is split into deterministic execution and agentic triage.

Deterministic Testing

The testing service runs shell commands inside a repo or implementation worktree. It records:

• command name;
• command string;
• tier;
• exit code;
• duration;
• stdout;
• stderr;
• summary;
• failures.

Supported tiers:

• basic
• unit
• integration
• regression
• happy-path
• evidence
• custom

Agentic Triage

The triage service starts a short read-only Codex session rooted in the worktree. It is allowed to inspect files with commands such as:

• rg
• git diff
• git status
• sed
• focused file reads

It is not allowed to edit files, commit, run broad new suites, or change repo state.

Structured Triage Output

The triage schema returns:

Field	Meaning
classification	implementation_regression, baseline_failure, test_command_issue, environment_issue, flaky, no_issue, or unknown.
confidence	low, medium, or high.
actionable	Whether automation can act on it.
needs_implementation_pass	Whether a repair pass should run.
needs_human_review	Whether automation should stop.
suspected_files	Repo-relative files likely involved.
proposed_changes	Concrete repair suggestions.
rerun_commands	Smallest useful commands to rerun.
blocking_reason	Human-readable blocker when automation should stop.

Repair Loop

The issue implementation workflow uses a bounded loop:

1. run deterministic tests;
2. if failed, run read-only triage;
3. if triage is actionable, run a focused Codex repair pass;
4. rerun deterministic tests;
5. stop after success or the configured max rounds.

Default max repair rounds:

CODE_ASSIST_IMPLEMENTATION_TEST_REPAIR_MAX_ROUNDS=2

Why Codex Is Not The Test Runner

Mastra runs tests directly because test execution must be deterministic, repeatable, cheap to audit, and easy to summarize. Codex is used where agentic reasoning adds value: reading the diff, interpreting failures, proposing fixes, and making focused repairs.