import type { RuleApprovalRecord, RuleBehavior } from "@sema-agent/core";
/**
 * `PersistedRuleTool` **不再是闭词表**(core 7.9.0 / [ref]):工具名自 core 的**目录**派生
 * (`pathTarget` 声明 ⇒ 路径文法;`Bash` ⇒ 命令文法),型是 `string`。于是本文件对它的处置从
 * 「转录一份名单」换成「转 core 的**谓词**」——名单在 core 的目录里,抄一份的那天目录加一个带
 * `pathTarget` 的工具,本仓会静默拒收一整类合法行(正是本文件顶注说的那个病)。
 *
 * 谓词方向仍是 fail-CLOSED:`ruleToolGrammarOf` 认不出的名字**不是**一条可持久化规则的工具位
 * (既非命令文法也非路径文法 ⇒ 这条行永远匹配不上任何调用),两只店与票口一律拒。
 */
export declare function isPersistedRuleTool(name: string): boolean;
/**
 * `PersistedRuleMatch` 五员(core 顶注逐字):`exact` / `prefix`(历史 colon-star,永久兼容读、复合前缀形的
 * 唯一拼写)/ `wildcard`([ref] 尾 space-star,单命令体上与 prefix **同一谓词**,建议面自此铸它)/
 * `subpath`(Read 目录形,永不容纳任何命令)/ `path`(core 7.9.0 [ref]:路径族 deny/ask/allow 的模式文法
 * —— `//abs`、`~/`、`/root-relative`、cwd 相对,段内 `*`、跨段 `**`)。
 */
export declare const PERSISTED_RULE_MATCHES: readonly ["exact", "prefix", "wildcard", "subpath", "path"];
/**
 * S-511 —— `RuleBehavior` 每一员在**无同意仪式的直接写口**(`POST /v1/rules`)上的逐员表态。
 *
 * 为什么是一张**表**而不是一句 `behavior !== "allow"`:后者对 core 加员是**静默放行** —— 将来多一个
 * 放宽方向的态,它会直接从这条收紧口写进店,而没有任何一行代码会红。`Record<RuleBehavior, boolean>`
 * 少一员就是编译红([ref] 词表纪律:未知词必须是编译错),新词由人显式表态,而**方向由 `false` 兜底**
 * —— 加一员而忘了表态是编译红,表态成 `false` 是恒拒,两条路都不会悄悄放宽。
 *
 * 判据本身是 core 成文的那条不对称(`removePersistedRule` 头注逐字):收紧不需要同意仪式
 * (「a host may narrow on a user's behalf, it may not widen」),放宽需要 —— 所以 `allow` 的家是
 * 「一次点头」那条路(ask 回决携规则 / 导入面的票仪式),不是这条口。
 */
export declare const DIRECT_RULE_WRITE_ADMITS: {
    /** 放宽方向:一次人的点头才铸得出它,本口恒拒(端点侧 400,文案在冻结门里)。 */
    readonly allow: false;
    /** 收紧:一条常驻拒绝。 */
    readonly deny: true;
    /** 收紧:一条常驻提问(它把自动放行降级成问人,方向同样是收紧)。 */
    readonly ask: true;
};
/** 能经直接写口落店的那几员 —— 从上表**派生**,于是「允许哪几员」只有一个说话人。 */
export type DirectWritableRuleBehavior = {
    [B in RuleBehavior]: (typeof DIRECT_RULE_WRITE_ADMITS)[B] extends true ? B : never;
}[RuleBehavior];
/** 判别式谓词(收窄到 {@link DirectWritableRuleBehavior}):端点判过之后,`allow` 在**类型上**到不了写家。 */
export declare function isDirectWritableRuleBehavior(behavior: RuleBehavior): behavior is DirectWritableRuleBehavior;
/** [ref] §2.3 B3:batch offer 成员的判别位(`command` = 历史逐段 Bash 规则;`directoryRead` = cd 段铸的目录只读授权)。 */
export declare const RULE_OFFER_BATCH_MEMBER_KINDS: readonly ["command", "directoryRead"];
/** [ref] §3.5:一段「为什么仍未被覆盖」的闭三词集(`redirection` 永久逐次 / `no_rule_form` 无可覆盖形 / `cap_overflow` 去重+帽挤出)。 */
export declare const UNCOVERED_SEGMENT_REASONS: readonly ["redirection", "no_rule_form", "cap_overflow"];
/** [ref] §3.3-5:卡编辑面的 breadth 警告码(记录 `edited.warnings` 存的就是这两个字面)。 */
export declare const EDITED_RULE_BREADTH_WARNING_CODES: readonly ["broad_prefix", "compound_prefix"];
/**
 * [ref] §4.5 / [ref] §3.5 —— 审批记录的**形版本号**(core `RuleApprovalRecord.schema`,本批 3→4;[ref] 三态 behavior 进候选行)。
 * 类型绑 core 的字面型:core 再升号 ⇒ 这里编译红,两只 durable 店(SQL 双方言 + File)的 stale 判别与写侧钉
 * 同批随之;判别是**等式**(`!==`)不是下限 —— 旧号的行按 stale 信封交还(不迁移、不 widen、不丢行),
 * pending 卡短命,重触发即取新卡(B7/B8 既诺)。
 */
export declare const RULE_APPROVAL_RECORD_SCHEMA: RuleApprovalRecord["schema"];
/**
 * 一次撤销之后「这条规则还活着吗」的**三词闭集**(core 7.25.0 [ref]:`RemovalLiveness`)。
 * `"yes"` = 店说它还在(add-wins:撤销期间又落了一次新批准);`"no"` = 店说它不在了;
 * `"unknown"` = **回答这一问的那次读回没做成** —— 这个域唯一不肯说的那句话是「看不见 ⇒ 没有」,
 * 第三个词就是它的反面。
 *
 * 🔴 **型从 core 的包根导出接过来,本仓零抄**(core 7.26.0 S-538 ⓐ:`RemovalLiveness` 随请托上了导出面)。
 * 上一版是 `Extract<RemoveResult, {status:"removed"}>["stillLive"]` —— 那是派生而非手抄(值不会漂),但它把
 * 一只**独立的闭集**寄生在某一个臂的形状上:core 哪天给 `removed` 臂改名、或让这只词表先在别的臂上落地,
 * 派生式就会指向一个与词表无关的东西。现在两者同名同源。
 * 🔴 **运行期词表 `REMOVAL_LIVENESS_WORDS` 刻意不 re-export**:本仓对这三个词零运行期判据(值由 core 在两只
 * 200 体上原样透传,分支全走编译期穷尽),开一扇没人走的门只会让台账多一行「引用而不消费」的例外。
 * 哪天真要判「这个串在不在表里」,那时从 core 直接读它。
 */
export type { RemovalLiveness } from "@sema-agent/core";
//# sourceMappingURL=permission-rule-vocab.d.ts.map