/**
 * The durable link between a roadmap item and its GitHub issue.
 *
 * The link is the item `id`, stamped on the issue as an HTML-comment marker. It is not
 * the `remote:` frontmatter field: creating an issue and writing a local link are two
 * writes to two systems, and every failure of the second leaves an issue with no link,
 * which the next run turns into a duplicate. With the id living server-side there is no
 * second write to fail, so the projection is a convergent rendering rather than
 * stateful sync — and can be thrown away and rebuilt.
 *
 * Two properties matter and both are easy to get wrong:
 *
 * - **Matching is position-independent.** A created body ends with the marker, but as
 *   soon as somebody comments or edits, it will not. Matching that depended on position
 *   would silently stop finding issues the moment the tracker was used.
 * - **Matching consumes the whole marker, terminator included.** The obvious
 *   implementation, `body.includes(id)`, resolves `item-20260907-foo` against the issue
 *   for `item-20260907-foo-2` — and that exact pair is manufactured by the roadmap
 *   skill's own collision rule, which suffixes a duplicate slug with `-2`. So the id is
 *   *extracted* and compared with `===`, never searched for as a substring.
 *
 * A third property was added by `richer-issue-bodies`:
 *
 * - **Matching is code-aware.** Once item prose is projected into the body, a marker
 *   quoted inside a fence or an inline code span is *visible code*, not a comment —
 *   GitHub renders it as text. A scanner that counted it would refuse runs as ambiguous
 *   over something no reader sees as a marker. The corpus holds exactly one such
 *   occurrence today, in a code span, so this is a measured case rather than a
 *   hypothetical one. The invariant to keep is that the scanner and the renderer agree.
 *
 * Requirements: roadmap-issue-projection/AC-47, roadmap-issue-projection/AC-48,
 * roadmap-issue-projection/AC-49, richer-issue-bodies/AC-15
 *
 * @module
 */
/** Render the marker for an item id. */
export declare function renderMarker(id: string): string;
/**
 * Every item id marked in a body, in order of appearance, de-duplicated.
 *
 * Returns an **array** rather than the first id. A single-id return would make the
 * two-markers case undetectable: the function would pick one and the projection would
 * confidently retitle or close the wrong issue. The plural return costs nothing and
 * makes the ambiguity representable, so `planProjection` can refuse instead of guess.
 */
export declare function findMarkerIds(body: string): string[];
//# sourceMappingURL=marker.d.ts.map