[P2] Implement a first owned bounded vector slice for everyday data processing

[wsdt]

Audit: 2026-09-05, commit 2b3b1ee24da2.
Classification: Documented language/standard-library gap; proposed bounded enhancement. Priority: P2.

Finding

docs/STANDARD-LIBRARY-V1.md marks std.collections missing. Existing fixed byte arrays, Bytes, and owned record/variant cleanup are useful but do not provide a general collection for values accumulated at runtime. This blocks ordinary agent results, parsed data, and application state before an HTTP or JSON layer can become convenient.

Relevant foundations include src/ast.rs, src/hir.rs, src/byte_ops.rs, src/cleanup_plan.rs, and the admitted ownership profiles in docs/COMPLETION-MATRIX.md. Do not infer that general collections already exist from the systems-language goal.

First implementation boundary

Specify an additive owned vector limited initially to Copy scalar element types, with an explicit maximum element/byte capacity. Include construction, length, fallible push, checked lookup, replacement, pop, and deterministic iteration. Use existing Option/Result conventions. Defer nested owned elements and public FFI layouts to separate tranches.

Define ownership and borrowing before syntax: one owner, no accidental Copy, no stale borrowed view across mutation/reallocation, atomic failure on allocation/capacity exhaustion, and one destruction path. Select an ordinary library or compiler-owned intrinsic boundary explicitly; do not hide unchecked Rust/C collection semantics behind an innocent library name.

Acceptance criteria

• Parser, formatter, resolver, HIR, ownership verifier, graph, cleanup replay, interpreter, native, and Wasm agree on each admitted operation.
• Empty/full/cap+1, invalid index, failed allocation, moved owner, outstanding borrow, and early-return cleanup have regressions.
• Capacity arithmetic cannot overflow and failure does not partially mutate or leak the old collection.
• Iteration order and serialization facts are deterministic.
• One multi-file example accumulates and filters a variable number of scalar values.
• The standard-library catalog, exact target/profile admission, and completion matrix reflect only the implemented subset.

Suggested sequencing: establish the collection semantics before expanding JSON into arbitrary owned trees. A bounded zero-allocation JSON token view can proceed independently.

Agent handoff

Recheck the working revision and existing issues first. Read AGENTS.md, the relevant completion-matrix row, and the owning versioned specifications. This proposed slice must preserve canonical source, independent replay, precise target admission, and separately granted authority. Place regressions in the existing owning harness. Execute the applicable quality gates and record what actually ran; unrun native, hosted, or device evidence must stay unpromoted.

Audit revision scope

Runtime observations in this ticket belong to commit 2b3b1ee. A final source-tree comparison against e1c5b56 was used to check for obvious superseding changes. That later snapshot was not rebuilt or exhaustively retested. Reproduce on the intended fixing revision before implementation.

Audit ID: SPX-AUDIT-20260905-14

Suggested scope: L. Dependencies: None required.

[wsdt]

Not attempted. Leaving open, and recommending a re-scope — the blockers below were verified on the current tree, not inferred.

• No collection type exists at all. No Vec, vector or collection anywhere in src/ or std/. The only indexed data are [u8; N] (fixed, Copy), Bytes, and Slice<u8>.
• Bytes is explicitly immutable (docs/PORTABLE-INDEXED-BYTE-DATA-V1.md:75). The language has no in-place mutation of owned aggregates at all — only whole-local assignment and Copy-scalar field stores.
• Allocation inside a loop is a hard compile error. src/byte_data_capacity.rs:888-895 rejects "bytes_copy is reachable from a while condition or body". That is exactly the shape push needs. MAX_BYTES_COPY_SITES counts static sites, and the Wasm arena capacity is derived statically, explicitly "not sibling calls or loop iterations".
• The Wasm backend cannot allocate. FIXED_MEMORY_PAGES has min == max, no memory.grow is emitted anywhere, and a data-export test actively asserts that memory.grow fails. Owned bytes are opaque host-arena tokens, not linear memory.
• Exactly one owned parameter shape crosses a project boundary — own Bytes, in useful_data_workspace_parameter_admitted (src/hir/workspace_link.rs:721). Widening it breaks a frozen profile.
• The four files needing the most work are already over the module-size rule and frozen at their recorded sizes (tests/module-size-budget.tsv): hir/validation.rs 9269, wasm/aggregate.rs 8864, cleanup_plan/replay.rs 8117, cleanup_plan/build.rs 7126.

