Interactive Drop Selector

Interactive drop selector

Contract

Inputs

The user must supply or unambiguously identify the repository or tracker scope. Obtain the candidate items from a user-supplied list or a read-only tracker query within that scope. Optional filters may limit the candidate set. A closing comment or reason is optional and must be supplied or approved by the user before it is posted; do not invent one. Existing authenticated read and mutation access must be available, but never request, create, replace, or expose credentials as part of this workflow.

Procedure

1. Confirm that the request is an explicit human invocation and resolve the tracker scope, candidate source, and any filters. Stop as blocked if the scope is ambiguous or authenticated access is unavailable.
2. Read the candidate items and validate each item's stable identifier, type, title, current state, and tracker scope. Exclude already-closed items from selectable targets and identify them separately.
3. Present a numbered selection table containing each open candidate's stable identifier, type, title, and current state. Accept only selections that resolve uniquely to entries in this bounded table; reject unknown, duplicate, malformed, or out-of-scope selections.
4. Show a final preview of the exact selected identifiers, the repository or tracker scope, the consequence that each will be closed, and any comment that will be posted. Make no remote mutation yet.
5. Ask for explicit approval of that exact preview. A selection alone is not approval. If the user declines, changes the selection, or does not clearly approve, return cancelled without mutation or regenerate the preview and seek approval again.
6. Immediately before each close operation, re-read the target and confirm its stable identifier, scope, and open state still match the approved preview. If it changed, skip it and report a conflict; never widen or substitute the target set.
7. Close each still-valid approved target using the tracker's normal close operation, applying only the approved comment when one exists. Record the remote result for each target. Do not stop reporting after a partial failure, but do not retry an uncertain result until a read confirms whether the close occurred.
8. Re-read every approved target and classify it as confirmed-closed, failed, or conflict. The done predicate holds only when all approved targets are confirmed-closed.

Failure and recovery

• blocked: Return this when scope, candidate identity, credentials, permissions, or required tracker access is unavailable; make no close operations.
• cancelled: Return this when explicit approval is absent or withdrawn; make no close operations.
• conflict: Skip a target whose scope, identity, or state changed after approval. Require a new bounded preview and explicit approval before any later attempt.
• partial: If some approved targets close and others fail, preserve the confirmed remote results and report every target separately. Do not claim rollback, because closing is an external mutation; offer reopening only when the tracker supports it and only after separate explicit human approval.
• unknown-result: When a mutation response is interrupted or ambiguous, read the remote item before retrying. Classify the observed state; if it cannot be read, report the uncertainty and do not issue a duplicate mutation.

Never swallow tracker errors or report the done predicate while any approved target is failed, conflicted, or unverified.

Output

Return the tracker scope, the approved target set, and one terminal status per target with its stable identifier and observed remote state. Return overall confirmed only when all approved targets are verified closed; otherwise return blocked, cancelled, partial, or unknown-result with the exact reason and any remote mutations already confirmed.