# Post-Beta Roadmap

Slovo `1.0.0-beta` is the first usable general-purpose beta baseline. The next
work should broaden the language and toolchain in connected beta slices without
pretending that ABI, package, runtime, or standard-library contracts are stable
yet.

## Direction

The best continuation is not a single feature lane. Slovo needs alternating
language, compiler, runtime, stdlib, and tooling slices so each new capability
can be used in real programs and verified by the release gate.

Each slice should ship only when it updates:

- language and compiler docs
- source examples and standard-library modules when relevant
- formatter behavior
- diagnostics and negative tests
- hosted runtime behavior when relevant
- benchmarks or conformance tests when relevant
- release notes and the public roadmap

## Immediate Sequence

### 1. Tooling And Release Hardening

Goal: make the public monorepo easy to build, test, install, and verify.

Work:

- add `glagol run` for the common build-and-execute loop
- add `glagol clean` for generated build artifacts
- improve `glagol new` templates for library, binary, and workspace projects
- document install paths for `glagol`, `runtime/`, and `lib/std`
- make release gates print a concise final summary
- keep PDF rendering explicit and non-mutating by default

Released in `1.0.0-beta.1`: `glagol run`, `glagol clean`,
`glagol new --template binary|library|workspace`, `scripts/install.sh`,
installed std/runtime discovery, README coverage, focused DX tests, and a
concise release-gate success line.

Why first: it reduces friction for every later feature and gives users a better
way to exercise the beta.

### 2. Runtime And Resource Foundation

Goal: create a safer foundation for host resources before adding networking or
larger IO APIs.

Work:

- define beta resource-handle policy for files, processes, sockets, and future
  host objects
- make host errors consistently return concrete `result` values where possible
- audit allocation failure behavior for strings and vectors
- add runtime conformance tests for cleanup paths
- document that resource handles are beta values, not stable ABI promises

Released in `1.0.0-beta.2`: read-only text file resource handles are
implemented with `std.fs.open_text_read_result`,
`std.fs.read_open_text_result`, and `std.fs.close_result`. The same release
also includes narrow filesystem status and mutation calls:
`std.fs.exists`, `std.fs.is_file`, `std.fs.is_dir`,
`std.fs.remove_file_result`, and `std.fs.create_dir_result`. Matching
`lib/std/fs.slo` facades and focused runtime tests are in place. Writable
handles, directory handles/enumeration, process handles, sockets, platform
error codes, and async resources remain deferred.

Why second: networking, file IO, process IO, and HTTP all need a common story
for handles, errors, cleanup, and platform variance.

### 3. Standard Library Stabilization Pass

Goal: make existing `lib/std` modules feel coherent before adding many new
surface areas.

Work:

- mark each public helper as beta-supported, experimental, or internal
- normalize naming across `std.string`, `std.num`, `std.math`, `std.io`,
  `std.fs`, `std.env`, `std.process`, `std.cli`, `std.time`, and `std.random`
- add examples that compose multiple modules in one realistic command-line
  program
- add stdlib documentation generation coverage
- identify helpers that should wait for generics instead of being copied across
  concrete type families

Released in `1.0.0-beta.3`: `docs/language/STDLIB_API.md` is
generated from `lib/std/*.slo` and guarded by `scripts/release-gate.sh`.
`examples/projects/stdlib-composition` adds a realistic command-line project
that composes `std.fs`, `std.string`, `std.math`, and `std.io` through explicit
standard imports, with focused check/test/doc/run coverage.

Why third: stdlib growth is already broad enough that naming and stability tiers
matter more than adding another isolated helper group.

### 4. Language Usability Slice

Goal: reduce awkwardness in common programs without destabilizing the typed core.

Candidate features:

- `glagol run`-friendly `main` conventions and clearer entry-point diagnostics
- better `match` diagnostics and exhaustiveness checks where the current enum
  model allows it
- type aliases for long concrete types such as vectors, options, and results
- destructuring for simple structs and enum payloads
- additional numeric completeness such as `f32`, only if it can be tested across
  checker, formatter, runtime, and docs

Why fourth: these features improve real Slovo code while keeping generics and
traits deferred until the core has more feedback.

