/**
 * Read the roadmap off disk into what the planner needs.
 *
 * Reads only. It does not judge: every refusal lives in `planProjection`, in one tested
 * order, so a tree with two problems always produces the same message.
 *
 * Two things this fixes about the obvious implementation:
 *
 * - `listStatus` silently skips an item whose frontmatter will not parse, because
 *   `readItem` returns null for both "absent" and "unparseable". A projection built on it
 *   alone would inherit that: an item invisible in the repo *and* on the board, with
 *   nothing anywhere saying so. Five of this project's first 49 items were invisible for
 *   up to ten days from exactly this. So `unparseableItems` is read alongside it.
 * - An item can parse perfectly and still carry no `id` — `readItem` returns `id: null`
 *   for a missing or empty key. `unparseableItems` does not detect that class, so
 *   `aidlc doctor` is silent about it. It is collected here as its own class so the
 *   refusal message can send the user somewhere useful.
 *
 * Everything resolves through `primaryCheckout`. A roadmap read from a worktree's copy is
 * a roadmap stranded on that branch, and for an inbox that is indistinguishable from
 * losing it.
 *
 * Requirements: roadmap-issue-projection/AC-33, roadmap-issue-projection/AC-34,
 * roadmap-issue-projection/AC-51
 *
 * @module
 */
import { type Milestone } from '../milestones.js';
import type { ProjectedMilestone } from './milestone-projection.js';
import type { ProjectableItem, UnprojectableRef } from './types.js';
export interface Collected {
    /** The primary checkout's working tree — everything below is relative to it. */
    root: string;
    items: readonly ProjectableItem[];
    unprojectable: readonly UnprojectableRef[];
    /**
     * Every item id → its repo-relative path, across **all five statuses**.
     *
     * Not restricted to the eligible ones. A `backlog` item routinely names the four `hold`
     * items it supersedes, and those references are the most useful links in the body
     * precisely because a reader cannot guess where a parked item went. Restricting this map
     * to projected statuses would drop them silently.
     */
    itemPaths: ReadonlyMap<string, string>;
    /**
     * The milestones as GitHub should show them, and each item id's milestone; null when no
     * milestones were passed in. Grouped by the same `milestonesView` `roadmap status` renders,
     * over every listed item, so the two cannot count differently (github-milestones/AC-5).
     */
    milestones: CollectedMilestones | null;
}
export interface CollectedMilestones {
    wanted: ProjectedMilestone[];
    assigned: ReadonlyMap<string, string | null>;
}
/**
 * A title for an item whose frontmatter has none.
 *
 * The filename slug, de-hyphenated. Refusing would be worse: the item is perfectly
 * projectable and the slug is a serviceable title, so a missing title is a cosmetic gap
 * and not a reason to block the whole run.
 */
export declare function titleFromFilename(filename: string): string;
/**
 * Read every status directory of the primary checkout containing `cwd`. `milestones` is the
 * parsed `milestones.yaml`, when on; the command reads it first so an invalid file refuses
 * before any `gh` call.
 */
export declare function collectItems(cwd: string, milestones?: readonly Milestone[] | null): Collected;
//# sourceMappingURL=collect.d.ts.map