sdd-attempt closes a change after task decomposition and blocks apply

[NicolasAgustinIbarra]

Pre-flight Checklist

• I have searched existing issues and this is not a duplicate
• I understand that PRs will be rejected if the linked issue does not have status:approved

📝 Bug Description

An sdd-attempt ledger completed an SDD change after its task-decomposition attempt settled. Acquiring the first planned implementation work unit then returned state: complete, which prevented implementation from starting.

🔄 Steps to Reproduce

1. Acquire an SDD attempt for task decomposition with max-attempts 1.
2. Settle that attempt as passed.
3. Acquire a distinct implementation work unit for the same SDD change.
4. Observe state: complete rather than an acquired attempt.

✅ Expected Behavior

Each approved work unit of an SDD change can acquire its own attempt within its configured budget. Settling task decomposition must not exhaust the implementation lifecycle.

❌ Actual Behavior

The task-decomposition acquisition used max_attempts: 1 and settled successfully. The subsequent status reported complete: true and next_action: complete. Acquiring the next planned implementation work unit returned state: complete.

Gentle AI Version

Gentle AI Version: 2.2.0

Operating System

Linux (Ubuntu/Debian)

AI Agent / Client

OpenCode

📋 Affected Area

CLI (commands, flags)

💡 Logs / Error Output

``text
sdd-attempt status
complete: true
next_action: complete

sdd-attempt acquire <implementation-work-unit>
state: complete

Additional Context

• One bounded task-decomposition attempt passed; the next implementation-work-unit acquisition returned complete.
• No application source code was modified. Planning artifacts were created and consumer state remained preserved.
• The planned next work unit was blocked before implementation could begin.
• Opaque evidence identifiers:
  • Task objective: sha256:3ff85d3677252b6a6adadd7b554a1236dd341d10d32d4cddb6c74658c9ac7cb4
  • Task evidence revision: sha256:e3b1d430c389bcda080db3607535b1196109828fcfa96da96bfe045a3c891254
• Private change, project, path, username, host, and credential identifiers have been removed or replaced with placeholders.

[jgarcialaneitor]

New occurrence on Gentle AI 2.2.4 / Windows / OpenCode.

Observed sequence (privacy-scrubbed):

1. Acquire a bounded first implementation work unit for an SDD change (max attempts: 1) -> proceed.
2. Complete that unit; focused verification passed (32 tests) and the production build passed.
3. Settle the unit as passed with a bounded opaque evidence revision.
4. Acquire a distinct, already-approved second implementation work unit for the same change -> state: complete, with no token.

Expected: after a passed first work unit, the distinct second work unit can obtain its own attempt authorization.

Actual: the ledger reported complete before the second work unit began, so the consumer workflow could not launch it without bypassing native attempt authority.

Mutation outcome and preserved state: the first unit had completed; the second unit made no changes and remains pending. Planning/apply state was preserved.

Minimal reproduction: settle any bounded work unit as passed, then acquire a second distinct work unit for the same active change.

Safe opaque evidence revision: sha256:3326b7a4944c29e67340f02008ab057b05a6517665bf35d588e47b98872b081e

No private project name, path, username, hostname, credential, raw command line, source content, diff, or environment values are included.

[NicolasAgustinIbarra]

Retested after upgrading the released CLI from v2.2.3 to v2.2.4. The installed v2.2.4 still reports complete: true and next_action: complete for the change after the task-decomposition attempt settled. A distinct first implementation work-unit cannot acquire an attempt because it receives state: complete. This was a read-only status check; no reset or consumer-state mutation was performed. Expected: a distinct planned implementation work unit can begin after task decomposition completes.

[Carlos0934]

New occurrence on released Gentle AI 2.2.4, OpenCode 1.18.11, Linux x86_64.

Observed sequence (privacy-scrubbed):

1. Acquire a bounded first implementation work unit (maximum attempts: 2; maximum changed lines: 500) -> proceed.
2. Complete that unit; 16 focused tests, 30 full unit tests, and formatting/lint checks passed.
3. Settle the unit as passed; status then reports complete: true and next_action: complete.
4. Acquire a distinct, approved second implementation work unit for the same active change -> state: complete, with no token.

Expected: a passed work unit completes only its own bounded objective, and the next distinct planned work unit can obtain a new attempt authorization.

Actual: the runtime ledger treats the whole active change as complete after the first implementation objective, so the second worker cannot launch without bypassing native attempt authority.

Mutation outcome and preserved state: the first unit wrote its intended changes and passed verification. The second acquisition made no repository mutation, no second worker launched, and all planning, implementation, and evidence state remains preserved.

Minimal reproduction: acquire and settle one bounded implementation work unit as passed, then acquire a second work unit with a different label and evidence goal for the same active SDD change.

Safe opaque evidence identifiers:

• Evidence revision: sha256:037f2db23825749fe9da92b41286799583cc007a71604f8ada5eda3b981b3ebf
• Runtime status revision: sha256:9168891464560ee3f14e701f703238a7240c84825a38487a60f9655b0de74a63

This reports observed behavior only; no root cause is asserted.