Added new macro features. resolve_value + default: key. Added raises to prevent CliGen features from being used outside of a already parsed state, and worked on specs. Will be working on specs later on as well to finish covering regex & redo timeparse & relative_operations

DESIGN.md

@@ -9,7 +9,7 @@ This document outlines the overall design of the CliGen shard & it's underlying
 
 ## How it works/High-Level overview
 
-Using crystal macros, you define the shape (arguments/flags, selections, work functions/subcommands, etc) and later on in `src/cligen/app/generate.cr` will use macros to (at compile time) generate `CommandNode(T)` objects & `Flag(T)` objects to contain your command/subcommand/arg parsing code from the data you provided in your `CliGen::Command` subclass.
+Using crystal macros, you define the shape (arguments/flags, work functions/subcommands, etc) and later on in `src/cligen/app/generate.cr` will use macros to (at compile time) generate `CommandNode(T)` objects & `Flag(T)` objects to contain your command/subcommand/arg parsing code from the data you provided in your `CliGen::Command` subclass.
 
 
 ## Architecture
@@ -72,8 +72,8 @@ The examples like above provide a "DSL-esk" way of defining:
 - Instance Variables,
 - Short/Long flags
 - Description of the flags (used in the help output as well)
-- A verification proc/lambda for doing ad-hoc checks of the value provided by the user (essentially allowing you to implement your own option: key like in selection)
-- Selections (currently compile-time and will open it up to runtime collecting of options later on based on defined annotations in the class)
+- A verification proc/lambda for doing ad-hoc checks of the value provided by the user (for cases where the `options:` key isn't expressive enough)
+- A static list of valid options via the `options:` key (currently compile-time; will open up to runtime collection of options later on)
 - define subcommands of this current command
 
 
@@ -405,7 +405,7 @@ This object serves as a wrapper around ARGV objects/strings/items and is used to
 
 ### Markdown Documentation Generation
 
-Since all command metadata is present in annotations at compile time (`@[CliGen::CommandInfo]`, `@[CliGen::SubCommand]`, `@[CliGen::Argument]`, `@[CliGen::Selection]`), the framework can walk the same structures that `generate.cr` already walks and render them into a Markdown document instead of a `CommandNode` tree.
+Since all command metadata is present in annotations at compile time (`@[CliGen::CommandInfo]`, `@[CliGen::SubCommand]`, `@[CliGen::Argument]`), the framework can walk the same structures that `generate.cr` already walks and render them into a Markdown document instead of a `CommandNode` tree.
 
 The generation would be driven by a `macro finished` block (similar to `generate.cr`) that emits a `self.generate_docs` class method on `App`. This method walks every `Command` subclass and its annotations to produce a structured document.
 
@@ -466,7 +466,7 @@ complete -F _myapp myapp
 Implementation notes:
 
 * Script body generated at compile time via a `macro finished` walk of `Command.subclasses`
-* `@[CliGen::Selection]` options (`%w[json yaml ecr]`) can be included as valid completions for their flag
+* `@[CliGen::Argument]` options (`%w[json yaml ecr]`) can be included as valid completions for their flag
 * Install path: `myapp --generate-completion bash > ~/.bash_completion.d/myapp` or printed with instructions
 * Same annotation data used by the doc generator, so both stay in sync with the command definition