/** R5(车A [ref] 欠账,批γ 落地;[ref] 件1 补齐写口):memory 面的键宽写前守卫。
 *  列宽收窄后,模型/调用方可控的键(条目名 slug、租户盘 scope)超宽此前落裸 SQL 错(PG
 *  `value too long`)或非严格 MySQL 静默截断(截断=两个不同的键折叠成同一行=**条目互串 / 两个租户
 *  的盘塌成一个**,最危险形)。写前响亮拒,错误可分类。
 *  列宽同源门=test/key-width-guards.test.ts(守卫常量 vs 两方言 DDL 逐字对表);写口在场门=同文件
 *  「[ref] 件1」组(超宽键一条写语句都不许发出 seam)。
 *
 *  **本文件是这两个宽度的唯一属主**([ref] 件1):scope 守卫此前住在 `src/memory-scope.ts`,只被
 *  `memoryScopeFor` 的产出处消费,而 store 写口全无——同一个列宽有两个居所、两半消费面,正是
 *  「守卫在位≠写口接上」那类缺口的温床。`memory-scope.ts` 现在只**再导出**本文件的这两个符号
 *  (旧 import 路径逐字不变)。 */
/** memory-engine entry 表 `slug` 列宽(两方言 VARCHAR(512) 同宽;(scope,slug) UNIQUE 键预算注在 DDL)。 */
export declare const MEMORY_SLUG_COLUMN_CHARS = 512;
/** memory 面 `scope` 列宽(两方言 VARCHAR(190) 同宽:engine 的 entry/cursor 两表 + memory-sync 的
 *  sync_cursor/push_queue/history)。`formatUserScope`/`formatProjScope` 的段编码(百分号转义)会
 *  **膨胀**——非 ASCII principal 编码后可超列宽,故产出处与写口两道都要判。 */
export declare const MEMORY_SCOPE_COLUMN_CHARS = 190;
export declare function assertSlugWidth(slug: string): void;
export declare function assertMemoryScopeWidth(scope: string): void;
/**
 * 一个 entry 写(add / update)的两个键宽一起判 —— 两方言的 `applyOne` 在**任何 I/O 之前**调用它。
 *
 * 为什么两条腿共用一个入口而不是各自展开:add 与 update 写的是**同两列**(update 的
 * `SET scope = …, slug = …` 会改盘也会改名),R5 那批只护住了 add ⇒ 一次改名就能把超宽 slug 送进
 * DB。一个入口=两条腿不会再各自漂。
 *
 * 返回**字符串**而不是抛:两方言的 `applyPatches` 契约是「冲突进 report,不抛」(与
 * `unstorable_bytes` 的拒绝式同族——后端能力差异诚实暴露,重试恒同答=幂等成立)。`undefined` = 过。
 */
export declare function memoryEntryKeyWidthRefusal(scope: string, slug: string): string | undefined;
//# sourceMappingURL=memory-key-guards.d.ts.map