Work discovery one decision at a time

[sameera]

As a delivery lead, I want a resume session to claim and resolve exactly one open decision ticket, record the resolution, commit it, and graduate newly sharp fog, so that discovery advances decision by decision across sessions without parallel sessions colliding.

Acceptance Criteria

• Given a discovery folder, when the resume action runs without a named ticket, then it selects one decision ticket that is open, unblocked, and claimable, and claims it before any work begins. A user-named ticket is claimed the same way.
• Given a claim, then the ticket's frontmatter records who claimed it and when. The owner is the claimant's GitHub login, resolved the way the in-flight decision-stub rule resolves it, falling back to a slug of the git user name. The claim is not a boolean.
• Given a ticket that is unresolved and whose claim is older than the staleness threshold, then it may be taken over, and the takeover is recorded. The claim's scope is one working tree: two contributors working in two clones never see each other's claims, and a merge conflict is what tells them they collided.
• Given the ticket's type, when it is resolved, then resolution routes to existing machinery only: research to the Explore and nxs-architect agents (away from the keyboard), interview to nxs-pm and the nxs-setup interview pattern (human in the loop), contested trade-offs to a council-typed ticket, and unblocking legwork to a task-typed ticket.
• Given a council-typed ticket, then the session runs the two perspective agents itself and synthesises their output under the council's synthesis mandate. It does not hand off to /nxs.council, because a slash command cannot invoke another slash command and the ticket must not sit claimed across a session boundary.
• Given an interview-typed ticket, then it resolves only through the live exchange. The agent never answers for the human.
• Given an agent's research output, then it is recorded on the ticket as evidence and is never a resolution. Only the session marks a ticket resolved and writes its index gist, because a fact is not a decision.
• Given a resolution, then it is appended to the ticket file as a resolution section, the ticket's status moves to resolved, and exactly one gist line naming the ticket is appended to the discovery doc's resolved-decisions index. The ticket file remains the only store of the detail until graduation copies it onto the stubs.
• Given the resolved-decisions index, then it is append-only and order-insensitive, so two clones appending different resolutions merge cleanly, and it stays reconstructible from the ticket files, so a botched merge costs only a rebuild.
• Given fog made precisely statable by the resolution, then it graduates into new typed ticket files — created, then blocking wired — and is removed from "Not yet specified". Work the resolution rules beyond the destination moves to "Out of scope" and never graduates.
• Given one decision ticket resolved, then the session commits its claim, its resolution, and its index line as one commit, reports the commit, and stops. One decision is resolved per session. Research-typed tickets may run in parallel to it, and they resolve nothing. The command never pushes.
• Given any human-facing output, then tickets are referred to by title, never by a bare filename.

Notes

Extends #229. One commit per resolved decision is the granularity a reader wants, because each commit is one decision and its reasoning, so the commit history reads as the decision history. Pushing is left to the user, which keeps the command out of each repository's branch protection and review policy.

Parallel sessions on the same machine may work the same discovery, sharing one working tree, and git gives them no protection at all. The claim is what keeps them off each other's tickets. Separate clones are a different story: git handles them, and one file per ticket is what makes those merges clean.