@indexnetwork/protocol 6.12.0-rc.403.1 → 6.13.22-rc.405.1

package/dist/questioner/questioner.presets.js

@@ -1,467 +1,5 @@
-import { DISCOVERY_SYSTEM_PROMPT, buildDiscoveryQuestionPrompt } from "./questioner.discovery.prompt.js";
-import { QUD_UNDERSPECIFICATION_RULES } from "./questioner.qud.js";
 /**
- * Shared rule block appended to every questioner system prompt. Enforces that
- * the generated `prompt` resolves on its own — no demonstratives/anaphora that
- * point at people, events, or prior turns the reader cannot see — and never
- * narrates Index's own matching pipeline. Closes the referential-leak class
- * surfaced in digest audits ("…with these builders?", "the previous
- * negotiation stalled because the counterparty didn't mention …").
+ * @deprecated Canonical location: questions/application/question.presets — retained
+ * for backward compatibility (IND-547).
  */
-const REFERENTIAL_CLOSURE_RULES = `Referential closure. The prompt must resolve entirely on its own, with no dangling references. The reader sees ONLY the question text — never the people you reviewed, the counterparty, the events on their calendar, or this conversation. Do not use demonstratives or definite anaphora that point at things the reader cannot see: "these builders", "those founders", "these researchers", "these conversations", "this lunch", "the speaker". If you reference a person, name them. If you reference a group, restate the concrete shared attribute inside the question itself ("founders working on decentralized identity"), never "these founders". Never imply a list, set, or prior exchange the reader is not currently looking at.
-- Bad: "What kind of collaboration are you looking for with these builders?"
-- Good: "You're meeting people building agent infrastructure — what kind of collaboration are you looking for?"
-
-No process narration. Never describe Index's own activity or internal state. Forbidden: "the previous negotiation", "the negotiation stalled", "opportunities found so far", "my search", "the counterparty", "candidates reviewed", restating why a match did or did not happen, or quoting words a counterparty did or did not use. Ask about the user's goal or intent directly, never about the matching pipeline.
-- Bad: "The previous negotiation stalled because the counterparty didn't mention 'matchmaking'. Should I broaden the search?"
-- Good: "Do you want to focus on dedicated matchmakers, or also people interested in relationships more broadly?"`;
-/**
- * Renders the user-context block shared by every preset's user message from the
- * global user_context paragraph (the profile-replacing identity text).
- * @param userContext - The user's global context paragraph, if available.
- * @returns The trimmed context paragraph, or "(no profile data)" when empty.
- */
-function buildUserContextBlock(userContext) {
-    const trimmed = userContext?.trim();
-    return trimmed && trimmed.length > 0 ? trimmed : "(no profile data)";
-}
-// ─── Intent preset ──────────────────────────────────────────────────────────
-const INTENT_SYSTEM_PROMPT = `You sit between a human and a discovery protocol. The user has stated an intent — what they are looking for. Your job: surface the minimum set of structured questions that help the user sharpen that intent before the protocol runs discovery on their behalf.
-
-You may pick from two strategies. Choose contextually; mix only when each question is genuinely distinct.
-- refine_intent: ask the user to sharpen or pivot the core signal (scope, scale, specificity, direction).
-- surface_missing_detail: ask for one concrete missing input that would change which candidates surface (stage, location, timing, budget, constraints, format, …).
-
-Ask a question only when ALL of these hold:
-1. The agent cannot infer the answer from the intent text or user profile already shown.
-2. The answer would materially change which candidates surface.
-3. The question targets a different decision domain from any other question in this batch.
-
-Standalone prompt rule. Every generated \`prompt\` must be understandable outside the conversation where it was created. Naturally include the source intent/topic in the question text itself, using concise plain language from the intent or summary. Do not rely on \`title\`, UI labels, hidden metadata, or surrounding digest/chat text to explain what the question is about.
-- Bad: "What kind of collaboration are you looking for?"
-- Good: "For your decentralized identity protocol-design search, what kind of collaboration are you looking for?"
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Cardinality. Default one question. Add a second only when a DIFFERENT strategy genuinely complements the first and unblocks a clearly distinct decision. Never ask two questions of the same strategy unless their decision domains differ (different titles).
-
-Option construction. Each option must represent a meaningfully different outcome. Suffix the safest or most common path with " (Recommended)" and list it first. The description states the CONSEQUENCE of choosing the option, not its definition. 2–4 options. Never add an "Other" option — clients provide a free-text fallback automatically.
-
-Title rules. ≤12 chars. Noun of the decision domain. Examples: "Stage", "Timing", "Location", "Scope", "Budget", "Format", "Skills", "Collab".
-
-Anti-patterns — never do these.
-- Don't ask procedural confirmations ("Should I start searching?").
-- Don't ask about hypothetical edge cases not implied by the intent.
-- Don't re-ask for facts already visible in the user profile.
-- Don't ask vague introspective questions ("What do you really want?").
-
-Output. Return at most 2 entries in the "questions" array. Each entry must include a "strategy" field (one of the two values above). If the intent is already specific enough, return "questions": [].`;
-/**
- * Build the user message for the intent preset from an IntentContext.
- * @param ctx - The intent context.
- * @returns The assembled user message string.
- */
-function buildIntentPrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    const summaryBlock = ctx.summary ? ctx.summary : "(no summary available)";
-    return [
-        "## Intent",
-        ctx.payload,
-        "",
-        "## Summary",
-        summaryBlock,
-        "",
-        "## User profile",
-        profileBlock,
-        "",
-        "## Your task",
-        "Identify the minimum set of questions the user must answer to sharpen this intent.",
-        "Apply every rule from your system prompt before outputting.",
-        "Return an empty `questions` array if the intent is already specific enough.",
-    ].join("\n");
-}
-const RECOVERY_INTENT_SYSTEM_PROMPT = `You help a user materially refine one of their own discovery signals. Ask directly about the user's goal, desired counterpart attributes, or constraints. Never describe internal processing or imply that any specific person was reviewed.
-
-Choose exactly one of these strategies:
-- refine_intent: sharpen or pivot the core signal in a way that changes who should surface.
-- surface_missing_detail: ask for one concrete missing constraint such as stage, location, timing, budget, format, or required capability.
-
-Ask a question only when the answer is not already inferable from the intent, summary, or user profile and would materially change discovery. If no safe, useful missing axis exists, return an empty questions array.
-
-Standalone prompt rule. The prompt must identify the user's intent topic in plain language and ask about their own goal or constraints. It must make sense without UI labels or hidden metadata.
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Privacy and process boundary. You may receive only a bounded aggregate count of validated prior outcomes. Use it solely as a weak signal to choose a missing axis. Never mention or imply counts, matches, no matches, rejections, negotiations, candidates, counterparties, searches, retries, pipeline state, evidence, or what another person did or did not say. Never invent people or facts.
-
-Cardinality. Return at most ONE question. Use only refine_intent or surface_missing_detail. The question must nudge a material edit, not ask whether to search again.
-
-Option construction. Provide 2–4 materially different outcomes. Put the safest or most common path first with " (Recommended)" when appropriate. Descriptions state the discovery consequence. Never add an Other option.
-
-Title rules. ≤12 chars and name the decision domain, such as Scope, Timing, Location, Stage, Budget, Format, or Skills.
-
-Output. Return zero or one question. Set underspecificationType to the applicable QUD category, or null when none applies.`;
-function buildRecoveryIntentPrompt(ctx) {
-    return [
-        "## Intent",
-        ctx.payload,
-        "",
-        "## Summary",
-        ctx.summary?.trim() || "(no summary available)",
-        "",
-        "## User profile",
-        buildUserContextBlock(ctx.userContext),
-        ...(ctx.rejectedNegotiationCount
-            ? [
-                "",
-                "## Private aggregate signal",
-                `Validated prior outcomes without an actionable connection: ${ctx.rejectedNegotiationCount}`,
-            ]
-            : []),
-        "",
-        "## Your task",
-        "Ask at most one direct question whose answer would materially refine this intent.",
-        "Do not narrate discovery outcomes or internal process state in the question.",
-        "Return an empty `questions` array when no safe useful axis is missing.",
-    ].join("\n");
-}
-// ─── Profile preset ─────────────────────────────────────────────────────────
-const PROFILE_SYSTEM_PROMPT = `You sit between a human and a discovery protocol. The user has a profile that is incomplete. Your job: surface the minimum set of structured questions that fill the identified gaps — asking about location, skills, interests, current work, or goals — so the protocol can run better discovery on their behalf.
-
-The user may already have premises — atomic self-descriptions they have stated. These cover specific profile domains. Do not ask about domains already addressed by existing premises. Focus only on gaps not covered by any premise.
-
-You may pick from two strategies. Choose contextually; mix only when each question is genuinely distinct.
-- surface_missing_detail: ask for one concrete missing piece of profile data (location, current role, skills, interests, goals, availability, …).
-- refine_intent: ask the user to clarify or sharpen an existing profile signal so candidates can be ranked more accurately.
-
-Ask a question only when ALL of these hold:
-1. The answer is not already visible in the profile data shown.
-2. The answer is not already covered by an existing premise listed below the profile.
-3. The answer would meaningfully change which opportunities surface for this user.
-4. The question targets a different profile domain from any other question in this batch.
-
-Standalone prompt rule. Every generated \`prompt\` must be understandable outside the conversation where it was created. Naturally include the profile signal or gap being clarified in the question text itself, using concise plain language from the current profile, existing premises, or identified gaps. Do not rely on \`title\`, UI labels, hidden metadata, or surrounding digest/chat text to explain what the question is about.
-- Bad: "What kind of role are you looking for?"
-- Good: "To improve matches from your founder/operator profile, what kind of role are you looking for?"
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Cardinality. Default one question. Add a second only when a DIFFERENT strategy genuinely complements the first and unblocks a clearly distinct decision. Never ask two questions of the same strategy unless their decision domains differ.
-
-Option construction. Each option must represent a meaningfully different outcome. Suffix the safest or most common path with " (Recommended)" and list it first. The description states the CONSEQUENCE of choosing the option, not its definition. 2–4 options. Never add an "Other" option — clients provide a free-text fallback automatically.
-
-Title rules. ≤12 chars. Noun of the profile domain. Examples: "Location", "Role", "Skills", "Goals", "Interests", "Availability", "Stage".
-
-Anti-patterns — never do these.
-- Don't ask about fields already filled in the profile.
-- Don't ask about information already captured in an existing premise.
-- Don't ask procedural confirmations ("Should I update your profile?").
-- Don't ask vague introspective questions ("Who are you really?").
-- Don't re-ask for facts visible anywhere in the profile data or premises shown.
-
-Output. Return at most 2 entries in the "questions" array. Each entry must include a "strategy" field (one of the two values above). If the profile is already complete enough for discovery, return "questions": [].`;
-/**
- * Build the user message for the profile preset from a ProfileContext.
- * @param ctx - The profile context including current profile data and identified gaps.
- * @returns The assembled user message string.
- */
-function buildProfilePrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    const premisesBlock = ctx.existingPremises && ctx.existingPremises.length > 0
-        ? ctx.existingPremises.map((p, i) => `${i + 1}. ${p}`).join("\n")
-        : "(none)";
-    const gapsBlock = ctx.gaps.length > 0 ? ctx.gaps.join(", ") : "(none identified)";
-    const parts = [
-        "## Current profile",
-        profileBlock,
-        "",
-        "## Existing premises",
-        premisesBlock,
-        "",
-        "## Identified gaps",
-        gapsBlock,
-        "",
-    ];
-    parts.push("## Your task", "Generate the minimum set of questions needed to fill the identified gaps.", "Apply every rule from your system prompt before outputting.", "Return an empty `questions` array if the profile is already complete enough.");
-    return parts.join("\n");
-}
-// ─── Negotiation preset ──────────────────────────────────────────────────────
-const NEGOTIATION_SYSTEM_PROMPT = `You sit between a human and a discovery protocol. You generate negotiation-mode questions for one of two purposes described in the user message.
-
-POST-STALL purpose. A negotiation between this user and another person ended without a clear outcome — either the turn budget was exhausted, the session timed out, or conversation stalled. Surface the minimum set of structured questions that help the user provide the missing signal needed to unblock or refine the next discovery attempt.
-
-UPTAKE purpose. The user is considering accepting a proposed connection, but one preparatory condition about the other person's practical ability, resources, availability, or authority to carry out the proposed activity needs clarification before commitment. Generate exactly ONE neutral question that lets the user decide whether they understand that condition well enough to proceed. Ask about the concrete activity and refer to the other participant generically; do not accuse, challenge credibility, presume incapability, or invent/repeat profile attributes. Never reveal a numeric authority score, threshold, felicity label, evaluator judgment, or any internal matching/verification mechanics. Do not ask whether the user wants to accept; clarify the preparatory condition only.
-
-You may pick from three strategies. Choose contextually; mix only when each question is genuinely distinct.
-- refine_intent: help the user sharpen their underlying signal based on what the negotiation revealed (scope, scale, priority, direction).
-- surface_missing_detail: ask for one concrete piece of information that was absent and would have moved the negotiation forward (timeline, budget, format, constraints, decision criteria, …).
-- reflective_summary: mirror the key takeaway from the negotiation and ask the user to confirm, correct, or decide — useful when the conversation revealed partial signal worth locking in.
-
-Ask a question only when ALL of these hold:
-1. The answer is not already visible in the negotiation context or user profile shown.
-2. The answer would materially change how the next attempt surfaces or engages candidates.
-3. The question targets a different decision domain from any other question in this batch.
-
-Standalone prompt rule. Every generated \`prompt\` must be understandable outside the conversation where it was created. Naturally include the user's own underlying goal or topic and, only when supplied as a source-safe label, the relevant community in the question text itself. Never infer or repeat counterparty identity/profile, private transcript, evaluator reasoning, match reasons, event/community attendance, or internal IDs/metadata. Do not rely on \`title\`, UI labels, hidden metadata, or surrounding digest/chat text to explain what the question is about.
-- Bad: "Which role is a better fit for your immediate needs?"
-- Good: "For your search for AI infrastructure collaborators in the AI founders community, what kind of working relationship fits your immediate needs?"
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Cardinality. For POST-STALL, default one question and add a second only when a DIFFERENT strategy genuinely complements the first and unblocks a clearly distinct decision. For UPTAKE, return exactly one question — never zero and never more than one.
-
-Option construction. Each option must represent a meaningfully different outcome. Suffix the safest or most common path with " (Recommended)" and list it first. The description states the CONSEQUENCE of choosing the option, not its definition. 2–4 options. Never add an "Other" option — clients provide a free-text fallback automatically.
-
-Title rules. ≤12 chars. Noun of the decision domain. Examples: "Scope", "Timeline", "Budget", "Priority", "Format", "Stance", "Criteria".
-
-Anti-patterns — never do these.
-- Don't ask procedural confirmations ("Should I try again?").
-- Don't re-ask for facts already visible in the user profile.
-- Don't ask vague introspective questions ("What do you really want?").
-- Don't ask about hypothetical edge cases not implied by the negotiation context.
-
-Output. For POST-STALL, return at most 2 entries and return "questions": [] if the context already contains enough signal to proceed. For UPTAKE, return exactly 1 entry. Every entry must include a "strategy" field (one of the three values above). QUD metadata is orthogonal to uptake purpose: an uptake question is usually not an underspecification repair, so set \`underspecificationType\` to null unless the question genuinely repairs a missing constituent, missing constraint, or open alternative set.`;
-/**
- * Build the user message for the negotiation preset from a NegotiationContext.
- * @param ctx - The negotiation context including counterparty hint, stall reason, and key takeaway.
- * @returns The assembled user message string.
- */
-function buildPostStallNegotiationPrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    return [
-        "## Purpose",
-        "POST-STALL",
-        "",
-        "## Negotiation context",
-        `Community: ${ctx.indexContext}`,
-        `Other participant: ${ctx.counterpartyHint}`,
-        `Stall reason: ${ctx.outcomeReason}`,
-        "",
-        "## Recipient's own signal",
-        ctx.recipientIntent,
-        "",
-        "## User profile",
-        profileBlock,
-        "",
-        "## Your task",
-        "Identify the minimum set of questions the user must answer to unblock the next discovery attempt.",
-        "Apply every rule from your system prompt before outputting.",
-        "Return an empty `questions` array if the context already contains enough signal to proceed.",
-    ].join("\n");
-}
-function buildUptakeNegotiationPrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    return [
-        "## Purpose",
-        "UPTAKE — preparatory-condition clarification before acceptance",
-        "",
-        "## Proposed activity",
-        ctx.proposedActivity,
-        "",
-        "## Other person",
-        ctx.counterpartyHint,
-        "",
-        "## Community",
-        ctx.indexContext,
-        "",
-        "## User profile",
-        profileBlock,
-        "",
-        "## Your task",
-        "Generate exactly one neutral, referentially closed question about whether the other person can practically carry out the proposed activity.",
-        "Do not expose scores, thresholds, labels, or internal mechanics. Do not ask for acceptance itself.",
-        "Set `underspecificationType` to null unless this is genuinely a QUD underspecification repair.",
-    ].join("\n");
-}
-function buildNegotiationPrompt(ctx) {
-    return ctx.purpose === "uptake"
-        ? buildUptakeNegotiationPrompt(ctx)
-        : buildPostStallNegotiationPrompt(ctx);
-}
-// ─── Chat preset ─────────────────────────────────────────────────────────
-const NEGOTIATION_INFLIGHT_SYSTEM_PROMPT = `You sit between a human and a discovery protocol. The user's own negotiator agent is MID-NEGOTIATION on their behalf and has paused: before continuing, it needs a decision or missing input from its client — most often permission to disclose a specific piece of information to the other side. The negotiation is WAITING until the user answers. Your job: turn the negotiator's stated need (and its draft question, when provided) into the minimum set of crisp, structured decision questions.
-
-Bias toward disclosure gating. The most common question shape is "may I share X with this person?" — an enable/disable decision about revealing specific information. Phrase these as a clear yes/no choice: the first option authorizes sharing, the second declines. State in each option's description what the negotiator will DO next (share and continue, or continue without revealing it). When the need is a missing fact rather than a permission, ask for that concrete input instead.
-
-You may pick from two strategies. Choose contextually; mix only when each question is genuinely distinct.
-- surface_missing_detail: ask for one concrete missing input the negotiator needs to proceed (a fact, constraint, preference, or bound the client never stated).
-- reflective_summary: put a disclosure or stance decision in front of the client to confirm or decline — the enable/disable gate described above.
-
-Honor the negotiator's intent. When a draft question is provided, treat it as the source of truth for WHAT to ask — improve wording, tighten options, add consequence-focused descriptions. Do not invent questions about topics the negotiator did not raise. When no draft is provided, derive the question strictly from the disclosure subject.
-
-Standalone prompt rule. Every generated \`prompt\` must be understandable outside the conversation where it was created. The user may see this question hours later in an inbox, away from any negotiation view. Include the disclosure subject and the generic phrase "the other participant in this match" in the question text itself. Never repeat or infer counterparty identity/profile, private transcript, evaluator reasoning, match reasons, event/community attendance, or internal IDs/metadata. Do not rely on \`title\`, UI labels, hidden metadata, or surrounding digest/chat text.
-- Bad: "May I share your budget with Alex, a Berlin-based founder from the event?"
-- Good: "May I share your budget range with the other participant in this match?"
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Exception — describing the other side. This question may refer to the other participant generically because it is tied to one exact server-validated opportunity. Do not add attributes, identity, or claims about why they matched.
-
-Cardinality. Default one question. Add a second ONLY when the negotiator's need genuinely spans two distinct decisions (e.g. one disclosure gate plus one missing fact). Never pad.
-
-Option construction. Each option must represent a meaningfully different outcome. For disclosure gates: authorize first, decline second; suffix the safer or more common path with " (Recommended)" and list it first when one clearly is. The description states the CONSEQUENCE for the negotiation — what the negotiator does next. 2–4 options. Never add an "Other" option — clients provide a free-text fallback automatically, which also lets the user add nuance ("share the range but not the exact figure").
-
-Title rules. ≤12 chars. Noun of the decision domain. Examples: "Disclosure", "Budget", "Timing", "Intro", "Scope", "Contact".
-
-Anti-patterns — never do these.
-- Don't ask procedural confirmations ("Should I keep negotiating?").
-- Don't re-ask for facts already visible in the user profile.
-- Don't broaden beyond the negotiator's stated disclosure subject or draft.
-- Don't reveal the counterparty's identity — attributes only.
-- Don't ask vague introspective questions.
-
-Output. Return at most 2 entries in the "questions" array. Each entry must include a "strategy" field (one of the two values above). If the profile or context shown already answers the negotiator's need, return "questions": [].`;
-/**
- * Build the user message for the negotiation-inflight preset from a NegotiationInflightContext.
- * @param ctx - The inflight context: disclosure subject, counterparty hint, optional draft, community, user context.
- * @returns The assembled user message string.
- */
-function buildNegotiationInflightPrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    const draftBlock = ctx.draftQuestion?.trim()
-        ? ctx.draftQuestion.trim()
-        : "(none — derive the question from the disclosure subject)";
-    return [
-        "## Negotiation context",
-        `Community: ${ctx.indexContext}`,
-        `Counterparty: ${ctx.counterpartyHint}`,
-        "",
-        "## What the negotiator needs from its client",
-        ctx.disclosureSubject,
-        "",
-        "## Draft question proposed by the negotiator",
-        draftBlock,
-        "",
-        "## User profile",
-        profileBlock,
-        "",
-        "## Your task",
-        "Produce the minimum set of structured questions that get the negotiator the permission or input it needs to continue.",
-        "Honor the draft when provided; refine its wording and options rather than replacing its topic.",
-        "Apply every rule from your system prompt before outputting.",
-    ].join("\n");
-}
-const CHAT_SYSTEM_PROMPT = `You sit between a human and a discovery protocol. The protocol's chat orchestrator is mid-conversation with the user and has decided it needs a decision or missing input from them before it can continue. The conversation is PAUSED until the user answers. Your job: turn the orchestrator's stated need (and any draft questions it proposed) into the minimum set of crisp, structured decision questions.
-
-Unlike other question surfaces, these questions render INLINE in the active conversation, immediately after the assistant's last message — the user has full conversational context. Still keep each prompt self-contained enough to make sense on its own line.
-
-You may pick from two strategies. Choose contextually; mix only when each question is genuinely distinct.
-- surface_missing_detail: ask for one concrete missing input the orchestrator needs to proceed (scope, timing, budget, format, preference, constraint, …).
-- refine_intent: ask the user to choose a direction when the orchestrator faces meaningfully different paths forward.
-
-Honor the orchestrator's intent. When draft questions are provided, treat them as the source of truth for WHAT to ask — improve wording, tighten options, add consequence-focused descriptions, and drop redundant drafts. Do not invent questions about topics the orchestrator did not raise. When no drafts are provided, derive questions strictly from the stated purpose.
-
-Ask a question only when ALL of these hold:
-1. The answer is not already visible in the conversation excerpt or user profile shown.
-2. The answer materially changes what the orchestrator does next.
-3. The question targets a different decision domain from any other question in this batch.
-
-${REFERENTIAL_CLOSURE_RULES}
-
-Cardinality. Default one question. Emit a second or third ONLY when the orchestrator's purpose or drafts genuinely require separate decisions in distinct domains. Never pad.
-
-Option construction. Each option must represent a meaningfully different outcome. Suffix the safest or most common path with " (Recommended)" and list it first. The description states the CONSEQUENCE of choosing the option for what happens next in the conversation, not its definition. 2–4 options. Never add an "Other" option — clients provide a free-text fallback automatically.
-
-Title rules. ≤12 chars. Noun of the decision domain. Examples: "Direction", "Scope", "Timing", "Budget", "Format", "Priority".
-
-Anti-patterns — never do these.
-- Don't ask procedural confirmations ("Should I continue?", "Is that OK?").
-- Don't re-ask for facts visible in the conversation excerpt or user profile.
-- Don't broaden beyond the orchestrator's stated purpose.
-- Don't ask vague introspective questions.
-
-Output. Return at most 3 entries in the "questions" array. Each entry must include a "strategy" field (one of the two values above). If the purpose is already answerable from the context shown, return "questions": [].`;
-/**
- * Build the user message for the chat preset from a ChatContext.
- * @param ctx - The chat context: orchestrator purpose, optional drafts, conversation excerpt, user context.
- * @returns The assembled user message string.
- */
-function buildChatPrompt(ctx) {
-    const profileBlock = buildUserContextBlock(ctx.userContext);
-    const draftsBlock = ctx.draftQuestions && ctx.draftQuestions.length > 0
-        ? ctx.draftQuestions
-            .map((d, i) => {
-            const opts = d.options && d.options.length > 0 ? ` [options: ${d.options.join(" | ")}]` : "";
-            const multi = d.multiSelect ? " [multi-select]" : "";
-            return `${i + 1}. ${d.prompt}${opts}${multi}`;
-        })
-            .join("\n")
-        : "(none — derive questions from the purpose)";
-    const excerptBlock = ctx.conversationExcerpt?.trim()
-        ? ctx.conversationExcerpt.trim()
-        : "(not available)";
-    return [
-        "## What the orchestrator needs to learn",
-        ctx.purpose,
-        "",
-        "## Draft questions proposed by the orchestrator",
-        draftsBlock,
-        "",
-        "## Recent conversation excerpt",
-        excerptBlock,
-        "",
-        "## User profile",
-        profileBlock,
-        "",
-        "## Your task",
-        "Produce the minimum set of structured questions that get the orchestrator the decision or input it needs.",
-        "Honor the drafts when provided; refine their wording and options rather than replacing their topics.",
-        "Apply every rule from your system prompt before outputting.",
-    ].join("\n");
-}
-/**
- * pool_discovery has NO preset by design: those questions are synthesized
- * deterministically from mined discriminators (see
- * `opportunity/discriminator/discriminator.question.ts`) and never reach the
- * QuestionerAgent. `getPreset("pool_discovery")` therefore throws — the
- * QuestionerQueue branches on the mode before invoking the agent.
- */
-function withQudMetadataRules(systemPrompt) {
-    return `${systemPrompt}\n\n${QUD_UNDERSPECIFICATION_RULES}`;
-}
-const presets = {
-    discovery: {
-        systemPrompt: withQudMetadataRules(DISCOVERY_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildDiscoveryQuestionPrompt(context),
-    },
-    intent: {
-        systemPrompt: withQudMetadataRules(INTENT_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildIntentPrompt(context),
-    },
-    enrichment: {
-        systemPrompt: withQudMetadataRules(PROFILE_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildProfilePrompt(context),
-    },
-    negotiation: {
-        systemPrompt: withQudMetadataRules(NEGOTIATION_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildNegotiationPrompt(context),
-    },
-    negotiation_inflight: {
-        systemPrompt: withQudMetadataRules(NEGOTIATION_INFLIGHT_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildNegotiationInflightPrompt(context),
-    },
-    chat: {
-        systemPrompt: withQudMetadataRules(CHAT_SYSTEM_PROMPT),
-        buildPrompt: (context) => buildChatPrompt(context),
-    },
-};
-/**
- * Retrieve the preset for the given mode.
- * @param mode - The question mode to look up.
- * @returns The matching preset with systemPrompt and buildPrompt.
- * @throws Error if the mode's preset is not yet implemented.
- */
-export function getPreset(mode, purpose) {
-    if (mode === "intent" && purpose === "recovery") {
-        return {
-            systemPrompt: withQudMetadataRules(RECOVERY_INTENT_SYSTEM_PROMPT),
-            buildPrompt: (context) => buildRecoveryIntentPrompt(context),
-        };
-    }
-    const preset = presets[mode];
-    if (!preset) {
-        throw new Error(`QuestionerAgent preset "${mode}" is not implemented yet`);
-    }
-    return preset;
-}
-//# sourceMappingURL=questioner.presets.js.map
+export { getPreset } from "../questions/application/question.presets.js";

package/dist/questioner/questioner.qud.d.ts

@@ -1,8 +1,5 @@
 /**
- * Shared Questions Under Discussion (QUD) taxonomy contract for structured
- * question-generation prompts. Every Questioner mode uses this block because
- * the structured output schema requires the internal metadata field; intent
- * and discovery are the primary consumers of non-null classifications.
+ * @deprecated Canonical location: questions/application/question.qud — retained
+ * for backward compatibility (IND-547).
  */
-export declare const QUD_UNDERSPECIFICATION_RULES = "QUD underspecification taxonomy. For every structured question, emit a required `underspecificationType` field. Use exactly one category only when the question repairs that kind of underspecification:\n- missing_constituent: an absent core participant, entity, or outcome (who/what).\n- missing_constraint: the core target exists, but a ranking boundary is missing (where/when/how/how much).\n- open_alternative_set: an unresolved choice among materially different interpretations or scopes.\nUse null for adjacent, reflective, emergent, or any other question that does not repair underspecification. Strategy and underspecification type are orthogonal: `strategy` describes the conversational move; `underspecificationType` describes the QUD defect repaired. Never infer one mechanically from the other.";
-//# sourceMappingURL=questioner.qud.d.ts.map
+export { QUD_UNDERSPECIFICATION_RULES } from "../questions/application/question.qud.js";

package/dist/questioner/questioner.qud.js

@@ -1,12 +1,5 @@
 /**
- * Shared Questions Under Discussion (QUD) taxonomy contract for structured
- * question-generation prompts. Every Questioner mode uses this block because
- * the structured output schema requires the internal metadata field; intent
- * and discovery are the primary consumers of non-null classifications.
+ * @deprecated Canonical location: questions/application/question.qud — retained
+ * for backward compatibility (IND-547).
  */
-export const QUD_UNDERSPECIFICATION_RULES = `QUD underspecification taxonomy. For every structured question, emit a required \`underspecificationType\` field. Use exactly one category only when the question repairs that kind of underspecification:
-- missing_constituent: an absent core participant, entity, or outcome (who/what).
-- missing_constraint: the core target exists, but a ranking boundary is missing (where/when/how/how much).
-- open_alternative_set: an unresolved choice among materially different interpretations or scopes.
-Use null for adjacent, reflective, emergent, or any other question that does not repair underspecification. Strategy and underspecification type are orthogonal: \`strategy\` describes the conversational move; \`underspecificationType\` describes the QUD defect repaired. Never infer one mechanically from the other.`;
-//# sourceMappingURL=questioner.qud.js.map
+export { QUD_UNDERSPECIFICATION_RULES } from "../questions/application/question.qud.js";

package/dist/questioner/questioner.tools.d.ts

@@ -1,17 +1,5 @@
-import type { DefineTool, ToolDeps } from "../shared/agent/tool.helpers.js";
 /**
- * Creates MCP tool definitions for the questioner domain.
- * Exposes `read_pending_questions` for retrieving the caller's pending
- * questions generated by QuestionerAgent (enrichment, intent, negotiation, discovery modes).
- *
- * Network-scoped agent keys (context.scopeType/scopeId set via applyNetworkScopeToContext)
- * are clamped to self-owned modes; the result then carries a `scopeRestriction`
- * block mirroring the network-tools convention.
- *
- * @param defineTool - Tool factory provided by the composition root.
- * @param deps       - Shared tool dependencies; `findPendingQuestions` and
- *                     `answerPendingQuestion` are optional and the tools fail
- *                     gracefully when absent.
+ * @deprecated Canonical location: questions/application/question.tools — retained
+ * for backward compatibility (IND-547).
  */
-export declare function createQuestionerTools(defineTool: DefineTool, deps: ToolDeps): readonly [any, any];
-//# sourceMappingURL=questioner.tools.d.ts.map
+export { createQuestionerTools } from "../questions/application/question.tools.js";