Conversation to spec

Produce one precise development authority and one separately loadable human explanation. Optimize the spec for compactness, traceability, and unambiguous execution; optimize the explainer for quick understanding. Never let the explainer become a second source of requirements.

Authority and boundaries

• Preserve consuming-repository safety, ownership, documentation, and architecture instructions. Within those boundaries, explicit user product decisions govern the requested outcome, followed by accepted domain and architecture records.
• Separate confirmed decisions from assumptions and unresolved questions. If product decisions conflict with repository safety or accepted architecture, preserve both claims and keep the spec draft or blocked; never choose silently.
• Do not reopen discovery or interview the user during this workflow. Record a material unknown in the authoritative spec and make decomposition readiness conditional.
• When the effort is too large or foggy to state its route-defining questions and settled decisions, stop and recommend decision-map; consume its resolved decision documents only after that map is ready-for-spec.
• Resolve the output language from repository instructions, then the user's request, and otherwise use Korean. Preserve quoted sources, identifiers, API names, links, and protocol markers exactly.
• Treat only the spec as normative. The explainer must declare kind: "spec-explainer", normative: false, derived_from, and source_fingerprint; it cannot be an input to to-tickets, tdd, or the Spec axis of code-review.
• Apply the plain-language invariant directly: preserve meaning and important details while adding no fact, requirement, advice, decision, or interpretation. Do not invoke bro, whose contract covers the last message rather than a source document.
• Use documenting-work to resolve persistence tier, path, identity, metadata, index, and lifecycle for both outputs. Keep exactly one normative body even when the explainer is durable.
• A request to draft returns two independently addressable conversation artifacts and creates no file. When the host cannot create separate response artifacts, return two canonical length-delimited envelopes with distinct IDs; only the complete spec envelope may be copied into a development handoff. An explicit request to persist a repository spec includes its declared paired explainer and locally required index or reciprocal links unless the user or repository forbids derived documents. Tracker publication, comments, and other external writes still require their own authorization.
• A published tracker spec is a planning or parent item, not an implementation ticket. Never add the ready-for-agent role. Use the selected tracker contract for state and Human action fields.
• Let work-github-issue own planning leases. Before tracker or other shared external writes, acquire a planning lease keyed to the source issue or key 0 when none exists. If unavailable, keep publication in the response.

Process