/**
 * Emit the per-platform question rendering file
 * (explanatory-questions/AC-6, AC-7, AC-8, AC-10).
 *
 * The question protocol (content `resources/rules/question-protocol.md`) is
 * platform-neutral by contract: it says what a question must carry and names no
 * platform tool anywhere (AC-6).
 * That leaves a gap — the agent still has to know how to put a question in front
 * of *this* user — and this module is what fills it, writing one file per project
 * holding only the platforms that project actually configured.
 *
 * Deliberately NOT a platform adapter, for the same two reasons
 * `roadmap-skill.ts` is not:
 *
 *   1. Adapters re-serialize frontmatter from a fixed key set, so anything they
 *      do not already know about is dropped on round-trip.
 *   2. An adapter packages one body for one platform. This file is the opposite
 *      shape: one body carrying every configured platform's section, so a user
 *      who runs two agents against one checkout reads one file rather than
 *      guessing which of two applies.
 *
 * The rendering data lives in `packages/content/capabilities/<platform>.yaml`
 * under a top-level `questions:` key rather than inside `capabilities:`, because
 * `resolveActivation` returns exactly one activation string per phase and Claude
 * Code's plan mode already occupies `requirements` and `design` — the phases
 * questions get asked in. A second entry for those phases would silently lose to
 * the first.
 *
 * No path here is derived from user data: every segment is a module constant.
 *
 * @module
 */
import type { CapabilityMap } from '@rasensio/aidlc-content';
/** Repo-relative target, for reports and tests. */
export declare const QUESTION_RENDERING_PATH: string;
/** Outcome of one emission pass. */
export interface QuestionRenderingReport {
    /** Repo-relative path written, or null when nothing was written. */
    path: string | null;
    action: 'created' | 'updated' | 'unchanged';
    /** Platforms whose rendering reached the file, in the order they appear in it. */
    platforms: string[];
    warnings: string[];
}
/**
 * The capability maps for `platforms`, in the order given, skipping any platform
 * the content package does not ship.
 *
 * Filtering lives here rather than at the two call sites so that `init` and
 * `update` cannot drift apart on which platforms get a rendering.
 */
export declare function questionCapabilities(platforms: string[]): CapabilityMap[];
/**
 * Render the file body from the configured platforms' capability maps.
 *
 * Exported for tests: rendering is pure over its inputs, so section ordering,
 * the null-mechanism fallback text and the missing-block warning can all be
 * asserted without touching a filesystem.
 *
 * @param caps - Capability maps, already narrowed to the configured platforms.
 * @param version - Version to stamp, e.g. `1.29.2`.
 */
export declare function renderQuestionRendering(caps: CapabilityMap[], version: string): string;
/**
 * Write the rendering file into a project.
 *
 * @param projectRoot - Absolute project root.
 * @param caps - Capability maps for the configured platforms, from
 *   {@link questionCapabilities}.
 * @param version - Version to stamp into the body. Passed in rather than read
 *   here so tests can pin it.
 * @param opts.dryRun - Compute the report without writing.
 */
export declare function installQuestionRendering(projectRoot: string, caps: CapabilityMap[], version: string, opts?: {
    dryRun?: boolean;
}): QuestionRenderingReport;
/**
 * One-line summary of an emission pass, or null when there is nothing to say.
 *
 * `unchanged` is deliberately silent, for the reason `summarizeRoadmapSkill`
 * gives: a line on every run in the common case trains the reader to skip the
 * section it sits in.
 */
export declare function summarizeQuestionRendering(report: QuestionRenderingReport): string | null;
//# sourceMappingURL=question-rendering.d.ts.map