Adding one new owned type is roughly 80 files just to satisfy the exhaustive Type/ResolvedType matches. A backend-complete, profile-admitted owned vector is roughly 110–130 files and 8,000–15,000 lines, plus a new graph schema version and a new cleanup-plan schema. Even the cheapest honest framing — a fixed-capacity, write-once-then-frozen buffer built by one allocating builtin — is roughly 80 files and 3,000 lines and still needs a new profile and a Wasm host-import protocol.

There is no genuinely-complete slice of this issue that fits a single session, and a half-working owned collection is the worst possible outcome for a language whose invariants are ownership and cleanup correctness. So nothing was built.

Recommended re-scope before anyone starts

1. Split off "fixed-capacity write-once scalar buffer" as tranche one: allocate once with a known capacity, fill, freeze, read. This avoids push-in-a-loop entirely and so avoids the capacity analysis.
2. State explicitly in the issue that push in a loop is blocked by src/byte_data_capacity.rs and by the absence of a Wasm allocator, so a growable vector is a separate and much larger piece of work that needs those two decided first.
3. Decide the Wasm allocation story (memory.grow versus host-arena protocol) before the language surface, since it determines what can be admitted on that backend at all.

Also relevant: #78 records that the SPX-G171 pre-bound caps a std.* package at roughly 4.7 KiB, so even the library-side surface of a collection would be tightly constrained until that is resolved.

[wsdt]

Tranche one landed in 70e64a78 (on main): Owned Bounded Byte Buffer v1. This issue stays open — the general owned vector it asks for is still not buildable, for the reasons recorded in my earlier comment — but the first genuinely-complete slice now exists and executes.

The scoping decision

A growable vector remains blocked at two independent layers, both verified: src/byte_data_capacity.rs rejects allocation reachable from a loop, and the Wasm backend cannot allocate at all (FIXED_MEMORY_PAGES min == max, a test actively asserts memory.grow fails). So this delivers the fixed-capacity write-once tranche I recommended, which sidesteps both.

What was built

Two compiler-owned operations added to the existing ByteOp family — not a new type:

Function	Signature
bytes_zeroed	(count: usize) -> Bytes
bytes_set	(buffer: own Bytes, index: usize, value: u8) -> Bytes

Reading, freezing and iterating reuse bytes_as_slice / byte_len / byte_get / byte_range unchanged. No new type, no new cleanup leaf kind, no graph schema version, no new mutation syntax, and the single own Bytes project-boundary shape untouched.

The ownership model, defined before the syntax

One buffer is one write-once chain expression:

bytes_set(bytes_set(bytes_zeroed(2usize), 0usize, 65u8), 1usize, 66u8)

A bytes_set buffer operand must syntactically be the previous link. That single structural rule delivers every property this issue named:

• One owner — the chain has one allocation and one binding.
• Never Copy — it is Bytes.
• No stale borrow across the freeze — a partially filled buffer is never nameable, so no view can exist during the fill. This is unrepresentable rather than merely checked, which is the strongest form the requirement can take. Binding the result is the freeze; moving it afterwards while a view is live remains SPX-T265.
• Atomic failure — capacity exhaustion, out-of-range index, non-literal capacity or index, and a second owner are all compile-time diagnostics (SPX-T271, SPX-T272). No partial buffer is ever produced.
• Exactly one destruction path — verified against the emitted cleanup plan: allocation temporary, each call argument and each intermediate result are separate slots, all transferred, with exactly one core.bytes.drop finalize at exit. Cleanup vectors untouched downstream.

