/**
 * Generic cell RPC action handlers.
 *
 * Six `request_response` actions bound to the specs in
 * `./cell_action_specs.ts`:
 *
 * - Mutations: `cell_create`, `cell_update`, `cell_delete`, `cell_clone`.
 * - Reads: `cell_get`, `cell_list`.
 *
 * Authorization model:
 *
 * - `cell_create` is authenticated at the spec level. The handler stamps
 *   `created_by` from `auth.actor.id`. `path` writes are admin-only —
 *   non-admin callers supplying `path` get `ERROR_CELL_PATH_ADMIN_ONLY`.
 * - `cell_get` is `optional` auth at the spec level. Per-row authorization
 *   via `can_view_cell(auth, cell)`. Misses + unauthorized reads both 404,
 *   so private-cell existence doesn't leak through the wire. Bundled
 *   relations are filtered to viewable targets (strict target-visibility).
 * - `cell_update` / `cell_delete` are authenticated at the spec level
 *   with per-row `can_edit_cell` enforcement. `path` writes on update
 *   are admin-only; `visibility` writes require the manage tier
 *   (`can_manage_cell`).
 * - `cell_list` is `optional` auth at the spec level. The SQL-side
 *   visibility predicate in `query_cell_list` admits null auth to
 *   public-only rows and authed callers to owned + public + grant-admitted
 *   rows; admin sees all. SQL-side because post-filtering in JS would
 *   silently truncate pages. The handler rejects the `created_by` filter
 *   for null auth (account-id enumeration guard).
 *
 * Mutations emit `cell_create` / `cell_update` / `cell_delete` audit
 * events via `deps.audit.emit(...)`. The `AuditLogConfig` threaded through
 * the consumer's `audit_factory` (see `create_app_backend`) must declare
 * the cell event types (see `./cell_audit_metadata.ts`).
 *
 * App vocabulary (e.g., collection / entry kinds) lives in client-side
 * helpers and per-app `validate_data` deps — this layer is generic-only
 * by construction.
 *
 * @module
 */
import { type RpcAction } from '../actions/action_rpc.js';
import type { RouteFactoryDeps } from './deps.js';
import { type CellJson } from './cell_action_specs.js';
import { type CellRow } from '../db/cell_queries.js';
import type { CellData } from './cell_data_schema.js';
/**
 * Dependencies for `create_cell_actions`.
 *
 * `validate_data` is the optional sub-API hook for per-kind shape
 * validation (e.g., a collection/entry registry). It runs on every
 * incoming `data` payload (create, update, clone-merged) and may throw
 * a `ZodError` — the handler converts that into the standard
 * `invalid_params` JSON-RPC error so per-kind validation failures
 * surface to clients with code -32602 (not -32603 / internal). When
 * omitted, payloads pass through as-is.
 */
export type CellActionDeps = Pick<RouteFactoryDeps, 'log' | 'audit'> & {
    validate_data?: (data: CellData) => CellData;
};
export declare const to_cell_json: (row: CellRow) => CellJson;
/** Create the six generic cell RPC actions. */
export declare const create_cell_actions: (deps: CellActionDeps) => Array<RpcAction>;
//# sourceMappingURL=cell_actions.d.ts.map