/**
 * Org sections spec 6.12 and 13.2 (piece P4.2): the single-writer rules as pure functions. Nothing outside
 * the writer files imports this yet, so nothing in the runtime changes; P4.4 wires it (definition findings,
 * `effectiveRolePolicy`, the boundary check at role start). The overlay (who is read-only and how) is in
 * `writer-overlay.ts` and re-exported here.
 *
 * `writerAuthority` classifies what a role can still do to the workspace after its overlay; `writerPreflight`
 * counts those roles (a role of the writing section with file-write authority or an open Bash, any role with a
 * tool provider or an unclassified tool, any role on a runner this core cannot qualify) and refuses more than
 * one. What it guarantees and does not is 13.2.2: file tools and a qualified shell for non-writers; the writer's
 * own Bash is unconfined.
 */
import { type WriterDef, type WriterOptions, type WriterStanding } from './writer-overlay.js';
import { type MutationReason, type WriterFinding } from './writer-text.js';
export type { WriterDef, WriterOptions, WriterOverlay, WriterRole, WriterStanding, } from './writer-overlay.js';
export { applyWriterOverlay, overlayFor, standingOf } from './writer-overlay.js';
export type { MutationReason, WriterCode, WriterFinding } from './writer-text.js';
export interface WriterAuthority {
    role: string;
    standing: WriterStanding;
    section?: string;
    workspace: string;
    /** Can the role change the shared workspace, after the overlay. */
    mutates: boolean;
    reasons: MutationReason[];
    /** Workspace-relative globs or directories the role may write through file tools; empty when it may not. */
    scope: string[];
}
/** What a role can do to the shared workspace, after the overlay (or as authored when none applies). */
export declare function writerAuthority(def: WriterDef, roleId: string, opts?: WriterOptions): WriterAuthority;
export interface WriterPreflight {
    errors: string[];
    warnings: string[];
    findings: WriterFinding[];
    /** Roles that can change each workspace, by workspace key. */
    writers: Record<string, string[]>;
    authorities: WriterAuthority[];
}
/** The writer preflight (6.12). Empty when no section declares non-empty `writes`. */
export declare function writerPreflight(def: WriterDef, opts?: WriterOptions): WriterPreflight;
export interface BuiltBoundary {
    /** `filesystem.denyWrite` the sandbox layer produced, canonical absolute paths. */
    denyWrite: string[];
    /** Directories the layer expanded into their children (`expandDenyWrite().mountPoints`): new entries in them stay writable. */
    mountPoints: string[];
}
/**
 * The reduced probe of 6.12 and 13.2.2, as a pure decision over what the sandbox layer built: the boundary of a
 * read-only role qualifies only when a deny covers the canonical workspace and the workspace itself (or anything
 * inside it) was not expanded into its children, which leaves new entries writable. `workspace` and the lists are
 * canonical absolute paths; the caller (P4.4) holds the role's start on `ok: false` and never widens access.
 */
export declare function boundaryQualification(role: string, workspace: string, built: BuiltBoundary): {
    ok: true;
} | {
    ok: false;
    finding: WriterFinding;
};
export interface WriteVerdict {
    /** False when no overlay applies to the role: this core says nothing. */
    applies: boolean;
    allowed: boolean;
    /** The text the role sees when refused. */
    refusal?: string;
}
/** May `roleId` write the workspace-relative `path` through file tools? (Who may write which path.) */
export declare function mayWrite(def: WriterDef, roleId: string, path: string, opts?: WriterOptions): WriteVerdict;
//# sourceMappingURL=writer-policy.d.ts.map