A kind of proof of concept for stories

story.txt

Story: writing a blog post

    user selects "new blog post"
    app goes to "new blog post" screen
        screen stays active while the user edits it
    {{DONE}}
    user selects "publish post"
    {{SAVE}}
    app publishes post

The above should be seen as all of the following:

* A part of the main program that other code hangs off of
* A part of the test suite that tests can be generated from
* A part of the workflow-focused stories that documentation can be generated from

The label {{DONE}} is there, because selecting "publish post" is only the most
straightforward outcome. At some point we'll want to specify other outcomes:

    at DONE
    user selects "save as draft"
    {{SAVE}}
    app saves as draft

    at DONE
    user closes the page
    app shows question "Do you want to save the post as a draft?"
        if yes
            {{SAVE}}
            app saves as draft
    app closes page

There are also error conditions that may be handled in a similar manner:

    at SAVE, when there is a network problem
    show message "Could not reach server, trying again..."
    app tries again
    ...

All the time, the focus is on

1. lifting out the major workflows of the application, keeping them as
   cohesive as possible
2. allowing side stories to be attached and connected to the major flows,
   threading in and out of it
3. showing things together that would usually be spread apart by virtue
   of being on different sides of an async call or user feedback