# AceLM sequential release assessment cycle

This document replaces the earlier implication that automated release review first runs all lenses and then performs one consolidated remediation phase. The user's automated release design is **assess one lens, complete its remediation lifecycle, then assess the next lens**, repeated across a deep pass and at least one lighter pass.

Standalone `assess-all` may still produce a consolidated proposal when explicitly requested. It is not the automated release execution algorithm.

## 1. Required pass structure

Let N be the number of lenses in the configured, ordered release profile. The full current catalog has N = 31.

| Pass | Purpose | Required behavior |
| --- | --- | --- |
| 1: deep | Discover all issues within each lens's scope as comprehensively as the evidence permits. | Apply the full rubric; record findings without quotas; produce warranted plans/plan sets and complete their review, acceptance, execution, and verification before advancing. |
| 2: light | Confirm significant omissions and issues introduced by subsequent lens changes. | Reuse prior reports as evidence, inspect intervening changes and affected interactions, and check that the previous lens work remains valid. Do not restart an unrestricted issue hunt. |
| 3: convergence, when needed | Confirm remaining significant issues and the effects of pass-2 remediation. | Narrow the focus further to unresolved significant findings, newly affected surfaces, and concrete invalidated evidence. No novelty or finding-count target. |

**Required:** pass 2 covers the entire configured lens sequence, even if pass 1 appeared clean. A completed two-pass full-catalog cycle schedules 62 lens evaluations. If a third full pass is necessary, the count is 93. For N lenses, the corresponding counts are 2N and 3N.

An early failure may stop a cycle before the scheduled evaluations complete. Report it as incomplete, not as a completed 62-evaluation release review. A correctly justified not-applicable disposition counts as a recorded lens evaluation, not as a substantive audit of a nonexistent surface; distinguish these in coverage reporting.

These counts are lens evaluations, not necessarily distinct model sessions, plan-review attempts, E-item executions, or verification retries. A lens's remediation may need multiple bounded review/verification attempts; those costs and attempts are reported separately. Deterministic test reruns are not extra lens passes.

## 2. Inner loop: finish one lens before the next

For each lens, against the current integrated candidate:

1. **Assess:** pin the incoming candidate commit, lens version, scope, pass mode, and applicable evidence. The assessor produces findings and, where warranted, a plan or plan set.
2. **Review:** RA independently reviews each required plan, including the orchestrator and child-plan consistency when there is a set, in a separate context from AA.
3. **Accept:** a human accepts the plans or an agent acts under explicit human-granted autonomous plan-acceptance authority. A plan set is approved through its required member/orchestration gates until a separate set lifecycle is defined; do not invent an undocumented set `accepted` state.
4. **Execute:** EA performs accepted E-* work in isolated worktrees/branches, respecting dependencies and approved scope.
5. **Verify:** independent VA and programmatic checks satisfy the V-* items, regression requirements, completion evidence, and applicable plan-set child/orchestrator gates.
6. **Integrate:** publish the verified changes through controlled integration. Recheck affected evidence on the integrated result; a successful private branch alone is insufficient to advance the release sequence.
7. **Record and advance:** persist findings/dispositions, accepted artifacts, executed/completed successors, before/after commits, evidence, remaining blockers, and the checkpoint. Only then start the next lens.

**No changes needed:** a lens may legitimately produce no plan. Record its assessed scope, evidence, and no-significant-findings/no-change verdict, then advance. Do not manufacture a no-op plan or a finding to satisfy the scheduler.

**Unresolved or failed remediation:** pause or fail at this lens. Do not continue to another lens while its required review, acceptance, execution, verification, or integration remains incomplete. A warranted explicit deferral/risk disposition is recorded under release policy; it is not silently treated as a completed fix. Expected human approval waits use stable status plus waiting activity.

Once assessment has begun, the release retains `reviewing` while a lens's remediation plans execute or await authorization. Record `activity: waiting`, the remediation IDs, selected assignment, lens/pass checkpoint, and readiness for the named next action. Run shows `wait` or `issue` as appropriate, rather than implying the assessor is actively working. A genuinely invalidated review snapshot or materially changed candidate requires a new review request and refreshed evidence; ordinary remediation waiting alone does not move the release to `to-review`. The orchestration run and checkpoint remain durable.

Lenses do not run concurrently in this automated cycle. A plan set may use safely isolated child concurrency where dependency policy permits, but the next lens waits until the whole required set and integration gate finish. As an implementation simplification, serial child execution is also valid.

## 3. Light-pass instructions

Pass 2 should receive an explicit instruction such as:

