test: Phase 1 baseline & containment for #610

.github/workflows/ci.yml

@@ -25,6 +25,29 @@ jobs:
       - name: Check formatting
         run: cargo fmt --all -- --check
 
+  # The fuzz crate is a standalone workspace excluded from the root build, so a
+  # normal `cargo build` never compiles it — API drift in wfl could silently
+  # break every fuzz target. This job type-checks the targets against the current
+  # API on stable (libFuzzer/nightly is only needed to actually *run* them).
+  fuzz-check:
+    name: Fuzz targets compile
+    runs-on: ubuntu-latest
+    needs: fmt
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false
+      - uses: dtolnay/rust-toolchain@stable
+      - name: Cache Cargo registry and target directory
+        uses: Swatinem/rust-cache@v2
+        with:
+          workspaces: fuzz
+          shared-key: fuzz-check-cache
+      # `--locked` enforces the committed fuzz/Cargo.lock, so dependency drift
+      # fails the job instead of silently regenerating the lockfile.
+      - name: Type-check fuzz targets against the current API
+        run: cargo check --locked --manifest-path fuzz/Cargo.toml
+
   clippy-and-test:
     name: Build, Test, Clippy
     runs-on: ubuntu-latest
@@ -70,18 +93,20 @@ jobs:
           fi
           echo "panic=abort correctly rejected by the compile_error gate"
 
-      # Run tests (integration tests now have access to release binary)
+      # Run tests across the WHOLE workspace (root package + wflpkg + wfl-lsp),
+      # so the CI aggregate is a true full-workspace baseline. Previously this
+      # was `cargo test` (root package only), which silently skipped wflpkg's
+      # tests. (integration tests have access to the release binary)
       - name: Run Tests
-        run: cargo test --verbose
+        run: cargo test --workspace --verbose
 
-      # Build LSP to catch Send/Sync regressions
+      # Build the LSP binary explicitly as a focused Send/Sync build gate.
+      # (`cargo test --workspace` above already compiles and runs wfl-lsp's
+      # tests, so a separate `cargo test -p wfl-lsp` step would only duplicate
+      # them — it was removed.)
       - name: Build LSP
         run: cargo build -p wfl-lsp --verbose
 
-      # Run LSP tests
-      - name: Run LSP Tests
-        run: cargo test -p wfl-lsp --verbose
-
       # Run Clippy for code quality
       - name: Run Clippy
         run: cargo clippy --all-targets -- -D warnings
@@ -455,11 +480,12 @@ jobs:
             exit 1
           }
 
-  # Version bumping only happens after ALL checks pass
+  # Version bumping only happens after ALL checks pass — including fuzz-check,
+  # so API drift that breaks the fuzz targets blocks the post-merge version bump.
   bump-version:
     name: Bump Version
     runs-on: ubuntu-latest
-    needs: [fmt, clippy-and-test, integration-tests, database-tests, run-wfl-programs]
+    needs: [fmt, fuzz-check, clippy-and-test, integration-tests, database-tests, run-wfl-programs]
     if: github.event_name == 'push' && github.ref == 'refs/heads/main'
     permissions:
       contents: write

Cargo.toml

@@ -28,6 +28,11 @@ members = [
     "wfl-lsp",
     "crates/wflpkg"
 ]
