[Low priority] Make all PR #609 resource-budget policies overrideable through .wflcfg

[logbie]

Summary

Follow-up to PR #609.

PR #609 intentionally ships conservative, safe defaults for execution budgets, stack safety, parsing/analysis checkpoints, pattern execution, source loading, HTTP admission/body/response handling, and WebSocket capacity. Keep those defaults, but make every user-relevant limit or policy introduced or consolidated by the PR overrideable through a project .wflcfg when an operator has a legitimate need to raise or lower it.

This is low priority for now. The current defaults should remain unchanged and safe.

Scope

Audit the complete PR #609 surface, including all later remediation commits and issue #611, and classify every constant/default as one of:

1. Public operational policy — must have a documented .wflcfg override.
2. Internal sampling/implementation detail — should remain private unless a real operational use case justifies exposing it.
3. Safety invariant — may be configurable only with validation, warnings, or an explicit unsafe/advanced opt-in.

At minimum, verify configurability and consistent propagation for:

• overall execution timeout and cooperative cancellation behavior;
• maximum interpreter operations;
• call/recursion depth, including the conservative direct-embedding default;
• import/include and execute file depth;
• maximum source size for CLI, REPL, modules, includes, and nested execution;
• pattern transition/step and active-state ceilings;
• HTTP request-body and response-body limits;
• HTTP pending/in-flight admission and bounded request queue capacity;
• HTTP body/handler response timeout;
• WebSocket queue, queued-byte, and connection ceilings;
• interpreter stack sizing / stack-safety policy where it is controlled by WFL;
• any other user-visible resource ceiling added or centralized by PR feat: add shared ExecutionBudget consolidating runtime resource caps #609.

Also audit constructors and entry points. A value loaded from .wflcfg should reach the CLI, REPL, nested interpreters, modules/includes, pattern VM, HTTP/WebSocket transports, and supported embedding runners without silently falling back to a different hard-coded value.

Important distinction

Do not automatically expose hot-loop implementation constants such as lexer checkpoint stride or cooperative-yield sampling stride merely because they are constants. Expose them only if users need them to control observable behavior. Deadline/cancellation correctness must not depend on making sampling internals configurable.

Proposed behavior

• Existing values remain the defaults.
• Local/project .wflcfg overrides global configuration following the existing precedence rules.
• Invalid, zero, overflowing, or dangerous values receive clear validation errors or documented sentinel behavior.
• Safety-sensitive overrides have documented consequences. For example, a high recursion limit without an adequate interpreter stack must not quietly reintroduce native stack overflow risk.
• Config-taking library APIs continue to honor explicit caller configuration; define clearly how filesystem .wflcfg applies to embedding APIs such as Interpreter::new().
• Configuration checker/fixer, reference docs, examples, and generated/default config are updated together.

Acceptance criteria

• Inventory every resource limit and user-visible policy introduced or changed by PR feat: add shared ExecutionBudget consolidating runtime resource caps #609.
• Each public operational setting has a documented .wflcfg key and default.
• All execution entry points consistently receive the resolved values.
• Configuration precedence and embedding behavior are explicitly documented.
• Dangerous combinations are rejected or produce actionable warnings.
• Config checker/fixer recognizes every new key.
• Tests cover default behavior, overrides, invalid values, precedence, and propagation into nested/runtime transport paths.
• No current safe default is weakened.

Related

• PR feat: add shared ExecutionBudget consolidating runtime resource caps #609
• Issue PR #609 final residuals: budget propagation, HTTP lease cleanup, Unicode patterns, and safe embedding #611
• Production-readiness tracking issue WFL Production Readiness: 8/10 by January 1, 2027 #610

[logbie]

Assessment: valid enhancement, but most of it has already shipped — the residual is much smaller than the checklist suggests. Verified against main (df56454, v26.7.37).

I walked the "at minimum" list against src/config.rs, ExecutionBudget::from_config (src/exec/budget.rs:184), and the .wflcfg key checker (src/wfl_config/checker.rs). Every user-relevant limit on that list is already a documented .wflcfg key today, loaded, mapped onto the budget, and known to the checker (so it doesn't warn unknown_setting):

Requested override	.wflcfg key	Status
Execution timeout	timeout_seconds	✅ mapped → max_duration
Max interpreter operations	max_operations	✅
Call/recursion depth	max_call_depth	✅
Import/include depth	max_import_depth	✅
execute file depth	max_execute_file_depth	✅
Max source size	max_source_size	✅
Pattern steps / states	max_pattern_steps, max_pattern_states	✅
HTTP request body	web_server_max_body_size	✅
HTTP response body	web_server_max_response_size	✅
HTTP pending/queue admission	web_server_request_queue_bound	✅
HTTP response timeout	web_server_response_timeout_seconds	✅ (0 disables)
WebSocket queue / bytes / connections / message size	web_socket_queue_bound, web_socket_max_queued_bytes, web_socket_max_connections, web_socket_max_message_size	✅

All are in Docs/reference/configuration-reference.md, and defaults are unchanged — so the "keep the safe defaults, add overrides" ask is essentially satisfied for the class-1 (public operational policy) items.

What actually remains — two things:

1. Interpreter stack sizing is not configurable. INTERPRETER_STACK_SIZE is a hard-coded 1 GiB at src/lib.rs:82, applied at src/lib.rs:125. This is the one item on your list with no .wflcfg path. It's squarely your class 3 (safety invariant): exposing it lets an operator configure a value that reintroduces stack-overflow SIGABRT, which max_call_depth exists to prevent. If exposed at all it needs a floor, validation, and a warning — and honestly max_call_depth may already give operators the knob they actually want, so I'd argue for deliberately leaving it private and closing that line item as "won't expose, documented rationale."

2. Cooperative-cancellation sampling (CLOCK_SAMPLE_STRIDE, src/exec/budget.rs:61, and the lexer checkpoint stride) — these are exactly the class-2 internals your "Important distinction" section says not to expose. Agreed; deadline correctness must not depend on them.

So the real work here is an audit + documentation pass, not a plumbing project: confirm propagation of the already-existing keys into the REPL, nested interpreters, and embedding runners (the one place a silent hard-coded fallback could still hide), then record the class-2/class-3 decisions so this doesn't get re-litigated. That's a fraction of the scope the issue currently implies, and it's consistent with the "low priority" label.

Suggested labels: enhancement, config, low-priority. Cross-ref: #609, #610 (Phase 1), #611.

Posted by the WFL repo warden (automated triage pass).