src/hir/validation/owned_buffer.rs re-derives the admission rule from resolved HIR alone, so a graph or patch route cannot forge a capacity or index — every forgery is SPX-H006.

Backends

Route	Result
Reference interpreter	Executes the full cycle
Native C11 (-O0/-O2)	Executes; leaks --atExit reports 0 leaks
WebAssembly	Precise checked rejection: error[SPX-W110]: bytes_zeroed is outside the WebAssembly owned-byte host arena protocol

The Wasm rejection is deliberate and documented, not a silent gap: owned bytes there are opaque host-arena tokens behind a frozen env import set, and admitting the feature needs new host imports plus stub updates across many JS harnesses.

Coordinator-verified

cargo test --locked -p semaprax --test language → 422 passed, 1 failed; --test module_size and --test source_locked_contracts pass. cargo fmt --all --check clean.

The single failure is pre-existing and I proved it rather than accepting the claim. generic_records::nested_generic_owned_records_keep_nonconcrete_and_nonrecord_descendants_closed asserts variant_errors.contains(&"SPX-T268"). Since this change touches HIR validation and the ownership catalogues, "not in my diff" was not sufficient — so I built a pristine detached worktree at origin/main (35a1399) and ran that test alone: 0 passed; 1 failed. It fails on main without this change. Filed separately as #84.

Three gates legitimately needed updating and were strengthened, not weakened: two source-locked contracts now read the new submodules, and the two builtin-catalogue tests went from 8 to 10 byte rows with per-parameter ownership moved from a positional rule to an explicit per-operation list — so bytes_set now proves it publishes an own operand.

Regressions in tests/language/owned_byte_buffer_v1.rs (existing harness, no new binary): success cycle across interpreter, native, graph and canonical round-trip with the one-drop cleanup assertion; empty; completely full; cap+1; non-literal index; non-literal capacity; capacity above ceiling; second owner; outstanding borrow across a move; loop rejection; Wasm rejection; three hostile-HIR forgeries.

What remains for this issue

1. Wasm admission — needs the allocation story (memory.grow versus host-arena protocol) decided first. That decision gates everything else.
2. Elements wider than u8 — i64/i32/usize/bool need either a compiler-owned Option<i64> return (only Option<u8> is specially wired today) or a stride-aware read family.
3. Loop-driven fill — still blocked by both original blockers.
4. Public FFI / project-boundary layout — untouched.
5. A std.* interface — none; docs/STANDARD-LIBRARY-V1.md says so explicitly.

Minor, deliberately left: a bytes_zeroed under a loop reports SPX-T267: bytes_copy is reachable from a while condition or body, because the shared allocation-family message names bytes_copy. The precise SPX-T252 fires alongside it. Changing the message would break a frozen golden in byte_data_capacity/tests.rs.

[wsdt]

Wasm admission landed. bf63cf6a "feat: execute bounded byte buffers on Wasm" implements the host-arena protocol; 4523d549 corrects two documents that still denied it.

The architectural decision, and its independent confirmation

The remaining work on this issue turned on one choice: memory.grow versus extending the host-arena protocol. I directed host-arena, on four grounds — owned bytes in Wasm are already opaque host-arena tokens behind a frozen env import set, so memory.grow would create a second incompatible model for the same concept; FIXED_MEMORY_PAGES min == max is a deliberate determinism invariant with a test actively asserting memory.grow fails; extending the import set additively preserves the frozen ABI; and a host-owned arena is what lets capacity be enforced rather than hoped for.

A sibling lane had independently reached and implemented the same design before that direction was acted on. A review pass against the requirements found no technical reason to revisit it.

What executes

(import "env" "spx_bytes_zeroed" (func (param i64) (result i64)))
(import "env" "spx_bytes_set"    (func (param i64 i64 i32) (result i64)))

