Task Results & Acceptance

In Heicode, completed can only indicate that the execution flow has ended. On its own it cannot prove that the code is correct, that tests passed, or that the original problem was solved.

Four Different Kinds of Success

These four states cannot substitute for one another. An Agent can finish executing without changing any files, can change code but have tests fail, or can have tests pass without covering the real problem.

Minimum Acceptance Evidence

Every development task should provide at least the following evidence:

• The list of changed files;
• A summary of the key diff;
• The verification commands actually run;
• The command exit codes;
• The number of tests passed, failed, and skipped;
• Any platforms or scenarios not verified;
• A record of manual intervention;
• Known risks and the rollback method.

Recommended Result Card

Task status: Completed
Code changes: 7 files
Tests run: 42
Tests passed: 40
Tests failed: 2
Not verified: Windows build
Manual intervention: 1
Conclusion: Needs review, should not be released directly

Acceptance Order

1. Check Whether Code Was Actually Changed

Confirm that a diff exists in the workspace, and rule out cases that only generate a report, only modify comments, only update the lock file, or only output suggestions without a real implementation.

2. Check the Change Scope

Compare the changed files against the task scope one by one. If a task only asked to fix one endpoint but a large number of unrelated modules were modified, treat it as a high-risk result.

3. Check Whether Tests Actually Ran

Don't just accept a natural-language summary. Look at:

• The full command;
• The working directory;
• The start and end times;
• The exit code;
• A summary of stdout and stderr.

If the test command was not found, timed out, was skipped, or was interrupted by an environment error, it cannot be recorded as passing.

4. Check Whether Tests Cover the Original Problem

New tests should fail before the fix and pass after it. Tests that only verify internal implementation details, fixed return values, or that mock out all dependencies may not prove the real problem is solved.

5. Check Regression Risk

Beyond the target tests, also run tests, builds, type checks, static analysis, or manual scenario verification for affected modules.

Handling Repositories With No Tests

When there's no automated testing, record at least:

• Which manual verification steps were used;
• Which inputs and outputs were verified;
• Which scenarios cannot be covered;
• Why the risk is considered acceptable.

Results for such tasks should be marked "manually verified" or "needs review" — they should not be disguised as automated test passes.

Extra Acceptance for Agent Swarm

In multi-Agent scenarios, also check:

• Whether the Agents repeatedly modified the same file;
• Whether the aggregated result dropped a valid change from some Agent;
• Whether conflicts were handled correctly;
• Whether the Team Lead's summary is consistent with the final workspace;
• Whether a failed Agent's partial results were mistaken for success.

Pre-Release Requirements

Before a production release, code review, testing, and release approval should be completed by people or processes independent of the executing Agent. Heicode's task status cannot replace your team's existing CI, review, and release gates.