Relax strictness that costs more than it protects

[martyn]

Relaxes the strictness that costs more than it protects. The safety property is unchanged: config source is never compiled or executed. It goes through an AST allowlist, calls can only name registered operators with literal or tensor arguments, and there are no imports or attribute access. Every node of the AST is still validated before any registry lookup.

1. Config parsing moves in process

What it was. Every resolve() / resolve_file() started python -I -S _parser_worker.py under rlimits (256 MiB address space, 2 s CPU, a 5 s wall-clock timeout) and exchanged a bounded JSON protocol. On top of that it had eight parser limits (source bytes, lines, AST nodes, depth, literal items and bytes, integer bits, initializer kwargs), protocol limits, and a second validator that re-checked the worker's JSON response. It only ran on Linux.

What it protected. Two things. The worker kept the AST allowlist separate from any code execution, and it protected the host process from pathological source that exhausts the parser.

Why it's safe to relax. ast.parse produces data and executes nothing, so it doesn't need a separate process to keep the allowlist separate from execution. The allowlist itself is unchanged (src/hndl/_parser.py, moved from the worker). The resource risk is real, though, and I measured it rather than assuming it away:

• At the 64 KiB source cap in the main thread, CPython 3.11–3.14 turn runaway nesting into SyntaxError, MemoryError or RecursionError within about 130 ms and 55 MiB. 3.14 also builds trees 32,000 levels deep for relu()()()... and 1+1+....
• On a small thread stack (512 KiB), CPython 3.11, 3.12 and 3.13 crash with SIGSEGV on -----1, not not ..., lambda: lambda: ..., ternary chains, and on 3.12/3.13 also on call, attribute, subscript and binary-operator chains. 3.14 does not crash. An exception handler can't catch this, so a plain in-process ast.parse would have been a regression.

So before ast.parse sees the source, _screen walks the token stream. The tokenizer is iterative, so this walk can't overflow the stack. It fails more than 50 levels of bracket nesting with E_RESOURCE, and more than 32 Python operators or keywords with E_SYNTAX. Valid configs contain none of those operators or keywords, and signs on numeric literals and calls on names aren't counted. Every other level of AST nesting costs one of those tokens. An iterative AST depth walk (150 levels) remains as a backstop for the recursive validator. With the screen, 29 adversarial sources at the size cap (plus 3 large valid configs) parse or fail with HNDLError in a 256 KiB thread on 3.11, 3.12, 3.13 and 3.14. That set includes chains of every nesting construct, 49-deep brackets combined with 32 operators, decorators, match patterns, and indentation. test_pathological_nesting_fails_cleanly_on_a_small_thread_stack runs a set of these inputs in a 256 KiB thread in a child process. I checked that the test fails, with SIGSEGV, on 3.11–3.13 when the screen is disabled.

These limits are dropped because the source cap and the operators' argument schemas already bound the values: MAX_LINES, MAX_AST_NODES, MAX_LITERAL_ITEMS, MAX_LITERAL_BYTES, MAX_INTEGER_BITS (an oversized int still fails with E_RESOURCE from the argument bound), MAX_INITIALIZER_KWARGS, the protocol limits and response validation, the Linux requirement and the explicit version gate (requires-python already has one). The initializer-scheme allowlist now comes from hndl.settings.SCHEME_NAMES. The worker kept its own copy because it couldn't import the package.

Measured (min of 20 runs, Python 3.14, _parse only):

source	before (worker)	after (in process)
linear(64)\nrelu()\nlinear()	31.8 ms	0.06 ms
200 statements	33.1 ms	3.6 ms
concat of 4,000 inputs	71.3 ms	20.7 ms

Full suite (-m "not network and not benchmark", same machine, sequential runs): 3552 passed in 154.6 s on develop, 3569 passed in 35.9 s on this branch.

