# AceLM Plan Execution and Verification Items

## Required Minimum Contract

Every AceLM plan requires at least one execution item (`E-*`) and at least one verification item (`V-*`). This rule applies to all plans, including orchestration plans and plans whose primary deliverable is documentation, analysis, or coordination. An orchestration plan is not exempt merely because its child plans executed.

- **`E-*` (Execution Items)**: Define the concrete work, code changes, or decisions that the Execution Agent (EA) must perform.
- **`V-*` (Verification Items)**: Define the empirical validation and verification obligations that the Verification Agent (VA) must independently confirm.

**Critical Invariant:** Execution completion (`E-*`) never implies Verification success (`V-*`). Verification obligations cannot be fulfilled from memory or inferred from an execution checkbox.

## E-* Execution Items

**Proposed IDs:** Artifact-local `E-01`, `E-02`, etc., with at least two digits. A fully qualified reference across artifacts is `<plan-id6>:E-01`.

Each execution item specifies:
- The concrete work or decision EA must perform.
- Permitted file and resource scope (including additions, modifications, deletions, and renames).
- Observable expected outcomes and relevant acceptance criteria.
- Local item-level dependencies on earlier E-items within the plan.
- Execution evidence: recorded actions, result revision/commit hash, command outputs, and deviations.
- Execution state, actor/session ID, and relevant timestamps.

**Item States:** `pending`, `running`, `performed`, and `failed`.
- `performed` indicates that the work was executed and recorded; it does not indicate that independent verification passed.
- Removing required scope requires an approved plan revision and re-acceptance rather than a silent waiver.

## V-* Verification Items

**Proposed IDs:** Artifact-local `V-01`, `V-02`, etc., with fully qualified references `<plan-id6>:V-01`.

Each verification item specifies:
- Which `E-*` items and specification acceptance criteria it validates.
- Verification methodology: automated test suites, static analysis, linting, manual inspection, or adversarial analysis.
- Required evidence artifacts and objective pass/fail criteria.
- Observed empirical evidence: executed commands, exit codes, test logs, diff inspection, and evaluated revision hashes.
- Verification verdict, verifier identity/session, and timestamps.

**Item Results:** `pending`, `running`, `pass`, and `fail`.
- Missing evidence is treated as an unmet obligation, not a pass.
- Verification combines deterministic programmatic checks with independent adversarial evaluation.
- The Verification Agent (VA) operates in an isolated context window separate from the Execution Agent (EA) to prevent author confirmation bias.

## Adversarial Agent Independence

AceLM enforces strict context and session boundaries between operational roles:
- **Authoring Agent (AA)** writes or revises the plan and its `E-*`/`V-*` declarations.
- **Reviewing Agent (RA)** independently assesses the plan in a distinct session and context before acceptance.
- **Execution Agent (EA)** carries out authorized work within allocated isolated worktrees.
- **Verification Agent (VA)** independently evaluates evidence and conducts empirical validation in a separate session/context from EA.

## Coverage, Final-Snapshot Evidence, and Completion Gates

1. **Full Coverage**: Every required `E-*` item must be mapped to at least one `V-*` item.
2. **Explicit Mapping**: Each `V-*` item references concrete `E-*` items or plan-wide integration criteria.
3. **Namespace Integrity**: IDs are unique within their E/V namespace, and item dependency graphs must be acyclic.
4. **Final-Snapshot Evidence**: V-items evaluate the final result commit snapshot. Any subsequent code change immediately invalidates affected verification results, requiring re-verification against the new commit.
5. **Plan Execution Gate**: A plan transitions to `executed` (`complete` only after explicit adoption under [the migration contract](acelm-status-migration.md)) only when every required E-item is `performed` and every required V-item is `pass` for the final repository commit.
6. **Orchestration Verification**: An orchestrating plan must validate its own V-items, including integration and interface coherence between child plans.

## Retry Accounting and Verification Waits

- **Single-Round Accounting:** When a verification check discovers an in-scope implementation defect, the corrective cycle (EA bounded repair + VA independent recheck) counts as **one retry unit** against the artifact's `VERIFY` retry budget and cumulative ceiling. Constituent steps within that round are not charged multiple times.
- **No Per-Item Resets:** Individual V-items do not receive fresh full budgets; the retry limit applies to the plan verification action as a whole.
- **Verification Wait Semantics:** If verification is suspended while waiting for dependency artifacts or human input, the plan **retains its `verifying` phase**; activity is recorded as `waiting` or `paused`, and Run shows `issue` if human action is needed.
- **In-Scope Repair vs. Scope Change:** Bounded in-scope repairs remain within the EA/VA verification retry loop. Any change to requirements, acceptance criteria, or approved file scope requires returning through AA revision, independent RA review, and human/delegated re-acceptance.

## Illustrative Plan Schema

```markdown
## Execution items

- [ ] E-01 Rename internal session validation helper to conform to new standard.
  - Allowed files: src/auth/session.ts, tests/auth/session.test.ts
  - Expected outcome: internal callers use updated helper; public API exported types remain identical.
  - Depends on: none.
  - Execution state: pending.
  - Observed execution evidence: none yet.

## Verification items

- [ ] V-01 validates E-01.
  - Required evidence: scoped git diff; symbol search across codebase;
    execution of tests/auth/session.test.ts (all tests pass);
    independent verification that public API surface is unchanged.
  - Pass criteria: helper renamed cleanly; zero edits outside allowed files;
    test suite passes with 100% success; zero compiler/linter warnings.
  - Observed evidence: none yet.
  - Result: pending.
```