> This lens has already been assessed and its accepted remediation executed. Inspect the prior findings, dispositions, evidence, current result, and changes made by later lenses. Determine whether anything significant was missed or whether subsequent changes introduced a defect or invalidated the earlier conclusions. A clean result is a successful outcome. Do not search for novelty, cosmetic refinements, or additional findings merely to demonstrate activity. Report concrete evidence for each new significant issue, or state that no significant issue was found within the assessed scope.

Pass 3 should be narrower:

> This is the final configured convergence pass. Verify the remaining significant findings and the effects of intervening fixes. Revisit unaffected conclusions only when concrete evidence calls them into question. Do not reopen accepted nonblocking dispositions or propose speculative improvement. Record new blockers if actually supported; otherwise confirm the applicable earlier evidence and a clean result. If the candidate still does not converge, report that outcome rather than extending the cycle.

These are proposed prompt texts implementing the user's intent. They do not weaken security, accessibility, regression, or correctness requirements. “Light” limits exploratory search and discretionary improvements, not the obligation to recognize a real blocker.

## 4. Significance and anti-churn rules

**Proposed significance policy:** treat an issue as significant if evidence shows that it violates a required acceptance criterion, release gate, security/privacy constraint, accessibility requirement, public contract, data-integrity invariant, or configured reliability/performance threshold; or introduces a consequential regression. A small code change can be significant. A style preference without a requirement or concrete user harm usually is not.

- No minimum findings count, discovery score, or reward for new plans.
- Require location, reproducible/inspectable evidence, impact, and the requirement or behavior violated.
- Check previous findings before opening a new one; distinguish new, reopened, duplicate, already fixed, and accepted disposition.
- Separate evidence-backed defects from speculative improvements. Optional improvements can be recorded for later work without blocking release or triggering light-pass remediation.
- Do not reopen an explicitly accepted nonblocking disposition without new evidence or changed assumptions.
- Keep unresolved significant findings visible. They are not hidden to hit a pass cap.
- RA rejects proposed remediation that has no justified issue or expands beyond the relevant scope.
- Preserve the full rubric and previous reports as references; pass 2/3 are differential reviews, not amnesia-driven repeated first passes.

A clean report must identify what was checked and why earlier evidence is still valid. “Nothing found” without examination is not sufficient.

## 5. Ordering and candidate evolution

Freeze a deterministic ordered lens list when the release cycle starts. Use the configured order; do not silently choose alphabetical order because it happens to be the filename order. The initial default ordering remains a design decision: security, architecture, correctness, UX, and performance can affect one another, so no ordering eliminates the need for subsequent passes.

Each evaluation sees the latest integrated result of all preceding completed remediation. Record the delta since the same lens's previous evaluation, including changes by later lenses in the prior pass and earlier lenses in the current pass. Prior reports, accepted decisions, tests, changed paths, and dependency relationships guide impact analysis. Cross-cutting changes require broader affected-surface inspection even in light mode.

If configuration changes require adding/removing/reordering lenses mid-cycle, pause and create an explicit profile revision or new authorized cycle; do not mutate already-recorded coverage silently.

## 6. Convergence and stopping

After the mandatory second pass, proceed toward final ship review only when:

1. Every configured lens has a completed, applicable evaluation or justified not-applicable record for both passes.
2. All required remediation has been reviewed, accepted, executed, independently verified, and integrated.
3. No unresolved significant blocker remains.
4. Evidence required for the final candidate is current, and later lens changes have not left an earlier significant conclusion unvalidated.
5. The final candidate satisfies the project's full required regression, build, security, accessibility, and other release checks.

**Proposed third-pass trigger:** pass 2 discovers significant new/reopened findings, performs changes that need cross-lens confirmation, or leaves relevant conclusions/evidence stale. Run pass 3 over the entire configured set. A no-change clean pass 2 with current evidence can stop at two passes.

A late-pass edit does not automatically invalidate every earlier lens; impact analysis records which conclusions are affected and why. However, if a pass-3 remediation materially affects an already-completed lens and its significant conclusion cannot be validated with current evidence within the configured cycle, the cycle has not converged. Targeted deterministic checks or the remediation plan's V items can refresh evidence where sufficient; they are not a license to claim an additional unperformed lens evaluation.

**Proposed maximum:** three full lens passes by default; no automatic fourth sweep. If required convergence is still absent, final readiness is `no-go` and record `fail-gate` with reason `release-lens-nonconvergence`. Exhausted review/verification attempts retain `fail-review`/`fail-verify` instead of being mislabeled. An authorized human may change scope or initiate an explicitly recorded follow-up cycle, preserving the prior history and total cost; it must not masquerade as the same successful capped cycle.

Release acceptance, publication/deployment, and post-release verification remain separate steps after this cycle. Completing 62 or 93 evaluations is not itself permission to ship.

## 7. Proposed configuration and counters