spx_bytes_zeroed takes a usize capacity and returns a carrier; spx_bytes_set takes (carrier, index, value) and returns the same carrier, mutating one arena entry in place.

The frozen four are provably unchanged. The additions are indexed after them (BYTE_ZEROED_IMPORT = SCALAR_IMPORT_COUNT + BYTE_IMPORT_COUNT), so spx_bytes_copy/get/drop/as_slice keep their exact indices, names and signatures. Emission is gated on uses_owned_buffer, so a non-buffer module links against exactly the old four — any drift would surface as a LinkError across the ~25 files carrying hand-written env stubs, and those all still pass.

The "dozens of JS harnesses" concern I flagged turned out to be a non-issue by design rather than by special-casing: because the imports are conditional, only the shared browser_runtime() needed the two new stubs. Other harnesses instantiate non-buffer modules and correctly require no change.

Bounds are enforced host-side, not in generated code. spx_bytes_zeroed rejects non-bigint, negative and > 65536n capacity. spx_bytes_set decodes and authenticates the opaque carrier, then rejects a non-bigint/negative/>= byteLength index and a non-integer or out-of-0..255 value — before mutating. Generated code passes arguments through unchecked, so the host is the sole gate.

Evidence is genuine execution, not emission-only

Real Node v24.3.0 runs, with the skip-guard confirmed not to have fired. The test asserts value 7n over four rounds with maxOwnedByteEntries: 1 — a one-entry arena that only balances if there is exactly one owner and exactly one destruction path, which is a sharper check than a leak count. Plus a contract-failure program proving atomic failure still settles the arena, and a parser sweep asserting no memory.copy and no memory.grow appear in the code section.

--test owned_data 109/109, --lib wasm::aggregate::tests::owned_buffer 2/2, --test language owned_byte_buffer 8/8, --test project -- standard_library 16/16 including the three-backend conformance case, clippy clean. Coordinator-verified --test documentation 27/27 on the rebased tree before pushing 4523d549.

One pre-existing failure attributed properly: --test wasm fails scalar_browser_ci_contract::browser_known_answers_match_authenticated_baseline_and_rename_graphs, reproduced identically at bf63cf6a^ with byte-identical hashes. A project-graph digest baseline unrelated to owned buffers.

Two documents were still denying it — corrected in 4523d549

• docs/STANDARD-LIBRARY-V1.md claimed the buffer runs "on the interpreter and native C11 only".
• docs/BOUNDED-JSON-SCANNER-V1.md listed the Wasm SPX-W110 rejection as the first of three independent reasons the buffer cannot back a JSON key record. That one mattered: leaving it would have told the next [P2] Add a bounded JSON parser and writer usable from Semaprax programs #63 lane the Core-Wasm door was still shut. Now two reasons, both still true.

Two things worth knowing, both scope-relevant

1. A new rejection was added beyond the brief. SPX-W115 closes the public byte-export adapter against any owned-buffer program. Internal Core-Wasm executes; the public adapter refuses. That is defensible — a public adapter needs a descriptor and a committed ABI — but it means [P2] Add a bounded JSON parser and writer usable from Semaprax programs #63's output buffer will execute internally yet cannot cross the public Wasm boundary without further work.
2. SPX-T272 is now the real blocker for [P2] Add a bounded JSON parser and writer usable from Semaprax programs #63's key-record use, not the backend. Literal-only indices mean a scan-discovered offset still cannot be written. Wasm admission removes the portable-tier objection but not that one.

What remains on this issue

• Elements wider than u8 — needs a compiler-owned Option<i64> return or a stride-aware read family.
• A non-literal (usize expression) index, which is what a discovered-offset write requires and what SPX-T272 currently forbids. This is now the highest-value next step, because it gates both this issue's general-vector direction and [P2] Add a bounded JSON parser and writer usable from Semaprax programs #63's key record.
• Loop-driven fill, still blocked by the capacity analysis.
• Public FFI / project-boundary layout, and a std.* interface.

[wsdt]