Where statement handling lives (for the for-loop PR). Each side has one dispatch table: Validator.STATEMENTS in src/hndl/_parser.py ({ast.Expr: expr_statement, ast.Assign: assign_statement}, and Validator.statements(body) handles a nested body), and _Interpreter.STATEMENTS in src/hndl/config.py ({"expr": ..., "assign": ...}, and _Interpreter.run(statements) handles a nested body). Adding for _ in range(N): takes one handler on each side, plus adding for and in to _ACCEPTED_KEYWORDS in _parser.py so the screen doesn't count them. Once loops unroll, max_nodes becomes the only bound on graph size.

Timing test. test_many_concat_edges_stay_within_a_bounded_resolution_time raced a 5 s subprocess timeout and was flaky under load. It now counts _Solver.set_shape calls instead: 6n+9 for n = 4,000 edges, against a bound of 100n, where a pairwise comparison would need about n² = 16M. The check is deterministic and runs in process.

2. Plan loading: readable diffs, and filling values the plan already determines

What it was. validate_concrete_plan re-resolves the saved arguments as explicit values and compared semantic digests. On any difference it refused with one line: E_INTEGRITY: Saved concrete arguments and port shapes are inconsistent; no inferred replacement is accepted.

What it protected. Re-resolution only sees the saved args and the external contracts. So a digest difference means one of these:

• (a) A saved internal port shape doesn't satisfy the equations. This is corruption or forgery, and construction reads these shapes.
• (b) The equations change a saved argument value, for example through finalize.
• (c) The saved plan lacks an argument, which is then filled by an operator default, by a dimension symbol, or by a policy or relation search.

Accepting (a) or (b), or (c) when a search fills the argument, could silently change the network a checkpoint was trained with. A policy or relation search can produce the same output shapes with different padding or kernels.

Why it's safe to relax. Only case (c) is relaxed, and only for the two ways the saved plan fully determines the value:

• An operator default. This is a plan written before the operator gained the argument, like pretrained plans from before layers=, and any argument added without since=. The SPEC already requires a version bump when a default changes meaning.
• An Arg(dim=...) argument. Its value is read off a saved port shape, and that shape is itself verified against the equations.

In those cases the plan loads completed. Saved source and provenance are kept. A UserWarning names each filled value and gives the old and new semantic digest, so anyone who keys checkpoints by digest can see the change. Every other difference is refused as before, but E_INTEGRITY now lists each mismatch, for example:

E_INTEGRITY: Saved plan does not satisfy its operators' equations:
  node hidden: output out is saved as [B, 5] but the equations give [B, 4]
Re-resolve it from its source with this release.

A missing policy- or relation-chosen argument gives, for example, node n0: in_channels is missing and would be chosen again as 3 (inferred); a saved plan never re-runs that choice. This builds on #81 rather than redoing it: an Arg(since=...) default that a saved plan still spells out explicitly is reported as "dropped" and accepted.

Digests. Both digests are still checked. The error now says what they detect: Saved plan is corrupted or was edited by hand: its artifact_digest does not match its contents. Restore the file, or re-resolve the plan from its source; to change a plan, edit it in Python and save it with to_json().

3. Resource limits

What it was. DEFAULT_LIMITS has six keys and is plumbed through every entry point as limits=. ResolvedPlan.from_json also had a 16 MiB input cap and its own max_nodes pre-check, and Capture had a hard-coded copy of the 4,096 max_nodes default with its own validation.

Decisions.

• limits= stays. It is public API documented in SPEC §5 and §7 for every entry point, and the tests use it. HyperGAN does not pass it (checked every .py under ~/dev/hypergan). Removing the keyword from about a dozen signatures would break callers and remove no real complexity.
• max_state_bytes default goes from 1 GiB to 64 GiB. Evidence: embedding(50257, 1024) + 24 × transformer_block(16, causal=True) + linear(50257) has 405M parameters (1.6 GB), and build() refused it by default with E_RESOURCE: Plan exceeds max_state_bytes before allocation. pretrained nodes count toward the same bound, so a wrapped ViT-L hit it too. 64 GiB still catches a typo that asks for terabytes before anything is allocated.
• Kept, because each stops a real failure: max_iterations (a relation that never settles), max_dimension / max_elements (huge-dimension typos), max_nodes (the only bound on graph size once loops unroll), and max_edges (it stops concat(input_count=2**31-1) from materializing ports, see test_huge_concat_input_count_rejected_before_materializing_ports).
• Removed: from_json's 16 MiB cap and its duplicate max_nodes check (revalidation still applies max_nodes and every shape bound). Capture now reads max_nodes from _limits(limits), so there is one default and one validation.