+# `fuzz/` is a standalone cargo-fuzz workspace (nightly + libFuzzer only); keep
+# it out of the stable-toolchain root build/test.
+exclude = [
+    "fuzz"
+]
 
 [package.metadata.deb]
 assets = [

Dev diary/2026-07-13-issue-610-phase-1-inventory.md

@@ -24,8 +24,25 @@ demonstrably behaves correctly today.
 
 ## Inventory result
 
-**Total open at start:** 17 (16 tracked issues + the #610 tracker itself).
-**Closed as verified-fixed:** 10. **Remaining open after triage:** 6 tracked + #610.
+**Total open on GitHub at start:** 17 (16 tracked issues + the #610 tracker itself).
+
+**Reconciliation of the 16 tracked issues** — stated explicitly because "open"
+was previously conflated between two senses (*open on GitHub* vs. *genuinely
+unresolved*):
+
+| Bucket | Count | Issues |
+|---|---|---|
+| Verified-fixed **and** closed on GitHub | 10 | the *Closed* table below |
+| Verified-fixed but still **open on GitHub**, pending a close click | 1 | #573 |
+| **Genuinely unresolved** | 5 | #592, #578, #555, #600, #612 |
+
+Arithmetic: `10 + 1 + 5 = 16` tracked `+ #610 = 17`, matching the start count. So
+**6** tracked issues are still *open on GitHub* (the 5 unresolved **plus** #573),
+but only **5** are *genuinely unresolved*. #573 is verified-fixed — PR #574
+shipped binary read/write + MIME with byte-round-trip tests **before** this
+inventory, and the issue is open on GitHub only pending a close click (it was
+originally recorded here as an open "Medium" limitation in error). See the #573
+row below.
 
 ### Closed — verified fixed against 26.7.36
 
@@ -49,16 +66,19 @@ demonstrably behaves correctly today.
 | #592 | Zero-arg include-exposed action by bare name is fatal | **High** | Fatal (`exit 3`, `Variable 'greet' is not defined`) on valid natural multi-file API; the third call form #580/#581's fix did not cover. Repro still fails on 26.7.36. |
 | #578 | Remaining #571 rough edges (glob, pattern-VM, text→number, inference) | **High** | Confirmed functional bugs (wrong result/crash, not doc drift). Verified `list files … with pattern "*.txt"` still returns `0` on 26.7.36. |
 | #555 | Aspirational skipped tests + broken keyword_reference docs examples | **Medium** | Core websockets landed (#593), but session/CSRF/cookie middleware, direct-index syntax, and 10 docs examples remain; 3 `CI-SKIP` TestPrograms still present. Docs-examples-in-CI is a mandatory release gate. Feature parts are effectively post-production. |
-| #573 | Web server cannot serve binary content (fonts, images) | **Medium** | Real limitation (file read + HTTP body are text/UTF-8 only); blocks self-hosting static assets. Not a regression in existing behavior. |
-| #600 | Native TLS: SNI / multiple certificates on one `:443` | **Post-production-readiness** | Single-cert HTTPS works; multi-cert/SNI is a multi-tenant deployment enhancement, not a release-gate blocker. |
+| ~~#573~~ | Web server cannot serve binary content (fonts, images) | **Fixed (correction)** | **Reclassified: this was recorded open in error.** PR #574 shipped binary read (`read binary from …`), binary write, lossless byte round-trip, and MIME helpers *before* this inventory, guarded by `web_server_binary_test.rs`, `binary_io_test.rs`, and `binary_file_and_mime_test.wfl`. The issue's own latest verification (2026-07-06) recommends closing; it is open on GitHub only pending a close click. |
+| #600 | Native TLS ergonomics: SNI / multiple certificates on one `:443` | **Post-production-readiness** (SNI) · Dependabot alert #49 = *vulnerable code not used* | **Correction (source-level re-review).** An earlier revision reclassified this **High (security)**, treating the *presence* of `rustls-webpki` (alert #49, [GHSA-82j2-j2ch-gfr8](https://github.com/advisories/GHSA-82j2-j2ch-gfr8)) in the dependency graph as WFL exploitability. That overreached. The advisory's panic requires opt-in `RevocationOptions` **and** attacker-controlled CRL bytes; default rustls configs are unaffected. WFL's only TLS setup is `warp::serve(routes).tls().cert_path(…).key_path(…)` (`src/interpreter/mod.rs:6441`); warp 0.3.7 defaults client auth to `TlsClientAuth::Off` / `with_no_client_auth()`, and WFL configures **no** CRL / `RevocationOptions` anywhere (verified by grep) — so the vulnerable path is **not reachable**. Disposition: record/dismiss alert #49 as *"vulnerable code not used."* #600 itself is the **SNI / multi-cert enhancement** (post-production); it is **not** a reachable High WFL security defect, and its TLS rewrite is not established as required remediation on this evidence. The literal *no-open-High-severity-security* policy gate may remain administratively open until #49 is formally triaged. SNI priority is tracked on #600 independently. |
 | #612 | Make PR #609 resource-budget policies overrideable via `.wflcfg` | **Low** | Explicitly filed "low priority"; safe conservative defaults already ship. Config-surface polish. |
 
 ### Severity legend (aligned to #610's gates)
 
 - **Critical** — blocks a mandatory release gate: critical correctness/security,
   data loss, or uncontrolled resource exhaustion.
 - **High** — correctness defect on valid/supported programs (incl. fatal
-  false-positives) or a confirmed functional bug; must be fixed before RC.
+  false-positives), a confirmed functional bug, **or a *reachable* high-severity
+  security advisory** — the vulnerable code path must actually be exercised by
+  WFL's usage; the mere *presence* of a vulnerable dependency does **not** qualify
+  (see the #600 row); must be fixed before RC.
 - **Medium** — false diagnostics that don't change runtime results, or real but
   non-blocking feature limitations touching a gate.
 - **Low** — polish / configurability with safe current defaults.
@@ -67,12 +87,18 @@ demonstrably behaves correctly today.
 ## Phase 1 exit-gate read
 
 The exit gate for Phase 1 is *"No known production-readiness risk is untracked."*
-After this pass **no open issue is Critical**, and the two open High-severity
-correctness items (#592, #578) are tracked with reproductions. The remaining
-Phase 1 tasks (record scorecard baseline, integrate the shared ExecutionBudget —
-note #609 already merged — regression tests, fuzz targets, baseline metrics,
-supported-platform definition) are separate checkboxes and out of scope for this
-inventory entry.
+After this pass **no open issue is Critical**, and the two open High-severity items
+are both **correctness** defects (#592, #578), tracked with reproductions.
+Separately, Dependabot **alert #49** (`rustls-webpki`, high severity) is present in
+the dependency graph but its vulnerable code path is **not reachable** in WFL's
+usage (see the #600 row) — disposition *"vulnerable code not used."* It is therefore
+**not** classified as a reachable High WFL defect, and #600's TLS rewrite is not
+established as its required remediation; the literal *no-open-high-severity-security*
+policy gate may remain administratively open until the alert is formally
+triaged/dismissed on the Security tab. The remaining Phase 1 tasks (record scorecard
+baseline, integrate the shared ExecutionBudget — note #609 already merged —
+regression tests, fuzz targets, baseline metrics, supported-platform definition) are
+separate checkboxes and out of scope for this inventory entry.
 
 ## Compatibility / resource impact
 

Docs/README.md

@@ -221,6 +221,7 @@ Guidelines for quality, security, performance, and collaboration — aligned wit
 - **[Operator Reference](reference/operator-reference.md)** - All operators
 - **[Built-in Functions](reference/builtin-functions-reference.md)** - Complete function list
 - **[Error Codes](reference/error-codes.md)** - Understanding errors
+- **[Supported Platforms & Support Boundaries](reference/supported-platforms.md)** - Support tiers, platform matrix, toolchain/runtime requirements, and what "supported" covers
 
 ### Development
 

Docs/reference/supported-platforms.md

@@ -0,0 +1,140 @@
+# Supported Platforms & Support Boundaries
+
+This document defines the platforms WFL supports, what "supported" means, and
+the boundaries of that support. It is the reference for the **Maintenance** and
+**Operations** dimensions of the production-readiness plan
+([issue #610](https://github.com/WebFirstLanguage/wfl/issues/610)) and for the
+mandatory release gate *"Release artifacts, checksums, installation, upgrade,
+rollback, supported-platform, and known-limitations documentation are
+published."*
+
+> **Status:** WFL is currently **alpha** software (see [`SECURITY.md`](../../SECURITY.md)).
+> The support tiers below describe what the project tests and stands behind
+> *today*; they tighten as WFL approaches its 8/10 production-readiness gate.
+
+## Support tiers
+
+WFL uses three tiers. A platform's tier is defined by **what CI actually
+exercises**, not by aspiration.
+
+| Tier | Meaning | What you can rely on |
+|---|---|---|
+| **Tier 1 — Supported** | Built **and** tested on every PR in CI. | A release binary is built and the end-to-end `TestPrograms` + Rust integration tests (`cargo test --test '*'`) run on **every** Tier-1 platform; regressions block merges. Coverage is **not identical** across Tier-1 platforms — see *Per-platform PR CI coverage* below for the exact lanes each one runs. |
+| **Tier 2 — Best-effort** | Expected to build from source; **not** covered by CI. | The code targets it and contributors run it, but breakage is possible between releases and is fixed on a best-effort basis. |
+| **Unsupported** | Not built, not tested, not a goal for the 8/10 release. | May work, may not. No guarantees, no gate coverage. |
+
+## Platform matrix
+
+| Platform | Architecture | Tier | Evidence / notes |
+|---|---|---|---|
+| **Linux (glibc)** | `x86_64` | **Tier 1** | `ci.yml` builds + tests on `ubuntu-latest`: unit/integration tests, Clippy (`-D warnings`), database tests (PostgreSQL + MariaDB), and the `TestPrograms` runner. |
+| **Windows** | `x86_64` (`x86_64-pc-windows-msvc`) | **Tier 1** | `ci.yml` runs the integration + `TestPrograms` matrix on `windows-latest`. The MSI installer (`cargo-wix`) and its smoke test run in `nightly.yml` **after** merge, not on PRs. |
+| **macOS** | `x86_64`, `aarch64` (Apple Silicon) | **Tier 2** | Builds from source ([`installation.md`](../02-getting-started/installation.md) documents the flow) but is **not** in CI. Supported best-effort until a macOS CI lane is added. |
+| **Linux (musl / non-glibc)** | any | **Tier 2** | No CI lane; static-musl builds are expected to work but unverified. |
+| **Linux / other Unix** | `aarch64`, others | **Tier 2** | Pure-Rust with a Tokio runtime; expected to build where the toolchain and dependencies do. Unverified. |
+| **32-bit targets** | `i686`, `armv7`, … | **Unsupported** | Not built or tested. The interpreter runs on a large (1 GiB) call stack thread and assumes 64-bit address space. |
+
+**Promotion policy.** A Tier 2 platform is promoted to Tier 1 only when a CI lane
+builds it and runs the integration + `TestPrograms` suites green — a
+before-the-release-gate requirement, not a documentation change.
+
+### Per-platform PR CI coverage (what actually runs today)
+
+Tier-1 coverage is **not symmetric**. This table lists exactly what each Tier-1
+platform runs on a pull request, per `.github/workflows/ci.yml`:
+
+| Lane | Linux (`ubuntu-latest`) | Windows (`windows-latest`) |
+|---|---|---|
+| `cargo fmt --check` | ✅ | ➖ (Linux only) |
+| Full `cargo test` (unit + integration) | ✅ | ➖ (Linux only) |
+| LSP build + tests | ✅ | ➖ (Linux only) |
+| Clippy `-D warnings` | ✅ | ➖ (Linux only) |
+| Database tests (PostgreSQL + MariaDB) | ✅ | ➖ (Linux only) |
+| Rust integration tests (`cargo test --test '*'`) | ✅ | ✅ |
+| `TestPrograms` end-to-end runner | ✅ | ✅ |
+| Release **artifact publish** (checksums, installers) | ➖ | ➖ (nightly/post-merge only) |
+| Documentation-example execution | ➖ (not wired into CI yet — mandatory gate still open) | ➖ |
+
+Known gaps that are **not** yet gated on any PR: the full unit/LSP/clippy/DB
+suite runs on Linux only; installer testing is nightly and post-merge; release
+artifacts are not published from PR CI; documentation examples are not executed
+in CI; and the declared MSRV is not verified (see below). These are tracked
+Phase 1→3 items, not guarantees.
+
+## Toolchain requirements
+
+| Requirement | Value | Source of truth |
+|---|---|---|
+| Rust channel | **stable** | All CI jobs use `dtolnay/rust-toolchain@stable`. |
+| Minimum supported Rust version (MSRV) | **1.88** (declared) | `Cargo.toml` `rust-version = "1.88"`. The codebase uses `let`-chains (stabilized in 1.88), so older toolchains fail fast via `cargo`'s check. Note: CI builds on **stable**, so the 1.88 floor is *declared but not gate-tested* — an MSRV lane is a tracked follow-up. |
+| Rust edition | **2024** | `Cargo.toml` `edition = "2024"`. |
+| Build profiles | `debug`, `release` | Integration tests and `TestPrograms` require a `cargo build --release` binary. |
+| Disallowed | `panic = "abort"` | CI asserts the release binary rejects `panic=abort` (`ci.yml`), so panics stay unwindable/catchable. |
+
+## Runtime requirements
+
+- **Async runtime:** Tokio (`tokio` "full"). WFL's interpreter is async and
+  drives the runtime on a dedicated large-stack thread.
+- **Filesystem:** required for source loading, `include from` / `load module`
+  module resolution, and filesystem stdlib operations.
+- **Network:** required only for programs that use HTTP (`reqwest`), the web
+  server (`warp`), or databases (`sqlx`: SQLite/MySQL/PostgreSQL). No network is
+  needed to run a plain script.
+- **Resource ceilings:** every run is governed by the shared
+  [`ExecutionBudget`](../../src/exec/budget.rs) (recursion/import depth, pattern
+  steps/states, source/body/response bytes, HTTP/WebSocket queues and
+  connections, and optional operation/wall-clock ceilings). Defaults are
+  documented in [`configuration-reference.md`](configuration-reference.md).
+
+## What "supported" covers — and what it does not
+
+On a **Tier 1** platform, the project commits to WFL being *predictable,
+testable, documented, and operable* for **supported language behaviour**:
+
+- Supported language constructs behave consistently across the parser, analyzer,
+  type checker, and interpreter.
+- The documented CLI, `.wflcfg` configuration, and standard-library surface work
+  as described. (Automated execution of documentation examples in CI is a
+  mandatory release gate that is **not yet met** — examples are validated
+  locally via `scripts/validate_docs_examples.py` today.)
+- Release artifacts are produced by the nightly/release workflows (not from PR
+  CI) and installable via the documented paths; verifiable checksums are a
+  tracked Operations follow-up.
+
+Support **does not** extend to:
+
+- **Untrusted-code sandboxing.** WFL runs the programs you give it; the
+  `ExecutionBudget` bounds resource *exhaustion*, but WFL is **not** a sandbox
+  for hostile code. See [`SECURITY.md`](../../SECURITY.md) → *Known Security
+  Limitations*.
+- **Aspirational / unimplemented syntax.** Anything marked planned/future in the
+  docs is explicitly outside the supported surface until implemented.
+- **Tier 2 / Unsupported platforms**, per the matrix above.
+- **End-of-life versions**, per the version-support matrix in
+  [`SECURITY.md`](../../SECURITY.md) → *Supported Versions*.
+
+## Versioning, compatibility & lifecycle
+
+- **Versioning:** calendar-based `YY.MM.BUILD` (e.g. `26.7.36`). The major
+  component stays `< 256` for Windows MSI compatibility.
+- **Security-update lifecycle:** the current minor line receives prioritized
+  fixes; older lines get critical-only or no updates. The authoritative matrix
+  lives in [`SECURITY.md`](../../SECURITY.md).
+- **Compatibility & breaking changes:** backward compatibility for supported
+  language behaviour is protected by [`GOVERNANCE.md`](../../GOVERNANCE.md)
+  (§3.1/§3.2 stability policy; §2.2 breaking-change authority). Breaking a
+  supported program requires the documented deprecation path.
+
+## Reporting a platform problem
+
+- **Build/runtime bug on a Tier 1 platform:** file a normal issue with the
+  platform, architecture, Rust version (`rustc --version`), and a minimal
+  reproduction.
+- **Security issue:** do **not** open a public issue — follow
+  [`SECURITY.md`](../../SECURITY.md) (private advisory or email).
+
+---
+
+*Maintained as part of the production-readiness effort (issue #610, Phase 1).
+Update the platform matrix whenever a CI lane is added or removed, and keep the
+tiers in sync with `.github/workflows/`.*