@sema-agent/core
Version:
Stateless, task-oriented AI agent core
677 lines (676 loc) • 41.1 kB
TypeScript
/**
* design/179 §4/§7/§13 — the ONE consent protocol every rule takes to enter the store through the engine.
*
* Single card, settings import and starter batch all reduce to the same three steps:
*
* durable approval record (pending) → authenticated confirmation transfer (approved) → principal-bound redemption (redeemed)
*
* and only the third step reaches the core-private writer. A host holding a record id cannot redeem it
* while it is pending, cannot redeem another principal's record, and cannot redeem free text — the
* redemption face takes a ticket and nothing else, so there is no field to write a rule of one's own into.
*
* The record is DURABLE, not an in-memory ticket: a safety ask can park, and the approval that redeems it
* may arrive in another process at another time. An in-memory ticket loses exactly that case.
*
* ## Crash order, and why replay is safe
*
* The record moves to `redeemed` — carrying the dot it minted — BEFORE the writer applies. A crash in
* between leaves a redeemed record whose rule is not in the store; replaying the redemption re-applies the
* SAME delta with the SAME dot, which the store folds idempotently. One redemption mints exactly one dot,
* for as many replays as it takes. Deliberately re-adding a deleted rule is a different act: a new ask, a
* new record, a new dot.
*
* ## The boundary this does NOT claim
*
* The confirmation transfer is an in-process call. A deployment must reach it only from its authenticated
* approval channel, and a deployment that shares filesystem credentials with the user can circumvent all of
* this by editing a file backend's file. That is the settings-file trust model, stated rather than
* defended against: for a file backend, host = user, no more and no less.
*/
import { type EditedRuleBreadthWarning, type UncoveredSegmentDetail, type RuleBehavior, type RuleOffer, type RuleRejectCode, type RuleScope, type RuleDot } from "./permission-rule-model.js";
import type { RuleOwner } from "./permission-rule-store.js";
import { type PermissionRuleStoreProvider } from "./permission-rule-provider.js";
/** One candidate rule inside an approval record: what it says (`behavior`), the exact text and where it
* would apply. A card mints `allow` candidates only (a card is one person's yes); the settings import
* carries all three behaviors, each entry under the list it was read from. */
export interface RuleCandidate {
behavior: RuleBehavior;
rule: string;
scope: RuleScope;
}
/** What the approval record is for — it decides the provenance the minted adds carry. */
export type RuleApprovalKind = "card" | "import" | "starter";
/**
* design/375 §4.1 — one "don't ask again" OPTION as the record stores it: references into the
* record's `candidates` by index, never rule text of its own. The display triple (rule, match,
* command) is deliberately NOT here — it is derived at projection time from the referenced
* candidate's text ({@link ruleOffersOfRecord}), so there is no stored copy to drift from the rule
* that would actually persist.
*
* · `kind: "single"` — one candidate covering the whole command.
* · `kind: "batch"` — a CONJUNCTION batch: confirming it is one yes to ALL of `candidates` at
* once, with no per-member sub-selection. On a CARD record the batch carries two MINT-TIME
* facts that cannot be re-derived from candidate texts and therefore must be stored:
* `segments` (each member's source segment, index-aligned with `candidates`),
* `uncoveredSegments` (the honest surplus count the wire offer disclosed, judged on the
* prepare-time coverage snapshot) and — since `schema: 3` (design/382 §3.5) — `uncoveredDetail`,
* one reason row per counted segment in segment order: WHY each stayed uncovered is a mint-time
* fact that cannot be re-derived from candidate texts, so it must be stored or a crash/reload
* rebuild would render a card that says less than the first render did (record-is-what-you-see).
* REQUIRED on a card batch, all three: "optional, validated when present" is the
* silent-absence-passes shape this record form already refused once, and it is not re-imported
* for the new seat. On an import/starter record there is no compound command
* and no coverage snapshot, so all three fields must be ABSENT — honest absence, never an
* empty-string stand-in. The read-side integrity checks refuse either direction's violation.
*
* Cardinality: a batch references 1..N candidates where N is the record's own candidate count.
* The wire offer's 1..5 is the CARD-lane minting cap — a card record inherits it by being minted
* there — while an import batch of twenty is a legal record; the two contracts are deliberately
* separate and neither speaks in the other's name.
*/
export type RuleOffer2 = {
readonly kind: "single";
readonly candidate: number;
} | {
readonly kind: "batch";
readonly candidates: readonly number[];
readonly segments?: readonly string[];
readonly uncoveredSegments?: number;
readonly uncoveredDetail?: readonly UncoveredSegmentDetail[];
};
/** A durable record of one pending/settled human decision about minting rules.
*
* Identity (design/182 §4.5, additive): a v1 record carries `principal` and nothing else — it stays
* valid forever and projects at runtime to a principal-kind {@link RuleOwner} (zero migration; pending
* and redeemed-but-unlanded records redeem across the upgrade unchanged). Only the local-owner path
* mints records with the `owner` field and NO principal. A record carrying both, disagreeing, is
* contradictory and unredeemable. */
export interface RuleApprovalRecord {
id: string;
principal?: string;
/** Structural owner (additive). Absent on every record a v1 tree minted. */
owner?: RuleOwner;
/**
* design/375 §4.5 — the record-form version stamp. A stored row WITHOUT it — or carrying an older
* number — predates this form; such a row confirms and redeems nothing (refused loudly,
* `record_schema_stale`) and is never read through a compatibility shim: pending approvals are
* short-lived, and re-triggering the command draws a fresh card. Stores hand pre-form rows back
* as {@link StaleRuleApprovalRecord}. `3` (design/382 §3.5, B8/B7): the card batch's
* `uncoveredDetail` seat became REQUIRED and `edited.warnings` became storable — a `schema: 2`
* row is read back stale exactly like the pre-stamp rows before it (the short-lived-pending
* bargain, unchanged). `4`: every candidate carries its `behavior` (the settings import now carries
* the deny/ask lists too) — a `schema: 3` row is stale by the same equality gate.
*/
schema: 4;
kind: RuleApprovalKind;
state: "pending" | "approved" | "redeemed";
candidates: RuleCandidate[];
/**
* The card's OPTION structure over `candidates` (design/375 §4.1). The flat candidate list stays
* the redemption/replay anchor — tickets, `redeemedDots` and the store writes all key on
* candidate indices, unchanged — while confirmation keys on OFFER indices into this array.
* Import/starter records are the whole-list normalization: one batch offer over every candidate,
* so all three entries speak one protocol. Offers are pairwise DISJOINT in membership (an
* unchosen offer's members must stay unredeemable, which overlapping offers could not
* guarantee); the mint sites satisfy that by construction and the read side refuses violations.
*/
offers: RuleOffer2[];
createdAt: string;
/** The ask this record was drawn from, for reconciliation. Advisory metadata; never adjudication input.
* `boundInputHash` is ALSO the card-edit binding anchor: an edited-candidate confirmation must echo
* it back, so a record minted without one refuses edits (there is nothing to bind the edit to). */
toolCallId?: string;
boundInputHash?: string;
/**
* The adjudicated command a CARD record was drawn for — the same post-rewrite bytes the ask carried
* (the form `boundInputHash` digests). Additive: absent on batch records and on every card a prior
* version minted. It is the edit gate's coverage input ("the edited rule must still admit THIS
* command"), so a record without one refuses edited candidates rather than guessing; the engine-
* candidate paths never read it.
*/
command?: string;
/** Monotonic revision of THIS record, bumped by every accepted transition. The compare-and-set key:
* comparing state alone cannot separate two different writes that both leave the state unchanged. */
rev: number;
/**
* Which OFFER the person actually chose, recorded by the confirmation transfer (design/375 §4.3;
* takes the seat the per-candidate selection held before offers existed).
*
* A card offers alternatives of different breadth and a human picks ONE. Without this, confirming
* the card would authorize every option on it: a host could redeem the narrow ticket, then later
* the wider one, and the second rule would exist without anyone ever having agreed to it.
* Choosing a BATCH offer is a conjunction — one yes to ALL of its member candidates at once —
* so every member becomes redeemable and every non-member stays unredeemable forever. Absent
* exactly while the record is pending.
*/
selectedOffer?: number;
/**
* The person-EDITED candidate this record carries, if any — full provenance for the one candidate
* whose text was authored at the card rather than derived by the engine. `index` names the appended
* row in `candidates` (whose `rule` holds the CANONICAL spelling); `text` keeps the raw input bytes
* exactly as submitted (the idempotency primary key — a client retrying a lost response resends the
* same bytes); `at` is when the edit landed. Present ⇒ the record's chosen offer is the single
* offer minted over this candidate (the append, the offer and the choice are one CAS write).
* Absent on every card settled through an engine candidate.
*
* `warnings` (design/382 §3.3-5) — the BREADTH warning codes the text gates raised on this edit,
* written in the same CAS that settles it: "the width was named before the yes" becomes a fact the
* record itself carries, auditable after any crash or upgrade. Optional; present only when a
* warning was raised, and when present it is an array from the closed code set (the read-side
* integrity gate refuses anything else). Codes only — the sentences are derivable from the
* canonical rule text and are deliberately not stored (no second copy to drift).
*/
edited?: {
index: number;
text: string;
at: string;
warnings?: readonly EditedRuleBreadthWarning["code"][];
};
/** Dots already minted for this record, keyed by candidate index — the replay anchor. */
redeemedDots?: Record<number, RuleDot>;
}
/**
* design/375 §4.5 — the minimal ENVELOPE a store hands back for a durable row that predates the
* CURRENT (`schema: 4`) record form. A typed read cannot honestly return such a row as a
* {@link RuleApprovalRecord}, and dropping it at the store layer would misreport "stale" as
* corruption — so the store contract is this variant instead: `staleSchema: true` plus the
* IDENTITY fields, which are spelled the same way in every version and therefore safe to read.
* The identity fields exist so the owner gate can still run, and it runs FIRST: a non-owner
* asking about a stale row is answered exactly like a non-owner asking about any row (existence
* is never confirmed); the stale disclosure is for the record's own owner only. Nothing else
* about the row is surfaced.
*/
export interface StaleRuleApprovalRecord {
readonly staleSchema: true;
readonly id: string;
readonly principal?: string;
readonly owner?: RuleOwner;
}
/**
* The durable home of approval records. A separate record type on purpose: it is not a checkpoint row and
* must not evolve with one.
*/
export interface RuleApprovalRecordStore {
/** A row whose `schema` is missing or unknown MUST come back as {@link StaleRuleApprovalRecord}
* (identity fields only) — never thrown away as a parse failure, never widened into a full
* record the current form cannot vouch for. */
get(id: string): Promise<RuleApprovalRecord | StaleRuleApprovalRecord | undefined>;
/**
* Compare-and-set on the record's REVISION, not on its state.
*
* State alone is not a compare-and-set key: a batch's second candidate transitions redeemed → redeemed,
* so two concurrent retries would both find the state they expected, both mint a dot, and both write —
* one silently overwriting the other's `redeemedDots`, which is how one approval becomes two adds and a
* deleted rule comes back to life. `next.rev` must be `expectRev + 1`.
*/
cas(id: string, expectRev: number, next: RuleApprovalRecord): Promise<boolean>;
create(record: RuleApprovalRecord): Promise<void>;
}
/** Everything the consent lane needs wired. */
export interface RuleConsentDeps {
provider: PermissionRuleStoreProvider;
approvals: RuleApprovalRecordStore;
/** Injectable clock/id for deterministic tests; defaults are the real ones. */
now?: () => Date;
newId?: () => string;
/**
* Deployment lever for the card-edit face: whether `confirmRuleApproval` accepts a FRESH
* `editedCandidate`. Absent or `false` = OFF (the default — the edit face widens what a fabricated
* confirmation could mint, from "one of the engine's bounded candidates" to "any same-head rule
* passing the coverage gate", so it is opt-in). Any other non-boolean value is a configuration
* mistake and refuses LOUDLY at the read — never silently mapped to a default. Replaying an edit a
* record already settled is a pure record read and does not consult this switch: the minting already
* happened, and withholding the receipt helps no one.
*/
cardEdits?: boolean;
/**
* design/382 §2.4-6 — the deployment's sensitive-read negative control for the directoryRead MINT
* floor, same-source with its compiled read-deny judge (`(d) => readDeny.matchPath(d) !== null` is
* the canonical wiring). Consulted only when a card would PROPOSE a directory authorization from a
* cd segment — never by the explicit-consent doors (hand-written, import), which carry their own
* preview and validation. Absent ⇒ the engine's built-in default deny table stands in (refusal-only).
*/
deniesDirectoryRead?: (directory: string) => boolean;
}
/** In-memory approval records — the test backend and the reference CAS semantics, the stale-row
* envelope read included. */
export declare class InMemoryRuleApprovalRecordStore implements RuleApprovalRecordStore {
private readonly rows;
get(id: string): Promise<RuleApprovalRecord | StaleRuleApprovalRecord | undefined>;
create(record: RuleApprovalRecord): Promise<void>;
cas(id: string, expectRev: number, next: RuleApprovalRecord): Promise<boolean>;
/** Test/inspection helper — how many records exist. The principal negative pins read this. */
size(): number;
}
/**
* design/375 §4.1 — project a record's stored offers into the wire {@link RuleOffer} shape: the
* AUTHORITATIVE card render source (record-is-what-you-see; the ask-time projection is advisory
* and may be coverage-narrower). The display triple (rule, match, command) is derived HERE, at
* projection time, by parsing each referenced candidate's stored text — never stored beside it,
* never accepted from a caller — so what a card shows is definitionally the rule that would
* persist; there is no second copy to corrupt. A batch offer's `segment`s and
* `uncoveredSegments` come from the mint-time facts the record carries.
*
* Card records only, in effect: an import/starter record's whole-list batch carries no segment
* metadata (its person-facing form is the import/starter PREVIEW, not an offer card), and asking
* for its card projection throws. A candidate text that no longer parses throws too — that is
* store damage on a row the validator once accepted, and rendering a wrong rule under a "don't
* ask again" label is the one failure a refusal always beats.
*/
export declare function ruleOffersOfRecord(rec: Pick<RuleApprovalRecord, "candidates" | "offers">): readonly RuleOffer[];
/** An opaque, single-purpose redemption ticket. Its only content is which record and which candidate. */
export type RuleTicket = string;
export declare function mintRuleTicket(recordId: string, candidateIndex: number): RuleTicket;
/**
* Create the pending record behind ONE approval card, and the tickets its options would redeem.
*
* The candidates are DERIVED here, from the call, by the same function that produced the options shown on
* the card — they are not an argument. That is the difference between the stated invariant and a wish:
* while this took a candidate list, a surface could display an approval for `git status` and build a
* record containing `Bash(rm:*)`, and every later step would faithfully honor the record. There is now no
* field in which to write a rule of one's own, on this entry as on the redemption entry.
*
* `toolCallId` and `boundInputHash` are recorded so an auditor can tie the record back to the exact ask,
* and a command the lane cannot speak for yields no record and no tickets at all.
*
* What this does NOT claim: that the command named here is the command that was displayed. A surface that
* shows one thing and says another is the same-layer trust §5 already states plainly — in an in-process
* deployment the host IS the user. What it closes is the gap where the rule TEXT never came from the
* engine at all.
*/
export declare function prepareCardApproval(opts: {
principal?: string;
/** design/182 §4.5 (additive): the structural owner — only the local-owner path needs it. */
owner?: RuleOwner;
/** The tool whose ask this card belongs to. Only the shell tool the rule lane speaks for is accepted. */
toolName: string;
/** The command as adjudicated — the same bytes the ask carried. */
command: string;
/** The ask's call id and argument digest, recorded for reconciliation. */
toolCallId?: string;
boundInputHash?: string;
/**
* Where a redeemed rule would apply — any of the three consent dimensions (design/382 §4.1).
*
* design/382 §4.4 (#490②, BREAKING B2) — the DEFAULT is no longer global:
* · present ⇒ used as given (the explicit channel; all three members legal, garbage refused loudly);
* · absent with `cwd` present ⇒ `{ kind: "project", root: cwd }`. Root = the adjudicated call's
* cwd is a deliberately NARROW default — the engine is a library and repository semantics are
* host business; a host wanting the true project root passes an explicit scope. The narrow cost
* is more asks (a nested-directory rule does not cover siblings), the safe direction;
* · both absent ⇒ a LOUD refusal (`config.missing_scope`): silent-global was the #490② defect,
* silent-project has no root to anchor, and "where does this consent land" is not guessable.
*/
scope?: RuleScope;
/**
* design/382 §4.3 — the SESSION IDENTITY of the adjudicated call, threaded by the caller from the
* original call context exactly like `cwd` (never inferred from the process). It is the coverage
* read's third eligibility axis: with it, a standing session rule of that session counts as
* coverage; without it, no session rule covers anything (fail-closed). Independent of `scope` on
* purpose — `scope` names where a NEW consent would land, this names where the CALL is running.
*/
sessionId?: string;
/**
* The working directory of the ADJUDICATED CALL — the same task root the gate's lane judged
* with — threaded by the caller from the original call context. Never inferred from `scope`
* (a rule's landing scope is not where the call ran; nested project roots make the two
* coverage answers diverge) and never from the process. Absent, a project-scope rule covers
* nothing (the shared predicate's fail-closed arm), so segments lean UNCOVERED and the batch
* leans wide — the over-offer direction, which redemption's per-rule validation keeps safe.
*/
cwd?: string;
/**
* design/382 §2.4 (adversarial-review r2) — the EXECUTION working directory of the adjudicated
* call: the live tracked cwd the shell will resolve a relative `cd ./x` against, threaded by the
* caller exactly like `cwd` (the runner's ask-projection seat threads its `handsCwdRef.current`;
* a host preparing cards for its own calls threads whatever base those calls execute under).
* ONLY the relative-cd resolution reads it; scope eligibility and the derived project scope stay
* on `cwd`. Absent ⇒ `cwd` is the base (the single-value deployment, where the two coincide).
* Present and DIFFERENT, it is what keeps this durable consent path and the advisory ask-time
* projection minting the SAME directory member — two faces reading one world.
*/
execCwd?: string;
deps: RuleConsentDeps;
}): Promise<{
approvalId: string;
offers: readonly RuleOffer[];
tickets: RuleTicket[];
candidates: RuleCandidate[];
} | undefined>;
/**
* The authenticated confirmation transfer: pending → approved.
*
* A deployment must reach this ONLY from the channel that actually carries a human decision — the same
* channel an approval card's yes travels. Nothing below this line can tell an authentic confirmation from
* a fabricated one, which is why the boundary is stated here rather than checked here.
*/
export declare function confirmRuleApproval(opts: {
approvalId: string;
principal?: string;
/** design/182 §4.5 (additive): the structural owner — only the local-owner path needs it. */
owner?: RuleOwner;
/**
* The index of the OFFER the person chose — into the record's `offers`, the same order
* `prepareCardApproval` returned them (design/375 §4.3). A card presents alternatives of
* different breadth, so "they said yes" is not an answer on its own — "they said yes to THIS
* one" is. A single offer authorizes its one candidate; a BATCH offer is a conjunction, one yes
* to ALL of its member candidates at once, with no per-member sub-selection. May be omitted
* exactly when the record carries ONE offer (a single-element choice space has no ambiguity —
* the import/starter whole-list batch lands here); a multi-offer record with no selection
* refuses `selection_missing`. Mutually exclusive with `editedCandidate`.
*/
selectedOffer?: number;
/**
* The person-EDITED rule text for this card, travelling on the SAME authenticated confirmation
* channel as a choice among the engine's candidates (never the un-authenticated prepare entry, which
* keeps refusing caller candidates). `text` is the rule as authored; `boundInputHash` must echo the
* record's own bound-input digest — the submitter's proof of "I am editing the card that showed THIS
* command", an in-process mis-binding fence (a caller holding only a leaked approvalId cannot spell
* it), not a cryptographic one. The engine validates the text through the one shared validator,
* requires it to still ADMIT the adjudicated command, appends it as a new candidate and binds the
* selection to it, returning the minted ticket. Mutually exclusive with `selectedOffer`.
*/
editedCandidate?: {
text: string;
boundInputHash: string;
};
deps: RuleConsentDeps;
}): Promise<ConfirmResult>;
/** Why a confirmation did not land. A closed set so a host can branch (re-present, re-fetch, give up).
* The two `record_*` members past `record_not_found` are the durable-row gates (design/375 §4.5/§4.7),
* disclosed to the record's own owner only — a non-owner gets `record_not_found` for every row:
* - `"record_schema_stale"` — the record predates the current (`schema: 4`) form; the decision it carried
* is void, and the recovery path is re-triggering the command for a fresh card (no
* compatibility read, no migration — `detail.message` says so);
* - `"record_malformed"` — the record's offer structure failed the read-side integrity checks
* (store damage); `detail.message` names the breakage.
* The three `edit_*` members are the card-edit face's own refusals:
* - `"edit_disabled"` — the deployment has not opted into card edits (`RuleConsentDeps.cardEdits`);
* - `"edit_binding_mismatch"` — the confirmation does not echo the record's bound-input digest
* (missing echo, a record minted without one, or a different card). Refused BEFORE anything else,
* settled replays included, and never returns a minted ticket;
* - `"edit_rejected"` — the edited text failed a gate (validator refusal, coverage, record shape);
* `detail` carries the specifics. */
export type ConfirmRefusalReason = "record_not_found" | "record_schema_stale" | "record_malformed" | "selection_missing" | "selection_invalid" | "selection_mismatch" | "not_pending" | "conflict" | "edit_disabled" | "edit_binding_mismatch" | "edit_rejected";
/** The confirmation outcome: landed, or refused with a named reason.
*
* `mintedCandidate` (additive) is present exactly when an EDITED candidate settled this confirmation —
* fresh mint and idempotent replay alike (a client retrying a lost response gets the same index, the
* same canonical rule text and the same deterministically re-minted ticket, never a push toward a
* second card). `rule` is the CANONICAL spelling, which may differ from the submitted bytes (spelling
* normalization); a surface echoes it back so the person sees the form that will actually persist.
*
* `detail` (additive, refusal arm) rides `edit_rejected`: `code` is the shared validator's refusal
* code when the validator is what refused, absent when another gate did; `message` always says why. */
export type ConfirmResult = {
ok: true;
mintedCandidate?: {
index: number;
rule: string;
ticket: RuleTicket;
};
} | {
ok: false;
reason: ConfirmRefusalReason;
detail?: {
code?: RuleRejectCode;
message: string;
};
};
/**
* What the TEXT×COMMAND gates answered. `canonicalRule` is the spelling that would actually persist,
* which may differ from the submitted bytes (spelling normalization). On the refusal arm, `code` is the
* shared validator's own refusal code when the validator is what refused, and is ABSENT when the
* coverage gate refused — the same presence rule the confirmation's `edit_rejected` detail carries,
* because they are the same values from the same body.
*/
export type EditedRuleTextPrecheck = {
ok: true;
canonicalRule: string;
/**
* design/382 §3.3-5 — BREADTH notes about the accepted rule (additive; absent = nothing to
* say). A warning is never a refusal: the muscle-memory wide forms are legal (§3.4), and this
* seat is what makes accepting one an informed act. Rendering them beside the input line is
* the surface's duty (the engine cannot force a display); what the ENGINE guarantees is the
* durable half — a confirmation through the edit arm writes the hit codes into the record
* (`edited.warnings`), so "the width was named before the yes" is an auditable fact. The
* confirmation result deliberately does NOT repeat them (one fact, one loud place).
*/
warnings?: readonly EditedRuleBreadthWarning[];
} | {
ok: false;
code?: RuleRejectCode;
message: string;
};
/**
* Would this edited rule text pass the card-edit face's text gates for this command? A pure function,
* for a surface that wants to answer while the person is still typing instead of after a round trip.
*
* It is the SAME body the confirmation arm runs (`checkEditedRuleText`), which is the whole point: a
* boundary that re-implements the check — or calls `parseRuleText` directly — installs a SECOND,
* STRICTER judge that refuses spellings the edit face accepts (the muscle-memory `Bash(adb *)` form is
* exactly such a case: the validator alone refuses it as a wildcard; the edit face normalizes it first).
*
* TWO THINGS IT DOES NOT SAY, and a surface's wording has to respect both:
* · `ok` means SUBMITTABLE, not "the confirmation will succeed". The record-level gates — the binding
* echo, the record's owner and state, scope inheritance, the deployment switch — are not inputs here
* and are re-decided by `confirmRuleApproval` against the record.
* · `canonicalRule` may differ from the bytes passed in (spelling normalization). It is the spelling
* that would persist, so an inline reviewer should show THAT form rather than echoing the input.
*
* The two arguments are different kinds of thing, and are treated differently on purpose: `text` is a
* PERSON's input, so every malformed spelling of it is an answer (a refusal), never a throw. `command`
* is the CALLER's context — the adjudicated command the card was drawn for — and an absent or non-string
* one is a caller bug: answering "your rule does not admit the empty command" would read to the person
* as a verdict on what they typed, so it refuses loudly instead of misattributing the fault.
*
* ONE RECORD SHAPE A CALLER MUST NOT ASK ABOUT: a card carrying no adjudicated command at all (minted
* before the field existed, or by a store that dropped it). That is a RECORD-level refusal, and this
* function is the text half — passing its absent command here is asking a question with no answer, and
* it throws rather than inventing one. A host holding such a record already knows the outcome without
* asking: `confirmRuleApproval` refuses the edit with a message that says coverage cannot be verified,
* so the surface's move is to not offer the edit box at all.
*/
export declare function precheckEditedRuleText(text: string, command: string): EditedRuleTextPrecheck;
/** What a redemption produced. `alreadyRedeemed` marks the replay path — the same dot, no second rule.
*
* `rev` is the DURABLE store's revision. A session-scope redemption (design/382 §4.3) lands in the
* session overlay and does not move it: its `rev` is a best-effort read of the store's current
* revision (0 when the store could not be read — the landing is in the overlay either way, and the
* durable revision is reporting, not the landing's identity). */
export type RedeemResult = {
status: "redeemed";
behavior: RuleBehavior;
rule: string;
scope: RuleScope;
dot: RuleDot;
rev: number;
alreadyRedeemed: boolean;
} | {
status: "refused";
reason: string;
};
/**
* Redeem one ticket into one persisted rule.
*
* Takes a ticket and a verified principal, and nothing else. There is deliberately no field carrying rule
* text: what gets persisted is what the engine put in the record when it drew the card, so a host cannot
* turn a click on `git status` into a rule for something else.
*/
export declare function redeemRuleTicket(opts: {
ticket: RuleTicket;
principal?: string;
owner?: RuleOwner;
deps: RuleConsentDeps;
}): Promise<RedeemResult>;
/** The three user-editable settings layers this version reads. */
export type ImportedSettingsLayer = "userSettings" | "projectSettings" | "localSettings";
/** One layer to read. `root` is the canonical directory a project-layer rule is scoped to — taken from
* where the FILE actually lives, since the local layer is not always at a repository root. */
export interface CcImportLayer {
layer: ImportedSettingsLayer;
path: string;
root: string;
readFile: (path: string) => Promise<string | undefined>;
}
/**
* What the import WOULD do, shown before anyone confirms.
*
* `uncovered` is a fixed-key record, not a list: everything this version does not import is named in the
* TYPE, so an empty list, a missing member or a duplicate is not expressible. A preview that reported only
* what it read would be claiming completeness it does not have.
*/
export interface ImportPreview {
candidates: RuleCandidate[];
skipped: Array<{
rule: string;
reason: string;
}>;
/**
* ALWAYS EMPTY in this version — a compatibility seat, kept on the wire shape so an existing reader
* keeps finding the key (removing a wire field would break readers for no gain).
*
* The seat once carried the entries whose MATCH FORM was rewritten on the way in (the space-star
* suggestion form of the other product translated to this lane's colon-star form, one row per
* translated candidate with its `scope`). That translation is retired: the space-star wildcard is
* now a first-class match form of this lane's own grammar, so an entry's match form imports as the
* file states it — `Bash(npm run *)` lands as `Bash(npm run *)`, never as a colon-star — and nothing
* is ever pushed here. What `candidates` carries is the grammar's CANONICAL re-projection of each
* entry (the parser folds spacing: `Bash(npm<TAB>run *)` lands as `Bash(npm run *)`); that is the
* ordinary normalization every rule text in this lane undergoes, the same one the store applies,
* and not a translation this seat reports. An entry whose star placement has no rule form is
* refused into `skipped` under `unsupported.wildcard`, named as the file writes it. A reader
* rendering a "rewritten spellings" column from this seat renders an empty column, correctly.
*/
translated: Array<{
from: string;
to: string;
scope: RuleScope;
}>;
layers: Array<{
path: string;
layer: ImportedSettingsLayer;
found: boolean;
}>;
/** The two SETTINGS LAYERS this version does not read at all. The three permission lists of the layers it
* does read — allow, deny AND ask — are all imported (each candidate carries its `behavior`), so there
* is no longer a "left in place" count beside them: an entry that did not become a candidate is in
* `skipped` with its reason. */
uncovered: {
flagSettings: "not-imported-v1";
policySettings: "not-imported-v1";
};
}
/**
* One member row of a batch redemption's FULL table (design/375 §4.6) — what actually happened to
* each candidate of the chosen offer, keyed by its ORIGINAL candidate index. `candidateIndex` is
* the member's identity: the same rule text can be two candidates in two scopes with two different
* outcomes, so the bare text is not a key. A successful row always carries its `dot` and the
* independent `alreadyRedeemed` axis (the single-leg replay marker: a dot-recorded-but-unlanded
* retry is `alreadyRedeemed: true` AND `persisted`; a rule that pre-existed in the store is
* `false` AND `deduped` — the two axes answer different questions and neither implies the other).
* A refused row always carries its `reason`. `deduped` counts as LANDED: an equivalent rule
* already standing means the consent is already in effect.
*
* design/382 §4.3 — on a SESSION-scope member the two landed words mean the same thing about a
* different home: landed in / already in the session's OVERLAY (a session rule's home store), never
* the persisted store. The words state that the landing happened; DURABILITY is what the member's own
* `scope` says, so a consumer never has to guess it off the status (deliberately no fourth status
* value — the closed set names landing outcomes, not storage classes).
*/
export type RedeemedBatchMember = {
readonly candidateIndex: number;
readonly behavior: RuleBehavior;
readonly rule: string;
readonly scope: RuleScope;
readonly status: "persisted" | "deduped";
readonly alreadyRedeemed: boolean;
readonly dot: RuleDot;
} | {
readonly candidateIndex: number;
readonly behavior: RuleBehavior;
readonly rule: string;
readonly scope: RuleScope;
readonly status: "refused";
readonly reason: string;
};
/**
* Read the THREE permission lists (allow, deny, ask) of the user-editable settings layers and produce a
* preview plus a PENDING approval record. Nothing is stored until someone confirms that record and the
* batch is redeemed. A preview with zero importable candidates returns NO `approvalId` — there is nothing
* to confirm, and the absence says so (design/375 §4.1).
*
* Every list is read through the ONE validator under its own behavior: a deny/ask entry takes the
* tightening floor (`Bash(node:*)` as a deny is a legitimately wide tightening and imports), an allow
* entry the allow floor. A content-form deny/ask so imported is the person's own standing instruction
* and adjudicates in the persisted-rule lane beside their allows — deny > ask > allow — instead of
* being escorted by a shell into a bare tool-name ask that widens `Bash(rm -r:*)` into "every Bash call
* asks". An entry that does not import (a spelling with no rule form, a tool the lane does not speak
* for, a non-string) is DISCLOSED in `skipped` with its reason and stays in the settings file.
*/
export declare function prepareCcImport(opts: {
layers: CcImportLayer[];
principal?: string;
owner?: RuleOwner;
deps: RuleConsentDeps;
}): Promise<{
preview: ImportPreview;
approvalId?: string;
}>;
/**
* The factory-reviewed starter set, offered when there is nothing to import.
*
* Every entry is an EXACT read-only command whose behavior does not depend on repository or environment
* configuration. The version-control family is deliberately absent: repository configuration can make a
* subcommand invoke an external helper, which is the same reason this repository already declined a
* subcommand allowlist for it. Nothing here takes effect until someone confirms the batch.
*/
export declare const STARTER_RULES: readonly string[];
/** Prepare the starter batch as a pending approval record. Nothing takes effect without confirmation;
* an unconfirmed deployment simply starts with an empty rule set. */
export declare function prepareStarterBatch(opts: {
principal?: string;
owner?: RuleOwner;
deps: RuleConsentDeps;
}): Promise<{
preview: RuleCandidate[];
approvalId: string;
}>;
/**
* Redeem the CHOSEN offer of a confirmed record, member by member — reporting what actually landed
* rather than what was previewed (dedup, concurrency and redemption-time validation can all move a
* member between the two moments).
*
* design/375 §4.1/§4.6 — this is the one-yes walk for every record kind: an import/starter record's
* whole-list batch, a card's chosen batch (each per-segment rule lands as its own candidate), or a
* card's chosen single (a one-member walk). Members OUTSIDE the chosen offer are simply not walked
* — and stay individually unredeemable through the ticket entry, same guarantee, one predicate.
*
* The walk contract, spelled out because each clause is load-bearing:
* · every member goes through the SAME single-ticket redemption leg — dot CAS'd into the record
* BEFORE the store write (a crash in between leaves a replayable intent), concurrent-loser
* dot reuse included; the walk adds no concurrency primitive of its own;
* · a refused member does NOT fold the batch: "all or nothing" is the CONFIRMATION's semantics
* (one yes covered the whole offer), not the landing's transaction shape — the walk continues
* and the member's row says refused, with the reason;
* · resuming a partial walk IS re-walking: already-landed members answer `alreadyRedeemed: true`
* and reuse their recorded dots (two concurrent walkers converge on one dot set, zero double
* mints), unlanded members mint on;
* · the returned table is COMPLETE — exactly one row per member of the chosen offer, in the
* offer's member order, no extras — so a caller's aggregate is an honest projection: all rows
* landed (`persisted` or `deduped`, both count as the consent being in effect) is full
* success, and ANY refused row must project to a non-success aggregate, never to a silent
* partial one.
*/
export declare function redeemRuleBatch(opts: {
approvalId: string;
principal?: string;
owner?: RuleOwner;
deps: RuleConsentDeps;
}): Promise<{
members: readonly RedeemedBatchMember[];
rev: number;
} | {
status: "refused";
reason: string;
}>;