Vision to stories

The Portal’s web surface was specified, built, and proven as chapter F6 in the companion course. Its vision is one line: serve the Portal to people. A vision names a destination, not a slice — so to turn it into work, read it into a ladder by asking, for every rung, which role gains what capability. The answer is the rung’s user story. F6 has nine rungs, and each one is a real As a <role>, I want… so that… line, quoted here verbatim from its f6.N.stories.md.

The roles are not generic. The first rung belongs to an operator — F6.1-US1: “As an operator, I want the Portal to boot as a Phoenix application, so that I can run and serve it with the standard Elixir/Phoenix toolchain.” The form errors belong to a learner — F6.5-US5: “As a learner, I want validation errors shown on the form, so that I can fix a bad submission without losing context.” The live search belongs to a learner too — F6.6-US1: “As a learner, I want the course list to filter as I type, so that I find a course without submitting or reloading.” A developer owns the safety rungs — F6.2-US4: “As a developer, I want every internal URL verified at compile time, so that a renamed or mistyped route is a build error, not a broken link in production.” Each rung calls only the unchanged Portal facade; F6.6’s live search is built at /elixir/phoenix/liveview.

A vision implies chores — “add a courses table”, “wire up a Phoenix route”. Those read like work, but they are not stories: they name a database or a router change with no role and no capability. The test for a unit of value is one question — does the line name a change a role can do? A line that does has a role and a verb that role can act on; it is a story. A line that does not is a task: restate it as the value it serves before it earns a place on the backlog.

Switch the candidate below. Real F6 stories are mixed with tautological task-phrasings; the classifier runs the one test and reports the verdict, naming the role and the change for a story, or the missing role for a task.

On the Portal — the learning platform this course builds — reading the vision into roles yields these nine stories. Each is the real Connextra line from its f6.N.stories.md, quoted verbatim; none is paraphrased. Read top to bottom and the vision “serve the Portal to people” resolves into a sequence of named roles, each gaining one capability. The Portal’s internals — the branded store and the event-sourced engine behind one facade — are built in the companion F6 chapter; here the work is the stories, not the code.

# Vision: serve the Portal to people.
# Read it into nine rungs — one role, one capability each (verbatim from f6.N.stories.md).

F6.1 # operator
  As an operator, I want the Portal to boot as a Phoenix application,
    so that I can run and serve it with the standard Elixir/Phoenix toolchain.

F6.2 # developer
  As a developer, I want every internal URL verified at compile time,
    so that a renamed or mistyped route is a build error, not a broken link in production.

F6.3 # operator
  As an operator, I want catalog and event data stored in PostgreSQL,
    so that nothing is lost when a node restarts or a new release is deployed.

F6.4 # developer
  As a developer, I want contexts to call each other only through public functions,
    so that boundaries hold and the dependency graph stays acyclic.

F6.5 # learner
  As a learner, I want validation errors shown on the form,
    so that I can fix a bad submission without losing context.

F6.6 # learner — built at /elixir/phoenix/liveview
  As a learner, I want the course list to filter as I type,
    so that I find a course without submitting or reloading.

F6.7 # learner
  As a learner, I want the catalog to update when someone else changes it,
    so that what I see stays fresh without reloading.

F6.8 # learner
  As a learner, I want to create an account and sign in,
    so that I have a real identity on the platform.

F6.9 # operator
  As an operator, I want course and enrollment counts that seed once and then update live,
    so that I read platform activity as it happens without ever re-querying.

The F6 vision — serve the Portal to people — read into nine real stories, one per rung, each owned by a named role: an operator who boots and runs the platform, a developer who gets compile-time link safety, a learner who sees errors inline and searches as they type. The test that separated value from a task was a single question — does the line name a change a role can do? A story has a role and a capability; a task names a chore. The ladder is a backlog, but not yet a refined one: some rungs are still too big to build in one slice. The next dive takes one rung and splits it, re-testing each piece.

Primary sources for reading a vision into role-owned stories, and the real F6 chapter this dive quotes.