A sibling landed the real thing: abf917d9 "feat: execute bounded generic vectors" — 3,639 insertions across 75 files, adding Vec<T> as a compiler-owned nominal type with stable identity core.vec, src/vec_ops.rs, docs/OWNED-BOUNDED-VEC-V1.md, cleanup-plan integration, and native plus Core-Wasm lowering.

This corrects my earlier analysis on this issue

I wrote that a general owned vector was not buildable because push-in-a-loop is blocked at two independent layers — the capacity analysis rejecting allocation reachable from a loop, and the Wasm backend having no allocator. On that basis I recommended a fixed-capacity write-once tranche, which is what 70e64a78 delivered.

That conclusion is now false, and the correction is worth stating plainly. abf917d9 admits a loop-carried profile directly:

"The first loop-carried profile is exact: a mutable vector is initialized once outside one bounded while, the body assigns that same binding exactly once from vec_push<T>(binding, value), and no borrow or other use of the vector crosses the assignment."

My analysis correctly described the constraints on the byte-buffer path I was reasoning about. It was wrong as a claim about the language, because a different design — an exact single-assignment loop-carried profile with staged-argument transfer at the call commit — satisfies the ownership rules the capacity analysis was protecting, rather than fighting them. Failure before commit leaves the old owner live; every exit after commit settles whichever single generation is live. General owned assignment stays rejected.

What is now admitted

Source	Identity	Signature
vec_with_capacity	core.vec.with-capacity	<T>(capacity: usize) -> Vec<T>
vec_push	core.vec.push	<T>(values: own Vec<T>, value: T) -> Vec<T>
vec_len	core.vec.len	<T>(values: borrow Vec<T>) -> usize
vec_capacity	core.vec.capacity	<T>(values: borrow Vec<T>) -> usize
vec_get	core.vec.get	<T>(values: borrow Vec<T>, index: usize) -> T

T is one of i64, i32, u8, usize, char, f32, f64, bool. vec_with_capacity accepts any usize expression — so the dynamic-capacity restriction I recorded against the byte buffer does not apply here either. A literal over 8192 is rejected statically; a dynamic value over 8192 selects sticky semaprax.vec.v1 code 3. Failures are sticky in that domain: code 1 push at full capacity, code 2 get outside initialized length, code 3 observable allocation failure — and cleanup cannot replace the selected status.

This maps onto this issue's asks directly: construction, length, fallible push, checked lookup, capacity, with one owner and no accidental Copy.

Against this issue's acceptance criteria

Met: exact source/HIR/formatter/Graph identity for all eight Copy scalars; rejection of inference, owned elements and oversized capacity; hostile-HIR forged element identity; forged cleanup-replay lifecycle staging/commit/status order; runtime execution across all engines without owner copy; sticky failures settling before re-entry; native stale and forged carrier rejection before access; Core-Wasm import routing. Capacity is charged target-neutrally at eight bytes per element and therefore cannot exceed 65536 bytes, so the overflow criterion is structural rather than checked.

Not met — one criterion clearly outstanding: "One multi-file example accumulates and filters a variable number of scalar values." abf917d9 adds no examples/ directory. That is now the concrete remaining gap on this issue.

Correctly not claimed: std.collections stays Missing in docs/STANDARD-LIBRARY-V1.md, needing the alloc tier and an authenticated transparent generic-intrinsic wrapper profile. The spec is explicit that ordinary authored generic functions cannot stand in for it. So there is still no std.* surface, which this issue deferred anyway.

Relationship to the byte buffer

70e64a78's write-once byte buffer (bytes_zeroed/bytes_set) and bf63cf6a's Core-Wasm host-arena admission are not superseded — they remain the Bytes-shaped facility, and Vec<T> explicitly rejects Bytes and String elements. Whether the byte buffer's remaining literal-index restriction (SPX-T272) still needs lifting for #63's key record is being re-assessed now that Vec<T> exists, since a Vec<usize> of discovered offsets may serve instead.

