@wrongstack/core 0.297.0 → 0.298.1

package/dist/plugins/auto-review-plugin.d.ts

@@ -90,17 +90,7 @@ export interface ParsedSeverities {
     high: number;
     medium: number;
 }
-/**
- * Extract Critical/High/Medium finding counts from a Chimera review report.
- *
- * The report format (from llm/chimera-review.md) uses section headers like
- * `### Critical (2)`, `### High (1)`, `### Medium (3)`. We match the count
- * in parentheses. Falls back to counting `1.`, `2.` list-item markers under
- * a severity heading when no `(N)` is present (defensive — the prompt asks
- * for both, but LLMs sometimes omit the count).
- *
- * Returns all-zero when the text doesn't match (clean report or unparseable).
- */
+/** Parse report counts for clean-vs-actionable classification. */
 export declare function parseReviewSeverity(text: string): ParsedSeverities;
 /**
  * Decide which follow-up cascade agents to spawn based on the review text.

package/dist/plugins/review-store-maintenance.d.ts

@@ -0,0 +1,26 @@
+/** Start maintenance before full-file JSONL reads become a meaningful heap spike. */
+export declare const REVIEW_STORE_COMPACTION_THRESHOLD_BYTES: number;
+/** Avoid repeatedly rewriting a large store that has no expired terminal records. */
+export declare const REVIEW_STORE_COMPACTION_INTERVAL_MS: number;
+export declare const REVIEW_STORE_MAINTENANCE_FILE = ".review-store-maintenance.json";
+export interface ReviewStoreMaintenanceResult {
+    compacted: boolean;
+    totalBytes: number;
+    reason: 'below_threshold' | 'interval' | 'compacted';
+    removedReports: number;
+    removedFindings: number;
+    eventsFolded: number;
+}
+export interface ReviewStoreMaintenanceOptions {
+    thresholdBytes?: number | undefined;
+    intervalMs?: number | undefined;
+    now?: number | undefined;
+}
+/**
+ * Compact the two Chimera JSONL stores only after they are large enough and
+ * no more than once per interval. The maintenance lock coordinates multiple
+ * CLI/WebUI processes; each store also takes its own mutation lock while it
+ * performs the atomic replacement.
+ */
+export declare function maybeCompactReviewStores(projectDir: string, opts?: ReviewStoreMaintenanceOptions): Promise<ReviewStoreMaintenanceResult>;
+//# sourceMappingURL=review-store-maintenance.d.ts.map

package/dist/plugins/review-types.d.ts

