Pre-flight Checklist
📝 Bug Description
Current main can recover a compact settlement after the eligible-untracked inventory changes, but the managed guidance and benchmark corpus do not directly lock the executable recovery path.
The recovery that currently works is: receive the fresh digest from the stale-settlement refusal, retain the existing intended-untracked selection, and retry compact sdd-attempt settle with the same settle request ID. Some managed guidance still points callers toward Review STATUS or describes settle as having no recovery flags, and the existing j4040 journey does not directly prove same-ID settlement with a non-empty retained floor.
This issue requests test and guidance coverage only. It does not request a new production recovery object, a compact JSON schema change, or any runtime behavior change.
🔄 Steps to Reproduce
- On current
main, acquire an SDD attempt with one selected eligible-untracked path.
- Create another eligible-untracked path while the attempt is active.
- Run compact
sdd-attempt settle with the original inventory digest and a fixed settle request ID.
- Observe
blocked(undeclared_untracked) and the current inventory digest in the refusal.
- Retry compact
sdd-attempt settle with the same settle request ID, the returned digest, and the original path retained in the selection.
- Observe that settlement completes successfully.
- Inspect the managed SDD guidance and j4040 benchmark path; the successful same-settle-ID flow with a non-empty retained floor is not pinned end to end.
✅ Expected Behavior
The shipped guidance and benchmark coverage should match the already-working runtime behavior:
- Name compact
sdd-attempt settle as the recovery operation.
- Require the same settle request ID for the retry.
- Use the fresh eligible-untracked digest returned by the refusal.
- Preserve the non-empty retained intended-untracked selection as the selection floor.
- Do not route this SDD settlement recovery through Review STATUS.
- Add driven benchmark evidence for the complete flow.
No production runtime or compact response schema should change.
❌ Actual Behavior
The runtime recovery succeeds, but the managed guidance and benchmark corpus do not directly enforce the exact executable continuation. This leaves room for future instructions or journeys to route callers through the wrong subsystem even while unit-level behavior remains correct.
Gentle AI Version
Current main at 4a628900a6fa0990b2060ddc5cbbd33a5e6d550e.
Operating System
Linux (Ubuntu/Debian)
AI Agent / Client
Other
📋 Affected Area
CLI (commands, flags)
💡 Logs / Error Output
STALE_SETTLE_STATE=blocked
STALE_SETTLE_REASON=undeclared_untracked
DIGEST_CHANGED=true
SAME_SETTLE_ID=audit-settle
SAME_ID_RETRY_STATE=complete
FINAL_RETAINED_SELECTION=selected.txt
Additional Context
A detached current-main reproduction completed the same-ID retry without invoking Review STATUS. PR #4167 was correctly closed because its production enhancement was unnecessary for the original #4090 symptom; this issue deliberately retains only the smaller test/guidance follow-up invited in the maintainer's closure comment.
Acceptance criteria:
Non-goals:
Related evidence: #4040, #4066, #4090, and the closure comment on #4167.
This report was prepared with AI assistance from current-main source inspection, GitHub duplicate search, focused Go tests, and an isolated CLI reproduction. The user reviewed and confirmed the required pre-flight declarations.
Pre-flight Checklist
status:approved📝 Bug Description
Current
maincan recover a compact settlement after the eligible-untracked inventory changes, but the managed guidance and benchmark corpus do not directly lock the executable recovery path.The recovery that currently works is: receive the fresh digest from the stale-settlement refusal, retain the existing intended-untracked selection, and retry compact
sdd-attempt settlewith the same settle request ID. Some managed guidance still points callers toward Review STATUS or describes settle as having no recovery flags, and the existing j4040 journey does not directly prove same-ID settlement with a non-empty retained floor.This issue requests test and guidance coverage only. It does not request a new production recovery object, a compact JSON schema change, or any runtime behavior change.
🔄 Steps to Reproduce
main, acquire an SDD attempt with one selected eligible-untracked path.sdd-attempt settlewith the original inventory digest and a fixed settle request ID.blocked(undeclared_untracked)and the current inventory digest in the refusal.sdd-attempt settlewith the same settle request ID, the returned digest, and the original path retained in the selection.✅ Expected Behavior
The shipped guidance and benchmark coverage should match the already-working runtime behavior:
sdd-attempt settleas the recovery operation.No production runtime or compact response schema should change.
❌ Actual Behavior
The runtime recovery succeeds, but the managed guidance and benchmark corpus do not directly enforce the exact executable continuation. This leaves room for future instructions or journeys to route callers through the wrong subsystem even while unit-level behavior remains correct.
Gentle AI Version
Current
mainat4a628900a6fa0990b2060ddc5cbbd33a5e6d550e.Operating System
Linux (Ubuntu/Debian)
AI Agent / Client
Other
📋 Affected Area
CLI (commands, flags)
💡 Logs / Error Output
Additional Context
A detached current-main reproduction completed the same-ID retry without invoking Review STATUS. PR #4167 was correctly closed because its production enhancement was unnecessary for the original #4090 symptom; this issue deliberately retains only the smaller test/guidance follow-up invited in the maintainer's closure comment.
Acceptance criteria:
Non-goals:
RuntimeUntrackedRecoveryErroror typed compactrecoveryfields from closed PR fix(sdd): return native untracked recovery #4167.Related evidence: #4040, #4066, #4090, and the closure comment on #4167.
This report was prepared with AI assistance from current-main source inspection, GitHub duplicate search, focused Go tests, and an isolated CLI reproduction. The user reviewed and confirmed the required pre-flight declarations.