[wsdt]

The last outstanding criterion is met, and writing it exposed a compiler bug. 0e1a3657 on main.

Correcting myself again — the loop-carried profile did not actually work

In my previous comment I reported that abf917d9 admitted a loop-carried vec_push, and treated my earlier "push-in-a-loop is blocked" analysis as refuted. That was based on the specification text, not on running it. In practice, any

values = vec_push<T>(values, value)

inside a bounded while failed with error[SPX-H006]: while loop body changes owned liveness.

Why it went unnoticed for two commits: source verification, HIR validation (is_same_owner_push_hir) and the independent cleanup replay all admitted the shape. Only cleanup-plan build rejected it — and the evidence for the profile was replay-only. There was no end-to-end source test of loop-carried push anywhere in the tree. So the facility's headline use case was documented, replay-verified, and non-functional.

That is a direct argument for why this issue asked for a worked example rather than unit coverage.

Root cause and fix

Found by instrumenting lower_while: PlanBuilder::assign_slot appended a storage to whichever region asked for it, so the in-loop assignment re-homed the binding slot from the function's root region into the loop body's region. The body's exit_scope then finalized the vector on every iteration, live_order went [F] → [], and one linearized body pass no longer preserved owned liveness. Outside a loop it worked only because the let and the assignment share one region.

The fix is a placement rule, not a relaxation: a storage belongs to the region that first introduced it. It lives in src/cleanup_plan/build/bounded_vec.rs as storage_is_placed, with the rationale in its doc comment — re-homing would make the body's exit finalize a vector the enclosing scope still owns, so "the next iteration would read destroyed storage." Net −1/+17 lines, and build.rs lands at 7125 against its 7126 budget without raising it.

Coordinator-verified against origin/main: assign_slot there still only tests containment within the target region, so this bug was live upstream and is not an artifact of this branch.

The example

examples/vector-stats-project — Package Manifest v1, four modules, run → 0, test → project tests passed:

• readings.spx — reading_at(index) = (index*37+11)%100, kept(value, threshold)
• collect.spx — imports both by stable @id; initialises one Vec<i64> at capacity 12 outside a bounded while that pushes count readings, then a second bounded while walks it with vec_len/vec_get summing only the kept ones
• app.spx, tests.spx

The count is variable, and that is demonstrated rather than asserted. The gate interprets alert_total at counts 0, 1, 2, 3, 4, 9, 12 with the filter disabled and gets 0, 11, 59, 144, 166, 431, 574 — the exact running prefix sums of the series. The filter is a real predicate: the same nine readings give 431 / 310 / 0 at thresholds 0 / 50 / 97.

