Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@ROADMAP.md`:
- Line 70: Update the ROADMAP entries for the delivered features by replacing
the open-item lines for issues `#263` (and documented `#403`) with the required
strikethrough + release link format: wrap the entire list item text in HTML del
tags like <del>[`#263`](...) description</del> and append the release link in
parentheses as ([vX.Y.Z](release-url)); ensure the exact text and issue number
for both `#263` and `#403` are updated in this same commit/PR so the roadmap shows
them completed.

In `@scripts/check_skill_examples.py`:
- Around line 97-112: The allowlist in scripts/check_skill_examples.py has
line-number keys that no longer point at the intended fenced SKILL.md examples
(e.g., keys 989 -> try_div, 1111 -> run_counter, 1188 -> identity and CORRECT
entries at 1363/1386/1525/1540/1556/1571/1599), so update the numeric keys so
each tuple (e.g., entries for "FRAGMENT" at 884, 989, 1009, 1039, 1070, 1111,
1140, 1188 and the listed CORRECT examples) maps to the actual starting line of
the corresponding fenced block in the current file; locate the mismatches by
searching for the unique symbols try_div, run_counter, identity and the named
CORRECT examples in the SKILL.md/checked file and replace the stale keys with
the correct fence start line numbers so CI stale-detection resumes pointing at
the true examples.

In `@spec/12-runtime.md`:
- Line 438: Update Section 12.2.1 to reflect that the CLI now supports passing
String parameters (allocated in WASM linear memory and passed as (ptr, len)
pairs) and remove or revise the earlier statement that functions with
"String"/"Array<T>" in their signatures are skipped during compilation;
specifically, change the paragraph that says functions with String/Array<T> are
skipped so it either documents supported String handling or accurately describes
current compilation constraints, and ensure references to CLI examples like
`vera run file.vera --fn f -- 42 3.14` and the String/Byte parsing behavior are
consistent across the chapter.

In `@tests/test_cli.py`:
- Around line 935-953: The test test_run_bool_arg currently only checks
returncode but not the command output; update the test to also assert that the
CLI printed the boolean return from the identity function by checking
result.stdout (e.g., assert "true" in result.stdout.lower().strip() or an exact
match depending on CLI formatting) after running [sys.executable, "-m",
"vera.cli", "run", path, "--fn", "identity", "--", "true"]; this ensures the
identity function received and returned the boolean value as expected.

In `@vera/cli.py`:
- Around line 931-935: The code leaves raw_fn_args as None when args contains a
trailing "--" with no tokens, which skips arity/type validation in
execute(raw_args=...); update the block that handles "--" so that raw_fn_args is
assigned an explicit empty list (e.g., raw_fn_args = list(raw_args_list) or
raw_fn_args = []) even when raw_args_list is empty, ensuring
execute(raw_args=...) receives [] and triggers proper argument validation for
the target function.
- Around line 528-530: The call to execute() uses fn_name directly which causes
lookup in result.fn_param_types to use "" when --fn is omitted; before calling
execute(), compute the effective entrypoint (e.g., effective_fn = fn_name if set
else result.default_export or the first export name from result.exports) and
pass that effective_fn into execute (and any related raw_args/typed-args logic)
so result.fn_param_types.get(effective_fn, []) is used instead of "". Update the
invocation that currently calls execute(result, fn_name=fn_name, ...) to use the
resolved effective_fn variable.

In `@vera/codegen/api.py`:
- Around line 2117-2142: The loop that builds parsed args uses zip(raw_args,
vera_params) and should be hardened by passing strict=True to zip to ensure
lengths match at iteration time; update the zip call in the block handling
parsed = [] (the loop referencing raw, wasm_type and variables raw_args,
vera_params, parsed, _alloc_string_arg) to zip(raw_args, vera_params,
strict=True) so any future refactor that breaks the arity invariant is caught
immediately.
- Around line 2102-2115: Replace the inline asserts in _alloc_string_arg with
explicit validation and exceptions so error messages are always emitted (even
with Python -O); specifically check that memory_export is an instance of
wasmtime.Memory and alloc_export is an instance of wasmtime.Func and raise a
clear exception (e.g., RuntimeError or ValueError) with the same descriptive
messages before proceeding to encode s, call alloc_export(store, len(encoded)),
and write into memory_export.data_ptr(store); also validate that
alloc_export(store, len(encoded)) returns an int and raise if not.