4. Other candidates, listed here and not changed

• validate_concrete_plan fully re-resolves on every build(), including plans the resolver just produced in the same process. A plan from resolve() is resolved twice. This could be skipped for plans the resolver produced in process. I left it alone because it is in the build path near perf/check-once.
• max_edges exists mostly to cap a variadic input_count. An Arg(max=...) on input_count would express that directly.
• Declaration-time caps on trusted code: MAX_PORTS, MAX_ARGUMENTS, MAX_SYMBOLS, MAX_NAME_LENGTH (operator.py), provider name length (registry.py), and MAX_OVERRIDES / MAX_PARAMETER_PATH (settings.py, which raise E_RESOURCE on init= / trainable= maps).
• resolve_graph rejects a frontend string longer than 256 characters. _contract repeats the max_dimension / max_elements checks that _Solver.set_shape does anyway.
• from_json requires the exact field set, so any new optional field needs a schema bump.
• There are about 20 E_* codes. E_OUTPUT / E_OUTPUT_ARITY / E_CURRENT could merge, and E_RESOURCE vs E_SCHEMA for bad contracts is a judgement call.
• The README still says "Install on Linux". Parsing no longer needs Linux, but the platform matrix isn't qualified yet.

Tests changed because they asserted strictness removed on purpose

• tests/test_config.py: dropped the "\n" * 4096 → E_RESOURCE assertion (line limit removed). Removed test_linux_isolation_and_no_unbounded_fallback, test_worker_invocation_is_isolated_for_strings_and_output_is_checked and test_timeout_and_worker_failure_are_explicit (worker removed). Added test_parsing_runs_in_process_on_any_platform, the pathological-nesting tests (in process and in a 256 KiB thread) and test_valid_configs_are_not_limited_by_the_nesting_screen.
• tests/test_examples.py: the timing test now counts solver work (see above).
• tests/test_plans.py: replaced test_persisted_omission_cannot_be_silently_reinferred with test_missing_arguments_the_plan_determines_are_filled_with_a_warning and test_missing_arguments_only_a_search_would_choose_are_refused_with_a_diff. The forged-shape test now also asserts the diff line.
• tests/test_pretrained_provider.py: test_a_plan_saved_before_layers_existed_has_to_be_re_resolved is now ..._loads_completed, which also builds the completed plan.

Checks

• PYTHONPATH=src python -m pytest -q -m "not network and not benchmark": 3569 passed, 80 skipped, 53 deselected (35.9 s)
• ruff check src tests examples: clean
• PYTHONPATH=src python -m hndl.docs --check: current
• Parser screen: pathological set run standalone on CPython 3.11.15, 3.12.13, 3.13.15 and 3.14.7 in 256 KiB threads, with no crashes.

🤖 Generated with Claude Code

[martyn]

CI note: the first two runs of test (3.14) failed in tests/operators/test_attention.py::test_deepcopy_preserves_behavior_and_shares_no_state, which this PR doesn't touch. On the third run it passed with no changes. That test adds 1.0 to the whole relative-position bias table. Softmax ignores a constant added to every logit, so the outputs differ only by rounding, and assert not torch.allclose(...) lands on either side of the tolerance depending on the CPU kernels. With the module fixed and varying only x, 122 of 200 seeds give allclose=True, which fails the test. Suggested follow-up: perturb one table entry instead of all of them.

🤖 Generated with Claude Code