spec: move 4 directions into scope; remove spawn + open enums as non-goals

Per direction: promote the design-compatible deferred directions to a committed
in-scope roadmap, and DELETE the two anti-principle items rather than keep them.

In scope (new §20.2, cross-referenced from §20.1-B/C/G/I and §3.2):
- scoped views / slices, capability objects / explicit dynamic dispatch,
  cross-isolate message API, two-tier execution. All design-compatible.

Removed (not deferred) — stated as firm non-goals (§21):
- unstructured spawn / public task handles (breaks single-isolate structured
  concurrency; task_group is the form; compiler still rejects spawn).
- Rust-style open enums (breaks sealed-sum exhaustiveness + review diffs).

Dropped both from the §3.2 review-visible list and reframed the §14.6 dynamic-
dispatch subsection from "deferred" to "in scope, not yet implemented" (it must
still not be described as implemented until built). Updated the spec-guard test
accordingly and regenerated docs/spec-todo.md with the 4 open items.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: olwang

crates/rsscript/tests/checker_package/misc.rs

@@ -70,7 +70,10 @@ fn package_manager_spec_uses_current_http_and_env_facade_shapes() {
 }
 
 #[test]
-fn rss_spec_keeps_protocol_dynamic_dispatch_deferred() {
+fn rss_spec_keeps_protocol_dynamic_dispatch_unimplemented() {
+    // Dynamic dispatch is now a committed in-scope roadmap item (§20.2), but it is
+    // still NOT implemented: the spec must not describe it as implemented, settled,
+    // or available to package contracts until it is actually built.
     let spec = fs::read_to_string(common::language_spec_path())
         .unwrap_or_else(|error| panic!("RSScript spec should read: {error}"));
 
@@ -86,7 +89,8 @@ fn rss_spec_keeps_protocol_dynamic_dispatch_deferred() {
             "protocol dynamic dispatch must remain deferred, found `{forbidden}`"
         );
     }
-    assert!(spec.contains("Dynamic dispatch (deferred, not admitted in v"));
+    assert!(spec.contains("Dynamic dispatch (in scope §20.2; not yet implemented)"));
+    assert!(spec.contains("does not yet implement protocol-typed dynamic dispatch"));
     assert!(spec.contains("The only implemented and specified protocol call form is"));
     assert!(spec.contains("explicit `Protocol.method(...)` dispatch"));
 }

crates/rsscript/tests/fixtures/fail/spawn-not-executable.rss

@@ -1,6 +1,7 @@
 // expect: RS0015