Released in `1.0.0-beta.4`: project/workspace build and run entry
diagnostics now use entry-specific codes and explicitly show the required
`(fn main () -> i32 ...)` contract. Non-exhaustive `match` diagnostics now use
clearer missing-arm wording and deterministic found-arm output.

### 5. Package And Workspace Discipline

Goal: make multi-package local development predictable before remote registry
work.

Work:

- document package identity, version, and local dependency rules
- decide whether a lockfile belongs in the beta package model
- add project-wide `fmt`, `check`, `test`, `doc`, `build`, and `run` behavior
- add diagnostics for ambiguous package roots and dependency cycles
- keep remote registry, semver solving, and publishing out of scope

Released in `1.0.0-beta.5`: local workspaces can declare `default_package` to
select the build/run entry package when multiple packages have entry modules.
Duplicate normalized member paths and missing default-package references are
dedicated diagnostics. Workspace documentation now includes package and local
dependency summaries, generated workspace templates declare
`default_package = "app"`, and `docs/language/PACKAGES.md` records the beta
local-package rules. Lockfiles, remote registries, semver solving, publishing,
optional/dev/target dependencies, and stable package ABI/layout remain out of
scope.

Why fifth: stable package rules are a prerequisite for a usable public language,
but remote publishing can wait.

### 6. Networking Foundation

Goal: add minimal blocking local networking after resource and error policy is
in place.

Work:

- add `std.net` with blocking TCP client/server primitives
- use loopback-only deterministic tests
- expose host failures through result values
- keep TLS, async, DNS policy, HTTP server frameworks, and event loops deferred
- add small examples such as echo client/server or local request/response

Released in `1.0.0-beta.6`: `lib/std/net.slo` now provides explicit wrappers
for loopback TCP connect, listen, bound-port lookup, accept, read-all,
write-text, and close result calls. The source fixtures use invalid port/handle
checks for deterministic result-shape coverage, and the compiler/runtime tests
cover lowering plus hosted loopback client/server smoke when the local sandbox
allows loopback sockets. DNS, TLS, UDP, async IO, non-loopback binding, HTTP
frameworks, rich host-error ADTs, and stable socket ABI/layout remain deferred.

Why sixth: networking is useful, but doing it before resources and host errors
would create unstable API debt.

### 7. Serialization And Data Interchange

Goal: make Slovo useful for command-line and network programs without requiring
maps/sets immediately.

Work:

- add string scanning/tokenizing helpers
- add simple JSON text construction helpers first
- defer full JSON object parsing until maps, richer strings, or generic
  collections exist
- add benchmark cases for parsing and formatting

Why seventh: networking and CLI tools need data interchange, but a complete JSON
library depends on collection work.

### 8. Generics And Collection Unification

Goal: stop duplicating every helper across concrete vector, option, and result
families.

Work:

- design generic function syntax and typed-core representation
- gate generic stdlib helpers behind conformance tests
- migrate repeated concrete helpers only after compatibility policy is written
- add generic arrays/vectors first, then maps and sets
- keep stable ABI/layout promises deferred until after real beta use

Why eighth: generics are important, but they should be introduced after the
compiler, docs, tests, and stdlib have enough real pressure to validate the
design.

### 9. Developer Experience

Goal: make Slovo comfortable for repeated daily use.

Work:

- language-server diagnostics and document symbols
- project watch mode
- generated API documentation for local packages and `lib/std`
- clearer benchmark harness output
- machine-readable diagnostics stability policy

Why ninth: editor support matters, but it should follow a stable enough syntax,
project model, and diagnostic model.

## Stable `1.0.0` Gate

Slovo should not become stable until all of these are true:

- migration and deprecation policy is documented
- `lib/std` has explicit stable and experimental tiers
- package/workspace behavior is deterministic
- conformance tests cover user-shaped projects
- release gates are reproducible on a clean checkout
- diagnostics and formatter output are stable for promoted features
- performance publications are repeatable and labeled as local-machine evidence
- the language can build useful local CLI tools, libraries, file-processing
  programs, and basic host-interaction programs without undocumented behavior

## Explicitly Deferred

These should not be early post-beta work unless a smaller prerequisite slice is
complete first:

- full async runtime
- TLS and certificate policy
- remote package registry
- macro system
- stable C ABI/layout guarantees
- optimizing compiler claims
- web framework or HTTP server framework
- broad Unicode/string normalization policy