```yaml
release_review:
  lens_profile: enterprise-full
  lens_order: explicit-versioned-profile-order
  minimum_passes: 2
  maximum_passes: 3
  pass_modes: [deep, light, convergence]
  significance_policy: project-release-gates
  stop_on_unresolved_required_remediation: true
```

The above is an illustrative AceLM configuration schema. Validate a minimum of 2 passes, a maximum of 2 or 3 under the standard profile, and maximum >= minimum. An alternate policy requires explicit authorization and honest reporting of its different budget.

**Passes vs. Retries:** The pass budget (62 evaluations over 2 passes, up to 93 over 3 passes) is distinct from retry budgets. Planned lens evaluations are scheduled workflow steps, not retries. Only corrective repair rounds (AA revision + RA recheck, EA repair + VA recheck) consume the respective artifact's retry budgets (`REVIEW`, `VERIFY`, `FAIL`, `GATE`), all subject to the artifact cumulative ceiling `MAX_CUMULATIVE_RETRIES` (default: 20 x resolved `MAX_RETRY`). A new lens or pass does not erase an exhausted artifact retry budget.

## 8. Durable execution record and crash recovery

Record cycle/profile IDs, catalog/lens versions, fixed order, pass number/mode, lens index, incoming/outgoing commits, relevant deltas, prior finding references, significant findings/dispositions, produced artifact IDs, plan acceptance authority, E/V evidence, integration outcome, counters, cost, and next resume step.

**Crash and Unexpected Termination Recovery:**
- An interrupted worker or crashed runner (`died`) does not restart pass 1 or discard completed work.
- Startup and periodic reconciliation confirm worker termination, fence stale mutation authority, and preserve checkpoints, worktrees, commits, and uncommitted progress.
- Recovery inspects actual repository state and resumes the exact unfinished lens, plan, or verification checkpoint.
- Normal terminal disconnection leaves the supervisor process running undisturbed.

## 9. Remaining decisions

- Define the initial full-profile lens order and any reduced profiles.
- Define project-specific significance thresholds and evidence requirements.
- Decide which independent findings warrant separate plans versus a plan set within one lens.
- Specify impact-analysis rules for evidence invalidation and sufficient deterministic refresh.
- Define follow-up-cycle authorization when convergence is not reached within the configured cap.

## 10. Mermaid diagrams

### Sequential Release Passes

```mermaid
flowchart TB
    START["Freeze ordered lens profile: N lenses"] --> P1["Pass 1: deep; seek all evidenced issues"]
    P1 --> LOOP["Sequential lens loop: assess → review/accept plans → execute → verify → integrate"]
    LOOP --> END{"Entire configured pass complete?"}
    END -->|"no"| LOOP
    END -->|"yes"| SECOND{"Mandatory pass 2 already completed?"}
    SECOND -->|"no"| P2["Pass 2: light; significant omissions and cross-lens regressions"]
    P2 --> LOOP
    SECOND -->|"yes"| CONV{"No significant blockers and final-candidate evidence current?"}
    CONV -->|"yes"| SHIP["Final ship review + separate release authority"]
    CONV -->|"no"| BUDGET{"Third full pass available?"}
    BUDGET -->|"yes"| P3["Pass 3: narrower convergence; no novelty hunting"]
    P3 --> LOOP
    BUDGET -->|"no"| FAIL["NO-GO: fail-gate, release-lens-nonconvergence"]
    COUNT["31 lenses: 62 scheduled evaluations over 2 passes; 93 over 3. Retry attempts counted separately."]
    SHIP ~~~ COUNT
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    classDef fail fill:#fff2ee,stroke:#a35743,color:#572d23;
    class SHIP good;
    class FAIL fail;
```

### Release Assessment Gates

```mermaid
flowchart TB
    START["Current integrated candidate + next configured lens + pass mode"] --> A["Assess lens: deep / light / convergence instructions"]
    A --> ISSUE{"Warranted remediation?"}
    ISSUE -->|"no"| CLEAN["Evidence-backed clean or justified not-applicable result"]
    ISSUE -->|"yes"| PLAN["Produce plan or plan set with E-* and V-* items"]
    PLAN --> R["Independent RA review"]
    R --> ACCEPT["Human or scoped delegated plan acceptance"]
    ACCEPT --> EA["EA executes approved work in isolated worktrees"]
    EA --> V["Independent VA + programmatic verification"]
    V --> INTEG["Integrate verified changes; recheck affected evidence"]
    INTEG --> G{"All required remediation and gates complete?"}
    G -->|"no"| STOP["Pause / bounded remediation or failure; do not advance lens"]
    G -->|"yes"| RECORD["Record lens result, commits, dispositions, evidence, checkpoint"]
    CLEAN --> RECORD
    RECORD --> NEXT["Only now advance to next lens"]
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    class NEXT good;
```