-// `spawn` is review-visible but not executable in v0.6; it must be rejected before
-// lowering (the lowerer's Spawn arm is `unreachable_lowering`).
+// `spawn` is a firm non-goal (spec §21, §20.2): unstructured task creation breaks
+// the single-isolate structured-concurrency model, so it is rejected before
+// lowering (the lowerer's Spawn arm is `unreachable_lowering`). Use `task_group`.
 features: async, local
 
 async fn work() -> Int {

docs/RSScript_v0.7_Spec.md

@@ -660,14 +660,16 @@ REIR adapter for capability-binding evidence
 The following may be parsed and surfaced for review but are not executable lowering targets in v0.7:
 
 ```text
-spawn (unstructured task creation)
 public Future / Waker / task-handle surface
-Rust-style open enum machinery beyond sealed RSScript sum types
 general user FFI
-advanced protocol/dynamic dispatch model (capability objects)
-scoped views / slices
+advanced protocol/dynamic dispatch model (capability objects)  → now in scope (§20.2)
+scoped views / slices                                          → now in scope (§20.2)
 ```
 
+(Unstructured `spawn` and Rust-style open enums were previously listed here; both
+are now firm non-goals, see §21 and §20.2 — `spawn` is still rejected with a
+stable diagnostic.)
+
 `async fn` signatures are review-visible contracts. v0.7 admits an executable async
 MVP: `await` appears inside an `async fn` at a statement boundary, inside an
 `if`/`loop`/`match`/`with` body, or **nested in an expression** — an `await` in a
@@ -3640,17 +3642,19 @@ short-circuit `&&`/`||`, which is only conditionally evaluated. Hoisting it woul
 force unconditional evaluation, so such an `await` stays rejected as a non-linear
 await (`RS0411`).
 
-#### Dynamic dispatch (deferred, not admitted in v0.7)
+#### Dynamic dispatch (in scope §20.2; not yet implemented)
 
-RSScript v0.7 does not admit protocol-typed dynamic dispatch, trait objects, or
-protocol-typed values. The only implemented and specified protocol call form is
+RSScript v0.7 does not yet implement protocol-typed dynamic dispatch, trait
+objects, or protocol-typed values.
+The only implemented and specified protocol call form is
 static, explicit `Protocol.method(...)` dispatch backed by an explicit generic
 bound or an explicit `impl Protocol for Type` declaration.
 
-Future protocol dynamic dispatch is a design target, not a v0.7 promise. It must
-go through feature admission again and must not be described as implemented,
-settled, or available to package contracts until syntax, checking, lowering,
-review evidence, and package metadata exist together.
+Explicit, review-visible `capability`-bounded dispatch is now a **committed
+roadmap item** (§20.2-2, §20.1-G) — not Rust-style implicit `dyn` coercion, which
+stays a non-goal (§21). Until it is built, it must not be described as
+implemented, settled, or available to package contracts: syntax, checking,
+lowering, review evidence, and package metadata must land together.
 
 Closed sets should still prefer sealed sum types with exhaustive match
 (section 20.1), which are strictly more reviewable. For open sets such as
@@ -5271,6 +5275,7 @@ A. Extended async surface beyond the v0.7 MVP
    - must not expose Future / Pin / Poll / Waker to RSScript users (section 14.4).
 
 B. Cross-isolate message API with zero-copy transfer
+   - now in scope: committed roadmap (§20.2).
    - explicit typed send/receive channels between isolates.
    - cross-isolate payloads are owned/Copy data or values moved with take.
    - take-based move across an isolate boundary is the no-shared-alias transfer
@@ -5279,6 +5284,7 @@ B. Cross-isolate message API with zero-copy transfer
    - managed handles never cross isolates; only explicit messages do.
 
 C. Two-tier execution: dev interpreter + Rust-lowering AOT
+   - now in scope: committed roadmap (§20.2).
    - a HIR-level interpreter for the managed subset for a fast edit-run loop,
      since rustc compilation cost is poor for inner-loop iteration.
    - the Rust-lowering path remains the production/AOT target.
@@ -5315,6 +5321,7 @@ F. Registry-level review-risk badges
      signals to derive from compiler/package review evidence.
 
 G. Capability objects (explicit dynamic dispatch)
+   - now in scope: committed roadmap (§20.2).
    - RSScript does not adopt Rust-style `dyn Trait` with vtable coercion.
    - if dynamic dispatch is needed, it must use an explicit capability-bounded
      form that is visible to review:
@@ -5344,6 +5351,7 @@ H. Stream<T> and await-for (async sequences)
      or `Stream` combinators that hide allocation.
 
 I. Scoped views and slices (zero-copy borrowed regions)
+   - now in scope: committed roadmap (§20.2).
    - for high-performance parsing, HTTP buffers, and binary protocols, RSScript
      needs a "borrowed view" that avoids full-copy semantics:
 
@@ -5444,6 +5452,48 @@ positional records /         conflicts with named-everything canonical style;
 implicit flow promotion       any record-like form must use named fields
 ```
 
+### 20.2 In scope: committed implementation roadmap
+
+The following directions — previously deferred (§20.1) or listed as
+review-visible-but-not-executable (§3.2) — are now **committed in-scope work**
+targeted for implementation, tracked as open items in `docs/spec-todo.md`. All
+four are design-compatible: large, but they extend the model without reversing a
+review-first tenet.
+
+```text
+1. Scoped views / slices (zero-copy borrowed regions) — §20.1-I, §3.2.
+   Lexically-scoped borrowed views (`with Buffer.view(...) as bytes { ... }`, or
+   `view bytes = ...`) that cannot be retained, escape their scope, cross an
+   await, or enter managed graphs. No surface lifetimes. Design-compatible; large.
+
+2. Capability objects / explicit dynamic dispatch — §20.1-G, §3.2.
+   Review-visible `capability`-bounded dispatch (`store: read capability Store<T>`),
+   NOT Rust-style implicit `dyn` coercion (which stays a non-goal, §21). The review
+   map must flag every capability boundary. Design-compatible; large.
+
+3. Cross-isolate message API (zero-copy transfer) — §20.1-B.
+   Typed send/receive channels between isolates; payloads are Copy/owned data or
+   values moved with `take`; managed handles never cross. Depends on the isolate
+   model; design-compatible; large.
+
+4. Two-tier execution (dev interpreter + AOT) — §20.1-C.
+   The reg-VM and the Rust-lowering backend already run at parity; this commits to
+   the fast HIR-level dev loop as a first-class tier. Infrastructure, not new
+   surface — both tiers must keep identical semantics and diagnostics.
+```
+
+These four override the corresponding "not adopted" / "not executable in v0.7"
+notes in §3.2 and §20.1 for those features.
+
+**Removed, not deferred.** Unstructured `spawn` / public task handles and
+Rust-style open enums were previously listed as future directions. They are
+*deleted* from the roadmap, not merely deferred, because they contradict core
+RSScript principles: `spawn` breaks the single-isolate, structured-concurrency
+model (`task_group` is the sanctioned form), and open enums break the sealed-sum
+guarantees that make match-exhaustiveness and review-diffs sound. Both are stated
+as firm non-goals (§21); the compiler continues to reject `spawn` with a stable
+diagnostic.
+
 ---
 
 ## 21. Non-goals
@@ -5457,6 +5507,8 @@ LLVM backend
 JIT
 surface Rust lifetimes
 surface & / &mut
+unstructured spawn / public task handles (breaks single-isolate structured concurrency; use task_group)
+Rust-style open enums / open sum extension (breaks sealed-sum exhaustiveness + review diffs)
 Rust-style traits as source semantics
 associated types
 blanket impls