In `@vera/codegen/core.py`:
- Around line 258-265: The code uses erased WASM-level types (via
_type_expr_to_wasm_type and self._fn_sigs) to decide CLI behavior (e.g., setting
_needs_alloc/_needs_memory and validating execute(raw_args=...)), but WASM tags
collapse Vera kinds (Nat/Int -> i64, Bool/Byte -> i32, String/Array -> i32_pair)
so CLI semantics cannot be enforced; update the compilation pipeline so
CompileResult carries Vera-level parameter kinds (the original type expressions
or a distinct fn_param_kinds vector) and change the usages in core.py (places
referencing self._fn_sigs, the allocation gate that sets
_needs_alloc/_needs_memory, and execute(raw_args=...)) to consult those Vera
kinds (or explicitly mark unsupported kinds) rather than the erased WASM types,
ensuring correct allocation/validation decisions.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@CHANGELOG.md`:
- Line 11: The markdown headings are missing a required blank line before them
(MD022); add a single blank line immediately above the "### Added" heading (and
similarly above the other heading flagged at line 15) so each heading is
separated from the previous content by one blank line to satisfy markdownlint.
- Line 12: Update the CHANGELOG entry so it accurately describes
CompileResult.fn_param_types as exposing erased WASM-level tags rather than
Vera-level kinds: replace the phrase "Vera-level param types" with wording that
fn_param_types contains WASM-level tags like `i64`, `f64`, `i32`, `i32_pair`
(per implementation in vera/codegen/core.py and vera/codegen/api.py and the
CompileResult data structure), and mention this is intentional to aid host
runtime interop for allocation/invocation.

In `@FAQ.md`:
- Line 212: Update the FAQ sentence that lists supported inference providers by
removing "Mistral" so it only mentions "Anthropic", "OpenAI", and "Moonshot";
locate the line referencing "<Inference> dispatches to Anthropic, OpenAI,
Moonshot, or Mistral via env vars" and change it to reflect only the
runtime-supported providers (anthropic, openai, moonshot) to avoid directing
users to an unsupported configuration.

In `@HISTORY.md`:
- Line 217: The HISTORY.md entry for v0.0.102 incorrectly claims “five semantic
metadata layers” while the changelog text lists four mechanisms; edit the
v0.0.102 paragraph to change the count and wording to “four semantic metadata
layers” (or rephrase to remove the numeric claim) so it matches the listed
items; locate the phrase "five semantic metadata layers" in the v0.0.102 entry
and update it and any adjacent wording mentioning "veralang.dev" or the four
mechanisms (`<link>` alternate/llms-txt, JSON-LD TechArticle entries, button
rel="agent-instructions", inline <script type="text/llms.txt">) for consistency.

In `@tests/test_cli.py`:
- Around line 2561-2573: Replace the weak assertion in test_string_arg_direct so
it checks the actual decoded string payload: after compiling with _compile and
calling execute(fn_name="greet", raw_args=["hello"]), read/decode the i32
pointer result returned in exec_result into a Python string (using the same
runtime/memory helper used elsewhere in tests or project) and assert it equals
"hello"; update the assertion that currently is "assert exec_result is not None"
to a concrete equality check against the decoded string to ensure the i32_pair
path writes the correct bytes.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@codecov.yml`:
- Around line 19-22: The Codecov config currently uses `target: auto` and
`informational: true`, which can make patch coverage non-blocking; confirm
whether `target: auto` is relying on the base commit comparison rather than
enforcing a fixed threshold and that `informational: true` disables failing the
status check, then harden the policy by replacing `target: auto` with an
explicit minimum like `target: 95%` (or add a separate project-level gate) and
set `informational: false` so patch coverage can fail CI if below the threshold;
update the `codecov.yml` entries for `target` and `informational` accordingly
and document the chosen threshold in the file comment.

In `@tests/test_cli.py`:
- Around line 2161-2171: The import of main from vera.cli is inside the with
pytest.raises(SystemExit) block in test_invalid_fn_args_inprocess, making it
ambiguous which statement raises; move the statement "from vera.cli import main"
outside the "with pytest.raises(SystemExit)" context so only the call "main()"
is inside that block (or alternatively add a Ruff PT012 suppression if keeping
the import inside is intentional). Ensure you update the test function
test_invalid_fn_args_inprocess accordingly so the import occurs before entering
the raises context.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@HISTORY.md`:
- Around line 241-250: Update the "Tests" metric in HISTORY.md's v0.0.102 column
to match TESTING.md by changing the value from 3,120 to 3,121 (locate the
"Tests" row in HISTORY.md and the v0.0.102 column entry and correct the number).

In `@tests/test_cli.py`:
- Around line 2646-2647: Add a single blank line separating the previous test
method (the block that calls execute(..., fn_name="id", raw_args=["abc"])) and
the next test method def test_fallback_wasm_type_direct to satisfy PEP8; locate
the execute(...) call and insert one empty line immediately before the def
test_fallback_wasm_type_direct declaration.

---

Duplicate comments:
In `@codecov.yml`:
- Around line 19-26: Update the Codecov config so the claimed "95%+ project
gate" is enforced: replace the generic target: auto under
coverage.status.project.python with an explicit numeric target (95) and change
informational: true to informational: false so the project status check is
blocking; reference the coverage.status.project.python block and the target and
informational keys in codecov.yml when making this edit.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tests/test_cli.py`:
- Around line 2647-2660: Add a brief one-line comment above the mutation in
test_fallback_wasm_type_direct to explain why spoofing
result.fn_param_types["id"] is safe: note that the underlying WASM function
still expects an i64 and Python int maps to it, so the fallback branch in
execute() (the else -> parsed.append(int(raw))) will still produce a valid
argument and the test remains valid; reference the
test_fallback_wasm_type_direct function, the result.fn_param_types mutation, and
the execute() call in the comment to make intent clear.