fullcourtdefense-cli 1.31.0 → 1.32.0

package/dist/actionPolicyEngine.d.ts

@@ -91,7 +91,51 @@ export interface EngineActionPolicy {
     resourceType?: string;
     rules: ActionPolicyRule[];
     enabled?: boolean;
+    /**
+     * Enforcement ceiling on a machine where a HUMAN is present (a developer
+     * workstation). `standard` (default): a `block` rule pauses the action and asks
+     * the developer in their IDE — a wrong Ask costs one click, a wrong block costs
+     * the customer. `hard`: the policy blocks outright even with a human present.
+     * Where no human is present (CI, workloads, SDK-embedded agents) every block is
+     * hard — an Ask nobody can answer must never silently allow.
+     */
+    enforcement?: ActionPolicyEnforcement;
 }
+export type ActionPolicyEnforcement = 'standard' | 'hard';
+/**
+ * The developer Ask a softened block becomes: IDE prompt, asked EVERY time (no
+ * session memory — a Block-level rule is exactly where a second, different
+ * action must not ride on the first yes), blocks on timeout.
+ */
+export declare const WORKSTATION_ASK_APPROVAL: ResolvedActionPolicyApproval;
+/**
+ * LOCAL CONTENT CEILING.
+ *
+ * Facts about what the arguments CONTAIN. A rule that needs one of these to
+ * fire is a rule about content, and content on this machine's own disk is not
+ * exfiltration: typing a key into `.env`, pasting a token into a test fixture,
+ * reading a config file that holds a password. Secret scanning on file content
+ * is inherently approximate (there is no finite list of what a fake key looks
+ * like), and the industry treats it as advisory for exactly that reason — a
+ * hard stop on EDITING is how a developer loses trust in the product after two
+ * wrong blocks. So: a `block` that fires on a content fact for a LOCAL FILE
+ * action is recorded as a warning (verdict `log`, `loggedInsteadOfBlocked`),
+ * never enforced. The same content leaving the machine — an external
+ * destination, a recipient, a shell command that sends it — is untouched by
+ * this ceiling and still blocks. A policy marked `enforcement: 'hard'` is also
+ * untouched: the admin confirmed it should stop without asking.
+ */
+export declare const CONTENT_FACT_FIELDS: ReadonlySet<string>;
+/** Does this rule need a content fact to fire? (A rule with no content constraint is about the ACTION, not the content.) */
+export declare function ruleNeedsContentFact(rule: Pick<ActionPolicyRule, 'constraints'>): boolean;
+/**
+ * Is this call a LOCAL FILE action — content touching this machine's disk with
+ * nothing leaving the machine? Requires a file path, no external destination,
+ * no recipient, and a file-shaped tool or operation. A shell command is never
+ * a local file action here (the command line may send data in ways the URL
+ * parser cannot see), so `echo $KEY | nc host 4444` keeps its verdict.
+ */
+export declare function isLocalFileContentAction(toolName: string, operation: string, context: Record<string, string>): boolean;
 /** A monitor-stage policy match: what WOULD have happened, recorded but not enforced. */
 export interface ActionPolicyMonitorMatch {
     policyId?: string;
@@ -113,6 +157,22 @@ export interface EngineCheckResult {
      * session > 1h, block > org) so one permissive rule can never loosen another.
      */
     approval?: ResolvedActionPolicyApproval;
+    /**
+     * The matched rule said `block`, but a human is present and the policy is not
+     * `enforcement: 'hard'`, so the action pauses and asks the developer instead
+     * (verdict is `require_approval` with WORKSTATION_ASK_APPROVAL). Surfaced so
+     * explanations can say "set to Block; asks you on a workstation; an admin can
+     * mark it Hard block".
+     */
+    askedInsteadOfBlocked?: boolean;
+    /**
+     * The matched rule said `block` because of what the arguments CONTAIN
+     * (`toolArgs.containsSecret` / `secretKind` / `containsPii`), but the action
+     * only touches a file on this machine's own disk and nothing leaves the
+     * machine — so it is recorded as a warning (verdict `log`) instead of
+     * stopping the developer. See LOCAL CONTENT CEILING below.
+     */
+    loggedInsteadOfBlocked?: boolean;
     /** Monitor-stage policies that matched (would-block / would-approve) without enforcing. */
     monitorMatches?: ActionPolicyMonitorMatch[];
     /** Org-scoped policies skipped because the call carried no developerName (for caller-side logging). */