@@ -125,6 +125,12 @@ export interface ChimeraReviewCompletePayload {
     reviewText: string;
     status: string;
     cwd: string;
+    /**
+     * Stable report identifier allocated by the execution owner before the
+     * completion event is published. This keeps the durable report, parsed
+     * findings, mailbox follow-up, and any cascade consumers on one identity.
+     */
+    reportId?: string | undefined;
     /**
      * Active session ID at review-complete time. Set by execution.ts when
      * emitting the event. Consumed by finding/report integration to stamp

package/dist/security/auto-approve-policy.d.ts

@@ -0,0 +1,37 @@
+/**
+ * Auto-approving PermissionPolicy used for subagents. Subagents run
+ * non-interactively under a director — they cannot answer permission
+ * prompts, so a non-YOLO policy on the leader would silently hang the
+ * delegated run on the first sensitive tool call. The user already
+ * authorized the delegation when they invoked the leader; subagents
+ * inherit that authorization automatically.
+ *
+ * Tool defaults of `permission: 'deny'` are still honored (this is a
+ * subagent capability override, not a deny-bypass).
+ *
+ * 2026-06+: Primary decision is now based on declared `Tool.capabilities`
+ * (capability allowlist / denylist model). The legacy name-based DENY set
+ * is kept only for backward compatibility with tools that have not yet
+ * declared capabilities.
+ *
+ * 2026-06-13+: Switched to allowlist-by-default. Only tools with explicitly
+ * allowed capabilities are auto-approved. Everything else is denied.
+ * Default allowed: fs.read, net.outbound (read-only, safe operations).
+ *
+ * Extracted from permission-policy.ts.
+ */
+import type { PermissionDecision, PermissionPolicy, PermissionTrace } from '../types/permission.js';
+import type { Tool } from '../types/tool.js';
+export declare class AutoApprovePermissionPolicy implements PermissionPolicy {
+    private readonly allowedCapabilities;
+    constructor(allowedCapabilities?: readonly string[]);
+    private static isMcpTool;
+    evaluate(tool: Tool): Promise<PermissionDecision>;
+    trust(): Promise<void>;
+    deny(): Promise<void>;
+    denyOnce(): void;
+    allowOnce(): void;
+    explain(tool: Tool): Promise<PermissionTrace>;
+    reload(): Promise<void>;
+}
+//# sourceMappingURL=auto-approve-policy.d.ts.map

package/dist/security/capabilities.d.ts

@@ -12,7 +12,26 @@
 export declare const ToolCapabilities: {
     /** Can execute arbitrary commands in the user's shell (the `bash` tool). */
     readonly SHELL_ARBITRARY: 'shell.arbitrary';
-    /** Can execute a restricted set of commands (the `exec` tool). */
+    /**
+     * Can execute the `exec` tool's allowlisted commands.
+     *
+     * "Restricted" describes the command NAME check, not the resulting power.
+     * Treat this as equivalent to {@link SHELL_ARBITRARY} when deciding what to
+     * grant: the allowlist includes general-purpose interpreters (`node`,
+     * `python`, `perl`, `ruby`) and, on Windows, the platform shells (`cmd`,
+     * `powershell`, `pwsh`) — deliberately, since without them `exec` cannot run
+     * `dir`/`type`/any cmdlet. `node -e …` or `cmd /c …` therefore reaches
+     * arbitrary execution, and per-argument denylisting cannot close that while
+     * the shells remain (blocking `node -e` still leaves `cmd /c node -e`).
+     *
+     * What actually bounds this is downstream, not the name check: the permission
+     * policy reconstructs the full command line and runs it through the
+     * destructive classifier, so destructive calls still require confirmation.
+     *
+     * Granting `shell.restricted` while withholding `shell.arbitrary` therefore
+     * buys no meaningful reduction in blast radius. Documented rather than
+     * silently implied, because the two read as a narrow/wide pair (WS-083).
+     */
     readonly SHELL_RESTRICTED: 'shell.restricted';
     /** Can run a restricted project formatter/linter-style command. */
     readonly SHELL_EXEC: 'shell.exec';
@@ -83,6 +102,31 @@ export declare const DANGEROUS_FOR_SUBAGENTS: readonly ToolCapability[];
  *   - `config.mutate` — rewriting trust/config is privilege escalation, not work.
  */
 export declare const WIDE_SUBAGENT_CAPABILITIES: readonly ToolCapability[];
+/**
+ * Clamp a requested capability grant to a ceiling.
+ *
+ * The per-spawn `allowedCapabilities` grant documented above is an escape hatch
+ * for a TRUSTED caller — the user, or in-process code the user invoked. It was
+ * also reachable from two untrusted sources, which could therefore hand a
+ * subagent the capabilities the list above deliberately withholds:
+ *
+ *   1. `<projectRoot>/.wrongstack/agents/<role>/config.json`, a repo-committed
+ *      file that `applyProjectAgentConfig` merged in. Note this sits beside
+ *      `.wrongstack/config.json`, which IS strip-listed by in-project-policy —
+ *      the denylist guarded one file while the dangerous one lay next to it.
+ *   2. Model output, via the un-enum'd `allowedCapabilities` array on the
+ *      kanban/director tool schemas.
+ *
+ * Untrusted input may NARROW a grant; it may never widen one. Returns the
+ * intersection, preserving `ceiling` order for stable output.
+ *
+ * @returns the clamped list plus the capabilities that were dropped, so callers
+ *   can surface the reduction instead of silently disagreeing with the config.
+ */
+export declare function clampSubagentCapabilities(requested: readonly string[], ceiling?: readonly ToolCapability[]): {
+    granted: string[];
+    dropped: string[];
+};
 /**
  * Check if a tool (or its capabilities array) includes any dangerous capability
  * for subagent execution.

package/dist/security/error-sanitize.d.ts

@@ -0,0 +1,49 @@
+/**
+ * Error text that crosses a process boundary — into an HTTP JSON body, a
+ * WebSocket frame, a transcript row — is attacker-observable output, not a
+ * developer log line.
+ *
+ * WS-066: the HQ server had a `sanitizeApiError` for exactly this and the
+ * WebUI/SimpleUI servers did not, so the same class of error reached the
+ * browser opaque on one surface and verbatim on the other. This module is the
+ * single implementation both now use.
+ *
+ * Two levels, because the two surfaces have genuinely different needs:
+ *
+ *  - {@link sanitizeApiError} — opaque category only. For HTTP `/api/*` JSON
+ *    bodies, which are same-origin reachable and the least authenticated
+ *    surface. The detail stays server-side in the caller's log.
+ *  - {@link scrubErrorDetail} — keeps the message (a local dev tool is much
+ *    less useful without it) but strips embedded credentials and rewrites
+ *    home-directory paths to `~`. For WebSocket payloads, which are token and
+ *    Origin gated.
+ *
+ * @module security/error-sanitize
+ */
+/** Longest error detail forwarded to a client; longer text is truncated. */
+export declare const ERROR_DETAIL_MAX = 500;
+/**
+ * Coerce a thrown value into a safe, opaque message for HTTP/JSON API
+ * responses. Raw error strings (file paths, environment details, stack
+ * fragments) are never forwarded to the browser — only a stable category.
+ * The original error is logged server-side by the caller.
+ */
+export declare function sanitizeApiError(err: unknown): string;
+/**
+ * Keep an error message readable but remove what must never leave the host:
+ * credentials the message quotes back (a provider echoing an `Authorization`
+ * header, a connection string with an inline password) and the absolute home
+ * directory, which leaks the OS account name.
+ *
+ * Use this where the detail has real diagnostic value and the channel is
+ * authenticated; use {@link sanitizeApiError} otherwise.
+ */
+export declare function scrubErrorDetail(err: unknown): string;
+/**
+ * {@link scrubErrorDetail} for text that is already a string, and WITHOUT the
+ * length cap — callers that maintain their own truncation contract (the
+ * provider error body keeps 2 KB plus a `truncated`/`rawLength` pair) must not
+ * have a second, silent cut applied underneath them.
+ */
+export declare function scrubErrorText(text: string): string;
+//# sourceMappingURL=error-sanitize.d.ts.map

package/dist/security/file-permissions.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Owner-only file hardening, on both POSIX and Windows.
+ *
+ * WS-045: this lived as a private function inside `secret-vault.ts` and was
+ * therefore reachable only by the config file. Every other secret WrongStack
+ * writes — the HQ `auth.json` (bearer tokens), `runtime.json` (local client
+ * token), the vault `.key` — got `chmod(0o600)` at best, which on Windows is
+ * a no-op for everything except the read-only bit: the file stayed readable by
+ * every other account on the machine. One exported module so a new secret file
+ * has an obvious thing to call.
+ *
+ * @module security/file-permissions
+ */
+/** Owner read/write, nothing for group or other. */
+export declare const SECRET_FILE_MODE = 384;
+/** Owner-only directory: enter + list + write. */
+export declare const SECRET_DIR_MODE = 448;
+export interface RestrictPermissionsOptions {
+    warn?: ((msg: string) => void) | undefined;
+    /** Label used in warnings, e.g. `secret-vault` or `hq-auth`. */
+    label?: string | undefined;
+}
+/**
+ * Restrict a file to owner-only access.
+ *
+ * POSIX: `chmod 0600`. Windows: `chmod` cannot express this, so we use
+ * `icacls` to drop inherited ACEs and grant the current user alone.
+ *
+ * Failures are warned, never thrown — a hardening step must not be able to
+ * block the write it protects, and `icacls` is absent in some minimal
+ * environments (containers, WINE, restricted CI images).
+ */
+export declare function restrictFilePermissions(filePath: string, opts?: RestrictPermissionsOptions): Promise<void>;
+/**
+ * `restrictFilePermissions` for a directory: `chmod 0700` on POSIX, the same
+ * icacls treatment (applied recursively to new children via inheritance) on
+ * Windows. Use on the directory that holds secret files so a file created
+ * there by a path we do not control still lands owner-only.
+ */
+export declare function restrictDirPermissions(dirPath: string, opts?: RestrictPermissionsOptions): Promise<void>;
+//# sourceMappingURL=file-permissions.d.ts.map

package/dist/security/index.d.ts

@@ -1,13 +1,16 @@
-export { DANGEROUS_FOR_SUBAGENTS, getDangerousCapabilities, hasCapability, hasDangerousCapabilityForSubagents, ToolCapabilities, type ToolCapability, WIDE_SUBAGENT_CAPABILITIES, } from './capabilities.js';
+export { noOpVault } from '../types/secret-vault.js';
+export { clampSubagentCapabilities, DANGEROUS_FOR_SUBAGENTS, getDangerousCapabilities, hasCapability, hasDangerousCapabilityForSubagents, ToolCapabilities, type ToolCapability, WIDE_SUBAGENT_CAPABILITIES, } from './capabilities.js';
 export { decryptConfigSecrets, encryptConfigSecrets, isSecretField } from './config-secrets.js';
+export { DirectoryPermissionPolicy, type DirectoryPermissionPolicyOptions, matchRule, resolveTargetPath, } from './directory-permission-policy.js';
+export { DIRECTORY_POLICY_LIMITS, DIRECTORY_POLICY_SCHEMA_VERSION, type DirectoryPolicyDiagnostic, type DirectoryPolicyDiagnosticCode, type DirectoryPolicyValidationResult, validateDirectoryPolicy, } from './directory-policy-schema.js';
+export { ERROR_DETAIL_MAX, sanitizeApiError, scrubErrorDetail, scrubErrorText, } from './error-sanitize.js';
+export { restrictDirPermissions, restrictFilePermissions, SECRET_DIR_MODE, SECRET_FILE_MODE, } from './file-permissions.js';
 export { evaluateToolKanbanBoundary, type ToolKanbanBoundaryEvaluation, } from './kanban-boundary.js';
-export { AutoApprovePermissionPolicy, DefaultPermissionPolicy, type PermissionPolicyOptions, } from './permission-policy.js';
+export { AutoApprovePermissionPolicy, alwaysAllowUnavailableReason, DefaultPermissionPolicy, type PermissionPolicyOptions, } from './permission-policy.js';
 export { TRUST_POLICY_JSON_SCHEMA, TRUST_POLICY_LIMITS, TRUST_POLICY_SCHEMA_VERSION, type TrustPolicyDiagnostic, type TrustPolicyDiagnosticCode, type TrustPolicyValidationResult, validateTrustPolicy, } from './permission-policy-schema.js';
+export { ReadOnlyPermissionPolicy } from './readonly-permission-policy.js';
 export { DefaultSecretScrubber } from './secret-scrubber.js';
-export { noOpVault } from '../types/secret-vault.js';
-export { ReadOnlyPermissionPolicy, } from './readonly-permission-policy.js';
-export { DirectoryPermissionPolicy, matchRule, resolveTargetPath, type DirectoryPermissionPolicyOptions, } from './directory-permission-policy.js';
-export { DIRECTORY_POLICY_LIMITS, DIRECTORY_POLICY_SCHEMA_VERSION, type DirectoryPolicyDiagnostic, type DirectoryPolicyDiagnosticCode, type DirectoryPolicyValidationResult, validateDirectoryPolicy, } from './directory-policy-schema.js';
+export { base32Decode, base32Encode, buildOtpAuthUri, generateRecoveryCodes, generateTotpSecret, generateTotp, hashRecoveryCode, verifyRecoveryCode, verifyTotp, } from './totp.js';
 export { DefaultSecretVault, migratePlaintextSecrets, rewriteConfigEncrypted, rotateConfigKeys, type SecretVaultOptions, } from './secret-vault.js';
 export type { CompatibilityTrustBoundaryOptions, TrustActor, TrustActorKind, TrustAllowDecision, TrustAttribute, TrustAuthContext, TrustAuthMethod, TrustBoundary, TrustBoundaryAuditEntry, TrustBoundaryDecision, TrustBoundaryRequest, TrustConfirmDecision, TrustDecodeIssue, TrustDecodeResult, TrustDenyDecision, TrustRisk, TrustScope, TrustScopedTokenDecision, TrustSubject, TrustSurface, } from './trust-boundary.js';
 export { createCompatibilityTrustBoundary, decodeTrustBoundaryDecision, decodeTrustBoundaryRequest, isTrustDecisionAllowed, TRUST_BOUNDARY_VERSION, } from './trust-boundary.js';