Start discovery from a foggy initiative

[sameera]

As a delivery lead, I want /nxs.discover to open discovery on a large, foggy initiative — naming the destination first, then creating a committed discovery folder with its decision tickets — so that unresolved decisions become tracked work instead of speculative work-shaped stubs.

Acceptance Criteria

• Given intent text describing a foggy initiative, when /nxs.discover is invoked with it, then the start action runs. Resuming and closing are explicit named actions, so passing intent text is what selects start.
• Given a foggy initiative description, when start runs, then it names the destination first — pinned to Nexus's contract, that discovery is done when every functional goal is sharp enough to be a backlog stub of size M or smaller — and confirms it with the user (house AskUserQuestion convention) before creating anything.
• Given a confirmed destination, when start continues, then it confirms the initiative's feature (same one-prompt convention) and records it in the discovery doc. That feature is the default for every stub at graduation, overridable per stub.
• Given the slug derived from the intent already names a discovery folder in the committed store, then start offers a choice before creating anything: resume that discovery, or start a new one under a fresh key. Because the store is committed, this check also sees discoveries other people started and shared.
• Given a confirmed destination, when the discovery folder is created at .nexus/discovery/discover-<slug>-<key>/, then the folder holds the discovery doc and nothing a queue-scanning stage can act on. Living outside .nexus/queue/ is what keeps the folder invisible to the distiller's scan and to the analyze and decision-record resolutions. (Amended 2026-08-09: this criterion originally placed the folder at .nexus/queue/discover-<slug>-<key>/ and relied on the absence of an epic.md to hide it. Decision record Decision Record: Pre-epic discovery: /nxs.discover and the fog referral gate #235, approved 2026-08-08, reverses that placement and refutes it by name; location is the stronger mechanism.)
• Given the discovery doc, then it carries the destination, the feature, an empty resolved-decisions index, a "Not yet specified" section holding the in-scope fog, and an "Out of scope" section. No open ticket is listed in the doc; open tickets are found by listing the ticket files.
• Given open decisions that can be stated precisely now, when tickets are created, then each becomes its own ticket file beside the discovery doc, typed research, interview, council, or task in its frontmatter. Blocking edges are wired as frontmatter blocked_by in a second pass.
• Given a suspicion that cannot yet be phrased sharply, then it is written to "Not yet specified" and no ticket is created for it. The test is whether the question can be stated precisely now, not whether it can be answered now.
• Given the folder is created, then start commits it and reports the commit. It never pushes, opens a pull request, or merges.
• Given research-typed tickets, when start finishes, then it fires their research agents and stops. Start resolves no ticket itself.
• Given any artifact this command writes — discovery docs, ticket files, prompts — then it uses Nexus vocabulary only. No "map", "frontier", "charting", or "wayfinding". The fog sharpness test may survive in prose.

Notes

Adapted from the wayfinder skill's "chart" mode, re-grounded in Nexus vocabulary and pinned to the backlog-stub destination contract. A ticket is a question whose resolution is a decision, never a slice of build.

The store is committed because discovery is the stage most likely to need more than one person, and committing makes the whole loop shareable with tooling the team already has. It lives in a directory of its own, outside the queue, and two properties of that placement are load-bearing: a folder outside .nexus/queue/ is invisible to every stage that consumes the queue, and the distiller's range helper excludes .nexus/discovery/ alongside the queue, so discovery prose can never become a concept delta. No label, classification, or GitHub issue is created at any point in this story.