Missing First-Class Data Types in Manifest (e.g., Ranges)

jorge commented

2026-03-17 23:07:22 -06:00

Owner

The ZerOS TOML manifest relies on the terminal to validate inputs before execution to provide a declarative CLI schema. However, some very common input formats are currently relegated to plain strings, which completely bypasses the terminal's ahead-of-time validation phase.

For devs: The open command currently defines the --lines (or -l) option with type = "string" to accept values like 10:20 or :50. Because the manifest type is just a string, the terminal's AST parser has no structural understanding of what a valid line range looks like. It cannot validate if 10:20 is a structurally sound range, or if the user accidentally typed 10:A0.

If the terminal doesn't validate it, the open program is forced to parse the string and handle the error itself during execution. This directly violates the "Fail fast and loud" engineering directive and the core promise of the declarative CLI schema, which dictates that applications should receive fully validated, strongly typed structs.

For users:
Without native type understanding, the shell cannot provide real-time syntax highlighting for invalid ranges (e.g., turning the text red when a letter is typed in a numeric range). Users only find out they made a typo after pressing Enter and reading an error from the application.

Test Examples

open -l 10:20 server.log (Valid range)
open -l abc:def server.log (Invalid range that should be caught by the shell before the program spawns)
open -l 10: server.log (Open-ended valid range)

The ZerOS TOML manifest relies on the terminal to validate inputs before execution to provide a declarative CLI schema. However, some very common input formats are currently relegated to plain strings, which completely bypasses the terminal's ahead-of-time validation phase. **For devs:** The `open` command currently defines the `--lines` (or `-l`) option with `type = "string"` to accept values like `10:20` or `:50`. Because the manifest type is just a string, the terminal's AST parser has no structural understanding of what a valid line range looks like. It cannot validate if `10:20` is a structurally sound range, or if the user accidentally typed `10:A0`. If the terminal doesn't validate it, the `open` program is forced to parse the string and handle the error itself during execution. This directly violates the "Fail fast and loud" engineering directive and the core promise of the declarative CLI schema, which dictates that applications should receive fully validated, strongly typed structs. **For users:** Without native type understanding, the shell cannot provide real-time syntax highlighting for invalid ranges (e.g., turning the text red when a letter is typed in a numeric range). Users only find out they made a typo after pressing Enter and reading an error from the application. ## Test Examples 1. `open -l 10:20 server.log` (Valid range) 2. `open -l abc:def server.log` (Invalid range that should be caught by the shell before the program spawns) 3. `open -l 10: server.log` (Open-ended valid range)

jorge self-assigned this

2026-03-17 23:07:22 -06:00

jorge referenced this issue from a commit

2026-03-18 13:45:29 -06:00

docs/programs: add first-class composite manifest types and migrate range/enum schemas

jorge closed this issue

2026-03-18 13:45:29 -06:00

Rows
Columns

Missing First-Class Data Types in Manifest (e.g., Ranges) #2

Test Examples