Three-backend conformance runs in useful_data::vector_stats_project::entry_and_conformance_return_zero_on_interpreter_native_and_wasm: interpreter, native C11 at -O0 and -O2 asserting no memcpy(result, source shallow carrier copy, and Core Wasm under Node against a one-generation host arena asserted empty after four rounds, so a leaked or double-owned carrier fails rather than passing quietly.

Coordinator-verified

--test owned_data 115 passed, --test useful_data 118 passed, --test module_size 1 passed, cargo fmt --all --check clean — all re-run by me on the rebased tree. The lane additionally reported --lib 1759 passed, --test cleanup_backends 127, --test language 437, --test examples 7.

One thing I broke and fixed: my own conflict resolution spliced the new LOOP_CARRIED constant into the middle of upstream's SET_FAILURE raw string, truncating it (error[E0425]). Repaired and re-verified before pushing.

Five limits of Vec<T> the example exposed

Worth recording, since none is in the specification:

1. It cannot cross an authored function boundary at all. own Vec<i64> and borrow Vec<i64> parameters are both SPX-O002 ("ownership mode is only valid for resource types"), and a returned Vec<i64> is unusable by a caller (SPX-F102 unsupported_callee). Only the authenticated transparent std.collections aliases may carry one through a signature — so a module split must be drawn around scalar helpers.
2. The public-adapter closure is module-level, so SPX-W115 refuses a web export whose module is merely imported by a module holding a vector — even when the exported function is pure scalar. Exporting from a module nobody imports is the only way out. This deserves a diagnostic hint; today it names a function you did not export.
3. Nested owned calls fail late: vec_get<i64>(vec_push<i64>(vec_with_capacity<i64>(1usize), 5), 0usize) gives SPX-H006: type ... has no cleanup facts, an internal-shaped message rather than an admission diagnostic. A let-bound form works.
4. No vec_len-typed boundary — it returns usize, which Project v1 boundaries reject (SPX-G174), so a published length needs a conversion the language does not offer.
5. The while tail-bool obligation doubles every loop condition, which is noisy for the accumulate-and-filter idiom that is now the facility's headline use.

[wsdt]

Closing: every acceptance criterion on this issue is now met and merged.

Criterion	Where
Parser, formatter, resolver, HIR, ownership verifier, graph, cleanup replay, interpreter, native and Wasm agree on each admitted operation	abf917d9 Owned Bounded Vec v1, plus the cleanup-plan placement fix in 0e1a3657
Empty, full, cap+1, invalid index, failed allocation, moved owner, outstanding borrow, early-return cleanup regressions	tests/language/owned_bounded_vec_v1.rs, tests/owned_data/owned_bounded_vec_runtime.rs
Capacity arithmetic cannot overflow; failure does not partially mutate or leak	Charged target-neutrally at 8 bytes/element, so it cannot exceed 65536; sticky semaprax.vec.v1 codes 1–3 with cleanup unable to replace the selected status
Iteration order and serialization deterministic	Exact source/HIR/formatter/Graph identity for all eight Copy scalars
One multi-file example accumulates and filters a variable number of scalar values	examples/vector-stats-project (0e1a3657)
Catalog, target/profile admission and completion matrix reflect only the implemented subset	docs/OWNED-BOUNDED-VEC-V1.md, std.collections package slice, matrix row

The example was the last one, and it earned its place: writing it exposed that the loop-carried vec_push profile — the facility's headline use — was documented and replay-verified but did not actually lower. Only cleanup-plan build rejected it, so replay-only evidence had passed it for two commits. Fixed by a placement rule (a storage belongs to the region that first introduced it), not by relaxing a check.

What this issue deliberately did not do

The original ask was a general owned vector. What shipped is an internal, explicitly instantiated Vec<T> for Copy scalar elements — no Bytes, String, authored aggregates, variants, resources or nested vectors, and no public aggregate ABI. std.collections stays Missing, needing the alloc tier and an authenticated transparent generic-intrinsic wrapper profile; the specification is explicit that ordinary authored generic functions cannot stand in for it.

The separate write-once byte buffer (bytes_zeroed/bytes_set, 70e64a78, Core-Wasm in bf63cf6a, computed indices in 09013e0e) is not superseded — Vec<T> rejects Bytes elements and has no vec_as_slice, so only the buffer freezes into a borrow Slice<u8>. They are parallel facilities that now share one deferred-commit mechanism.

Five limits recorded for whoever extends this

1. Vec<T> cannot cross an authored function boundary — own/borrow Vec<i64> parameters are SPX-O002, a returned Vec<i64> is SPX-F102 unsupported_callee. Module splits must be drawn around scalar helpers.
2. The public-adapter closure is module-level, so SPX-W115 refuses a web export whose module is merely imported by one holding a vector, even when the exported function is pure scalar. Deserves a diagnostic hint.
3. Nested owned calls fail late with an internal-shaped SPX-H006 rather than an admission diagnostic; a let-bound form works.
4. vec_len returns usize, which Project v1 boundaries reject (SPX-G174), so a published length needs a conversion the language does not offer.
5. The while tail-bool obligation doubles every loop condition, which is noisy for the accumulate-and-filter idiom this facility now headlines.

Those are follow-on work, not gaps in this issue's stated scope.