import type { ExtensionAPI, ExtensionFactory, ToolResultEvent } from "@earendil-works/pi-coding-agent";
import { type FrontendSafetyOptions } from "./safety.js";
import { type ContextLifecycleOptions } from "./context-lifecycle.js";
import { type TokenRateLimiterOptions } from "./rate-limit.js";
import { type FrontendValidationMode, type FrontendToolState } from "./tools.js";
export interface FrontendExtensionOptions extends FrontendSafetyOptions {
    /**
     * Default final-gate mode. `code` avoids starting the target project.
     * An explicit user request for screenshot or visual validation still opts
     * the current task into `visual` mode.
     */
    validationMode?: FrontendValidationMode;
    rateLimit?: TokenRateLimiterOptions | false;
    contextLifecycle?: ContextLifecycleOptions | false;
    autoValidateVue?: boolean;
    autoValidateQuality?: boolean;
    maxReadOnlyCallsBeforeVerification?: number;
    promptCacheHeader?: {
        name: string;
        value: string;
    };
}
export declare const FRONTEND_AGENT_RULES_MARKER = "<!-- ksyun-frontend-agent-rules -->";
export declare const FRONTEND_AGENT_RULES = "<!-- ksyun-frontend-agent-rules -->\n## Ksyun frontend agent rules\n\n- Inspect the project before generating code, and use only the exact installed package exports, type declarations, runtime metadata, and tests as component API truth.\n- Search in this order: compatible scene template, nearby repository usage and installed examples, exact installed contract/source, then online documentation only as an unverified last-resort clue.\n- For a recognizable list, detail, purchase, or image-based page implementation, call frontend_scene_template once with the exact intended targetFile and language=auto before writing the page, then reuse its composition and file plan. Retrieve only the best match. A compatible template already supplies component evidence: do not re-query its listed components unless you materially change their API usage. Copy a full-sfc result only after local adaptation; for composition-only, preserve the nearby Options API pattern and reuse its template/style structure.\n- A compatible template variant is an implementation baseline, not merely an example. Preserve its required root component and matching pagination/event/slot composition; adapt business columns and data around that skeleton. Never replace a returned ProTable template with a hand-built Table, or vice versa, unless a different template variant was explicitly resolved before the first page write.\n- Treat a scene template as an implementation accelerator, not a literal DOM contract. Preserve capabilities the task actually needs, but adapt header markup, documentation wording, columns, filters, and pagination ownership to the screenshot, repository conventions, and chosen component variant. In code mode, never rewrite valid markup merely to satisfy visual wording or a specific semantic tag.\n- If no compatible template covers the requirement, batch component names in component_query, then prefer component_usage from the installed tests/examples/source. Call component_contract only for required members those examples do not cover. Before composing Table/Dropdown/Select/Form/Menu/Tabs children or slots from scratch, call component_usage.\n- Every imported library component must have render-tested template evidence, exact contract evidence, or installed-usage evidence. Resolve component_validate evidenceGaps before another speculative edit.\n- Component documentation is not API truth and cannot override the exact installed package. If used as a last resort, verify the proposed API against installed declarations, tests, or source before editing.\n- Preserve installed component runtime defaults. KPC Table defaults to a built-in checkbox selection column; use v-model:checkedKeys or explicitly set check-type=\"none\" before implementing a manual Checkbox column.\n- Implement a minimal working slice early, but batch the planned view, mock, types, and pure utility files in one response when their contracts are already known. After any Vue/TypeScript mutation, resolve the exact automatic validation feedback before more than two additional read-only investigation calls.\n- For built-in write calls, always provide the required path argument before content. Keep generated views focused and adapt the returned template instead of regenerating a larger page from scratch.\n- Treat verification diagnostics as local evidence: inspect the attached failing source line and owning component, fix that expression first, and preserve unrelated template behavior such as selection, pagination, search, and totals.\n- Do not generate a monolithic page SFC. Keep views focused on presentation and interaction; in TypeScript projects move feature types to a colocated types.ts, while JavaScript projects keep JavaScript without adding TypeScript only for the template. Move search/filter/pagination pure functions to a colocated utils.ts or utils.js. A newly generated or materially expanded page above 500 lines blocks completion.\n- Decide on mock data only after inspecting nearby pages and the existing API/service/store/fixture layer. Reuse real adapters when they exist. For an isolated prototype or image-based implementation with no usable data source, keep deterministic mock records in a colocated mock.ts or mock.js that follows the project language instead of embedding them in the Vue file.\n- Default to code validation: validate changed Vue files, component contracts, template invariants, architecture, and available typecheck/lint/test/build gates. A supplied image is requirement input, not permission to start the project.\n- Call frontend_preview only when the user explicitly asks for screenshot validation, visual comparison/acceptance, pixel-level matching, or a rendered preview. In that opt-in mode, make the requested route directly reachable and require visual validation to pass. A single named reference image is selected automatically.\n- frontend_finish already runs the final full typecheck/lint/test/build plan. Do not call frontend_verify immediately before frontend_finish; use frontend_verify only for an earlier targeted progress check or to diagnose a blocker returned by the final gate.\n- Call frontend_finish only when the task is ready for the final full gate. In code mode it must report that runtime appearance was not verified and must not require a screenshot or SSIM comparison. A newly generated view must still be statically referenced by the existing Vue Router when the project has one.\n- If frontend_finish reports the same blocker twice, stop retrying it. Read the named source and exact diagnostic evidence, make one targeted correction, and rerun the cheapest relevant validator before the final gate.\n- Missing lint/test/typecheck scripts are residual risk, not permission to repair unrelated legacy files. Never edit files outside the requested feature merely to make a whole-project gate green.\n- Never claim completion unless the latest frontend_finish result has passed. If a non-retryable infrastructure failure blocks preview, report the blocker honestly instead of retrying or claiming success.\n- Never write outside the Pi cwd, access .env/secrets, or install/mutate dependencies without explicit host authorization.";
export declare function promptNeedsVisualValidation(prompt: string): boolean;
export declare function promptRejectsVisualValidation(prompt: string): boolean;
export declare function promptNeedsSceneTemplate(prompt: string): boolean;
export declare function promptReferenceImagePaths(prompt: string): string[];
export declare function promptRequestsMockData(prompt: string): boolean;
/**
 * Keep the package dormant for general coding work. It becomes active only
 * when the user explicitly asks for a frontend component-library workflow.
 */
export declare function promptNeedsFrontendComponentCapability(prompt: string): boolean;
interface ValidationDiagnosticLike {
    code: string;
    severity: string;
    line: number;
    message: string;
}
export declare function recordValidationDiagnostics(state: FrontendToolState, file: string, diagnostics: readonly ValidationDiagnosticLike[]): boolean;
export declare function recordVerificationScopeIssues(state: FrontendToolState, issues: readonly string[]): string[];
export declare function markDirtyToolResult(event: Pick<ToolResultEvent, "content" | "details">, dirtyFiles: string[]): {
    content: ToolResultEvent["content"];
    details: Record<string, unknown>;
};
export declare function registerFrontendExtension(pi: ExtensionAPI, options?: FrontendExtensionOptions): FrontendToolState;
export declare function createFrontendExtension(options?: FrontendExtensionOptions): ExtensionFactory;
declare const frontendExtension: ExtensionFactory;
export default frontendExtension;
//# sourceMappingURL=extension.d.ts.map