chore: updates readmes

BREAKING.md

@@ -4,8 +4,8 @@ Only `pkg/machine` and `pkg/states` adhere to semver. Semver of other packages i
 
 ## v0.10
 
-- `FooBar` handlers execute later and more often
-- `FooAny`, `AnyFoo` handlers has been removed
+- `FooBar` handlers get execute later and more often
+- `FooAny`, `AnyFoo` handlers have been removed
 - `AnyAny` is now `AnyEnter`
 
 ## v0.9

README.md

@@ -38,16 +38,18 @@ It has atomic transitions, relations, [transparent RPC](/pkg/rpc/README.md), [TU
 [telemetry](/pkg/telemetry/README.md), [workers](/pkg/node/README.md), and soon diagrams.
 
 Its main purpose is workflows (in-process or distributed), although it can be used for a wide range of
-stateful applications - daemons, UIs, bots, agents, firewalls, consensus algos, etc. **asyncmachine** can precisely (and
-transparently) target a specific point in a scenario and easily bring structure to event-based systems. It takes care of
-most contexts, `select` statements, and panics.
+stateful applications - daemons, UIs, configs, bots, agents, firewalls, consensus algos, etc. **asyncmachine** can
+precisely (and transparently) target a specific point in a scenario and easily bring structure to event-based systems.
+It takes care of most contexts, `select` statements, and panics.
 
 It aims at creating **autonomous** workflows with **organic** control flow and **stateful** APIs:
 
 - **autonomous** - automatic states, relations, context-based decisions
 - **organic** - relations, negotiation, cancellation
 - **stateful** - maintaing context, responsive, atomic
 
+[![diagrams](https://github.com/pancsta/assets/blob/main/asyncmachine-go/am-vis.svg?raw=true)](https://github.com/pancsta/asyncmachine-go/pull/216)
+
 ## Stack
 
 Top layers depend on the bottom ones.
@@ -135,8 +137,8 @@ mach.Add1("Foo", nil)
 mach.Is1("Foo") // false
 ```
 
-**Complicated** - wait on a multi state (event) and a sync state (Ready) with
-1s timeout, and mutate with typed args, on top of a state context.
+**Complicated** - wait on a multi state (event) and Ready state with a 1s
+timeout, then mutate with typed args, on top of a state context.
 
 ```go
 // state ctx is an expiration ctx
@@ -218,7 +220,7 @@ All examples and benchmarks can be found in [`/examples`](/examples/README.md).
 
 ## Getting Started
 
-🦾 [`/pkg/machine`](pkg/machine/README.md) is the main package, while [`/pkg/node`](pkg/node) is
+🦾 **[`/pkg/machine`](pkg/machine/README.md)** is the main package, while [`/pkg/node`](pkg/node) is
 the high-level usage. Examples in [`/examples`](/examples/README.md) are good for a general grasp, while [`/docs/manual.md`](/docs/manual.md)
 and [`/docs/diagrams.md`](/docs/diagrams.md) go deeper into implementation details. Reading tests is always a good idea.
 

docs/manual.md

@@ -184,7 +184,7 @@ inactive**. A list (slice) of state ticks forms a **machine clock**. The sum of
 current **machine time**.
 
 Machine clock is a [logical clock](https://en.wikipedia.org/wiki/Logical_clock), which purpose is to distinguish
-different instances of the same state. It's most commonly used by in the form of `context.Context` via
+different instances of the same state. It's most commonly used in the form of `context.Context` via
 [`Machine.NewStateCtx(state string)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.NewStateCtx),
 but it also provides methods on its own data type [`am.Time`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Time).
 
@@ -247,10 +247,10 @@ Methods to check the active states:
 
 - [`Machine.Is(states)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Is)
 - [`Machine.Is1(state)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Is1)
-- [`Not(states)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Not)
-- [`Not1(state)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Not1)
-- [`Any(states1, states2...)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Any)
-- [`Any1(state1, state2...)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Any1)
+- [`Machine.Not(states)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Not)
+- [`Machine.Not1(state)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Not1)
+- [`Machine.Any(states1, states2...)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Any)
+- [`Machine.Any1(state1, state2...)`](https://pkg.go.dev/github.com/pancsta/asyncmachine-go/pkg/machine#Machine.Any1)
 
 Methods to inspect / dump the currently active states:
 
@@ -386,8 +386,11 @@ States usually belong to one of these categories:
 1. Input states (e.g. RPC msgs)
 2. Read-only states (e.g. external state / UI state / summaries)
 3. Action states (e.g. Start, ShowModal, public API methods)
+4. Background tasks (e.g. Processing)
+5. Joining states (e.g. ProcessingDone)
 
-Action states often de-activate themselves after they are done, as a part of their [final handler](#final-handlers).
+_Action states_ often de-activate themselves after they are done, as a part of their [final handler](#final-handlers). _Joining
+states_ are used for relations with other states, as relations to an inactive state are not possible.
 
 **Example** - self removal
 
@@ -844,7 +847,7 @@ Side effects:
 
 [Mutations](/docs/manual.md#mutations) are the heartbeat of asyncmachine, while [relations](/docs/manual.md#relations)
 define the rules of the flow. Each [state](#defining-states) can have 4 types of **relations**. Each relation accepts a
-list of state names. Relations guarantee optional consistency among [active states](#active-states).
+list of state names. Relations guarantee consistency among [active states](#active-states).
 
 Relations form a Directed Cyclic Graph (DCG), but are not Turing complete, as they guarantee termination. Only
 [auto states](#auto-states) trigger a single, automatic mutation attempt.