/**
 * Per-work-kind context scope: the narrowest slice of the repository a
 * step needs. Sessions PULL context by reading files, and every read is
 * re-sent on every later turn of that session — so the scope is the
 * main token lever: start in the narrowest useful directory, name the
 * paths that matter, and forbid surveying the rest.
 *
 * Derived from RepoLayout so it ports across templates like every other
 * path. Two deliberate limits: dynamic paths (the unit's own directory,
 * the slice's aggregate) are known only to the role composing the task,
 * so the guidance names them in words; and over-narrowing backfires —
 * when the compiler points outside the scope, following it is correct,
 * surveying is not. Exemplar citations in the prompts are NOT subject
 * to trimming: they are the cheapest quality lever there is.
 */
import type { WorkKind } from "./model-roster.js";
import type { RepoLayout } from "./repo-layout.js";
import type { ClientPlatform } from "./types.js";
export interface StepScope {
    /**
     * Repo-relative directory the session should treat as its workplace
     * ("." = the whole repository). Callers that launch sessions may use
     * it as the session's cwd.
     */
    workingDir: string;
    /** Repo-root-relative paths the step is expected to need. */
    paths: string[];
    /** One or two sentences: what else the step may reach for, and what not. */
    guidance: string;
}
/**
 * The scope for one work kind. `platform` narrows client-bound kinds to
 * one client; without it they span every client (the caller that knows
 * the platform should pass it).
 */
export declare function contextScopeFor(layout: RepoLayout, kind: WorkKind, platform?: ClientPlatform): StepScope;
/** The scope as a prompt section, appended to every session's prompt. */
export declare function scopeBriefing(scope: StepScope): string;